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

[Deana Pennington]

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


-- 
********

Deana D. Pennington, PhD
Long-term Ecological Research Network Office

UNM Biology Department
MSC03  2020
1 University of New Mexico
Albuquerque, NM  87131-0001

505-272-7288 (office)
505 272-7080 (fax)