Is "component" a misnomer? Is a higher level term needed?

[Colin Clark]

Hi all,

I agree with Daphne's comment that there are two separate threads to the 
discussion:

1) From the technical perspective, what is the scope of a reusable 
component?

2) From the UX walkthrough perspective, how do we best ensure that the 
results point to meaningful design solutions for our users?

I think having both discussions is productive. I've spent a lot of time 
talking with people about components from both the user perspective and 
the technical perspective, and particularly their relationship to design 
patterns. This is one of my favourite topics! :)

Here are some thoughts on the technology side, prompted by Antranig's 
post last week.

Antranig's response sums up an ongoing conversation that he and I have 
been having since well before the Fluid Project started. I'm thoroughly 
enthused by the notion of self-contained, reusable chunks of user 
interface that can be easily adapted to suit the various interaction 
patterns that we see in lots of places throughout an application. 
Manipulating files and content is a classic case, common to all kinds of 
applications, especially on the desktop. Imagine how frustrating it 
would be to work with content without the embeddable components within 
desktop GUIs for loading, saving, picking, and manipulating files!

In my thinking, the Fluid conception of a component specifically makes 
an attempt to correspond more closely with the kinds of workflows and 
activities that users engage in while using our software. This will 
naturally be at both the smaller and larger scale, from calendar pickers 
to file viewers on up to larger-scale multi-step wizards and flows. 
Thus, components aren't just widgets, but larger assemblages of UI 
behaviour.

It seems to me that the way to achieve this from the technical 
perspective is with cooperating client and server-side frameworks. On 
the server, I envision the ability to easily address chunks of service 
logic and markup-generation capabilities independent of the current 
boundaries for a portal or a tool.

On the client, we can take advantage of the flexibility and late binding 
of JavaScript to build richer user interfaces that can directly 
query--through the "open URL space" of an application--all of the logic 
needed to enable useful interactions with the system, without requiring 
users to break out of their current workflow to do some related but not 
co-located task.

I will be honest in saying I've essentially given up in coming up with a 
more suitable terminology than "component" on the technical side. While 
I think it's entirely worthwhile (there are so many preconceptions about 
what a component is), I just haven't come up with anything succinct and 
coherent enough. "UI Unit" is just about as good as I can get, and 
that's not very good. :)

> ii) The permissions system similarly has a single "one-size-fits-all"
> view full of a huge heap of tickboxes. These cannot be placed
> "close to the tools", unless the tool defines within itself a
> completely custom view, which once done, conversely cannot be
> dispatched back to a central location!

The issue of permissions seems in some ways similar to the problem of 
where to locate preferences, something my team has been talking a lot 
about recently. There are so many cases where the "Control Panel" or 
Wizard approach to specifying preferences is really inconvenient. Such 
preferences might be best stated directly in context of the work the 
user is currently doing, so that the effect of the preference change is 
immediately visible.

Colin

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