[Fwd: Re: [seek-kr-sms] ontology/folder UI design in Kepler]

[Matt Jones]

I think Shawn described the user group well -- SEEK targets ecologists, 
especially quantitiative ecologists (e.g., modelers), while Kepler 
itself has a broader audience of scientists from multiple (and growing) 
domains.  Knowledge engineers simply don't exist among ecologists, so I 
agree with Shawn that any plan that leaves a knowledge engineer in the 
stream is not scalable and somewhat destined to fail over the long term. 
  However, I do think we will need to use the skills of knowledge 
engineers to bootstrap the ontology process, as I think its much harder 
to design these from the ground up than it is to extend and refine an 
existing ontological framework.

Shawn and I have worked up a general description of the staged 
development we would like to do to put semantics tools into Kepler. 
Here it is:

http://seek.ecoinformatics.org/Wiki.jsp?page=SemanticsInKepler

Its pretty general now, but is a bit more complete of a picture.  I 
added Sergui's email comments about what we *need* in the GUI at the end 
for reference because I thought it was valuable.

This wiki page should be the basis for discussions about GUI changes and 
how we should proceed with GUI design, and we should revise it as our 
vision matures or add additional material and pages.  Kepler as a 
workflow engine itself is one of our goals, but the major thing that is 
unique about SEEK (there are other workflow systems that work fine) is 
its novel inclusion of formal semantics to drive the workflow authoring 
task.  So...this is research, and we need to be creative in constructing 
usable GUI's that let us experiment with the semantic approaches to 
workflow design. Even though we are targeting quantitative ecologists, I 
don't think its acceptable to limit our GUI designs to things that they 
already know and love.  The whole point of SEEK is to develop some *new* 
approaches.  Hopefully we can acheive this in a way that actually is 
intuitive and saves time for them, but we probably won't get there on 
the first pass.  Lets hope that at the end of 2.5 years of iterations 
through this we will have reached that goal.

Matt

P.S. And to answer Laura's question, yes we really are thinking of 
having user's annotate ports, as the users are then ones creating the 
ports, so there's nobody else available for the task.

Shawn Bowers wrote:
> Laura L. Downey wrote:
> 
>> As someone new to the project, I'm still trying to understand which user
>> group we are designing for -- knowledge engineers, domain scientists, 
>> both,
>> or some hybrid of an ecologist with some ontological knowledge.  And the
>> next question is to what level we are trying to support the various tasks
>> these users might perform within Kepler.   Deana and I had a good 
>> discussion
>> this morning where she was catching me up on things and where she 
>> mentioned
>> that the KR-SMS team is still in the process of determining the target 
>> users
>> and associated tasks.  Until we have that information we can't really 
>> fully
>> design the ontology UI.
> 
> 
> I think there are two aspects: one is Kepler in general, and one is SEEK 
> and SEEK's use of Kepler. The Kepler system is really targeted at a very 
> broad user base from programmers, to domain scientists, to researchers, 
> to information managers, to possibly even students learning about 
> science and scientific workflows and models.
> 
> SEEK, however, I think is more targeted at the scientist/researcher (at 
> least as described in the proposal) and although not necessarily 
> explicit, those who manage data (e.g., "information 
> managers/specialists" within LTER) or provide analytical support (e.g., 
> people doing complex synthesis projects like at NCEAS).
> 
> Mark and Matt probably have more insight into the target user group; so 
> they can correct me here if I am wrong.  I am not sure what Deana means 
> in terms of us trying to determine the target users and associated 
> tasks. My impression has always been, at least from the proposal, that 
> we are charged with enabling ecological scientists and researchers via 
> SEEK.
> 
> Also, in previous threads on this list, we discussed differences to the 
> "bottom up" and "top down" design of Kepler (in the Fall I believe).  We 
> agreed that we are currently going bottom up, that is, we are developing 
> low-level core functionality that can eventually be built upon to get to 
> a more integrated and conceptual interface. Alternatively, we had 
> discussions briefly about "top down" designs, in which we start from the 
> conceptual interface (e.g., high-level schemas for workflows and other 
> "visions" of interface capabilities distinct from Kepler and what Kepler 
> provides).  I think we have had a fairly good idea of what the 
> high-level SMS tasks are, at least since I started the project.
> 
> What I think would be cool, is if we could work from both of these 
> levels.  Instead of strictly focusing on the bottom-up approach (which 
> we agreed is necessary to do), we also spend some additional time 
> thinking about and investigating way-out there and crazy interfaces that 
> may be useful to scientists wrt the workflow paradigm. Ferdinando sent 
> around one such "vision" of interaction, and I think we should continue 
> to pursue and develop these ideas, and even do "usability" experiments 
> in this regard.
> 
> My concern is that if we only focus on Kepler as it is today; we have 
> already biased our user group and that we are limiting ourselves. 
> Instead, I think we should also pursue design from "the other end" so 
> that we have multiple types of information to base our decisions on.
> 
> Laura, you can hopefully further enlighten us about these issues -- 
> since from my experience HCI research is rich with this "top down" 
> style, for example, experiments leveraging "wizard of oz" studies, 
> surveys, field studies, observational studies (which could be a very 
> exciting line of research: e.g., how do people currently communicate 
> their datasets and analyses), and so on.
> 
> Shawn
> 
>> We could however, as I and others have mentioned, certainly 
>> incorporate some
>> "picking concepts" mechanism where we display the known concepts and 
>> allow
>> the user to select concepts to support the task of assigning concepts to
>> datasets and/or actors.  I'm assuming (dangerous I know) that Matt is
>> referring to something similar with his "browsing" terminology in his 
>> last
>> note and which we'll know more after he gets the wiki page up he 
>> referenced.
>>
>> Later, after we have more information, it might be possible to supplement
>> that "concept selection" by offering some list of questions the user 
>> has to
>> answer in order to do their tagging.  We could even consider a wizard 
>> like
>> UI if we managed to formulate a basic set of questions, easily
>> understandable by domain scientists that could be translated to work
>> properly within a formal ontology.  But again, I would not see being 
>> able to
>> determine that set of questions until the KR-SMS team has hashed out 
>> their
>> target user group(s) and determined the kinds of tasks they would 
>> perform.
>> But in the interim, we could offer some hierarchical representation for
>> users to pick concepts from.
>>
>> I noticed that Serguei has offered a set of questions based on the 
>> "tagging
>> task" for us to consider in trying to determine which kind of specific UI
>> (including metaphors) we might offer.  At first I thought he was offering
>> these as questions as something to translate into English ;-) for the 
>> users
>> to answer to help them do their annotations.  But Deana pointed out 
>> that was
>> not the case.
>>
>> One quick question here, are we really thinking about letting users 
>> annotate
>> ports?  This seems to be a very very low level of annotation that I can't
>> see that many users doing.  Is this related to the data integration 
>> issue?
>>
>> Back to Serguei's questions.... if I'm understanding them correctly (with
>> some help from Deana) basically he's asking does the user need to 
>> understand
>> all the complexity in the ontology.  And if so, then a tree 
>> representation
>> can't adequately communicate that complexity.  However, I think that the
>> complex graphs produced by the various ontology tools are certainly
>> difficult enough for experienced KE's to decipher, much less domain
>> scientists, even those with some ontological knowledge.  Ferdinando 
>> brought
>> up the issue of graphic extension philosophy as a means of trying to
>> simplify these complex graphs but after looking at those examples, I'm 
>> not
>> convinced they would be applicable to scientific ontologies -- especially
>> after talking with Deana about the nature of scientific ontologies.  
>> Those
>> examples work because there are these easy binary groupings like 
>> man/woman
>> or mother/father etc in the family tree example, or small numbers of 
>> large
>> categories like chemical compounds falling into one broad category 
>> (nitrogen
>> compounds) with say 3 different kinds of processes to apply to them.
>>
>> I think it might be possible to use the graphic extension philosophy a
>> little in a tree representation -- for example some symbol that indicates
>> that a concept is used in multiple places within the tree, with the 
>> option
>> of showing the various "neighborhoods" that a concept is used in. (Think
>> about an option that says show me all the occurrences of "concept X" 
>> and a
>> view of the tree being expanded one level above and below the various
>> occurrences of "concept x" with concept X highlighted and everything 
>> else in
>> the tree collapsed.  I also think we could support the operation of 
>> showing
>> the user other items that have been assigned a certain concept.  And we
>> might offer filtering and searching on the tree too.  Lots of these
>> suggestions support the notion that the user has an idea how they want to
>> classify something and only needs to see various pieces to make a 
>> decision.
>> Of course if the user wants to see the entire tree, we have to make that
>> available too.  And that is a tough problem lots of people seem still 
>> to be
>> working on -- visualization of large hierarchies.
>>
> _______________________________________________
> seek-kr-sms mailing list
> seek-kr-sms at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms

-- 
-------------------------------------------------------------------
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
-------------------------------------------------------------------