Announcing the FLUID Project

[Mark Norton]

Daphne Ogle wrote:

> I think it's important for the scenarios to go along for the ride to 
> help us make prioritization decisions as we go along.  If the team 
> understands the scenarios driving the design we are less likely to 
> de-prioritize a requirement that is critical to completing the 
> scenario.  Without the context, the list of requirements becomes a 
> disparate list of actions.  Is this in line with your experience?

Yes, I agree, context is important.  Fortunately, with tools like a 
wiki, this kind of documentation becomes possible.  Hypertext was 
designed with this kind of documentation in mind.

>
> I've created the first draft spec of the image organization component 
> and realize in the short time period I didn't pull out the 
> requirements.  I'll do that soon and would love to get some thoughts 
> on the usefulness of the document from a development perspective.  
> I'll post to the wiki. 

Let me know and I'll have a look at it.

> I'll be working closely with the development team at the ATRC to 
> evaluate the right level of documentation in order to get our work 
> done while preserving the intent of agile to learn and adjust quickly 
> as we go along.  We are thinking of this process as iterative and 
> since we are working in an agile environment a lot of the details will 
> be worked out in conversation as the work is happening. 

As I pointed out in my last message, the iterative refinement work has 
to be done with the right view in mind.  Architecture is an abstraction 
that suffers from both larger preterbations and slow acretion.  I 
seriously doubt that you will come up with a good architecture for Fluid 
by looking at one scenario/component, then another, followed by more.  
Rather, the architecture should be tested by building components against 
the current model and evaluating how well it is working.

I should clarify that I'm not against experimentation. On the contrary, 
it's vital.  I will be interested to observe how agile programming will 
lead to a strong architecture that can be applied to a broad range of 
problems.  While I can see how agile techniques can lead to a good 
application user interface, that approach doesn't necessary define an 
approach that will handle all similar UI's.  Do you have any 
documentation on how agile programming will be applied in THIS project?

> Yet we'll want to have the right level of documentation moving forward 
> so the community can understand why and how we made decisions as our 
> applications and the components within them continue to evolve.

Yes, vital.

> This is interesting.  From an interaction design perspective, context 
> is very important.  We've been thinking a lot about how to preserve 
> the context yet create generalizable components.  The current thinking 
> (from my perspective...others please chime in) is to start small and 
> build a components for specific contexts which will help us think 
> about how to make them generalizable. 

Classic bottom-up design approach.  Work with the intances and 
generalize later.  It's very, very easy to get absorbed into the details 
and completely loose sight of the larger abstractions.  Good discipline 
can prevent this, but it's very hard.  Top-down equally has problems.  
It leads to impractical designs that have no real basis in practice.  
Elegant, but unusable as we've seen all too often.

The approach I'm advocating has sometimes been called middle-out.  The 
idea is to try and gain as broad a view as possible of what the 
abstraction should look like (and requirements is the best way to get 
this view), create an architecture/design and immediately test it 
against practice.  It's still iterative, but is more of a model - test, 
rather than implement - abstract approach.

> Absolutely!  Determining the right way and level to communicate the 
> requirements and design based on existing best practices and our work 
> is something the FLUID project can contribute back to the communities 
> as part of the "Design toolkit" we plan to deliver.

I agree with that.

- Mark Norton