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

[Shawn Bowers]

Deana Pennington wrote:

> Although I understand the desire to fully flesh out the intended user's 
> thinking and needs by soliciting feedback from an extensive group of 
> non-SEEK users, I'm pretty sure that any survey/test that we tried to 
> conduct right now, with nothing but the current Kepler app to work with, 
> will be severely hampered by their ability to envision anything else. 

I don't know if you are referring here to what I suggested below, but if 
so, this isn't what I was saying at all.



shawn



> 
> Deana
> 
> 
> 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
>>>   
> 
>