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

Sean Keesler smkeesle at
Wed Sep 19 14:46:45 UTC 2007

Regarding your comment (if I understand it right) that folks doing
walkthroughs probably should not try to ³design a solution² (because they
might come up with something unimplementable):

While doing my UI review of the OSP matrix tool

(for example:

I tried to be careful to make justified statements about what problems
existed in the tool UI and to offer some possible recommendations for
improvement, much like Paul did for the ³tabs problem² below.

However, Paul  and I did plunge into the solution space. He made 2
recommendations for solutions. I also tried to offer multiple
recommendations in order to try to spark discussion around the problem by
functional experts and support staff that actually understand how the system
will be used. I¹m fairly confident that I¹m not WAY off the deep end and
suggesting the impossible.

I personally would not want to do reviews that amounted to pile of Œgripes¹
or identified problems. I feel that you need to be able to make some
justified recommendations if you want to complain. That implies putting your
toe in the solution space. It also implies some level of knowledge about
what might be reasonable.

A discussion before developers get involved to really lay down requirements
INDEPENDENT of developer input is an important step. After the functional/UX
group understands what they really want, then they should be able to engage
developers more thoughtfully.

I tend to think that the technical folks have a tendency to want to drive
the boat, rather than take us where we want to be sometimes.

My 2 cents...

Sean Keesler
The Living SchoolBook
030 Huntington Hall
Syracuse University

On 9/18/07 7:34 PM, "Paul Zablosky" <Paul.Zablosky at> 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:
> 1. Create a component that allows the user to select two tabs at once.
> 2.  
> 3. 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
>>> <
>>> oritization+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
>>> <>, 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
> _______________________________________________
> fluid-work mailing list
> fluid-work at

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

More information about the fluid-work mailing list