[kepler-dev] Screentshots for registry search
tao at nceas.ucsb.edu
Wed Oct 6 14:08:25 PDT 2004
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
> 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> 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> 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
> - 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> 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
> 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.
> christopher jones cjones at lifesci.ucsb.edu (805) 680-5946
> marine science institute university of california, santa barbara
Thanks again for your suggestion!
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101
More information about the Kepler-dev