I had the great pleasure of attending the Maemo/Mozilla Danish Weekend last weekend, where I gave a talk on user-interface issues and tips to think about when creating add-ons for Fennec. The high point for me, other than getting suggestions from some of the first people to try building add-ons for Fennec, was getting to see the results of the Fennec Add-ons Developer Challenge, including the winner: Fabrice Desre's GraffiTwit.

Brian King wrote a great overview of the event, with links to the winning Fennec add-ons, so I'll cheerfully refer you over there rather than recounting everything again.

I will link to my slides, though. Here they are:

In Firefox, by default, we show a Google search field when you start the browser, but also give you the option to change it to whatever homepage you want. Occasionally, as on the very first time to run the browser, we show you a welcoming message instead. Recently, there's also been work to try to further refine what shows up when you open a new tab. All of these "start page" variants are attempts to speed you on your way to whatever it is you'd like to do with the web.

Let's break it down a bit. I'm thinking about three cases, the last two of which aren't addressed separately in Firefox today, but could be.

1. First run page – shown the very first time the app is launched
2. A start page that is shown each time the app is launched
3. A new tab page – shown every time the user opens a new tab

What should we do in Fennec? Where does the usage landscape differ from how Firefox works on the desktop?

1. First-run page

The first-run page is our big chance to get the user started with using the browser and the web quickly and pleasantly. It's a particular opportunity, in that we have some important things to communicate, and it's also when the user will forgive us the most for getting between them and whatever they were setting out to do. I think that users more or less expect, the very first time they open the browser, that we'll have something to say.

At the moment, Fennec uses this point of contact in a fairly limited way; we say hi and put up a little bit of pictorial instruction about how to use the browser:

There's more we can do here, and other ways to introduce the location of controls (zooming animation!). This is a separate topic from the one I'm thinking about right now, though.

Skipping to 3. Opening a new tab

A lot of thinking has been going on into what to show when you open a new tab in desktop Firefox. There's a good overview of the design issues and goals here, with a lot more detail here. In a nutshell, though, the ongoing work is trying to provide three things:

1. Links to sites you probably want to go to, drawing that list from the browser's knowledge of where you go often and have been recently (also offering links to recent updates on those sites, drawn from RSS)
2. If you opened the new tab immediately after closing another tab, the page offers a chance to reopen the tab (undo)
3. If you copied something before opening the new tab, the page provides a means to do something contextually appropriate with whatever it is that you've copied — a dictionary lookup if it's a single word; web search if it's a phrase; map if it's an address

And all of this on a page that's as spare and clean as possible.

The key insight here is that everything offered is an attempt to speed the user towards whatever it was he or she was setting out to do. None of it is general, though possibly interesting, information like "the current weather." Instead, the browser makes its best guess about what you're doing, and tries to help. When a user opens a new tab manually it's almost certainly with some specific goal in mind, so this start page, more than the other varieties, must not derail that train of thought with a lot of non-targeted distractions.

What about Fennec? Of those three types of interventions, I actually have another idea for a way to undo an accidental tab-close that's more tightly tied to the closed tab (more on that in a future post). Easing the taskflow for something copied is something we should figure out how to incorporate, though, for the moment, the incidence of general purpose copying is fairly low on smartphones (another issue for another day).

What remains is the "let's let you just tap on the link you probably wanted" functionality. It turns out, though, that this is something that Fennec already does — the navigation screen (what comes up when you tab on the titlebar) contains a set of awesomebar-educated guesses as to where you're trying to go. Rather than duplicating this in a start page, it seems to me that we should, on a new tab opening, skip the user right to the navigation screen for those suggestions. You can also search from that screen, which covers a major mobile new-tab use case.

Still interested and following along? You win a free trip!*

Back now to 2. Start page

What about a start screen that comes up when you launch the browser?

Unlike the case of a new tab, it's more plausible that a person might open the browser without a specific destination or search in mind. The likeliest cases, I think, are (a) just wanting to be entertained and kill some time; and (b) wanting to check in on what's new on your sub-section of the web since the last time you looked (from news to the latest tweets). This got me thinking about having a really light-weight and zero-configuration page that just presents some recent things that, awseomebar-style, we know the user might be interested in. Here's a quick mockup of the kind of thing I've been thinking:

I'm borrowing some ideas from some interesting stuff that's been coming out of Mozilla Labs -- most notably Atul Varma's Ambient News experiment (a video here). You can read more about it on his blog post, but, essentially, it addresses my relevance and low-configuration criteria by assembling the list of news sources automatically awesomebar-style and draws in the latest articles via RSS transparently. The user never goes through the still overly-jargon-filled (eating? molecules?) process of subscribing to feeds -- from his or her perspective, the article titles are just there. Ideally, we could use the same method to generate the entries in the section above for number of new emails, unread tweets, and so on.

Anyway - lots of details to work out yet, so please get to it. :) Or, rather, please let me know how you think this could be made simpler and more useful. What would you want to have come up when you launch a browser on your phone or mobile device? Or would you just want the browser to launch with the tabs you had open last time? Under what circumstances would you launch the browser manually rather than following some other path to it (like a link in an email or a search initiated through a widget on your phone's desktop)?

Please discuss here!

* to another thousand words on the subject of start pages! Not redeemable for cash value. Which would be huge.

It's quite minimal, out of necessity; when there's so little screen space to work with, everything there has to really earn it's place. What's there -- the page title/URL (all a tappable control itself), the site identity button, the stop/reload button, and the bookmarks button -- are all there because either they are important (1) immediately on app launch, (2) when a page is first loading, or (3) as a user begins to use a page.

Recently, though, we've been coming up against even tighter constraints than those that led to the current titlebar design. While everything you see above can reasonably fit on a screen like that on the Nokia n810 held in landscape orientation, it starts to get a little cramped when in portrait instead. On devices with smaller or lower-resolution screens, the problem starts to become acute.

There are a number of small things we can do to get back some horizontal space. For example, if you look at the work going on with our theme, you'll notice that we're starting to replace some of the interior curves with straighter edges -- it's saving us about 20 pixels at the moment, which may seem small but is a big deal on screens that are only 240px wide.

It's still not enough, though, and that's where this new idea comes from: moving the bookmarks button out of the titlebar. Given all the talking I do about the value of awesomebar results, you might wonder why we need a separate list of just bookmarks at all. It turns out that it is valuable, though, and that's because sometimes you're browsing, where the awesomebar is for search. Some examples:

• using a particular organization of bookmarks as a to-do list (either for a task or "here's my stack of every-day morning news sources")
• "I remember I've got it here somewhere... but what was it called?"
• and the big one: sometimes, you just can't type – maybe you're on the go and have only a thumb free – so you forgo the speed that searching would give you and just swipe through the list to the bookmark you want

That "See all bookmarks" item is the first item in the list, so as you pan down the list, it scrolls off the top. Also notice that this simplifies the titlebar – there's now just one place to tap when you want to go somewhere.

What's interesting (and effective, I think) about this design is that it adapts to your current usage type. When you're in can't-type browse mode, access to all your bookmarks, in a browsable format, is right there alongside our suggestions of where you probably want to go. When you're in the mood for search, at which point you're typing, that item gets out of the way because it's not a match for your search terms.

Am I concerned about taking up a whole row of vertical space that could be allocated to another awesomebar suggestion? I am, but on the whole I think it's worth it. No placement will be ideal for both screen orientations -- when landscape, the extra space we have is horizontal, whereas, when a device is portrait, the extra space is vertical. It's not quite a deadlock though -- we're more constrained in portrait than we are in landscape, which makes this seem like the best option.

What do you think? If you've got thoughts about this and/or ideas for alternate approaches, I'm very eager to hear them. Please pipe up in the discussion, over here.

We just released Fennec Beta 1 for Maemo devices like the Nokia n810. If you don't have one of those, you can also get a build for a desktop OS like Windows, Mac, or Linux. Download it and give it a try! Performance is much better than in our previous alpha releases, the user-interface is coming along as well.

In the time-honoured tradition of my people, I have recorded a video walkthrough. If you don't want to install the beta, or just want to have a guided tour first, click on through:

Of course, there's more going on around Fennec as well. People have been creating new add-ons for Fennec, which you can install either from addons.mozilla.org or directly from within Fennec's add-ons manager.

Stuart mentions a couple of particularly cool add-on projects in progress in his beta 1 blog post, as well as detailing some of the back-end work that's been a major focus for this release.

You can get instructions and a download via the release notes. If you don't have a Nokia n810, desktop versions are available too (Windows, OS X, Linux).

For a quick introduction, I've recorded a short video walkthrough of alpha 2:

For more information on what's new and what's underway, there are a number of other blog posts related to alpha 2:

• Taras Glek on Alpha 2 performance
  
• Mark Finkle on what's new in the front end
  
• Jono DiCarlo on Weave in Fennec
  
• Stuart Parmenter announcing the release
  

Please tell us what you think, or, better yet, get involved!

From an interface perspective, this chunk of Fennec is still a work in progress (see some design wireframes here); what you see in alpha 1 is more or less straight out of desktop Firefox. Still, it gets the job done, which means that we can walk through the process:

Above is the AMO page for URL Fixer. Soon AMO will recognize Fennec and offer direct installation, but for the moment, I just had to feed Fennec the XPI. When I did so I got the following:

So, clearly here's a dialog that needs some mobile-design attention. Still, when I tapped "Install Now," it actually went and did so. When I then moved over to the add-ons manager, URL Fixer had already finished installing. (Yes, we need to get some of our browser-level notifications in (as demonstrated over that link in a downloads context), so that users will know that things have happened.) So:

Tapping "Restart Fennec" did what it should. When it came back up, I went and looked in the add-ons manager again, and there it was, safely installed:

And it works!

So, much cleaning up to do interface-wise, but add-ons work, and that's great. Thanks Chris! (And Mark, of course!)

Fennec alpha 1 is here! If you have a Nokia N810, please install it and try it out! If you don't, though, you can also install Fennec on your Windows, OS X or Linux desktop.

The release notes give a good overview of what's new and how to get started with Fennec. Jay and Mark have posts about it, too.

As I mentioned in my last post, Fennec's user-experience is really coming together — it still needs tweaking and tuning, but you can get a real sense of how Fennec dedicates screen space to web-content and minimizes the need for typing. If you want to get a sense of how it works, before you install it yourself, I've recorded a quick video walkthrough:

I'm eager to know what you think, so keep the feedback coming!

Screenshots

The following are actual screenshots from an N810 running M8 rather than wireframes or pixel-perfect mockups.

A Fennec entry, with icon, in the Application Manager:

Fennec, just opened, non-full-screen:

Switched to full-screen, and on a new page. The titlebar has some more room to spread out:

As you pan down the page, the titlebar slides off the top:

Here, I'm panning past the right-hand edge of the page to get at the control strip:

Or, off the other side to see my tabs:

Less look, more feel

Of course, there's UI work, both theme and interaction-design, still very much ongoing. One critical part of the UI, the navigation screen that comes up when you tap on the titlebar, is in as of M8. It has yet to be themed, but is starting to behave as it should.

Here's that screen, filled with awesomebar-based suggestions of where you might want to go before you've even begun to type. Search engines are also in place, so you can send your search terms off to the engine of your choice with a single tap. Obviously this is still undergoing theming (to look more like this), and needs to be tweaked so that each line is taller and more finger-tappable.

And, as you begin to type, the awesomebar provides better suggestions:

My blog comments are still broken, so please help yourself to the discussion group

He's posted some of the recent work to his blog, and he'll be posting more there as we go. This is a effort still very much in progress, so please jump in with your suggestions (generally or even about specific glyphs/icons). There's a Fennec UI discussion thread ripe for contribution.

This first set takes us through some basic Fennec operation.

1. Initial page load
When a page first loads, and you're still at the top, you see a Title Bar at the top, with an identity button and a reload button. You also have access to your bookmarks.

2. Movin' on down
As you pan down the page, the Title Bar scrolls off the top. The entire screen is dedicated to web content.

3. Take a step to the right
Panning to the right of a webpage causes the Control Strip to snap elastically into place — it provides most of the primary UI, including a starring (bookmarking) button, back and forward, and access to page actions (e.g. SMS this page to a contact) and browser tools (Preferences, Add-ons, and Downloads). There's more how these sections work in the wireframes, with pixel-designed screens on their way.

4. What about the other side?
Similarly, panning off the the left of the webpage gets you to your tab area, which also snaps into place. The bottom button, on the left, creates a new tab. The idea behind the button on the right is that you should be able to pull up, via Weave, a tab that you have/had open on your desktop.

More to come!

Update: My comments are broken, so please leave your thoughts in the Google group or on Sean's post. Sorry and thanks!

1. Text input for mobile devices by Scott MacKenzie
2. Mobile GUIs and Mobile Visualization by Patrick Baudisch
3. Understanding Mobile User Experience by Mirjana Spasojevic
4. Context-Aware Communication and Interaction by Albrecht Schmidt
5. Haptics, audio output and sensor input in mobile HCI by Stephen Brewster
6. Camera-based interaction and interaction with public displays by Michael Rohs

They're all worth flipping through if you're new to and interested in this space.

... the motivations, assumptions, and directions behind Chromium's user interface design. Its goal is to explain the current design in a way that further work can be developed in-style, or so that our assumptions can be challenged, changed, and improved.

Of course, the huge design choice that isn't explained, the giant in the room, if you will, shows up in this illustration from the comic:

I can't help but think that people will encounter some difficulties in using a browser that's taller than a man. The Fitts' Law hit alone seems worth a bit of rethinking on Google's part, at least without a lot of stretching.

Click for the legible version (large!)

That's seven tabs, one of which contains four sub-tabs (Advanced), over the course of which the user can click on buttons to bring up a further 23 windows or panels, one of which has a further five tabs. That's leaving out the Add-ons Manager, host to preferences for add-ons, and the monster-filled fathoms-deep sea that is about:config.

It's hard to get rid of preferences. Typically, there aren't any that are entirely without worth, and, on an individual pref-by-pref basis, it's hard to argue that removing functionality is worth the small ease-of-use gain of one less item. Over time, though, you're left with a situation that is the opposite of simple.

This is a problem to chip away at in Firefox; for Fennec, it demands immediate attention. The smaller screen on a mobile device and a button-density dictated by the size of a fingertip make it impractical to show a huge number of preferences — assuming that you'd even want to inherit that problem! Another defining characteristic of mobile is that the ratio of power-users to non- is skewed even further to non-power-users than on the desktop. Mobile users are just less likely to want to "configure" their mobile browsers.

For comparison, here's the full set of "Settings" in mobile Safari:

• General
  • Search Engine - Google/Yahoo
• Security
  • JavaScript - ON/OFF
  • Plug-Ins - ON/OFF
  • Block Pop-ups - ON/OFF
  • Accept Cookies - Never/From Visited/Always
  • Databases - lets you see a list and delete>
• Clear History (button)
• Clear Cookies (button)
• Clear Cache (button)
• Developer
  • Debug Console - ON/OFF

What preferences do you think are absolutely necessary in a mobile browser?

A couple of things that fit into place in my head:

1. Prying yourself away from the network

In China, not answering your mobile telephone is considered rude, no matter where you are, whom you are with, the time of day or what activities you are engaged in. And voice mail does not exist. Despite this cultural imperative to be available anytime and anywhere, there is a simple work-around practiced by hundreds of millions of Chinese. Manually removing the telephone battery creates a message to in-coming callers that the telephone's owner is out of range and thus unable to answer the phone. This regular subversion of the cultural imperative functions as an open secret, even playing a prominent role in a popular 2003 Chinese film called Shouji ("mobile telephone").

One of the defining characteristics of mobile users that they are always accessible/available, because their devices, and therefore the network, are always present. This can be great — it's a huge part of the value of mobile, because of the changes in behaviour that it allows (e.g. Shirky's transition from planning to coordination). As always, there are downsides as well. When the option to ignore your device, already rarely-chosen in North America, is actually ruled out as actively rude, the issues with constant availabilty are really thrown into relief.

There are cues and norms associated with being interrupted in "real" non-computer-mediated life, and, to some degree, these have grown up around fixed-place (desktop) computer use. At very least, we have basic tools (setting availability in your IM client) and some circumstantial divisions (if I stick to gmail and stay out of IRC when I'm not working, I won't get work-related messages). This all becomes more complicated when the same devices bridge all parts of our lives, and when the situations that can be interrupted are more varied and sensitive than sitting at a desk.

The ability to be appropriately available is going to be one of those issues around which there's going to be a lot of tweaking and perfecting over the next couple of years, I think. One early simple implication for the design of Fennec, though, is the possibility of a mechanism for setting your availability centrally in the browser, so that that websites and apps can pick it up rather than forcing the user to tell each site that he or she would rather not be bothered. Eventually, we could even start making this smarter, by basing some of it on the users location (taking advantage of GPS), schedule (I'm in a meeting), or even movement.

2. The potential of rich devices

Looking to the future, it is easy to imagine that in the next years China's mobile telephones will become the literal meaning of the Chinese word for mobile phones, shouji, "hand machines." Once rich data transmission becomes massively affordable, the mobile telephone will combine the pervasive, persistent and intimate qualities of existing phones with the internet's near limitless entertainment and communication options.

Literal translations are usually played more for laughs than for insight, but I really like this bit about hand machines. When people are dubious about the value of mobile access to the web and rich devices, it often gets phrased in the form of "Why would I want [a camera/TV/the web/other ability] on my phone?" The Chinese word captures it much better; what you've got isn't a phone – it's a hand machine. Making calls was just the great capability that got you carrying it first (no surprise that it was something to do with being social).

I was a bit skeptical about how many people would watch, but Aza blogged about it and numbers don't lie (I'm looking at you, numbers) — quite a few people managed to sit through the first one. Resulting comments led to interesting discussions, so it was well worth it.

After the jump, you can find the recordings of our thinking through "find in page" and how to deal with bookmarks.

The really productive part of the session, for me, was the time we spent hearing about mobile browsing use-cases from the people gathered for the session. The proof of our mobile web browser is going to be in how well it supports people as they try to live online while untethered, so really understanding these is critical. I've added my notes from that session to our page of usage scenarios; if you have ideas to add — a mobile itch that Fennec can scratch (metaphor only!) — we want to hear them.

With your indulgence (assumed!), I'm going to spend a couple of blog posts on the ideas in that presentation and about the design direction for Fennec. For starters, though, I thought I'd push further out into plain view the mockups of the Fennec UI we're building. The working designs are, and have been, on the wiki, but they can be a bit hard to find. This is where they're updated and extended as we figure things out, so have a look and let me know what you think about where we're heading.

https://wiki.mozilla.org/Mobile/UI/Designs/TouchScreen/workingUI

You can leave comments here or post to the thread.

We're also trying out some experiments in opening up the Fennec design discussions, so stay tuned, and let us know whether you find this kind of thing useful.