SIGIA-L Mail Archives: SIGIA-L: Show Dropdowns on Click or Roll
SIGIA-L: Show Dropdowns on Click or Rollover?
From: Dan Hoffman (dhoffman_at_exchange-east.xceed.com)
Date: Mon Jan 22 2001 - 13:27:48 EST
This is related to a comment re the IHT site, but since, it's an issue that
applies more generally, I'm starting a new thread.
Craig Chalmers made the point that there were a number of good reasons for
revealing drop-down menus on click, rather than on rollover. I agree with
many of Craig's points, but I've done a number of sites with DHTML drop-down
menus, and the reason I haven't often designed that way is because the menu
title is often itself a destination page. For example, I worked on an
apparel site where there was a "Men's" pulldown menu (shirts, pants,
sweaters, etc.), but also a main "Men's" page. The most intuitive way to
design access to the Men's main page is to have the user just click "Men's"
(the menu title). If instead, clicking "Men's" were to open the pulldown,
then what's the action to go the Men's main page? Click "Men's" a second
time? Double-click it? I don't think users would intuitively expect either
of those. In this context, it just seemed like the most intuitive approach
was to have a rollover of the title display the drop-down, and a click of
the title bring you to the section main page.
This issue doesn't exist in software menus (regardless of platform) because
the menu titles (such as "File", "Edit", "Help") are just categories of
options, not options themselves. For example, you can execute the File
options "Save", "Open", "Print", etc., but you cannot execute "File".
I'd be curious to hear more on this.
Dan
Dan Hoffman
Creative Director
Xceed, Inc. (www.xceed.com)
212-553-2063
> ----------
> From: Craig Chalmers
> Reply To: cchalmers_at_i-storm.com
> Sent: Friday, January 19, 2001 6:18 PM
> To: 'George Olsen'; sigia-l_at_asis.org
> Subject: RE: SIGIA-L: IHT Layout
>
> Another "Good":
>
> I like how the designer chose to mimic the standard Windows functionality
> on
> the toolbars. Usually a page that employs DHTML dropdown menu items
> becomes
> annoyingly cluttered as you mouse around the page. I like what they do
> here--making the user click on an item, such as "regions", before seeing
> the
> drop-down menu. Not only does this preserve the clean look of the page,
> but
> it also places the user in the familiar setting of a Windows-type
> application. Another cool part to this feature is that the dropdown menu
> does not collapse on mouseOut--the user must click anywhere outside the
> menu
> in order to make it collapse. This is also in keeping with Windows
> functionality.
>
> I find that most applications of DHTML dropdowns do not follow this model
> and, as a result, are very disconcerting.
>
> <2 cents>
>
> Craig Chalmers
> Information Architect
> I-Storm
> 650.318.0332
> cchalmers_at_i-storm.com
>
>
> -----Original Message-----
> From: owner-sigia-l_at_asis.org [mailto:owner-sigia-l_at_asis.org]On Behalf Of
> George Olsen
> Sent: Friday, January 19, 2001 1:09 PM
> To: sigia-l_at_asis.org
> Subject: Re: SIGIA-L: IHT Layout
>
>
> >Blake Carver wrote:
> >
> >http://www.iht.com/articles/7694.html
> >
> >It's an interesting story, if you're a librarian, but the layout of the
> page
> >is like nothing I've seen in a few ways.
>
> I think the concept is brillant -- but there are some problems in the
> implementation. I think some of the complaints about readability are in
> part simply because it's different than what we're used to, and likely
> would be less of an issue with familiarity.
>
> The good:
>
> * Starts thinking in terms of web "screens" rather than web "pages."
> Because the text is pre-loaded in hidden layers, clicking to the next
> screen is much faster than hitting the server.
>
> * Multi-column layouts generally more readable over columns that span the
> width of the screen. I think some of the problems people have notes are
> due
> to other reasons (see below).
>
> * Giving the ability for users to change type sizes in an obvious way.
> (Yeah, IE has this, but I'm not sure how many users are aware it's there.)
> I especially liked how the number of pages automatically adjusts as the
> type size changes.
>
> * Leaving the "next/previous" buttons on-screen in "one-column view" does
> preserve interface consistency -- the problem is that it's not clear they
> don't work. Using a darker gray or color for the buttons would've allowed
> them to be "grayed out" in this instance, and since it's a common
> operating
> system conventation to "grey out" non-fuctional items on a menu, it would
> be easily understood. The same conventions should be used for the
> "previous" button on the first page, and the "next button" on the last --
> where neither is functional.
>
> The bad
>
> * The medium gray text is less readable than darker (or black) text. This
> may be one reason the eye wanders.
>
> * More importantly, the column widths are too narrow, given the inherent
> increased difficulties of on-screen reading (compounded by the text
> colors). A two-column format probably would've worked better.
>
> * The "gutters" (white space between the columns) are probably too narrow
> as well, which again allows the eye to wander.
>
> * The icons don't clearly indicate the diffence between the "one-column
> single-page" view and the "three-columns, multi-page view." This could be
> fixed easily, but adding "pages" to "three-column" icon, like this:
>
> _____
> | - - |_
> | - - ||
> |_____||
> |_____|
>
> since the icon already has the "bent corner" that's associated with
> "page."
> This could also be clarified in the status window message -- although few
> people bother to look there. A really nice addition would be a "tool tip"
> that appears if the cursor lingers over the button for a second or two.
>
> The ugly
>
> * After you've switched to one-column view, clicking on the three-column
> button only produces two columns of mismatched lengths (at least on Mac
> IE). I'll give the designer the benefit of the doubt and assume it works
> on
> Windows IE (albeit not on NS). In an ideal world, browsers would support
> standards so that stuff would work reliably, but we're not there yet. In
> lieu of that, since the site appears to be database-drive anyway, it would
> have been nice to do some browser detection and substitute less-capable
> but
> properly functioning versions for older/less capable browsers.
>
>
> Wish they've done
>
> * Since people might have a strong preference for which view, it would've
> been nice to be able to set a preference for the site -- an "always shown
> it this way" button.
>
> * Since monitor size varies widely, having "intelligent" columning that
> tries to keep column width within an optimal range and varies the number
> of
> columns depending on the browser size.
>
> * The related topics sidebar gets pushed to the end of the article, where
> people may not see it. (Looking at some other stories, it turns out this
> isn't actually a sidebar, it's positioned at the end of the article -- the
> column breaks just made it appear to be a sidebar in this case.) That
> said,
> it would be better to make secondary material available on all pages. In
> fact, two wider columns, plus a narrow column for secondary material would
> probably result in a better column width for the main story (three columns
> are too narrow and two columns without a sidebar may be a little too
> wide).
>
>
> _____________________________________________________________________
> George Olsen george.olsen_at_pobox.com
> User Experience Architect at-large 310-403-0301
>
>
>
>
>
>
>
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:28 EST
|
