[seek-dev] Re: new screenshot

Chad Berkley berkley at nceas.ucsb.edu
Wed Jul 14 21:01:13 PDT 2004


They are in the kepler CVS module under kepler/docs/dev/screenshots.  
Look at the the jpg files that start with actor-ontology.

chad

Bertram Ludaescher wrote:

>MAtt, Chad:
>
>I cannot see the "additional screenshots". Nothing in my inbox and I
>don't see it here either:
>
>http://www.ecoinformatics.org/pipermail/seek-dev/2004-July/thread.html#741
>
>help!
>
>Bertram
>
>  
>
>>>>>>"MJ" == Matt Jones <jones at nceas.ucsb.edu> writes:
>>>>>>            
>>>>>>
>MJ> 
>MJ> Hi Chad,
>MJ> Thanks for the additional screenshots, Chad.  I'm not sure which one 
>MJ> works best. I do think the Actor/Data separation in tabs is good from a 
>MJ> usability perspective even if it isn't strictly necessary from a 
>MJ> classification perspective.  Particularly telling is that, even in your 
>MJ> example, you would use different concepts to organize data than you do 
>MJ> actors, so the disctinction occurs very high up in our concept space.  I 
>MJ> think most scientists will make a strong distinction here (see below).
>MJ> 
>MJ> Also, I agree we should eliminate the slider altogether - it will 
>MJ> probably be confusing.
>MJ> 
>MJ> The question of whether to use a) one tree with instances in the tree, 
>MJ> or b) two panels where the first tree filters individuals in the lower 
>MJ> list, is the hard one.  In (a) we can't really combine categories 
>MJ> easily, so you are stuck with looking at the actors in a single 
>MJ> category, which can be limiting and means you might have to expand lots 
>MJ> of folders to find what you are looking for.  But the UI is very 
>MJ> understandable. In (b), you have a tree used as a control in a way that 
>MJ> is not typically done, so we need to be sure the increased query 
>MJ> functionality (e.g., abillity to select multiple properties at once) 
>MJ> justifies the hit on intuitiveness.  Also, (b) will likely suffer from 
>MJ> screen real-estate problems.  The single panel onthe left already seems 
>MJ> too small because we frequently want to see 15+ rows of actors or even 
>MJ> more for data.  Making 2 panels just makes it worse.
>MJ> 
>MJ> Ultimately I think we should be presenting these design choices to 
>MJ> users.  For starters getting Deana and Samantha and other SEEK 
>MJ> participants to comment on the 3 screen shots would be useful.  Towards 
>MJ> this end, I showed your screen shots to Ginny Eckert, a quantitative 
>MJ> ecologist (and my wife), and here's her perspective:  1) definitely 
>MJ> separate data and actors in two tabs -- ecologists just think this way. 
>MJ> 2) for the browse view, only use one pane for the tree, as the two 
>MJ> panels are just too confusing.  Its not clear at all how it works. Move 
>MJ> any advanced querying (e.g., find all numerical simulations that are 
>MJ> also static) into a separate advanced query dialog. 3) Eliminate the 
>MJ> slider -- she thought it might be useful, but probably too non-conventional.
>MJ> 
>MJ> Some other stuff she comented on too: 4) The main workflow display MUST 
>MJ> have scroll bars, and the panning control should/could be moved to a 
>MJ> dialog/floating panel so that the tree has more real estate. 5) Ginny is 
>MJ> very used to using menu driven systems for selecting the statistics to 
>MJ> be used ona set of data. Her process for this type of app is 'Open the 
>MJ> data, select stats from hierarchical menus, configure stat, run'.  See, 
>MJ> for example, SAS Analyst.  So, she says that having the 'models' in the 
>MJ> tree on the left is really non-intutitive altogether, and those 
>MJ> hierarchies really should be menu items.  I'm not sure if we can 
>MJ> accomodate that view, but she felt pretty strongly about it.
>MJ> 
>MJ> So, in conclusion, I would probably vote for something akin to your 
>MJ> 'actor-ontology-search-without-list-with-tab.jpg', but also remove the 
>MJ> slider from the bottom, and add an advanced query dialog that parallels 
>MJ> the data query dialog and allows easily creating advanced logical queries.
>MJ> 
>MJ> Cheers,
>MJ> Matt
>MJ> 
>MJ> 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 ...
>>>>>          
>>>>>
>MJ> 
>MJ> -- 
>MJ> -------------------------------------------------------------------
>MJ> Matt Jones                                     jones at nceas.ucsb.edu
>MJ> http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
>MJ> National Center for Ecological Analysis and Synthesis (NCEAS)
>MJ> University of California Santa Barbara
>MJ> Interested in ecological informatics? http://www.ecoinformatics.org
>MJ> -------------------------------------------------------------------
>MJ> _______________________________________________
>MJ> seek-dev mailing list
>MJ> seek-dev at ecoinformatics.org
>MJ> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
>  
>




More information about the Seek-dev mailing list