[kepler-dev] Simple Search
sbowers at ucdavis.edu
Fri Nov 4 07:26:24 PST 2005
Reset in google is called the "back" button in your web browser. My point
is that the naming of buttons seems fairly inconsistent and over
redundant. It is also unusual to have five buttons for "quick search".
On Fri, 4 Nov 2005, Bertram Ludaescher wrote:
> Advanced Search is very common (see the google 'Advanced Search').
> Reset Search isn't.
> my $0.02
> >>> On Thu, 03 Nov 2005 17:05:23 -0800
> >>> Shawn Bowers <sbowers at ucdavis.edu> wrote:
> SB> Just a small note. I think the use of the term "search" on the buttons in the
> SB> design is inconsistent. For example, why does it say "advanced search" but not
> SB> "reset search" and "sources for search"? I think redundancy can be good too, but
> SB> one has to take it with a grain of salt, in particular, i think it is pretty
> SB> obvious that these buttons apply to search (especially with the named border)
> SB> without having to say it on every single button (or any of them). If things are
> SB> inconsistent and over-redundant I think that also has an affect on the overall
> SB> usability and general impression.
> SB> To me it looks funny ... but it isn't a big deal.
> SB> -shawn
> SB> Laura L. Downey wrote:
> >> See comments below.....
> >> Laura L. Downey
> >> Senior Usability Engineer
> >> LTER Network Office
> >> Department of Biology, MSC03 2020
> >> 1 University of New Mexico
> >> Albuquerque, NM 87131-0001
> >> 505.277.3157 phone
> >> 505.277-2541 fax
> >> ldowney at lternet.edu
> >> --------------------------------------------
> >> Hi Shawn -
> >> I concur with your views on the "source" button - that's an unusual word
> >> for a search panel - although the "preferences" alternatives may be too
> >> indirect. I think we need to make the user aware "up front" that there
> >> is a choice of locations that may be searched, otherwise they may miss
> >> this point and not find what they need. Any other wording suggestions,
> >> anyone?
> >> [LLD>] sources is used because it is linked to the data sources dialog and
> >> data sources was a bit long -- once the user goes there one time they will
> >> then know what the word sources means. We could consider the word
> >> 'configure' but by choosing sources I'm trying to reinforce "data sources"
> >> that is used in the dialog the button is connected to. And yes it is
> >> important the user know up front that they can configure data sources to be
> >> searched which is why this is there. And as Matt pointed out we will be
> >> doing something very similar for the sources for actor search (adding the
> >> MoML type etc.).
> >> [LLD>] We don't currently have a global preferences or configuration section
> >> so that is another reason I didn't break this off to something like that.
> >> However even if we did, this sources config is so specific to search for
> >> data (and there will be something specific for search for actors) that I
> >> think it needs to be with the collection of things related to search so that
> >> the user doesn't have to go looking for some not so prominent global
> >> preferences dialog.
> >> I'd be inclined to just go with Laura's design with regard to the labels
> >> "go" vs. "search" etc, because the buttons need to be a uniform size
> >> anyway - we don't gain anything by having a shorter label ("go") - it
> >> doesn't allow us to have a narrower button, since we need to maintain
> >> consistency. Based on that criterion, it then comes down to a question
> >> of who prefers which word... which isn't really worth spending our
> >> valuable time debating.
> >> Redundancy is sometimes a good thing for reinforcement purposes.
> >> Remember the old rule of public speaking - "Tell 'em what you're *gonna*
> >> tell 'em; then *tell* 'em; then tell 'em what you *told* 'em"
> >> :o)
> >> [LLD>] couldn't have said it better myself Matthew ;-) And I'll add that
> >> consistency is the key here and making sure not to use the totally incorrect
> >> word. The HCI research shows that people generally only agree about 10% of
> >> the time on what the one exact "right" word should be, but they generally
> >> agree on something that is totally confusing. I'd also point out that the
> >> difference between go and search is probably not some major usability issue
> >> to worry about since we have plenty of bigger issues to deal with.
> SB> _______________________________________________
> SB> Kepler-dev mailing list
> SB> Kepler-dev at ecoinformatics.org
> SB> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
More information about the Kepler-dev