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

Rod Spears 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.
> Deana
> 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 
>>> 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 
>> seek-specific)
>> 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 
>> user-needs.
>> 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 
>> 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.
>> shawn
>>> 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
>> _______________________________________________
>> seek-dev mailing list
>> seek-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev

More information about the Seek-dev mailing list