Is "component" a misnomer? Is a higher level term needed?
abloodworth at berkeley.edu
Wed Sep 19 17:52:24 UTC 2007
I don't think we are discouraging folks from suggesting potential
solutions if they are knowledgeable about the problem space; in fact,
we have a place on our Walk-through reporting template for both
"Suggestions for solution" and "Component Identified?" We just don't
want those suggestions to be the main focus of our discussion. I
think our goal in trying to talk about user "pain points" or
"problematics" as opposed to components is two-fold:
1) To make sure we don't lose sight of the user needs which prompted
our component suggestions.
2) To ensure we don't inadvertently limit ourselves to just the
components already suggested.
Looking at all the different needs/pain points the group has come up
as a whole, and discussing them as a group, might point us to
different components than those suggested by individual evaluators to
address (often single) pain points. We also want to keep the
discussion at a high enough level to facilitate looking at connecting
problems/pain points, or even coming up with more innovative, far-
reaching solutions to problems.
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.
> 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 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
>>>> +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
>>>> 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
>>>> +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
>>>> 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
> fluid-work mailing list
> fluid-work at fluidproject.org
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
abloodworth at berkeley.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work