Component discussion

[Colin Clark]

Hi Kathy,

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."
* Navigation
   * Re-usable menus and navigation bars
   * Breadcrumbs
* 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 
for implementing the user interface logic within JavaScript on the 
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
> that might want to happen in html/css/javascript component:
> 
> 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,
> which many people do want to see. This might be a javascript project.

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:

http://wiki.fluidproject.org/display/fluid/Accessibility+Transformation+Brainstorming

> 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,

Colin

-- 
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org