[seek-dev] Re: [seek-kr-sms] UI
rods at ku.edu
Mon Jun 14 05:56:34 PDT 2004
In many ways I think the current user-interface work for Kepler is
almost orthoginal to this discussion.
There are many issues with the current UI that need to be fixed ASAP,
but I don't think it should keep us from getting a group together to
start down the path that Shawn has outlined.
If we (and we should) take a more process oriented approach to
developing the UI this work really has little, if anything, to do with
Kepler for quite sometime.
As I see it the Kepler UI is really the "advanced" UI for SEEK. There is
a whole lot of work that needs to go on before that.
Deana has a very valid point as to how to begin this work with/without
the usability position being filled. At the same time, many different
aspects of the UI are being to take shape and time is of the essence.
Deana Pennington wrote:
> Shawn & Rod,
> I think these are all great suggestions, and we've been discussimg
> putting together a group of ecologists for a couple of days of
> testing, but:
> 1) we thought that there are some major issues with the interface as
> it stands right now that need to be fixed before we try to get a group
> together, and
> 2) a decision needs to made about the useability engineer position, so
> that person can be involved right from the start in user testing and
> UI design
> So, I think we should table this discussion until the above 2 things
> are resolved. It's obvious that this needs to be addressed soon.
> Shawn Bowers wrote:
>> Rod Spears wrote:
>>> (This is a general reply to the entire thread that is on seek-kr-sms):
>>> In the end, there are really two very simple questions about what we
>>> are all doing on SEEK:
>>> 1) Can we make it work?
>>> a) This begs the question of "how" to make it work.
>>> 2) Will anybody use it?
>>> a) This begs the question of "can" anybody use it?
>>> Shawn is right when he says we are coming at this from the
>>> "bottom-up." SEEK has been very focused on the mechanics of how to
>>> take legacy data and modeling techniques and create a new
>>> environment to "house" them and better utilize them. In the end, if
>>> you can't answer question #1, it does matter whether you can answer
>>> question #2.
>>> But at the same time I have felt that we have been a little too
>>> focused on #1, or at the very least we haven't been spending enough
>>> time on question #2.
>>> Both Nico and Fernando touched on two very important aspects of what
>>> we are talking about. Nico's comment about attacking the problem
>>> from "both" ends (top down and bottom up) seems very appropriate.
>>> In fact, the more we know about the back-end the better we know what
>>> "tools" or functionality we have to develop for the front-end and
>>> how best they can interact.
>>> Fernando's comment touches on the core of what concerns me the most,
>>> and it is the realization of question #2
>>> His comment: "/I also think that the major impediment to an
>>> understanding that requires a paradigm switch is the early
>>> idealization of a graphical user interface/." Or more appropriately
>>> known as "the seduction of the GUI." (Soon to be a Broadway play ;-) ).
>>> We absolutely have to create a tool that scientists can use. So this
>>> means we have to create a tool that "engages" the way they think
>>> about modeling problems. Note that I used the word "engage", meaning
>>> the tool doesn't to be an exact reflection of their process for
>>> creating a models and doing analysis, but if has to be close enough
>>> to make them want to "step up to the plate" and "take a swing for
>>> the fence" as it were.
>>> In many ways too, Fernando's comment touch on the the problem I have
>>> always had with Kepler. The UI is completely intertwined with the
>>> model definition and the analysis specification. It has nearly zero
>>> flexibility in how one "views" the "process" of entering in the
>>> model. (As a side note, the UI is one of the harder aspects of
>>> Kepler to tailor)
>>> In a perfect world of time and budgets it would be nice to create a
>>> tool that has standalone Modeling and Analysis Definition Language,
>>> then a core standalone analysis/simulation engine, and lastly a set
>>> of GUI tools that assist the scientists in creating the models and
>>> monitoring the execution. Notice how the GUI came last? The GUI
>>> needs to be born out of the underlying technology instead of
>>> defining it.
>>> I am a realist and I understand how much functionality Kepler brings
>>> to the table, it gives us such a head start in AMS. Maybe we need to
>>> start thinking about a more "conceptual" tool that fits in front of
>>> Kelper, but before that we need to really understand how the average
>>> scientist would approach the SEEK technology. I'll say this as a
>>> joke: "but that pretty much excludes any scientist working on SEEK,"
>>> but it is true. Never let the folks creating the technology tell you
>>> how the technology should be used, that's the responsibility of the
>>> I know the word "use case" has been thrown around daily as if it
>>> were confetti, but I think the time is approaching where we need to
>>> really focus on developing some "real" end-user use cases. I think a
>>> much bigger effort and emphasis needs to be placed on the
>>> "top-down." And some of the ideas presented in this entire thread is
>>> a good start.
>> Great synthesis and points Rod.
>> (Note that I un-cc'd kepler-dev, since this discussion is very much
>> I agree with you, Nico, and Ferdinando that we need top-down
>> development (i.e., an understanding of the targeted user problems and
>> needs, and how best to address these via end-user interfaces) as well
>> as bottom-up development (underlying technology, etc.).
>> I think that in general, we are at a point in the project where we
>> have a good idea of the kinds of solutions we can provide (e.g., with
>> EcoGrid, Kepler, SMS, Taxon, and so on).
>> And, we are beginning to get to the point where we are
>> building/needing user interfaces: we are beginning to
>> design/implement add-ons to Kepler, e.g., for EcoGrid querying and
>> Ontology-enabled actor/dataset browsing; GrOWL is becoming our
>> user-interface for ontologies; we are designing a user interface for
>> annotating actors and datasets (for datasets, there are also UIs such
>> as Morhpo); and working on taxonomic browsing.
>> I definately think that now in the project is a great time to take a
>> step back, and as these interfaces are being designed and implemented
>> (as well as the lower-level technology), to be informed by real
>> Here is what I think needs to be done to do an effective top-down
>> 1. Clearly identify our target user group(s) and the general benefit
>> we believe SEEK will provide to these groups. In particular, who are
>> we developing the "SEEK system" for, and what are their
>> problems/needs and constraints. Capture this as a report. (As an
>> aside, it will be very hard to evaluate the utility of SEEK without
>> understanding who it is meant to help, and how it is meant to help
>> 2. Assemble a representive group of target users. As Rod suggests,
>> there should be participants that are independent of SEEK. [I
>> attended one meeting that was close to this in Abq in Aug. 2003 --
>> have there been others?]
>> 3. Identify the needs of the representive group in terms of SEEK.
>> These might be best represented as "user stories" (i.e., scenarios)
>> initially as opposed to use cases. I think there are two types of
>> user stories that are extremely benefitial: (1) as a scenario of how
>> some process works now, e.g., the story of a scientist that needed to
>> run a niche model; (2) ask the user to tell us "how you would like
>> the system to work" for the stories from 1.
>> 4. Synthesize the user stories into a set of target use cases that
>> touch a wide range of functionality. Develop and refine the use cases.
>> 5. From the use cases and user constraints, design one or more
>> "storyboard" user interfaces, or the needed user interface components
>> from the use cases. At this point, there may be different possible
>> interfaces, e.g., a high-level ontology based interface as suggested
>> by Ferdinando and a low-level Kepler-based interface. This is where
>> we need to be creative to address user needs.
>> 6. Get feedback from the target users on the "storyboard" interfaces
>> (i.e., let them evaluate the interfaces). Revisit the user stories
>> via the storyboards. Refine the second part of 3, and iterate 5 and 6.
>> 7. Develop one or more "prototypes" (i.e., the interface with canned
>> functionality). Let the user group play with it, get feedback, and
>> 8. The result should be "the" user interface.
>> One of the most important parts of this process is to identify the
>> desired characteristics of the target users, and to pick a
>> representative group of users that can lead to the widest array of
>> use-cases/user-stories that are most benefitial to the target users.
>> For example, we have primarily focused on niche-modeling as the use
>> case. (This isn't a great example, but bear with me) If our sample
>> user group only consisted of scientists that did niche modeling, or
>> if this were our target user group, we would probably build a user
>> interface around, and specific to niche modeling (i.e., niche
>> modeling should become an integral, and probably embedded, part of
>> the interface). Of course, for us, this isn't necessarily true
>> because we know we have a more general target user group. But,
>> hopefully you get the point.
>>> Deana Pennington wrote:
>>>> In thinking about the Kepler UI, it has occurred to me that it
>>>> would really be nice if the ontologies that we construct to
>>>> organize the actors into categories, could also be used in a
>>>> high-level workflow design phase. For example, in the niche
>>>> modeling workflow, GARP, neural networks, GRASP and many other
>>>> algorithms could be used for that one step in the workflow. Those
>>>> algorithms would all be organized under some high-level hierarchy
>>>> ("StatisticalModels"). Another example is the Pre-sample step,
>>>> where we are using the GARP pre-sample algorithm, but other
>>>> sampling algorithms could be substituted. There should be a
>>>> high-level "Sampling" concept, under which different sampling
>>>> algorithms would be organized. During the design phase, the user
>>>> could construct a workflow based on these high level concepts
>>>> (Sampling and StatisticalModel), then bind an actor (already
>>>> implemented or using Chad's new actor) in a particular view of that
>>>> workflow. So, a workflow would be designed at a high conceptual
>>>> level, and have multiple views, binding different algorithms, and
>>>> those different views would be logically linked through the high
>>>> level workflow. The immediate case is the GARP workflow we are
>>>> designing will need another version for the neural network
>>>> algorithm, and that version will be virtually an exact replicate
>>>> except for that actor. Seems like it would be better to have one
>>>> workflow with different views...
>>>> I hope the above is coherent...in reading it, I'm not sure that it
>>>> is :-)
>> seek-dev mailing list
>> seek-dev at ecoinformatics.org
More information about the Seek-dev