Designing mSupport For Android
One of the best uses of smartphones and small tablets is for mobile performance support (mSupport). The size and convenience of small devices are sensible mediums for providing assistance throughout the day.
If you’re interested in native apps—those that reside on the phone—it helps to understand the differences and similarities when designing for different mobile operating systems.
I recently modified the design of my reference and support app, Instructional Design Guru, so it can run on Android devices. Although this is my first experience with Android, I can offer you what I’ve learned to save you time and effort. Here are some of the differences I’ve found when designing a native app for the two.
User Interface in Practice
One of the first things I looked for were design patterns in the user interfaces of Android reference apps. Android apps had more user interface variations than I expected. There is no approval process to get an Android app in an app store, so perhaps there is less motivation to follow guidelines.
Apple, on the other hand, has a strict review process before it allows an app into iTunes. Some will see the Android approach as leaving lots of room for creativity; others may dislike the inconsistency between apps. Note the differences in the design of the four Android reference app examples below.
Some Android UI Components
I was pleased to see that the Android documentation is more detailed than the last time I checked. There are a lot of solid design guidelines explaining the components of the UI and suggesting the best ways to use them (see Resource links below). After reading the guidelines, the variations in the UI designs shown above started to make a little sense, even if I didn’t agree with all of the implementations.
I was particularly interested in the guidelines for the action bar, where much of the functionality resides. Whereas the iPhone uses a tab bar at the bottom, Android phones use a main action bar at the top. The action bar is important for designers to understand.
- Area 1 – The icon provides app identity. When the left arrow next to the icon, called an “up” arrow, is tapped, it moves users up through the app’s hierarchy. Not stated in the guidelines is that tapping the icon in some apps takes you to its home screen.
- Area 2 – This segment of the action bar provides functionality for different views. It was too crowded for me to use this area.
- Area 3 – The guidelines recommend showing the most important actions of your app here.
- Area 4 – The three dots represent the action overflow. When tapped, the less important actions display.
One problem I see with this arrangement is that the back button is supposed to display in area number 3. In languages that read left to right, it seems more natural to have the back button on the left side of the action bar.
Split Action Bar
There is also the option of splitting the action bar into three regions, as shown below.
- Area 1 – Main action bar.
- Area 2 – Top bar: use for changing views with tabs or a spinner.
- Area 3 – Bottom bar: display additional actions and the action overflow, if needed.
Contextual Action Bar
Android also has the capability for displaying a contextual action bar, which “overlays the app’s action bar for the duration of a particular sub-task. CABs are most typically used for tasks that involve acting on selected data or text.”
Differences in Search UI
In both mobile operating systems, selecting the Search function displays a field for entering a term. When the keyboard displays on the iPhone, the tab bar at the bottom disappears. On Android phones, the bottom bar displays in the middle of the screen above the keyboard. In some Android apps, the functions on the action bar move from the bottom to the main action bar.
Although I’m not doing the programming myself, it’s important to know that an iOS programmer may not do Android development and vice versa. Native iPhone apps are typically coded in Objective C and Android apps are coded in Java. Yes, there are hybrid approaches too, but that’s a different story. See the resource link for Phone Gap at the end.
Performance support apps are often based on a database, such as MySQL or SQLite. It’s ideal if the same database can be used with both mobile operating systems. This saves development time and costs.
Instructional Design Guru for Android
Now back to the Instructional Design Guru implementation. After much back and forth, I realized I could not place the tabs for ID Guru at the top, as recommended in the guidelines. I needed the top bar (below the main action bar) for titles, so I placed the tabs at the bottom. Here is a comparison of the UI design for both apps.
- Instructional Design Guru for Android ($4.99)
- Android Developer Guidelines (Be sure to see the Design section)
Get The eLearning Coach delivered to your Inbox twice a month, with articles, tips and resources.