TURK GUZELI – BOOK YOUR BEAUTY
TURK GUZELI – BOOK YOUR BEAUTY SESSION ONLINE IN TURKEY

APP Available only in Turkey .
Development : Naro Dev








No products in the cart.
A Narodev Creation :
– Amine G –
– Ilyes A –
– Mohammed .N.B –
You can use emoji (and other graphical unicode characters) in URLs. And wow is it great. But no one seems to do it. Why? Perhaps emoji are too exotic for normie web platforms to handle? Or maybe they are avoided for fear of angering the SEO gods?
Whatever the reason, the overlapping portion on the Venn diagram of “It’s Possible v.s. No One Is Doing It” is where my excitement usually lies. Graphically animating URLs is a new thing. So I decided to put a little time into the possibilities of graphical characters in URLs. Specifically, with the possibility for animating these characters by way of some Javascript.
First off, make sure your page’s Javascript code is being labelled as UTF-8 or you’re gonna have a bad time putting emoji in your code at all. This can be accomplished via an HTTP header, or page META tag. There’s a good chance you don’t have to worry about this. But you can find more info about this here: Unicode in Javascript by Flavio
To achieve our desired outcome of emoji dancing like sugar plum fairies in our address bar, we need a loop. And really, all we need is a loop. We start the loop, it loops, and we’re happy. So here’s our first loop, a spinning emoji moon. I think when they added this sequence of emoji they must have had this in mind right?
var f = ['?', '?', '?', '?', '?', '?', '?', '?']; function loop() { location.hash = f[Math.floor((Date.now()/100)%f.length)]; setTimeout(loop, 50); } loop();
Run Moon Code:
You can click the toggle checkbox above to see the result of this loop in your URL bar.
If you don’t like the spinning moons you can swap out that array with whatever emojis you want. Like a clock:
var f = ['?','?','?','?','?','?','?','?','?','?','?','?'];
Run Clock Code:
This is a real simple example. Too simple really. So let’s upgrade our loop so that it generates a string of multiple emoji! This time we’re utilizing the emoji “skin tone modifiers” characters to make some color-changing babies:
var e = ['?', '?', '?', '?', '?']; function loop() { var s = '', i, m; for (i = 0; i < 10; i ++) { m = Math.floor(e.length * ((Math.sin((Date.now()/100) + i)+1)/2)); s += '?' + e[m]; } location.hash = s; setTimeout(loop, 50); } loop();
Run Babies Code:
We use a sine wave controlled by time and position to select which color we want. This gives us a nice loopy color changing effect!
Or how about we revisit our moon spinner, spread it out, and make something resembling a loading indicator? Sure, let’s do it:
var f = ['?', '?', '?', '?', '?', '?', '?', '?'], d = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0], m = 0; function loop() { var s = '', x = 0; if (!m) { while (d[x] == 4) { x ++; } if (x >= d.length) m = 1; else { d[x] ++; } } else { while (d[x] == 0) { x ++; } if (x >= d.length) m = 0; else { d[x] ++; if (d[x] == 8) d[x] = 0; } } d.forEach(function (n) { s += f[n]; }); location.hash = s; setTimeout(loop, 50); } loop();
Run Multi-Moon Code:
But it’s not just emoji that give us a means to pump graphics out of our URL bar. There’s a whole boatload of unicode characters of interest to our goals.
Particularly interesting are the Box-drawing Characters:
Many of these lend themselves better to a two dimensional output. But they’re still pretty good on the single line we have to play with. For instance we can make a string of multiple height varied block characters and construct a nice little wave:
function loop() { var i, n, s = ''; for (i = 0; i < 10; i++) { n = Math.floor(Math.sin((Date.now()/200) + (i/2)) * 4) + 4; s += String.fromCharCode(0x2581 + n); } window.location.hash = s; setTimeout(loop, 50); } loop();
Run Wavy Code:
I liked this look so much I put it up permanently at wavyurl.com.
Using the variable width characters we can even wiggle on the horizontal, creating something like a progress bar:
function loop() { var s = '', p; p = Math.floor(((Math.sin(Date.now()/300)+1)/2) * 100); while (p >= 8) { s += '█'; p -= 8; } s += ['⠀','▏','▎','▍','▌','▋','▊','▉'][p]; location.hash = s; setTimeout(loop, 50); }
Run Progress Bar Code:
A progress bar huh? That’s like, almost useful. Which brings me to…
In an attempt to reduce the frivolity in our little experiment, I came up with the idea to show a web video’s progress in the URL. I simply attach a function that renders our progress string to the “timeupdate” event for a video, and voila! A video progress indicator in the URL, complete with the time and duration!
var video; function formatTime(seconds) { var minutes = Math.floor(seconds/60), seconds = Math.floor(seconds - (minutes*60)); return ('0'+minutes).substr(-2) + ':' + ('0'+seconds).substr(-2); } function renderProgressBar() { var s = '', l = 15, p = Math.floor(video.currentTime / video.duration * (l-1)), i; for (i = 0; i < l; i ++) { if (i == p) s +='◯'; else if (i < p) s += '─'; else s += '┄'; } location.hash = '╭'+s+'╮'+formatTime(video.currentTime)+'╱'+formatTime(video.duration); } video = document.getElementById('video'); video.addEventListener('timeupdate', renderProgressBar);
Run Video Progress Bar Code:
With the above checkbox checked, you can use the video below to try it out.
I rather like this lines and circle progress bar, but if you fancy some moon emoji, I’ve got you covered:
var e = ['?', '?', '?', '?', '?'], video; function formatTime(seconds) { var minutes = Math.floor(seconds/60), seconds = Math.floor(seconds - (minutes*60)); return ('0'+minutes).substr(-2) + ':' + ('0'+seconds).substr(-2); } function renderProgressBar() { var s = '', c = 0, l = 10, p = Math.floor(video.currentTime / video.duration * ((l*5)-1)), i; while (p >= 5) { s += e[4]; c ++; p -= 5; } s += e[p]; c ++; while (c < l) { s += e[0]; c ++; } location.hash = s+formatTime(video.currentTime)+'╱'+formatTime(video.duration); } video = document.getElementById('video'); video.addEventListener('timeupdate', renderProgressBar);
Run Video Moons Progress Bar Code:
Okay, calling this progress bar “useful” is a stretch. But if I squint, I can almost see a scenario where it would be useful to have this in a video sharing URL. Like YouTube has the option of creating a link to a video at a specific time. Might it not be cool to include a visual indication? Hmmm?
Maybe there is some more useful implementation of this “technology” that I haven’t come up with. I’ll keep thinking on that. And hey, maybe you can come up with something?
You may be wondering why I used “location.hash =” instead of the newer and shinier HTML5 History API. Two reasons. One solvable. The other less so. Both inconvenient.
Issue 1 is also a feature of the History API: It actually changes the whole URL path, not just the hash. So if I use the History API and change our page to “/?????”, it’ll look nicer than having tacked on a #. But it also means my web server must be able to response to “/?????”, or the user will be out of luck if they refresh, or otherwise navigate to the modified URL. This is doable, but trickier than using “location.hash =” which doesn’t require me to prepare the server in any special way.
Issue 2 is more unexpected. Turns out that in 2 out of 3 browsers I tested, the History API is throttled. If I push my wavy URL characters to the address bar at a fast rate I’ll eventually get the following error in Chrome:
Throttling history state changes to prevent the browser from hanging.
Safari is nice enough to give us a bit more info:
SecurityError: Attempt to use history.pushState() more than 100 times per 30.000000 seconds
Now if I stay under that limit I’m fine. But c’mon, 3 frames a second just doesn’t cut it for the ooey gooey URL animations I desire.
Good boy Firefox on the other hand doesn’t seem to give a hoot how many times I push a new history or how quickly. Which is gosh darn thoughtful of it. But breaking in two major browsers, plus neccesitating the web server configuration to fix Issue 1, makes me willing to put up with a little # in the URL.
I’ll leave it there. But I will tell ya that I’ve got a few ideas for making tiny games that display in the URL bar. Especially given the Braille Characters that we have yet to explore. So stay tuned for that.
If you have questions, comments, or simply want to keep up with my latest tinkerings, check me out on Twitter: @MatthewRayfield. Or subscribe to my almost-never-bothered email list here.
Oh and if you want the source for these URL mutilating abominations wrapped up in nice little ready-to-run HTML files, here you go ;]
Bye for now!
Nowadays it’s hard to impress or even surprise with an interface animation. It shows interactions between screens, explains how to use the application or simply directs a user’s attention. While exploring the articles about animation, I found out that almost all of them describe only specific use cases or general facts about animation, but I haven’t come across any article where all rules concerning animation of interfaces would be clearly and practically described. Well, in this article I won’t write anything new, I just want to collect all the main principles & rules in one place, so that other designers who want to start animating interfaces don’t have to search for additional information.
When elements change their state or position, the duration of the animation should be slow enough to give users the possibility to notice the change, but at the same time quick enough not to cause waiting.
Numerous researches have discovered that optimal speed for interface animation is between 200 and 500 ms. These figures are based on the particular qualities of the human brain. Any animation shorter than 100 ms is instantaneous and won’t be recognized at all. Whereas the animation longer than 1 second would convey a sense of delay and thus be boring for the user.
On the mobile devices, Material Design Guidelines also suggests limiting the duration of animation to 200–300 ms. As for tablets, the duration should be longer by 30% — around 400–450 ms. The reason is simple: the size of the screen is bigger so objects overcome the longer path when they change position. On wearables, the duration should be accordingly 30% shorter — around 150–200 ms, because on a smaller screen the distance to travel is shorter.
Web animation is treated in a different way. Since we are accustomed to an almost instant opening of web-pages in a browser, we expect to transit between different states quickly as well. So, the duration of web transitions should last about 2 times shorter than on mobile devices — between 150–200 ms. In other cases, the user will inevitably think that the computer freezes or has troubles with the internet connection.
But. Forget about these rules if you are creating a decorative animation on your website or trying to attract the user’s attention to certain elements. In these cases, animation can be longer.
You need to remember that regardless of the platform the duration of the animation should depend not only on the traveled distance but also on the size of the object. Smaller elements or animation with small changes should move faster. Accordingly, the animation with large and complex elements looks better when it lasts a little longer.
Among the moving objects of the same size, the first one to stop is the object that has passed the shortest distance.
Small objects in comparison with large objects are moving slower since they make bigger offsets.
When objects collide, the energy of collision must be evenly distributed between them according to physical laws. So, it’s better to exclude the bounce effect. Use it only in exceptional cases when it makes sense.
The movement of the objects should be clear and sharp so do not use motion blur (yes, After Effects users, not this time). It is difficult to reproduce the effect even on modern mobile devices and it’s not used in interface animation at all.
List items (news cards, email lists, etc) should have a very short delay between its appearance. Each occurrence of the new element should last from 20 to 25 ms. The slower emergence of elements may annoy the user.
Easing helps to make the movement of the object more natural. It’s one of the essential principles of the animation, which is thoroughly described in the book The Illusion of Life: Disney Animation, written by two key Disney animators — Ollie Johnston and Frank Thomas.
For the animation not to look mechanical and artificial, the object should move with some acceleration or deceleration — just like all live objects in the physical world.
Objects that are not affected by any physical force move linearly, in other words with constant speed. And just because of this fact they look very unnatural and artificial for the human eye.
All applications for animation use the animation curves. I will try to explain how to read them and what they mean. The curve shows how the position of the object (y axis)
changes during the same time intervals (x axis)
. In the current case, the movement is linear, so the object travels the same distance at the same time.
Linear motion can, for example, be used only when the object changes its color or transparency. Generally speaking, we can use it for the states when an object does not change its position.
We can see on the curve that at the beginning the position of the object changes slowly and the speed increases gradually. That means the object is moving with a certain acceleration.
This curve should be used when the objects fly out of the screen at full speed. Those can be system notifications or just cards of the interface. But keep in mind that such type of curve should only be used when the objects leave the screen forever and we cannot recall or return them.
The animation curve helps to express the right mood. At the example below, we can see that the duration of movement and the distance for all objects is the same, but even small changes in the curve give you the possibility to influence the mood of animation.
And of course, by changing the curves, you can move the object as similar to the real world as possible.
It’s opposite to ease-in curve, so the object quickly covers long distance then slowly reduces the speed till it finally stops.
This type of curve should be used when the element emerges on the screen — it flies up on the screen at full speed, gradually slows down until it completely stops. This can also be applied to different cards or objects that appear from the outside of the screen.
This curve makes the objects gain speed at the beginning and then slowly drop it back to zero. That type of movement is the most frequently used in interface animation. Whenever you doubt what type of motion to use in your animation, use standard curve.
According to Material Design Guidelines, it is better to use an asymmetric curve to make the movement look more natural and realistic. The end of the curve must be more emphasized than its beginning, so that the duration of acceleration is shorter than that of slowing down. In this case, the user will pay more attention to the final movement of the element and thus to its new state.
Ease-in-out is used when the objects move from one part of the screen to another. In such case, animation avoids the eye-catching and dramatic effect.
The same movement type should be used when the element disappears from the screen but the user can return it to the previous place at any time. It concerns the navigation drawer, among others.
From these examples follows a fundamental rule that many beginners neglect — the beginning animation is not equal to the ending animation. As in the case with the navigation drawer — it appears with deceleration curve and disappears with the standard curve. Besides, according to Google Material Design, the time of the object’s emergence should be longer to attract more attention.
A function cubic-bezier()
is used to describe the curves. It’s called cubic because it’s based on four points. The first point with coordinates 0;0
(bottom left), and the last one with coordinates 1;1
(top right) are already defined on the graph.
Based on that we need to describe only two points on the graph, which are given by four arguments of the function cubic-bezier()
: the first two are the coordinates x
and y
of the first point, the second two are the coordinates x
and y
of the second point.
To simplify your work with curves I suggest using sites easings.net and cubic-bezier.com. The first one contains the list of the most frequently used curves, parameters of which you can copy to your prototyping tool. The second source gives you a possibility to play with different parameters of the curve and immediately see how the objects will move.
Just like in ballet choreography, the main idea is to guide the user’s attention in one fluid direction during the transition from one state to another.
There are two types of choreography — equal and subordinate interaction.
Equal interaction means that the appearance of all objects obeys to one particular rule.
In that case, the appearance of all cards is perceived as one flow that guides user’s attention in one direction, namely from the top to down. If we don’t follow the order, the user’s attention will be scattered. The appearance of all elements at once would look bad as well.
As for the tabular view, it’s a bit more complicated. Here the user’s focus should be directed diagonally, so showing elements one by one is a poor idea. Revealing each element one by one will make animation excessively long, and the user’s attention will be zigzag-like, which is wrong.
Subordinate interaction means that we have one central object which attracts all user’s attention, and all other elements are subordinate to it. This type of animation gives the sense of order and draws more attention to the main content.
In other cases, it would be very difficult for the user to know which object to follow so his attention would be dispersed. Therefore, if you have several elements that you want to animate, you need to clearly define the sequence of their motion and to animate as minimum objects as possible at one time.
According to Material Design, when the moving objects transform their size disproportionally, they should move along the arc rather than in a straight line. It helps making the movement more natural. By “disproportionally” I mean that the change of height and width of the object by increase/decrease is carried out asymmetrically, that is with different speed (for example, a square card turns into a rectangle).
The movement along the line is used when the object changes its size proportionally. Since the implementation of such movement is much easier, the rule of disproportional arc movement is often neglected. Looking at the real examples of applications, you’ll see the domination of the linear movement.
The motion on the curve can be achieved in two ways: the first called Vertical out — object starts moving horizontally and ends with a vertical movement; the second — Horizontal out — object begins to move vertically and ends with a horizontal motion.
The path of the object’s movement along the curve must coincide with the main axis of the scrolling interface. For instance, on the next image we can scroll interface up and down and accordingly the card unfolds in a Vertical out way — at first to the right and then down. The reverse movement is done in the opposite way — that is the card first rises vertically and ends up moving horizontally.
If the paths of the moving objects intersect one another, they cannot move through each other. The objects should leave enough space for the movement of another object by slowing down or accelerating their own speed. Another option — they just push away other objects. Why that? Since we assume that all objects in the interface lie in one plane.
In another case, the moving object can rise above other objects. But again no dissolving or movement through other objects. Why? Since we believe that the elements of the interface behave in accordance with the laws of physics, and no solid objects in the real world are capable of doing that.
So, if we sum up all of the above-mentioned rules and principles, the animation in the interface should reflect the movements that we know from the physical world — friction, acceleration, etc. Imitating the behavior of objects from the real world we can create a sequence that allows users to understand what to expect from the interface.
If the animation is built correctly, then it is unobtrusive and does not distract the users from their goals. If it does, you either need to soften it or even remove at all. That means that the animation shouldn’t slow down the user or prevent from performing the task.
But do not forget that animation is more of an art than science, so it’s better to experiment and test your decisions on users.