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

[Mark Norton]

Being one of those focused, software developer types, can you give me an 
example of an "other solutions to user problematics"?  I am having 
trouble visualizing a solution that can be used in software development 
that doesn't involve software elements, components, snippets of code, or 
a design pattern that could be translated to code.

- Mark Norton

Paul Zablosky wrote:
> 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?
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>   
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date: 9/17/2007 1:29 PM
>