Designing For Android Tablets

Advertisement

More than ever, designers are being asked to create experiences for a variety of mobile devices. As tablet adoption increases and we move into the post-PC world, companies will compete for users’ attention with the quality of their experience. Designing successful apps for Android tablets requires not only a great concept that will encourage downloads, usage and retention, but also an experience that Android users will find intuitive and native to the environment.

The following will help designers become familiar with Android tablet app design by understanding the differences between the iPad iOS user interface and Android 3.x “Honeycomb” UI conventions and elements. We will also look at Honeycomb design patterns and layout strategies, and then review some of the best Android tablet apps out there.

Note that while Android 2.x apps for smartphones can run on tablets, Android 3.0 Honeycomb was designed and launched specifically for tablets. Future updates promise to bring Honeycomb features to smartphone devices, as well as make it easier to design and build for multiple screen types.

For most of us, our first exposure to tablets was via the iPad. For this reason, it’s reasonable to begin comparing the two user interfaces. By comparing, we can align what we’ve learned about tablets and begin to focus on the key differences between the two, so that we can meet the unique UI needs of Android users. Not only will this help us get up to speed, but it becomes especially important when designing an Android tablet app from an existing iPad one.

It’s Just Like The iPad, Right?

While the Android tablet and iPad experience share many similarities (touch gestures, app launch icons, modals, etc.), designers should be aware of the many differences before making assumptions and drawing up screens.

Screen Size and Orientation

The biggest difference between the two platforms is the form factor. Layouts for the iPad are measured at 768 × 1024 physical pixels, and the iPad uses portrait mode as its default viewing orientation.

With Android tablets, it’s a bit more complicated, due to the multiple device makers. In general, there are 7- and 10-inch Android tablets screen sizes (measured diagonally from the top-left corner to the bottom-right), with sizes in between. However, most tablets are around 10 inches.

What does this mean in pixels? A good baseline for your layouts is 1280 × 752 pixels (excluding the system bar), based on a 10-inch screen size and using landscape (not portrait) as the default orientation. Like on the iPad, content on Android tablets can be viewed in both landscape or portrait view, but landscape mode is usually preferred.


The portrait view on a typical 10-inch Android tablet (left) and on the iPad (right).


The landscape view on a typical 10-inch Android tablet (left) and on the iPad (right).

However, with Android, screen size is only the half of it. Android tablets also come in different “screen densities” — that is, the number of pixels within a given area of the screen. Without going into too much detail, designers have to prepare all production-ready bitmaps for three different screen densities, by scaling each bitmap to 1.5×and 2× its original size. So, a bitmap set to 100 × 100 pixels would also have copies at 150 × 150 and 200 × 200. By making three batches of graphics scaled at these sizes, you will be able to deliver your bitmaps to medium, high and extra-high density tablet screens without losing image quality.

For more information on screen densities and preparing graphics for Android devices, refer to my previous article on designing for Android.

System Bar

While iOS makes minimal use of the system bar, Android Honeycomb expands its size to include notifications and soft navigation buttons. There is a “Back” button, a home button and a “Recent apps” button.


The Android Honeycomb system bar.

Android Honeycomb’s system bar and buttons are always present and appear at the bottom of the screen regardless of which app is open. Think of it like a permanent UI fixture. The only exception is a “Lights out” mode, which dims the system bar to show immersive content, such as video and games.

“Back” Button

While the bulkiness and permanence of the Honeycomb system bar might seem an obstacle to designers, it does free up the real estate that is typically taken by the “Back” button in iPad apps. The “Back” button in Honeycomb’s system bar works globally across all apps.


The “Back” button in the system bar.

Action Bar

The bulk of the UI differences between platforms is found in the top action bar. Android suggests a specific arrangement of elements and a specific visual format for the action bar, including the placement of the icon or logo, the navigation (e.g. drop-down menu or tabs) and common actions. This is one of the most unifying design patterns across Android Honeycomb apps, and familiarizing yourself with it before attempting customizations or something iPad-like would be worthwhile. More on the pervasive action bar later.


The action bar.

Widgets

New to iPad users will be Android’s widgets. As the name implies, these are small notification and shortcuts tools that users can set to appear on their launch screen. Widgets can be designed to show stack views, grid views and list views, and with Android 3.1, they are now resizable.


Several widgets on a launch screen.

Notifications

While iOS’ notifications system pushes simple alerts to your launch screen, Honeycomb offers rich notifications that pop up (“toast” we used to call them) in the bottom-right area of the screen, much like Growl on Mac OS X. Custom layouts for notifications can be anything from icons to ticker text to actionable buttons.


A notification on Android.

Settings

Access to settings in an iPad app are usually presented in a pop-over, triggered by an “i” button; and settings categories are broken up into tables for easy visual identification. Honeycomb has a different convention. It looks more like the iOS’ “General Settings” screen, where the user navigates categories on the left and views details on the right. This is the preferred (and more elegant) way to present multiple settings in Honeycomb.


The settings design pattern in the Calendar app.

UI Elements

As you can imagine, Android goes to great lengths to do everything opposite from its competitor (that’s called differentiation!). Honeycomb has its own UI conventions, and it now has a new “holographic UI” visual language for such routine actions as picking a time and date, selecting an option, setting the volume, etc. Understanding this UI language is important to building screen flows and creating layouts.


A sampling of UI elements, taken from a slide in a Google I/O 2011 presentation.

Fonts

How many fonts does iPad 4.3 make available? The answer is fifty-seven.

How many does Android? Just three.

Yep, those three are Droid Sans, Droid Serif and Droid Sans Mono. But there is an upside. While only these three ship with the platform, developers are free to bundle any other fonts with their apps.

Anything the Same?

Luckily for designers who are already familiar with the iPad, the two platforms have some similarities.

Touch Gestures

Tap, double-tap, flick, drag, pinch, rotate and scroll at will.

Split View and Multi-Pane UI

The split view is one of the most common layouts for tablets. It consists of two side-by-side panes. Of course, you can add panes for more complex layouts.


Ustream’s split-view layout, with categories on the left and content on the right.

Embedded Multimedia

Both platforms allow embedded audio, video and maps.


The YouTube app, with an embedded video player.

Clipboard

For copying and pasting data into and out of applications.

Drag and Drop

Both platforms have drag-and-drop capabilities.


The drag-and-drop feature in the Gmail app.

Design Patterns

Honeycomb continues many of the design patterns introduced in Android 2.0 and expands on them. In case you’re not familiar with design patterns, they are, as defined in Android, a “general solution to a recurring problem.” Design patterns are key UI conventions designed by Android’s maintainers to help unify the user experience and to give designers and developers a template to work from. They are also customizable, so no need to fret!

As mentioned, the action bar is the most prominent Android UI component and is the one we’ll focus on here.


The action bar highlighted in the Calendar app.

Icon or Logo

The action bar starts with an icon or logo on the far left. It is actionable; by tapping on it, the user is directed to the app’s home screen.


The Calendar app icon.

Navigation

Next, we’ll typically find some form of navigation, in the form of a drop-down or tab menu. Honeycomb uses a triangle graphic to indicate a drop-down menu and a series of underlines for tabs, which typically take up most of the action bar’s real estate.

A left arrow button might also appear to the left of the icon or logo or the label, for navigating back or cancelling a primary action.


Three different kinds of action bar navigation.

Common Actions

Common actions, as the name implies, gives user such things as search, share and an overflow menu. They are always positioned to the right of the action bar, away from any tabs.


Common actions in the Calendar app.

Overflow Menu

The overflow menu is part of the common actions group and is sometimes separated by a vertical rule. It is a place for miscellaneous menu items, such settings, help and feedback.


An overflow menu.

Search

Search is also a part of the common actions group. Unique to search is its expand and collapse action. Tap on the search icon and a search box expands out, letting you enter a query. Tap the “x” to cancel, and it collapses to its single-button state. This is a space saver when many actions or tabs need to be shown.


The search function collapsed (top) and expanded (bottom). Tapping the magnifying glass opens the search box, while tapping the “x” closes it.

Contextual Actions

Contextual actions change the format of the action bar when an item is selected, revealing options unique to that item. For example, if a photo app is displaying thumbnails, the action bar might change once an image is selected, providing contextual actions for editing that particular image.

To exit the contextual action bar, users can tap either “Cancel” or “Done” at the far right of the bar.


The contextual action bar is triggered when tapping and holding an email in the Gmail app.

Tablet Layout Strategies

Using Fragments and Multi-Pane Views

The building blocks of Honeycomb design are “Fragments.” A Fragment is a self-contained layout component that can change size or layout position depending on the screen’s orientation and size. This further addresses the problem of designing for multiple form factors by giving designers and developers a way to make their screen layout components elastic and stackable, depending on the screen restraints of the device that is running the app. Screen components can be stretched, stacked, expanded or collapsed and shown or hidden.


The Fragments framework gives designers and developers several options for maintaining their layouts across screen sizes and orientation modes.

What makes Fragments so special? With a compatibility library, developers can bring this functionality to Android smartphones going back to version 1.6, allowing them to build apps using a one-size-fits-all strategy. In short, it enables designers and developers to build one app for everything.

While Fragments may be a term used more by developers, designers should still have a basic understanding of how capsules of content can be stretched, stacked, expanded and hidden at will.

The most common arrangement of Fragments is the split view. This layout is common in news apps and email clients, where a list is presented in a narrow column and a detailed view in a wider one.


The split view used by USA Today

Another way to present a split view is to turn it on its side. In this case, the sideways list Fragment becomes a carousel, navigating horizontally instead of vertically.

Orientation Strategies

While Fragments are great for applying one design to multiple screen sizes, they are also useful for setting orientation strategies. Your screen design might look great in landscape view, but what will you do with three columns in a narrow portrait view? Again, you have the option to stretch, stack or hide content. Think of Fragments like a bunch of stretchy puzzle pieces that you can move around, shape and eliminate as needed.

A Word About Animation

The Honeycomb framework allows designers and developers to use a variety of animation effects. According to the Android 3.0 Highlights page, “Animations can create fades or movement between states, loop an animated image or an existing animation, change colors, and much more.” Honeycomb also boasts high-performance mechanisms for presenting 2-D and 3-D graphics. For a good overview of what Honeycomb is capable of, check out this video.

Learning from Example

Android tablet apps are still a relatively new space, and some brands are only beginning to test the waters. Below is a list of apps for inspiration. You can download any of them from the Android Market or Amazon.

YouTube
Naturally, Google’s YouTube app for Honeycomb is exemplary, showcasing all of the design patterns and UI elements discussed above. To get a good feel for Honeycomb, download this app first and take it for a spin.

CNN
The CNN app makes good use of touch gestures (including flicking to view more content), the split view and fonts! A custom font (Rockwell) is used for news headlines.

CNBC
Another good news app, with animation (the stock ticker tape) and rich graphics and gradients. CNBC has one of the most visually compelling apps.

Plume
With its three-column layout, Plume is a good example of how layouts might need to be changed dramatically from landscape to portrait views.

FlightTrack
A data-heavy app done elegantly. Includes nice maps, subtle animation and standard Honeycomb UI elements.

Pulse
What else can you say: it’s Pulse for Android tablets! But comparing the Android and iPad versions, which are identical in almost every way, is still fun anyway.

WeatherBug
This was one of the first Honeycomb apps in the Android Market. It makes good use of maps and of the holographic UI for showing pictures from weather cams.

Kindle
Kindle pretty much sticks to the book in using design patterns and Honeycomb UI elements. The outcome is elegant, while staying true to Android’s best practices.

Honorable Mentions

  • IMDb
  • News360
  • USA Today
  • AccuWeather
  • Ustream
  • Google Earth
  • Think Space

Online Resources

Video

Presentations

Blogs

Android Developers

(al)

Born and raised in Silicon Valley, Daniel McKenzie is a digital product designer helping startups and companies strategize and design products that matter. He also likes to write and tweet (@danielmckenzie) on various design and innovation topics.

  1. 1

    Thanks Dan, really a helpful article…

    -1
  2. 2

    Johnny Simpson

    August 9th, 2011 6:42 am

    This is very interesting! I actually recently got an iPad, I assume its the same deal, and the website I’m working on works great on it using media rules. God bless CSS3!

    +1
    • 3

      PixelTunnelVision

      August 9th, 2011 2:10 pm

      I think this article is geared more so toward making actual Android apps, not websites.

      p.s. Anyone on an even remotely older browser won’t be able to see your media queries. Don’t rely entirely on HTML5 and CSS3 just yet.

      -3
      • 4

        Gotta keep up the game, the use of css3 and media queries are supported by every device that matters and are mostly used. So its entirely safe to use that for responsive sites. And besides that – there are plenty of ways to get it working even on old browsers like old explorer versions.

        So my advise to you: keep up :)

        0
  3. 5

    Problem is that Android tablets don’t sell and Android users don’t like spending money on apps which means that unless you’re developing free apps, you’re screwed.

    0
    • 6

      That’s what people said about Android OS for phones too and now it has the largest market share. If you wait until something is on top, then you’re behind the curve.

      Great article Dan! There are plenty of articles on how to develop for the iPad, it’s nice to also see how to develop for Android. I’d like my product on as many devices as possible.

      0
    • 7

      Jamie Nordmeyer

      February 24th, 2012 7:51 pm

      I own an Eee Pad Transformer and an HTC Incredible, and have bought several apps for them. My favorite is Markups.me, which is a UI prototyping tool (I’m a web developer).

      0
  4. 8

    I appreciate the authors knowldege on the subject, and this is a well written article. Except, I wonder if next in the series is “Luiqidating your dev company after developing Android tablet apps”.

    It’s a great article, if you ignore the fact that there is no commercial market for Android table apps.

    If you’re toying at it great, but I really don’t think that anyone is going to make any money from Android tablet apps for some time to come.

    0
  5. 9

    Great article!

    People saying it’s stupid developing apps for Android are idiots. Serioulsy guys…

    0
    • 10

      No Pedro, it’s stupid to make apps for Android tablets. The number of devices in consumer hands is so small that commercial development of apps for it is business suicide.

      And to those who voted down my first comment – can anyone show me anyone that is making a living from selling apps for android tablets (and please note the word tablet).

      It’s not always going to be this way, but Android is nowhere in tablet land right now and I don’t see it changing for a few years.

      -1
      • 11

        Its funny but the people who are early adapters are usually the one’s who end up making all the money when a device takes off. The first major Andriod tablet only came out the beginning of this year and the new Galaxy (which in my opinion is the first to be as good as or better than the iPad) is now only a few months old. I mean seriously, did developers wait to start creating apps for the iPad until it had a large enough user base? Nope… definitely not, and I am sure that they made they’re money once it took off.

        Are you even aware there are more activated Andriod devices than iOS? Have you even paid attention of what is to come for iOS 5 and Ice Cream Sandwhich? I suggest you look into Google future release of Ice Cream Sandwhich and even the Andriod Home technologies they are developing because it is truly some new and innovative stuff. While Apple’s iOS 5 on the other hand basically steals all of the functionality details currently in use on Honeycomb such as threaded mail, notification center, and iCloud (Google Music).

        Also I would like to add that I am both an Apple and Andriod user and love all of my devices, but I expect the company that had a several year head start to be the one’s ahead of the game and not the other way around. If Google is already pulling ahead in development in under a year, than imagine how far they could go in 2 or 3 years…

        If you ask me, it’s not stupid to develop Andriod tablet apps, it’s stupid not to see the potential money you can make by starting your development now. But, you know what? Keep thinking the way you do, because it allows developers who think ahead of the game to make more money…. leaving the stragglers with scraps…

        0
        • 12

          I don’t think anyone is disputing the fact that there are more Android devices than iOS. The simple fact is that Android owners don’t spend any where near as much money as iPhone/iPad owners.

          In 2010, $102 million was spent on the Android Market. On the Apple App Store it was $1.7 billion.

          Android has a long way to go. By the way, I develop for both platforms, and make much, much more money from the iOS versions of my apps. From a business point of view, buying my iPad was a no-brainer. Will I buy a Honeycomb tablet? No. Maybe a cheap tablet from eBay…

          0
    • 13

      For Android you can develop for any size or type of device within the same app(project), your architecture is just slightly different . This is done by using fragements, you can learn more about it here http://www.youtube.com/android#p/search/0/RfJuigJebRg and it is pretty cool. Not sure how this is done for iPhone/iPad though.

      0
  6. 14

    great article

    it´s still, like in the first days of smag – you wish the article will never end… but it happens… the only negative thing.

    0
  7. 15

    Ben Hernandez

    August 9th, 2011 9:20 am

    This is great, very helpful. Any ide where I could get a good collection Honeycomb GUI elements similar to those Teehan + Lax made for Android 2.3.4?

    http://www.teehanlax.com/blog/android-2-3-4-gui-psd-high-density/

    0
  8. 16

    This is the type of articles Smashing is known for: in-depth, comprehensive and from a professional that deals with these problems, not some list with random resources thrown in there.

    Kudos to Dan and thank you for this great article!

    0
  9. 17

    Great article!

    I would add one small addition to the ‘Navigation’ section.
    The top-left icon with the ‘left pointing arrow’ is described as follows:

    “A left arrow button might also appear to the left of the icon or logo or the label, for navigating back or cancelling a primary action.”

    This icon/button is there for the *’Up’* action.
    This ‘Up’ user-interaction is a somewhat new concept in Honeycomb:

    The well-known ‘Back’ user-interaction (back-key/back-soft-key) usually brings the user back to the screen where (s)he came from.
    The ‘Up’ user-interaction has the purpose of sending the user upwards in the navigation hierarchy of the currently viewed item while (s)he remains in the current application.

    Example:
    The user clicks a widget with an e-mail. The e-mail app is started and the message is shown:
    - The user does ‘Back’: User goes back to home-screen, looking at the widget.
    - The user does ‘Up’: User stays in the e-mail app and is sent to the ‘Inbox’.

    (See “Using the app icon to navigate “up”" section at http://developer.android.com/guide/topics/ui/actionbar.html)

    Note that not all apps implement the ‘Up’ as such. Many implement this as a plain ‘Back’ action (even some of the Google apps.

    0
    • 18

      This inconsistency hopefully -as it really needs to change in ICS -at this time users never reliably know if the icon takes you to the app ‘home entry activity, or back in the activity stack; it’s very unintuitive when not consistent. –The browser is a pet piece of mine as the system level back should navigate you to the previous stack item, not the previous webpage, as there us already a tried and true navigational system for that. Navigational redundancy is bad.

      0
  10. 19

    Excellent article! But you missed one thing. Explain the hybrid nature of layouts these days. As designers need to know what will be “native code” generated UI elements, versus what is being rendered within the webView with CSS and HTML5. Knowing the names the native UI elements is important.

    What about custom listView item design rather then using the default “android.R.layout.simple_list_item_1″

    Listen to design for mobile you gotta learn some code, otherwise you are not designing in a smart way.

    Good looking on the Fragments though!

    0
  11. 20

    Nice article and very useful

    0
  12. 21

    You forgot to add long tapping to the list of touch gestures. It’s a very effective interaction pattern that is specific to Android.

    Also, I think you meant to say “the far left of the action bar” in the “Contextual Actions” section.

    Otherwise, great article. I might point some of our designers to it in the future.

    0
  13. 22

    Safiullah Khan

    August 11th, 2011 6:52 am

    Thanks a lot, Dan. Couldn’t have been any better time to reach to this post. Just yesterday that i got an Android Tablet App design project at work and was searching web to get started.
    The official Android design guidelines page is more directed towards developers and resources for tablets are very few as compared that of Mobiles.

    Would be great if anyone could provide links on layout strategies/patterns for android tablets.

    Happy Computing.

    0
  14. 23

    Good snapshots of a lot of great apps showcasing the Android UI elements, especially for one who hasn’t spent too much time with the devices. A useful followup article though might be one that would be to describe the web version of the example apps (if there are) and contrast the differences between the native apps and the web versions. I think it’s still unclear whether the app-only thinking will eventually become the norm but it’s interesting to see the developments happening on both sides.

    0
  15. 24

    Douglas Bonneville

    August 12th, 2011 9:54 am

    Note to self: don’t develop Android tablet apps. Go fishing instead.

    0
  16. 25

    This is the type of articles Smashing is known for: in-depth, comprehensive and from a professional that deals with these problems, not some list with random resources thrown in there.

    Kudos to Dan and thank you for this great article!

    0
  17. 26

    The best option is develop code to Android and make “phone” and “tablet” version, but using reusable and upgradable code.
    Then you have always both versions updated and with minimum coding effort.

    0
  18. 27

    The honeycomb UI looks neat, problems arise with the clients saying that they need iPad experience (They just want the search bar to look the same capsule type as in iOS), the Page/Screen Title appears at top left to the middle, the menu icon disappears when the overflow list view comes up. Hard to tweak!

    0
  19. 28

    official cheap tory burch sale

    August 25th, 2011 2:36 am

    The wide width dress sandals from Softspots are extremely popular because of the high level of comfort they offer while retaining the style element.

    0
  20. 29

    Hi,
    I’m an designer, working for a local newspaper.
    Seeing the wave of tablets coming up so far, I have decided to learn something about designing a page for tablet
    What tools are required in designing a page for tablet
    Does printing software (which I use, like) QuarkXpress, Adobe InDesign and Photoshop sufficient in designing a page for ‘tablet’.?
    Any tutorial resources
    Thanks

    0
  21. 30

    Remember when people designed for tiny mobile screens? You probably don’t remember because you decided not to do it despite the advice that it will be the future of the web given on sites like this. The browser is and will always be the premier app for the foreseeable future.

    Reasonably design for the desktop and the mobile devices will catch-up with it, if they’re not already.

    0
  22. 31

    Abinaya Sampath

    December 4th, 2011 10:52 pm

    Very Useful article…Thanks Dan…

    0
  23. 32

    Anyone know exact pixel dimensions for a 7″ android tablet? Thanks!

    0
  1. 1

    Johnny Simpson

    August 9th, 2011 6:42 am

    This is very interesting! I actually recently got an iPad, I assume its the same deal, and the website I’m working on works great on it using media rules. God bless CSS3!

    +1

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top