Announcing the FLUID Project

[Mark Norton]

Colin Clark wrote:

> Mark Norton wrote:
>
>> Could you double check and make sure I'm on this list.  I signed up 
>> for all of them when you announced them a couple of weeks ago, but 
>> haven't seen any traffic.
>
>
> I checked our mailman subscriber list and it doesn't look like you're 
> on any of the lists. Do you want me to subscribe you by hand, or do 
> you want to give it another try?

I added myself.  I thought I was already subscribed, but whatever.

>> No real shortage of scenarios, use cases and issues, eh?  If I might 
>> say, part of the problem is boiling down what's already known  and 
>> capturing it succinctly in a set of requirements (not scenarios, not 
>> use cases).  If you take a purely bottom up approach it might be 
>> possible to hit a truly general architecture in the two years covered 
>> by the Mellon grant.  I would suggest a series of abstract models 
>> that are successively refined.  Perhaps thats saying the same thing, 
>> but at least you have an architecture at any given point in time, 
>> rather than waiting for one to emerge.
>
>
> I'm interested to hear more about your thoughts in regards to 
> requirements, as I'm sure Daphne is as well.

As you now, I've done a fair amount of standards development work over 
the past 10 years.  I've seen many different approaches, some that 
worked and many that didn't.  In my experience, scenarios and use cases 
are a valuable tool.  Combined with other techniques like user studies, 
evaluation studies, direct observation, user suggestions, etc., it is 
possible to build a corpus of information around virtually any topic.  
The problem with such a collection is that it is unorganized with 
respect to the work that needs to be done in follow-on stages. 

Requirements are the distillation of those inputs into a set of 
statements that describe how something SHOULD work.  Rather than making 
inferences about statements like, "Anne selected the year-month-day 
format from the drop down menu", we work from a statement like, "a means 
must be provided to select a date format".  Note that this requirement 
doesn't state how the selection is to be performed -- that is a 
subsequent design choice.

Based on my experience with IMS, Sakai, Moodle, and many other projects, 
there are lots of UI scenarios, use cases, studies, etc. available as 
input into the FLUID project.  I strongly suspect that ATRC has it's 
share to contribute, along with UCB, CARET, etc.  If these were pooled 
in a central place, it would be possible to look for patterns across 
them.  For example, a date format selection widge (hypothetically).  
Further, we are able to see that more than one format is required:  
American, European, sortable, numeric, fully spelled out, etc.  Precise 
requirements for such a widget could then be extracted, reviewed, and 
considered for further design.

Here's the important part:  once a set of requirements around a widget 
(or behavior, etc) is finalized by the community, it becomes a goal (or 
set of goals) to achieve in design, and implemenation.  Futhermore, 
solid requirements create the basis for good test plans.  You cannot 
test for what you don't understand precisely.

> Our prioritization process will be driven by the heuristic reviews and 
> usability studies we are doing. Everyone brings a different set of 
> opinions about what needs to be fixed in each of the communities. This 
> research and design work will, I hope, start to provide some stability 
> and consensus about what issues need to be fixed by looking at the 
> problems our users encounter most when using Sakai and uPortal.

I sincerely hope you understand what you trying to design before you set 
out to do that.  Consenus on abstract requirements early on will save a 
lot of debate later.

> I think we're on the same page here in terms of architecture. My plan 
> is to define a general shape for our technical model, create 
> components to solve key usability and accessibility problems, and at 
> each stage in the development process take the time to refine the 
> architecture from a top-down and bottom-up approach.

Well, this is just my opinion, but I think you are setting yourself up 
for a lot of extra work by taking this approach.  Consider:

1.  Look at some use cases.
2.  Create a component to solve this problem.
3.  Change the architecture to encompass this solution.
4.  Modify all previously created components to fit the new architecture.
5.  Look at new use cases and iterate.

It's that forth step that you left out of your statement above that 
creates the extra work.
Consider instead:

1.  Gather all use cases (etc).
2.  Create a broad set of requirements the define what much be accomplished.
3.  Create an initial architecture
4.  Test this architecture by building models and prototypes of components
5.  Iterate and refine both models and architecture
6.  As models and architecture settle out, create tests based on 
requirments for components

Now in both cases, the architeture is successively changed and refined.  
However, the first approach, there is the danger that the ordering of 
component development will have a radical impact on the architcture and 
design later on.  In the second approach, the initial design takes a 
much broader view.  In my mind, this reduces risk, because I'm not 
focused too closely on one aspect of a much larger problem (as defined 
by the requirements).  The chances of get it "close to right" are 
higher.  The subsequent changes to the architecture are likely to have a 
reduced impact on existing models and implementations.

> All of this process, both in terms of requirements and technical 
> design will take time to work out together as a community. We'd 
> appreciate your feedback and patience as we get started.

I will provide input as time allows.

> In the meantime, we're focusing on areas where we've already done a 
> lot of design research and that will provide manageable scope making 
> "bite-sized" improvements and for experimenting with potential 
> architectural solutions. 

Just remember what the term "architecture" refers to.  It is the 
foundation of an application.  It is the bedrock on which the whole 
structure is built.  It is the "bones" that provide strong support.  
While the bricks&mortar analogy can be taken too far, if you tinker with 
the foundation of a building after starting it's construction, you risk 
have the whole thing fall down around you.  This is not a problem as 
long as you have the time and money to build it again:  from the 
foundation on up.  You cannot build a roof first.

> I believe very strongly in proving architectures through practice.

I agree.  Where we may disagree is how that is accomplished.  Pratice 
informs and shapes architecture.  Architecture is realised in design.  
Implementation comes from design and implementations are tested against 
the original practice expectations.  Writing code and expecting good 
architecture to emerge rarely (if ever) works.

For what it's worth,

Mark Norton