Design deliverable & process working documents
daphne at media.berkeley.edu
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
> 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
> 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
> 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.
> 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
University of California, Berkeley
Educational Technologies Services
daphne at media.berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work