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

Daphne Ogle daphne at media.berkeley.edu
Wed Sep 19 18:51:32 UTC 2007


Hi Sean, et all,

Comments below...

-Daphne


On Sep 19, 2007, at 7:46 AM, Sean Keesler wrote:

> 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: http://confluence.sakaiproject.org/confluence/x/mLg)
>
> 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.
I think there's been a bit of a misunderstanding here.  The end goal  
of the UX Walkthroughs is to create solutions...absolutely!  The  
discussion we had on Friday was about the timing of the solution  
discussion.  Getting into solutions too early...before we really  
understand the problem can put unneeded constraints on our thinking  
early on.
>
> 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.
This is a good point.  It seems quite natural for technologists to  
want to start thinking about the technical solution immediately --  
makes sense since that is their problem space.  What would be great  
to see here is that collaborative conversations happen early but are  
focused on the problems, goals, needs.  I like to design the scenario  
of use in text without any implementation details as a first step and  
only after understanding the activity and information a user needs  
start designing the specific solution.  Once we understand what the  
user is trying to do then we can start talking about trade-offs for  
various implementations while trying to achieve the same intent.   
When I've had this kind of collaboration is when the best designs  
have been created.
>
> 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
> 315-443-3450
>
>
> On 9/18/07 7:34 PM, "Paul Zablosky" <Paul.Zablosky at ubc.ca> 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://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
>>>>
>>>
>>
>>
>> _______________________________________________
>> fluid-work mailing list
>> fluid-work at fluidproject.org
>> http://fluidproject.org/mailman/listinfo/fluid-work
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

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



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


More information about the fluid-work mailing list