Archive Page 2

On pages 10-11 of Designing Web Navigation,  James Kalbach does a nice job of pointing out the tight interlinkage between effective navigational design and effective information access – this time in connection not with how to find information, exactly, but how to know when you’ve found it, and what it relates to. 

As Kalbach puts it, navigation design implicitly answers three questions:

  • where am I?
  • what’s here?
  • where can I go from here?
The answers to these three questions add up to information context: through navigation, users come to understand what other pages they have to view to understand the one they’re looking at, the precision (or vagueness) of the information they’re looking at, and, relatedly, when they’ve come to the end of their search and there’s no more information to see.
One conclusion to draw from this is that site structure has to be to some extent visible on the page for context to be maximally understood; another is that natural predispositions (such as the assumptions that pages nested deep in the hierarchy will be more specific and precise than those at the top) should be catered to.
Navigation offers visitors a semantic peripheral vision of a site’s content. [Kalbach, Designing Web Navigation, 13]

Nothing to do with information design, this one – just a note on a Flex bug I’m hoping might be useful to anyone else who tries punching the cryptic error messages they’re receiving into Google.

I’ve been playing around with Flex lately, and so far it’s great – it lets you play around with functionality and design with incredible intuitiveness. 

Unfortunately, the Flex 3 Builder doesn’t handle CSS very well. two problems I’ve run into so far:

(1) Underscores not allowed in CSS selector names: for some reason (the Adobe note on the problem isn’t terribly helpful), Flex will not allow you to use an underscore character (‘_’) in CSS selectors.

Unfortunately, it doesn’t identify the problem as such. Instead, Flex reports it (as it does all CSS faults, as far as I can tell) as a difficulty with the root Application element using the message ‘There is an error at line n of your MXML document: the “Application” tag has invalid syntax’.  Naive users unfamiliar with Flex may then waste a good couple of hours trying to figure out what the $#%^ could possibly be wrong with a well-formed <mx:Application /> tag.

Remove the underscore, however, and the problem disappears.

(2) A second CSS difficulty comes with the ‘Convert to CSS …’ button (in the ‘Flex Properties’ window Standard View).

The idea behind this button is a great one: doodle the look ‘n’ feel of a component in the Flex Design View, then hit the button to universalize it using a CSS stylesheet.

The problem is that the syntax of the Embed directive is different, depending on whether it’s used in the MXML or the CSS file. In the latter, you don’t/can’t use the ‘@’ prefix necessary for the former  - but Flex doesn’t remove it automatically when performing its CSS conversion. The result is that you once again get a fault reported with the MXML root, when the difficulty is instead in the CSS document.

Both of these are pretty minor niggles in an otherwise incredibly helpful tool – but because they’re minor and syntactical, and especially because the error-reporting isn’t great, they can be a real timesuck on your project …

 


Notes on Designing Web Navigation by James Kalbach (O’Reilly 2007)

James Kalbach opens his book by stepping back from issues of navigation design with the question – is a navigation structure necessary at all? He then goes on to outline a number of alternative models that have been proposed, along with examples of each.

The entries you see below are short summaries of the opinions presented in the book, along with occasional brief reflections on my part. More extended remarks and … erm … musings (my god, I hate that word) … can be reached by clicking on the ‘Continue reading …’ link at the bottom of the post.

Kalbach’s conclusion is that each of these ‘pure’ models of navigation is optimized for particular purposes, and that most sites combine them into a structure he calls ‘balanced navigation’. At first I thought this was a rather predictable end result. Later I realized that taking all these varied models into account does radically restructure how I’d been thinking about web design. I’d really been looking at navigation purely in terms of the navbars, rather than as a system of inter-related structures – links in content, search engines, etc. Obviously, though, they all function together in terms of end-user experience.

Continue reading ‘Web navigation – is it necessary? Overview’


The Content-Linking-Only Model

This navigation model is that often found in amateur websites in the early days of the web. In this model, the only way to navigate around the site is by links embedded in the body of page text.

  • Pros: no ‘navigational burden’ imposed on the reader, who doesn’t have to master any ‘navigation system’ for the site.
  • Cons: information retrieval is very difficult – all content must be scanned for links to be perceived and understood

Continue reading ‘Web navigation – is it necessary? (1)’


The ‘Liquid Information’ model

This one’s just strange. In this model, every single word in any document functions as a link, being associated with a menu of options allowing you to select what kind of linkage you wish to follow. Apparently this will put an end to the ‘tyranny of links’, but I’m not so sure.

To get an idea of what this would involve, you can take a look at the Hyperwords demo; alternatively, you can get it as a Firefox 3 add-on.

Continue reading ‘Web navigation – is it necessary? (2)’


The Filter Model

In this model, the browser interface works to winnow the possible result set based on user settings: that is to say, the site in question consists in essence of a huge number of documents, and by manipulating various parameters this unmanageably-large repository is filtered to a manageable number of useful documents.If you’re finding this hard to picture, that’s because it is. The only example Kalbach gives of this kind of ‘navigation’ is The Glass Engine. I find this indescribably cool; and also utterly incomprehensible.
Continue reading ‘Web navigation – is it necessary? (3)’


The Search Model

This one’s pretty much self-explanatory: the user is given a search box, and this is his or her only means of navigating the site. As Kalbach points out, in its pure form this is problematic, as it assumes the user already knows what s/he’s looking for.


The Structural Browse Model

This style of navigation is one I associate more with file structures than with web-navigation (although with the release of things like Adobe’s AIR and the various Google apps, the line is becoming blurred). In the Structural Browse model, the user is provided with a persistent image of a hierarchy of documents – each element of which can be opened to display the next level down on the hierarchy. Think of the way Windows Explorer or Mac OS X work when you’re ‘Saving As …’, and you’re there.

Continue reading ‘Web navigation – is it necessary? (5)’