[kepler-dev] Screentshots for registry search

[Jing Tao]

Hi, Chris:

Thanks for your input! I comment my thought below you orginal one.

On Wed, 6 Oct 2004, Christopher Jones wrote:

> Date: Wed, 06 Oct 2004 11:40:13 -0800
> From: Christopher Jones <cjones at lifesci.ucsb.edu>
> To: Jing Tao <tao at nceas.ucsb.edu>
> Cc: Bertram Ludaescher <ludaesch at sdsc.edu>, kepler-dev at ecoinformatics.org,
>      bzhu at sdsc.edu
> Subject: Re: [kepler-dev] Screentshots for registry search
> 
> Jing,
> 
> Thanks for providing the URLs.  That makes it easy to have a quick look.
> 
> Given that UI considerations are completely subjective, please take my comments 
> with a grain of salt...
> 
> >>JT> Here is the order to look.
> >>JT> 1) registry-search-init.png
> >>JT> 2) registry-search-current-context.png
> >>JT> 3) registry-search-searching.png
> >>JT> 4) registry-search-searching-result.png
> >>JT> 5) registry-search-final-context.png
> >>JT> 
> >>JT> The first screent is the initial screen. After click "Change Search 
> >>JT> Context" button and the second screen will be shown.
> My first thought is that putting the 'Change Search Context" button on the data 
> tab somewhat clutters the tab.  Also, the meaning of this isn't super apparent 
> from an end user perspective.  It strikes me as a 'Preferences' dialog, and so 
> I'd suggest that the button be removed in favor of an Edit --> Preferences 
> dialog ( or Tools --> Options for Windows).  In fact, it seems that any Kepler 
> configuration should follow this convention.  This would also allow you some 
> screen real estate in the Preferences panel to explain what is meant by 'search 
> context' for those that are unfamiliar with searching multiple services.
> 

I don't satify the word "Search Context" either. But I couldn't find a 
better one. This is the reseaon I asked for reviewing :).  Change the 
button to a menu item is a good idea. But this will involve ptolemy UI 
changes. This is why we put a button as a short cut.

> >>JT> 
> >>JT> The second screen -  registry-search-current-context will show the search 
> >>JT> context reading from configure file(including service name, url ...). You 
> >>JT> may use check box and "Remove" button to get rid of some search context. 
> >>JT> If you click "Search Registry" button and the third screent will be shown.
> Screen #2 could be the 'Searching' preference dialog, or the 'Data Sources' 
> dialog.  I guess I'm thinking that the word 'Context' does not ring true for me. 
>   The wording should indicate that the user is configuring the data sources that 
> are to be searched.
> 
> Layout: change screen #2 in order to follow some of the basic dialog box 
> conventions:
>    - the 'Remove', 'Search Registry', 'Save', and 'Cancel' buttons are 
> vertically centered between the scroll box and the bottom.  These should be 
> 'anchored' to the screen bottom with the same margin as you see on the right side.
> 
>    - the scrollbox should extend to the newly located buttons within the same 
> margin distance as seen on the right of the 'Cancel' button.  Likewise, the 
> scrollbox crowds the dialog edges.  Give it margins equal to the buttons.
> 
>    - the header should be left-margined the same as the dialog box.  Of course, 
> if this were all in an Edit --> Preferences dialog, it would often be Titled in 
> a groupbox.
> 
> The 'Search Registry' button is really just a surrogate to 'Add' (which you use 
> in a later screen as the end result).  I would change 'Search Registry' to 'Add' 
> so the user is aware that the end result is to add a data source. (It also pairs 
> nicely with 'Remove' =))
> 
> "End Point' and 'Document Type' columns:
> 
>    - the End Point is merely informational, and helps the user understand the 
> location of the service.  From a jargon perspective, you might label the column 
> 'Location' or the like.
> 
>    - as for the doctype column - most end users are going to be lost on the 
> meaning of PUBLIC or SYSTEM identifiers. Most will not make the connection 
> between 'Data Sources' and metadata document types.  There's alot of info in 
> this column that the user is choosing - different specifications with different 
> levels of detail, different versions of the same specification, etc.  Unless the 
> end user is fluent in metadata specifications, this column will only confuse 
> them.  I don't have a good answer, but perhaps a friendlier name would help (EML 
> 2.0.0 Datasets, Darwin Core 1.0 Datasets, etc.).  Granted, the friendly name 
> should be stored on the service side and rendered, rather than being hardcoded 
> into the app.  Also, maybe change the column to 'Data Specification' or 'Data 
> Type', or 'Data Description'.

Those suggestions are very nice. I will use it.


> 
> >>JT> 
> >>JT> In the third screen - registry-search-searching.png, you may specify 
> >>JT> search criteria there. And click "Search" button, user 
> >>JT> will get the search result - registry-search-searching-result.png screen.
> If this dialog is to stay this simple, I would reduce the dialog screen size so 
> that margins adhere to the margins described above.  Buttons need to be 
> relocated as above as well. Also, some explanatory text would help this dialog a 
> lot.
> 
> I'd look at the search dialog in Morpho, however, if this dialog were to be 
> expanded in functionality at all. (Repeatable terms, choice of operator, etc.) 
> Of course, this depends on the ricness of the registry query API.
> 
The schema for ecogrid service registry is pretty simple and probably we 
may use a simple GUI. Of course we need to reduce the size of this screen.



> >>JT> In the fourth screen, you may choose search context by check box. Then 
> >>JT> click "Add" button to add your choice to orignal search context. Then you 
> >>JT> will get the final search context-original ones and adding ones. Use 
> >>JT> "Save" button, you may save the search context to configure file.
> Here, again, follow the button and scrollbox margin recommendations.
> 'Add' could be changed to 'OK'.  One question about the behavior of this UI - in 
> the 'canada' search result screen, if the user only selects *only* EML 2.0.0 
> Datasets to be searched, will the 'Current Search Context' be configured to only 
> show EML 2.0.0 Datasets as a choice, or does it return all possibilities from 
> the service, with EML 2.0.0 checked?  If it's the latter, I'd say that this 
> screen is a bit redundant with the first, and that it should only display the 
> Service Name as a 'hit', perhaps with the endpoint location as extra info.
> 
For the qestion, the answer is former rather than latter. This can give 
user more flexibility.


> 
> Jing, I hope this helps - but it's all just subjective opinions.
> 
> Best,
> Chris
> 
> _________________________________________________________________
> christopher jones     cjones at lifesci.ucsb.edu      (805) 680-5946
> marine science institute  university of california, santa barbara
> _________________________________________________________________
> 

Thanks again for your suggestion!

Jing

-- 
Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101