
Home Pale Moon homepage Pale Moon Start page Information General information Project history Site News Awards Technical details Release notes Pale Moon layout Download Pale Moon > Pale Moon Pale Moon x64 Pale Moon Portable Pale Moon Legacy (discontinued) Pale Moon language packs Profile Migration tool Profile Backup tool 3rd Party Builds [NEW] Pale Moon Commander [DEV] Pre-release WIP Archived versions Help F.A.Q. Troubleshooting Known Issues Beware of unofficial versions! Forum Feedback Testimonials Contact
About the Pale Moon layout in version 4 and later Several people have asked why Pale Moon has not followed the Firefox GUI (Graphical User Interface) layout. This document aims to provide a bit of background to the choices made in Pale Moon and to explain the reasoning behind the differences with Firefox. These layout changes were not done lightly, or without thought. The fact that the end result looks more like version 3 of the browser is not necessarily because version 3 is known and because Pale Moon is adverse to change, far from it. Rather, the layout is the result of working with the existing elements and attempting to keep things logical. It is also because the design choices in Firefox 4 and later were considered regression rather than progression, and there being very little that is truly "innovative" about the layout (as that implies good reason for, and a clear and unmistakable advantage of, the new state of things). Some definitions First off, some definitions for common terms/abbreviations: (G)UI: (Graphical) User Interface - This is what constitutes everything in the browser that is not page content, meaning all buttons, controls, menus, toolbars, the status bar, etc. UX: User eXperience - the name says it all, really. Standard UI convention: Something that has, either over time or by peer agreement, been settled on as being "the standard way of doing something in a user interface" and that is shared among a large number of applications. Affordance: Visually, the UI has clues that indicate what it is going to do. Users don’t have to experiment or deduce the interaction. The affordance of a UI is based on real-world (past) experiences or standard UI conventions. Expectation: Functionally, the UI delivers the expected, predictable results, without surprises. Users don’t have to experiment or deduce the result of doing something. The expectations are based on labels, real-world (past) experiences, or standard UI conventions. Efficiency: The UI enables users to perform an action with a minimum amount of effort. If the intention is clear, the UI delivers the expected results the first time, so that users don’t have to repeat the action (perhaps with variations) to get what they want. Responsiveness: The UI gives clear, immediate feedback to indicate that the action is happening, and was either successful or unsuccessful. Not to be confused with "reacting quickly" per se, although the two can be considered close to each other. Element grouping The basic premise behind Pale Moon's choices is simple: Element grouping. Grouping elements together with similar function or similar feedback is very important to UI design; people have designated zones in the UI where they can find groups of similar elements. This improves affordance and efficiency of the UI, as the location of an element is a clue to its function, and the intention is therefore clear. This scattering about of controls has been a problem for layout for several different popular browsers, including later versions of Microsoft's Internet Explorer. Grouping elements together with the objects they control is another consideration that will increase the affordance, as the location is a clear indication to what it will affect, making the result expected when the element is used. The status bar One of the most important changes in Pale Moon has been to bring back the status bar to the browser, after the (already optional) element was completely removed in the development stages of Firefox 4. A status bar is both a standard element (standard UI convention) for applications that have status to report (and a web browser is certainly one of those applications) and considered essential by a vast majority of users as shown in a survey. Removing the status bar, and even removing the option to have it if one wants it, has been a very ill-conceived notion by the Mozilla UX team for Firefox. By including the status bar, a small, peripheral-view element provides users with several different types of feedback about the status of the browser. In all respects, including the status bar is beneficial to the user interface's level of intuitiveness: it provides affordance by showing status text, in an expected location, and improves responsiveness. Firefox's alternative for status text (the popup method) to display network status and link addresses gives a comparable amount of feedback, but in a much more intrusive way: by not having it in a static element, the popup demands attention from the user, which is not a good thing for the kind of information provided. After all: this kind of information is secondary to the actual page content, and shouldn't draw someone's attention. In addition, popping in and out rapidly while browsing, the information can be very distracting or annoying. An intuitive interface should not lead to frustration. Plus, the popup status can't be configured or disabled, so in fact this has been two steps back, not just one. The status bar also provided more information than what has been retained in the UI elsewhere in the new design. There is no page load progress which is especially important for people on slower connections, there is no file download status information which forces you to open the downloads window to see if your files are still downloading, the status can no longer be set by web pages which is important feedback for some web applications, etc. On top of all that, if you use add-ons with icons placed in the add-on bar, meaning you have the add-on bar enabled, the status information is not placed in this add-on bar while there is plenty of space to do so, but floats above it instead - in the end using up more screen space than was used with the previous status bar. The argument that it would allow more room for page content is then not just moot, but even false. Navigation controls By default, Firefox spreads different navigation controls out horizontally over the browser. From a UI design perspective, this is a very poor choice. Internet Explorer 8 has suffered from the same poor decision, and you can wonder if copycatting has been going on without much thinking of the impact. Element grouping is important for these controls, as is having the elements be a similar shape (not mixing bordered with borderless) and size, resulting in the more classic look of the back/forward/reload-stop/home controls being grouped together to the left of the address bar, and of about equal size, being the default layout. All these elements control browser navigation. Tabs on top This has been a hot topic, and one could even call it "trendy" - but is it logical from a UI design perspective? In some conditions, it is: when a browser is maximized or used in full screen, having the tabs at or close to the edge of the browser means they are at the edge of the screen. In this case, it becomes easier to use, since the screen edge is a "hard" border and you don't have to be as accurate to quickly select a different tab - this follows Fitts' law concepts. In all other cases, it is not. Considering that today's computers have high resolution screens - in this age of full HD being pretty much standard with any system - most people use Windows with multiple applications in regular windows, and not maximized. In this scenario, having tabs on top means that, once again, element grouping (this time of larger zones of the browser) is not followed. Consider the following different layouts: The left layout has tabs not grouped with the element they control, but has static UI elements that are browser-wide inbetween. The right layout has tabs grouped with the content. The tabs don't control the way the navigation controls of the browser or the URL bar look or behave, nor do they influence other toolbars that may be there; they only control the page content. Both tabs and content are dynamic. One could argue that the URL address is an exception to this, of course, but in that case you would expect the URL field to be a separate control in its own zone - which it is not. If you consider system elements of the window placed around these layouts, like the application menu (which is a standard UI convention to have), title bar and borders, potential side bar, additional browser controls at the left and/or right end of the tab bar, etc., then it becomes even clearer that, in the right hand layout, the hierarchy of the elements is preserved: the outside being standard system elements (OS-static), wrapping around the browser elements specific to the program (application-static), which in turn wrap around content and content controls, which are dynamic. This is why the default in Pale Moon is to have tabs not on top, as it's more logical to have them next to the content. All is not lost: Configurability Drawing on the configurability of the Firefox UI layout, all of these design choices are defaults - and can be changed. In some cases it takes only 1 click (like tabs on top, or making the status bar hidden), in other cases it takes a few more steps, but even those are easy to follow. So, if you don't like the way Pale Moon is laid out, then play with the options and configure it the way you want it. [<- Back]
Firefox, Mozilla Firefox and Mozilla are registered trademarks of the Mozilla Corporation. Site and contents © 2009-2013 Moonchild Productions - All rights reserved Pale Moon's distribution is subject to the following redistribution policy

The Pale Moon Project - Custom-built and optimized Firefox browsers for Windows Operating Systems

About the Pale Moon layout in version 4 and later

Several people have asked why Pale Moon has not followed the Firefox GUI (Graphical User Interface) layout. This document aims to provide a bit of background to the choices made in Pale Moon and to explain the reasoning behind the differences with Firefox.
These layout changes were not done lightly, or without thought. The fact that the end result looks more like version 3 of the browser is not necessarily because version 3 is known and because Pale Moon is adverse to change, far from it. Rather, the layout is the result of working with the existing elements and attempting to keep things logical. It is also because the design choices in Firefox 4 and later were considered regression rather than progression, and there being very little that is truly "innovative" about the layout (as that implies good reason for, and a clear and unmistakable advantage of, the new state of things).

Some definitions

First off, some definitions for common terms/abbreviations:

(G)UI: (Graphical) User Interface - This is what constitutes everything in the browser that is not page content, meaning all buttons, controls, menus, toolbars, the status bar, etc.
UX: User eXperience - the name says it all, really.
Standard UI convention: Something that has, either over time or by peer agreement, been settled on as being "the standard way of doing something in a user interface" and that is shared among a large number of applications.
Affordance: Visually, the UI has clues that indicate what it is going to do. Users don’t have to experiment or deduce the interaction. The affordance of a UI is based on real-world (past) experiences or standard UI conventions.
Expectation: Functionally, the UI delivers the expected, predictable results, without surprises. Users don’t have to experiment or deduce the result of doing something. The expectations are based on labels, real-world (past) experiences, or standard UI conventions.
Efficiency: The UI enables users to perform an action with a minimum amount of effort. If the intention is clear, the UI delivers the expected results the first time, so that users don’t have to repeat the action (perhaps with variations) to get what they want.
Responsiveness: The UI gives clear, immediate feedback to indicate that the action is happening, and was either successful or unsuccessful. Not to be confused with "reacting quickly" per se, although the two can be considered close to each other.

Element grouping

The basic premise behind Pale Moon's choices is simple: Element grouping.

Grouping elements together with similar function or similar feedback is very important to UI design; people have designated zones in the UI where they can find groups of similar elements. This improves affordance and efficiency of the UI, as the location of an element is a clue to its function, and the intention is therefore clear.
This scattering about of controls has been a problem for layout for several different popular browsers, including later versions of Microsoft's Internet Explorer.

Grouping elements together with the objects they control is another consideration that will increase the affordance, as the location is a clear indication to what it will affect, making the result expected when the element is used.

The status bar

One of the most important changes in Pale Moon has been to bring back the status bar to the browser, after the (already optional) element was completely removed in the development stages of Firefox 4.
A status bar is both a standard element (standard UI convention) for applications that have status to report (and a web browser is certainly one of those applications) and considered essential by a vast majority of users as shown in a survey. Removing the status bar, and even removing the option to have it if one wants it, has been a very ill-conceived notion by the Mozilla UX team for Firefox. By including the status bar, a small, peripheral-view element provides users with several different types of feedback about the status of the browser. In all respects, including the status bar is beneficial to the user interface's level of intuitiveness: it provides affordance by showing status text, in an expected location, and improves responsiveness.

Firefox's alternative for status text (the popup method) to display network status and link addresses gives a comparable amount of feedback, but in a much more intrusive way: by not having it in a static element, the popup demands attention from the user, which is not a good thing for the kind of information provided. After all: this kind of information is secondary to the actual page content, and shouldn't draw someone's attention. In addition, popping in and out rapidly while browsing, the information can be very distracting or annoying. An intuitive interface should not lead to frustration. Plus, the popup status can't be configured or disabled, so in fact this has been two steps back, not just one.

The status bar also provided more information than what has been retained in the UI elsewhere in the new design. There is no page load progress which is especially important for people on slower connections, there is no file download status information which forces you to open the downloads window to see if your files are still downloading, the status can no longer be set by web pages which is important feedback for some web applications, etc.
On top of all that, if you use add-ons with icons placed in the add-on bar, meaning you have the add-on bar enabled, the status information is not placed in this add-on bar while there is plenty of space to do so, but floats above it instead - in the end using up more screen space than was used with the previous status bar. The argument that it would allow more room for page content is then not just moot, but even false.

Navigation controls

By default, Firefox spreads different navigation controls out horizontally over the browser. From a UI design perspective, this is a very poor choice. Internet Explorer 8 has suffered from the same poor decision, and you can wonder if copycatting has been going on without much thinking of the impact. Element grouping is important for these controls, as is having the elements be a similar shape (not mixing bordered with borderless) and size, resulting in the more classic look of the back/forward/reload-stop/home controls being grouped together to the left of the address bar, and of about equal size, being the default layout. All these elements control browser navigation.

Tabs on top

This has been a hot topic, and one could even call it "trendy" - but is it logical from a UI design perspective?

In some conditions, it is: when a browser is maximized or used in full screen, having the tabs at or close to the edge of the browser means they are at the edge of the screen. In this case, it becomes easier to use, since the screen edge is a "hard" border and you don't have to be as accurate to quickly select a different tab - this follows Fitts' law concepts.

In all other cases, it is not. Considering that today's computers have high resolution screens - in this age of full HD being pretty much standard with any system - most people use Windows with multiple applications in regular windows, and not maximized. In this scenario, having tabs on top means that, once again, element grouping (this time of larger zones of the browser) is not followed. Consider the following different layouts:

The left layout has tabs not grouped with the element they control, but has static UI elements that are browser-wide inbetween. The right layout has tabs grouped with the content. The tabs don't control the way the navigation controls of the browser or the URL bar look or behave, nor do they influence other toolbars that may be there; they only control the page content. Both tabs and content are dynamic. One could argue that the URL address is an exception to this, of course, but in that case you would expect the URL field to be a separate control in its own zone - which it is not.
If you consider system elements of the window placed around these layouts, like the application menu (which is a standard UI convention to have), title bar and borders, potential side bar, additional browser controls at the left and/or right end of the tab bar, etc., then it becomes even clearer that, in the right hand layout, the hierarchy of the elements is preserved: the outside being standard system elements (OS-static), wrapping around the browser elements specific to the program (application-static), which in turn wrap around content and content controls, which are dynamic.

This is why the default in Pale Moon is to have tabs not on top, as it's more logical to have them next to the content.

All is not lost: Configurability

Drawing on the configurability of the Firefox UI layout, all of these design choices are defaults - and can be changed. In some cases it takes only 1 click (like tabs on top, or making the status bar hidden), in other cases it takes a few more steps, but even those are easy to follow.
So, if you don't like the way Pale Moon is laid out, then play with the options and configure it the way you want it.

[<- Back]

Firefox, Mozilla Firefox and Mozilla are registered trademarks of the Mozilla Corporation.
Site and contents © 2009-2013 Moonchild Productions - All rights reserved
Pale Moon's distribution is subject to the following redistribution policy