[kepler-dev] Simple Search

Sat Nov 5 06:10:52 PST 2005

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.

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 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.

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.

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.

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
> >>
>
>