[kepler-dev] Screentshots for registry search

[Rod Spears]

We appreciate your input and I am not trying to discourage it at all, 
but I think Jing was just trying to give us kind of an overview of what 
the major UI components and how they would be used. Working out the 
finer details of layout etc. is something I figured we would address 
during implementation.

As far as getting into the an over all discussion of what appears to be 
intuitive or make sense for the user... I think we are a long ways from 
that. It is universally accepted that the current UI is for the most 
advanced user. There really isn't much UI here that really lends itself 
to a novice user. In fact, the state of the Kepler UI (for SEEK) is 
really just a "work in progress" or maybe even "proof of concept" 
because basically we are still "inventing" how this works.

At some point we will have a majority of the functionality implemented 
and then I think we can step back and address many of the UI issues. 
Plus, our UI resource (Laura) will have been playing around with Kepler 
and getting to understand the mental model of the of various different 
users and will be able craft a UI that meets the needs of the project.

One could argue that saving the UI until later is bad approach, but 
since we do not completely understand how all of this will work and what 
all the capabilitites of Kepler are, I think it is the most pragmatic 
approach.

I guess in a nutshell, we are building a prototype from which the "real" 
tool will be created from.

I hope this provides a little perspective on where we are at. But 
getting input is always good and can be used Laura at a later date.

Thanks,
Rod


Christopher Jones wrote:

> 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
> _________________________________________________________________
>
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev