Tablets, User Experience and Fragmentation – Part 2

In my last post, I discussed the realities of platform and operating system fragmentation across smartphones and tablets. This also illustrated the difference in strategies the major platforms are taking to own this growing market. First, with Apple and Google having a similar strategy of taking their mobile platform wins and bring them to tablet devices. Counter to this is Microsoft’s strategy of building from their base on the desktop and that do the tablet with Windows 8.

But with these platforms comes the need to have strong user experience for these applications. One of the promises for cross-platform development has been the “write once, deploy everywhere” concept, where an application would take itself and then adapt completely for a different device. I think that this can work, but only within classes of devices. In this article I’ll show some examples where this can break down and ultimately hamper your overall experience, in the next post we’ll take this further, reviewing the development options for the varying platforms as they relate to user experience.

Responsive Web Design

One of the new “buzz” terms is Responsive Web Design. The idea here is that a web site that will be viewed at various sizes will swap out different CSS style sheets to display the semantic data underneath in a different way. This is performed through a number of means including the use of media queries or JavaScript. The Boston Globe is an example of this in action:

Desktop

At the desktop version, the approach is a basic three-column website, but as you shrink the browser window down, the layout adjusts to meet this different resolution. The layout and user experience of the site continues to adapt as the window size gets smaller and smaller:

Tablet

High Resolution Phone

Low Resolution Phone

For websites, this concept is great and it allows for a single source of semantic content to have adaptability over a wide range of sizes; however, where does this apply to the mobile application workflow? Websites are about consuming content and they have a traditional flow. Applications are generally focused on completing tasks and require a stronger two-way communication with the user. Each platform approaches the transition of applications from smartphones to tablets in a different way. In this post, I’ll review three of these starting with Google and Android.

Android

The Android platform supports multiple form factors including smartphones and tablets at varying sizes and resolutions. With Android, you are able to create applications for any of these devices. If you create a smartphone application first, you are able to make the application for resolutions that are within the range of the “default” resolution of 480×800, like the Skype application running on this Samsung Captivate:

Skype on Samsung Captivate

Now this application looks pretty good, the interface is relatively clean and easy to understand, and it looks right for the screen size on this device. When you start to bring these applications to the tablet space, things start to get a little awry.

The Android platform allows applications that were designed for smartphones to work on tablets, unless the application developer specifically blocks it. This same Skype application is not blocked, so I can run the application on a tablet running Honeycomb:

Skype on Dell Streak 7

Now this is the same application running on a tablet. As you can see, although the platform allows the application to run on the larger screen, there are layout issues and significant wasted space in the UI that starts to make the application look awkward. At an even larger screen with the Samsung Galaxy Tab 10.1, the same issues are exaggerated even further:

Skype on Samsung Galaxy Tab 10.1

Other applications have the same issues, like the ESPN ScoreCenter application.

ESPN ScoreCenter on Samsung Galaxy Tab 10.1 and Samsung Captivate

When you look at these side by side, you can see even more where the issues lie. The smartphone version has a nice, tight, and easy to see format, while the tablet rendition of the same application is stretched and looks awkward because it is straining to adapt to the resolution. There are also items that don’t adjust as well, as you can see with the advertising widget at the bottom of the screen:

Ad Rendering--Smartphone versus Tablet

Looks great on the smartphone, but the tablet has it stretched and just looks sloppy. Google does provide developers the means to create tablet-only applications; however, if you recall in the previous post, there are a class of tablets (like the Samsung Galaxy Tab 7.0) that run smartphone class operating systems (specifically Android 2.2 or 2.3). In the case of these tablets, if an application has a smartphone or tablet version, the smartphone version will run, even though it is a tablet-sized device. There are some limited ways to control for this by blocking out specific devices; however, from an end user experience, it can be very awkward since then no application may be available, as I’ll get into next.

The added complexity for consumers using these devices is around application availability. Look at this example:

Search Results for "Sirius XM"

You just got a new car with Sirius XM radio installed and also got an Internet streaming account to listen to music on the go. You get home and look up the app in the Android Market and what do you find? Well, it depends.

With these three devices, the application only was available on one. The Captivate had the application, but the two tablets did not; whereas if you search for Netflix, you get that on all of the devices.

Search Results for "Netflix"

With so many Android devices available, how do you know if the applications you enjoy will be on the device? What prevents Sirius XM from being on the tablet, when Skype proved that the same application from the phone can run on the tablet with no problems (other than some user interface oddifies)? There really is no easy explanation for the consumer, which can lead to significant frustration.

One additional headache with Android devices is the difference in user interface across the platform. TouchWiz, Sense, Blur, Nook, Kindle Fire, Stock Android—these are all modifications of the basic user interface of the device, which can make user portability across devices very complex. Throw in the UI specific implementation of widgets and settings options and you can get a lot of very frustrated people trying to wrestle with their devices. For instance, all four of these devices are showing the settings for the hardware. From a user experience perspective, they are all significantly different:

Settings on Four Android Devices

Now depending on your experience level, you can probably navigate between these pretty easily; however, I always like to think of what I call “The Grandmother Test”. When I help her or other people like her with gadgets and computers, they are looking for visual consistencies that they can rely on, and that never change. Statements like “Click the green button” are easier to understand than “Click the button with the label ‘Go’”. But when one device calls something “Airplane Mode” versus “Flight Mode” and a default button skin is changed from green to blue, the “Grandmother Test” fails pretty quickly.

iOS

With iOS things are quite different with application portability, but it still leads to some awkwardness for the user experience.

Up to an including the iPhone 3GS, there was a single resolution for all of the devices for the platform: 320×480. This was for the iPhone, iPhone 3G, iPhone 3GS and the iPod touch—a single resolution for all. It made development for the platform much easier since there was consistency between them.

When the iPhone 4 was released with the Retina display, this changed things significantly for the developer of these applications, as now there was a significant increase in resolution to 6480×960. This was twice the resolution of the original phone. What was interesting about this bump was that the resolution was exactly double of the previous resolution. This had some advantages. First, applications that were created for the iPhone 3GS resolution could easily be “scaled up” by using 4 pixels for what previously used 1. Applications would continue to have the same aspect ratio, same layout, and so on. The only compromise was that there was some slight pixilation when viewing the apps on the new iPhone 4 screen. Apple did perform some sub-pixel optimization to slightly smooth out the scaling effect, but it was a compromise. The Bejeweled 2 application is an example of that, as it was originally designed for an iPhone 3GS screen and is scaled up for the iPhone 4 resolution.

Bejeweled 2 on iPod touch

Now for developers, this meant that if you were targeting either the iPhone 3GS or the iPhone 4, you would need to design for both devices. If you wanted maximum amount of visual clarity you needed to create two sets for the two resolutions.

Until the iPad came out.

When the iPad launched, one of the big selling points was that all of the existing iPhone applications available in the app store could run on the iPad. This was great news for consumers that had already invested in their favorite apps for the iPhone. But there was a catch. Since the iPad resolution and aspect ratio were significantly different than the iPhone these applications were run in a unique window within the iPad screen. Specifically, the iPad is a 4:3 aspect ratio device with a resolution of 1024×768, iPhone 3GS designed apps, when run on the phone, displayed within a little box in the center of the screen.

Bejeweled 2 on iPad

Now this is obviously ludicrous to waste so much space on the device, so there is a “2x” button that essentially does what the iPhone 4 does: scale up the app to twice the originally designed size. The only issue was that the aspect ratio was different, so there are black areas around the application window to make up for the difference.

Bejeweled 2 Scaled Up on iPad

With such a large screen however, the pixilation effect that was not as noticeable on the iPhone 4 started to clearly show for scaled up iPhone 3GS designed applications.

Pixilation

With this new tablet form factor though, there were obvious advantages that could be used, but the challenge still existed for bridging the user experience with the smartphone versions. The advantage of Apple’s platform is that there are only a handful of devices that are part of the ecosystem. The iPhone/3G/3GS/iPod touch, iPhone 4/4S/iPod touch, iPad/iPad 2. Multiple devices—but there are only three resolutions to design for. With this, it is possible to make applications that can cater to these different form factors more easily, as shown with the Sirius XM app.

SiriusXM on iOS

But this ideal situation for design has developer handicaps. First, is the fact that the OS version on the device can be very inconsistent. Ranging from iOS 3, 4 and now 5, it is possible to have any of these for the devices. A large reason for this is due to the fact that a number of users never connect their phone to their computer, or they have elected not to update their devices when they sync with their computer (which also for the record exists with other platforms including Android and Windows Phone). Apple is attempting to make this fragmentation issue easier through the use of cloud services in the future to avoid a much worse fragmentation issue that exists with Android, but it exists nonetheless.

But even with handicaps, what is a clear benefit for the end user, when compared with Android, is that availability of the application in the app store is generally guaranteed (outside of OS version and hardware requirements) so there aren’t as many arbitrary or mysterious reasons why applications are or are not available across devices like there exists on Android.

Windows Phone

When Windows Phone 7 launched, it was a complete reset on Microsoft’s smartphone strategy. Their previous platform has beginnings all the way back to the Windows CE embedded operating system that was used on personal digital assistants in the early 2000s. Windows Phone 7 was something very different and very new for the company, and being late to the party when compared to Apple and Google made things difficult, but they were able to learn a few lessons from some of their competitors.

Now at 7.5, Windows Phone devices support a single resolution: 480×800. All devices that are on the platform use that screen resolution, regardless of the physical size of the device. While this may seem like a significant limitation it does provide significant benefits for developers. It means that there is only one resolution to target.

Windows Phone 7.5

The challenge is what will happen in the future. With phones like the HTC Titan having much larger physical screens, the desire to get higher resolutions would be advantageous for developers that want to have more refined and detailed user experiences. There are reports that the platform will support varying screen resolutions in the future; however, the biggest challenge is how they will support them. Will they take an Apple route where there is a more constrained aspect-locking approach to larger screens, or will they go the Google route with adaptable layout based on varying screen resolutions and aspect ratios. Simplicity for this platform has advantages today, but there are big unknowns regarding where it will go in the future.

When it comes to tablets, we need to remember that Windows Phone 7 is only for smartphones. If you recall, this is because Microsoft’s future strategy for tablets is with Windows 8, the successor to their Windows 7 desktop operating system.

Windows 8

While this makes user experience design easier for smartphones, it does make it more complex for tablets. This is because, based on a desktop legacy, there are dozens of possible screen resolutions for desktops, notebooks, netbooks and tablets that the operating system can target. To combat this, Microsoft has stated that their tablet-friendly Metro UI will only support resolutions that are greater than 1024×768, which pushes out popular netbooks or tablets with a vertical resolution of 600.

Windows 8 Full Screen Metro Application

But in the case of Windows 8, the question is how traditional Windows applications will co-exist with their new tablet-friendly counterparts work in this mixed system. In Windows 8 there is a decidedly two-sided world of Windows Desktop (what I’ll call the old Windows 7 UI) and Windows Metro (the new UI designed for tablets). You can have the two co-exist in a side by side orientation that can dock scaled down versions of Metro applications to the right or left of the Desktop.

An interesting new twist is then added to the tablet user experience design, and that is multiple forms for the same app. For example, a Metro application has to have the full-screen version, and the side docked version. These are obviously two very different views to the same app, combined with the fact that the other side docked app could be another Metro app, or the Desktop.

Windows 8: Metro and Metro Side-by-Side

Windows 8: Metro and Desktop Side-by-Side

With this, there is a very different mixture of user interface modes and presentations that can have impact on end users that will be experiencing this for the first time. The compromise though is that users will have full desktop functionality on their tablet devices and can use existing desktop software that they already use, combined with external peripherals.

Wrap Up

This is only the beginning to give a high-level view of user experience for these various platforms and the issues that they cause when migrating to different classes of devices; however, these are all devices that consumers are or will be buying and as a community we need to determine the best course of action for how these devices will serve the needs of the end user.

To which brings us to how these applications are made. In my next post, I’ll talk more about the varying native and cross-platform technologies that can be used to create these apps, and where there are gaps or potential issues in how you use them.