[kepler-dev] Simple Search
Laura L. Downey
ldowney at lternet.edu
Fri Nov 4 11:09:43 PST 2005
Thanks for that reminder Jing. I don't think a savings of 2 letters though
really buys you much in screen real estate. The most common word for
canceling an operation is "cancel." And again we want to be consistent in
our use of terminology. Part of the re-design involves standardizing lots
of dialogs with "ok" and "cancel." And also using words like "save," and
"apply" instead of programmer or database terms like "commit."
Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM 87131-0001
ldowney at lternet.edu
From: Jing Tao [mailto:tao at nceas.ucsb.edu]
Sent: Friday, November 04, 2005 12:35 PM
To: Laura L. Downey
Cc: 'Bertram Ludaescher'; 'Shawn Bowers'; kepler-dev at ecoinformatics.org
Subject: Re: [kepler-dev] Simple Search
For data search, the "cancel" buttion was implemented long time ago in
Kepler. And we call it "Stop" rather than "cancel" because it has less
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101
On Fri, 4 Nov 2005, Laura L. Downey wrote:
> Date: Fri, 4 Nov 2005 11:33:12 -0700
> From: Laura L. Downey <ldowney at lternet.edu>
> To: 'Bertram Ludaescher' <ludaesch at ucdavis.edu>,
> 'Shawn Bowers' <sbowers at ucdavis.edu>
> Cc: kepler-dev at ecoinformatics.org
> Subject: Re: [kepler-dev] Simple Search
> Shawn, I confess that your comment about a search button being named
> 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
> 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
> might change their mind and want to search on something else. This need
> 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
> 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
> navigate to them. Users expect resetting and canceling functions
> with the current task to be directly accessible -- think for example of
> 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
> We need an advanced search button (and that phrase is common across tons
> search functions) so that we can support power users.
> We need the sources button or whatever we want to call it because our
> has the ability to select whether it is searching locally or on the
> 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
> 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
> 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
> 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
> 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
> 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> Reset in google is called the "back" button in your web browser. My
> 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
> 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
>>>>>> 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
> 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
> too, but
> SB> one has to take it with a grain of salt, in particular, i think it is
> SB> obvious that these buttons apply to search (especially with the named
> 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
> 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
>>>>> for a search panel - although the "preferences" alternatives may be
>>>>> 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,
>>>>> [LLD>] sources is used because it is linked to the data sources dialog
>>>>> data sources was a bit long -- once the user goes there one time they
>>>>> then know what the word sources means. We could consider the word
>>>>> 'configure' but by choosing sources I'm trying to reinforce "data
>>>>> 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
>>>>> doing something very similar for the sources for actor search (adding
>>>>> MoML type etc.).
>>>>> [LLD>] We don't currently have a global preferences or configuration
>>>>> so that is another reason I didn't break this off to something like
>>>>> However even if we did, this sources config is so specific to search
>>>>> data (and there will be something specific for search for actors) that
>>>>> 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
>>>>> "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
>>>>> tell 'em; then *tell* 'em; then tell 'em what you *told* 'em"
>>>>> [LLD>] couldn't have said it better myself Matthew ;-) And I'll add
>>>>> consistency is the key here and making sure not to use the totally
>>>>> 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
>>>>> agree on something that is totally confusing. I'd also point out that
>>>>> difference between go and search is probably not some major usability
>>>>> 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
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev