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

[Paul Zablosky]

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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20070914/a217982e/attachment.html>