I recently ranted that iOS needs a new mobile browser better than Mobile Safari. Well, the folks at Opera are trying to build just that, with a new app called Coast. The challenge here for browser-makers, and mobile app developers in general, is pushing the UI to include desktop-level functionality without a messy, confusing UX. I spoke with Huib Kleinhout, the original developer behind Coast, on the right way to enable big functionality on the small screen.
What was the original pitch to Opera to start building Coast?
The original pitch is quite close to what Coast has become today. If you analyze how technology and user experience paradigms have changed the last decades it becomes quite clear that existing browsers are doing a poor job and only taking baby steps at the time in the right direction. I proposed a project to make the browser invisible and designed for touch.
Since I had been working on the idea for several months (though still as a side project), the case that I presented to the president of engineering at Opera was relatively complete. The case include historical context, technical and UX justifications, new paradigms and principles for browsing, technical/UX solutions for invisible technology, and two visual designs. To give an example, two principles from the pitch were:
- Content is king, the browser should be invisible and not dominate the visual experience.
- Websites are becoming applications and shouldn’t be interweaved with the browser chrome. It’s up to the each site to decide what interaction model to employ, how users can manage their favorite content, and how contextual actions such as sharing or printing should be presented.
These principles are generalizations, but have been important guidelines for the design priorities. Coast still has a share button, but instead of sticking it on top of each site it has been moved to the background (in the “recent sites” screen).
Because the pitch included many aspects from a high-level vision to two concrete designs implementing that vision, it was a pretty good case.
Do you see a difference between a mobile browser on a tablet versus a phone?
You can only create the best experience when the software is designed for the hardware it will run on. While the screen size is the main difference between a phone and a tablet, even that has significant effect on how you use it.
Not only on how much information can be displayed at the time but also on how you use your hands to interact with it and what kind of tasks you perform with it. You don’t quickly pull an iPad out of your bag to simply look up the time. It’s more a device that you use when you have a couple of minutes to sit comfortably.
The best iPad and iPhone apps cater for these differences. And while cross-device apps also need to keep a consist experience across devices, there is plenty of room for differences. The same holds true for browsers.
Were you concerned that people would have trouble with the use of gestures?
In the interface we differentiate primary gestures and the secondary gestures. Primary gestures are the basic ones you need to browse the web, such as swiping back and forward. Using usability tests and many iterations of the user interface, we ensured that the primary gestures are easy to discover.
Secondary gestures are those gestures that you don’t really need to use it as a browser, but that make the app a lot more fun and efficient to use. Examples of secondary gestures are swiping up and down the search field, swiping down the site in “recent sites” to expose the safety information instead of clicking on the “i,” the multitouch interaction when editing the home screen, swiping on the stack of new sites at the bottom to expand the stack, etc.
When you launch Coast the first time you get to see a short introduction movie. The goal of this movie is not only to teach users about the basics of the app, but also to encourage users to tap and swipe through the UI: We want users to explore and enjoy the dynamics of the interface, it won’t easily break; a touch screen is to be touched!
Was there a struggle to keep legacy elements like the status bar, or was it easy to throw them out in favor of a cleaner and simpler design?
Creating a simpler, cleaner design doesn’t mean just hiding stuff, but we had very clear goals and ideas on how to create a simple, touch-friendly experience. Most of the classic UI elements have been replaced with new, less-intrusive, under-the-hood technology.
For instance, all the UI elements in traditional browsers that need to be visible for the user to evaluate the security of a page have been replaced with an advanced safety engine. This engine runs in the background and constantly evaluates different risks based on many risk factors. It only warns the user when really needed. Another example are browser windows/tabs: These are automatically managed in the background without the user having to spend time on the management, a little like the apps are on iOS or Android.
Other legacy elements have been replaced with more touch-friendly interactions, for instance swiping back/forward to navigate between pages and swiping down to reload a page.
We designed, implemented, and tested many iterations of the UI; always starting with considering how the experience should be, rather than taking the current experience as a reference.