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

Nico M. Franz franz at nceas.ucsb.edu
Fri Jun 11 16:29:38 PDT 2004

To Shawn:

    I think item 9. (or 1.?) on your list ought to read: "invite potential 
sponsors and users on a two-week cruise to the Bahamas." But then perhaps 
academics' role in society is to be a bit more idealistic..

To all:

    I want to make it clear that in my previous e-mail, the "top" for 
taxonomy wasn't a group of scientists or a set of relevant conceptions or 
practices (however fixed or flexible). In that sense I abducted 
Ferdinando's and Shawn's original points for different purposes. I truly 
think that the taxon group's top constraint is one related to long-term 
persistence, and to the economic solutions required to provide this 

    I have personally rather quickly given up on the idea of lobbying our 
ideas about taxonomic concepts with the expert community by approaching 
them directly. The ideas may well be brilliant, very useful and highly 
necessary. But the experts will rightly ask: "how long will my 
contributions last on-line, and who will pay for their long-term 
maintenance." If we cannot give satisfactory answers to these questions 
(and possibly some experts will be satisfied later than others), then we 
should not expect the experts to join in en mass. Doing real taxonomic work 
on-line (e.g. by connecting concepts from different classificatory scheme 
through synonymies) just can't be ephemeral. It needs to stand on a 
socio-economic foundation (nearly) as solid as the print 
publishing/library/museum conservation process. Otherwise, we implicitly 
force experts to invest their careers and expertise in ventures whose 
futures are not sufficiently clear to even meet the requirements of the 
Codes, much less a sustained and efficient communication about taxa.

    At best we'll lure some experts that are so secure academically that 
they can afford to put things on-line and risk that it will be lost soon. 
This work might not enter in the taxonomic legacy, and it might compromise 
their situation when applying for positions and funding. It's close to a 
non-starter, and we have evidence in the field already to support this 

    I do not know to what extent these issues apply to LTER-related aims. 
As I said before my hunch is that taxonomy has less money and more inherent 
demands for long-term persistence. This makes it harder and explains the 
tediousness of the process, and our awareness of it.

    So what are we trying to do in the taxon group? I think we're like a 
think tank that NSF funds at the moment though we're really working for a 
taxonomic service organization - yet to be named - with perceived long-term 
funding. It just might be USDA-ITIS. It might be a large scientific 
publisher like Thomson. It won't be any group of scientists, maybe not even 
a consortium of museums. The implementation of our ideas won't be exactly 
democratic, or by consensus among many experts. It will be (slightly) 
forceful and unilateral. As far as the science goes, the system won't be 
perfect or even good at the start. But it will come with economic 
respectability. The rest may eventually follow.

    To even speak with a taxonomic service provider that can look out for 
its own survival, we need some bottom-up work. We need arguments that will 
make the provider think that our bottom-up package provides a cognitive and 
thus economic edge over competitors. Once the persistence issues are 
adequately addressed, we expect users to honor our unilateral efforts, 
since we jumped over a hurdle nobody else has taken so far. The platform 
can then deepen and expand. The key issue is to understand and minimize the 
risk of it ever going away. That's a "top", it's just not a purely academic 

    Of course I wish that had all been understood long ago and addressed by 
now. But even the scientific publishers - who are loaded and do nothing but 
worry about the economics of internet publishing and maintenance of 
information - are fairly new to the business of putting their money only 
on-line. I believe that their and taxonomy's interests and requirements are 
in many ways alike.


At 01:32 PM 6/11/2004 -0700, 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 
>>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 
>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.
>>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
>seek-kr-sms mailing list
>seek-kr-sms at ecoinformatics.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-dev/attachments/20040611/564675fa/attachment.htm

More information about the Seek-dev mailing list