[seek-dev] Re: [seek-kr-sms] UI

Shawn Bowers bowers at sdsc.edu
Fri Jun 11 13:32:52 PDT 2004

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

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

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.


> Rod
> 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  
>> :-)
>> Deana

More information about the Seek-dev mailing list