colin.clark at utoronto.ca
Wed May 30 21:58:07 UTC 2007
This response is long overdue, apologies for the delay. It's great to
have you helping out with Fluid!
I've copied the fluid-work list on this email because I think much of
the discussion is relevant to the wider community.
> My next question for you: how do I think about what can be made into a
> component? Do we have a list of suggestions?
Off the top of my head, I don't think we have good list of suggestions
for Fluid components yet. We've done a lot of component brainstorming in
the past but I haven't documented it anywhere.
Daphne, do you have the list of component ideas we compiled when I was
in Berkeley, by chance?
In the meantime, we've been thinking about Fluid components as being
akin to UI design patterns in several ways. First, Fluid components are
intended to be customizable for specific contexts, rather than fully
prescriptive in their appearance and functionality. Of course they will
have a default look and feel which represents the best design for the
context in which they were built.
So there are lots of patterns in Jenifer Tidwell's _Designing
Interfaces_ book that we think would make a lot of sense as components.
Here are some of the things I usually talk about when presenting Fluid:
"Components are recurring interactions."
* Re-usable menus and navigation bars
* Forms and data entry
* Address forms, login forms, etc.
* Direct manipulation of objects (eg. the Lightbox)
* Drag and drop
* Folders, files, and hierarchies
* Direct manipulation of on-screen objects
* Workflows, wizards, and sequences
* Multi-step indicators
* Layout and organization
* Sortable tables
* Extras on demand widget
I've been thinking a lot recently about the fact that many improvements
may involve improvements to the HTML and CSS, but may not be appropriate
client side. I think there's definitely a place in Fluid for consistent
and reusable HTML and CSS designs, particularly if they are paired with
UI design patterns that specify the necessary behaviour. Gonzalo's done
some great work in this regard for Sakai, and I'd like to work with him
to evolve this for Fluid.
> Here are three thoughts for interface-intensive improvements, things
> The multi-step indicator, with room for a fairly bold graphic treatment.
> In the Sakai Resources tool, most of our users don't use most of the
> columns: Access/Created by/Modified/Size, but apparently they were once
> requested and there's some attachment to them. Our head of user services
> put in a Jira report, SAK-7478, asking that users be able to modify or
> hide these columns. Then we could add a column to show a description,
This sounds really interesting. I think the Resources tool is ripe for
Fluidization, so to speak.
There are so many interactions that are awkward or overwhelming when you
have implement them with the limited set of form controls available with
plain HTML and full-page requests. In the long run, Resources is one of
the places where the rich interactions of Fluid may be able to help most.
> The Sakai schedule tool really wants to add events from each cell in the
> calendar, like Microsoft Outlook, not to make you click Add and then
> specify the date and time.
This also sounds like a good suggestion.
I'd like to start documenting ideas for Fluid components. I'll try to
put up a wiki page soon. Do you mind if I add these as well?
Compiling a list of ideas about components will help to provide some
context to our discussion on the list and to some of our ongoing
architecture work. Ultimately our choice of components to actually build
will be prioritized based on the rest of our design activities, but
having a "component ideas" page would still be helpful.
Another section you might want to take a look at is the brainstorming
page for component transformation in the wiki:
> I'm going to poke around and see what I can learn about usability issues
> in uPortal.
Let me know what you come up with. This is an area where I want to put
more attention on as soon as possible. We're interviewing candidates for
our new interaction designer position, and looking to enlist other
designers in the uPortal community. At that point, I expect we'll build
our next component within the context of uPortal.
Thanks again for your help,
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
More information about the fluid-work