Announcing the FLUID Project
markjnorton at earthlink.net
Wed May 9 14:57:54 UTC 2007
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.
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,
More information about the fluid-work