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

antranig at caret.cam.ac.uk antranig at caret.cam.ac.uk
Fri Sep 14 22:58:48 UTC 2007


Hi there Paul - glad we're thinking along such similar lines!

This word "component" is one we've also had a lot of difficulty with
in RSF... we have at least two things that could go by that name,
neither of which really correspond extremely well with the things
that typically go by these names in UI designs. I like to think that
this confusion signifies how close together Fluid and RSF are in
their aim to reformulate the way we think of "reusable units of UI
real estate", but as you say it does leave a bit of a terminology gap.

At the base, we have what have now been termed "primitive components",
which simply reflect direct markup realities. Tags, but abstracted.

At the next layer up, we have units of an application which are
dispatchable "within code", which used to be called "evolvers" but
are effectively any kind of "producers" which construct part of a
component tree. Over time we have come to call these simply
"components", since they correspond more nearly to what other people
call components.

At the top layer, we have application-wide "addressible application
units" - these are not necessarily indexed "within code", but the
design of RSF is intended to make it transparent whether they are or
not. That is, they could be dispatched to other webapps within the
application or even within other servers. In other designs, the
things most nearly corresponding to these have been called "portlets".
Portlets however have typically suffered from a unidirectional
relationship between consumers and producers - one is very clearly
either a "portal" or a "portlet" in this world, and very rarely do
these roles overlap.

We had lots of names for these things, most of which are too whimsical
to repeat :P

Anyway, in all this verbiage, I really *am* trying to get at a thing
which means something to users. One of the biggest deficiencies in
Sakai's (and I think in most webapp design) UI is the problem of
*locality*. Too often one has to navigate in some strange way to
get from one UI "unit" to another, and the essential fault (as well
as the underlying error of design) is that the underlying technology
doesn't make it idiomatic or easy for developers to "reaggregate"
parts of their application so that they can be folded "on demand"
into parts of views where they will be most convenient to users.

So, jointly between RSF and the "Entity Broker" we are committing
to Sakai trunk, we imagine to support these "addressible units"
which are most conveniently represented in current technology as
dynamically dispatchable portlets - each one with a path, representing
its "view state" or ViewParameters. Dynamic, because the mapping
onto what is dispatchable is not defined in a crummy XML file
providing a single flat level of addressing, but allowing
"application units" to come and go, as well as setting up and
tearing down their navigation paths programmatically.

We don't have any of these things yet, but there are a sample of
places in Sakai at least where such things would go
i) The preferences system is currently "hard-baked", and has a hard
dependency on each application which exports preferences. As a result
there are really only about 4 apps which have bothered to do this
since each further one creates a dependency risk and involves
committing to core code.

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!

iii) "Resources" has to be the central target. The best we have been
able to do so far in "reaggregating" is the system of "helpers",
whereby one tool briefly takes completely control of the render pane,
until such time it decides it has finished at which point it
dispatches back. These things are generally so arcane and nonstandard
that again few people have managed to create any unless impelled by
really strong "pain points" of design. Each one in general uses its
own URL mapping and back-dispatching strategy... there are so many
powerful use cases for "includable" units of resource choosing, resource
presenting, resource manipulating applications within Sakai that I
don't think we have even drawn the wide parameters of them yet.

I won't go on any futher... I'm we will sure expand on these areas
enormously at the summit. The names? We have successively had
"Oblets" - Widely unpopular as smacking of Heliocentrism
"The Global Pan-Handler" - Silly... "pan-handled units".
Everything else is just vague... "view units", the standard locution
"reusable units of UI estate", "application modules", "dispatchable
units", "entity views", "entity worlds", etc. etc.

In any case, I have a strong feeling we agree in our goals even
if we don't really have names for them yet :)

Look forward to talking about this more next week,
Cheers,
Antranig.



Quoting Paul Zablosky <Paul.Zablosky at ubc.ca>:

> The intent of this message is to bring to a wider audience a discussion
> that started in this morning's UX Breeze meeting.
>
> One of the things we will be doing at the Summit later this month is
> defining, discussing, and prioritizing component proposals.  Daphne is
> developing exercises and activities
>
<http://wiki.fluidproject.org/display/fluid/Component+Identification+and+Prioritization+Exercise>
> to this end.  We are also going through cognitive walkthroughs,
> heuristic inspections, and accessibility assessments with the idea of
> identifying component solutions to common pain points.  We have a list
> of proposed components
> <http://wiki.fluidproject.org/display/fluid/Component+Suggestions>, and
> our reporting template includes a column for "Identified Component".  We
> have begun categorizing components and adding descriptions.
>
> As we discussed all of this, two things became clear:
>
>    1. The pain point, or user-centric problem statement is something
>       that deserves more discussion.
>    2. The name "component" may not be appropriately descriptive of all
>       possible solution options.
>
> To clarify our understanding we came up with some alternatives to
> /component/, the best of which was /"User-centric Reusable Solution"/.
> This is not a term we would want to promulgate, but it is avoids the
> "software plug-in" notions that seem to cling to "component".  At the
> same time we recognized the need to shift our focus a bit to pain points
> or "user problematics".   What we plan to do is start a list of
> Identified Pain Points
> <http://wiki.fluidproject.org/display/fluid/Identified+Pain+Points> to
> collect those that might have potential for a reusable solution.
>
> Just what a "Fluid Project Solution" is will continue to evolve and
> become increasingly reified as solutions are created over time. Right
> now the most concrete example we have is the Component Library
> <http://wiki.fluidproject.org/display/fluid/Components>.   But we are
> inevitably going to identify problems to which there is no obvious
> component-library-member solution, and we want to capture and analyze
> them. What we lack is terminology for a problem solution that we can't
> imagine fitting into the library.
>
> So here are the questions:  Do we need another term that embraces both
> "component as a member of the component library"  and "other solutions
> to user problematics" and can we propose something that is meaningful
> and useful?  Should we broaden the meaning of component to address a
> wider range of solutions than it is now perceived to cover?
>
>
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the fluid-work mailing list