OutSystems released a new version of our integrated development environment (IDE), Service Studio, at the end of July 2021. Before the release, we’ve shared a month of content on how our UX/UI Team tackled this project while building and implementing their very own Product Design System to create a delightful experience for all users.

As part of this series, we presented you with data on why illustrations add value to the interfaces of software products, courtesy of our Digital Designer David Monteiro; the Team Lead of the Product Content Team, Marina Calado, showed why writing the words that matter is vital to establishing a UX writing practice, and we interviewed our UX/UI Team Lead, Andreia Mesquita, about how OutSystems built its UX culture.

In the first part of this article, I shared my views on what it means to be a UX engineer and their main responsibilities while working side by side with Design and Engineering teams. In this article, I will deep-dive into my work at OutSystems by describing some of our UX processes, how we adapted across different projects, and what we achieved in the past year.

Creating a structured and well-defined design system is fundamental to help you sell such a framework within your company and highlight the value it will bring. This is why we chose a challenging starting point: one of the oldest applications by OutSystems — the Service Center.

Some of you might have heard about it as it was developed more than 10 years ago! Much like a pilot TV episode that helps sell a particular show, having pilot apps is perfect because you know exactly your priorities and where you should focus.

The Pilot Application

We have a decade-old application in our hands. Now what? We are aware of the impact that creating a disruptive change in this type of software will bring, as many of our users have been working with this application for a long, long time. So, we need to ensure that old users will have a pleasant new experience while new users still find it attractive and modern.

With some of the groundwork done — we synced the design and code according to the foundations we’d defined, and we audited the app -, we chose the top three most visited/used screens. Then, we extracted the primary components used, the basic inputs and controls, some tables and data, and the main existing styles.

Following this, we matched the old styles and components with the new design system we were building. After internal and external feedback loops with stakeholders and the team, we designed the first screens to be implemented. In the meantime, while management decisions were taking place, we continued designing and developing the first components to make sure they fit perfectly inside our product.

Finally, all was set for our first delivery as the Design System Team. We released the design files and code elements to the dev teams while introducing a completely new framework of components. And, just like that, the team had to learn how to use the new design system on top of a legacy system with more than 10 years while trying not to introduce any breaking changes!

It was precisely at this point that I switched roles from Design to Engineering, joining the Lifecycle Team as a UX Engineer to help them develop the app. The move was beneficial for us during the initial phase of the design system because it allowed us to improve and further define the system, but it also helped us with:

Advocating and Educating

As a UX engineer, by collaborating with the Engineering Team, you will have the opportunity to teach them how to use the system while also improving and supporting its ongoing development. The result? We end up with a new team that can fully build new products while using the system. Regarding advocating, it’s all about promoting the need and the importance of using the system and stressing its benefits and outcomes.

Collecting Feedback

While observing the team using the system, you collect feedback and change some components to make them easier to use in future development processes. You understand what works better and what needs to be improved in Code and Design and then bring back the feedback to the Design System Team to plan future work.

Building the Confidence to Succeed

Moving such a complex application to a new system and receiving great feedback from our users proved that continued improvement work on the design system would help us evolve and launch new products.

We have a Design System, Everyone Wants a Design System

As if this was not enough, different Design and Engineering teams were developing new tools and experimenting with the first draft version of the Product Design System at the same time. Use cases popped up both in design and code.

We focused on improving the system based on the pilot application’s feedback on the design system side. We also prepared for the future by taking in feedback from the experiments by different teams.

We were developing around eight different products/apps and constantly delivering features. Although the first version of the Product Design System was already in place, it wasn’t ready (yet) to escalate quickly. So, teams continued working on new features and designing specifications for new components. How did it end? A complete mess.

Apps that should have the same styles and behaviors looked and felt different. I’m not blaming anyone — we were doing the best we could. These mishaps happen, and it’s okay; we were one step closer to having a mean, well-oiled machine. We just needed to learn and overcome those issues.

So, we went back again to one of the pieces of advice shared in the first part of this article: we prepared the groundwork, designing and building all the necessary assets to accommodate every tool under development. We went through different stages during this process that helped us deliver the best experience for our teams and, most importantly, to our users!

Audit

By reviewing the work so far, you will once again have the opportunity to identify broken experiences and missing assets. Then, you can easily match those with the most recent features from the Product Design System while removing friction from the current implementation.

Awareness

Get involved with the teams and create regular syncs to show (and tell) what’s going on with the Product Design System. By doing this, our teams were able to:

1. Better estimate their work without having dependencies on the Design System Team.
2. Continue focusing on business logic instead of pixels (as mentioned in the first part of this article).

Make It Available, Reusable, and Open to Contributions

When all the pieces finally fit together, and we had a “final” version of our Product Design System — well, not final because design systems are constantly evolving, but I’ll leave that to a potential sequel of this text — it was vital to make it available and easy to use by everyone.

To achieve this and help different teams grow simultaneously, specific tools/assets from the Design System Team were fundamental:

• UI Library — A Figma file with all the necessary UI assets.
• Code Library — Ready-to-use OutSystems blocks on top of the OutSystems UI Framework.
• Product Design System Preview — An application where developers and designers can inspect and interact with the code configurations.
• Design System Documentation — More detailed and specific information about the entire system developed to build OutSystems products.
• Weekly sync meetings to understand the teams’ needs and collect feedback from the field.

Design System Today

Today, the Product Design System is the single source of truth and the baseline of any new development project inside OutSystems. In the meantime, we delivered a few more components and introduced a new theme for specific use cases. The best part? Teams are now fully autonomous to build their own components while using the foundations and the best practices from the Product Design System. And they do it more quickly and efficiently, providing a seamless user experience.

Is it mission accomplished? Well, yes and no. The work you put into a design system is never over. As your product evolves, so does your system, or you will end up with an obsolete framework.

That’s another peculiarity about working between design and engineering — in both these areas, your work is never done. You keep iterating, improving. And that’s a pretty cool thing when you enjoy being a UX engineer as much as I do.

Originally published at https://www.outsystems.com.

How Can a UX Engineer Help a Design System Team? Part 2 — The Build Up was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

OutSystems released a new version of our integrated development environment (IDE), Service Studio, at the end of July 2021. Before the release, we’ve shared a month of content on how our UX/UI Team tackled this project while building and implementing their very own Product Design System to create a delightful experience for all users.

As part of this series, we showed you how we grew our UX practice, explained how we used data to elevate our product’s look and feel, and spoke to our UX/UI Team about design systems in general and the one they helped create at OutSystems.

In this article, we’ll dive into the role of UX engineers and how their skills can help you turn design language into a code component library.

I’ve been working with front-end development, mainly CSS, for the past couple of years here at OutSystems. My goal? Trying to build the perfect CSS architecture using the most recent features and best practices for the OutSystems UI framework and following the best approaches for fitting components together seamlessly. Yes, you can blame me for some of the issues that you faced during your projects.

Last year I was challenged to embrace a new project and help our UX/UI Team build a design system and evolve our product (including Service Studio’s new version and other new tools). That was precisely what I was looking for after getting more familiar with design systems and what it entails to create one.

With that, my job role shifted from Front-End Software Engineer to UX Engineer, but at the time, the functions of such a position weren’t clear within the company. All the team knew was: “We need someone to help us translate the design into code, pattern behaviors into variables in a clean, scalable way, and who communicates with the different development teams.”

In other words, they were looking for someone who could help collaborate with the Design Team and the Engineering Team, turning the design language into a code component library.

So, What Exactly Is a UX Engineer?

Having worked with user experience, design files, and elegant pieces of implemented code, it was clear to me that I could play that role. I wanted to help the company craft exceptional experiences and welcomed the opportunity of joining a new team entirely focused on building a design system.

Looking back, I am thankful that I could focus on the tasks ahead before even knowing that the role of a UX engineer was a real thing. Job roles can be complicated to describe, and the term “UX engineer” often confuses people, including some at OutSystems, who ask me about what I do. Are you creative or technical? Do you work in the Experience Team or the Engineering Team? How is a tech guy so visually creative?

After walking the walk for a while, I had answers. All these questions lead to a fundamental issue: what do UX engineers do, and why do UX teams need them?

A UX engineer falls between UX design and software engineering. UX engineers, or UXEs, possess the skillset of a front-end or UI engineer, but they have a working knowledge of UX design principles. In essence, a UX engineer is a front-end engineer who works with the Design Team as the link between Design and Engineering.

As Teo Yu Siang explained in an article for the Interact Design Foundation: “UX unicorns [UX engineers] are a rare and special breed of people who can not only contribute to all phases of the design process; they can also take charge of front-end development.”

Thus, UX engineering bridges the gap between UX designers and software engineers. Often confused with front-end developers, UX engineers are the magic makers, bringing UX designs to life.

By doing so, they merge technical know-how and design aesthetics, partnering with programmers, UX researchers, designers, and more, to conceptualize and deliver an effective user experience focusing on the technical elements.

What Are Their Skills and Responsibilities?

The role of a UX engineer can vary depending on the project, team, or company, but these are the major skills and responsibilities we have to deal with daily. Essentially, a UX engineer is involved where it delivers the most value to the team and the product.

Ideation

During ideation, UX engineers contribute to discussions on usability, brainstorm solutions, and advise on any technical impediments. The latter is essential to help decide which ideas are feasible.

Design

We also work with UX/UI designers to create a library of consistent and usable components that will be used during the wireframing and prototyping phase and handed off to the Engineering teams.

Build and test

This is where the technical side of a UX engineer shines through, and the core skills are essential, such as HTML, CSS, Javascript, and OutSystems. We need to develop all the components, layouts, and parts of the designs. And here is where I spend most of my time: trying to build the best, most consistent, and reusable components that are performant, easy to use, accessible, and well documented, and which will be used by everyone.

Testing is crucial for a UX engineering role because it helps catch and fix issues early. Our goal when testing is understanding if we need to adjust or create new code or simply change the design. In the final production stages of a product, the UX engineer’s job is to reduce any potential friction. At OutSystems, we define friction as any bump in the road during the users’ journey whenever they aim at a particular outcome while using our product.

Communicate and collaborate

Great communication skills will help you collaborate smoothly with your design system’s stakeholders, such as Design teams, Engineering teams, and Product Management, to ensure that interaction and visual designs are implemented according to design specs. Talk to the team, understand their main challenges, and how you can help overcome them and build a relationship of trust. Also, use the company’s terms, not UX lingo, to ensure you’re communicating clearly.

It’s vital to communicate clearly and effectively with project teams during all stages of the design process and development while increasing awareness of the Product Design System and its adoption. Such will ensure that the designs are executed exactly as intended — with elegantly simple and efficient code.

And don’t forget about mentoring and providing guidance to other team members — whether they work in Engineering or Experience groups. Mentoring is a great way to propagate your design system and all the excellent work you’ve been doing.

When can you do this? Besides sync meetings, which are a great opportunity to pass on your knowledge, you can also set up training sessions on good practices and share documentation and other resources.

Finally, effective communication will also help you collect feedback to share with both the UX and UI design teams, improving the collaborative process and end result. I will further discuss these topics in the second part of this article.

The Life of a UX Engineer at OutSystems

Now that I’ve explained what a UX engineer is and does, it’s time to share some of the lessons learned after joining the OutSystems UX Group to help build a design system. I will provide you with more context in the second half of this text, but for the purpose of this article, all you need to know is that soon after our Product Design System was in place, we bumped into a wall.

The main issue was escalating quickly enough: as Engineering teams started building around eight different applications and products using our Product Design System, the Design Teams were still creating components, screens, and flows — and yes, you guessed it, it was sort of a mess.

Teams focused so heavily on delivering features that we jumped from “design” to “engineering,” failing to have someone linking the two. In fact, if code comes after the design, why can’t we have somebody who excels at programming writing this particular code?

We rapidly understood that this missing layer was essential for the design and development process. If you jump from one to the other, a huge chunk of design information can simply disappear. We will miss tiny details — such as how the interactions look, what happens when the user clicks here or there, the animations’ time — and fail to provide the best experience for our customers and users.

So, before jumping into design files, development, and planning our next steps, our first mission was to define how we would integrate code within the Product Design System and assess the main benefits of developing it ourselves.

This is how we came up with the code for our Product Design System — to bring order and consistency to our products and processes. It allows us to build, launch, maintain, and unify products: Engineering can focus on business logic instead of pixels, and designers can focus on user experiences, interactions, and flows. In the end, these components and materials are essential, as they act as a single source of truth for building products.

Stepping Stones

Finally, I got where I wanted! I was in the middle of CSS and Figma files, working with a new team, and ready to build the system! I won’t get into the details of what a design system is ( my teammates explain it well here) or which technical solutions we developed, but I will leave you with some of the lessons learned so you at least know where to start.

Sync Design and Code

The first rule is to have everyone communicate in the same language. Translation? It is vital that what you read in design is what you write in code. Start by defining your design tokens, foundations, and visual guidelines. Write them as simple CSS Styles using your preferred method.

Prepare the Groundwork

In new projects, it’s important to have time for experimentation. With your brand guidelines defined, you can start exploring how the many foundations connect and how they can be used in basic components like buttons and inputs.

If you are creating a design system for an existing system, the first thing to do is to make an inventory and audit all the work done so far. By doing that, we can see precisely where and how the experience is broken. Start by creating a complete list of all the UI elements and Interactions and group the visually similar ones.

Build and Document Your Component Library

Once all the styles fit together seamlessly, it’s time to start building your UI Library, including both your design and code foundations. With a ready-to-use and well-documented library, you are set to achieve a massive boost in productivity. I will get into more detail in the second part of the article, so watch this space!

With all these pieces in motion, do you remember why we started this in the first place? Well, you reached your destination. Now you have the proper tools to increase your productivity while delivering the best experiences — welcome to the life of a UX engineer!

Originally published at https://outsystems.com.

How Can a UX Engineer Help a Design System Team was originally published in OutSystems Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

So, there I was. A front-end developer who loves a good challenge. I was determined to turn an image into an elegant piece of code. And I also wanted to animate it. You see, for me, there is nothing more challenging than going deep into CSS and HTML, and honing these skills. Therefore, I’m always on the lookout for something that will push me and also allow me to evaluate where I can improve.

Before I found this challenge and as part of my self-improvement journey, I tried to play with the Daily CSS Images, but sadly I don’t have much time to do it! Another thing I do regularly is create small snippets of CSS interactions based on Dribbble Shots.

So when I came across Codevember, my heart skipped a beat! This was perfect. I would have to come up with a creative codepen every day based on the daily Codevember theme.

If you have read any of my previous stuff, you know that I love to play with CSS, so this challenge was the perfect opportunity to further explore these skills. Now the catch. I’m not a very creative guy, so I had to come up with some sort of technique to turn an image into an elegant piece of code.

And that’s what I’d like to share with you.

Pick Your Image; Break It Apart

To explain this process, I chose the iconic classic yellow tram that runs across Lisbon.

I drew the yellow tram as a two-dimensional vector graphic. Oh, and I excluded the graffiti. With an image editor (I used Illustrator, but you can also use Photoshop or Sketch), I picked colors and sizes and began to separate the main areas of the image.

Then I split each area of the image into even smaller pieces.

Image Pieces Into a Relative Stage

Now that I’ve set the relative stage for my tram, you can also create your relative stage because we will work with absolute positions and sizes. Inside the relative stage, create the number of divs that represent the image divided into main areas. And, inside each main area, create the divs that represent the smaller pieces. Then center the stage in the screen.

This will all make sense soon, I promise.

You can now create classes for each div with an obvious name — you know, call things by their names, as this will help you to know which element of the image the div corresponds to. Style each div with width/height and background-color or border to see the range of the areas, and then work with position absolute to position the divs almost in the right place.

Optimize Your Code

Now that we have this done, we can optimize the code. Code optimization is an important step especially when you’re dealing with CSS because the number of lines can turn your work into a scavenger hunt.

So, to optimize the code, you should:

• Identify the common repeated styles to help reduce the number of CSS lines. For example, all divs have the position absolute applied, so instead of declaring position absolute in the entire CSS, we only write it once and apply that class to the HTML. (For this example, I will only identify the repeated background colors, position absolute, and center elements horizontally.)
• Create useful classes for them.
• Write the created useful classes in HTML.

If you follow this advice, you can significantly improve your code, and it’s easier to debug.

Going Pixel Perfect

To appease the perfectionist in you, there’s even more you can do to ensure perfect-looking images:

• Remove the auxiliary styles that help you identify the main areas.
• Apply the correct background colors in useful classes.
• Style each div with the correct styles by applying the correct sizes, the correct position, and the other styles for a more accurate design.

For this example, I added some borders and a border-radius, and of course, I changed some positions and sizes to match the final UI Design 100%. Since some styles are duplicated, I created more useful classes to optimize the code.

Animate Your Images

If you know me, you know that I like to animate things. So, here’s what I did to animate our CSS image. I decided to create an animation that represents the idea of movement, and for that, I slightly changed our initial structure because I wanted to create two different types of animations:

I wrapped all the divs that I wanted to animate in a single div. This way, I only had to animate that div, instead of all the divs individually.

Since the railways have another animation, I had to move the railway divs outside the train divs.

Using only CSS Keyframes with some delays and times, this is the final result:

Questions? Write them in the comments below!

✉️ Subscribe to CodeBurst’s once-weekly Email Blast, 🐦 Follow CodeBurst on Twitter, view 🗺️ The 2018 Web Developer Roadmap, and 🕸️ Learn Full Stack Web Development.

From Design to Code: Creating and Animating Images with CSS was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ll let you in on a secret: If there’s one thing I love, it’s animating elements in mobile applications.

A while back, I wrote that animating for mobile can be easy if you follow the proper approach. I went through the advantages of animating properties in the Composite layer as it prepares the rendering and its calculations to be processed in the GPU.

Generally speaking, those are proven CSS3 animation guidelines that, once followed, will allow you to create fluid and smooth animations constantly running at 60 FPS.

So achieving performant animations in the Composite layer is not a problem. The problem is when you want to animate elements in the Layout.

The Problem of Animating in the Layout

So, I already know I should avoid using transitions that will trigger layout or paint properties — meaning top/left/right/bottom properties.

Here’s an example of how I used the top and height properties to create an animation:

And here’s the result:

And when I checked the timeline… ouch!

As you can see, this doesn’t create a fluid animation because it has the browser creating layouts each time, which will affect all of their children. Think of the children!

So, Sometimes CSS Alone Doesn’t Cut It

Elements in the Layout have widths or heights, lefts or tops. These are the cases in which CSS3 will not be enough. And that’s when this new method comes along. A method that flips the whole thing on its head.

Make no mistake: we’ll still be animating the Composite layer, but we’re doing pre-calculations and converting Layout animations into Composite ones. Cheaply, jank-free, smooth as butter.

And, don’t be afraid of that big word: pre-calculations. Yes, math is involved, but I’m here to make it as simple to grasp as possible. All the code I’ll show you is commented and easy to understand.

In order to manipulate styles in the Layout properly, without all that jank, CSS needs a little boost. This is where JavaScript comes to our rescue: it takes care of the calculations for you, so don’t go running for your TI-84 just yet.

What’s This FLIP Thing, Then?

FLIP stands for First, Last, Invert, Play:

• First: Initial state of the element we’re animating.

• Last: Final state of the element we’re animating.

• Invert: The magic show. This is where the fun happens, by calculating how the element changed since the first to the last position. (See commented code. Also, if you love magic, there’s more to be had here).

• Play: Apply the result between the First and the Last, using transform properties, so that the animation runs in the Composite layer.

Here’s the complete, commented code:

And then the CSS:

The result is this buttery smooth gem right here:

And what does the timeline show us?

FLIP Is Just Right for 60 FPS

Animations in mobile apps should run at 60 FPS. This is not always easy to achieve if you try to animate some styles that will impact effects in the Layout layer.

FLIP is really good for when you want fast responses immediately upon user action. And, for when you don’t know the exact location and dimensions of the object — because you’re smart and you consider all those different devices and screen sizes you have out there.

This kind of pre-calculation is possible because you have 100 ms after user input, where you can cook some magic to make something happen apparently instantaneously. Look at this beauty:

And here’s the code for you to play with:

See you on the FLIP side!

References

Smooth as Butter: Achieving 60 FPS Animations with CSS3, José Rosário

FLIP Your Animations, Paul Lewis

FLIPping Awesome Animations, David Khourshid

José Rosário | Mobile and Front-End Expert at OutSystems

You were going to leave without sharing? That’s FLIP’d up…

(editor’s note: I’ve lost control of José, I gave him this flip idea and now he can’t breathe without spilling out a cringe-worthy pun. If you’re reading this, I’m still hiding from him in a supply closet on the 3rd floor — send help!)

So please FLIP this to the top on Facebook, LinkedIn, Twitter, or email!

FLIP Your 60 FPS Animations, FLIP ’Em Good was originally published in OutSystems Experts on Medium, where people are continuing the conversation by highlighting and responding to this story.

Animating elements in your mobile applications is easy.

Animating elements in your mobile applications properly may be easy, too… if you follow our tips here.

While everyone is using CSS3 animations in mobile these days, many are not doing it properly. There are best practices to take into account that are constantly and considerably disregarded. This happens mainly because there are still people who don’t really understand the real reasons why those practices exist and are so vigorously endorsed.

There is such a large spectrum of device specifications nowadays, that if you don’t optimize your code to consider this, instead of animations that are smooth as butter, you’ll end up delivering a subpar experience to the highest share.

Remember: though there are some high-end, flagship devices out there which keep pushing the envelope, you still have most of the world using the type of device that compared to those spec monsters is nothing but an abacus with an LCD.

We want to give you a hand in harnessing the power of CSS3 correctly. To do just that we need to understand a few things first.

Understand the Timeline

What is the browser doing while rendering and playing around with the elements? This very simple timeline is called the Critical Rendering Path.

To achieve smooth animations we need to focus on changing properties that affect the Composite step, instead of adding this stress to the previous layers.

1. Styles

The browser starts calculating the styles to apply in elements — Recalculate Style.

2. Layout

In the following layer, the browser will start generating the shape and position for each of those elements — Layout. This is where the browser sets the page properties such as width and height, as well as its margins, or left/top/right/bottom for instance.

3. Paint

The browser will now start filling in the pixels for each element into layers. The properties that it uses are, for instance: box-shadow, border-radius, color, background-color, among others.

4. Composite

This is where you want to do your magic, as this is when the browser starts drawing all the layers in the screen.

Modern browsers can animate four styles pretty, pretty well, making use of the transform and opacity properties.

• Position — transform: translateX(n) translateY(n) translateZ(n);
• Scale — transform: scale(n);
• Rotation — transform: rotate(ndeg);
• Opacity — opacity: n;

How to Achieve the 60 Frames Per Second Mark

With this in mind, it’s time to roll up our sleeves and get to work.

Let’s start with the HTML. We’re going to create a very simple structure and put our app-menu inside a layout class.

Going About It the Wrong Way

See those properties we changed? You should avoid using transitions with the left/top/right/bottom properties. Those don’t create a fluid animation because they have the browser creating layouts each time, which will affect all of their children.

The result is something like this:

That animation is not smooth at all. We checked with DevTools Timeline to see what was happening under the hood, and this was the result:

This clearly shows FPS are irregular and that performance is quite slow.

“The green bar indicates FPS. A high bar indicates that the animation is rendering at 60 FPS. A low bar indicates sub-60 FPS. So, ideally, you want the green bar to be consistently high across the Timeline. Those red bars also indicate jank, so, alternatively, another way to gauge your progress is by eliminating those red bars.”
Thank you, Kayce Basques!

Using Transform

The transform properties affect a Composite. Here we’re telling the browser that layers will be painted and ready to go as soon as the animation starts, so there are fewer hiccups when rendering the animation.

That’s exactly what Timeline is showing:

The results start getting better, FPS are more regular and, therefore, the animation is smoother.

Running Animations in GPU

Let’s take it up a notch, then. To really get it running smooth and buttery, we’re going to use the GPU to render the animation.

Though translateZ() or translate3d() will still be needed by some browsers as a fallback, the will-change property is the future. What this does is that it promotes the elements to another layer, so the browser doesn’t have to consider the layout render or painting.

See how smooth that is? Timeline substantiates that:

The animation’s FPS are much more constant and the animation renders much quicker here. But there’s still a long frame running there. There’s still a little bit of a bottleneck at the beginning.

Remember the HTML structure created right in the beginning? Let’s control the app-menu div on that structure by using JavaScript:

The problem here is that by adding that class within the layout div, we made the browser recalculate styles one more time — and that affects the rendering performance.

The 60 FPS Smooth as Butter Solution

What if we have the menu created outside of the viewport area, instead? Having this in an isolated area will ensure that you only affect the element that you really want to animate.

So, we propose the following HTML structure:

And now we can control the state of the menu in a slightly different way. We’re going to manipulate animations in a class that gets removed when the time of transition ends, by using the transitionend function in JavaScript.

Let’s put it all together and check the results, then.

Here’s a complete fully-enabled CSS3 example, with everything in its right place:

And what does Timeline show us?

Smooth as butter, see?

Edit (17th Aug): Due to popular demand, here’s a working example for you guys:

Edit (23rd Feb, 2017): Part II of this article is live! FLIP Your 60 FPS Animations, FLIP’em Good

José Rosário | Mobile and Front-End Expert at OutSystems

You can bake a cake with all this butter! Tell your friends: LinkedIn | Twitter | Facebook | Email

The ideas shared in this post resulted partially from the research project RADicalize, which was supported by the EU and PT2020.

Smooth as Butter: Achieving 60 FPS Animations with CSS3 was originally published in OutSystems Experts on Medium, where people are continuing the conversation by highlighting and responding to this story.