To build a quality app, you must consider these 8 points
There are 8 areas in app development that I have found are often ignored by designers and developers. This may be because they would rather go with an implementation of convenience, or because they are “micro-interactions” and just not sexy enough for anyone to waste any brain power on when you are pressed for time or you have short deadlines. Some of these may not come across as a surprise to you. This is because Google has been telling us for a while now to not ignore these areas. What is interesting though, is that as I began to list them, I realised that a lot of these areas are related. I may even go so far as to say that these are some of my peeves when it comes to app development.
Without any more delay, the areas are:
What do the empty states look like?
Sure, while there is data to show on the screen, the screen looks great. But, what should we do on the screen when:
- The data fails to load.
- The data returned is empty.
- Some fields shown in the design are empty or null. Should they be displayed with no value, should they disappear? How does this affect the follow of the screen?
- There is no internet connection.
- What should the image placeholders look like while the images load or if it errors out?
When should the data be loaded?
I think it’s fair to say that I have never had this specified to me without having to chase someone up. The question here is, when some action is taken on a screen that requires loading of a whole new screen. Should I transition to the new screen, then load the new data, or should I load the data first, presumably showing some loading indicator and then when the data loads, then transition?
This question is related to #1 because if you transition before loading data, then what should appear on the next screen while the data loads? That screen will presumably be empty.
There is a new school of thought that says that you should “optimistically” or “predictively” load data in the background in anticipation that the user may click on a link. If you can do this, it solves the issue altogether, however, if you take this approach, beware that you will smash your users data allowance. Perhaps a better idea would be to check if the user is on Wifi, then load the data in the background before the user clicks. In this scenario, you’re back to the empty state problem and what if the data hasn’t finished loading in the background? Where should it be loaded? This takes us nicely to our next point.
What should the loading indicators look like?
To be fair, this is often specified, but since designers can’t really predict where all I’ll need loading indicators, the information is far from perfect. Nothing is worse than platform default loading indicators as they often don’t fit the UI and design pattern of your app. Android tried to address this by allowing your widgets and drawables to be tinted, so if you use an indeterminate progress indicator, it can be tinted to the same colours as those used in your app.
There is also the question of whether a loading indicator should be inline or blocking (more on this in point #5). This really does matter at times and can make the difference between a great user experience and an average one.
Loading indicators flickering on and off
I still remember the first time someone asked me to make sure the loading indicator was on the screen for at least a second before hiding it and to make sure that I wait for at least a second before showing it… mind blown! It was such a simple micro-interaction, but it made the user experience immediately better. You see, a loading indicator is often shown because the user interacted with the screen in some way. API calls on Wifi can be resolved in 200–1000ms easily depending on the amount of data to be transferred. This means, from a users perspective, the loading indicator can seem to flicker on then off. It gets worse when people chain API calls in their app, you can see this flicker several times on a screen. Loading indicators show up when a user interacts with the screen, when a user clicks something, it’s roughly 1–1.5 seconds before the user expects something to happen on the screen, so, unless you know that the dataset is large and will take a while to load, showing the progress indicator immediately is overkill. Users interacting with the screen takes me to my next point. To be fair, this implementation can be complex when you think about it. It’s easy to hide a progress indicator in your API callback and then transition to an other screen. It’s a lot harder to hide the progress indicator, wait for some period of time if 1 second has not passed, or wait for 1 more second to make your life easier before using the loaded data to transition to an other screen.
What happens when the user taps on something
These days in Android, when a user taps something, the ripple effect on the item clicked is almost expected on Android, or atleast some form of feedback is a must no matter what platform you are on. Yet, I still see buttons and link that show no indication that they were tapped on, or are being held down. This makes the user immediately anxious. If something doesn’t happen on the screen immediately, the user assumes that this is a fat finger problem and taps again. This results in the second issue, what does the disabled state look like for buttons and links? When the user taps on something, to prevent a double tap issue, you want to do one of 2 things. Either show a blocking progress indicator which is an anti-pattern and strongly discouraged. Or you want to disable the button to prevent the user taping a second time. If you choose to disable the button/link/area, you don’t have to change the UI of the thing tapped, but you should definitely think about whether that is needed. If you do disable a button, you also have to keep in mind that you’ll need to enable the button again if an error occurs, or if the user navigates to an other screen, then returns to the first one. You know what happens when a user taps an text entry field? A soft-keyboard comes up. And this brings us to our next point.
What does the screen look like when they soft keyboard is raised?
I can’t emphasise this point enough. When the soft keyboard comes up, should your screen resize or should it pan? If the screen resizes, will content that previously did not need to scroll, now need to scroll? Is the content on the screen readable when the size of the screen is extremely small? Should the ActionBar/Toolbar still be visible? Because the Toolbar then takes up a lot of space on the screen. There are a whole number of issues that can come up when the screen size shrinks and the issues can be unique to your app or the screen. For example, the Medium app, while editing, keeps the formatting options on top of the keyboard. It would be a terrible user experience if they didn’t. The only tip I have here is that if the keyboard can come up on a screen, test it on as many different screen sizes as you can. Pay special attention to any buttons that need to be clicked or navigated to after the fields are filled out. You know what people do in text input fields? Type a lot, this brings us to our next point.
What should by text input length be?
This is a solved issue on the web. I don’t think anyone would dare put up a webapp without limiting the size of the text input fields. However, on mobile, while developers are good about limiting what can be input into a field, they rarely limit the number of characters that can be typed in free text input field. Don’t get me wrong, mobile devs will often limit fields like pin entry, username, password etc. However, something like “leave a comment” is often ignored. This often is not damaging as api’s tend to perform sanity checks. This applies not only to the number of characters that can be typed, but also to the how many lines an input field is allow to grow before you have to scroll the text in it. It can be argued that this is often left out because developers are not told what the limits should be. You know what happens when a user inputs a lot more text than you expect? You have to display it.
Text is longer than shown in the UI designs
Often, we get these pretty designs, everything fits perfectly, and then you have this one field that has text either much, much longer than anything in your designs, or much, much shorter. With longer text, should we wrap to multiple lines? How many lines do we want before we truncate? Do you want a soft or a hard truncate? Do you want a “more” option to show the rest of the text. If your text is centred, does your text look like it’s centred properly? If we wrap lines in centred text, is the whole thing centre aligned or left aligned. How does the rest of the screen flow in all of these conditions?
While the problem with long text is obvious, problems caused by short texts are often not. Having text shorter than expected can make a screen look empty. It can cause other elements on the screen to shift, or if you are scaling text to fit, cause gigantic size text. If you have a wrap content link or button, it can mean that the text or button is hard to click.
These are just an example of some of the things that I wish people would think more about when designing or developing an app. Do you have a peeve when it comes to app design? Share it in the comments.
Finally
In order to build great Android apps, read more of my articles.
