All posts by Lachlan Hunt

Web Developer Quiz Answers

Characters, General, MarkUp, Standards

These are the answers to last week’s Web Developer Quiz. If you have not attempted the quiz yourself, I recommend you do so before reading the following answers. All the responses to the quiz from ealier this week were made public earlier today.

Validation

There is only one error within the sample document, validate it and see for yourself:

Line 4, column 11: there is no attribute “ALIGN”

The align attribute is not valid in HTML 4.01 Strict because it is deprecated. It is valid in HTML 4.01 Transitional. For information about why line 7 isn’t an error, refer to the validation quiz and associated answers I published earlier.

Elements in the DOM

There are 3 p elements within the document. The syntax: <> in an empty start-tag, an unsupported SHORTTAG feature from SGML. It basically means to open the most recent unclosed element. Similarly, </> is an empty end-tag which ends the most recent open element.

The em element will not be present because, despite appearances to the contrary, it is actually commented out. The head and body elements will still be present, even though their start- and end-tags have been omitted.

Validate it and look at the Parse Tree to confirm these answers.

Semantics

The unordered list (option 3) is the most semantically correct. A stylesheet may be used to style it in any way desired.

The <h1> element without the style attribute or the class attribute with a presentational class name is the most appropriate markup for a document title. An external stylesheet may be used, and is the recommended way, to horizontally centre it in a visual medium using a large, bold font. The use of the style attribute or the presentational class name is not recommended because it fails to separate the markup from the presentation.

Everyone got these 2 questions correct. Well done. In hindsight, I wish I had made these more difficult, but since semantics is not an exact science, I found that (in general) the more complicated the question, the less specific the answer could be. So, I settled for relatively easy questions for things that beginners tend to markup poorly.

Character References

  • For an HTML 4.01 document: the numeric character reference: &#146; and the character entity reference: &apos; are invalid.
  • For an XHTML 1.0 document: technically, none of them are invalid; however the numeric character reference: &#146;, while it is not prohibited in XML, refers to a Unicode control character and should not be used anyway.
  • For a generic XML document with no DTD, only the character entity reference: &rsquo; is invalid. &apos; is valid because it is one of the 5 predefined entities in XML.

Since few people correctly answered these questions, I will be providing more information about this in tomorrow’s post.

Media Types (MIME)

An XHTML 1.1 document SHOULD NOT be served with the text/html MIME type. See the XHTML Media Types Note for more information.

An XHTML 1.0 document MAY be served as text/html when the document conforms to the Appendix C HTML Compatibility Guidelines in the XHTML 1.0 Recommendation. Those who pointed out that this is ludicrous get a bonus point.

If any of you have any questions or comments regarding this quiz, please feel free to let me know. The feedback I have recieved, or will recieve, regarding this quiz will help me a lot with the next one I’m planning, which will most likely be a CSS quiz of some kind, possibly followed by a JavaScript/DOM quiz if I have time. Beyond that, well, you’ll have to wait and see.

Firefox Interface

Mozilla, User Agents

A while ago, Scott Berkun – one of the developers of early versions of IE – announced 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.