Firefox Australis: One browser interface to rule them all (opens in new tab)

I guess this goes without saying, but view them in Firefox. At least the OS X one looked thoroughly screwed in Chrome.

Thank you for the links, as I wasn't going to visit the brain dead extremetech site on my iPad.

OS X mockup: the window control traffic lights don't line up vertically with the toolbar/tab bar icons, looks jarring. The close tab button is still on the right, tab titles are still left-aligned instead of centered, not impressed.

Firefox team: stop trying to ape the Chrome UI and think for yourselves for once, put the tab bar on the left or right side.

In these screenshots, the borders of inactive tabs disappear. This doesn't seem like a good idea. Wouldn't it be hard for users to identify them as tabs?

Note that these demos are early mockups from September 2011. Some details of the UI are bound to have changed since then.

Ooh, cool -- will add those links to the story.

Speaking as a Linux user, I don't think they have. Their use of and integration with the UI primitives of the GTK+ toolkit has been, well, primitive and unsatisfying, and Qt support is virtually non-existant (there was some porting done, but not enough to be anywhere near usable). However, even on OS X and Windows they don't use, say, native tab buttons. In fact, looking at the live demos I linked earlier, I don't think it's any more or less differenciated from each system's native style than the current design, purely in terms of for what elements it calls into that style for and for what elements it doesn't.

As for Chrome, the sin Chrome commits on Linux in particular is that it defaults to something called client-side window decorations, that is it tells the window manager not to display the decorations it would normally put around the client area and then proceeds to draw its own inside this client area, which behave potentially vastly differently from whatever the user has configured for his native system decorations. This is less of a sin on Windows because client-side decorations are in some sense almost the norm there (and in the technical sense they in fact are). The new Firefox design still appears to avoid it on Chrome and thus is still better, though in fairness Chrome also offers the option to disable it.

Let's face it, desktop Firefox has in fact never been using the native toolkit of the platform on any platform it supports in the conventional sense (reason for the desktop qualifier: I heard the Android version now intends to go native). Rather it uses its own UI toolkit that has a set of platform backends that call into native APIs to, say, grab a pixmap of a native element and then weaves that into its own rendering, which is very different from actually putting a native element on screen, since the original code implementing its behavior and the details of its rendering doesn't actually run[1]. Rather, any time Firefox makes something look native it's just a case of more or less close emulation.

Now interestingly, this is not uncommon among browsers, especially in the document viewport: As far as I know, even MSHTML reimplements all of the form controls it embeds into websites by itself rather than use native Windows widgets, and for the longest time you could easily spot the differences in behavioral details. To my knowledge KHTML is the only browser engine which ever used (and still does use) native platform widgets directly. And in the case of Firefox, the Gecko engine powering the viewport also powers the browser chrome. This is one reason that you had number of semi-popular browsers embedding Gecko into chromes actually using native platform toolkits, like Camino on OS X and K-Meleon on Windows.

1 = Let me give a concrete technical example of why this is a problem. In KDE 4, our default style engine renders combination of radial and vertical gradients into the background of windows. Cf. this screenshot of a plain, empty window: http://www.eikehein.com/kde/window.png

Now, KDE is based upon the Qt toolkit, and the traditional Linux platform backend of Firefox uses the GTK+ toolkit instead (as mentioned there are the beginnings of a Qt port, but it's not anywhere near useful yet). Obviously we prefer Qt over at KDE, but since application developers who chose differently have written some perfectly excellent applications using GTK+ and we believe users should be free to use them without suffering aesthetic consequences, we in fact sat down and wrote an essentially feature-equivalent, visually faithful and fully native GTK+ version of Oxygen. It's the most sophisticated style engine available for GTK+ today (in ways screenshots don't entirely do justice - there's e.g. tons of subtle transition animations in there you don't usually see in a GTK+ engine, say fading in focus rings). This makes actual, native GTK+ windows look just fine. Here's one and the same demo application written using three different toolkits, Qt 4, GTK+ 2 and GTK+ 3: http://4.bp.blogspot.com/-Ezze7Ar8OQ4/TaRaTjLLh5I/AAAAAAAAAk...

Firefox however isn't a native GTK+ application, but instead just calls into GTK+ to let it render certain UI elements (or even only parts of them) into buffers it then uses as sort of raw materials in the painting of its own UI elements. And this abstraction over the native GTK+ is leaky, i.e. it suffers from limitations where Firefox' indirect use of GTK+ doesn't account for something a GTK+ style engine might be doing because it wasn't anticipated. And our gradient window backgrounds are where one of those limitations hits: Firefox doesn't ask GTK+ for the window background to draw into its own window. As a result, you don't get the gradient in a Firefox window using the Oxygen GTK+ style engine - and we even had to add a system to our window decoration to allow the special-casing of such windows to tick off the gradient in the deco as well, so you don't get a seam. This makes it look reasonably okay, but it's just not fully there: http://www.eikehein.com/kde/firefox-oxygen.png

And let's not even talk about those transition animations ... or actually, let's, to pre-empt the counter-argument of them not being desirable in the first place: You can turn these off if you don't like them. The point is that by not actually using the native widget, Firefox is not in a position to follow the user's preference in the matter either.

So, there you have it - here's the KDE guy in fact not complaining about Firefox not doing Qt, but actually doing GTK+ so poorly we can't make it fit even by embracing GTK+. Clearly it's not us not going the extra mile for integration :).

It looks like they're still keeping the subtleties of each OS (eg the ICS action bar), just adding they're own styling, icons, branding, and flow on top.

Looks a lot better than apps that just port iOS apps to Android pixel-for-pixel.

The browser is an exempli primus of an app allowed to break the OS UI guidelines. This is becase the browser is becoming the OS, and the OS becoming the browser. Said differently, the only UI on the OS is coming from the browser.

This of course is not yet the case, but soon it will be.

The forward-button still appears when there actually is a link to go forward to (instead of having it greyed-out a lot of the time). My personal opinion is that it looks good, and that the round back-button has become a way of recognizing Firefox. The option to shrink it isn't that hard to find though, you just choose "Small icons" in the UI-settings.

You kind of allude to this with the identity bit, but to spell it out I remember reading in their docs that part of the original motivation for the large button was the idea to establish a cross-platform "keyhole shape" element (formed together with the forward button) there to identify Firefox by.

Branding aside it's usual a good idea to make the most used elements of the UI big, it makes them easy to click.

The only difference between Chrome's tab design and Firefox's is that Chrome's tabs have rounded corners and Firefox's tabs are rectangular. You refuse to use a browser because it has rounded corners? Really?

Anyway, there will probably be add-ons to bring back the rectangular look if enough people prefer it to the rounded look. If I were a real fan of Firefox's current look, I'd be more worried about the big orange button being dropped in favor of an options button in the exact same place where Chrome puts it.

That joke is tera-ble.