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.

I think it's worth coming at this problem from the other direction as well, crushing it, finally, in something we like to call the pincing crab-claw of good design. Implicit in the question of "how do we help people manage tabs?" is the assumption that people want to or should have to manage their tabs; this is definitely true for some tabs, but I think that fully half of the solution will come through helping people avoid a situation that requires capital-M Management in the first place.

Reduce

Sometimes people have multiple tabs quite simply because they need to have multiple documents or applications open simultaneously. But sometimes tabs are stand-ins for activities that could be supported (better, even) in some other way.

• Applications
  A number of my long-running tabs are applications I refer to over the course of a day: webmail, a calendar, an RSS aggregator, an IM client. And the list of web applications that people use, often in place of traditional "web 0.0" apps, is definitely not getting any shorter. This is bad news from a tab management perspective — it suggests that our lists of perma-tabs will only get longer.

  One way to deal with this this is by getting web apps out of the browser and into their own independent windows, as in Prism. By handing the window navigation task from the tab strip to the OS, we let users make use of the often richer and certainly more familiar set of window navigation tools available there (alt/cmd-tab, expose, taskbars/docks, and so on). Even working almost entirely within a browser as I do, I still find myself quite often hitting Cmd-tab (on the mac) to get back to my email, which is, of course, just in another tab rather than another application. This doesn't make as much sense for transient documents, but for something long running like an application, this can be very powerful.

• An attention queue
  People often use tabs as a kind of to-do list — pages to read, forms to fill, reminders of tasks to carry out. Why as open tabs rather than bookmarks? In part, I think it's because an open tab is less permanent than a bookmark. Especially before Firefox 3, bookmarking a page felt like a commitment and required filing — not exactly right for something you just intend to deal with As Soon As Possible and may need no long-term connection to. It's also because a bookmarked page, while around for later, doesn't have the presence and judging stare of an open tab. An open tab can be an unbidden reminder in a way that a bookmark, hidden until called forth, cannot.

  What can we do to support the "deal with this later" use-case that doesn't contribute to tab-clutter? I've started tagging pages to come back to with the tag "queue" and then, periodically, looking at everything with that tag. It's not an ideal solution, though, because I still have to initiate the reminder process. It helps to remind of what I have to do, when I think to check, but not that I have to do something.
  

Re-use

Quite often, when I try to sift through and clean up my tab pile, I find that I have the same document open in multiple tabs. In part, this is because it's getting easier to navigate to a page again than to find one that I know is already open (which better tab navigation will start to reverse). But in many cases, I'm sure I just didn't remember that I'd opened something previously. Making it easier for people to re-use an already open tab would certainly help prevent the tragedy of tab-inundation.

One early concept for this is an attempt to intercede when we see tab duplication beginning — as a user begins to tell the browser where to go. Some quick idea sketching led me to some variants on putting this information in the awesomebar - more discussion of these in a future post:

(click for larger version)

Recycle

Lastly, some open tabs are documents that you're well and truly done with, but that you didn't close. Metaphorically speaking, you just left it on the floor and walked away, again. Would it kill you to tidy up after yourself?

Amidst the sea of open tabs, though, it takes effort to comb through your tab list for the flotsam and jetsam. To paraphrase something I read somewhere recently, there's immediate benefit to opening a tab but not for closing one. The benefit in the latter case is separated in time from the effort to get it — this is a contributing factor for all clutter, really.

What can we do to encourage or make it easier for people to close tabs that they're finished with? Some add-ons try to lower the effort bar on the triage, by providing an indication of tab age and disuse, for example. What else can we do here?

If you have thoughts or suggestions about these issues, please do get in touch! Other good sources for insightful thinking about the nature of tabs and their management are Aza and Bryan. Update: Andy Edmonds has also written on this topic.

which leads, inevitably and in the spirit of adventure, to this:

Now to find the right recipe...

Others of the changes are more subtle, and have more to do with simply lessening the effort involved in using the Manager. As always, improving the fit between human and software requires an understanding of what people are really trying to do — in the case of the Download Manager, people are usually involved in one of two main activities: (1) watching, and occasionally controlling, the progress of their downloads; and (2), finding files (or information about those files) that they've downloaded in the past.

Is it done yet?

In many ways, the best progress indicator is one that you don't actually have to watch. When a quick download finishes, it's useful to see the manager so that you can deal with the file right away. If a download is going to take a while though, people typically won't sit and watch — it makes more sense to get the Download Manager out of the way and get on with something else. It's still useful to have a cue that something is going on and an access point to the Download Manager, though, which is where the download progress indicator in the status bar comes from:

I remember downloading it...

The latter of the two main uses is that of finding files you'd downloaded earlier. To help out with this, we've surfaced details that correspond to what you might remember about the file you're seeking. Much of this information was previously available but obscured — you could see it once you'd found the file you wanted, but not when hunting for the file in the first place. For example:

• The time or date, in a person-friendly format, is listed down the right-hand side of the window for easy scanability. If what you know is roughly when you downloaded the file in question, you can run down that column until you get to the range that's relevant.
• The file name is obviously an important cue as to what a given file is — it's been made a little bigger so as to stand out amongst the other backup information we're now providing
• When the file name is vague (document1.pdf?) or not meant for humans in the first place (xpz243ghb.exe), it can be very helpful to know where the file came from. To that end, we show the name of the site from which you got the file. For me, this is a bit of help that I now find I can't do without.

Once you've found the file you're after, you can open it (double click) or remove it (hit 'delete'), or, if you're after more information, right-click:

Of these options, the one that's new and that I find particularly useful is "Go to Download Page." If what you're after is not the file itself but where you got it, this will take you right there.

But I know what it's called!

Scanning through the list is made more productive now, but searching is even better. Here's an example of how searching, combined with the information we now surface, makes finding a downloaded file much simpler. Say I'm looking for take-out menus — I can just filter on menu:

What's interesting is that few of the filenames themselves contain the name of the restaurant, but I can see which one I'm after because we've listed the site names. These site names (along with all the text you can see on the screen) are searchable as well, which saves me in this situation: I'm looking for a menu from Juice For Life, but their name isn't in the file name:

And there's the file. Happy searching!