When AREA 17 first designed Quartz in 2012, our client at The Atlantic was forward thinking in their brief: ignore desktop. A simple, yet revolutionary statement.
By ignoring the desktop context, we had the freedom to serve the mobile context. We killed the homepage, dropped the right column, inserted premium native ads and reduced the navigation and branding. Context is a primary consideration when designing a user interface. This is understood by most UI designers and as mobile asserts its dominance, many of us adhere to a mobile-first approach.
The question is, should the context stop at the device level? Or should we consider the context of mobile sites vs. native app also? Today we’re seeing a blurring of the lines, with UI elements making their way from app to site, and vice versa. While some standardization makes sense, there is still inherent differences between these environments that need to be taken into account.
If we oversimplify, we can say that apps are tasks focused and websites are documents based. The reality is that each app or website feature-set can fit either definition or somewhere in between. A key difference is its context: websites are fetched from a network and viewed in a browser app; apps are standalone local containers, thus, living at a lower level from the OS perspective.
Most apps are packaged and can be seen as closed spaces: navigation sessions will mostly be “per app” and constrained inside that space. Websites, or the collection of pages composing it, are accessible from anywhere, and the navigation session will be part of a larger one: from google, incoming links, social, email, etc.
While subtle, these differences impact the UI structural elements.
The branded header
An app is branded by its icon, its launch screen and if it is already launched, can be clearly identified during app switching. The user mainly navigates within a single app without any delays since the app structure is stored locally. That is why internal screens headers are easily replaced with contextual information and a back button: e.g. sub-task title, filtering rather than the app branding.
A mobile site is more granular, pages lives within a browser between multiple sites, the brand is not so visible. Also, the user can (and will) land directly on detail pages (the homepage is dead) and should always know where she is. That is why it makes sense for a mobile site to have a branded header and clear access to navigation.
Here are some examples of internal app headers and their equivalent website form:
Context again, in an app, the navigation UI and views are embedded locally, this allows instantaneous navigation between main screens. On the other side, a webpage needs to retrieve (almost) all of this stuff from the network for each page view.
When possible, exposing the content structure is better than hiding it behind a burger-menu; this lets the user have a better understanding of the content organization and boosts user engagement. In native apps, bottom Tab Bars are a very common UI Pattern used to quickly switch between sub-tasks.
It is more tricky to have it work flawlessly on web sites: Tab bar items are perceived as buttons rather than web links, and with the native behavior habit, users could anticipate near instantaneous response times. This is not easily achievable in a mobile web context, a temporary visual feedback, eg. a loader or some content preview is then necessary.
Quartz mobile website uses a bottom tab bar that can feel a little bit laggy depending on mobile network performance: there is a delay after a tap with no loading indication other than a slight activity in the status bar. The YouTube website’s top tab bar displays an instantaneous loading visual feedback on tap.
Also, browsers already have a toolbar; this adds some visual design constraints to keep things readable if there is a double bar at the bottom of the screen. Not to mention the in-app reading experiences of web articles that can be viewed in Twitter & Facebook apps.
An alternative solution is to use simple link tabs or standard navigation bars:
That said, tabs (links or button based) on mobile screens are limited to 4 or 5 items, so they are well-suited for websites with few navigation options. But you could still use a scrollable navigation bar or fallback with an “All”, “More” or “Menu” button which works exactly like a burger menu, just less cryptic.
UI is only the surface
Things are evolving to break the app “closed” container paradigm as Google is now indexing app content. Also, online services behind apps are interacting with more and more touch points like notifications, chat or smartwatches. UI is only the surface and from the features requirements perspective, an app does not have to mirror an existing website and vice versa: they are not offering the same experience and not used the same way.
So, as a first step, there is always some user research, discovery and strategy work that needs to be done. For example, the New York Times “NYT NOW” app, which is based on a single news feed with bookmarking features. In other terms, a simply focused task with a rich experience, that’s what an app is better at.