[seek-dev] Re: new screenshot

Rod Spears rods at ku.edu
Thu Jul 15 13:26:35 PDT 2004


We are flying blind...

And I think we approaching this from the inside out (once again). Shawn 
is right, instead of trying to figure out how to make our problem fit 
into Kepler. We should be defining the problem, the best UI for our 
target users that solves the problem, THEN see how to implement that 
inside of Kepler.

If we see the entire UI in terms of tab and tree controls then that is 
how we will view our solutions. 

Rod



Shawn Bowers wrote:

>
> I think that at this point, Kepler basically offers little to no 
> support for really organizing and describing actors and workflows.
>
> It seems that what you are pointing out is that there needs to be some 
> well thought out organization for actors, such that the organization 
> actually helps people (scientists, researchers, etc.) develop 
> workflows.  Of course, different disciplines, different user groups, 
> and different use cases may all have different preferred organizations.
>
> I think a benefit of the infrastructure that we are considering is 
> that you can have many different organizations, i.e., different 
> "views" of the same actors. One of these classifications could be 
> purely in terms of ecology concepts, others could be in terms of the 
> generic function of actors (aggregration, transformation, etc., the 
> "building blocks" you describe), and so on.  But for this to work, we 
> need some default organizations, possibly some templates for creating 
> configuring new ones, and maybe even some tools to help construct such 
> organizations from scratch.
>
> This infrastructure may also enable some of Ferdinando's ideas of 
> concept-based workflow construction/specification, where you don't 
> care about the specific actor -- you basically work at the concept 
> level, and let the system figure out the best actor(s).
>
> Also, I wonder if some of these organizations can be constructed using 
> existing information. For example, based on semantic annotations of 
> datasets using Rich's ontologies, e.g., can useful classifications be 
> "extracted" -- allowing such organizations to be automatically 
> constructed? Or, if actors have their input and outputs semantically 
> marked up, can we easily configure/infer/classify actors and construct 
> organizations using that information?
>
>
> shawn
>
>
>
> 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 ---------------------------------
>>
>




More information about the Seek-dev mailing list