Android UI Patterns

Android UI Patterns blog is moving

2017-09-14T07:53:00.001-07:00

..to Medium.

Hey everyone! Just a quick post here informing that I will be moving the Android UI Patterns to the Medium platform.

You can already find the new blog here: https://medium.com/android-ui-patterns including two new posts that I've done in the last couple of weeks!

It feels like it's time to let Blogger go as the platform. Google has long neglected Blogger and while technically still working I'd not be surprised if the upcoming spring cleaning will take this away.

Blogger is also visually fairly poor and running a UI blog that looks like this might not be the best thing to do..

So. In the coming weeks I will be pointing the www.androiduipatterns.com domain to the Medium publication. However, any RSS subscriptions are likely to stop working. You can start following the publication or me on Medium in the meanwhile so all the content will still be delivered to you :-)

Juhani

Couple of Great Apps for Designers

2017-01-16T06:35:00.000-08:00

I wanted to give a quick shout out to two Android apps that designers and app UI developers might find very useful in their work.

https://play.google.com/store/apps/details?id=com.scheffsblend.designertools

Designer Tools package multiple helpful features into one app. You can can use a grid overlay to check your component alignment, you can overlay your screen with a semi-transparent mock overlay to see how your implementation matches the design and you can use a colour picker to extract the colour value of any pixel on your screen to confirm that the colours are set correctly. Additionally you can enable a screenshots details mode which will automatically augment your screenshots with device details. This will become very useful when reporting issues to developers!

This app is also Open Source and the dev team is actively looking for feedback and thoughts. Check out the code from GitHub or give feedback, report problems or suggest improvements.

https://play.google.com/store/apps/details?id=com.faizmalkani.keylines

Faiz's Keyline Pushing app is, as far as I know, the first app that brought us the keyline overlay easily. While this app doesn't have the rest of the features of the Designer Tools app discussed above this app provides much finer controls for keylines.

Personally, I'd love to see Keyline Pushing app's finer grid control implemented also in the Designer Tools app. Faiz, maybe joining forces with the Designer Tools team would make sense? ;-)

Huge thanks to both of the app teams! Android developer and designer community is amazing. Many of us spend our free time to make everyone's work easier.

Android as a Prototyping Platform - a Case Study

2016-02-22T10:16:00.000-08:00

I've not been writing much lately here. The reason is twofold:
1) Android has gotten much better lately and there's much less to complain about. Companies are starting to understand the value of understanding Android design and doing it right. Well.. mostly.. What's up with the new G+ app??
2) And this is the big one. I've been working to turn my long time passion hobby project into a real product. Me and my friends have been working on a new type of hybrid miniature game called Lands of Ruin which combines two of my passions. Android and miniature gaming!

We're currently running a Kickstarter campaign for the Lands of Ruin project. Check out the campaign here:
https://www.kickstarter.com/projects/landsofruin/lands-of-ruin-hybrid-tabletop-gaming-as-it-should

Anyways, this post is not just a marketing blurb about our Kickstarter (although all support and sharing is much appreciated!).

During the last 3+ years I've been building the digital part of Lands of Ruin as an Android app prototype. It turns out that Android is an amazing platform for rapid prototyping simply by using native code!

Background - Process

Before I jump into explaining how we did what we did let me first explain what it is that we're doing.

Lands of Ruin is a tabletop miniature game with a companion tablet app (is that the geekiest thing you've ever heard or what?). It is also something that has not been done before. While there's been couple of hybrid gaming attempts they have been very different nature. In short, what we wanted to is to create a smooth interaction between the physical game and the digital world. How do you do something like that? We had no prior examples we can pull from or ideas to copy. We had to create the interaction from scratch.

Step 1 - Paper

Like on any great design project everything always starts with pen & paper. Pen and paper is an invaluable tool for rapid prototyping. You get an understanding what is needed without having to write any code. And best of all you can do it together with others. Two heads is better than the sum of its parts!

In our case the earliest paper prototypes didn't even try to represent tablet UI. Instead with the pen and paper combination we explored what needed to be tracked and what needed to be automated. Even talking about user interfaces at this point would have been way too early. First, we had to figure out "what" before we could start talking about the "how".

Unfortunately, I don't have any of the early paper experiments left so I could show you. But in short they mostly reminded spreadsheets on paper.

Regular iterations

Very quickly at the beginning of the project we understood that we had to iterate a lot. We had to establish a working routine that worked for an after-work-hobby project. To us the solution was to set a certain night of the week aside for play testing. We decided on Thursday nights and that became the routine for the next 3 years. Every Thursday we played a game with the current prototype and after the game we discussed ideas of improvements and what to do next. Then we set the goals for the next Thursday and separated. We worked through the week to achieve the set goal as well as had brainstorming sessions (usually in a bar) to solve problems we ran into during the week. That has worked really well!

Not-so-coincidentally we still play every Thursday. Nowadays the game night is usually for guests who come to play the game into our office and enjoy a beer or two. The improvement interactions are still there though. Problems found during these game sessions are noted and hopefully fixed before the next Thursday.

Step 2 - Functional "What" Prototype - or Proof of Concept

After the initial paper phase I wrote the very first Lands of Ruin companion app. At this point very little thought was spent on the UI and how it should function. The first prototype was still for understanding what the app needed to do.

When building something completely new there's one question that is worth answering:

"why hasn't anyone done this before?"

There's approximately three answers to the question:

It's a stupid idea and not worth doing.
Nobody thought about it.
The technology hasn't been there to do it before.

If you think the answer is #2 you're probably deceiving yourself. There's a lot of people on this planet. A lot of smart people, many of them smarter than you or me.

To answer the question we decided that we need a proof of concept. That's where the coding started and the result was this:

Now, the result was far from good UI or intuitive experience but that was never the aim of this prototype. This prototype allowed us to actually play the game for the first time. The limited ruleset and functionality of the app was well defined enough that it allowed us to elaborate how the complete product would feel.

Another important step with this prototype was that we were able to get others to play the game. Naturally, the very first play testers needed a lot of help navigating the app and game itself but the experience was invaluable. We were able to get an understanding of the strength of the concept and decided to move ahead.

I spend around two weeks evenings coding this app. The UI was bare minimum but the core there. Game characters existed, actions were available to be performed and the players' tablets talked to each other over WiFi.

Step 3 - Quick Prototype

Once we had a good enough understanding what we wanted to build it was worth starting to think how to build it. It was finally time to start thinking about the real UI. We had probably around 15 test games under our belts.

There were still many parts we didn't understand about the interaction. Especially tricky part was the connection of digital world and the tabletop. Our game design required that the app knew approximately where the characters were on the battlefield.

We needed more information. The proof of concept prototype didn't provide us any way to test the most difficult design ideas. It was time to spend more time on the app.

This was the first time we sat down and drew what we wanted on paper. After quick pen & paper iteration it was time to open up Omnigraffle and draw something more concrete.

At this point it was no longer feasible to play the game with the paper prototype. The Omnigraffle wireframes were discussed in the team and the decision was that it was worth trying.

The result was this:

The app was still far from intuitive or beautiful but it had all the functionality the game required in graphical form. The game map was there and it worked. This was the very first time the game was played in the way we intended. We were now 6 months into the project.

Problems

Now that we had more fidelity in our prototype we started finally understand problems we had. While the solutions were still far away the first step was understanding the problem's cause.

At this point it became painfully clear that handing the characters wasn't easy or pleasant... and if an interaction in a game is not pleasant it's not really a good game at all.

We started iterating over the design. Not visually - but functionally. We wanted to find enough space on the small 7" screen to have all the components easily accessible. We added sliding drawers for more details and view pagers for easier access to the characters.

Here's one of the iterations:

And the next iteration:

And the next one:

We kept moving things around, changing sizes, rearranging them. Each step felt like we were closer to the goal. More and more playtesters came by to play the game and the feedback felt better after each game.

Fragments are awesome

At this point I want to point out one thing. Unlike you might have heard Android fragments are awesome and very powerful for prototyping.

Our game UI is completely native Android code still today. As an android developer that's what I know the best and that's the environment I get the best result fastest. Each part of the UI you see in the screenshots is an independent fragment. In the screenshot above there are 5-7 fragments visible at the time. Each fragment knows what they need to show and are subscribed to changes in the central game state. None of the fragments talk directly to each other. All communication is decoupled using an event bus approach.

This architecture allowed us to iterate extremely fast. The fragment showing a charter always knows how to display that character in the current gamestate no matter where it is located or what other fragments are visible.

This decoupling and event bus architecture allowed me completely change one part of the UI from one prototype to another without having to worry about breaking anything else as well as completely rearrange the UI and the game would remain playable from one build to another.

Step 4 - Design

We had finally enough test games and data that we wanted to take the next step. The current prototype was simply too ugly to show anywhere public. At the same time we saw an opportunity to go to a local maker event, Make Munich, to show the game to the public.

This was the kick we needed. We decided that the Make Munich event will be our launch event and we would put the app into the Google Play Store for closed beta and hopefully get more people outside our team to try the game. Bring in the Photoshop and visual design.

Rick, the artist in the LoR team, got the challenge to do our visual design. The resulting UI is here:

With this UI we proudly went to the Make Munich event and issued a press release telling about the release of the game. This was in the April of 2014.

Step 5 - Reality strikes back

After the Make Munich event we evaluated the response we got from the audience and from other play testers. There was no going around the fact that the game wasn't very good. There were several complex rule mechanisms that made the interaction difficult. The app UI was too clunky in many use cases forcing the players to focus too much on the tablet instead of the tabletop and the opponent.

As one of our design principles was that the game MUST feel like a tabletop miniature game and the focus of the players should be on the miniatures, terrain and tabletop this was a clear state of failure.

We had failed on our design goals. What next?

Well. Back to the drawing board! It was still clear to us that the concept was viable but our implementation was bad. Something had to be done!

Even though we spent a lot of time on both asset production and design as well as on development we simply had to let go and scrap the current app version. It wasn't what we set to create.

Step 6 - Try something completely different

The big problem in the design was that the characters were difficult to access.

We had couple of beers and brainstormed what could be done. An idea about drawers popped up and we decided to give it a try.

A complete reshuffle of the game UI ended up looking like this:

While the UI looks completely different the power of Android fragments actually allowed me to create this configuration in one evening. All the functional components were still same as before but where they were was different. Due to the fragment architecture and event bus approach no other changes was needed. The game was playable again the next day.

Unfortunately this wasn't good either and we ended up abandoning this approach very quickly.

Step 7 - Cards before cards were cool

The UI just didn't work. The game concept was kept back by the app. We didn't want to make more noise about our game as we weren't happy about the way it felt. It felt wrong. A radical new approach was needed. simple rearranging of component wasn't enough anymore.

Cards! A lot of tabletop games use cards to represent characters. Maybe a familiar concept would make more sense. There's also many games that handle digital cards. We can find the games we like and see how good interaction is done.

The first prototype with cards in non-functional state looked like this:

While we were in unplayable state at this time the concept felt promising. It felt like this could actually solve the issues we were having. It was worth putting the extra time in to see how this works as a game.

It worked! We were onto something. Week or two later when the game was in playable state we felt that things are finally starting to feel the way we wanted it to feel.

Step 8 - Making things look polished

We couldn't go back to releasing an app that looked like it was a complete prototype so after quick iterations with the card concept we decided to do proper design for visuals as well. Rick was forced into asset production mode again.

The first results were:

Finally! The app started to feel like it's close to what we wanted. In test games the difference was MASSIVE. The tablet has finally become secondary on the gameplay.. it has became an extension of the tabletop game we had. This was exactly what we set out to create!

This wasn't to say that the app was perfect but we were finally, after 3 years of development, getting there. This approach was worth polishing.

In the next iterations we changed the card orientation to better for the vertical stack we used and started providing more information to the players at the right time.

Here's what we had:

Step 9 - Getting ready to launch

The app now had all the core features of our basic gameplay. We also have a good understanding how to build the advanced features we've been promising on top of this solid core. However, the visuals in the app weren't satisfactory. Rick, who had done the assets until now, had his hands full on other tasks related to our impending Kickstarter and event demos.

We reached out to get support from abroad. We hired my girlfriend's sister Natalia Kovalchuk to get the game design up to par and in shape to be displayed in events and in Kickstarter.

Here is the result of this design iteration:

Step 10 - Kickstarter

And here we are. More than 3 years after the initial idea we are trying to get the game into public's attention. We're currently running a kickstarter campaign trying to fund creating the physical component of tabletop miniature gaming.. the miniatures.

Check out our Kickstarter promo video as well:

https://www.youtube.com/watch?v=tNL1_Oa7ONQ

You can see the app in action in the video.

I would really appreciate if you'd also considered backing our Kickstarter campaign. Even if you're not a gamer dropping a £1 is actually very useful as Kickstarter likes to promote campaigns with higher backer numbers. But why not to get into tabletop gaming with Lands of Ruin? It's never been this easy!

I much appreciate your support!

Please share our Kickstarter page link and help us to make our dream reality.

https://www.kickstarter.com/projects/landsofruin/lands-of-ruin-hybrid-tabletop-gaming-as-it-should

I hope to get back to normal writing after the Kickstarter is over. There are couple of Android apps that have design that needs to get some attention!

Splash screen with any other name is still a splash screen - and they suck!

2015-08-10T03:30:00.000-07:00

For some unfathomable reason Google decided to add Splash Screens to their design guidelines. While they now call it a "Launch screen" it's the same thing. A screen that is shown to the user while the app is loading.

Unsurprisingly, this started a lot of (unhappy) discussion in the Android community. I recently added my opinion as well. In all the discussions there's a common theme. Overwhelming majority of people seems to be against the use of splash screens. Then again truth is not democratic so paying attention to the arguments for usage of splash screen makes sense as well. In almost all of the discussions the same arguments arise. Until now I've not seen a single argument that I'd completely agree with.

As the discussion in G+ has been spread into multiple separate threads already instead of trying to reply to them separately I'm writing my answers to the common arguments here.

Argument: Splash screen is better than staring at an empty screen.

This is one of the most common arguments what I've seen posted in the comments. If your app's landing screen takes a long time to load your app is broken. While arguably Android has become slower over years Activity startup times are still very fast. Inflating the main layout and showing a UI without any dynamic data should be very fast. If that's not the case in your app you should fix it by making it fast to load instead of adding a splash screen that will then guarantee that your app is always launching slow.

We have to remember that mobile apps are used in short bursts. Sometimes a use session might last only for few seconds as user checks something or searches for an answer. If your app uses 3-5 sec to even show a UI to your user you're already wasting user's time.

Argument: Splash screen is better than not having any information if the app is launching other than the launcher button getting pressed.

While technically this argument is true the root cause of the issue is not solved by adding a splash screen. Some apps do indeed take ages to even show up and lock the UI while they're trying to do everything to show user something. These apps need to be fixed! The app is running something in the UI thread that it shouldn't. The app developer needs to take care of the threading to fix the app. "Fixing" it with a splash screen is like adding gaffer tape over a leak hoping it'll go away.

Argument: My app's data takes a long time to load. A splash screen is better than a loading indicator. This especially with slow internet speeds.

This argument is also very common but I feel that there's a fundamental flaw in it. This argument assumes that the users always want to start with the data that is being shown on the app's landing screen.

The reason I argue against splash screens in this case is twofold:

If you show your app's UI to the user first and then load the data into it you allow user to orient to the UI and they're immediately ready to go when the data comes in.
Users don't always want to interact with the data on the app's landing screen. Let the user get on with their task without forcing them to load the first screen's data. This is very important especially on a slow internet connection. Let user interact with your app while the data is loading. In many cases they might not care about the data you're loading by default.

Argument: Splash screen is needed to help brand presence.

If the design can't display the brand without an extra screen the design sucks. You can't rely on a screen that is shown to the user once in the start of an app to convey an important message.

Argument: Splash Screen can be implemented correctly.

I'm saving the big one to the last. This is the argument Google's Dev Advocates keep brining up (I love you guys but in this one, you're wrong).

To me this boils down to three main things:

This is a slippery slope.

Yep, a slippery slope argument is a logical fallacy. Unfortunately, I believe this being actually a slippery slope in our industry. I've been part of many software teams and seen many from far. The problem is that a lot of uninformed decisions get made in the teams. It is unfortunate situation but happens more often than we'd like to believe that people without knowledge or understanding to make a decision make decisions about things they shouldn't even be part of discussing. Brand design in an app is one of these. A product owner often want the brand more visible without understanding the impact to the users. While they selfishly simply want their logo to be visible everywhere they don't understand the harm they cause to the app's UX this way directly harming the brand image.

Previously we, as the devs and designers who want to create the best possible app, have had another logical fallacy in our toolbelt to fight this. The Authority Fallacy. We have been able to argue that Google says that splash screens should not be used. That usually convinced these decision makers who would ignore arguments from their own experts. What will happen now? In the same discussion they can pull out any Google app and point to it and say that "Google is doing this, so will we".

The big problems will come once the decision is made and all the sudden there's one extra screen for people to add junk on. Nearly an empty screen to play with. At this point it doesn't matter if we, the devs, start explaining how it is just a theme background image and not an actual screen. The battle is already over. I know this will happen. I've been in these meetings. I've worked with these people. Google has stripped us from our weapons in this battle.

Dear Google Dev Advocates, you live in a different world than we do... Say hello to ads on splash screens...

Trying to do a splash screen right is like polishing a turd.

The pattern is flawed. Fundamentally flawed. When you premise is wrong it doesn't matter how well you do something it'll still end up being wrong.

Google's version of splash screen is just a themed background shown while the app inflates it's UI. While it sounds like a nice idea it really isn't. A small graphical component certainly loads so fast that it doesn't slow down the UI inflation but why would you do that. If your app's UI inflation takes seconds you're already doing something wrong. If it doesn't take seconds only thing you're doing is flashing some graphic to the user that they don't really catch. Quickly flashing graphic is worse than no graphic at all.

Then there's the problem of this kind of splash screen not being able to convey any progress. It's just a static screen. If something takes longer how do I communicate that to the user? You know that the first thing any designer wants to add to this is a loading indicator and a nice transition out of the splash, right? This leads into a situation where we now have to use an Activity instead of the screen background. Should we then use a splash screen while we're loading our splash screen?

Showing splash only on "cold launch" exposes users to OS internals.

Android OS was designed to hide OS functionality from users and developers work hard on making the users feel like the app is always there and they can continue from where they left off whenever they come back. We do this because users shouldn't have to understand what happens when the phone runs out of memory and the apps are cleaned from the memory.

Now we introduce different functionality on "cold launch". It makes perfect sense to us, the devs, but it doesn't for regular users. To a regular user this functionality will only be confusing. The app sometimes shows this strange logo screen and sometimes it doesn't. What's the difference? Do I need to do something different?

This is such a bad idea. Consistent and predictable behaviour is important! Let's not force users to start figuring out what's going on under the hood.

So. NO. Do not add splash screens to your app. Simply make sure your app launches to the main UI fast and let users get on with what they want to do.

Thoughts on Designing for Smartwatches

2015-05-05T05:30:00.001-07:00

There's been more and more discussion about wearable tech and especially smartwatches lately. Apple's Apple Watch certainly threw some more fuel to the fire when many tech journalists rushed out their reviews of the device. Many of the reviews of the Apple's device made a big deal about notifications and how irritating and disturbing they were. I believe this to be a symptom of bad journalism and lack of understanding and experience with the device.

While I can't make many claims about the Apple Watch I can, however, talk about the effects of smartwatch use in my life. I have been using Android Wear devices daily since the last year's Google I/O. While the things I'm writing in this article are very much anecdotal I've heard others expressing very similar thoughts during the last year.

At the start, I was extremely sceptical about wearing a smartwatch. Firstly, I abandoned wristwatches years ago. Last time I wore one was when serving in the army in -99. Going back to having something on my wrist was not an easy thing to do. But then again, I'm an Android developer and when something new arrives to my domain I feel that I have to give it a try so I can talk about it to our customers. Second, I really didn't see the point of the watch. Why would I use the small screen when I have a perfectly fine screen in my pocket.

So I did. At the morning of June 26th 2014 I wrapped an LG G Watch to my wrist, jumped through few hoops to get it running with the pre-release software, and I haven't looked back since.

The Watch Extends Your Phone

One thing people (and tech bloggers) keep asking about smartwatches is: "what does it do?". The answer currently is: "not much" and that is good.

Let's first accept few facts. The smartwatch screen is tiny. The currently available watches also have fairly poor hardware behind the tiny screen. Both of these factors limit what you actually want to do on the watch.

A good thought experiment to do is to see how long the task you're thinking about doing on the watch takes. If it takes longer than 5 seconds from start to end you probably don't want to use your watch for it. Think about it. You already have a perfectly fine larger screen in your pocket. taking the phone out and turning on the screen and focusing to the task takes only few seconds.

Apps - not so important - yet

The way Google kickstarted the Wear ecosystem was well thought out. Your Wear device directly hooks into the already powerful Android notification system. Actions on notifications are available on the watch without developers having to update their apps. This is why one could argue that Wear had millions of apps available on the launch day.

The Wear devices can, however, run much more complex apps than just glorified notifications. In fact, your Wear device runs nearly full Android OS. Building complex apps for Wear is easy and fast but that doesn't mean you should.

I already referred to the 5-second thought experiment. Would you actually want to reply to a text message on the tiny wrist screen or would you rather pull out your phone and use the comfortable keyboard on it? I know I would just use my phone.

Interaction is a big problem when it comes to building apps for smartwatches. How do you do user input? There are few attempts trying to implement keyboards for Android Wear but all of them fall short in comfort of use. If the user input you expect is any longer than two words users there's no point trying to get the task done on the wearable.

There is voice, of course, but voice has a very limited use for multitude of reasons. Privacy in crowded places, voice recognition issues in loud areas and so on.

There are limited use cases for apps running on the watch fitting these limitations. Apps running on the watch must behave like extension to their mobile counterparts. Fully standalone Wear apps are unlikely to ever become very useful.

All configuration and data input must happen either via a web client or a mobile app. Never ask user input on the wearable beyond a very simple one-tap interaction.

Let’s look at an app I find really good: Bring! Shopping List which also happens to be pretty much the only app I'm currently using on my watch beyond notifications.

Bring! is a shared shopping list app. The app itself is nicely made and I can recommend to everyone (I just wish they would add Google login to the app). In this context it's the Wear extension that we're interested about.

The Bring Wear extension shows you the current shopping list. From feature point of view it is very limited. You cannot, for example, add new items to your shopping list or send notifications to your partner. For someone who is not a Wear user this might seem to be limited but it is, in fact, very well thought out approach. The only actions you can take on the Wear app is to mark items done. That's all. Any more complex tasks the mobile app is better anyways and your phone is in your pocket anyways.

The simple approach of Bring! Wear app design allows them to keep the UI clean and usable. Shopping list is also a use case where it makes sense for users not to have their phone out all the time and making the shopping list available to your wrists is actually very useful. I use this app when shopping all the time!

In short. Bring! on your wrist makes sense while most apps don't because of:

It is used in a situation where users hands might not be available for holding a phone.
It seamlessly maintains the shopping list based on what you add on your phone.
The interactions are designed to be very simple and straightforward.
Only a very limited and therefore focused use cases are supported on the wear. Because of this small focus the UI can be highly optimised for completing the task.

Bring! might not be the killer app that sells the smartwatch use to the general public but their app design approach most certainly is spot on. When you're thinking about extending your app to a wearable think first. Is it needed? Why would users use the wearable instead of their phone? What kind of situations it is for? If you can't answer these questions maybe your time is better spent polishing your mobile app.

This is still a new area for apps. The apps that we're celebrating year or two from now are probably something we don't even think about yet. So keep trying! Just remember to keep thinking about the use context. Instagram feed on your wrists doesn't make sense in any context...

Notifications, notifications, notifications

While we're waiting for the killer apps to emerge let's focus on what is currently the killer feature of smartwatches. Notifications. The way smartwatches help you to handle the constant notification stream is great. To me, personally, this is the reason I wear mine every day. But this is also the place where people are going to be split into two groups: smartwatch users and non-smartwatch users.

Let's start with a screenshot:

If you're a type of person who is annoyed by the flood of notifications in the screenshot smartwatch is probably for you. If you, on the other hand, don't really mind a smartwatch might no really help you.

To me, Android notifications represent a todo list. As long as I have notifications up there I need to do something. Often the "do something" is simply reading the notification and swiping it away. Sometimes it is more like reading an email, replying to G+ comment and so on.

The power of Wear, to me, is that I can filter my notifications (my todo) without taking out my phone every time I receive a notification. Firstly, with a quick glance I can determine the priority of a notification.

The latest notification shows key aspects of the events immediately (depending on the app). In case of G+, GMail and Hangouts I always know which app notified me and who did something to cause the notification. Usually that's enough information to device what to do with the notification. Sometimes it's OK to ignore the notifications while sometimes I want to react to it immediately.

But this is just the first step. Second, and the most powerful one, is the gestures that allow me to put the notification to its right category.

I can:

Pull out my phone, act on the notification immediately. For example, in case of a hangout message from someone I'm waiting to meet.
Swipe the notification down. This way the notification is going to stay on my phone. These are the things I want to react to soon but not right now. Maybe a hangout message from a friend but when I'm currently in a situation I can't talk right now. Next time I pull my phone out the notification is going to be there to remind me.
Swipe the notification away. These are cases where I get all the info I needed from the notification and I don't wish to react to it on my phone at all. This could be a notification from Swarm, for example. The notification already told me everything there's to know about it. Done.
Other case for this is an email that is something I want to read but there's no hurry. Swiping the notification away will dismiss it from my phone as well but the email itself stays in the inbox unread and will be waiting for me when I'm in front of my computer the next time.
I can perform actions to the notifications. Most useful of all of these is the GMail notifications. If I get an email I can either directly archive it from my watch with one swipe & tap or tap the email to read a bit more before making the decision. I do this A LOT. When I get promo emails which I don't really care so much about I tend to glance at them and archive directly if there's no interesting topics. This way the notification is gone and the email with it.

I keep hearing people (and reviewers) saying that they hate notifications and the last thing they want is more notifications on their wrist. I think this is a misconception. A Wear device doesn't add more notifications to your life. It allows you to get rid of the ones you don't want much more easily. THAT is the best thing about Android Wear in its current form.

Notification on the wrist are not annoying. They do not interrupt you (at least on Wear). You can keep ignoring the subtle vibration on your wrist if you want but it's there if you need it and you don't need to pull out your phone. And of course you can prevent apps you never want to see on your wrists from posting notifications to the Wear.

This is, however, something that takes time to get used to. That's also why I feel that almost all of the Apple Watch reviews were posted too soon and the reviewer didn't actually have any idea of the impact of the wearable. For me, it took more than a month to get used to not pulling out my phone every chance I got to check if I had missed something. Also, when waiting for a message from someone I no-longer was holding the phone on my hand to make sure I don't miss it. My Wear device takes care of that.

It takes time to change your habits but once you do wearables starts to make sense.

Importance of the watch face

As I already said apps don't make much sense on smartwatches. Watch faces, however, do! It's still a watch and users do use it to tell time. On Android Wear watch face is the most persistent part of the user experience. Watch face is the part user sees every time they look at their wrist.

Watch faces also allow personalisation of the device. Different people like different style. Watch faces are going to be one of the key selling points of future smart watches, I'm sure.

On Android Wear the watch faces API was recently opened to devs. Even before there already was a flood of custom watch faces in the Play Store. Today we're spoiled for options.

There are two basic approaches to watch faces on Android Wear at the time of writing this: 1) customisable watch face platforms 2) masterfully designed preset watch faces with little or no customisation options.

When building a customisable watch face there are couple of things to think about. Firstly, if your configuration has a lot of options don't expose them on the watch, do it on the phone.

Probably the best example of doing things right is the Puije Black watch face. Their phone configuration app is easy to use and also follows Android design guidelines. Their preview is live rendering of the watch face available for round and square screens.

If your watch face is highly configurable take more time designing your configuration app. All normal app design guidelines apply here. Think about users. Use Android components and patterns. Your users will give up if they can't figure out how to make the watch face theirs.

Smartwatches are not for everyone

Wearing a watch is a personal choice and so is spending hundreds of euros for yet another tech device you'll be upgrading in a year or two. Smartwatches are definitely not for everyone. I don't think the potential market for Android Wear in its current form is more than 15% of all Android phone users. How many of them will get one is an even more difficult question.

Even with those limited numbers it makes sense to think about Wear when you're building your app. Making sure you handle notifications correctly is an easy way to please Wear users. Building a Wear app is also very easy as Wear is just Android. But take a minute thinking if building one for your app makes sense.

I like my watch so much that if I accidentally leave it home I really miss it and find it annoying to use my phone. But I completely understand people who don't think they need one. Android Wear is great but not for everyone!

How We Created Scalable UI - A Case Study

2015-01-08T05:08:00.000-08:00

I rarely get to write about projects I've been involved with myself so writing this one makes for a pleasant change. For more than a year I've been working as a consultant embedded as a part of a very talented Android design and dev team at Onefootball. Onefootball, an awesome startup based in Berlin, have been developing apps for multiple platforms to bring football (soccer for my American readers) news, statistics and results to their users.

Download the app for free from Google Play

As a company, Onefootball has great ambition to do things right and be the best football app on every platform. This ambition is found from the management to the design and development team. A bit more than a year ago it started to become clear that an Android app wasn't good unless it utilised larger screens as well. That is when I joined the team.

The app is extremely rich with content. The amount of leagues and competitions available to users to browse for is mind boggling. Each of the competitions comes with massive amount of data complete with full season history, match data, team compositions, player statistics for each player and news related to teams and competitions.

Scalable Design

Arranging this amount of information is not easy. Creating responsive UI to accommodate all the different data display variations required us to use multiple different approaches. In this article I want to introduce few of the solutions we used to a create scalable UI that works seamlessly across a broad range if Android devices.

From tabs to columns

A lot of the app's content is split into multiple content sections that exist at the same level of the information hierarchy. On a smaller screen the natural component to use is a tab bar. For example the match screen shows things like the match overview, live ticker, line-up and stats.

Each tab's content is created as a flexible screen that spans the width of the screen on most phone sizes.

To get the match screen ready for larger screens the approach we chose to take was to remove the tabs altogether and show the tabs as columns which forms horizontally scrolling content. This created a display that easily scaled up to any tablet size and utilised the available screen space without feeling like the components information was cramped or constrained by space.

Tabs to tabs

On other screens with a similar structure we went a different way. This was when the content of the tabs itself was nicely scalable and was able to utilise the available screen real estate.

Many screens like the match screen were perfect for this. The content of each tab was already using card-style layouts and simple reorganising the way the cards are laid out in the screen allowed us to utilise the full screen on larger devices.

In some cases we also adapted the content of the cards to limit the amount of information shown when space is more limited. In this case, for example, the number of teams shown in the competition table is only three when on a smaller screen device and on larger screens we can show more. The full table is only a tap away for the users who want the complete information.

Cards are flexible

It's not an accident that a lot of Android apps use card-style visuals to show their content. Cards are easily arranged into flexible layouts and scalable UI forms itself nearly automatically.

Content like news articles with rich visuals and mixed sources create a great opportunity to use staggered list-style approach to create visually pleasing, content rich screens.

In some cases simply arranging the cards wasn't possible. If the cards used are different in size and must maintain strict chronological order using a staggered list is not the right way to display them. For us, the solution was to break some of the cards into smaller content components and show them as a grid.

In some cases the smaller screens displayed the content in a simple list while for larger screens we utilised grid-like layouts. This is something Google advises against in the Material Design guidelines but in this case we decided to break from the guidelines as this created the best possible scalable result.

Viewpager is easy to adapt

Viewpager is a very powerful component. On the team screen we wanted to show recent and upcoming matches.

For smaller screen widths we only show one match and a small slice of the next one to communicate to the users that there's something more just a swipe away.

When there's enough screen width to fit more than one match comfortably we adapt the viewpager to show two or three pages to reveal more information to the user.

Adaptive navigation

In some cases we chose to change the navigation hierarchy slightly when user was on a larger device.

For example in case of the list of matches, we made the selection in the mast screen open a quick view of the match instead of navigating directly to the match page (like it does on smaller devices). This allows users to browse multiple matches more easily while still making it easy to jump into the full match page when the user desires.

On the competition stats detail page we improved navigation between the different stat details on larger screens. Larger screens meant there was empty space on both sides of the list and it felt like a natural place to place quick navigation to the other details pages.

For the competition matchday list we ended up using a dropdown navigation on smaller screens but larger screens have room to show the matchday list on the side allowing user to jump between the matchdays more easily.

User Delight

Going for good app to a great app requires more than just nice scalable UI. You need to delight your users. In case of Onefootball a lot of details were added to the app to push it from being good to great.

In a football app the right place to start making users delighted is the team page. Onefootball app affords each team a fully themed page. A fan of any team will immediately recognise the colour theme and prominent team logo.

The team page was also improved with subtle but meaningful behaviour. The header of the page transforms into toolbar when scrolled. Lollipop's activity transitions were also spot on for this content. The hero element transition is both delightful as well as helpful.

Conclusion

The Onefootball was great fun. Working with a company that wants to do Android right is rewarding. The results are something I can be very proud to have been part of. Elegant Android scalability can be challenging but approaching it the right way makes it possible to get great results. There are pitfalls but they are avoidable. In our case the app ended up being featured multiple times - most recently as the Editor's Choice in the Google Play Store and in the Google's 2014 Best Apps List.

If you are interested in working with the Onefootball to create the best football app ever made I can wholeheartedly recommend the company. Check out their website for open positions here: http://www.onefootball.com/careers.html.

If your company is interested in getting your app built the right way and pushed to the next level don't hesitate to contact us, at Fat Robot. We can help you. We know how to build Android the right way.

http://fatrobot.io/
juhani@fatrobot.io

The State of Android Hardware Companion Apps

2014-11-16T09:03:00.000-08:00

- 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?

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

2014-10-10T06:30:00.001-07:00

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

Material Design - Activity Transition Animations

2014-09-05T04:12:00.000-07:00

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

Read This: Designer's Guide to DPI

2014-08-18T02:24:00.001-07:00

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

Read this: androiduiux.com - Crafting the Unclouded Experience

2014-08-11T14:03:00.001-07:00

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

2014-08-11T05:34:00.000-07:00

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!

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

2014-08-05T12:54:00.000-07:00

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.

YouTube Link

Android Developers blog post

On Importance of Supporting User Goals, an Example

2014-08-05T01:39:00.002-07:00

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:

Samsung Delivers a Pile of Failure in Their Olympic App

2014-02-02T06:38:00.000-08:00

Onboarding experience

What Samsung has done with their first-time experience is stunning. To me this is by far the worst what I've seen. I'd be very interested to see analytics from their system about user dropoff rate in the first couple of screens.

It is worth remembering that the your app's user experience starts from the Play Store. Be careful not to leave in permissions that not actually needed in your app. Why does this app need to disable my lock screen? Scary.

Once you get the surprisingly large 30MB app installed to your device you're ready to embark to to most remarkable journey to try to get to the actual content.

When you first launch the app you're greeted with a popup reminding you that when you use data it might cost you. If that wasn't stupid enough look at the options provided to you in the popup. "Do not remind" and "OK". I wonder if they mean "Do not remind me again" or "Damnit! Don't remind me. I don't want to know!". If I select OK does it mean that they keep reminding me that my data might not be free every time I open the app? Ridiculous. I bet this was put here by Samsung's legal department.

Once you figure out which one of these ridiculous buttons you want to press you'll see a gift from the Samsungs software engineering department. A splash screen with a loading indicator. I refuse to believe that they don't have any content or app structure to show without "Updating data: DB". But hey, at least we get to see the debug messages showing which data it is loading.

When the "Updating data: DB" is ready you're certainly going to see some content and be able to figure out if you want to use the app or not. Well.. not so fast.

First you need to tell the app which Language you'd like to use. I don't know in which usage scenario this makes any sense but I'm certain that Samsung's engineering team must have a great UML chart explaining why this is needed.

User already selected the language when they setup their phone. Apps never have to ask language form users. Never! Worth noting, by the way, the app's language selection doesn't even default to your phone's language setting. It always defaults to English.

Once you figure out which language you'd like to use you're presented the feared T&C screen that every legal department on the planet loves so dearly. Fortunately Samsung hasn't even tested reading their legal text as when you open one the screen's scrolling mechanism breaks. But that's not a big loss. Nobody ever reads T&C anyways.

But surely we are now done. Right? Well.. No.

We now need to tell the app which country we like. While it could probably at least guess the country where I'm in right now (it uses location permissions) it chooses to default to the language setting of your phone (you know, the one they could have used for the language selection). But then again, personalised data in the app based on my favourite country, athlete and sport. That's great!

I think a better way to do this would be to default to your country and your country's most popular sport and let the user easily change them but I can't really blame Samsung going this route. That is if they'd done the actual selection screens well. I know that Samsung has been a big fan of Apple for a long time but I'd still keep Apple's search screens out of Android.

Now that you've found your country and other info needed you're set to go, right? Must be... Nope.

This one is so bad that it made me laugh when I saw it. "Need to update spp client" Go google market! Go!

Firstly, some level of spelling checking would probably make sense. I'm not a native English speaker either and I bet that I have more than my fair share of broken English on this site but I'm not a multi-billion dollar corporation. Secondly, what the hell is "spp client"? Am I supposed to know that?

At least pressing the "OK" takes me to the Google Play Store to install some more Samsung crap to my phone. Go google market, go!

Once you install the additional Samsung push services you'll finally be able to use the app.

Rest of the app

Unfortunately, rest of the app follows pretty much the same path as the onboarding experience. It is riddled with very bad design decisions and poor implementation. It sometimes uses action bar items to navigate between screens, tabs are never swipeable and some screens are locked to portrait while others are locked to landscape.

Christophe Versieux compiled a list of usability issues found in the app (I left out the points I already mentioned above):

Still an iOS 2D launcher icon, square with rounded border, not following the slight 3D and silhouette pattern we are used to an Android
iOS 7 design (icons, colors)
Ads at the bottom that lead to Samsung US website
Use right-pointing carets on line items
ActionBar looks bigger, separators are ugly and even displayed when only one item
Non scrollable tabs
Settings screen (sounds obvious)
On the Map they even used the iOS pin!
Toast when trying to exit the app
Navigation drawer is the sliding menu

You can find the app from Google Play for free at: https://play.google.com/store/apps/details?id=com.samsung.sochiwow.minfo.ex

Awesome Android Design - slides by Nick Butcher

2014-01-15T02:42:00.000-08:00

Nick Butcher from Google gave a presentation on "Awesome Android Design" in the GDG Sydney meetup. While the presentation itself unfortunately isn't available online the presentation slides are. This slide deck is packed full of important information from beginner to experienced Android designers and developers!

Get the slides from here.

HTC Maximizes User Frustration with their UX Design

2013-11-27T11:38:00.000-08:00

It's a sad day when I have to write a negative post about an app that was built by one of the Android phone manufacturers I really like. But in this case I just cannot not write this.

This app is so full of mistakes in UX design that I don't even know where to start. This app could actually be good but in its current state it is one of the most frustrating apps to use.

Incorrect touch feedback

The app is mostly composed with HTC's custom tile layout. While I'm not personally a fan of it there's really nothing wrong with it. But what I'm not fine with is the deceptive touch feedback on the tiles. For some reason the app wants to make you believe that every tile is tappable. That's not the case, however. While every single tile does react to taps (it gets pressed down) only few of them actually lead to somewhere. The app is lying to users and creating disappointment after disappointment.

In this example tapping the score or the location doesn't do anything while tapping the team icons and the bottom three tiles actually do.

How to fix: Clearly distinguish tappable components from non-tappable ones. Do not add button down states to components that don't do anything.

Confusing navigation

The app makes users easily confused about where they are in the app's navigation hierarchy. On Android the text on the action bar should always tell the name of the screen where the user is. For some unknown reason HTC has decided to sometimes show the current screen title and sometimes show the title of the screen where the up (back in this app) will take the user when tapped.

Here's couple of examples. On the left I'm reading the highlights of the Champions League. I tap one of the articles and the action bar title now changes to "Highlights".

In the above example the user might still understand what is going on after pausing for a bit and but it is much, much worse elsewhere in the app.

In the example below I'm at the post match screen. The screen title is correct. "Post Match". I tap one of the teams and I'm taken to the team page. But wait a minute!? The screen title now says "Clubs", plural. I've clearly selected Arsenal and every page in the viewpager is only Arsenal related information. The screen title should say "Arsenal".

Now, this took a little bit work to figure out what's happening here (I initially thought that it's just a typo). The reason this screen says "Clubs" in the action bar is that there's another way to get to this screen: via a clubs list. So this screen title is actually a title of a higher level screen that is in another navigation tree. And as they're not implemented the up functionality correctly tapping the up button takes me back to the post match screen. Incredibly misleading!

How to fix: Very simple fix in this case as well. The action bar always tells the user where they are. Change each screen to reflect that. The app's up navigation should also be fixed. Up != Back.

Notification spam and incorrect notification title
This app spams the user like no other app I've ever seen. It literally notifies me every minute if I use the app. In fact, I think they have tied a notification to app closing event. Who approved this?

The content of the notification has no value to users.

How to fix: Don't do this. This is just stupid.

Another issue with the app's notification is much more minor but still should be fixed. For some reason the app users the app name as the notification title.

How to fix: Notification title should be the event title, not the app title. Just use the match name when there are multiple events in the same notification or the event name when there's only one.

Tablet what?

The app does not scale nicely to larger screens and is locked to portrait.

How to fix: some of the screens in the app work pretty well on larger screens as well. But some could use some large screen love. And remove the portrait locking. Nobody should ever do that.

Yep

There you have it. The app is not great but could be. How did the company behind such gems as HTC G1 and Nexus One let this to the store I don't know. I just know that it makes me sad. Let's hope HTC fixes these issues soon.

If you want to try the app yourself you can find it on Google Play.

Going responsive with Google Play - a presentation by the Google Play team

2013-11-14T02:31:00.000-08:00

Kirill Grouchnikov often talks about the design and development of Google Play Android app and lets us see behind the curtain of the most used Android app and how to make it work on all devices. In the AnDevCon Kirill gave a presentation with Marco Paglia "Going Responsive with Google Play". The presentation slides are now available and very much worth taking a look.

Get the slides from Google Drive: Going Responsive with Google Play

More About Android 4.4 from Google's Developer Advocates and Engineers

2013-11-02T06:55:00.000-07:00

There's tons of information about Android 4.4 all over the Android developer site. I bet we've all been sifting through the information overload yesterday and today. But wait, there's more! Google's engineers and developer advocates have been posting tons of interesting post to Google+ allowing us to deepen our knowledge of the new platform version. Here's a list of few of them.

Nick Butcher posted a good collection of links about the Support Library and Play Services.
https://plus.google.com/u/0/+NickButcher/posts/LgFBByJFvpS

Roman Nurik posted links to the updated Device Art Generator as well as links to PSD of the Nexus 5 renderings.
https://plus.google.com/u/0/+RomanNurik/posts/6rvFc3txjEs

Romain Guy posted two posts about the Android UI framework:
Android 4.4 & rendering pipeline improvements
Batching & merging on Android 4.4

Get Up to Speed with Android 4.4 Design - Watch this: ADiA

2013-11-01T15:23:00.001-07:00

I've been reading about new APIs and services available in the new Android 4.4, KitKat, release. It looks like this release is another big step forwards with the platform UI design. Probably the biggest user-facing change is the toning down of the Holo blue colour throughout the system. The system status bar, for example, no longer has blue icons and the Holo blue glow for touch feedback is gone from buttons and scroll edge effects.

To get a good overview from design point of view to the new platform device the best source is the latest episode of Android Design in Action (ADiA). The Google's team explains many of the platform highlights with examples.

Watch it on YouTube:

Android Design in Action: New in Android 4.4

How Following Android Guidelines Can Change Users' Perception of Your App

2013-10-30T14:34:00.000-07:00

Sometimes when installing random apps from Google Play I run into apps that are great positive surprises and stand out from the masses. In this case this app isn't mind blowing or anything like that but it is a good, simple to use and very much an Android app. I'm talking about Hotel Search HRS app.

But before we delve in I want to note that I am in no way associated either with the app developer or the company. Many of the comments in this post are based on educated guess based on the data publicly available.

What made this app interesting was that there seemed to be two of the same apps in the Play Store with different package name and one of the apps with postfix "new" in the name. After digging a bit more it became clear that they have had an app before that have been very unsuccessful. Unfortunately I was not able to find the previous app anymore as they've updated the old app to the new version as well but fortunately AndroidPit still had screenshots of the old app.

Here's how the app used to look like (screenshots by AndroidPit).

Screenshots by AndroidPit

The app reviews tell a grim story about the user reception the previous version had.

Some of my favourite quotes from the user reviews:
"the hitler of mobile apps"
"Worst app ever"
"Good for nothing app Worst app ever made"
"Absolutely Crap"

It also looks like that some carrier or OEM has forced this app on phones without allowing users to uninstall it. It just looks bad on so many levels.

New app

Fortunately the company behind this app has now taken the hint and understood that what they had simply was not cutting it. They have now created a new app. This time the app is clearly built by a team that knew what they were doing. This must have been a team of designers and developers who understood the Android platform and knew how to build for it. The result is good.

Here's how the app looks like now (or you can try it yourself Google Play link):

Now, we're not talking about revolutionary UI design. It certainly isn't a Timely class app but I think that is what makes this app a great example to businesses. The app simply follows Android design guidelines, uses default components and is generally well structured and designed. Users are likely to understand how to use the app without thinking. While the development most likely wasn't cheap it probably wasn't extremely costly either. The level of quality, usability and especially Androidiness is possible for any company willing to do it.

Here's how the new app reviews look at the time of writing this:

The sad thing is that the previous app had 1,000,000 - 5,000,000 installs on Google Play. The company was forced to create another app to get rid of the extremely bad reviews. I wish that Google Play would allow developers to correct their mistakes and help the developer improve their app ratings by releasing new app versions but that is currently not the case.

As a conclusion I would like to say and use this app as a cautionary example of the damage done to any brand that choses to release bad apps and and ignore the platform guidelines. In the worst case it might mean that you will have to start from the ground up later on to gain any credibility.

Here's more screenshots of the new app version. Tip of the hat to the company behind this for making the bold step and to the developers and designers involved for doing excellent work!

Taylor Ling's UI Design Kit updated. Also for GIMP.

2013-10-03T11:07:00.001-07:00

Taylor Ling has updated his awesome design kit to 4.3. The update contains tons of new updates and it's all available for free from his website.

Check out the changelog and get the download links here: Android UI Design Kit for Photoshop and GIMP 4.3. If you like it and benefit from it please throw few dollars to Taylor's way via paypal.

Google's Android Apps Look Boring - And It's a Good Thing

2013-09-15T03:49:00.001-07:00

This is a post I've been wanting to write for years but it hasn't been possible before. Google's apps on Android have been similar mixture of styles and patterns as we've seen in Android apps in general. But now it is finally changing. Google has unified their app UX and visual style. Most of their apps now use standards components and design patterns explained in the Android design guidelines. I think we can finally say that we have a unified platform when it comes to apps (well, almost).

But what about the style. Google apps all look relatively boring, right? Most of them use the default gray style and even the ones that don't, use very simple variations of darker gray colour themes.

Gray is the new black

I think that the plain styling of the Google apps is a great thing. Let me explain why. Personally, I very rarely buy any non-black, non-white or non-gray clothes. The simple reason is that I can't be bothered to figure out if a certain tone of red works with my other clothes so I go with the ones that I know always just work. I think Google has done the same with the stock app stylings. The Google apps will never clash with even the wildest and craziest stylings of 3rd party apps. Whatever crazy apps you'll install to your phone the GMail app is always just fine (just like my black shirt).

When everything is gray non-gray stands out

Another reason why I think that Google has made us all a favour by staying with their extremely simple styling is that now that we see apps like the amazing Timely they stand out. Google has left room for 3rd party apps to shine and stand out.

Making gray is easy

Third reason I really appreciate the simple styling of GMail, calendar etc is that not every project has a designer (sad but true). On Android it is perfectly fine to leave your app without styling. The simple non-clashing colouring and style of the platform stock apps lets us, the developer types, use simple math to create our apps. Just make sure that your margins, hit areas etc are as defined in the design guidelines and your app visuals are going to be just fine. It'll never win any design contests but not every app has to.

So, this is why I think Google's apps are awesome because they're not awesome.

Android Asset Studio Nine-patch Generator update adds an interactive preview

2013-08-23T12:16:00.000-07:00

Nine-patches are one of the most powerful graphical components for creating scalable Android apps. They are, however, sometimes difficult to understand especially when starting with Android development.

The Android Asset Studio online tool has had a nine-patch editor for a while but today it got much better. Roman Nurik announced an addition of an interactive preview to the tool. In addition to easily editing the stretch regions, content padding and optical bounds you can now resize the preview and see how the asset scales directly in your browser. Once done, you can then export assets for different densities ready to be dropped to your app project.

If you're a developer send a link to this tool to your designers. They can now make sure that the assets they create scale correctly without need to put the assets into the app to try them out.

You find the Android Asset Studio Nine-patch Generator here: http://android-ui-utils.googlecode.com/hg/asset-studio/dist/nine-patches.html

Read Roman's announcement here: https://plus.google.com/u/0/+RomanNurik/posts/EJrAU41o9wf

The new yardstick for the best Android design is here - Timely Alarm Clock

2013-08-19T04:59:00.002-07:00

Tasks app is something I've been using as an example of great and simple Android app in many occasions. It's one of the apps that took the new Android design and implemented it in it very basic and in the simplest form possible. I've used it as an example what to do when you don't have access to a lot of design resources.

Now, the same team has released their next app. And it is beautiful!

Before reading further get the app from Google Play for free. There's so many things in the app that can't be shown in screenshots.

Design guidelines

The timing for this app release is perfect. There's a lot of discussion about Android guidelines and what following them means. Even Matias Duarte chimed in. This all, of course, relates to release of the very beautiful Yahoo! Weather app and the strong reaction to criticism of it.

Many seemed to think that following design guidelines somehow limits creativity or makes all apps look the same. That's absolutely not true and Timely Alarm Clock app is the best example of this ever released.

The Timely Alarm Clock app follows the Android design guidelines on every screen. Any Android user feels home in the app from the initial launch but it is beautiful. It most certainly doesn't look the same as other apps.

Pushing the boundaries

Another misconception about the design guidelines is that if you follow them you're bound to using only the standard components provided by the platform. That's not true either.

The Timely Alarm Clock app team has created a new and novel way to set the alarm time. On the app's main screen user can pull from the left-hand-side time bar to create a new alarm. This is not done in any app in the Google Play (as far as I know). It's a new idea and it works.

There's absolutely nothing wrong in creating this kind of new interaction. There's, however, an issue when it comes to new thing. Discoverability. If you do things that are common on the platform you can trust that users know how to use them but when you're creating something completely new you have to guide users a bit more. The app team does this perfectly as well. I've seen apps that try to explain how their app works by using popups. Never do that! Guide in context instead. Do what this app team has done. The available actions are explained in context and user is not blocked by the instructions.

Don't reinvent the wheel

Despite the tons of new innovation and beautiful design in the app the app team uses standard Android components, icons and design patterns where applicable.

UI components and icons

There's already a very functional switch component in Android, why replace it. There's also tons of great looking icons like the trash bin, why recreate them. Reskin, recreate icons only when needed. Use the standard ones when you're doing standard actions. Users know them.

UI design patterns

I love the fact that the app doesn't use a full action bar. Somehow for some people action bar has become a "have-to-have" component in every single app. It's just a design pattern. As everything else, Use it only if you need (but if you need it use the standard implementation!). This app does use bottom part of the split action bar though. It allows the app to show actions on each screen and creates a place for the overflow menu.

It is worth noting that when the app needs the top action bar to be there it appears. For example, when handling selected items the action bar is shown as that is what users would expect.

There are other patterns many of you would recognise as modern UI patterns introduced by the Google's Android team.

Settings

There's a standard way of doing settings in Android. Why change it? The app users are comfortable with the way settings are done in most apps so keep it that way and save yourself a lot of development and design time to be used in more interesting parts of the app.

Large screens

No Android app is good unless it works across many different screen sizes. Timely Alarm Clock delivers in this front as well. On larger screens, when there's space, the middle tab of the app is always visible. This is a genious approach for using the available space.

All the other screens adapt nicely as well.

Animations and transitions

The app is not only beautiful. It's delightful. Every time you tap on anything you get an immediate feedback of what you're doing in form of a pleasant animation. Each screen transition is well thought out and masterfully implemented.

In some apps animations are taken too far and merely cause motion sickness to users. Not so in this app. Everything is just right. Animations are smooth and short. They all serve a purpose to make user either have a better sense of structure in the app or convey a message of an action. This is how animations should be done.

Make no mistake. Animations are difficult and even dangerous. Adding animations to apps don't improve the app unless the animations are extremely carefully designed. Often it is better not to add animations unless you have the resources to make them as perfect as they are in Timely Alarm Clock app.

Technology

The app is not only well designed but it is technologically excellent. It automatically syncs your alarmas between devices and doesn't seem to consume much battery. This makes the app even better as an example of the best design on the platform. Functionality and design is not either or. They can live in the same app!

Polish, polish, polish

Everything in this app screams polish. Every screen, every transition, every animation has been polished to make them flawless. Applying this much polish to your app is not free. I don't want to even start guessing how much time building this app took. Whatever the number is, it is long. But all that work shows. When you use the app you don't only instantly know how to use it but you're delighted by it time after time. This is masterclass.

Even the app website is great. The team has taken the time to showcase their app with animated images and well sectioned feature descriptions. But what is most striking to me, as an Android fan, on their website is the fact that they've used multiple different devices to showcase the app. I'd love to see this from more people.

Conclusion

I'm speechless. This is the best Android app I've ever seen. This is the one I'll be sending to designers I work with. This is the app I'll be referring in my presentations and this is the app that'll be waking me up every morning.

We, as Android community, are in debt to the Timely Alarm Clock team. Hopefully companies around world will see this as a challenge and proof that you can be awesome on Android. Let's hope that we'll see this as a start of a trend. Let's how the world that you can push the Android design forward and create stunning apps without breaking the guidelines. The guidelines aren't limitations, they're there to help you!

Now, if you haven't yet, go to Google Play and get yourself the app that defines the next generation of Android design: https://play.google.com/store/apps/details?id=ch.bitspin.timely