Sunday, 16 November 2014

The State of Android Hardware Companion Apps

 - Doing Android wrong makes me distrust your product's future.

Time after time I keep running to this same issue: hardware companies don't get Android. Companies building expensive products are either completely failing in their mobile app strategy across the board or put all their efforts to their iOS app effectively making their Android apps an afterthought.

But what does it matter as long as it works (on some level)?
Trust. It's all about trust.

I simply don't trust companies who don't seem to care about Android users. I've been burned too many times before. And I don't think I'm the only one.

Because of past bad experiences my shopping decision now includes looking up the Android app of the product I'm considering purchasing and seeing if it looks like an Android app and if it seems to be built the right way (scalable, uses notifications correctly, etc basic Android platform knowledge).

If I see things like use of the menu-button-of-shame, strange notification use, use of iOS UI components or UI structure etc. I know that the company is not regarding Android as a first class citizen in their own ecosystem.

When the platform I'm using is clearly at the end of the priority queue of the company whose products I'm considering buying it tells me few things based on my past experience. The UX of the mobile app is likely to be subpar. I'm likely going to get a feature limited version of the software and all new and improved features are going to arrive to me much later than if I was using iOS. Still... I'm paying the same price for the hardware product.

I simply do not trust that the device is worth the money if the company doesn't think that it's worth their time to look into the most used mobile platform of the world.

No thank you!

Cross-platform disasters

Some companies building high-end (or at least expensive) products like BOSE seem to be completely failing to understand the importance of creating mobile user experiences. With their SoundTouch Controller (iOS) product they seem to have gone the route of ignoring all platforms and build an app with some cross-platform tool and the results are as expected.

There's no way I'll put my money into your product if you don't understand how to build mobile apps. It might be that use of the mobile app is just a secondary way of controlling the system and "an additional feature" but if this is the quality of your product I doubt I'll enjoy the rest of it either!




iOS-first (only?) approach

Now, this might be justified on some level but there's limits. Making hardware that talks to mobile devices is difficult. Bluetooth as a technology sucks big time but that's unfortunately what we have to use (at least for now). It probably makes sense for companies to pick the largest segment of their market to target first when building software to their hardware which is relatively standards and least fragmented.

After the start I'd expect to see the Android support added relatively quickly. It's a massive market. Let's say that you decide to target just couple of the top-end Android phones in the first iteration you will likely target a very similarly sized audience. While you might encounter some issue with some devices you can start ironing out the issues one-by-one.

But seeing something like this in an online store of bleeding edge hardware maker a year after the device release causes problems. As customer shopping in the Runtastic store this makes me pause. I will think twice buying any of the hardware that is compatible with Android as I'm not sure where my platform fits in their corporate strategy?


In case of Runtastic this becomes even worse. With Runtastic I'm not only buying their hardware to use. I'm also buying into their ecosystem. I'll be uploading my info to their systems, using their exercise apps and so on. If I subscribe to their ecosystem will I be treated on the same level as people using iOS devices?

Direct iOS ports

Then there's something that I don't understand at all. This should never be done by anyone. A company that takes time to make their hardware compatible with Android but for some unfathomable reason decides to port their iOS app directly to Android without looking into Android platform guidelines, UX etc. I cannot understand how this still happens in 2014.

Building Android apps right way is much easier than trying to make your apps look and function like iOS apps. Still. Some companies insisting doing this in the way we in Finland call "climbing a tree ass first" ("perse edellä puuhun).

Parrot's Flower Power is an interesting product that monitors how your flowers are doing. But what they've done with their Android app is beyond belief. It is a 1-to-1 direct port of their iOS app. From the minute you open the app on your Android device you feel like it is not built for you.

The app uses iOS bottom tabs which immediately make the app navigation not functional when combined with the Android back button. It's also style-wise mostly just confusing to all Android users. Tabs in screens don't work as expected (where's my swipe gesture), the whole font throughout the app is strange, it's full of custom controls that don't belong to the platform and they've even implemented features that you really don't need to implement on Android as the platform gives them to you for free. And top of everything the app is, of course, locked into one orientation (a sure tell that the design is not flexible).

I simply cannot understand what made them to do this? Are there no Android users in the company management? Is there no designers using Android at all in the company? This app is very confusing, ugly and doesn't belong on Android. There's no way I will buy hardware that is supported this poorly on my platform.


iOS-only marketing

Another thing with hardware manufacturers that I fail to understand is the lack of Android presence on their websites. Maybe the most striking example of this is Parrot Zik 2.0 website. Take a look at the site. Would you imagine that you could use the headphones with Android as well? On the surface no. Every single image on the site is an iPhone running their software. There's even sentences like "They are made for iPhone, iPod, iPad.".


These things are not cheap. The Zik 2.0 costs almost $400 in Amazon.com by the time of writing this.


Scanning the Parrot website for compatibility there's, in fact, exactly one mention of "Android" and it is this: "Free app compatible with smartphones running on iOS, Android".

Anyone wanna take a guess how good their Android app is?

This $400 headset comes with a companion app that looks like absolute crap. It's, of course, exact clone of the iOS app but in this case it's bad on both platforms.

The app is locked on in portrait on phones and to landscape on tablets. It also fails in some very basic UI design things like using margins and alignment. It also has reinvented all the controls.

The best of all it has a menu-button-of-shame. This is such a direct proof that this app was built without any knowledge of the Android platform.


The app also immediately adds a persistent notification to your status bar when you open it. The notification content simply baffles me. And maybe not a big surprise that the notification's priority is set incorrectly so it's always fully visible.


There's a lot more I could point out in the app as issues but I think I've made my point. Do I want to pay $400 for headphones if this is the quality I can expect? Hell no!

Crowdfunding projects

Kickstarter and indiegogo are both full of tech projects looking for funding. More often than not you see these small startups fighting for funding completely fail to understand that platform differences matter. You see pitches in Kickstarter that claim support for iOS and Android but they only show iOS devices in their campaign page (or even worse, some strange abominations like below).


As Android community, we're already getting burned very often by large manufacturers and it's making us careful. When you choose to show only iOS devices on your campaign page it tells us that if I back your project I'll likely have to wait for features iOS users will get earlier. Personally, I'm not backing projects like that anymore.

Self-fulfilling prophecy

Android users don't spend money. iOS users are where the money is. - You've probably heard this statement before. If this is true you can hardly blame the manufacturers for putting their efforts into iOS and then doing something half-arsed to tick the box for having an Android app later if they get around to it.

I would not be surprised if this attitude in the industry was the cause for Android users not spending the money to these products. It's quite natural. If you show that you don't care about my UX I'm not going to give my money to you.

If you think that Android users would not buy your products maybe the fault lies with you and not with Android users? Are you creating products worth buying? Can you really afford to ignore 80% of the potential market?

Conclusion, TL;DR

This post turned out to be a bit more whiny than I intended it to be but I think the point becomes clear. While in many areas Android has finally became a first class platform in hardware companion apps there's a lot of space for improvement.

While there are hardware manufacturers who are already pushing quality of their mobile software they're more of an exception than a rule. I see this as a lot of unused potential. A manufacturer doing their Android apps right can differentiate positively from the crowd. Any takers?

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.