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

Bertram Ludaescher ludaesch at sdsc.edu
Tue Jun 15 03:47:20 PDT 2004


>>>>> "RS" == Rod Spears <rods at ku.edu> writes:
RS> 
RS> I agree with Ferdinando and the entire problem can be boiled down to his 
RS> quote "/we need to start a synthesis (top-down) effort aimed at 
RS> understanding what's the language that shapes an ecologist's thinking 
RS> when they approach a problem/"
RS> 
RS> Of course, I think the word "language" is both literal and figurative.
RS> 
RS> I disagree with the notion that Kepler is a "/visual modeling and 
RS> analysis language/." Or if it is that, it is at too low level and the 
RS> moment entirely too difficult for the non-SEEK scientists to use. The 

boxes with arrows between them is about as abstract as you can get I
think (as well as concrete, depending on what the boxes stand for).

Maybe we need to think about how IMA or other more conceptual
approaches can be viewed as boxes with arrows between them. I might be 
stretching this a bit, but I think that in principle it should be
possible to draw an ER or UML class diagram as an actor network. With
the right "director" such an network might allow to query the
conceptual ER/UML schema or some underlying databases conforming to
that schema. It's certainly different from what Ptolemy folks had
originally in mind, but given their very abstract approach and very
hooks into the system I wouldn't be surprised if such a conceptual
data modeling and querying tool were in fact quite easy to implement
on top of Ptolemy. 

However even more interesting is, again, to think what structured
approach to analysis pipelines or integrated modeling one would
need.. 

Bertram
RS> solution isn't "just fix Kepler's UI."   Kepler has an important role to 
RS> play in the project, it is a very powerful tool as we all know. The 
RS> point is, let's not /force /it to play role it isn't necessarily meant 
RS> to play.
RS> 
RS> Rod
RS> 
RS> 
RS> Ferdinando Villa wrote:
RS> 
>> 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
>>> 
>>> 
RS> 
RS> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
RS> <html>
RS> <head>
RS>   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
RS>   <title></title>
RS> </head>
RS> <body bgcolor="#ffffff" text="#000000">
RS> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
RS> <title></title>
RS> I agree with Ferdinando and the entire problem can be boiled down to
RS> his quote "<i>we
RS> need to start a synthesis (top-down) effort aimed at understanding
RS> what's the language that shapes an ecologist's thinking when they
RS> approach a problem</i>"<br>
RS> <br>
RS> Of course, I think the word "language" is both literal and figurative. <br>
RS> <br>
RS> I disagree with the notion that Kepler is a "<i>visual modeling and
RS> analysis language</i>." Or if it is that, it is at too low level and
RS> the moment entirely too difficult for the non-SEEK scientists to use.
RS> The solution isn't "just fix Kepler's UI."&nbsp;&nbsp; Kepler has an important
RS> role to play in the project, it is a very powerful tool as we all know.
RS> The point is, let's not <i>force </i>it to play role it isn't
RS> necessarily
RS> meant to play.<br>
RS> <br>
RS> Rod<br>
RS> <br>
RS> <br>
RS> Ferdinando Villa wrote:
RS> <blockquote cite="mid1087228283.4452.32.camel at basil.snr.uvm.edu"
RS>  type="cite">
RS>   <pre wrap="">One way I would frame this discussion, thinking about the comment about
RS> "visual modeling and analysis language" and the whole UI issue, is that
RS> we need to start a synthesis (top-down) effort aimed at understanding
RS> what's the language that shapes an ecologist's thinking when they
RS> approach a problem, and characterize its relationship with the two
RS> conceptual frameworks we've been concentrating on so far: the KR
RS> framework and the workflow framework (in their abstract nature, before
RS> going down to OWL and Ptolemy, and WITHOUT one thought to any pretty
RS> screenshot!). The exercise should highlight whether we need to (a) have
RS> enough of one - maybe slightly extended - and infer the other, (b) find
RS> something that sits in the middle, or (c) find something totally
RS> different. This done, we should be able to easily define the visual
RS> language that most closely embodies it.
RS> 
RS> Back to personal opinions, I'll just add that it's my belief that this
RS> process, although it needs very open minds, doesn't necessarily have to
RS> be very long and very hard, and I think we have all the pieces in place
RS> to quickly prototype the right UI (as opposed to the "advanced" one!)
RS> when the idea is clear, without having to distance ourselves much from
RS> things as they stand now...
RS> 
RS> ferd
RS> 
RS> On Mon, 2004-06-14 at 08:56, Rod Spears wrote:
RS>   </pre>
RS>   <blockquote type="cite">
RS>     <pre wrap="">In many ways I think the current user-interface work for Kepler is 
RS> almost orthoginal to this discussion.
RS> 
RS> There are many issues with the current UI that need to be fixed ASAP, 
RS> but I don't think it should keep us from getting a group together to 
RS> start down the path that Shawn has outlined.
RS> 
RS> If we (and we should) take a more process oriented approach to 
RS> developing the UI this work really has little, if anything, to do with 
RS> Kepler for quite sometime.
RS> 
RS> As I see it the Kepler UI is really the "advanced" UI for SEEK. There is 
RS> a whole lot of work that needs to go on before that.
RS> 
RS> Deana has a very valid point as to how to begin this work with/without 
RS> the usability position being filled. At the same time, many different 
RS> aspects of the UI are being to take shape and time is of the essence.
RS> 
RS> Rod
RS> 
RS> 
RS> Deana Pennington wrote:
RS> 
RS>     </pre>
RS>     <blockquote type="cite">
RS>       <pre wrap="">Shawn &amp; Rod,
RS> 
RS> I think these are all great suggestions, and we've been discussimg 
RS> putting together a group of ecologists for a couple of days of 
RS> testing, but:
RS> 
RS> 1) we thought that there are some major issues with the interface as 
RS> it stands right now that need to be fixed before we try to get a group 
RS> together, and
RS> 2) a decision needs to made about the useability engineer position, so 
RS> that person can be involved right from the start in user testing and 
RS> UI design
RS> 
RS> So, I think we should table this discussion until the above 2 things 
RS> are resolved.  It's obvious that this needs to be addressed soon.
RS> 
RS> Deana
RS> 
RS> 
RS> Shawn Bowers wrote:
RS> 
RS>       </pre>
RS>       <blockquote type="cite">
RS>         <pre wrap="">Rod Spears wrote:
RS> 
RS>         </pre>
RS>         <blockquote type="cite">
RS>           <pre wrap="">(This is a general reply to the entire thread that is on seek-kr-sms):
RS> 
RS> In the end, there are really two very simple questions about what we 
RS> are all doing on SEEK:
RS> 
RS> 1) Can we make it work?
RS>     a) This begs the question of "how" to make it work.
RS> 
RS> 2) Will anybody use it?
RS>     a) This begs the question of "can" anybody use it?
RS> 
RS> Shawn is right when he says we are coming at this from the 
RS> "bottom-up." SEEK has been very focused on the mechanics of how to 
RS> take legacy data and modeling techniques and create a new 
RS> environment to "house" them and better utilize them. In the end, if 
RS> you can't answer question #1, it does matter whether you can answer 
RS> question #2.
RS> 
RS> But at the same time I have felt that we have been a little too 
RS> focused on #1, or at the very least we haven't been spending enough 
RS> time on question #2.
RS> 
RS> Both Nico and Fernando touched on two very important aspects of what 
RS> we are talking about. Nico's comment about attacking the problem 
RS> from "both" ends (top down and bottom up)  seems very appropriate. 
RS> In fact, the more we know about the back-end the better we know what 
RS> "tools" or functionality we have to develop for the front-end and 
RS> how best they can interact.
RS> 
RS> Fernando's comment touches on the core of what concerns me the most, 
RS> and it is the realization of question #2
RS> His comment: "/I also think that the major impediment to an 
RS> understanding that requires a paradigm switch is the early 
RS> idealization of a graphical user interface/." Or more appropriately 
RS> known as "the seduction of the GUI." (Soon to be a Broadway play ;-) ).
RS> 
RS> We absolutely have to create a tool that scientists can use. So this 
RS> means we have to create a tool that "engages" the way they think 
RS> about modeling problems. Note that I used the word "engage", meaning 
RS> the tool doesn't to be an exact reflection of their process for 
RS> creating a models and doing analysis, but if has to be close enough 
RS> to make them want to "step up to the plate" and "take a swing for 
RS> the fence" as it were.
RS> 
RS> In many ways too, Fernando's comment touch on the the problem I have 
RS> always had with Kepler. The UI is completely intertwined with the 
RS> model definition and the analysis specification. It has nearly zero 
RS> flexibility in how one "views" the "process" of entering in the 
RS> model. (As a side note, the UI is one of the harder aspects of 
RS> Kepler to tailor)
RS> 
RS> In a perfect world of time and budgets it would be nice to create a 
RS> tool that has standalone Modeling and Analysis Definition Language, 
RS> then a core standalone analysis/simulation engine, and lastly a set 
RS> of GUI tools that assist the scientists in creating the models and 
RS> monitoring the execution. Notice how the GUI came last? The GUI 
RS> needs to be born out of the underlying technology instead of 
RS> defining it.
RS> 
RS> I am a realist and I understand how much functionality Kepler brings 
RS> to the table, it gives us such a head start in AMS. Maybe we need to 
RS> start thinking about a more "conceptual" tool that fits in front of 
RS> Kelper, but before that we need to really understand how the average 
RS> scientist would approach the SEEK technology. I'll say this as a 
RS> joke: "but that pretty much excludes any scientist working on SEEK," 
RS> but it is true. Never let the folks creating the technology tell you 
RS> how the technology should be used, that's the responsibility of the 
RS> user.
RS> 
RS> I know the word "use case" has been thrown around daily as if it 
RS> were confetti, but I think the time is approaching where we need to 
RS> really focus on developing some "real" end-user use cases. I think a 
RS> much bigger effort and emphasis needs to be placed on the 
RS> "top-down." And some of the ideas presented in this entire thread is 
RS> a good start.
RS>           </pre>
RS>         </blockquote>
RS>         <pre wrap="">
RS> Great synthesis and points Rod.
RS> 
RS> (Note that I un-cc'd kepler-dev, since this discussion is very much 
RS> seek-specific)
RS> 
RS> I agree with you, Nico, and Ferdinando that we need top-down 
RS> development (i.e., an understanding of the targeted user problems and 
RS> needs, and how best to address these via end-user interfaces) as well 
RS> as bottom-up development (underlying technology, etc.).
RS> 
RS> I think that in general, we are at a point in the project where we 
RS> have a good idea of the kinds of solutions we can provide (e.g., with 
RS> EcoGrid, Kepler, SMS, Taxon, and so on).
RS> 
RS> And, we are beginning to get to the point where we are 
RS> building/needing user interfaces: we are beginning to 
RS> design/implement add-ons to Kepler, e.g., for EcoGrid querying and 
RS> Ontology-enabled actor/dataset browsing; GrOWL is becoming our 
RS> user-interface for ontologies; we are designing a user interface for 
RS> annotating actors and datasets (for datasets, there are also UIs such 
RS> as Morhpo); and working on taxonomic browsing.
RS> 
RS> I definately think that now in the project is a great time to take a 
RS> step back, and as these interfaces are being designed and implemented 
RS> (as well as the lower-level technology), to be informed by real 
RS> user-needs.
RS> 
RS> 
RS> Here is what I think needs to be done to do an effective top-down 
RS> design:
RS> 
RS> 1. Clearly identify our target user group(s) and the general benefit 
RS> we believe SEEK will provide to these groups. In particular, who are 
RS> we developing the "SEEK system" for, and what are their 
RS> problems/needs and constraints.  Capture this as a report. (As an 
RS> aside, it will be very hard to evaluate the utility of SEEK without 
RS> understanding who it is meant to help, and how it is meant to help 
RS> them.)
RS> 
RS> 2. Assemble a representive group of target users. As Rod suggests, 
RS> there should be participants that are independent of SEEK. [I 
RS> attended one meeting that was close to this in Abq in Aug. 2003 -- 
RS> have there been others?]
RS> 
RS> 3. Identify the needs of the representive group in terms of SEEK. 
RS> These might be best represented as "user stories" (i.e., scenarios) 
RS> initially as opposed to use cases.  I think there are two types of 
RS> user stories that are extremely benefitial: (1) as a scenario of how 
RS> some process works now, e.g., the story of a scientist that needed to 
RS> run a niche model; (2) ask the user to tell us "how you would like 
RS> the system to work" for the stories from 1.
RS> 
RS> 4. Synthesize the user stories into a set of target use cases that 
RS> touch a wide range of functionality.  Develop and refine the use cases.
RS> 
RS> 5. From the use cases and user constraints, design one or more 
RS> "storyboard" user interfaces, or the needed user interface components 
RS> from the use cases.  At this point, there may be different possible 
RS> interfaces, e.g., a high-level ontology based interface as suggested 
RS> by Ferdinando and a low-level Kepler-based interface.  This is where 
RS> we need to be creative to address user needs.
RS> 
RS> 6. Get feedback from the target users on the "storyboard" interfaces 
RS> (i.e., let them evaluate the interfaces). Revisit the user stories 
RS> via the storyboards. Refine the second part of 3, and iterate 5 and 6.
RS> 
RS> 7. Develop one or more "prototypes" (i.e., the interface with canned 
RS> functionality). Let the user group play with it, get feedback, and 
RS> iterate.
RS> 
RS> 8. The result should be "the" user interface.
RS> 
RS> 
RS> One of the most important parts of this process is to identify the 
RS> desired characteristics of the target users, and to pick a 
RS> representative group of users that can lead to the widest array of 
RS> use-cases/user-stories that are most benefitial to the target users.
RS> 
RS> For example, we have primarily focused on niche-modeling as the use 
RS> case. (This isn't a great example, but bear with me) If our sample 
RS> user group only consisted of scientists that did niche modeling, or 
RS> if this were our target user group, we would probably build a user 
RS> interface around, and specific to niche modeling (i.e., niche 
RS> modeling should become an integral, and probably embedded, part of 
RS> the interface). Of course, for us, this isn't necessarily true 
RS> because we know we have a more general target user group. But, 
RS> hopefully you get the point.
RS> 
RS> 
RS> shawn
RS> 
RS> 
RS>         </pre>
RS>         <blockquote type="cite">
RS>           <pre wrap="">Rod
RS> 
RS> 
RS> Deana Pennington wrote:
RS> 
RS>           </pre>
RS>           <blockquote type="cite">
RS>             <pre wrap="">In thinking about the Kepler UI, it has occurred to me that it 
RS> would really be nice if the ontologies that we construct to 
RS> organize the actors into categories, could also be used in a 
RS> high-level workflow design phase.  For example, in the niche 
RS> modeling workflow, GARP, neural networks, GRASP and many other 
RS> algorithms could be used for that one step in the workflow.  Those 
RS> algorithms would all be organized under some high-level hierarchy 
RS> ("StatisticalModels").  Another example is the Pre-sample step, 
RS> where we are using the GARP pre-sample algorithm, but other 
RS> sampling algorithms could be substituted.  There should be a 
RS> high-level "Sampling" concept, under which different sampling 
RS> algorithms would be organized.  During the design phase, the user 
RS> could construct a workflow based on these high level concepts 
RS> (Sampling and StatisticalModel), then bind an actor (already 
RS> implemented or using Chad's new actor) in a particular view of that 
RS> workflow.  So, a  workflow would be designed at a high conceptual 
RS> level, and have multiple views, binding different algorithms, and 
RS> those different views would be logically linked through the high 
RS> level workflow.  The immediate case is the GARP workflow we are 
RS> designing will need another version for the neural network 
RS> algorithm, and that version will be virtually an exact replicate 
RS> except for that actor.  Seems like it would be better to have one 
RS> workflow with different views...
RS> 
RS> I hope the above is coherent...in reading it, I'm not sure that it 
RS> is  :-)
RS> 
RS> Deana
RS> 
RS> 
RS>             </pre>
RS>           </blockquote>
RS>         </blockquote>
RS>         <pre wrap="">_______________________________________________
RS> seek-dev mailing list
RS> <a class="moz-txt-link-abbreviated"
RS>  href="mailto:seek-dev at ecoinformatics.org">seek-dev at ecoinformatics.org</a>
RS> <a class="moz-txt-link-freetext"
RS>  href="http://www.ecoinformatics.org/mailman/listinfo/seek-dev">http://www.ecoinformatics.org/mailman/listinfo/seek-dev</a>
RS>         </pre>
RS>       </blockquote>
RS>       <pre wrap="">
RS>       </pre>
RS>     </blockquote>
RS>     <pre wrap="">_______________________________________________
RS> seek-kr-sms mailing list
RS> <a class="moz-txt-link-abbreviated"
RS>  href="mailto:seek-kr-sms at ecoinformatics.org">seek-kr-sms at ecoinformatics.org</a>
RS> <a class="moz-txt-link-freetext"
RS>  href="http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms">http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms</a>
RS>     </pre>
RS>   </blockquote>
RS> </blockquote>
RS> <br>
RS> </body>
RS> </html>



More information about the Seek-dev mailing list