[seek-dev] Re: new screenshot

Rod Spears rods at ku.edu
Thu Jul 15 09:11:06 PDT 2004


Well, it is interesting Dan brings this up. I left out a small 
discussion on the "evil of tree controls" which I will include here:

Tree controls are evil. They are more evil for novice users than more 
experienced users. Strangely enough, there are many many people in this 
world that have problems navigating the Windows file system with a tree 
control. Strangely enough, they can make the leap that the tree 
represents the file system. But then these folks think in a very flat 
structure.  It is probably a safe assumption that our users, even the 
less technical ones, can handle a tree control.

But remember how most people think about trees or what their exposure to 
trees is: The file system.

Folders contains "things" where things are typically, for the most part, 
data. In their mind, folders are folders and the only real attribute of 
a folder is that it can hold things, like other folders and data. At 
most, the folder name describes the relationship all the siblings have.

Once we start assigning meaning to tree nodes, and if nodes at different 
levels mean different things then we need to be extra careful, 
expecially if the parent node cannot easily describe what it contains.

Rod


Daniel Higgins wrote:

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


-- 
Rod Spears
Biodiversity Research Center
University of Kansas
1345 Jayhawk Boulevard
Lawrence, KS 66045, USA
Tel: 785 864-4082, Fax: 785 864-5335

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


More information about the Seek-dev mailing list