Breaking Development: Fragmentation in Mobile Design

by Luke Wroblewski September 23, 2012

In her Fragmentation in mobile design: Fact or fiction talk at Breaking Development in Dallas, TX Belen Barros Pena made that case that fragmentation in mobile operating system design (not development) does not exist. Here's my notes from her talk:

  • When people talk about mobile, they always bring up fragmentation. But if fragmentation is so important we have to look at it in detail. We have to break it down more.
  • Mobile phones are made of two things: hardware and software.
  • Hardware: phones used to be all kinds of form factors but today they have converged on black rectangles.
  • Development: there are at least 12 operating systems on the market, each with its own development requirements. This makes transferring code between OS quite difficult. In mobile operating systems, fragmentation is an issue for developers. But is it an issue for designers?

Mobile Design Fragmentation

  • All mobile operating systems are composed of applications that consist of content and actions.
  • Content in an application is organized in a hierarchy or structure. You need to move between sibling content (across the same level) and between parent and children content (top down navigation).
  • Top-down navigation can be accomplished by using the content itself. But you also need to go back up (using something like a back button).
  • Actions live in content screens. Not all actions in an application are the same. Some are really important: always present & in same place (global actions). Others are contextual (screen actions) or relevant to only one piece of content (object actions).
  • Applications also have input screens that collect information. These are connected to the application through actions.
  • These basic interaction constructs make up all mobile applications. So they are common across all operating systems.
  • Organizing content on screens is accomplished with lists and grids. Each operating system uses these interaction paradigms because they all need to fit a lot of content on small screens.
  • Tabs are the most common design pattern for managing sibling navigation. They are rendered differently on operating systems but work in a similar manner.
  • Global and screen actions are also commonly represented at the top and bottom of actions.
  • But what about the navigation differences with up/down navigation. Use the switcher test: how does the back button work? Got to app, open app switcher, go a different app, press back button: where does it go?
  • Software back buttons: all operating systems use software back buttons to navigate the hierarchy of an application. Hardware back buttons: these back buttons navigate activity history across all apps. Android 4 is the once exception. It uses two back buttons one software button and one hardware button. 95% of the time these two actions do the same thing. So it’s not clear way things work this way.
  • Lists, grids, tabs, bottom action bars, contextual menus on long press, and common actions on back buttons: these are common design patterns across all operating systems.
  • Commonplace means familiar –both for designers and developers. As people can move between operating systems and easily learn.
  • However, there is a dark side to this commonality. We are really early in the development of mobile and digital interfaces. Isn’t it too soon to have this level of standardization? These patterns are coming from the desktop. Are they truly the best patterns for mobile?
  • When you are designing an operating system, you are not focused on interaction innovation. Instead your innovation goes to creating a coherent framework, protecting users, and giving third party developers tools.
  • Disruption in mobile design will not come from the companies designing the OS. Disruption in mobile design must come from third party services. We need to tell operating system manufacturers what is required. That means spending a lot of time understanding what people actually need.