Monthly Archives: October 2005

Firefox Interface

A while ago, Scott Berkun – one of the developers of early versions of IEannounced that he’s switched to Firefox and provided some feedback regarding Firefox’s user interface. This was later followed up by Asa, 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.

Find Toolbar

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:

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’s focus and attention. In the case of the find toolbar, especially since it is “find-as-you-type”, the user’s primary focus is not on the toolbar itself, it’s on the page; or, more specifically, the location of their search terms highlighted within the page.

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 “Match Case” or click the close button (on the occasions when pressing Esc doesn’t work, after taking focus away from the toolbar.)

One minor issue with the find toolbar is, that if I press Alt+C to check/uncheck match case, the focus shifts to the checkbox and I can no longer continue typing. I have to tab 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.

Downloads Dialog

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’s 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.

Tabs and New Windows

Scott also states that Firefox goes against IE’s window implementation by starting each new tab instance from scratch and not bringing over the history. At this point, I’d like to point out that IE initially went against Netscape’s implementation which, IIRC, never carried the history over between new window instances.

As I’ve been a Netscape user for a long time, I’m partial to the Netscape/Mozilla/Firefox model and I don’t think it makes sense for new tabs/windows to bring across the history from other windows. I never liked that behaviour of IE – 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, there are some extensions available which allow you to duplicate tabs, for those that want that behaviour.

Location Bar

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’s presence does provide a means to discover that Ctrl+L 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.

After some investigation, however, I discovered that it’s not completely useless. In the event that the user has customised the toolbars and removed the location bar, the result of selecting Open Location… is to open the “Open Web Location” dialog box.

The Open Web Location dialog box contains: A combo box for entering or selecting the URI; A Choose File… button for selecting a local file; Options for opening the page in the current window, a new window or a new tab; and Open and Cancel buttons.

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.

The “Open in” 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: “Open” (for current window), “New Window” and “New Tab”. That way, it only requires a single click regardless of the user’s decision. Another problem with this dialog is that the keyboard shortcut: Alt+Enter doesn’t work for opening a new ta, like it does for the location bar. Lastly, the “Choose File…” button could be useful; however, there is already an “Open File…” option in the File menu, so it seems quite redundant.

I suggest removing this dialog completely and making the following changes:

  • Open Location… 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 focuses the location bar, except by reading the help files, but then there’s no such ability for using Alt+D either, which works in both Firefox and IE.)
  • 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).
  • 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.
  • It should also have a close button, but I’m not sure whether it should appear on the right (like on the yellow information bars) or on the left (like on the find toolbar).
  • Don’t bother adding the Choose File… button, it’s redundant.
  • Extend the Go button with a drop down menu, just like the back and forward buttons have. This menu should contain “Current Tab”, “New Tab” and “New Window” (in that order), with their associated keyboard shortcuts beside, which is useful for discoverability. Doing this would actually make the Go button useful. I’ve never used it myself, but I’ve heard that some users don’t know they can just press Enter instead.

Web Search

Similar to the location bar, there’s a “Web Search” 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. However, unlike Open Location…, 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:

  • 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).
  • When selected, a web search toolbar should appear at the top of the window.
  • 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.
  • 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).

Plugins

For the most part, the plugin interface is very effective. It’s so easy to install a missing plugin, it takes just a few clicks and it’s all automatic. That’s fantastic… 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’t want to install Flash, or that I don’t want to install Java, and Firefox should respect my decision and show me the alternate content instead. If the page doesn’t have accessible alternate content, I’ll just leave if I can’t do or find what I want, but I don’t want to be bugged by the information bar every single time, for the same plugin.

I’m not sure how the interface should look to implement these features, but I should be able to perform the following functions:

  • Install the plugin (already possible)
  • 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)
  • Choose not to install the plugin, and not be reminded later.

If I choose to install later, or to never install it, then the alternate content should be displayed. Currently the “Click here to download plugin” 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.

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… The menu should open a dialog similar to the Extensions dialog, and the Get More Plugins… link should open the Plugin Finder Service and list all available plugins, including Flash, Java, Quicktime, etc.

As for the “Click here to download plugin.” place holder, it needs to be redesigned a little bit.

Screenshot: Click here to download plugin. place holder

Firstly, remove “Click here to” and just use “Download plugin”. Users know how to click links, they do it all the time, and “Click here” links are well known to be extremely bad for usability, despite the fact that they’re abused by billions of websites. However, the text also needs to be styled to look like a link. It should be blue and underlined (or however the user has configured the default link style in the preferences). For example:

Sample rendering of the “Download plugin” place holder with the text styled as link.

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 “click here to…” 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.

Web Developer Quiz Update

I’ve received quite a few responses to yesterday’s Web Developer Quiz, including some feedback about the type of questions I asked and criticism about them being too much about SGML which I’d like to take the opportunity to address.

Firstly, out of all the responses received in the last 24 hours (although, they’re not yet published), not one person has answered all questions correctly. Indeed, there are questions in there that no-one has answered correctly yet, which I am very surprised about — I was expecting to, at least collectively, receive the correct answers for all questions.

Secondly, I’m going to go through each section and explain, without giving away the answers just yet, why I asked each question and why it’s important for authors to know the answers to them.

Validation

Looking at the sample document, it’s not hard to see that it makes use of unsupported SGML features that cannot be used in the real world. However, this does not mean that authors do not need to be aware of them.

In fact, the document demonstrates just how easy it is to make unintentional use of such features, which, while it may not be what the author intended, will either result in one of two possibilites. 1. Completely unexpected errors that don’t seem to make sense: a problem I see a lot of beginners struggle with. 2. As is the case with this document, the combination of 2 specific authoring errors results in no validation error being reported at all, for the mistakes.

At this point, I’d like to point out that there is just 1 error within the document (most people have picked it so far), but it has nothing to do with the unsupported SGML features, and everything to do with the declared DOCTYPE. This will, perhaps, become more apparent to you when I reveal the answers and explain the reasons for the errors, or lack thereof, in more detail next week.

Elements in the DOM

The first of these questions is very much related to an unsupported SGML feature, rather than real world, practical HTML, and I admit, I just threw it in as a challenge for the more advanced authors. It is, however, important to be aware of the syntax and that it is unsupported, and thus cannot be used, even inadvertently.

The second question is testing your knowledge of real world, supported mark up. You need to be aware that start-tags and end-tags can be omitted for some elements, yet the elements will still be present in the DOM. You also need to be aware of the HTML/SGML comment syntax and, although it wasn’t really tested with these questions, the syntactic differences between SGML and XML comments.

Semantics

These are, perhaps, the easiest and most practical questions in the quiz. So far, nearly everybody has answered these questions correctly, and I don’t feel I need to explain why they were included, it seems quite obvious to everyone.

Character References

Surprisingly, nobody has correctly any of these 3 questions. Yet it is important from both a practical point of view and a validation point of view, to understand the similarities and differences between HTML, XHTML and XML with respect to character references. It is also important to have an understanding of the Unicode character repertoire and code points, which is what everyone has failed on, so far.

Media Types

Again, this is important from a practical perspective. Authors need to understand, that they should not use XHTML with the wrong media type, and also understand the practical limitations with doing so. Conversely, although this was not tested with these questions, it is important to understand the current practical limitations with using the correct media type for XHTML.

I’ll be revealing the answers including all the responses to the quiz on Sunday evening (local time). Until then, tell others, who haven’t seen it yet, about the quiz, I’m interested in finding out how much an average web developer really knows about the technologies they use every day.

Web Developer Quiz

This quiz is designed to test whether or not web developers have an understanding of the basic technologies used on the web, primarily HTML, HTTP, Media Types (MIME) and character repertoires and encodings. Personally, I expect every single web developer to pass this quiz with flying colours, yet reality tells me that a large proportion will struggle. So, in the interests of finding out exactly how much web developers in general do and do not know, and for your own personal benefit, I decided to publish this quiz (or survey, if you like).

Firstly, a few ground rules. Please don’t cheat. I expect all web developers to know the answers to these questions without the need for reference material or the use of automated tools. That means, please don’t make use of the validator or look up the specifications to answer these questions, they’re designed to be easy enough to answer without such tools, yet still provide enough of a challenge for all but the most knowledgeable authors. Secondly, in order to give everyone a fair go and avoid chance of having all the correct answers given away in the first response, I’ve temporarily enabled comment moderation and no comments will be appearing until I publish the results and answers next week. Ok, so on with the quiz…

This sample document applies to the first 3 questions. You may assume the HTTP headers contain:

Content-Type: text/html;charset=UTF-8

Note: This document uses some special syntax that is not widely supported in existing browsers; it is only designed to test your knowledge of HTML.

1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
2. <html lang="en">
3.   <title/Sample HTML 4.01 Document/
4.   <p align="right">This is a sample HTML 4.01 Strict document.
5.   <>How much do you know about HTML?</>
6.   <!-- -- --> <em>It’s not hard!</em> <!-- -- -->
7.   <p>Created by <a href=http://lachy.id.au/">Lachlan Hunt
8. </html>

Validation

Which lines in the above HTML document contain validation errors, if any? Note: I’m only looking for those errors that will be reported by a conforming SGML based validator.

Elements in the DOM

  1. How many p elements are there within the above document?
  2. Which of these elements, if any, will not be present within the the Document Object Model of the above document?
    • <head>
    • <body>
    • <em>

Semantics

  1. Which markup structure is the most semantically correct for a navigational link menu, regardless of how it will be presented visually?
    1. <div class="menu">
          <a href="…">Link  1</a> |
          <a href="…">Link 2</a> |
          <a href="…">Link 3</a>
      </div>
    2. <div class="menu">
          <a href="…">Link  1</a><br>
          <a href="…">Link  2</a><br>
          <a href="…">Link  3</a><br>
      </div>
    3. <ul class="menu">
          <li><a  href="…">Link 1</a></li>
          <li><a  href="…">Link 2</a></li>
          <li><a  href="…">Link 3</a></li>
      </div>
  2. Which markup structure is the most semantically correct for a title within the document body that may be horizontally centred in a visual medium (eg. screen) using a large, bold font?
    1. <div class="title">Document Title</div>
    2. <h1>Document Title</h1>
    3. <p align="center"><font size="+3"><b>Document Title</b></font></p>
    4. <h1 style="font-weight:bold;font-size:large;text-align:center;">Document Title</h1>
    5. <h1 class="LargeBoldCenterHeading">Document Title</h1>

Character References

Given these three numeric character references, and two character entity references:

  • &#x2019;
  • &#8217;
  • &#146;
  • &rsquo;
  • &apos;
  1. Which ones are invalid for an HTML 4.01 document?
  2. Which ones are invalid for an XHTML 1.0 document?
  3. Which ones are invalid for a generic XML document? (assume no DTD or Schema)

Media Types (MIME)

  1. Which of these MIME types SHOULD NOT be used for an XHTML 1.1 document?
    • application/xhtml+xml
    • text/html
    • application/xml
    • text/xml
  2. Using the answer from the previous question, under what conditions MAY (according to the recommendation) an XHTML 1.0 document use that MIME type?