[seek-dev] Re: [seek-kr-sms] UI
Rod Spears
rods at ku.edu
Tue Jun 15 08:14:25 PDT 2004
I don't think we have enough information to do anything at the moment,
which basically what Shawn's message was about.
We need to do some formal "use case" analysis to understand our user's
"mental model" and what our users need before we can propose doing
anything. In fact, my belief that Kepler is not necessarily the right
tool for the "top-down" approach is rather premature.
I think the only thing we know is that Kepler with a part of some
portion of the solution. (Oh, and that boxes and arrows will be used
somewhere ;-) .)
Rod
Deana Pennington wrote:
> One way to look at this is to think about short-term (next year) vs
> intermediate term (next 3 years of SEEK) vs long-term (decade+)
> visions. I am completely sold on Ferdinando's approach for the
> long-term. I don't think that it's something we can fully implement
> within the SEEK time frame. But I do think that we can design some
> short/intermediate-term objectives that will build on the things we
> are already doing in Kepler and be consistent with the long view. Can
> we (the "open-minded, interested SEEK participants of Ferdinando's
> opinion below) come up with some very short term objectives that
> include both approaches? Something implementable within the next few
> months? If so, then I would be very interested in getting a user
> group together to test 1) kepler alone, 2) IMA alone, and 3) a
> prototype combined approach. 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. So, does anyone want to
> propose something that would be implementable in the short term, that
> merges top-down/bottom-up approaches as a prototype?
> I have already suggested that we take the GARP pipeline and implement
> it in IMA. In my original posting to this list, I suggested that we
> take the limited number of actors that we are using, construct a
> partial ontology that represents them and link it with whatever other
> ontologies we are constructing, and design an interface that would
> allow the user to work with those concepts rather than directly with
> the kepler actors, which could be selected and bound to the concept in
> the final design step. It seems (to me) that this (or some other
> simplistic merging of approaches) should not be that hard to do. Ideas?
>
> 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
>>>
>>
>
More information about the Seek-dev
mailing list