UI

Basics of Interaction Design and Animation

Baso Kamladze — Wed, 20 Jul 2022 11:08:05 +0000

Basics of Interaction Design and Animation Baso Kamladze Wed, 07/20/2022 - 15:08

It’s really hard to surprise someone In today’s world of UI, especially with user interface animations. Animation is one of the key tools in interaction design, it helps us understand how to interact with interface elements, it shows connections between elements/screens, and it focuses us on changes. Long story short, today I want to talk a bit about 4 basic principles of animation — speed, blur, easing, and choreography — and how we adapt them in the interface design.

Speed & Duration

Speed and duration are the key components of animation. When there is a change, it’s important to get the user's focus on that. So we use animation for this purpose, we are making the change slower and smoother to make changes clear (but we still need to be cautious not to make it too slow, which will distract the user and cause frustration).

The researchers have found that the optimal and acceptable speed for interface/interaction animation is from 100ms to 500ms (that's milliseconds, one-thousandth of a second) — it’s enough to focus on what’s changed and also not to make it boring). While animation faster than 100ms gives an illusion that things are changing immediately, animations that last more than a second are considered annoying and a cause of the user's frustration.

So let’s take Google's Material Design as an example. They use animation speeds between 100-500ms and this range is even smaller on mobile — 100-300ms. Sure, they’ve made several changes in the new Material 3 (You), animations are now much longer, but they are also more complex. Because of this complexity, there are several transformations involved in each interaction, so this is the reason why the total animation time goes from 200ms to up to 500ms in some cases. Yeah, those are some basics, but actually, each interaction has different speeds and durations on different devices. For example, the block entering the screen takes 250ms in mobile apps; the same interaction on tablets is 30% slower (300-350ms), and on a smartwatch, it’s 30-50% faster (100-150ms). Note that this applies to scale- and position-related animations, but for the icon and some other micro-interactions, speed is a constant 100ms on every device. The reason for that is simple — the bigger the screen size, the larger the distance an object has to travel.

Acceleration

Let’s get back to the main topic:

The first rule of interface animation is that animation speed increases proportionally to the distance. So for example, a 100px block has to travel for 200px and its timing is 200ms (traveling with 1px/ms speed), but if the travel distance is 400px, the timing won't be 400ms, and the speed will be accelerated and the animation will take about 300ms (so the speed will be 1.5px/ms in this case).

Animation speed and duration don’t depend on only the distance, but also on object size. Smaller elements are faster because they move more in an empty space than the bigger ones. For better visualization see the image below:

Blur

In general, the motion blur is used for a better and smoother animation, which adds life to the animation. But this is not the case in the interface animation. The animation is driven by the user’s action, aimed at increasing engagement and attention, motion blur will cause the loss of focus from what’s changed. Plus it’s hard to implement.

Easing

Everything in digital is inspired by the natural, physical world. To make the animation feel non-mechanical, but smooth and pleasant, it needs to have some kind of speed changes (i.e. easing). Easing gives movement (animation) a natural feel and connects it with the physical world. This is one of the main principles of animation.

There are several types of easing and I’m gonna discuss some of them below:

Linear Motion

The motion is linear when the object moves without physical impact (without acceleration). This type of motion is not natural and we don’t see it in real life, so it doesn't look pleasant to the human eye. We can use this type of animation only in cases when we need some static motions, like loaders, in other cases we don’t use it in the interface.

Ease-in

In this case, the object starts moving faster, but decelerates and becomes slower to the end.

We use this type of animation when an object/card is moving out of the screen and it won’t get back on the screen, so it’s for outgoing animations to get the user’s attention and show that this object is going and won’t return back. We don't want to bore the user, because they won’t have more connections with this card.

The main point of animation is to make a mood in the interface, even too small changes on the curves can make slightly different animations and interactions.

Ease-out

This is the reverse variant of ease-in, in this case, the animation starts faster, and then it becomes slower in the end. It’s mostly used for incoming objects to get the user's attention.

Ease-in-out

It’s a standard curve, which starts slowly, accelerates, and then continues slowly in the end as well. In most cases, it’s used to get the user's attention on every movement and change. Sometimes we use a slightly modified variant of this motion, which is called an asymmetric curve (it’s a bit faster in the beginning, then in the end, or vice versa).

Choreography

The choreography is the sequence, formation and continuity of animating elements to give the user the correct focus and to make transitions from one element to another.

Sequence

The sequence is an interaction, which shows the user what’s changing during the animation, from the starting point till the end, shows the whole process of animation, how the transition has started, what was changed, how it was changed, and what is the last result of the animation.

Element types

1. Outgoing elements - Things that disappear from the screen.

2. Incoming elements - Things that are appearing or incoming on the screen.

3. Persistent elements - These are elements, which are always on the screen, but sometimes they change shape, size, and position, but they never leave the screen.

Continuity

Animation needs to be continuous, especially when it’s used on multiple elements (like lists, cards, etc). Animation continuity means that an element starts moving about 50% earlier than the previous one ends, or else the elements will jump around and will irritate the user (unless it’s a case where elements have very fast transitions, 20-25ms).

I’ve tried to write a bit about the animation basics in digital products and if you’ll like it I’m gonna try to write another post about animation, with more detail, about its use in different design systems or devices, about patterns and the best practices, and about its psychological side.

Thanks! 😊

P.S. If you're interested in animation beyond interaction design, go ahead and read an amazing book The Illusion of Life by Frank Thomas and Ollie Johnston, key animators at Disney during the Golden Age of American animation. There is also a short video based on the 12 basic principles of animation described in the book.

Animation

Language English

Classic Tables vs Lists on Touch Devices

Baso Kamladze — Fri, 24 Jul 2020 14:28:08 +0000

Classic Tables vs Lists on Touch Devices Baso Kamladze Fri, 07/24/2020 - 18:28

Data is useless without proper arrangement, visualization, and tools. When designing data-driven user interfaces, it’s critical for the final product to be easy to act and interact with, to scan and understand the connection with its parts. Every type of data can be hard to visualize, but large datasets in enterprise applications are especially complex to break down.

There are multiple proven ways of presenting large datasets, like tables, lists, graphs, or charts. But right now, let’s focus on the data that needs to be displayed in a highly detailed manner, with granular filtering and sorting capabilities. With these requirements, classic Data Tables and Data Lists come to mind.

Data Tables have been around for ages and we’ve come a long way since the first tables of data displayed on the plain text-only terminal interfaces. There are lots of design patterns and time-tested solutions for the data table layout and mechanics, but in this post, I want to highlight my experience and what I’ve learned by working with classic Data Tables vs Lists on touch native, small-screen devices.

Classic Data Tables

When there is a need of displaying lots of attributes for a large number of data points (for example, the list of machines with their technical properties, deployment status, ownership details, etc), the go-to solution is to display it with a Data Table. With this approach you can benefit from the maximum available screen space, it’s easy for grouping and organizing information, making it scannable, comparable, and digestible. Also, Data Tables are relatively easy to develop and tables, in general, are native for most of the users from real-life — tables are everywhere, from school grade sheets to medical test results and simplest Excel documents.

Tables make it easy to filter, sort, manipulate, and take actions on the data. Bulk actions are natural for data tables as well — like selecting multiple rows and performing actions on the selection with a single click.

At first glance, everything seems awesome, right? That’s mostly true, for devices with larger screens (desktops or laptops) this works really well, because:

The widescreen size allows you to show a large amount of information in a single row and also, to show a lot of rows in a single screen. So users can scan and compare information efficiently.
For interaction, we use a mouse. With this, we benefit from the precise mouse pointer, giving users the ability to interact with small objects, which makes it perfectly usable to have smaller, more tightly packed controls in the UI. Also, with the mouse, we have the “hover state”, that we can leverage for displaying contextual information or actions only when we need them.

Data table on a large screen, where everything fits just fine.

Now enter the Touch Devices — tablets, phablets, smartphones, and other gadgets with a finger as a pointing device and no abundant screen real estate.

In this realm, small arrows which we were using for sorting become useless — tapping on tiny objects with our fat fingers is difficult and error-prone. This particular problem can be solved by making the sorting arrows a single control. Tapping the ‘merged’ button can cycle its state through sorting directions.

As for the table itself, the available screen width on smaller devices becomes the main villain. Keeping the table layout and making its container horizontally scrollable might be a viable option in some cases. But most of the time, the ‘scannability’ of each row is an important feature, which gets lost if you have to scroll horizontally just to see all columns of a single row.

Data table on a mobile device with horizontal scrolling. Meh.

Also, we have to figure out what to do with actions — usual suspects of the data table. We don’t want those buttons taking up precious horizontal space. Since in our use case mobile users will mostly visit the app for viewing the data, we can afford an extra tap for revealing the actions. So the action buttons can be collapsed into a single dotted control:

This also solves the issue of not having the hover state (and tooltips) on touch devices: we can put labels next to the action icons in this popout menu and keep things less ambiguous.

To sum up — pros of the data table:

General simplicity of the concept;
The native format for most of the users, familiar look and feel;
Ease of presenting the structured data;
Good for scanning the presented information;
Simple for development, with lots of available tooling.

It’s clear that the pros above apply mostly to large screens. On the smaller devices, we have to compromise in one way or the other.

Lists

Mobile devices are everywhere and the mobile-first directions for the UI designs are becoming more common. If your users spend a significant amount of time using your product on the go, it makes sense not to compromise for smaller screens but to rethink how to transform the data table.

Lists are multiline, vertically aligned data containers. Since each container has no fixed height, data can flow naturally and take up as much space as needed, without clipping or hiding behind the horizontal scroll. Data in the list item container is scanned in a natural F-shaped pattern.

So each row of our data table becomes a single container on the narrow screen. If we properly arrange the data points in each container and represent the information structure with visual hierarchy, we’ll be able to avoid most of the shortcomings that the data table has with limited available width.

With lists, we’re sacrificing the beautiful feature of the table — having the columns. Finding a row by a single data point is super easy when scanning a single column for it. But if the list container has a consistent layout, almost the same ease-of-use can be achieved with lists as well. When the layout (and data) is not overly complex, users will quickly get a grasp on the data arrangement pattern and mentally apply it to all containers, all without even thinking about it.

Our sample data table transformed into a list

We’re missing one thing here: we removed columns and sorting controls got lost as well. But since only a single column (data property) can be used for sorting at a time, we can turn this into the simple select box like this:

Conclusion

At the end of the day, every direction in UI comes down to the specific use case and to the expectations from the system.

You might have a dataset that has too few properties to cause problems in narrow-width data tables. Or your dataset might have lots of columns, making the list approach not feasible. So before jumping to a solution, think about the users and get as much information as possible on their usage situations — how will they use this interface, what are the most common goals and decide accordingly, trying to make life easier for most of your audience.

Data Design

Data Tables

Language English