[kepler-dev] Simple Search
Bertram Ludaescher
ludaesch at ucdavis.edu
Fri Nov 4 06:58:17 PST 2005
>>> On Thu, 03 Nov 2005 14:19:49 -0900
>>> Matt Jones <jones at nceas.ucsb.edu> wrote:
MJ>
MJ> Yeah, we debated whether or not to have the source button so visible or
MJ> whether to bury it in prefs. Burying it means few or no users would
MJ> regularly use it. As the distributed searches can take a while,
Is someone looking at the issue why? And how to solve it?
(a special kind of bug for sure -- make the system faster ;-)
MJ> sometimes its nice to disable several EcoGrid nodes so that the results
MJ> from a single node return faster.
I think that's only a workaround, not a solution. Could we change (not
today, but in the future) the result return protocol of the EcoGrid to
a "streaming mode"? That is, results appear as they come in?
And why do EG-searches take so long in the first place (first-time or
not..)? Do we have an analysis where the time is spent?
Seems we might have an indexing challenge somewhere.. Our searches are
by keyword or concept name it seems, but not complex nested-queries
with cyclic, multi-way joins and aggregations ... So why aren't they
blindingly fast?
MJ> This will be more needed as the
MJ> number of nodes grows -- but it also placesa burden onto the user to
MJ> know what nodes they want or need to search. Today its pragmatically
right; we can't outsource/work-around the problem that way..
MJ> useful, but it would be nice if we could eliminate it altogether and
MJ> simply direct searches to the most appropriate nodes automatically. For
.. and use indexing. Maybe even a warehousing approach. One big
warehouse with efficient index structures for the kinds of searches we
do.. can't beat that one I think ;)
MJ> example, there is no need to search EcoGrid nodes for actors and
MJ> worflows if that node does not contain any KAR files, so some useful
MJ> coverage metadata in the EcoGrid registry could help the client
MJ> eliminate a bunch of nodes from the search without user intervention.
yep, so approaches have been also been the subject of research in the
db community
MJ> We have a facility set up for this node-level metadata in the EcoGrid
MJ> registry but are not currently using it because we haven't decided what
MJ> metadata we want for each node -- its something we should start using.
MJ>
MJ> In summary I'd support moving the Sources button to Preferences, or
MJ> maybe to advanced search when it is created, and renaming it to make it
MJ> clear what it is for?
my suggestion on the source button issue:
It could be "semi-hidden" under the Advanced-Search button. Not in an
obscure place (like Preferences), yet not in the face of most users
who hopefully won't need it. There should be "good" default settings:
with efficient EcoGrid search mechanisms we might be able to query a
single index-server (or as we scale to thousands of users, a network
of those.. this one for later..)
Bertram
MJ>
MJ> Matt
MJ>
MJ> Matthew Brooke wrote:
>>
>> 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?
>>
>> 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)
>>
>> m
>>
>>
>>
>>
>>
>> Shawn Bowers wrote:
>>
>>> I wonder whether we actually need the "sources" button to be so "up
>>> front" in the Kepler interface. At a minimum, I think we need to
>>> change the name. Here are some suggestions on what we could do with
>>> the "sources" button:
>>>
>>> 1. Rename it to something like "Configure" or "Preferences" (a la
>>> google)
>>> 2. Move it to the advanced search dialog
>>> 3. Move it to something that manages "preferences" (usually Tools >
>>> Options)
>>>
>>> Also, in the png Laura sent, I think there is some naming redundancy,
>>> which would allow the names to be simplified. For example, there is a
>>> named border around the quick search textfield and buttons that is
>>> called "search". And, the button to perform the search is also called
>>> "search." I think using "go" instead of "search" for the button is ok
>>> in this situation ... and is a shorter label. Also, the "Advanced
>>> Search" button could loose the "Search" and just be "Advanced," again
>>> because it is clear from the labels.
>>>
>>> What do other folks think?
>>>
>>> Shawn
>>>
>>>
>>>
>>> Matt Jones wrote:
>>> > Also, the "Sources" dialog for data determines which ecogrid nodes to
>>> > search, and for each one which metadata types to search. When we
>>> add in
>>> > the actor search capabilities, the nodes will simply add a new
>>> metadata
>>> > type to search (MoML). So the same dialog can probably be used.
>>> >
>>> > Matt
>>> >
>>> > Matt Jones wrote:
>>> >> Yep, going through the bugs yesterday someone definitely made that
>>> >> point. Its in bugzilla somewhere, maybe in a closed bug -- search
>>> for
>>> >> reset or cancel in the closed bugs.
>>> >>
>>> >> Matt
>>> >>
>>> >> Matthew Brooke wrote:
>>> >>
>>> >>> Hi Laura -
>>> >>>
>>> >>> Yep - I agree with you on the necessity for the cancel button,
>>> but I was
>>> >>> sure I'd read/heard some discussion that there would be major
>>> issues in
>>> >>> implementing it.
>>> >>>
>>> >>> Can anyone else on the list help out on this? Does it ring any
>>> bells? Or
>>> >>> has senility finally caught up with me?
>>> >>>
>>> >>> m
>>> >>>
>>> >>>
>>> >>> Laura L. Downey wrote:
>>> >>>
>>> >>>
>>> >>>> See below....
>>> >>>>
>>> >>>> Laura
>>> >>>>
>>> >>>> -----Original Message-----
>>> >>>> From: Matthew Brooke [mailto:brooke at nceas.ucsb.edu]
>>> >>>> Sent: Thursday, November 03, 2005 2:31 PM
>>> >>>> To: Laura L. Downey
>>> >>>> Cc: kepler-dev at ecoinformatics.org
>>> >>>> Subject: Re: [kepler-dev] Simple Search
>>> >>>>
>>> >>>> Hi Laura -
>>> >>>>
>>> >>>> Thanks for the response - more questions ;-)
>>> >>>>
>>> >>>> 1) I think i read in a bug or email somewhere that the "cancel"
>>> button
>>> >>>> won't be implemented in the near future, because it's
>>> non-trivial to do
>>> >>>> so. Did I read that, or am I hallucinating? I can't find
>>> anything in
>>> >>>> bugzilla now
>>> >>>>
>>> >>>> [LLD>] I don't remember that but I know a cancel function is
>>> essential, in
>>> >>>> case the user wants to stop the search for any reason (search is
>>> taking too
>>> >>>> long, user changes his/her mind and wants to search for
>>> something else etc.)
>>> >>>>
>>> >>>> [LLD>]During user testing this was a huge problem, especially
>>> since some of
>>> >>>> the ecogrid searches were taking like 5 and 10 minutes and we
>>> had no way to
>>> >>>> stop those searches without rebooting the machine. And since
>>> all the users
>>> >>>> were trying to hit the ecogrid at the same time this really put
>>> a dent in
>>> >>>> that part of the training and testing when that happened.
>>> >>>>
>>> >>>> [LLD>] Users need control of the application and should be able
>>> to cancel
>>> >>>> operations if they need or desire to.
>>> >>>>
>>> >>>> 2) What does the "source" button do in the simple search screen?
>>> >>>> Currently, only the data search tab has a "source" button
>>> >>>>
>>> >>>> [LLD>] See my previous answer to Shawn. :-)
>>> >>>>
>>> >>>> thanks
>>> >>>>
>>> >>>> m
>>> >>>>
>>> >>>>
>>> >>>> Laura L. Downey wrote:
>>> >>>>
>>> >>>>
>>> >>>>> Sample attached.
>>> >>>>>
>>> >>>>> 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: Shawn Bowers [mailto:sbowers at ucdavis.edu]
>>> >>>>> Sent: Thursday, November 03, 2005 2:05 PM
>>> >>>>> To: Laura L. Downey
>>> >>>>> Cc: 'Chad Berkley'; 'Matthew Brooke';
>>> kepler-dev at ecoinformatics.org
>>> >>>>> Subject: Re: [kepler-dev] Simple Search
>>> >>>>>
>>> >>>>> Laura, can you quickly give a pointer to a screen shot of how
>>> the five
>>> >>>>> buttons
>>> >>>>> should be placed.
>>> >>>>>
>>> >>>>> -shawn
>>> >>>>>
>>> >>>>> Laura L. Downey wrote:
>>> >>>>>
>>> >>>>>
>>> >>>>>> Sorry I meant to copy my response to Matthew to the list. He
>>> was using
>>> >>>> an
>>> >>>>
>>> >>>>
>>> >>>>>> old design as a reference. The current design does away with
>>> the text
>>> >>>> and
>>> >>>>
>>> >>>>
>>> >>>>>> concept checkboxes and contains actually five buttons:
>>> >>>>>>
>>> >>>>>> Search
>>> >>>>>> Reset
>>> >>>>>> Cancel
>>> >>>>>> Source
>>> >>>>>> Advanced Search
>>> >>>>>>
>>> >>>>>> So no I don't recommend that we get rid of the Reset button.
>>> This is
>>> >>>>>> something that came directly out of some simple user testing
>>> in which the
>>> >>>>>> users couldn't reset things back to the original "browse" or
>>> pre-search
>>> >>>>> view
>>> >>>>>
>>> >>>>>
>>> >>>>>> that Chad mentions.
>>> >>>>>>
>>> >>>>>> 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: Chad Berkley [mailto:berkley at nceas.ucsb.edu]
>>> >>>>>> Sent: Thursday, November 03, 2005 1:48 PM
>>> >>>>>> To: Matthew Brooke
>>> >>>>>> Cc: Laura L. Downey; kepler-dev at ecoinformatics.org
>>> >>>>>> Subject: Re: [kepler-dev] Simple Search
>>> >>>>>>
>>> >>>>>> Currently, the reset button is the only way to reset the
>>> search results
>>> >>>>>> to the pre-search view. If you do away with that button, you
>>> need to
>>> >>>>>> figure out some other way to get the tree back into the normal
>>> view.
>>> >>>>>>
>>> >>>>>> chad
>>> >>>>>>
>>> >>>>>> Matthew Brooke wrote:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>> Hi Laura -
>>> >>>>>>>
>>> >>>>>>> Can you please clarify one of the proposed changes to the
>>> Simple Search
>>> >>>>>>> box (top left in kepler UI) -
>>> >>>>>>>
>>> >>>>>>> specifically, some of the powerpoint slides show the search
>>> box with no
>>> >>>>>>> reset button (see attached example), whereas bug #2108
>>> ("changes to
>>> >>>>>>> simple search") mentions removing the "text" and "concept"
>>> checkboxes,
>>> >>>>>>> but does not mention removing the "reset" button.
>>> >>>>>>>
>>> >>>>>>> So should the reset button stay, or should it go?
>>> >>>>>>>
>>> >>>>>>> thanks
>>> >>>>>>>
>>> >>>>>>> Matthew
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> ------------------------------------------------------------------------
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> ------------------------------------------------------------------------
>>> >>>>>>>
>>> >>>>>>> _______________________________________________
>>> >>>>>>> Kepler-dev mailing list
>>> >>>>>>> Kepler-dev at ecoinformatics.org
>>> >>>>>>>
>>> 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
>>> >>>>>
>>> ------------------------------------------------------------------------
>>> >>>>>
>>> >
>>>
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>>
MJ>
MJ> --
MJ> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MJ> Matt Jones
MJ> jones at nceas.ucsb.edu Ph: 907-789-0496
MJ> National Center for Ecological Analysis and Synthesis (NCEAS)
MJ> UC Santa Barbara http://www.nceas.ucsb.edu/ecoinformatics
MJ> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MJ> _______________________________________________
MJ> Kepler-dev mailing list
MJ> Kepler-dev at ecoinformatics.org
MJ> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
More information about the Kepler-dev
mailing list