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. This post focus on navigation and positioning of information on the different screens, alongside with tips and trick to make your views responsive.
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 on 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:
- The home or launchpad where you can see the categories
- List of notes on a category
- List of pictures on a category
- View to edit notes
- View to take photos
Then with these screens you should define the relationship between them, defining which views ban 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 an 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:
Instead a better approach is 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 adding horizontal navigability to access related information. In this case the notes and pictures are related with 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 very 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 tickmarks 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 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 screens 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 by 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. Using this the form will resize when the user rotates the device.
Making an object resize is not enough to make a screen responsive. Following with 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 a xml to a screen size, you only have to save it on a different folder.
For instance, think you want to have a different layout for tablet. On 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:
- normal (default)
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:
- ldpi: low density (~120dpi)
- mdpi: medium density (~160dpi) (default)
- hdpi: high density (~240dpi)
- xhdpi: extra high density (~320dpi)
- xxhdpi: extra extra high density (~480dpi)
- 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.
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.