Firefox Australis: One browser interface to rule them all(extremetech.com)
extremetech.com
Firefox Australis: One browser interface to rule them all
http://www.extremetech.com/computing/128161-firefox-australis-one-browser-interface-to-rule-them-all
46 comments
I guess this goes without saying, but view them in Firefox. At least the OS X one looked thoroughly screwed in Chrome.
No wonder since it is full of -moz-* vendor prefixes.
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.
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?
I'd really like tabs to auto-hide. I'd really like a bunch of the UI to be auto-hiding.
Just hiding the tab borders does seem sub-optimal.
Just hiding the tab borders does seem sub-optimal.
Note that these demos are early mockups from September 2011. Some details of the UI are bound to have changed since then.
Are you sure? I do remember a mockup from that timeframe that showed all platforms on one page, and was static rather than interactive. Given the greater sophistication in these and the fact that they're still linked from their wiki (https://wiki.mozilla.org/Firefox/Features/Theme_Refinement_a...) I had assumed these to be recent.
Edit: The older set I was referring to: http://people.mozilla.com/~shorlander/ux-presentation/ux-pre...
Edit2: The OP links were added to that wiki page in an early March 2012 revision.
Edit: The older set I was referring to: http://people.mozilla.com/~shorlander/ux-presentation/ux-pre...
Edit2: The OP links were added to that wiki page in an early March 2012 revision.
Hmm, in the new ones I was derailed by the icons of background tabs being not lined up with the OSX color pills. Yet the old mockups show a curve similar to the tab shape that creates a very welcome break in the design, explaining that "here are the tabs", and "here are the window controls", while the curve slant explained the height position difference between the pills and the icons/text (notice how the line linking the green pill center to the home icon center looks perpendicular to the centermost part of the separator curve, which cuts this segment in half). Without that curve, the new design simply feels broken. What's worse, since it's right there on the top-left, this is the absolute first experience of the software from the user's eye. It does not feel robust at all.
Ah, I must have been confusing these with Stephen Horlander's early mockups. Thanks for the detective work.
Ooh, cool -- will add those links to the story.
I actually prefer when apps respect the UI guidelines of the OS they're running on. I understand the desire for one unified interface, but there's also much to be said for intra-OS UI consistency. FF has done really well in the past with that, but I guess they're jumping on the Chrome bandwagon.
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 :).
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 :).
Speaking as a Mac user I agree. The Mac Firefox browser has always been clunky and never felt particularly 'native' to Os X. Camino was a far more native Gecko-based Mac browser.
> 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.
One man's sin is another man's salvation. That's one of the main reasons I use Chromium and Chrome as my primary browsers on Linux, besides their superb performance optimization. It works well with Ubuntu's integration of the top OS info bar and the app's menu bar, and saves noticeable screen space. I love it.
I'm hoping Firefox at least provides that as an option in future builds as well.
One man's sin is another man's salvation. That's one of the main reasons I use Chromium and Chrome as my primary browsers on Linux, besides their superb performance optimization. It works well with Ubuntu's integration of the top OS info bar and the app's menu bar, and saves noticeable screen space. I love it.
I'm hoping Firefox at least provides that as an option in future builds as well.
Right, no objections if that makes things better for you. I would like to mention that in Plasma Netbook (the netbook-optimized edition of our workspace) we've tried a sort of alternative approach where if windows maximize, we disable the borders and merge the window controls into the top panel, to achieve the space saving. You can also set that up in Plasma Desktop of course.
As for app menu in a panel: That's actually something we had back in KDE 3.x but are still lacking in the KDE 4 mainline at present, mainly because it's taken a while to coordinate the standard with folks like Canonical and because we really wanted the core patches to be integrated at the Qt level. Things look to be coming together now for the upcoming 4.9 release, though I believe (K)Ubuntu has actually been shipping the patches for a while already, for the benefit of KDE apps running in Unity, but also to support the same sort of arrangement in KDE workspaces.
As for CSDs, there's bunch of other things they break that I didn't list in the original post. For example, with WM-provided decos, the window manager can detect when you're trying to interact with a frozen app and offer to kill it, which is in fact something we're doing. If you move the deco into the app process, though, well, then it hangs together with the app, and things get a little more complicated. And there's performance issues in some remote desktop cases, and so on.
As for app menu in a panel: That's actually something we had back in KDE 3.x but are still lacking in the KDE 4 mainline at present, mainly because it's taken a while to coordinate the standard with folks like Canonical and because we really wanted the core patches to be integrated at the Qt level. Things look to be coming together now for the upcoming 4.9 release, though I believe (K)Ubuntu has actually been shipping the patches for a while already, for the benefit of KDE apps running in Unity, but also to support the same sort of arrangement in KDE workspaces.
As for CSDs, there's bunch of other things they break that I didn't list in the original post. For example, with WM-provided decos, the window manager can detect when you're trying to interact with a frozen app and offer to kill it, which is in fact something we're doing. If you move the deco into the app process, though, well, then it hangs together with the app, and things get a little more complicated. And there's performance issues in some remote desktop cases, and so on.
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.
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.
This of course is not yet the case, but soon it will be.
I'm pretty sure I recall the same concessions being made for Swing when Java was up and coming.
(Of course, the difference here is that this is actually happening, but still...)
(Of course, the difference here is that this is actually happening, but still...)
Another difference is UI startup time. The Java VM took minutes on most computers to go from URI entry to first UI display. Compare that to optimistic rendering all browsers do today, where delay is mostly dependant on network speed.
Tell that to anyone who uses their PC for programming, document creation, graphics design, or is comfortable with the command line.
I have been using webapps for said tasks more and more. Many tasks performed using a webapp do not yet have compelling advantages. But soon they will get them, I think. To name a bold example, http://C9.io: Not yet bringing many compelling advantages, but the tipping point is close.
Different strokes for different folks, I guess. I can't stand using a webapp for something that should be a desktop app. I just don't get the responsiveness I need. It's like using Photoshop without a mouse.
I had that experience a few years ago, when javascript execution engines where not optimized yet for speed. Today, I have the same experience with apps built using flash, where there is an annoying delay when hovering/clicking. A mature webapp running on a fast javascript engine does not give me any noticable delay. The "feel" is just the same as a native app.
c9 has one big advantage - before I was granted admin privileges at work, it allowed me to get started with some node work without having to install anything.
Thanks for reminding me of half of my html5 "todo" list.
[edit] whether I find the free time to get around to any of it is another matter, admittedly.
[edit] whether I find the free time to get around to any of it is another matter, admittedly.
The mock-ups of future Firefox-versions always look gorgeous but they usually start running into issues at the implementation-stage. Some things are left out, corners are cut and in the end it doesn't give the full experience the mock-ups are giving the impression of. Firefox 4 is a good example of this, where the original designs were showing much more than what actually shipped in the end.
I hope that they have learned from this during the past redesigns and assign someone responsible for making sure that the mock-ups are followed thoroughly.
I hope that they have learned from this during the past redesigns and assign someone responsible for making sure that the mock-ups are followed thoroughly.
I've been wondering about this for a while: what's with the large back button? Back when it was introduced, it was cool because back button was the most often-use one of all nav buttons (next, reload, stop, home) but now they're reduced to one, large back buttons just doesn't seems to make any sense anymore.
Are they still doing it as a part of Firefox UI identity or is there any (recent) usability research on this?
Are they still doing it as a part of Firefox UI identity or is there any (recent) usability research on this?
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.
My issue with this interface is the following:
You either have round tabs or rectangular tabs. Firefox used to have rectangular tabs, Chrome has rounded ones.
The new Firefox ones has, well, I don't know. It's a mix of both, please choose one, and I prefer rectangular. Seriously, they are mixing rounded and rectangular, it's ugly.
You either have round tabs or rectangular tabs. Firefox used to have rectangular tabs, Chrome has rounded ones.
The new Firefox ones has, well, I don't know. It's a mix of both, please choose one, and I prefer rectangular. Seriously, they are mixing rounded and rectangular, it's ugly.
As long as they keep the add-on bar they can do whatever they want to the UI.
[deleted]
I'd still use Vimperator.
You know I don't use Chrome (which is sooo fast) partly because I don't like its UX (especially the tab design).
Copying it will not gain back the lost market share, it will only give more reason to use Chrome.
Copying it will not gain back the lost market share, it will only give more reason to use Chrome.
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.
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.
> 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.
While I'm overall not a fan of Chrome's UI and this may speak correctly to the present state of affairs, I feel there's something worth adding to give credit to Chrome for advancing the state of the art: They implemented a bunch of smart behaviors Firefox later copied. Good piece on this: http://www.theinvisibl.com/2009/12/08/chrometabs/
While I'm overall not a fan of Chrome's UI and this may speak correctly to the present state of affairs, I feel there's something worth adding to give credit to Chrome for advancing the state of the art: They implemented a bunch of smart behaviors Firefox later copied. Good piece on this: http://www.theinvisibl.com/2009/12/08/chrometabs/
My goodness! Finally, someone giving Apple a run for their money in terms of obsessive design! I love how they do tabs right to left when using an Arabic locale... They've really thought it out.
Incidentally, no idea who voted you down. That was a very insightful link!
Incidentally, no idea who voted you down. That was a very insightful link!
Just to add to that, re reversing in Arabic locales: All KDE/Qt apps will do the same with their tabs and have done so for at least a decade, and you can even get a feel for it in an LTR locale by running them with --reverse (useful for devs to check for issues in custom widgets).
(And thanks for the kind words. :)
(And thanks for the kind words. :)
Well yes, it's a detail but it's in my face all day long. Also, on XP (that I still use at work ...) it has that ugly xp-esque blue.
The tab thumbnails look a lot like Opera's.
Is it just me or does the first mock-up look a lot like Chrome?
The article is showing the wrong screenshots. Here is the accurate one: http://imgur.com/NdNif
Linux: http://people.mozilla.com/~shorlander/files/australis-design...
OS X: http://people.mozilla.com/~shorlander/files/australis-design...
Windows 7: http://people.mozilla.com/~shorlander/files/australis-design...