[kepler-dev] Simple Search

Laura L. Downey ldowney at lternet.edu
Fri Nov 4 10:33:12 PST 2005


Shawn, I confess that your comment about a search button being named search
being inconsistent doesn't make a whole lot of sense to me.  Or that you
think having Search in the group box title is so over-redundant as to make
something not usable or gives some negative impression.

As to the current five button design, there is a specific reason for the
buttons that are there.

We need a search button to perform the search.

We need a reset button to get back to the original state (that is not needed
in regular search engines because they start out blank).  This need is
supported by user testing results.

We need a cancel button because the search can take a long time and/or users
might change their mind and want to search on something else.  This need is
also supported by user testing.  Making users wait until the system is
finished before they can perform another search is simply not good design.  

Or burying the reset and cancel functions somewhere else is not good design
either.  Grouping controls together for a specific task is standard design
practice.  I can't imagine putting the buttons for resetting a screen from
search or canceling a search somewhere else in the application like in a
menu or something -- that would force the user to go looking for them and to
navigate to them.  Users expect resetting and canceling functions associated
with the current task to be directly accessible -- think for example of form
design or even dialog box design, you have reset to clear a form or cancel
to get out of the action.  You have ok and cancel in a dialog box.  These
actions give the user control over their tasks and are directly accessible.

We need an advanced search button (and that phrase is common across tons of
search functions) so that we can support power users.

We need the sources button or whatever we want to call it because our system
has the ability to select whether it is searching locally or on the ecogrid
and also what it might be searching on the ecogrid.  This functionality is
very specific to kepler and is not common in standard search engines.  

I don't know if I agree that the "sources" functionality should not be
exposed at the top level but I'm sure we could look at that during some user
testing.  I know Matt mentioned elsewhere about putting it on the advanced
search screen but it isn't really part of the advanced search task and that
screen is already fairly busy with what we are trying to support.  One of
the reasons I did include it is because we had some screen real estate to
utilize since I wasn't going to put 4 buttons across.  The search, reset and
cancel buttons go together to deal with the simple search box, and the
sources and advanced search buttons are secondary because they are more
advanced tasks but still related overall to the search functionality we are
providing.  And if there is no compelling reason to put a function in a
lower level and we have room for it, then letting it remain at the top level
means one less thing a user has to remember when they do need to use it.

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
 
-----Original Message-----
From: Bertram Ludaescher [mailto:ludaesch at ucdavis.edu] 
Sent: Friday, November 04, 2005 9:17 AM
To: Shawn Bowers
Cc: Bertram Ludaescher; Laura L. Downey; kepler-dev at ecoinformatics.org
Subject: Re: [kepler-dev] Simple Search

>>> On Fri, 4 Nov 2005 07:26:24 -0800 (PST)
>>> Shawn Bowers <sbowers at ucdavis.edu> wrote: 
SB> 
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
suppose) 

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> 
SB> -shawn
SB> 
SB> On Fri, 4 Nov 2005, Bertram Ludaescher wrote:
SB> 
>> 
>> 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
>> 




More information about the Kepler-dev mailing list