[seek-dev] Re: new screenshot

[Daniel Higgins]

Hi All,

    I would like to bring up another question regarding this 
concept-based ontology display of actors that is being discussed. Just 
what will end up as the leaf nodes of the concept tree? I tend to think 
of actors as modules in a workflow. Now it is certainly true that a 
complete workflow can be put in a composite actor container and called 
an 'actor'. But there is not much advantage in doing that unless this 
new 'actor' can be reused somewhere else.

    Is the ontology based display of actors going to include all 
workflows, or modular actors AND more complex workflows?  In my 
experience building Kepler workflows/models, one tends to use some actor 
components in almost all models (e.g parameters, displays. expressions, 
etc.) Many of these would seem to fit into all (or none) of a higher 
level concept organization.

    For example, I would imagine that a large number of workflows would 
fit into the general category of data analysis where there is some data 
that is input., the data is massaged so that it can be feed to some 
analysis module (e.g a statistical calculation), and then the results 
displayed in one of many ways. There could easily be a large number of 
such workflows that only vary in some small way (e.g. one uses integer 
data, another floats, or one plots a scatter plot as output and another 
a box plot). If all these workflows with only small variations were 
listed, the result would seem to be somewhat overwhelming to a new user. 
On the other hand, they are all made up of a smaller set of  more atomic 
actors that do things like type conversion, mathematical transformation, 
or graphical display. These more atomic actors don't really seem to fit 
anywhere in some concept ontologies, yet they are the pieces used to 
build almost any workflow.

    I tend to think that someone using Kepler really wants a small set 
of atomic actors that are useful for building a variety of scientific 
workflows. This is sort of like the electronics world where only a few 
types of components are used to build TVs, stereos, computers, and iPods.

    So I am suggesting that perhaps we distinguishg between example 
workflows and a (hopefully) small set of 'atomic actors' used to build 
such workflows. The example workflows are very useful educationally, but 
are not directly used to build new workflows. [As an example, the Stella 
system uses a very small number (3 ?) of atomic actors to build all 
sorts of workflows (models). This simplicity is one of the factors that 
make it appealing.]

Dan Higgins

Rod Spears wrote:

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


-- 
---------------------------------
Dan Higgins
Software Developer
National Center for Ecological Analysis and Synthesis (NCEAS) 
735 State St. Rm 205 
Santa Barbara, CA 93101 
805-892-2531 
higgins at nceas.ucsb.edu 
---------------------------------

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