[seek-dev] Re: new screenshot
Matt Jones
jones at nceas.ucsb.edu
Fri Jul 16 10:30:26 PDT 2004
I also agree we're not flying blind. Lots of ecology and analysis
experience in-house. Plus lots of contact withour target user-group.
It would be nice to get some more sreen shots like the ones Chad has
been developing so that we can make some intelligent design decisions
before implementation. Chad, Shawn, Mark, and I had a good conversation
about the screenshots before I sent this info to the list, so you missed
some of the context, Rod.
Vergil is nicely configurable, and the Ptolemy folks have encouraged us
to continue making changes that are re-configurable. I like that
approach, because it makes it easy for us to plug in new components as
we go, and easy for the Ptolemy folks to ignore our chnages if they so
desire.
I think that, once we get these browsing and data query interfaces
designed, we should consider the interface as a whole. That willbe
easier to do if we've thought carefully about the components, in terms
of screenshots. However, keep in mind that we need to make some
incremental progress as well, as other parts of the project like BEAM
are waiting to use the stuff we produce, plus we have an NSF review next
summer that will determine our future. So...we can't just completely go
pie-in-the-sky in terms of design. Our near-term goal is to have much
of this released in October (see notes from SEEK meeting in Scotland for
details). That said, I think Ferdinando's suggestion to simultaneously
consider what the ideal 'conceptual analysis' interface would be is a
good one. Maybe we should schedule a few days to do that. I'll chew on
that and see if I can come up with a time for a small group AMS/Kepler
people to meet for a design session.
Matt
Shawn Bowers wrote:
>
>
> Chad Berkley wrote:
>
>> I don't think we're flying blind. We picked kepler because it had a
>> reasonably well defined UI that we could build off of. One that
>> seemed intuitive to us (us includes ecologists as well as computer
>> scientists). In making that decision, we were working off of more
>> than 3 years of development experience where we were working with
>> scientists to build other interfaces. I'm somewhat opposed to the
>> mentality that *everyone* must think the UI is perfect and completely
>> intuitive at first glance. I just don't see that realistically
>> happening. I've mostly convinced myself that the only way we are
>> going to get a UI is to take 2 developers and 2 ecologists (or
>> whatever kind of domain scientist) and stick them in a room for a few
>> days and let them decide. I'm not sure deciding a UI design by
>> committee (i.e. on seek-dev) is really a good way to do things.
>>
>> On another note, if someone else with more UI experience than I would
>> like to come up with the perfect interface design screenshot and check
>> it into CVS, I would be happy to review it :)
>
>
>
> The nice thing too about Ptolemy is that it is very configurable (I
> think so much so that it gets obfuscated, but that is another issue).
> So, making changes or tweaks even to the UI isn't that hard.
>
> On the other hand, I think Kepler does need to spend considerable time
> on making the UI intuitive to the targeted users. (I think this is the
> point of developing the screen-shots/design for actor and data browsing,
> and so progress is being made.) Kepler now basically uses the default
> Ptolemy UI configuration, but there seems to be lots of opportunities to
> use some of the more advanced configuration of Ptolemy to support new
> (and improved) interfaces.
>
> I agree with Chad (and Rod too I think), try some stuff, get a user
> group (the two ecologists), see what they think, tweak, iterate again,
> etc. There are probably some basic UI best-practices we can use as we
> do this stuff. And we should have some basic goals, like making things
> intuitive enough so that you don't have to read a manual or have someone
> there to hold your hand just to start use the system, etc.
>
> I think also that even the Ptolemy group, from what I have heard,
> recognizes the need for a better UI.
>
>
> shawn
>
>
>
>
>>
>> chad
>>
>> 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
>>
>>
>> _______________________________________________
>> seek-dev mailing list
>> seek-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
>
>
> _______________________________________________
> seek-dev mailing list
> seek-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
--
-------------------------------------------------------------------
Matt Jones jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------
More information about the Seek-dev
mailing list