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

[Rod Spears]

I agree with Ferdinando and the entire problem can be boiled down to his 
quote "/we need to start a synthesis (top-down) effort aimed at 
understanding what's the language that shapes an ecologist's thinking 
when they approach a problem/"

Of course, I think the word "language" is both literal and figurative.

I disagree with the notion that Kepler is a "/visual modeling and 
analysis language/." Or if it is that, it is at too low level and the 
moment entirely too difficult for the non-SEEK scientists to use. The 
solution isn't "just fix Kepler's UI."   Kepler has an important role to 
play in the project, it is a very powerful tool as we all know. The 
point is, let's not /force /it to play role it isn't necessarily meant 
to play.

Rod


Ferdinando Villa wrote:

>One way I would frame this discussion, thinking about the comment about
>"visual modeling and analysis language" and the whole UI issue, is that
>we need to start a synthesis (top-down) effort aimed at understanding
>what's the language that shapes an ecologist's thinking when they
>approach a problem, and characterize its relationship with the two
>conceptual frameworks we've been concentrating on so far: the KR
>framework and the workflow framework (in their abstract nature, before
>going down to OWL and Ptolemy, and WITHOUT one thought to any pretty
>screenshot!). The exercise should highlight whether we need to (a) have
>enough of one - maybe slightly extended - and infer the other, (b) find
>something that sits in the middle, or (c) find something totally
>different. This done, we should be able to easily define the visual
>language that most closely embodies it.
>
>Back to personal opinions, I'll just add that it's my belief that this
>process, although it needs very open minds, doesn't necessarily have to
>be very long and very hard, and I think we have all the pieces in place
>to quickly prototype the right UI (as opposed to the "advanced" one!)
>when the idea is clear, without having to distance ourselves much from
>things as they stand now...
>
>ferd
>
>On Mon, 2004-06-14 at 08:56, Rod Spears wrote:
>  
>
>>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.
>>
>>Rod
>>
>>
>>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
>>>>        
>>>>
>>>      
>>>
>>_______________________________________________
>>seek-kr-sms mailing list
>>seek-kr-sms at ecoinformatics.org
>>http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
>>    
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040614/0fab7aba/attachment.htm