[seek-dev] Re: new screenshot

[Rod Spears]

I agree with the conclusions stated below in Matt's reply, except the 
part about menus. Actor and Data tabs should be separate (I thought we 
decided this long ago). The slider is confusing, mostly because it is 
too general and the user has no idea "specifically" what is meant by 
"General" or "Spefic." We understand those terms in and "general" way 
but we cannot tell from the UI how general "General" is or how specific 
"Specific" is and it is hard to tell just what the gradiation is in 
between the two. For example, what does half way between General and 
Specific mean?

Also, a deadly UI sin is to have things in one tab effect things in a 
different tab. Tabs are many parts of the whole, for lack of a better 
description tabs are just a one level tree control that hides the other 
siblings.

*As far as the menus go:*
Why were toolbars invented? They were invented because menus hide UI and 
aren't always easy to use especially when you have to traverse past the 
initial drop down. Comboboxes are the same way. They save real estate 
but but require multiple clicks and possibly scrolling and quite often 
if you aren't careful they pop "away" on you. (Same for menus).

The hard part is to balance how other apps work and what scientists are 
used to versus the usability of entirely new approach. The simple 
statement is, burying complex UI in menus because that is what 
scientists are used to is not the right answer.

I wish we could have asked Ginny after the first 10-15 minutes of using 
that app (SAS Analyst), for which she is now an experienced user, how 
intuitive it was. Did she use the app because it was intuitive and easy 
to use, or because had to?  We can't forget, scientists don't have to 
use our app to get their work done.

If she liked the idea of menus better than the UI we showed her, maybe 
there was something really wrong with our UI.


Rod


Matt Jones wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-dev/attachments/20040715/d25f1080/attachment.htm