[seek-dev] Re: new screenshot

[Matt Jones]

Hi Chad,

Thanks for the additional screenshots, Chad.  I'm not sure which one 
works best. I do think the Actor/Data separation in tabs is good from a 
usability perspective even if it isn't strictly necessary from a 
classification perspective.  Particularly telling is that, even in your 
example, you would use different concepts to organize data than you do 
actors, so the disctinction occurs very high up in our concept space.  I 
think most scientists will make a strong distinction here (see below).

Also, I agree we should eliminate the slider altogether - it will 
probably be confusing.

The question of whether to use a) one tree with instances in the tree, 
or b) two panels where the first tree filters individuals in the lower 
list, is the hard one.  In (a) we can't really combine categories 
easily, so you are stuck with looking at the actors in a single 
category, which can be limiting and means you might have to expand lots 
of folders to find what you are looking for.  But the UI is very 
understandable. In (b), you have a tree used as a control in a way that 
is not typically done, so we need to be sure the increased query 
functionality (e.g., abillity to select multiple properties at once) 
justifies the hit on intuitiveness.  Also, (b) will likely suffer from 
screen real-estate problems.  The single panel onthe left already seems 
too small because we frequently want to see 15+ rows of actors or even 
more for data.  Making 2 panels just makes it worse.

Ultimately I think we should be presenting these design choices to 
users.  For starters getting Deana and Samantha and other SEEK 
participants to comment on the 3 screen shots would be useful.  Towards 
this end, I showed your screen shots to Ginny Eckert, a quantitative 
ecologist (and my wife), and here's her perspective:  1) definitely 
separate data and actors in two tabs -- ecologists just think this way. 
2) for the browse view, only use one pane for the tree, as the two 
panels are just too confusing.  Its not clear at all how it works. Move 
any advanced querying (e.g., find all numerical simulations that are 
also static) into a separate advanced query dialog. 3) Eliminate the 
slider -- she thought it might be useful, but probably too non-conventional.

Some other stuff she comented on too: 4) The main workflow display MUST 
have scroll bars, and the panning control should/could be moved to a 
dialog/floating panel so that the tree has more real estate. 5) Ginny is 
very used to using menu driven systems for selecting the statistics to 
be used ona set of data. Her process for this type of app is 'Open the 
data, select stats from hierarchical menus, configure stat, run'.  See, 
for example, SAS Analyst.  So, she says that having the 'models' in the 
tree on the left is really non-intutitive altogether, and those 
hierarchies really should be menu items.  I'm not sure if we can 
accomodate that view, but she felt pretty strongly about it.

So, in conclusion, I would probably vote for something akin to your 
'actor-ontology-search-without-list-with-tab.jpg', but also remove the 
slider from the bottom, and add an advanced query dialog that parallels 
the data query dialog and allows easily creating advanced logical queries.

Cheers,
Matt

Shawn Bowers wrote:
> 
> Comments interspersed ...
> 
>>> It isn't immediately clear anymore why the slider is there... I 
>>> thought the reason to have it was to be able to, within the directory 
>>> structure, "collapse" a set of nodes so that you can, e.g., see all 
>>> the individuals (actors, datasets, etc.) under a directory or any of 
>>> its subdirectories, without having to navigate through to the 
>>> subdirectories themselves (i.e., the subdirs aren't directly shown).
>>
>>
>>
>> OK, (imagine for a second that the slider is actually on 3 (note the 
>> slider may also just be divided proportionally, in which case 2 could 
>> equal level 6, 3 level 9, etc.), where it should be).  You now see 3 
>> levels of the tree.  Note that there are no '+' symbols next to the 
>> behavioral, functional or static folders.  Now, if we move the slider 
>> to the right one notch so it's on 4...+ symbols would appear next to 
>> behavioral, functional and static (if they actually have children) and 
>> you would be able to browse there.  I actually now think that this 
>> slider makes more sense when the results are integrated in the tree, 
>> but I still think it's useful with the list view.
> 
> 
> I agree that the slider doesn't make much sense unless you only have a 
> single tree view. Otherwise, you can just use the capabilities of the 
> tree view directly (with the other window) as I mentioned in the other 
> email.
> 
> Actually, I still think having two separate panels -- one for the tree 
> w/ individuals and concepts, and one for listing selected individuals -- 
> and no slider is the best way to go. Selecting a concept in the tree 
> displays all individuals under that node, i.e., the individuals in the 
> current concept, the individuals in all the subconcepts, and in their 
> subconcepts, etc.  Selecting multiple concepts in the tree view displays 
> the union of those selected.   Individuals can be selected and placed in 
> a workflow, e.g., by dragging and dropping from either panel.
> 
> My main problem with the slider is that it is "unconventional". It isn't 
> a standard kind of user interface widget used with trees.  It adds an 
> extra level of complexity that I don't think is needed. And, it isn't 
> immediately clear, without playing with it a bunch or reading some 
> documentation, what it does or what it is for.
> 
>> There are not supposed to be directories...sorry for the icon, i just 
>> copied the "data" icon from kepler.  Those are intended to be 
>> individuals.
> 
> 
> OK. My mistake -- it does look a little different than a folder icon.
> (A better icon would be the canonical cylinder disk, but okay.)
> 
> 
>>> I think what you are proposing with actors is very simple in terms of 
>>> ontological information, and doesn't apply directly to Rich's 
>>> ontology.  The notion being exploited in your screenshot is 
>>> assignment of a controlled-vocabulary-style keyword (with some notion 
>>> of subconcept, or narrower-term/broader-term) to an actor.  The 
>>> ontology is trying to extend the more eml-ish approach of describing 
>>> what is in the dataset, so that we can do some automatic processing 
>>> with it.
>>
>>  
>> What do you mean by "Rich's" ontology?  This is just dealing with 
>> organizing the models/actors/etc in kepler.  I thought Rich's ontology 
>> was the full on ecology ontology that would probably be used to 
>> classify data only.  Am I missing something here?
> 
> 
> I was under the impression that Rich was the only person actually 
> working on ontologies for SEEK.  Also, there has been some initial work 
> on representing models and actors using the same framework, so it isn't 
> solely for data.
> 
> My point is just that to do something similar for data (and possibly for 
> actors), more thought needs to go into how to get the concepts that 
> would be useful for this browsing interface.  The ontology being created 
> does not consist of a set of keywords -- it consists of concepts defined 
> in terms of their interrelationships, which sometimes can get pretty 
> complex.  This was the reason for my comment below.
> 
> I think your actor-ontology-search-without-list-with-tab.jpg image shows 
> this well.  The concepts that show up in the tree are pretty much 
> hand-picked terms that make sense to an ecologist for finding data (as 
> opposed to all the various concepts that exist within an ontology, or 
> even a controlled vocabulary but that is another story). If you just 
> took all the concepts of the ontology and created a tree -- I don't 
> think it would be that helpful for the kind of browsing interface being 
> proposed.  Also, there might be useful data-level items that could show 
> up as a "directory", e.g., a particular species name, or a particular 
> biodiversity index, etc., so that has to be taken into consideration as 
> well.  In general, I think we need a good way to pick out the 
> appropriate terms from the ontology that are best suited for this style 
> of browsing.
> 
> shawn
> 
> 
>>> The difficult thing is defining concepts so that they can capture the 
>>> purpose of the structural description of a dataset, that EML provides 
>>> -- which is what enables integration, e.g., or the ability to apply 
>>> automatic conversions, etc.  The concepts, however, I wouldn't 
>>> necessarily consider as keywords per se ... although it may be 
>>> possible to infer or extract keywords from the dataset directly based 
>>> on the semantic "registration", or possibly to extract keywords from 
>>> the ontology.
>>>
>>> A while ago, Rich and I also discussed an approach for taking a 
>>> keyword list (either user-defined or some "standard" list of terms), 
>>> and letting a user define the terms using the ontology. (Rich uses 
>>> something simple for this in his FoodWeb work.) Then, you could 
>>> "automatically" construct a structured controlled vocabulary of the 
>>> terms from their definitions (automatically, assuming you did the 
>>> work of mapping terms to ontology stuff).
>>>
>>> Right now, the best way to get keywords for datasets is probably to 
>>> extract them directly from detailed parts of the ontology (for those 
>>> parts of the ontology that reflect "keywordy" information, like 
>>> subclasses of Observable Entity Properties or Observable Entities, 
>>> etc).  But, the concepts defined within the ontology are probably 
>>> higher-level than what one would consider as keywords. For example, 
>>> the concepts "Observation," "Time," "Location," and so on, don't seem 
>>> like they would be very useful keywords to browse for datasets ...

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------