[kepler-dev] Screentshots for registry search

[Christopher Jones]

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.

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

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

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


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
_________________________________________________________________