Posts tagged design

Embedded browsing is an important part of Crème experience. People often post links to Twitter, and you want to see the pages behind the links right then and there. So, in Crème and in many other apps, you can tap on a link and a nice browser window opens, showing you the web page.

As we continue working on Crème, it makes sense to go back and revisit parts of the interface and scrutinize each detail, looking for improvement potential. Lately, the browser started to get on my nerves with a usability problem, so I improved the browser.

Just for review, here is the browser in all Crème versions up to 1.3.

Pretty standard. There is a “Back” button in top, “Back” and “Forward” in the bottom, together with “Reload” that changes to spinning wheel while the page is loading, and an action. Many other Twitter apps, but also Facebook and others have exactly the same kind of browser.

The usability problem that triggered the redesign was that I often surfed around the web pages with this browser, and then wanted to go back. Naturally, I should have used the browser’s “Back” and “Forward” buttons since that is the right way of doing that. Instead, I tapped on the top left Back because that’s how 80% of “Back” action in Crème happens. Instead of going back to the previous webpage, POOF — the browser was gone and I was back to wherever I started, having lost my intermediate pages.

This made me unhappy with the current Back/Forward approach and prompted a scrutiny of the whole interface. Why does the browser have to be like this? Sure, one answer is that this is similar to Safari regarding Back and Forward. But is that the best solution?

We are going to approach this from the perspective of OS X Human Interface Guidelines. They say:

During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution—that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems. If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users.

iPhone HIG also has something similar, but I like this wording more.

So, what are the elements, why are they this way, and can they be some other way?

• Top left “Back” button, goes back to previous screen. This is an important part of Crème. Let’s keep it for now.
• The rest of top bar — why is there all this empty space? Can we put it to good use and kill some other inefficiency? Let’s see…
• Bottom left “Back” and “Forward,” root causes of this redesign. “Back” is inconsistent with top left “Back”. How about we instead make it work like this: when you tap a link in browser, the new page gets pushed to navigation stack, and a new “window” opens. To go back to previous browser window, you’d use the top left “Back” button, as elsewhere in Crème. Feels good.
  What about Forward though? See above about 80/20. Forward falls into the 20%, it is not a very common action in this kind of browsing situation. So it goes away. Goodbye.
• Refresh/Spinner. The spinner duplicates the activity indicator in the top status bar that spins when activity is going on. So the spinner is not necessary. As for Refresh, again, it is not common in embedded browsing situation, and can go away.
• Action button. Now, there’s some useful stuff there, like being able to post link or open link in Safari. But action buttons in Crème are typically in top right corner. This can go there too.

So, we have either killed all the buttons from the bottom toolbar, or shuffled them around, or changed interface behavior, so that none of them are needed. We can get rid of the bottom toolbar now, which makes us happier because the interface is now consistent. Browser was the only view with bottom toolbar in Crème.

This change has the added benefit of making Crème more iPad-ready. We are still ways away from making an iPad version, but it is useful to tighten the interface for this new device as we go. From iPad HIG:

If your iPhone application has a toolbar, consider moving it to the top of the screen instead of leaving it at the bottom. With the additional width of the iPad screen, you should be able to provide all of your toolbar functionality in a single toolbar at the top. This gives you more vertical space for your focused content.

This does not, of course, mean that iPhone apps can’t have bottom toolbars. But, in this particular case, it helped focus the interface.

We can also add more context to the page by loading the page title in the middle part of the top bar. This also fills the “Back” buttons of next browsers with proper text.

Here is the result after making the changes. Feels more focused, and we also gained 44px (9%) of vertical screen estate by killing the bottom toolbar, so we can show more content.

Tech note: we now push more browsers to the navigation stack as you drill down the links. I was afraid that this affects memory consumption, but an Instruments trace showed that the memory impact of this is negligible. So technically, it didn’t get worse.