Friday, 10 October 2014

Navigation Drawer - Where Does it Belong in the View Hierarchy?

It used to be so simple.

http://developer.android.com/design/patterns/navigation-drawer.html

But things change. Sometimes you have to break the old to create new. When the Navigation Drawer pattern became a part of the Google's design guideline for Android it was clearly defined and the implementation was available of devs to use.

But did Google make a mistake in the initial definition? It might have seemed correct at first but there was a mistake in the spec.

Things are now changing. New updates from Google have moved things around. The new Material Design guidelines define the navigation drawer (now called Side Nav) on top of everything in the app UI.

http://www.google.com/design/spec/layout/structure.html#structure-side-nav-1

We're now in middle of a transition again. Google is changing their apps and while the process is ongoing there's a lot of variation in the released apps. I would really love to see Google to unify the way they use the drawer to send a clear message to app developers.


But what does it matter where it is rendered? It still just works!

I think it matters a lot. This is something that tells the user what they're controlling. If the drawer is the main navigation of an app it becomes one of the most important controls to get right.

View hierarchy tells user which parts he or she is manipulating when they press an item in the navigation.

This is what the previous drawer hierarchy looks like and this is what the recent update to Photos app also did. In my opinion there's two things that are wrong with this approach.

Firstly, this implies that the action bar will not change if I navigate to any of the entries... but it does.

Secondly,  the action bar actions are still active when the drawer is open but they affect the content that is currently hidden behind the drawer.

Confusing.


In the latest Google Hangouts app the drawer renders on the same level as the tabs. This tells the user that when I navigate to another item from the drawer the tabs will stay in place. That's not what's happening here though. I think this implementation is wrong and should be corrected.

The latest update to Google Newsstand adheres most closely to the Material Design guidelines from any of the Google apps.

I think this implementation is great and the correct one. When I navigate the whole content changes, including the action bar. This corresponds most closely to reality.


Making the drawer the highest level component also allows us to avoid unpleasant visual issues with action bars that move away when scrolling not unlike what is happening in the latest Google Play update.











Ok, things are changing and Google still haven't really worked out everything internally for the next iteration. I'm hoping that a consistency is found soon and we can move on. Until then we have to be mindful of our implementations.

Changing familiar things is never easy. I polled the public opinion about this change on Google+ to see what the opinion in general is right now. Change will take time.


https://plus.google.com/u/0/+JuhaniLehtim%C3%A4ki/posts/Xms3aQ6LweU

Friday, 5 September 2014

Material Design - Activity Transition Animations

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.
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:

(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.

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


Monday, 18 August 2014

Read This: Designer's Guide to DPI


Sebastien Gabriel from Google's UX team has written a comprehensive article about designing for different screen densities.

This article is worth reading if you're a designer and worth sharing to your designers if you're a developer. This post will help designers (even without Android understanding) to understand how to create assets supporting different screen densities.

Read the full article here:
http://sebastien-gabriel.com/designers-guide-to-dpi/home

Monday, 11 August 2014

Read this: androiduiux.com - Crafting the Unclouded Experience

Taylor Ling has written yet another post that is absolutely worth your time. In the latest post Taylor describes the process behind crafting the user experience for the Unclouded app.


Read the full post here:
http://androiduiux.com/2014/08/12/crafting-the-unclouded-experience/

Revisiting Yahoo! Apps


Yahoo! have been busy building Android apps some of which are among the most beautiful apps on the platform. When the first of the new generation apps, Yahoo Weather, launched there was controversy about some of the UX decisions made in the otherwise gorgeous apps. I wrote about them here and even Matias Duarte chimed in to the discussion.

A lot has changed since the initial launch in the Weather app and we've also seen some new apps that are worth noting. So, I wanted to revisit the Weather app and take a look at another Yahoo app while we're at it.

Now, before we continue I want to add a disclaimer here. These apps are great. I'd rate all of them with either 4 or 5 stars on Google Play. That doesn't mean that there's nothing to improve with them. These apps provide us an opportunity to critically evaluate apps that function very well and supporting the user in their goals (unlike some other apps out there) as well as look great for most parts.

Hence, a fair warning, there will be some nitpicking ahead. Again!

Yahoo Weather


Google Play Link

I heavily criticised Yahoo Weather for breaking some of the core Android design guidelines. The two core problems I had with the app was the implementation of the navigation drawer and use of iOS icons in the app.

I'm happy to say that both of the big issues have been fixed. The navigation drawer now slides on top of the content indicating its correct place in the information hierarchy. The iOS icons from the drawer are also now gone and replaced with Android's icons where applicable.


The navigation drawer still has some issues but none of them are deal breaking anymore. The app now behaves and looks like an Android user would expect. I would still like to see the other Yahoo app links removed from the drawer but I bet that is a business driven decision that can really be influenced.

Other point I'd like to raise is some of the links under the Tools category. Navigation drawer is intended for app navigation and 3 out of the 4 items under tools are actions instead of navigation. However, this is a really minor point on my book and as there's no obvious solution to where to position these actions there's not much we can criticise here.


There's also few minor issues that are no longer an issue although Yahoo hasn't really fixed them in their app:

The app still hides the status bar. New Android versions now allow users to swipe down and bring the status bar back to visible whenever they want so at least on those Android versions this is not an issue anymore.

Another one was the non-standard navigation drawer icon. It looks like Google is moving towards this type of icons in their new design style so this one isn't an issue anymore either.

Information Hierarchy

The app doesn't use Action Bar at all (which is perfectly fine, don't need a pattern - don't use it). But doing so there's some unexpected implications that might seem to be very small but which I'd consider problems worth attending to.

User can move between different cities by swiping. The transition is beautifully crafted and using it is an absolute delight. But there's a problem. The navigation drawer icon as well as the plus icon move together with the city screen.

What's the problem with this, I hear you say. - Let me explain.

We, as humans, are very good at classifying information in a hierarchical way. We can keep large sets of information in our memory as long as we understand how these pieces relate to each others. When using any app users are building a mental model of the app's information.

In this case these two icons are physically attached to the city (they move with it). The implication to user is that these two buttons are part of that screen and therefore act on the information on that screen. This is not what the buttons do. The navigation menu is naturally higher level than an individual screen as well as the "add new city" button.

I doubt that this really causes serious usability issues in this very simple app but I still think it would be worth fixing. It is worth trying to encourage users to form the correct mental model of your app whenever possible!


Scalability

For some reason both of the apps we're looking at today are locked to portrait. The apps also do not scale up nicely to larger screens.

Portrait locking is a real issue especially on larger devices. I don't really understand why this was done.
The app works fine on larger screen devices (as long as you hold them portrait). But it doesn't really scale, it just stretches.

On the app's main screen this isn't a big issue as the image is the main component ant showing an image full screen is always a nice way to ensure optimal use of any screen real estate.



When you scroll down the issue becomes more serious. The app is still gorgeous on larger screens but it wastes a lot of space. All components are significantly stretched and the information density becomes very small.


I believe this is a result of Photoshop-driven-design (based purely on a guess, I have no actual information about Yahoo's design processes). Scalability and screen sizes were probably not discussed when this app was designed.

As I said above, the app does work on larger screens but it could be a lot better! This issue is something that prevents me from recommending this app as one of the best designed apps on Android. The app certainly is one of the most beautiful apps out there but Android apps have to be scalable! If the scalability is solved the portrait locking could simply be removed as well.

Yahoo News Digest


Google Play link

Yahoo News Digest is the second of the new Yahoo apps that gained reasonable amount of attention when it launched and for a good reason. It is beautiful and highly functional. It also has laser focus on providing the right information to the users.

 

Delightful Details and Polish

Not only is the app beautiful and comfortable to use but it also delights users with small details like the read article indicator which doesn't really add huge value to the users but creates an interesting game-like aspect to reading news articles.

The level of polish is very apparent throughout the app. Even the error screen is nicely designed.

Reinventing the Wheel, the Right Way

In many of my previous posts I have complained about app developers trying to reinvent the wheel, ie. replacing standard components with fully custom ones. This app does the same. It replaces the standard Android sharing dialog as well as uses a fully custom settings screen. In this case the result justifies the approach.

The app still uses Android's intents to share news articles but the UI has been replaced with a pop-up that perfectly matches the app's style. It also gives a bit more information to the user compared to the default Android share dialog.

One interesting thing to note on the sharing dialog is the way Yahoo promotes it's own services in the share dialog. I don't have either the Yahoo Mail or Tumblr installed on my phone. Selecting these options will direct me to the Play Store to download the corresponding app. I find this to be a nice and innovative approach to marketing.

I'm also fan of the settings screen. It's clean implementation and style matching the rest of the app justifies ditching the default components. It even comes with a hidden easter egg (tap the color circles on top to start a mini game).

I want to reiterate my point here. Use the default Android components unless you have a good reason not to. In this case there's a good reason for both. The sharing dialog has added functionality (and marketing) and the settings screens matches the app's style much better than the stock settings display would. 

Scalability
Scaling to larger screens seems to be a big issue in Yahoo's apps. This app is locked to portrait and also simply stretches on larger screens.

The way the top icons stretch on larger screens is especially striking. The large stretched icons feel really out of place on a Nexus 7 screen. Our fingers don't change size when we use larger devices so neither should the touch controls.


As with the weather app the content stretches on larger screens instead of utilising the added screen real estate fully. Take a look how the same screen looks like on a 7" screen and on a 5" screen.
The content is beautifully laid out on both cases but the 7" experience is far from perfect. On larger screens this app could, for example, pull some of the rich graphical components of the news stories to the list page to make it more lively. The content and the design is so rich that there's certainly many things that the app could use the additional space for.

Summary

Yahoo has stepped up as one of the top developers on Google Play. New apps they create are beautiful and extremely useful. The two apps I mentioned in this post are gorgeous but both of them suffer from lack of good scalability to larger screens.

The Weather app has gotten rid of the gaping issues it had on the launch and now feels very much like an Android app. Therefore we're now focusing on much finer details than before. Yahoo now has a possibility to truly push the boundaries of Android design. Their apps are already great and even delightful. I'm expecting to see great things coming from the Yahoo's Android team in the future!

Tuesday, 5 August 2014

Watch This: Material design in the 2014 Google I/O app

Material design is something that I have not had time to write about yet (but believe when I say that I will!).

Fortunately there's no shortage of others talking about it. Today, Google's Android Developers blog released a great post about the process they used to build the Google IO app for this year's conference.

As the IO app is available as open source it is probably the best example to look at (we can find out how everything is implemented). Take a look at the YouTube video by Roman Nurik as well as the actual article explaining their design decisions.

On Importance of Supporting User Goals, an Example

If you have seen any of my conference presentations you are aware that I keep raving about understanding and supporting user goals in your app design. Supporting users on what they actually want to get done is more important than visual design or even following design guidelines. By that I mean that no matter how great visual polish the app has or great design pattern it uses the app will fail if it doesn't help users achieve their goals.


When designing an app you rely on previous layers and build on top of them. The bottom layer that everything is based is the understanding of users and what they actually want to do with your app. Without this everything else will crumble.

Failing in User Goal support

I've been using an app that completely fails to understand very some basic user goals and I wanted to use it as a negative example of what kind of problems can be caused to your design when the design is feature focused instead of user goal focused. Later in this post I'll look into other issues in the app but they're not nearly as important to understand as the very first ones.

The app I'm going to be focusing is called Watchever. It is a German equivalent to the Netflix streaming service. It allows subscribers to stream any movies and series from their selection without additional cost.

Unfortunately, the app is disastrous. Not only is it buggy, ugly and fails with pretty much all Android guidelines but it is also built (at least partially) from very feature driven point of view. Let me explain.

The app's landing screen / home screen is divided into sections. The sections make various amount of sense but let's take a look at one of them. The third section after a featured graphic and "My Bookmarks" is "Already Watched".

A fair question arises when looking at this. Why is this here? What user goals this supports?

You can probably think of some that could be reasonable and even high enough priority to justify this section on the front page:
  • I started to watch a movie but didn't complete it. Now I want to continue where I left it.
  • I've been watching this series and I want to watch the next episode of it.
Unfortunately the app developers have not really been thinking about these user goals, or at least have not thought them through. The actual reason for this section being here is a mystery to me.

Here is why the section design is unlikely result of any real user goals but instead a feature added without further thinking:

The app does not show only movies I've not completed. It shows everything I've actually watched. There's also no way for me to know if I've completed the movie, when I did it and how many times I've watched the movie. All of which are important personal information the app should know and show me to support me in my decision making. The movie detail page is empty of any my personal information (other than my rating).


But what about the series use case?

I'm afraid the app doesn't fare any better with it. When opening a series page there's no information about any of my watching history. I have no idea which episode was the last one I watched. A small consolation is that if I hit the "Play" button the app will actually continue from where I left off in this season of the series. But why isn't this information visible to me? Series are also divided into individual seasons so you have to remember which season you were on or you'll not be able to continue from where you left.

Unfortunately, these are not the only places where the app fails to deliver the content in the right way to the user. It is littered with designs that were not well thought or incomplete. To me it looks like the team lacked the right processes to create end-user facing UI.

Issues like these create frustrating user experience. Users either have to remember things the app could remember for them or force users to find usage patterns that are out of the ordinary and unnecessarily complex.
Remember: your app should not contain a single feature that is not derived from a user goal! Every single component, screen and animation should help users to reach the goal they want to achieve with your app!

Android design guideline failures

This app requires some serious rethinking to fix its UI. It is also littered with issues of lower level UI design mistakes and some Android-specific problems.

Tabs do not work this way

The way the app uses tabs (its core navigation) is just plain wrong. This might be due to the heavy influence of iOS in the app design but that's a poor excuse.

Tabs should be used on navigation on the top level. When diving into detail pages the tab bar should not be there anymore. Keep your app's navigation simple and one directional. Separating detail pages from main pages will help your users understand your app's content hierarchy. 

Nitpicking

I've been accused of nitpicking a lot in the past. In fact, so much so, that I've decided to give a talk about why detail matter in UX in the upcoming Droidcon UK. These are things that force unnecessary cognitive load to users or force them to stop to think where no thinking would not be required.

Mixed terminology

The app's main audience is German so it might very well be that the English translation is not given as high priority as the German counterpart but mixing terminology when it comes action and action labels is a very bad practice.

Is it an offline-mode or travel mode?

In fact, there's no difference. They should be called the same. The difference in labeling forces users to pause and think "what's the difference". It doesn't seem like much and users will likely understand it but why add this burden to them? Let them concentrate to the actual task in hand.

The actual app content naming is also inconsistent. The same episode of the same series have (at least) two different formats for naming. While most users will most likely understand that these labels refer to the same episode why do this? Make sure you refer with the same label to the same content everywhere in your app.

Ha! Gotya!

One of my pet peeves is actions offered to users that are not actually available. The app allows users to download content for offline viewing (travel mode). There's a limit of two concurrent downloads. While the limit itself is fine it should be indicated better.

If I already have two downloads in progress and try to start third I get a pop-up on my download pop-up (ugh!).

This one would be very easy to fix. Just make sure that the download buttons are disabled when user cannot add new videos to the download process or even better, keep the rest of the videos marked for download in local queue and start the download automatically once the server allows it. That's what user indicates that he or she wants (user goals again!).


Search, I don't even..

The action bar search in this app is something that really baffles me. The app's fake Action Bar has a search button. Tapping it brings up Android's contextual Action Bar and search. It works pretty nicely but exiting the search isn't that simple. Pressing back to dismiss the keyboard and then the search will bring you to another search view and pops up the keyboard again. This time you're in the fake Action Bar search.

How did this got through to the release?



Moving responsibility to users

The app's travel mode could be one of the features that push competitive advantage to them over many competitors. Many of the competing services do not allow me to watch movies on the plane or elsewhere without internet connection.

Unfortunately, the implementation in this case falls flat. For some reason the app moves responsibility of moving between offline and online modes to the user. Users have to manually trigger switching the modes.

When switching to the travels mode the user is even greeted with two consecutive pop-ups. I hate pop-ups!




I can't wrap my head around why this is done the way it is. Android platform provides developers tools to detect internet connection availability and the app can react to this automatically.

A great example of handing the very same use case is Google Music. Simply use the same interface offline and online but indicate the users what is available to them (and allow users to filter the views). Even better would be to adopt the pinning pattern used throughout Google apps to allow users to download content offline.


Summary

The Watchever app gives us an example of an app that will require a lot of work to fix. It is barely usable in its current form and the company is sure to lose a lot of its customers to any emerging competition.

Fixing the app would require foundation work and better understanding of users and user goals. Fixing smaller issues in the app would likely result into marginally better user experience while still failing to create acceptable app.

Often, when I review apps on this blog minor fixes could elevate the apps to decent standards but this app is demonstrating the dangers of not building proper foundations. Understand your users' goals before you start building your app features! Think how your users will use your app. Support them in their goals and make sure your understanding has been correct (usability testing on prototypes).


In my case the unusable Android app lead to this (account terminated):


It doesn't look like other users are happy either: