Monday, 10 August 2015

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

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:

  1. 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.
  2. 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.

Tuesday, 5 May 2015

Thoughts on Designing for Smartwatches

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!

Thursday, 8 January 2015

How We Created Scalable UI - A Case Study

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.


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:

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.

Sunday, 16 November 2014

The State of Android Hardware Companion Apps

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

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

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

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

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

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

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

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

No thank you!

Cross-platform disasters

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

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

iOS-first (only?) approach

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

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

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

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

Direct iOS ports

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

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

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

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

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

iOS-only marketing

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

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

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

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

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

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

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

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

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

Crowdfunding projects

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

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

Self-fulfilling prophecy

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

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

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

Conclusion, TL;DR

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

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

Friday, 10 October 2014

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

It used to be so simple.

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.

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.


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.