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

Daphne Ogle daphne at
Wed Sep 19 03:18:12 UTC 2007

I think we are talking about a couple of ideas here:

1) The concept we have in mind when we use the term "component".
As we've progressed through the walkthroughs, and discussed pain  
points and components, it's been clear that component has a specific  
meaning in many people's minds.  During the call we decided this  
tends to be a low level of granularity, perhaps widget,  than how we  
want to think about Fluid components.  A Fluid component/reusable  
solution could be an entire workflow like a wizard or perhaps an  
entire tool, say a Dashboard and also widgets.    So the question is,  
do we need terminology (and is there any) that better represents the  
concept of how we are thinking about components/reusable solutions  
that doesn't bring baggage with it?

2) Thinking solutions too early was constraining our thinking
Again, while doing the walkthroughs what we were finding by trying to  
label pain points with a component solution this early is that it was  
constraining our thinking a bit to the widget level since they tend  
to be easier to see while your in the details and are more common. So  
for the component ID and prioritization activity at the summit, we  
decided we want to talk about pain points and user activities rather  
than arrive with a solution in mind.  We also want to include context  
in our discussion, so rather than saying we need an organizer  
component, we want to talk about the bigger picture:  we need a way  
to organize thumbnail images and a way to organize files and also  
need a way to organize tools in a site or portlets in a portal.  Then  
we can figure out what part of these are common across all  
applications, specific to Sakai but across it's tools, or perhaps  
specific to Sakai, a tool and a site type.  We can build components  
at the right level and for the right goals.


On Sep 18, 2007, at 4:34 PM, Paul Zablosky wrote:

> 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:
> Create a component that allows the user to select two tabs at once.
> 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 <http:// 
>>> +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  
>>> < 
>>> +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:// 
>>>> 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 < 
>>> 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
>>> -------------------------------------------------------------------- 
>>> ----
>>> 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
> _______________________________________________
> fluid-work mailing list
> fluid-work at

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at
cell (510)847-0308

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

More information about the fluid-work mailing list