So I wanted to write this post up as a way of convincing the Mozilla folks that their mobile version of Firefox named Fennec needs a complete overhaul in terms of usability. I'm not worried about the rendering so much as I am about the user interface - menus, address bar, tabs, etc. - which I find both confusing and generally unusable.
I've been using mobile browsers a long time, on a lot of different devices. So I can appreciate the effort the Fennec guys have made to get the buttons and stuff out of the way of the user and maximize the amount of screen real-estate dedicated to the web page being viewed by putting the interface hidden off to the sides. If you haven't used Fennec, the idea is that you "swipe" the page from the left, right or down and get to the buttons that you can use to move back, call up bookmarks, enter the url, call up the settings, etc.
I can imagine that one day a developer came up with the "side-swiping" idea as a way of cleaning the cruft out of a small screen. Then after mocking up this new and interesting way of maximizing the screen, everyone else said, "Hey, wow, that's new and interesting," and it went into the final code. And then once Fennec was released to the public, every blogger out there said, "hey wow, that's new and interesting" and it became part of the Fennec identity. It's now the thing that makes Fennec stand out from the rest of the crowd of mobile browsers (of which there are many variations).
I totally understand. The problem is that side-swiping sucks.
I'm not saying that as a general put-down, or as an insult to whomever came up with it (was it Aza?), I'm saying "Hey, nice idea! But it didn't work." After the many times I've tried to use Fennec on a real device, the user interface continues to be a pain in the ass as well as incredibly confusing and non-intuitive. It just doesn't work.
Let me enumerate the problems that I see right now:
1) The functionality is hidden. This is never a good thing, especially for newcomers, but also for experienced users as well. Though when you first start up Fennec, you get a home page that sort of shows you which direction to move your fingers to get which functionality, once you start browsing the interface is then gone and you end up swiping left and then right because you forgot where something is. Making users memorize where common functionality is located isn't great.
2) The swipe action is commonly misfired while browsing. As you're trying to move around various web pages, you end up calling out the sides or the top bar by accident *all the time*. Swiping in a perfectly vertical line is pretty much impossible, and any other movement is interpreted as a call out to the sidebars, which then start to pop out, and then flicker back to where they were before. This makes reading long pages painful.
3) Scrolling to the top and sides to see the UI. Once you've read to the bottom of a screen, if you want to enter another URL, you have to scroll to the top of the page again to get your address bar back or, unintuitively, open up a side panel, which then calls up the top address bar. If you have a page that's too wide for the screen (which is common if you've zoomed, or on vertical displays on many phones) the same problem happens with the side bars - you have to scroll to get to the edge of the page before you can get to the UI.
4) Too much page movement is bad for a mobile device. Because the UI moves the page itself to the left and the right to show the chrome, the page has to be re-rendered on the screen as it moves over, many times causing a sheering effect because of the lack of power on the mobile device and generally makes everything slow. At the minimum, the side bar should be an *overlay* so that only that small part of the screen has to be redrawn.
5) No page-location indicators. There's no need to have scroll bars, definitely, but having no indication at all where you are in a page isn't good either. I'm not sure if this is just missing from the beta and will come in the future, or intentional, but it's definitely needed.
6) No keyboard/button interaction. Lots of mobile devices have buttons - either side buttons, keypads or even full-on keyboards. Right now Fennec doesn't support something as basic as paging with the space bar, saving a bookmark with the keyboard or entering a URL. Just because a device is mobile, doesn't mean it's an iPhone clone - this stuff is vital.
7) Slow Rendering restricts quick scanning. The latest revs of Fennec have an iPhone like checkerboard pattern while moving around the page displayed constantly, even for a fully-downloaded page. I'm not sure why this is. The N810's integrated Mozilla-based browser manages to store an entire page and display it, making skimming and scanning a big page quick. By putting the checkerboard pattern up, there's this constant flickering of the display as you move around making something as simple reading a long news article almost a seizure-inducing action.
In my opinion, most of these UI problems above are fundamental to the design of the interface and can only be solved by scrapping the idea of swipe actions, and going back a bit to basics. To illustrate what I mean, and to try to be constructive, I spent the morning going through various modern mobile web touch-screen browsers on my Nokia N810 and various phones and taking screen shots.
Let's start with Fennec itself:
You can see in the above image a bug which really illustrates the problem with the sidepanel interfaces. This particular bug on the N810 causes the sides to stay stuck half way out when the screen is maximized, so the first time I took a screen shot, that's what I got. In general though, it's a great example of a UI that's supposed to be hidden, *constantly getting in the way*.
This is a shot of Fennec with a page fully loaded, but with no actions taken yet.
Now we've scrolled down a bit - see the address bar doesn't disappear, it slowly scrolls away like it's part of the page. You need to scroll back up to get to it again. Also notice the URL is gone, replaced by the BIGGEST PAGE TITLE IN THE WORLD. I understand the UI has to be big enough to touch with your fingers, but does the title have to be so big?
Swiping to the left gets your new bookmark, back, forward and settings buttons. (How you get to a list of your bookmarks is an exercise for the user to discover).
Swiping to the right gets the multiple tabs that may be open, and the ability to launch another one. I think this is the weakest part of the user interface. Does a user really need to have such quick access to another tab that it needs to be always available? And do the tabs really have to have thumbnails of the pages? My desktop Firefox browser just has basic text-based tabs and they work great, also I can barely see what's on the thumbnail anyways.
Nokia N810 Mozilla Browser
Next is the integrated browser that comes with the Nokia N810, also based on Mozilla:
This is integrated browser with a page fully loaded. Notice on the bottom the permanent tool-bar with bookmark, feed icon, address bar, back, forward, and zoom controls. Also notice the scroll bars on the page taking up a lot of room as well. Though I do use the side scroll bars quite a bit to "page" down, I'd prefer a bit more screen dedicated to the page.
This is the same browser with the toolbar turned off, which is how I usually use it. The toolbar will come back up while loading a page (the progress bar is in the address bar), however for the most part it's not there and to get it back you need to press the menu button and go to minimized view which can be slow. Note also that there's no sign of "tabs" - the integrated browser works like the old IE did, where you have multiple browser windows and use the OS desktop itself to switch between them.
The Midori browser is based on Webkit, and it looks like the user-interface was ported directly over from the desktop. You can see it's got all the things we don't want on a mobile browser interface - tons of space wasted on tabs at the top of the screen (which may or may not be there), scroll bars, and a gigantic toolbar. This is what you would get if you ported Firefox over directly, which no one wants.
Actually, *this* is what you'd get if you ported the UI directly. That's my desktop Firefox resized to 800x480 like an N810. Obviously, there's way too much junk in there for a mobile device.
Digia's @web browser is another Webkit based browser for the N810. You can see there's no scrollbars, or really any other functionality apparent once you've loaded a page, though the address bar does stick around. Notice hidden at the bottom is an arrow? That doesn't go away and is how the UI is called up from a page.
This is the Digia browser after it's been moved a bit - the address bar disappears completely. The only thing left is the little blue arrow at the bottom, which has it's pros and cons: It's nice that there's *something* on the screen to show both new and old users how to get to the interface, however it's pretty small, easy to miss, but does cover a bit of real-estate. Maybe for reading news it wouldn't be so bad, but what about a web-video or email interface? It'd be annoying to have that arrow covering up something important.
And what happens when you press the blue arrow? You get your basic UI back: Tabs, address bar, refresh, zoom, back, forward, home, add bookmark and manage bookmarks. One click away and it all disappears. The simple, yet functional of this UI is attractive to me, though the implementation itself is butt-ugly.
Nokia N97 Webkit
Moving on to another touch-screen device is the 640x360 resolution Nokia N97 with the integrated Webkit-based browser. Once you enter an address or choose a bookmark, the page loads and then the interface is automatically hidden as it goes into "full-screen" mode. (You'll note that the phone has been auto-detected and a mobile-version of NYT is used - that's not a big deal as I'm actually talking about the outside interface, not the rendering). Since Symbian's UI tends to be rather bulky, I like that it goes into full-screen right away though it might be a bit confusing for new users. Notice on the bottom right is a resize arrow, which brings the UI back up, including a toolbar. This has the same issues as the Digia one - it's nice to have a hook back to the UI, but does cover up some of the screen which might be important.
Pressing the resize-arrow brings back the menu options, including the menu on the left, the go to URL, and zoom. These could be a lot clearer and that real-estate used for much more common functions that you have to dig into the "menu" for, but I do like that it pops up and goes away so easily.
These are the menu options, which give the rest of the functionality missing on the main interface. The greyed out buttons aren't available. The nice thing about this interface is that at least it's not another menu - it's very touch-screen friendly.
One last thing to note is that I was going to take some wide-screen shots of N97, but the screenshot app I used isn't landscape aware, so it didn't work. :-)
Opera Mini on the N97
To contrast with the integrated N97 browser is the Most Popular Mobile Application on the Planet: Opera Mini.
Once a page loads (from a URL or bookmark) you are immediately presented with an overview of the entire web page. Note there's no toolbars, a small title bar, and only very tiny scroll bars. Despite being designed for a traditional smart phone with left/right soft buttons, Opera Mini actually works great on a touch-screen device like the N97. Scrolling, moving back and forth, and choosing menu options all works fine. The lesson of this is that just because you have to design for fingers, doesn't mean the interface has to be "fat".
Double-tapping the page will auto-zoom to that column of text, making it very easy to read a web page, even on a small screen device. Also, if you have a pop-out keyboard, you can use keyboard shortcuts to move around the screen, and a little tiny pointer will show up if you use the directional pad, which makes clicking smaller links quite a bit easier.
Android is a decent browser, but the user interface is exactly the sort of thing that will frustrate new users and make even experienced users have to click around to figure out.
Android starts out after a website is loaded with just the top-left corner of the page showing. Hmmm... now what? How do I zoom? How do I go back? It's all hidden. Note the nice small page location indicators though - they're not scrollbars per se, but the do help you see where you are on the page.
Once you touch the screen you get a bit more help! Ahh, there's the zoom... and what's that thing on the right, does that go full-screen?
Ahh! That zoom button put me in whole page view... can I move that magnifying box around? Woops, nope. What do I do? Oh, I see, double-tap.
Okay, I've zoomed out a bit, but how the hell do I go back!??!
Oh, I see, if I press the menu key on the face of the device, I get all the basic options. This is the main problem with this browser. It's not that it doesn't render pages correctly, it does that fine. The problem is the UI is spread out and not all available via the touch screen. I think this is a key point to make - you can't predict if a user knows which keys to press (such as the G1's "menu" key) so the entire interface should be available from the touch screen alone. This might make it more crowded, but in the end the users will be happier that they can find what they need.
Okay, last but certainly not least is the iPhone. Everyone's seen this browser, but now that we've seen a bunch of *other* attempts, let's see what Apple did right.
First thing is that the interface is actually very economical. Even though it's meant for touch screens, it doesn't have oversized buttons or text-entry boxes. Once the page is loaded, the title remains at the top of the screen, but scrolls away with the address bar and search box. Note that even though it's a bit crowded, having TWO spots to enter text is needed to make it abundantly clear to the end user what they can do - *and* it looks just like the default browser on their desktops (Safari, Firefox and IE all have search boxes at the top). Apple didn't hide functionality, and they didn't radically change the way users expect a browser to work.
Double-tapping on a column zooms into that area. The zoom functionality using multi-touch *is* hidden away from the user, but is such an integral part of the iPhone, that most users don't even notice. My son when he was only 4 years old got the idea right away, so it's obviously quite intuitive, though sadly, not something that most other multi-platform browsers will be able to use.
Finally, once you scroll down a bit, the address bar disappears. What's not captured in the screenshot is the little page-location markers that show up in place of scrollbars as you pan around the page. Now even though I don't particularly like the addressbar disappearing, Apple has added a shortcut that most people learn pretty quickly, which is to tap the mobile information bar at the top, which scrolls you right to the top of the page quickly. Also notice that the nav buttons don't disappear- they're important! And obviously Apple thinks they're worth the screen real-estate.
Whew! So after looking all these mobile browsers there's a bunch of obvious stuff that comes to the fore in my mind, which I'll summarize here:
1) Don't hide functionality. Put the most used functions - back, home, bookmarks, tabs/window list, zoom - on the screen and keep them there.
2) If you do hide something, make it easy to find again. As much as I sorta dislike the little arrows overlays, I have to say they help get your UI back.
3) Bigger isn't better. Just because it's a touch screen browser, doesn't mean the interface has to be comically huge. Opera and iPhone show that smaller menus and buttons will work just as well.
4) Be familiar. A billion people use browsers on the desktop every day, make it easy for them to move to mobile by making the interface similar to what they're used to.
5) Most phones have keys of some type, might as well use them. The power users will love you if make the tedious stuff just a button-press away. Just don't make the functionality *only* accessible from the keyboard like the Android browser.
6) Load the page and keep it loaded (cache, cache, cache). Cellular networks are relatively slow, and mobile CPUs are relatively slow - don't make the phone or the user work too hard or wait too long for a page. Once a page is loaded onto the phone, make it quickly and smoothly scrollable. If Opera Mini can do it in JavaME in limited memory, native browsers can do it as well without pixelating the screen. Up and down, by the way, is more important that side to side. Make it so that slight movements, or a slight angle on a drag doesn't jerk the page around for no reason - the iPhone is a big culprit of this and makes reading longer pages more difficult that it should be.
7) Zooming is key. Web pages have been designed for desktops, so they just don't fit on a mobile display in a readable way. Even a higher-resolution device like the N810 needs to zoom. Make it quick, make it smooth, make it easy. If you have to have several screen presses to zoom, you're not doing it right. Opera is amazing the way it can detect a column and perfectly fit it in the screen with just a double tap and iPhone's multi-touch is intuitive as hell - is this the reason those are the two most popular mobile browsers?
8) Tabs/Multiple windows aren't that important. I hate to limit functionality, but Opera doesn't have tabs or multiple windows and it works just fine, thank you very much. More browser windows is more complexity, more memory and more confusing. I hate to presume what people do on their mobile browser, but it's unlikely they have 30 tabs open like they do on their desktop. Mobile browsing is task or entertainment focused - give me directions or movie times, or give me something to read while waiting. So while tabs is nice to have, and works well on the iPhone, I feel it's a feature that can be safely put in the "advanced users" area without any guilt.
9) Make it easy to explain. Like I wrote a couple years ago, the best user interfaces are the ones that can be easily explained over the phone. If you can't explain to someone how to use your application by using just words (rather than showing them), then something is wrong with your app. If an application requires odd or uncommon ways of interacting with it - hard-to-see screen overlays, crazy gestures, hidden commands - then it's not right.
Whew, that's all! I really hope this was worth the effort, not just for the Fennec folk, but for anyone developing a mobile web browser. It's easily the most important application a smart phone can have, and it'd be nice if millions of people weren't enjoying using it, rather than being befuddled any time they need to use the web with their phones.
Please contact me at email@example.com or on Twitter @russb if you have any thoughts you'd like to share.