[kepler-dev] Simple Search

Bertram Ludaescher ludaesch at ucdavis.edu
Fri Nov 4 08:16:54 PST 2005

>>> On Fri, 4 Nov 2005 07:26:24 -0800 (PST)
>>> Shawn Bowers <sbowers at ucdavis.edu> wrote: 
SB> Reset in google is called the "back" button in your web browser.  My point

but I think there is a difference in functionality: if you hit 'back'
then the server might still be choking on your previous request ;-)
In contrast, 'reset' would actively reset something somehwhere (I

SB> is that the naming of buttons seems fairly inconsistent and over
SB> redundant.  It is also unusual to have five buttons for "quick search".

I agree with the latter. 5 buttons for quick search is probably 3 too
many or so.. maybe just search and advanced search? 

SB> -shawn
SB> 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
>> Bertram
>> >>> 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 mailing list