[kepler-dev] Simple Search

[Matt Jones]

I'm largely in agreement with Shawn, with a few caveats.  Number one is 
that we need to make forward progress over the short term, and so its 
clear we will not be able to tackle everything we would like.  A few 
other comments inline...

Shawn Bowers wrote:
> Laura, please see my comments below.
> 
> On Fri, 4 Nov 2005, Laura L. Downey wrote:
> 
> 
>>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.
> 
> 
> I never actually said that the button being named search is inconsistent,
> I was referring to the design of the entire panel itself. My main concern
> is that the current design is not what one usually finds (for more reasons
> than just the names of buttons though), and might be displaying and trying
> to do too much stuff. I think there are some serious questions about what
> these buttons are supposed to be doing, in particular, "sources."
> 
> What I said was that the use of the word "search" isn't being applied
> uniformly *across* the buttons.  (And in a very simple sense, i.e., if you
> are going to add "search" to some buttons, you should use the term
> "search" in all the buttons to be consistent with the over use of the term
> "search".) It is also clear with the grouping that all buttons apply to
> the search task, so it may not be necessary to repeat the word "search" in
> the buttons themselves. (I prefer "Go" and "Advanced", e.g., or even just
> "advanced" where hitting "enter" performs the search, the "go" function.)
> 
> But, there are more serious issues than this ....
> 
> 
>>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.
> 
> 
> It seems like the actual reason for needing the "reset" in the first place
> has been lost/buried in discussions of re-working the layout. In
> particular, this button is needed because the component that displays
> search results for actors is serving two somewhat orthogonal purposes: one
> is for displaying search results, the other is for navigating and browsing
> the existing actors. "Reset" is letting you get from one back to the
> other.
> 
> This is a unique feature of the actor tab, and thus, reset is not needed
> for the data side.
Not really true.  Although we haven't managed to implement it yet, we 
have intended to have locally saved data that could be browsable via its 
  classification into a data ontology.  For people that use Morpho, we 
could expose the morpho data stores.  We will also want people to be 
able to access other data sets they might have on disk.  So browsing was 
intended to (eventually) extend to data too.

> 
> I think the question to ask users (if any at this point) is not whether
> the reset button is needed, but if this notion of mixing navigation and
> browsing is really appropriate. I think early on this was a discussion the
> developers had, and we decided to just try it out. However, I think we
> should seriously consider whether this is the right
> interface/functionality, or if we should try something different.
I agree, but I actually think we should consider this in a post-release 
scenario.  The initial discussions between Chad, Shawn, me, and others 
included several other arrangements of components where browse and 
search were not mixed.  We certainly can consider this again, especially 
as the whole 'shopping cart' functionality that we discussed in Estes 
Park has not been fully designed.  So I htink we should give some 
serious thought to this overall system and UI design.

> 
> I am currently leaning towards repurposing what is now called the actors
> tab to a "local components" tab, for lack of a better name; and the "data"
> tab to an "external components" tab. Local components can be browsed and
> searched -- but with a very simple search interface, and remote ones can
> be searched with a more feature-rich interface.
Maybe.  But there is no reason to not provide a rich search interface 
for local components.  Local data can make just as much use of the 
advanced search dialog as remote data.
> 
> Based on the current mixed functionality, maybe you can explain better how
> the "source" button fits into this browsing/navigating/searching results
> window.  Because I am a bit lost.
Right now EcoGrid is a distributed search, reflecting the reality that 
there is not now (nor will there ever be) a centralized database or 
index of all of data of interest to kepler scientists.  Given a 
distributed search and a system that isn't too smart about what data 
nodes contain various kinds of data, the 'Sources' list allows the user 
to use their superior jusgement to select a set of nodes to search. 
This is a practical necessity for the near term.

> 
> In my personal opinion, I think we need to get back to basics, and before
> making changes by adding buttons and so on, we need to figure out what the
> functionality is supposed to be.
> 
> 
>>Or burying the reset and cancel functions somewhere else is not good
>>design either.
> 
> 
> I don't recall anyone suggesting this.
> 
> 
>>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.
It is fairly often used in distributed data systems with hundreds of 
nodes.  Look at, for example, the NSDI or NBII clearinghouses.  Most 
web-based search mechanisms (e.g., Google) are centralized databases 
that don't pose these problems, even though the web itself is 
distributed.  Eventually I'd like to see the 'Sources' choice go away in 
favor of a smart node selection system (where the user's search can 
automatically be routed to only the appropriate nodes), but this is a 
long way off I think.

Matt
> 
> 
> As stated above, I think this functionality needs more thinking about in
> terms of the implications for the current design/functionality, especially
> with the use of browsing and searching in the same component.
> 
> 
>>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.
> 
> 
> Again, I haven't heard any comments concerning this "source" feature that
> clarify how the component's current functionality would behave for the
> actors tab. I think at this point user testing of the "sources"  button
> would be premature.
> 
> -shawn
> 
> 
>>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
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matt Jones
jones at nceas.ucsb.edu                         Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara     http://www.nceas.ucsb.edu/ecoinformatics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~