[kepler-dev] Simple Search

Fri Nov 4 14:05:47 PST 2005

Hi, Laura:

Thanks. If you have any suggestion, let me know.

Jing

Jing Tao
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 13:15:40 -0700
> From: Laura L. Downey <ldowney at lternet.edu>
> To: 'Jing Tao' <tao at nceas.ucsb.edu>
> Cc: 'Bertram Ludaescher' <ludaesch at ucdavis.edu>,
>     'Shawn Bowers' <sbowers at ucdavis.edu>, kepler-dev at ecoinformatics.org
> Subject: RE: [kepler-dev] Simple Search
> 
> Hi Jing,
>
> I didn't realize you had re-designed those dialogs dealing with choosing
> data sources and search the ecogrid.  I'll take a look.  I have some
> proposed re-designs for those too as Matt had asked me to tackle them a
> while back.  They were definitely confusing originally.
>
> As to having room for a cancel button, yes I think we will be just fine in
> that regard.  I've also been thinking of a way to hide the left tabbed
> section if the user desires so that a majority of the screen real estate can
> be used to display more of the workflow.  I think I filed a bug on that a
> while back.  And also Ferdinando just recently was commenting to me about
> possible similar functionality.
>
> 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: Jing Tao [mailto:tao at nceas.ucsb.edu]
> Sent: Friday, November 04, 2005 1:29 PM
> To: Laura L. Downey
> Cc: 'Bertram Ludaescher'; 'Shawn Bowers'; kepler-dev at ecoinformatics.org
> Subject: RE: [kepler-dev] Simple Search
>
> Hi, Laura:
>
> Actually i tried to use "Cancel" first. But our search pane is not wide
> enough to contain a button which can hold the 6 letters. So I have to use
> "Stop". Probably after re-design we can use it.
>
> By the way, I re-design and implemented the data source selection window
> (After clicking source button). It is much clearer now.
>
> Thanks,
>
> Jing
>
> Jing Tao
> 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 12:09:43 -0700
>> From: Laura L. Downey <ldowney at lternet.edu>
>> To: 'Jing Tao' <tao at nceas.ucsb.edu>
>> Cc: 'Bertram Ludaescher' <ludaesch at ucdavis.edu>,
>>     'Shawn Bowers' <sbowers at ucdavis.edu>, kepler-dev at ecoinformatics.org
>> Subject: RE: [kepler-dev] Simple Search
>>
>> 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
>> 505.277.3157 phone
>> 505.277-2541 fax
>> ldowney at lternet.edu
>>
>>
>> -----Original Message-----
>> 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
>> letters.
>>
>> Thanks,
>>
>> Jing
>>
>> Jing Tao
>> 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
>> 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
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>
>>>
>>
>>
>
>
>