[kepler-dev] Simple Search

[Bertram Ludaescher]

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> 
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> 
SB> To me it looks funny ... but it isn't a big deal.
SB> 
SB> -shawn
SB> 
SB> 
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> _______________________________________________
SB> Kepler-dev mailing list
SB> Kepler-dev at ecoinformatics.org
SB> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev