Design deliverable & process working documents

Tue Apr 17 13:33:17 UTC 2007

On Apr 14, 2007, at 9:05 AM, Colin Clark wrote:

> Hi all,
>
> Anastasia is away on vacation in Paris (lucky!) for the next few
> weeks, but I thought I'd respond to some of these questions because
> they're quite interesting. I'm sure Daphne will have other thoughts
> about this topic, too.
>
> On 12-Apr-07, at 6:11 PM, Anastasia Cheetham wrote:
>> Is 'design pattern' too high-level in this case? I'm thinking about
>> the design patterns that have been written up on the UI DG site in
>> Sakai, and it seems to me that an 'implementation' of these patterns
>> might involve more than one component. Maybe it's my engineer's
>> brain, but I've been thinking of a component as something much more
>> fine-grained.
>
> I see a clear analogy between a UI design pattern and a flexible UI
> component. You're right that many of the patterns we've been working
> on in Sakai recently have been fairly large-scale, but patterns by
> nature range from large and general to very detailed and fine-grained.
>
> For example, UI patterns in Jenifer Tidwell's _Designing Interfaces_
> book range from something as small as "Dropdown Chooser" to larger,
> more diffuse patterns such as "Visual Framework" or "Global
> Navigation." Christopher Alexander's original architectural patterns
> were like this too, encompassing patterns that describe good urban
> planning down to more detailed patterns about wall placement in a
> building.
>
> Clearly not all design patterns could be suitably implemented as
> FLUID components, but I think there are many cases where the
> combination of user models, UI design patterns, and flexible
> component implementations will provide a strong foundation for
> building new user interfaces with the FLUID framework.

Exactly.  The level of granularity for components is still a bit  
fuzzy I think.  Some things like a paging type component or perhaps a  
back/forward navigation component seem pretty clear.  Higher level  
components such as file navigation need some thinking about how we  
capture the various users needs and contexts in an implementation.   
One question I've been thinking about regarding these more inclusive  
components is: does implementing for a particular context take away  
the reusable value?  If we build a image browser or "image light  
table" component for instance, how many times is that likely to be  
used in a particular application?  Perhaps it's value is in reuse  
across the applications FLUID wants to support?  We are definitely  
breaking new ground.  What do others think?
>
>> Regarding users/personas: These always seem to be Sakai and UPortal
>> people - should we include Kuali and Moodle?
>
> We definitely need to keep Kuali Student and Moodle in mind.
>
> I expect that York University, since they have recently chosen to
> adopt Sakai as their primary LMS, will provide us with some
> additional design and testing support in regards to Moodle.
>
> It's still early for Kuali Student. They are still in the governance
> planning and high-level architecture phase at the moment. As they
> start to build user interface prototypes over the next year or so, I
> expect we'll get more involved in helping build user profiles and
> personas in context of Kuali Student.

I see the user profiles as higher ed profiles rather than being  
specific to the application.  The profiles define the different types  
of user groups we have in higher ed.  Personas should be defined more  
specific to a type of activity and I think there are likely user  
activities that are similar across the applications (especially Sakai  
and Moodle).  In a sense, the profiles will help specific development  
projects think about who they need to talk to to define their problem  
space, user goals and solutions ("we should talk to people from each  
of these groups to make sure we understand use across higher ed").   
Again, this is very much a work in progress and some initial  
thoughts.  Looking forward to further conversations about how this  
will play out.
>
>> Regarding swappability: At what point in the design process would
>> consideration of swapping come into play? What is the relationship
>> (if any) between the personas and the factors that would control
>> swapping?
>
> This is a really good question. So our plan is to allow for user
> interface components to be swapped based on personal accessibility
> preferences. For example, substituting a highly mouse-based component
> for one that has been designed specifically for screen reader users.
> What sorts of design models would help us in determining the best
> types of user interface transformations, etc?

This is where I see user models like personas being very valuable.   
To keep it simple for now, let's say we define a paging component  
based on a design pattern around allowing users to view chunks of  
information rather than overwhelm them with everything at once (for  
now this is made a pattern on the fly :) ).   Different personas  
would need a different implementation of the pattern to meet their  
specific needs.  Perhaps we have a paging component that is keyboard- 
based for a screen reader persona and one that is mouse-based for  
another persona and even another one that works for our persona that  
is a savvy PDA user.

-Daphne
>
> Colin
>
> ---
> Colin Clark
> Inclusive Software Architect/Programmer
> Adaptive Technology Resource Centre, University of Toronto
> 416-978-7728 / colin.clark at utoronto.ca
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Interaction Designer
University of California, Berkeley
Educational Technologies 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/20070417/8df7225a/attachment.htm>