One of the key features of the Google's new Material Design is introduction of more animations than we have seen before in the guidelines. Material Design is all about bringing tactile materials to our UIs. Things in real life move and interact with our touch in a certain way. With the new guidelines Google is bringing that familiar feeling and interaction to Android apps.
Read more from the Google's guidelines for animations here:
http://www.google.com/design/spec/animation/
Animations can be both one of the most powerful tools in your UI design and the most destructive. A well designed animation can be both helpful and delightful. A bad animation is annoying and counter productive.
Android L release and the Material Design guidelines are adding a lot of options to designers and developers for using animations in their apps. Personally, I'm willing to bet that we're going to see an explosion of animation exploitation. As with everything new people get over excited and tend to overuse the new (and flashy) techniques. This will most likely be met by disapproval from users and the animation will be stripped out from many apps. It will take time until we'll find the right way to use these new tools.
In this article I want to take a look at one of the most important types of animations in Android apps. Activity transitions.
In Android apps activities are construct that can often be seen as screens in design. More often than not an activity is a screen in an Android app. Users navigate in the app by moving from activity to activity (from screen to screen).
Until lately now, most apps use Android default transitions between activities. The default transition is usually a sliding animation of some sort (depending on device and Android version). Here's an example of an app using default activity transition.
The transition animation is simple and subtle but important. It indicates to the user that a new entry has been added to the user's back stack. A similar, but reversed, transition is played when user taps the back button.
The back button interaction is why I have been advising against overriding the default transitions without a good reason to do so. Android's back button interaction is already difficult to grasp and changing the subtle indicators might make users hesitate.
However, there is a downside to the default transition. User is now teleporting between completely detached screens even when the screen content is clearly related. In the above example the user is pressing an apartment image to get details of the that item. There is a disconnect. That is what Google is trying to fix with the set of new tools and guidelines for developers and designers.
The Android launcher as well as the Google Now launcher already animate launched apps from the launch icon and the multitasking UI animates the selected app from the thumbnail.
All this was made possible by APIs that allowed developers to define the source view for launched activity. Some apps have been using that feature for some time already.
Let's take a look at Wally app. The app has a list of images and when user selects one of them the details activity is launched from the image.
This is still a form of teleporting between screens but the teleportation is more pleasant. User has better feel of continuum but it could still be much better.
The keyword here is continuum. These activity transitions allow us to design apps where screens are connected to each other with hero elements. By hero elements I mean elements that are central to the content and are present on both screens.
Let's look at an example.
A common case in many, many apps is that there is a list of items and tapping one of them user moves to another page for more information about that item. Traditionally we have relied on having a clear title and images confirming users that they're seeing the correct item and tapped what they intended. This has worked well but it can improved.
What if we can have the main elements of the item on screen all the time and just rearrange the screen to show more information? That is exactly what the Material Design L transitions allow us to do.
Take a look at this video of a quick demo app to see how it looks in practice. The change in feeling of the app is massive. We're no longer teleporting to another screen but we're transitioning to a details screen without any confusion of what is happening.
It's worth noting that using text elements as hero views is not without problems if the text element size changes (as you can see in the video). Images are probably more suited for these transitions anyways.
The default can be overridden (as is case with most things in Android). Changing the fading effect to an explode animation is a simple one line command in the source activity:
getWindow().setExitTransition(new Explode());
This is all that is needed to change the transition to look like this:
(this video is slowed down to better show the animation effect)
In this slowed down video it becomes very clear that there are a lot of disconnected movement on the screen. The components move out and in and the hero element movement gets obfuscated.
Human eye is very good in detecting movement but if every element on the screen is moving at once our brains won't automatically lock on to the key component. I would argue that using additional layout animations will hinder the benefits of the hero element transition.
Let's look at another example. This is from a pre-release version of the awesome Android Twitter client Talon. In this version they have gone overboard with the L-transitions and created a very destructive user experience. Before we move on I want to make absolutely clear that I'm not picking on the Talon team on trying these things. This is from a pre-release version and I'm sure they will be corrected in the final release!
Every transition is now distractive and there's no purpose for using them.
Make sure that every animation and every part of your transition has a purpose. Thinks about the implications to users. Use animations to help users figure out what is going on and be aware of how human eye reacts to movement.
The explosion transitions and other similar animations might look great in a tech demo to your customer but they will become tiresome in the long run for actual users. Be aware of the flashy demo effect. You can wow your customer by showing these in a meeting but you'll be giving bad advice to them. Be considerate and emphasise meaning in transitions!
Animations with purpose can make a huge difference in your app feel to the positive direction!
Style definitions
Enable transitions in your app style file in values-v21 folder. This is the style you're using throughout your app.
<style name="AppTheme" parent="android:Theme.Material.Light">
<item name="android:windowContentTransitions">true</item>
<item name="android:windowAllowEnterTransitionOverlap">true</item>
<item name="android:windowAllowExitTransitionOverlap">true</item>
</style>
This can also be done in the Java code as explained in this SO question answer.
View names
Make sure you're using view names with your hero elements. The names must match in the source layout as well as in the target layout. You can use either the XML attribute to do that or do it in Java code:
mAvatar.setViewName("avatar");
mTextView.setViewName("title");
To launch the new activity add ActivityOptions object to the call to tell the system to run the transition.
ActivityOptions options = ActivityOptions.makeSceneTransitionAnimation(getActivity(),
Pair.create((View) mAvatar, "avatar"),
Pair.create((View) mTextView, "title"));
getActivity().startActivity(DetailsActivity.newIntent(getActivity(), this.id), options.toBundle());
Rest is handled automatically by the system!
Read more about L-animations from the Android documentation here: https://developer.android.com/preview/material/animations.html
Read more from the Google's guidelines for animations here:
http://www.google.com/design/spec/animation/
Animations can be both one of the most powerful tools in your UI design and the most destructive. A well designed animation can be both helpful and delightful. A bad animation is annoying and counter productive.
Android L release and the Material Design guidelines are adding a lot of options to designers and developers for using animations in their apps. Personally, I'm willing to bet that we're going to see an explosion of animation exploitation. As with everything new people get over excited and tend to overuse the new (and flashy) techniques. This will most likely be met by disapproval from users and the animation will be stripped out from many apps. It will take time until we'll find the right way to use these new tools.
In this article I want to take a look at one of the most important types of animations in Android apps. Activity transitions.
In Android apps activities are construct that can often be seen as screens in design. More often than not an activity is a screen in an Android app. Users navigate in the app by moving from activity to activity (from screen to screen).
Until lately now, most apps use Android default transitions between activities. The default transition is usually a sliding animation of some sort (depending on device and Android version). Here's an example of an app using default activity transition.
The back button interaction is why I have been advising against overriding the default transitions without a good reason to do so. Android's back button interaction is already difficult to grasp and changing the subtle indicators might make users hesitate.
However, there is a downside to the default transition. User is now teleporting between completely detached screens even when the screen content is clearly related. In the above example the user is pressing an apartment image to get details of the that item. There is a disconnect. That is what Google is trying to fix with the set of new tools and guidelines for developers and designers.
In future Android apps should be a continuous experience and not a disconnected sequence of jumps from one screen to another.There has been ways to make clearer connection between the content between activity boundaries already in the previous Android versions.
The Android launcher as well as the Google Now launcher already animate launched apps from the launch icon and the multitasking UI animates the selected app from the thumbnail.
All this was made possible by APIs that allowed developers to define the source view for launched activity. Some apps have been using that feature for some time already.
Let's take a look at Wally app. The app has a list of images and when user selects one of them the details activity is launched from the image.
This is still a form of teleporting between screens but the teleportation is more pleasant. User has better feel of continuum but it could still be much better.
(this video is slowed down to better show the animation effect)
Android L Activity Transitions
This is where the next level of Android activity transitions come in. The Android L release (preview) gives developers shortcuts to create extremely powerful transitions without having to spend a lot of time writing fragile and hacky code (as we had to do before when we wanted to achieve the same effect).The keyword here is continuum. These activity transitions allow us to design apps where screens are connected to each other with hero elements. By hero elements I mean elements that are central to the content and are present on both screens.
Let's look at an example.
A common case in many, many apps is that there is a list of items and tapping one of them user moves to another page for more information about that item. Traditionally we have relied on having a clear title and images confirming users that they're seeing the correct item and tapped what they intended. This has worked well but it can improved.
What if we can have the main elements of the item on screen all the time and just rearrange the screen to show more information? That is exactly what the Material Design L transitions allow us to do.
Take a look at this video of a quick demo app to see how it looks in practice. The change in feeling of the app is massive. We're no longer teleporting to another screen but we're transitioning to a details screen without any confusion of what is happening.
It's worth noting that using text elements as hero views is not without problems if the text element size changes (as you can see in the video). Images are probably more suited for these transitions anyways.
(this video is slowed down to better show the animation effect)
Activity transition layout effects
The additional tools for activity transitions are not limited just to hero elements. Google added more tools to the developers' kit. Developers can now define define how elements are removed and added to the screens. By default all components other than the hero elements fade away in the source activity and fade in in the target activity. This is what you can see in the previous video.The default can be overridden (as is case with most things in Android). Changing the fading effect to an explode animation is a simple one line command in the source activity:
getWindow().setExitTransition(new Explode());
This is all that is needed to change the transition to look like this:
In this slowed down video it becomes very clear that there are a lot of disconnected movement on the screen. The components move out and in and the hero element movement gets obfuscated.
Human eye is very good in detecting movement but if every element on the screen is moving at once our brains won't automatically lock on to the key component. I would argue that using additional layout animations will hinder the benefits of the hero element transition.
Let's look at another example. This is from a pre-release version of the awesome Android Twitter client Talon. In this version they have gone overboard with the L-transitions and created a very destructive user experience. Before we move on I want to make absolutely clear that I'm not picking on the Talon team on trying these things. This is from a pre-release version and I'm sure they will be corrected in the final release!
Every transition is now distractive and there's no purpose for using them.
Use animations for a purpose!
Like every tool when used incorrectly they can cause more harm than good. Animations are no exception. While the L-release is going to make it extremely easy for us to create all sort of animations, transitions etc I'd advise all of us to use caution when deciding to use them.Make sure that every animation and every part of your transition has a purpose. Thinks about the implications to users. Use animations to help users figure out what is going on and be aware of how human eye reacts to movement.
The explosion transitions and other similar animations might look great in a tech demo to your customer but they will become tiresome in the long run for actual users. Be aware of the flashy demo effect. You can wow your customer by showing these in a meeting but you'll be giving bad advice to them. Be considerate and emphasise meaning in transitions!
Animations with purpose can make a huge difference in your app feel to the positive direction!
Technical implementation for hero elements
I don't usually write much about technical implementation in this blog but I'm making an exception this time as the official documentation is still fairly poor (will probably be better at the time of L-release). Here are few implementation tips to get similar transition working on your L-preview apps.Style definitions
Enable transitions in your app style file in values-v21 folder. This is the style you're using throughout your app.
<style name="AppTheme" parent="android:Theme.Material.Light">
<item name="android:windowContentTransitions">true</item>
<item name="android:windowAllowEnterTransitionOverlap">true</item>
<item name="android:windowAllowExitTransitionOverlap">true</item>
</style>
This can also be done in the Java code as explained in this SO question answer.
View names
Make sure you're using view names with your hero elements. The names must match in the source layout as well as in the target layout. You can use either the XML attribute to do that or do it in Java code:
mAvatar.setViewName("avatar");
mTextView.setViewName("title");
To launch the new activity add ActivityOptions object to the call to tell the system to run the transition.
ActivityOptions options = ActivityOptions.makeSceneTransitionAnimation(getActivity(),
Pair.create((View) mAvatar, "avatar"),
Pair.create((View) mTextView, "title"));
getActivity().startActivity(DetailsActivity.newIntent(getActivity(), this.id), options.toBundle());
Rest is handled automatically by the system!
Read more about L-animations from the Android documentation here: https://developer.android.com/preview/material/animations.html
Additional resources for animations
- Google Material Design animation guidelines
- Video: Google I/O 2014 - Material design: Motion
- Video: Google I/O 2014 - Material design principles
- Taylor Ling's UI ANIMATION IN PHOTOSHOP – TUTORIAL #1
- Sketch App wireframe templates by Vincent Tantardini
No comments:
Post a Comment