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

Paul Zablosky Paul.Zablosky at
Tue Sep 18 23:34:55 UTC 2007

It's not always obvious that there is a code-implementable solution to a 
pain point at the time of pain point identification.  People performing 
walkthroughs may be superb at identifying problems, but not have the 
background or experience to design software-implementable solutions.  
Also, it's not clear that the "design a solution" stance is the 
appropriate mindset for teasing out the user problematics.  So there 
needs to be a process for identifying, recording, and describing 
problems without plunging into the solution space. 

Having some latency between identifying a problem and specifying its 
solution should be a good thing in the long run.  If we can show 
commonality between the pain-inducers, we have a good chance of finding 
a reusable solution.  Also, it gives us the opportunity to consider a 
variety of solutions from different designers.

Getting back to Mark's question, I think that there are all sorts of 
"user problematics" with solutions that don't reside in a library.  
These include all the do's and don'ts of  good design practices: 
solutions that don't involve reusable code.   One was mentioned 
yesterday in this list.  If content elements that the user needs to see 
at the same time are positioned behind different tabs, there are two 
obvious solutions:

   1. Create a component that allows the user to select two tabs at once.
   2. Don't organize content in this way: i.e. if the user needs to view
      content elements together, don' t position them behind separate tabs.

This is a bit contrived, of course -- I'm pretty sure that we wouldn't 
attempt solution 1.   And I'm also pretty sure that most of the 
solutions we come up with will involve reusable componentry.   But 
sometimes the solutions will lie elsewhere, and we should be open to 
this in our processes.

Mark Norton wrote:
> 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 
>> <> 
>> 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 
>> <>, 
>> 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 
>> <> 
>> 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 
>> <>.   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
>> ------------------------------------------------------------------------
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the fluid-work mailing list