Announcing the FLUID Project
daphne at media.berkeley.edu
Wed May 9 17:44:31 UTC 2007
On May 9, 2007, at 7:57 AM, Mark Norton wrote:
> 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
> are a valuable tool. Combined with other techniques like user
> 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
> inferences about statements like, "Anne selected the year-month-day
> format from the drop down menu", we work from a statement like, "a
> 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.
This makes a lot of sense to me. I think scenarios ( "Anne selected
the year-month-day format from the drop down menu") are useful in
interaction design to make sure we understand the context of use. I
can see that they may be too abstract for implementation. We can
pull the functional requirements from the scenarios and/or use cases
so that we have a more explicit list. 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?
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. 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. 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.
> Based on my experience with IMS, Sakai, Moodle, and many other
> 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.
> requirements for such a widget could then be extracted, reviewed, and
> considered for further design.
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. I think the key will be
including the context with the components for ease of use in design
later. So for a concrete example, we are currently tackling a drag
and drop component for organizing images. This may end up being a
couple of transformable components since drag and drop isn't
currently accessible (so a keyboard only component may also be
necessary). This is completely hypothetical since prioritization of
future work is still in the works but... I could see another drag and
drop component for moving modules around in a portlet for example.
They will be very similar and both fall under the umbrella of the
same design pattern (organize content perhaps...the pattern
definition is being done in parallel for this first component in
order to move forward) but there may be some idiosyncratic
differences based on the context of how users think about the
organizing. How does this sit with you? I realize this is still
pretty abstract we'll continue to get more explicit as we learn
> 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
> 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.
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.
This is a great conversation to be having!
> fluid-work mailing list
> fluid-work at fluidproject.org
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work