[seek-dev] Re: [seek-kr-sms] UI
Rod Spears
rods at ku.edu
Tue Jun 15 08:06:59 PDT 2004
I am not against boxes with arrows. But the problem is when you
completely integrate the boxes and arrows with a tool that only "thinks"
about boxes and arrows one particular way.
Rod
Bertram Ludaescher wrote:
>>>>>>"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." 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 & 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-dev/attachments/20040615/f9423b13/attachment.htm
More information about the Seek-dev
mailing list