Announcing the FLUID Project

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  
> 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.
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  
> 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.
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  
through doing.
>
> 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.
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!

-Daphne

>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20070509/6cd50b15/attachment.htm>