Android UI best practices

In this post, you will see a general guide to make your Android app’s UI more intuitive and, of course, make it look better. It is focused on navigation and positioning of information on the different screens, alongside with tips and trick to make your views responsive.

Navigability

Defining the workflow

One of the most important parts when designing an Android UI (and any mobile App in general) is the navigation between screens. It should be intuitive and follow the information model that you are using. To make it easier, let's start with an example:

Think for a moment that you are trying to develop an app which allows you to take notes and photos which can be categorized into folders.

As it was mentioned above, the screens should follow the “information model”, which is the way the information is stored. In this case, you would have as follows:

As you can see here, the user can create either pictures or notes, and both of them are stored on categories.

After defining the model, a good start is to list all the screens you will be needing. For this example the list would be something like this:

1. The home or launchpad where you can see the categories
2. List of notes on a category
3. List of pictures on a category
4. View to edit notes
5. View to take photos

Then with these screens, you should define the relationship between them, defining which views can be directly reachable from the others. Following this example, the diagram would be like this:

With this, you have the navigability defined. Now let's start with the screen design.

Designing the screens

An important thing when designing a UI for Android devices is managing the white space, especially when the app will be used with a multitude of screen sizes and resolutions.

In this example, you will have a list of folders, which will only have a name. But the notes and the images may have a summary or a description. So, if you make separate views for each of them, it may look like this:

   

A better approach might be to make a single screen with multiple fragments, as shown here:

Then, depending on the minimum screen size your app supports, you can make one of the views collapsible or not.

Another good thing you can do is to add horizontal navigability to access related information. In this case, the notes and pictures are related to the category so you may add a link between them. You can link them by simply using buttons, or in a more sophisticated and correct way, using tabs. Then you would have something like this:

Using tabs is common when designing horizontal navigability, but for things with few items, less than 4 or 5 at most. If you want to let the user navigate to any of the screens, tabs should have names. However, if you want to show steps like when writing information for a sign in, you should use tick marks and use swipe views.

Now, using lists is a good way to show text information, but if you want to show images a list is not the best option. When you use a list you waste too much white space, especially if landscape mode is enabled. The best approach is using a grid or a carousel, depending if you want to show the pictures all at once (grid) or one by one (carousel). Here you see it in the example:

   

After taking all of this considerations the initial diagram has to turn into this:

Responsive screen design

Use of “wrap_content” and “match_parent”

Something important when designing an Android UI is allowing the views to resize accordingly to the screen's size, which can be from 3’’ phone to a 10’’ tablet. Even when just rotating the device the size of the visible view changes completely. So a good practice is to allow the device to resize the objects instead of giving them a fixed size in pixels. In order to do this, Android implements the wrap_content and match_parent values which can be set to either the width or the height of an object.

For example, this can be used in a form for signing in, which is composed of a list of TextViews (with the name of the field), followed by an EditView to write the value. To fill the white space and make the form tidier, you may set the name’s width to wrap_content and then the field’s to match_parent. By using this, the form will resize when the user rotates the device.

Size classifier

Making an object resize is not enough to make a screen responsive. Following the last example, if you make the form fill all the view it will look good on a 3’’ and 4’’ phone, but on a tablet, it will be too long. 

In order to avoid this, you can use size classifiers, which allow you to define different layouts for different screen sizes. It is very simple to assign an XML to a screen size, you only have to save it in a different folder.

For instance, think you want to have a different layout for a tablet. In this case, you may use the large classifier, which changes when the screen is bigger than 7’’. So, after the layouts are made, you save the default one on res/layout/example_layout.xml and the other one on res/layout-large/example_layout.xml. You need to remember that both files must have the same name.

Then when referring to the example_layout resource, Android will automatically look for the adequate file. The available sizes are:

1. small
2. normal (default)
3. large
4. xlarge

Also, if you want a more precise size, you can define the layout for a specific screen dpi instead of a screen size. The densities you can use are the ones listed below:

1. ldpi: low density (~120dpi)
2. mdpi: medium density (~160dpi) (default)
3. hdpi: high density (~240dpi)
4. xhdpi: extra high density (~320dpi)
5. xxhdpi: extra extra high density (~480dpi)
6. xxxhdpi: extra extra extra high density (~640dpi) (It is recommended to use this size only for the launcher).

All of this classifiers can be used not only for the layouts but for all the resources. In general, the size qualifiers are used for the layouts and the density qualifiers for the mipmaps and drawables.

Object sizes

Not only the bitmaps and layouts can be classified according to the density or screen resolution, but all the objects on a layout. For this, you have at your disposition special sizes for the text and objects on a layout, which are the sp and dp modifiers.

The first one is used on text sizes and the other one for object properties, like width, height or margins. Both define a size depending on the screen density.

Congrats! Now you have the tools to make your app look better and more professional.
If you want, you can see an example here.

Read More

Starting with Mobile Development

The mobile development area is one that grows stronger and stronger each day. As such, many different applications have appeared on the mobile stores, and many others are requested by different corporations. This creates a wide variety of styles, ways of use, and general functionality of the different applications. But no matter what type of App you are making and for what purpose, there are some practices that any mobile App should follow or at least consider.

Audience and platform standards

When starting a project a mobile developer needs to consider the following questions: “Who am I developing for?” and “For which platform am I developing for?”. The first question is similar to what developers in other environments would ask themselves, to make sure the application is useful for the final user and that he can use it intuitively. But the second question is something that is seldom thought about the first time.

Even if we just consider the two biggest mobile OSs (Android & iOS), there are notable differences in how the end user expects the App to behave, how it navigates between screens and even how it looks. Both Google and Apple have substantial information about how to design Apps for their platforms, and even when developing the same App for both we need to consider how to comply with their respective guidelines. And this rarely can be achieved with a single unique solution. It is important to understand the core principles of the target platform before deciding on a possible solution or design option. Only defy these guidelines if you have an extremely good reason to do so, and this reason is specific to your App.

This problem is particularly important for mobile developers who use hybrid solutions to develop once for both (or more) platforms. It is not uncommon for this types of solutions to have one design for each platform per screen, which in turn hinders the code reusability for the logic of the App.

The risk of not following the standards (or not considering the audience) is mainly of confusing and frustrating the user since he tries to use the App in a way he is used to and it does not respond in as expected. This can then turn into the user uninstalling the App, bad reviews on the stores, and/or general dissatisfaction with this and other related App products.

We can easily see an example of this differences between Android and iOS just by going to the Play Store and App Store respectively. Both feature tabs to show their contents, but Android’s Play Store feature Tabs are at the top and only use text, while Apple’s App Store features the tabs at the bottom of the screen and are a combination of images and text. Even the way to mark which tab is selected differs. On Android, we see that the selected tab is underlined, while on iOS the selected tab is marked with a different color and filling the icon.

    

Design (UI/UX)

The design is the next big consideration for mobile development. This can make or break your App according to how comfortable your users feel with it. As with all applications which need a visual interface, it is important to strive for intuitive and simple design for the user to, almost immediately, understand everything. But mobile development comes with a couple different aspects to consider.

First of all, this point is heavily related to the last section about standards and audience. A user will expect your App to have a look and feel similar to other Apps he uses on his device or that he has used in the past. This helps to make your app intuitive and enhances the user experience.

However, this does not mean that if you need to develop an App for more than one platform you need to make them completely different. The same application on different platforms should behave consistently throughout all of them, even considering mobile Apps that have an associated web App. What the App can do and the workflow of how to do it should be as similar as possible while adapting to the guidelines of the target platform.

Another aspect of UX design to consider for mobile development is the ratio of images to words that are present in your App. Thinking visually is important while designing the App to develop an engaging experience, but words can be easier to understand and explain better what you want to communicate. A key rule is using common icons for common actions, as would be the back arrow to go to the previous screen or a camera icon to take a picture. After that, it is usually good to use images and icons only if they are representative enough of what you want the user to understand, and use words for what you cannot say with images. Show your App to different potential users and try figuring out which images are intuitive and which should be changed for clarity.

Basically, you want not to overwhelm the user with images, and not force them to read unnecessarily. The best way to achieve this balance is not to keep what you think is the best idea, but what your potential users say they understand. You need to make sure they will understand by showing it to them and getting their feedback.

No matter how good your App looks and how intuitive it is, it will fail if it performs poorly. Obviously, this is true for every type of development, but as always mobile development can be a different problem entirely.

With mobile Apps, the user expects an almost immediate response to their actions, and if that is not possible they want to be informed that the action will take time to complete. The most common ways to indicate this are looped animations (for example activity indicators) and percent-done animations (for example progress bars).

When should you use one of these methods and when to use each one? Unfortunately, there is not a perfect way to determine this, but there are some useful tips that can help you decide. Usually, if an action does not take more than a second to complete, no indication of progress is needed for the user. The visual impact of his action will be evident (either by a change on the screen, a change of color, a toast message appearing, etc) shortly and he will not become impatient. Moreover, it can confuse the user if every click he does comes with an indicator even if the response is immediate (like quick navigation or toggle button presses).

If the action takes more than a second, but it is not very long (for example 10 seconds or more), or there is no way of determining how much of the progress is complete or how long it will take (as waiting for an HTTP response), you should use a looped animation, either one that is custom to your App or the usual one for your platform. This makes the user realize that the App is working and not that the click has not registered or that it does not work.

Lastly, if the action takes longer than about 10 seconds, and you can give an estimate of how much time is left or how much of the work is done, you can use a progress bar to show this process to the user. This helps him notice that the action will take a while and can give him an idea of how much time it will be. As always you should check the platform guidelines to ensure you use time indicators correctly.

As a general rule of thumb, always try to optimize your code to respond as fast as possible and show visual progress to the user, notifying him if something is happening in the background to reassure him that the App has not become frozen.

Security

Yes, security is important for all types of development. Yes, as it has been the case in the last sections, mobile development has some extra considerations to take about security as well.

Mobile Apps usually have the feature of communicating heavily over the network, being dependent on the responses and processing that is done server-side. Also, by nature, they are used on devices that are on many different (potentially non-secure) networks. All this without even mentioning that mobile devices are more likely to be lost/stolen, which can lead to information being stolen if mobile developers do not put emphasis on security.

The principal aspects that need to be treated are:

• Encryption for all data that is being shared by the App wirelessly, both incoming and outcoming.
• Backup of user data automatically, to ensure that no data is lost for the user if a problem occurs, of any nature.
• Authentication to ensure that only the destined user sees the information that only he should have access.
• A way to erase information remotely in case a device is lost in any way, to help prevent stealing of data.

Analytics

The last point we will cover in this post is the importance of analytics data on mobile development and applications. Integrating analytics help track your users' activity and how they use your App. This, in turn, can give you information on what aspects of your App are the most popular, the amount of time the users spend on it, and what is the general navigation process that most of your users follow.

This aspect is linked to the audience importance we discussed earlier. Who uses your App and why lets you redesign the App to make it more usable and useful for your users, and evaluate in which areas to focus. There are many analytics tools that can be used on the different platforms, and in some cases, even the platform itself can give you tools for this purpose.

Analytics also helps with finding and fixing bugs, if it is incorporated to send crash logs and different internal data flows. With this, information about the errors in the App can be found earlier and in a more complete way, and also see which ones are the most common and their impact on the user experience.

Exactly which analytics are necessary for your App varies from case to case, but crash logs, navigation flows, device type, time of usage, duration of usage, and user location are usually useful information to have and to process later.

It is important to integrate analytics as soon as possible in the development since the task of adding all the logs to your analytics can be a daunting experience if done all at the same time instead of when it is being programmed the first time.

Other

This post is just a simple recap and is in no way a complete guide for all considerations in mobile development. There are many other aspects that should be considered such as testing, how to know your end users, cloud, etc. without mentioning the guidelines that each platform has for developers. And as always, the experience is invaluable to make the correct decisions when the different problems appear.

We have iOS and Android best practices posts on this blog, which are linked below:

IOS UI best practices
Android UI best practices

References

• Android design guidelines: Design | Android Developers
• iOS design guidelines: iOS Human Interface Guideline

Read More

iOS UI best practices

Apple always has, through every one of its systems and platforms, made a major focus on interface design and user experience, and its users have come to expect it. So, if you want your Apps to succeed in the App Store or just make a great iOS App in general, this definitely is one of the key areas to concentrate on. Luckily, Apple has provided some general guidelines on how to design a good interface, and here we will go over the most important of them and provide some examples at the end to complete this post. Everything goes with the principle of “simple is better” and being minimalist, so even if some things seem kinda evident, remember that the secret is in the basics.

General design

There are a couple aspects of an App that any mobile developer should know before starting to even think about coding and designing. Users will most likely decide if they like your App or not after just a couple seconds, and every little visual aspect will influence this decision. Mobile users are usually really temperamental with the Apps they try out, uninstalling them just according to their first impression, so you need to make it count.

Knowing this, the first screen is usually one of the key points in your App you want to focus on. As a general rule, the home screen should guide the user to how he should use the App, showing the most important information and giving the user options to go to almost anywhere in your App in an instant. Following this, intro screens that just serve a purpose to say what the App name and provide a button to continue do not follow Apple good practices. The user already knows which App is the one they opened, and just giving them the obligation to go through one more screen and one more button press to just start using the Application is not a good idea. Remember that they will see this screen every time they open it, especially the first one, and you do not want their first opinion to be “how annoying this is”.

Another aspect of design that has to be kept in mind is how or if you should prompt the user to rate your App. As a general rule, prompting the user to rate your App is a bad idea. Developers usually do this on impulse, since if you ask the user to do it you will most likely get more rates on the store, and this can, in turn, improve its position, but that is just one side of the coin. Remember that your user first wants to use your App for one purpose, and that is not to rate it. If the user is constantly asked to rate an Application, he will most likely start getting angry with this message, or just ignoring it completely depending on how intrusive it is. And, in the worst case, you do not want an angry user to be the one that reviews your App.

 

Stylish choices are good (and sometimes necessary) for some Apps, but remember that it should not in any way hinder the core purpose of your App. If you do “something” that makes your App look a little bit nicer, but it makes the App a little harder to use or a little more frustrating, it probably is not the best of ideas. 

Another aspect of the general design is to adjust to as many conventions as possible, especially when related to functionality. Apple provides many types of buttons and button images to guide the user to what each button does, and developers should really try to adjust to this. For example, if the users see a trash icon, he will assume this is for a delete functionality, as well as if he sees a curved arrow pointing to the left it most likely that corresponds to a “reply” action. UI is the best way to guide the user in your App, and a UI design that does this in the best way is one that follows UI conventions.

Layout

Chances are you will want to show many options, test, or possible actions on one screen. However, this can potentially be confusing for your final user if it is not organized properly. Luckily for us, Apple already fixes some of this issues by providing controllers and some minor restrictions to UI elements (like how the Tab Bar is at the bottom), ensuring they are used in a common and structured way.

However, many other options are left for us developers and designers, and a little thinking on the general layout and positioning of elements can go a long way.

Structure

To start with the layout, it is important to understand that screen space is one of the most important assets the UI designer has and should be used thoughtfully. This does not mean you should just fill the entire screen or leave everything in one corner. Empty or background space is an indispensable tool for design, and almost a necessity for the user to not be overwhelmed with information. 

Following this concept, things that just take up space for the sake of being there (like borders to your application) should be avoided. There may be some exceptions to this general rule, but unless you have a really good reason you should follow it. Although users like to see an appealing design and feel comfortable, it can annoy them to focus on a smaller screen than the one they could use if that border was not there. A clean appearance is usually the best appearance. 

Another aspect that should be considered is where the different elements are positioned inside the screen. The first rule here is a somewhat easy one but sometimes forgotten in favor of stylish design. Always remember to highlight the most important functionality. When a user reaches a screen in your App, chances are you have a pretty good idea as the designer to what he wants to do or where he wants to go next. As such, the thing that is most likely to be needed should be at the top and highlighted with some color, image or with another method.

Imagine you have a really long scroll screen, and the option you almost always want to press is at the bottom. The first time you see this screen you will need to read everything before finding what you were looking for, and all the following times you need to keep scrolling to the bottom even if you know exactly what you want. Design should follow the desired functionality, and not the other way round.

Buttons

Let’s stop a little bit now with one of the most common elements in UI, buttons. Buttons are almost a necessity for development if we want the user to select when he is ready to perform a certain action or follow a determined flow. How the buttons visual can vary from App to App, maintaining the general Application aesthetic, but the important part is that it needs to be focused on its purpose. Buttons are for being pressed, and therefore should be easy to press. This section also applies to any other UI element that is meant to be pressed.

 

In order to achieve this, there are a couple of basic rules that should be followed:

• Buttons should be big enough for the user to press them without missing. Buttons that are too small tend to confuse the user after they try to press them and miss them, not knowing if their touch registered.
• Make sure buttons have some distance between themselves. Having many buttons next to each other can generate problems if the user misses, forcing the App to do something other than what the user intended.
• Buttons need to be evident. If you make a custom button and the user does not recognize it is a button, it was definitely not a good design choice.

Fonts

The text is likely to be prominent in your App since it is one of the most effective tools a designer has to convey meaning and guiding the user through all options and information. Being such a vital (and somewhat simple) tool, it is important it is as refined as possible.

Some key aspects to keep in mind about fonts are the following:

• Think about the size of the text in your App. Too small font sizes should be avoided, to make sure the user is able to read all text comfortably (Apple suggests a size of at least 11px).
• Be careful when considering font color. A key color is recommended, used in your App to draw attention to certain areas. If too many are used the user may be overwhelmed and the attention will be divided into many different areas instead of focused on one thing, which would be the thing the user wants to see.
• Do not use many types of fonts in any App, except for very specific reasons. Using many types of fonts will confuse the user, and direct his attention almost randomly through each screen. Also, the user will need to adjust every time the font changes to understand it. This is likely to cause frustration and rejection towards the App.

 

If the user feels comfortable reading what you have to say in your App, it is much more likely he will keep using it for longer. Obviously, no one is going to use an Application just because it has some nice fonts, but someone can easily uninstall it if he finds the visually shocking. Remember that mobile users are prone to delete an App after just a couple of seconds if they do not find it nice.

Feedback

The last aspect we will cover in this post is the importance of notifying the user about what the Application is doing in the background. Mobile applications have many reasons to take some time before finishing a process. Motives can range from fetching data remotely to heavy algorithms run on not so powerful devices. This cannot be always avoided, but it may not be so bad for the final user if done correctly.

The first thing is knowing approximately how much time a given process will take. If it is an immediate action, and the user will be immediately informed that the action ended (like with navigating to another screen or removing a field) this is not so important. In fact, informing him something more in this cases can be actually confusing for them. However, if the action is quick but does not give the user feedback in itself (like adding data internally), the user should be informed in some way, like with a message, that the action has been completed. If not, the user may try doing the same action again, maybe giving more problems than intended in the long run.

On other actions that take a couple more seconds, a little more planning is in order. Hiding buttons after the user has clicked them is a common strategy, as well as showing the default Activity Indicator from Apple. This informs the user immediately that the App has received his input, and is working accordingly. The animation of the Activity Indicator (or any other indication you wish to give them) is key here, since otherwise, the user may think the App has frozen.

If the wait for the user is especially long, more powerful actions should be taken. Leaving space for progress bars and finding a way to inform the user before he starts the lengthy process is vital. The user wants to be informed that he will have to wait in order to decide if he wants to do what the App allows him to. If this is not the case, you run the risk of the user closing the Application, maybe even thinking that the App is broken or buggy.

One other aspect that is important to mention when talking about how to give feedback to the user, is that feedback should not only be given to this kind of processes. A way to clearly indicate the user that an option has been selected or that certain mode is in effect is also a necessity. A good example of this is the tab bars that come natively with iOS since they have a different color and icons for when they are selected as opposed to when they are not.

Conclusion

This was just some of the many recommendations Apple provides for designers, but some of the most important of them. Many of them may be evident to designers, especially to designers with experience, but can be really disastrous if not applied correctly. If you want to see the difference that it makes to follow these or nor, please check our GitHub repository for iOS UI Best Practices.

References

iOS Design guidelines: UI Design Do’s and Don’ts
Our post of Mobile Best Practices
GitHub link: iOS best practices
Example code: iOS-UI-best-practices on our GitHub

Read More