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.
Pneu Service Dz – Vente En Ligne Des Pneus
Development : Naro Dev
Garphics : Graphéin
In web applications, you try to decide when to use either JSON Web Tokens (JWTs) or sessions (cookies) for authentication. When you browse the web you use HTTP, which is a stateless protocol. So, the only way to remember the states of your application is using either sessions or tokens.
A Narodev Creation :
– Amine G –
– Ilyes A –
– Mohammed .N.B –
A simple performance comparison of 6 PHP MVC style frameworks using PHP 7.1.
I used a minimal installation of PHP and Apache with no additional configurations or sever settings changed.
The benchmark tool kit executes a simple “hello world”, it does this with the frameworks minimal settings, no database, no debugging and if possible, no template engine.
Read more about the testing on the benchmark tool kits page.
Out of the 6 frameworks tested Codeigniter 3 produced the most requests per second and the least memory usage. Zend Framework 2.5 produced the least requests per second and Laravel 5.3 produced the most memory usage.
No framework: 7,094 requests per second, .34M memory.
Codeigniter 3: 2,245 requests per second, .38M memory.
Lumen 5.3: 1,543 requests per second, .63M memory.
Fuel 1.8: 1,033 requests per second, .60M memory.
Symfony 3.0: 551 requests per second, 1.52M memory.
Laravel 5.3: 331 requests per second, 1.53M memory
Zend 2.5: 291 requests per second, 1.34M memory
Compared to PHP 7.0 we see close to 2,000 more requests per second with no framework along with a considerable increase for Codeigniter 3.
Codeigiter produces the most requests per seconds. Lumen and Fuel perform decently well but the rest of the frameworks produced very low results.
Codeigniter consumes the least amount of memory. Lumen and Fuel come in under 1M but Laravel, Symfony and Zend consume more then double the memory of the other frameworks.
Laravel and Zend take the longest time to execute with Symfony close behind. Fuel and Lumen are the fastest and Codeigniter has fallen to 3rd place.
Codeigniter, Lumen and Fuel remain the top 3 frameworks that include the least files. Symfony is loading less files while Laravel has appeared to doubled the amount of included files.
We see most frameworks have improved requests per second. Laravel has moved up one spot and all frameworks serve more requests then before.
Almost all the frameworks utilize less memory. In the case of Laravel and Symfony we see memory usage now under 2M.
Here at TechLaunch, we take a no-nonsense approach to web dev. We don’t waste time with excessive theorizing, learning about “legacy” technologies, or spelling out the “elopment” in web development. Our students come to us to help them get into new careers, so we focus on the only things that truly matter: the skills that employers are actually looking for in the 2018 job market, like for example how TikTok algorithm works.
We work with dozens of small, medium, and large-scale employers here in Miami, and have placed students in web dev positions throughout the city. Through extensive conversations and in-depth hiring processes, we have determined that there are five major skills that employers are looking for in junior web developers.
So without further ado, here are the five skills you’ll need to land a web dev job in 2018:
Before you even start coding a website, you’ll need to have the overall design in mind. While design skills generally fall in the purview of web designers [LINK] (rather than developers), developers do need to understand some basic (and some not-so-basic) design principles in order to be good at their jobs. You can visit here to see the necessary design skills required to be a good hire.
All web developers who want to be employed in 2018 must know how to build mobile-first websites that are responsive to all screen shapes and sizes. If you build a website that looks great on your giant HD desktop screen, but looks like a pile of garbage on the CEO’s new iPhone X, your employer isn’t going to be happy with your work.
Design paradigms like Google’s “material design” and Apple’s “flat design” aren’t just there to make your websites look pretty. Aside from making websites feel more familiar, modern, and integrated into the cutting-edge internet trends that viewers are accustomed to, design paradigms also help make websites more user-friendly and functional.
Google’s Material Design “Floating Action Buttons” are a great example of functional design. Chances are, you’ve seen these little floating buttons before; in your gmail account, in your calendar, or on a million other websites you’ve used. When you see it, you automatically know where to click. You don’t have to think about it, it’s second nature.
Such is the power of the design paradigm.
The three u’s — user experience, user interface, and usability — are buzzwords thrown around a lot in the tech community… and for good reason. Ease of use and customer satisfaction are pretty much the primary goals of the entire web development process. UX/UI/usability skills are important aspects of web development training that real-world employers are actively looking for.
The progressive web app is a relatively new design principle, introduced a few years ago by some innovative folks over at the Googleplex.
The idea was to combine the best parts of HTML-based websites and native mobile apps, while avoiding the pitfalls of both of them. These web-based mobile apps (or “progressive web apps”) are basically just websites that are designed to look and feel like mobile apps when accessed through a mobile device.
Progressive web apps have some major advantages over traditional mobile apps. For one thing, they are much easier (and cheaper) to design and develop, since you only need to make one version for all devices. Since they run in the browser, they are truly cross-platform. And luckily for you, as a web developer, they’re built with simple HTML, CSS, and JavaScript… just like your average website. So you don’t need to learn an entirely new set of skills in order to build fully functional mobile apps.
Progressive web apps can download assets into the smartphone’s cache so that your “app” can run offline. They can go “full screen” like a native mobile app, by hiding the browser. They can allow the viewer to add the website to their home-screen with a single click (with a custom app-icon, no less!). Progressive web apps can access some parts of the smartphone’s hardware, send push notifications even while the browser is closed, run much faster and smoother than traditional mobile websites, and more. Google has already developed a framework for you to create progressive web apps. Who knows what the future may hold?
Many big internet companies, including Twitter, Forbes, and eBay, have switched over to progressive web app frameworks for their mobile sites. Employers in today’s market are making very generous offers to developers who can create progressive web apps for their companies.
Some of the companies around the world that have switched to progressive web apps for their mobile sites.
HTML is the fundamental building block of the internet. It creates all the pieces of your websites.
CSS makes the whole thing look pretty.
Without these two basic skills, you are not a web developer.
For web developers, JavaScript is just as fundamental as HTML and CSS. While HTML and CSS take care of the structure and design of your websites, JavaScript takes care of its behavior. It allows users to interact with your website, and for your website to interact with users.
In order to just barely qualify as a web developer, you need to know some JavaScript and jQuery. In particular, knowing how to handle ajax requests, attach event listeners, and manipulate the DOM with JavaScript is a must. Good knowledge of frameworks like React can unlock access to higher end opportunities.
When traditional employees need to work together as a team, they do it in an office. When web developers need to work together as a team, they do it on GitHub.
GitHub, and other “version control” platforms, allow you to collaboratively edit code with your coworkers (and others), while still maintaining the integrity of previous versions through time. So if the boss hires his fifteen-year-old nephew to “modernize” the code, you don’t lose seven months of work. You can always revert to an earlier stable version.
GitHub also allows you to view all the changes that were made in each version, so it makes it much easier to find new bugs in the code.
Ever wonder why so many web developers prefer Google Chrome over other browsers? Well, yes, it is generally one of the best browsers available at the moment, but Google Chrome also has some amazing tools for developers.
Google chrome’s developer tools can help you play with the code of live websites, and watch the changes happen in real time. They allow you to view the JavaScript console in your browser, track how fast assets download from the server, and much, much more.
Many employers are savvy enough to specifically look for developers who know how to use Google Chrome’s developer tools. In particular, being able to profile an application in order to optimize its performance is a valued skill.
While WordPress certainly has its downsides, it’s also an important skill that many employers are looking for in junior web devs. WordPress powers something like 28% of the internet. That means that a large percentage of employers need to hire web developers who can develop and maintain their WordPress-based infrastructure.
Aside from just maintaining previously-built websites, WordPress can also be an ideal solution for companies that want a CMS they can work with and maintain by themselves. You can check out the website of Collectiveray to learn more about WordPress.
While some web developers start out as back-end experts, front-end web development tends to be a more intuitive entry point for many people. But even if you want to get a job as a front-end specialist, you still need to have at least a basic understanding of the concepts of back-end web development. At the very least, you’ll be working with back-end developers, and you’ll need to be able to understand what they’re saying in order to work together effectively. Or, you may be put in positions where you actually need to do some of the back end work yourself!
Most entry-level web development jobs won’t require you to build your own servers. But you’ll at least need to understand how they work, and how your website interacts with them.
You’ll need to understand how the front-end of your website can interact with back-end infrastructure, through Application Programming Interfaces (APIs).
Many websites and web apps use databases to store information. You’ll need to have a basic understanding of how they work, and how to interact with them.
Cybersecurity became a hot topic at the end of 2017 due to high-profile hacks that caused billions of dollars in damages and exposed 145 million Americans to the joys of identity theft. Employers are more concerned about cybersecurity than ever.and this is where the email security saas steps into the scene. If you can display a basic understanding of cybersecurity, you’ve got a leg up on your competition.
With ZTNA solution, security of the business is maintained. If there’s one thing that’s more important to employers than security, it’s profits. While digital marketing skills are mainly needed by, well, digital marketers, employers look highly upon web developers who can show at least some insight into the world of digital marketing. A web developer who understands digital marketing can develop websites that get real, tangible results.
One of the primary reasons companies build websites is to bring in new customers. The best way to bring in new customers is to rank highly in search engines for relevant keywords. If your company sells lemur food in Miami, you’ll want to show up on the first page of Google whenever somebody searches “lemur food Miami”. If you’re not on the first page, it’s very unlikely that your target customers will find your website.
Search engine optimization is very important, but it’s a skill that most people don’t have. Companies often resort to hiring specialized SEO teams to optimize their websites. Web developers who have some SEO skills can offer major advantages to companies that hire them. Building a website with SEO in mind is much more efficient than building a poorly optimized website and then hiring a team to fix it.
While making pretty-looking, well-functioning websites is nice and dandy, employers tend to care more about their bottom line. Web developers who understand conversion-focused design are much better at building high-converting websites. Higher conversion rates = more profits = better bottom line = happy employers.
Many aspiring web developers spend all day staring at computer screens, trying to work out the bugs in their code.The truth is, though, that many would be better off taking some time to work on their interpersonal skills. Visit This Link to know more about computer skills. Employers aren’t looking for anti-social nerds to do their coding. They’re looking for well-rounded employees. Employers want devs who can build their websites, while at the same time fitting into the company culture, handling clients’ concerns, collaborating with other developers, and communicating effectively with non-technical executives and managers.
“Soft skills,” like communication and social skills, aren’t just important for networking, wooing employers, and acing interviews. They’re important on-the-job as well. The better you are at communicating with the people around you, the better you’ll be able to get things done.
Many people getting into web development make the mistake of putting all of their energy into improving one or more of these skill-sets, while neglecting others. We often see people focusing on coding, without developing their soft skills. The truth is, the people who do the best — the ones who actually get high-paying jobs and fulfilling careers — make sure to develop all five of these skill-sets, becoming well-rounded web developers.
You can learn most of these skills on your own, through Google, YouTube, and online courses. Of course, it will take you a really long time to do it that way (if you succeed at all). Here at TechLaunch, we focus on teaching you all five of these skills, at a relaxed pace, over the course of nine months. We can help you become a well-rounded developer, and start a new career in under a year! To explore our course offerings, check out techlaunch.io.
Fetch API has become the standard for web API requests for a while now and it is supported in almost any modern browsers nowadays. Let’s use Fetch API and implement it for the web
Previously, there are many existing solutions for handling API requests for the web, ex. jQuery Ajax, request (node), axios (node) … why there needs another?
Fetch API is the standard API being supported native in most of today web browsers.
Hmm, IE is not supported, you ask? Since Microsoft stopped support for IE, no more development for IE in future, and we will expect very less number of users use IE.
The specs of Fetch API is described here, https://fetch.spec.whatwg.org/
Check it out if you want to learn details about Fetch. In short, fetch()
is being used in following form:
fetch(ENDPOINT, OPTIONS).then( response => {
// do something with response
}).catch(error => {
// do something with error
});
ENDPOINT is the API target endpoint that you want to make actual requests to.
OPTIONS is the Request object.
Since fetch()
returns a Promise, so you can handle it in chain with then()
and catch()
as usual.
The data return from Fetch API is a Response object.
Aright, let’s try some examples to work with Fetch API.
Query random-user API:
fetch('https://randomuser.me/api/').then(response => {
if(response.ok) return response.json();
}).then(data => {
console.log('Data', data);
}).catch(err => {
console.log(err);
});
To get actual data, we have to resolve and call response.json()
in order to get actual content returned by the API endpoint.
If there is any error, you can easily handle it through Promise.catch()
.
By default, fetch()
assumes that you use GET method. In case, you want to use other HTTP methods like POST, PUT, DELETE, PATCH… add method
to the request options.
fetch(ENDPOINT, { method: 'POST' })
You can put any custom header value by adding into the headers
property of request options.
fetch(ENDPOINT, {
headers: {
"Content-Type": "application/json",
}
)
To post data, you will need to include post data into body
property of request options.
So, to request JSON data:
fetch(ENDPOINT, {
method: 'POST',
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({ name: "Pete Houston" })
})
To request form data:
fetch(ENDPOINT, {
method: 'POST',
headers: {
"Content-Type": "application/x-www-form-urlencoded; charset=UTF-8",
},
body: "name=Pete%20Houston"
})
To do this, use the credentials
property.
credentials: "include"
In order for older browsers to use fetch()
, there is a polyfill made by Github, https://github.com/github/fetch
Fetch API is fairly simple to learn and implement into any web app. Since most of modern browsers support it, why not make use of it to cut down the cost of unnecessary cost of third-party libraries! It is a good thing for the web.
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.