[seek-dev] Re: new screenshot

Bertram Ludaescher ludaesch at sdsc.edu
Fri Jul 16 09:00:01 PDT 2004


on a similar note: Ptolemy/Kepler is MUCH MORE than its GUI (which is
actually called Vergil). We might be ahead of the time a bit (like
Johannes Kepler) -- see, e.g., here:

See the pres. I just gave to these folks:

http://grist.caltech.edu/sc4devo/presentations/list.cfm

For the Kepler enthusiasts: Triana is well positioned in the "Grid
world". For SEEK this is probably less of an issue (although we might
have overemphasized the Grid aspect a bit) and semantics, esp. for
ecologists, is more imporant. But other potential Kepler users might
have more need for grid capabilities. We're getting there also ..

Bertram


>>>>> "CB" == Chad Berkley <berkley at nceas.ucsb.edu> writes:
CB> 
CB> I don't think we're flying blind.  We picked kepler because it had a 
CB> reasonably well defined UI that we could build off of.  One that seemed 
CB> intuitive to us (us includes ecologists as well as computer scientists). 
CB>   In making that decision, we were working off of more than 3 years of 
CB> development experience where we were working with scientists to build 
CB> other interfaces.  I'm somewhat opposed to the mentality that *everyone* 
CB> must think the UI is perfect and completely intuitive at first glance. 
CB> I just don't see that realistically happening.  I've mostly convinced 
CB> myself that the only way we are going to get a UI is to take 2 
CB> developers and 2 ecologists (or whatever kind of domain scientist) and 
CB> stick them in a room for a few days and let them decide.  I'm not sure 
CB> deciding a UI design by committee (i.e. on seek-dev) is really a good 
CB> way to do things.
CB> 
CB> On another note, if someone else with more UI experience than I would 
CB> like to come up with the perfect interface design screenshot and check 
CB> it into CVS, I would be happy to review it :)
CB> 
CB> chad
CB> 
CB> Rod Spears wrote:
>> 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 ---------------------------------
>>>> 
>>> 
>> 
>> _______________________________________________
>> seek-dev mailing list
>> seek-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
CB> _______________________________________________
CB> seek-dev mailing list
CB> seek-dev at ecoinformatics.org
CB> http://www.ecoinformatics.org/mailman/listinfo/seek-dev



More information about the Seek-dev mailing list