{"id":87,"date":"2005-10-06T10:50:50","date_gmt":"2005-10-06T10:50:50","guid":{"rendered":"http:\/\/lachy.id.au\/log\/2005\/10\/firefox-interface"},"modified":"2006-04-30T23:33:38","modified_gmt":"2006-04-30T23:33:38","slug":"firefox-interface","status":"publish","type":"post","link":"https:\/\/lachy.id.au\/log\/2005\/10\/firefox-interface","title":{"rendered":"Firefox Interface"},"content":{"rendered":"

A while ago, Scott Berkun \u2013 one of the developers of early versions of IE<\/abbr> \u2013 announced that he\u2019s switched to Firefox<\/a> and provided some feedback regarding Firefox\u2019s user interface. This was later followed up by Asa<\/a>, who attempted to address some of his concerns. I too am going to take a look at some of his issues, as well as discuss a few more of my own.<\/p>\r\n

Find Toolbar<\/h3>\r\n

Firstly, the Scott complained about the Find toolbar being at the bottom of the screen instead of the top. Personally, I think putting it at the bottom is the best possible location for it, for the following reasons:<\/p>\r\n

If it were placed at the top, then its appearance would likely cause the page to shift down, or else cover up the top part of the page a little: both of which would not be good for usability. The top should also be reserved for toolbars\/information bars that deserve the user\u2019s focus and attention. In the case of the find toolbar, especially since it is \u201cfind-as-you-type\u201d, the user\u2019s primary focus is not on the toolbar itself, it\u2019s on the page; or, more specifically, the location of their search terms highlighted within the page<\/em>.<\/p>\r\n

I use find-as-you-type quite often and the amount of times my focus actually shifts down to the toolbar itself is minimal: usually only when I want to select \u201cMatch Case\u201d or click the close button (on the occasions when pressing Esc doesn\u2019t work, after taking focus away from the toolbar.)<\/p>\r\n

One minor issue with the find toolbar is, that if I press Alt+C<\/kbd> to check\/uncheck match case, the focus shifts to the checkbox and I can no longer continue typing. I have to tab<\/kbd> back to the text box to do so, but then the the text is all selected again and I can’t just continue typing from where I left off. When using this keyboard shortcut, focus should immediately shift back to the text box and allow me to continue typing. It should not highlight the contents of the text box, as usually happens when a text box gains focus, the carat should return to the same position. <\/p>\r\n

Downloads Dialog<\/h3>\r\n

Scott also talks about the Downloads dialog and mentions that it would be better implemented as a one line toolbar at the bottom, much like the find toolbar. As mentioned in the comments in Scott\u2019s post and also by Asa, this is already possible using the download status bar extension. Personally, the download dialog never really bothered me that much, but I agree that removing unnecessary dialogs is a good thing. The other alternative to the toolbar at the bottom, is to place it in the sidebar, as is done by the All-in-one-sidebar extension.<\/p>\r\n

Tabs and New Windows<\/h3>\r\n

Scott also states that Firefox goes against IE\u2019s window implementation by starting each new tab instance from scratch and not bringing over the history. At this point, I\u2019d like to point out that IE initially went against Netscape\u2019s implementation<\/em> which, IIRC<\/abbr>, never carried the history over between new window instances.<\/p>\r\n

As I\u2019ve been a Netscape user for a long time, I\u2019m partial to the Netscape\/Mozilla\/Firefox model and I don\u2019t think it makes sense for new tabs\/windows to bring across the history from other windows. I never liked that behaviour of IE \u2013 it always seemed quite unintuitive. When I request a new tab\/window, I expect just that: a new tab\/window, to start afresh with a clean slate, not a copy of my current tab\/window. Besides, IIRC<\/abbr>, there are some extensions available which allow you to duplicate tabs, for those that want that behaviour. <\/p>\r\n

Location Bar<\/h3>\r\n

The file menu is mostly quite good. All but one item, that is. The Open Location item is, under normal circumstances, almost completely useless. All it does is give focus to the location bar (at least when the location bar is present on the toolbar). It could be argued that it\u2019s presence does provide a means to discover that Ctrl+L<\/kbd> will give focus to the location bar, but a menu item for the sole purpose of giving focus to something else still seems rather pointless.<\/p>\r\n

After some investigation, however, I discovered that it\u2019s not completely useless. In the event that the user has customised the toolbars and removed the location bar, the result of selecting Open Location\u2026 is to open the \u201cOpen Web Location\u201d dialog box.<\/p>\r\n

\"The<\/p>\r\n

This dialog box looks disgusting. Honestly, it looks like it was slapped together quickly without much thought, and nothing done with it since. The combo box for entering the URL looks too narrow (vertically), it should be the same height as all other text boxes and drop down lists.<\/p>\r\n

The \u201cOpen in\u201d list is useful, but it requires too many clicks to use: one to open the list, another to select the option and a third on the open button. There probably should have, instead, been 3 buttons: \u201cOpen\u201d (for current window), \u201cNew Window\u201d and \u201cNew Tab\u201d. That way, it only requires a single click regardless of the user\u2019s decision. Another problem with this dialog is that the keyboard shortcut: Alt+Enter<\/em> doesn\u2019t work for opening a new ta, like it does for the location bar. Lastly, the \u201cChoose File\u2026\u201d button could be useful; however, there is already an \u201cOpen File\u2026\u201d option in the File menu, so it seems quite redundant.<\/p>\r\n

I suggest removing this dialog completely and making the following changes:<\/p>\r\n

    \r\n\t
  • Open Location\u2026 should only be visible in the File menu when the location bar has been removed from the toolbar. (though, this one is debatable since there would then be no way to discover that Ctrl+L<\/em> focuses the location bar, except by reading the help files, but then there’s no such ability for using Alt+D<\/em> either, which works in both Firefox and IE.)<\/li>\r\n\t
  • Instead of opening a dialog box for this menu item, a location toolbar should appear at the top of the page (like the way the find toolbar appears, except at the top of the page).<\/li>\r\n\t
  • The appearance of this toolbar should not push the page down. It should instead just temporarily cover up the top of the page. It should disappear once the user has opened the new location or taken focus away from it.<\/li>\r\n\t
  • It should also have a close button, but I\u2019m not sure whether it should appear on the right (like on the yellow information bars) or on the left (like on the find toolbar).<\/li>\r\n\t
  • Don\u2019t bother adding the Choose File\u2026 button, it\u2019s redundant.<\/li>\r\n\t
  • Extend the Go button with a drop down menu, just like the back and forward buttons have. This menu should contain \u201cCurrent Tab\u201d, \u201cNew Tab\u201d and \u201cNew Window\u201d (in that order), with their associated keyboard shortcuts beside, which is useful for discoverability. Doing this would actually make the Go button useful. I\u2019ve never used it myself, but I\u2019ve heard that some users don\u2019t know they can just press Enter instead.<\/li>\r\n<\/ul>\r\n

    Web Search<\/h3>\r\n

    Similar to the location bar, there\u2019s a \u201cWeb Search\u201d menu item (in the Tools menu) with the sole purpose of giving focus to the search box. It also serves to reveal the keyboard shortcut: Ctrl+K<\/em>. However, unlike Open Location\u2026, it does absolutely nothing when the search box has been removed from the toolbar. My recommendation for this is essentially the same as for the location bar:<\/p>\r\n

      \r\n\t
    • The menu item should only be visible when the search box has been removed (but the same argument for not doing so with Open Location still applies).<\/li>\r\n\t
    • When selected, a web search toolbar should appear at the top of the window.<\/li>\r\n\t
    • On this toolbar, there should be a Search button (similar to the Go button). It should also have a drop down menu, with the same 3 options as the Go menu, which I suggested above, for opening the search results page in the current tab, new tab or new window.<\/li>\r\n\t
    • This search button should also be available for adding beside the current search box; if not there by default (though having it there by default may look too cluttered).<\/li>\r\n<\/ul>\r\n

      Plugins<\/h3>\r\n

      For the most part, the plugin interface is very effective. It\u2019s so easy to install a missing plugin, it takes just a few clicks and it\u2019s all automatic. That\u2019s fantastic\u2026 Well, at least until I choose not to install a plugin, in which case Firefox will bug me every single time I visit a page that requires it. I should be able to decide that I don\u2019t want to install Flash, or that I don\u2019t want to install Java, and Firefox should respect my decision and show me the alternate content instead. If the page doesn\u2019t have accessible alternate content, I\u2019ll just leave if I can\u2019t do or find what I want, but I don\u2019t want to be bugged by the information bar every single time, for the same plugin.<\/p>\r\n

      I\u2019m not sure how the interface should look to implement these features, but I should be able to perform the following functions:<\/p>\r\n

        \r\n\t
      • Install the plugin (already possible)<\/li>\r\n\t
      • Choose to install it later, and be reminded next session. (Similar to the current default behaviour, but not be reminded every time a the page reloads during the session)<\/li>\r\n\t
      • Choose not to install the plugin, and not be reminded later.<\/li>\r\n<\/ul>\r\n

        If I choose to install later, or to never install it, then the alternate content should be displayed. Currently the \u201cClick here to download plugin\u201d place holder is left there even after I dismiss the information bar; which makes that page inaccessible, even if the author was sensible enough to include alternate content.<\/p>\r\n

        I should also be able to manage the installed plugins, just like I can manage the themes and extensions. I should be able to easily install, enable and disable plugins at will, from a menu like Tools>Plugins\u2026 The menu should open a dialog similar to the Extensions dialog, and the Get More Plugins\u2026 link should open the Plugin Finder Service and list all available plugins, including Flash, Java, Quicktime, etc.<\/p>\r\n

        As for the \u201cClick here to download plugin.<\/em>\u201d place holder, it needs to be redesigned a little bit.<\/p>\r\n

        \"Screenshot:<\/p>\r\n

        Firstly, remove \u201cClick here to\u201d and just use \u201cDownload plugin\u201d. Users know how to click links, they do it all the time, and \u201cClick here\u201d links are well known to be extremely bad for usability, despite the fact that they\u2019re abused<\/strong> by billions of websites. However, the text also needs to be styled to look<\/em> like a link. It should be blue and underlined (or however the user has configured the default link style in the preferences). For example:<\/p>\r\n

        \"Sample<\/p>\r\n

        Another option would be to make it look like a button, either option would be acceptable. This has already been done with the yellow information bar, I recall that it used to say \u201cclick here to\u2026\u201d as well, in older versions, but now uses a button on the right. The whole point is that a user should not have to read instructions to use something; it should be obvious from its design that it should be clicked.<\/p>\r\n","protected":false},"excerpt":{"rendered":"Discussion of ways in which I would improve the Firefox user interface.","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[11,6],"tags":[],"_links":{"self":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/87"}],"collection":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/comments?post=87"}],"version-history":[{"count":0,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/87\/revisions"}],"wp:attachment":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/media?parent=87"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/categories?post=87"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/tags?post=87"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}