[seek-dev] Re: new screenshot
Bertram Ludaescher
ludaesch at sdsc.edu
Thu Jul 15 05:08:56 PDT 2004
thanks.
I guess I didn't look in my cvs mail folder in a while ;-)
B
>>>>> "CB" == Chad Berkley <berkley at nceas.ucsb.edu> writes:
CB>
CB> They are in the kepler CVS module under kepler/docs/dev/screenshots.
CB> Look at the the jpg files that start with actor-ontology.
CB>
CB> chad
CB>
CB> Bertram Ludaescher wrote:
CB>
>> 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