[seek-dev] Re: [seek-kr-sms] UI
dpennington at lternet.edu
Fri Jun 11 13:46:43 PDT 2004
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
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
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 design:
> 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 them.)
> 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
Deana D. Pennington, PhD
Long-term Ecological Research Network Office
UNM Biology Department
1 University of New Mexico
Albuquerque, NM 87131-0001
505 272-7080 (fax)
More information about the Seek-dev