[Dev] Re: [Design] Fwd: Processing Dogfood Feedback
mimi at osafoundation.org
Wed Nov 9 20:50:16 PST 2005
+1 for lots of quick iterations.
At 8:22 PM -0800 11/9/05, Philippe Bossut wrote:
>I think the process (as in set of steps) is workable. I'd advocate
>though to have a short feedback loop between steps 2 and 3, i.e.
>mock up or prototype 5 ideas or more and iterate through the
>My experience is that it's very useful to show lots of design and
>variation rather than few so that people can break the design apart
>and articulate what they like better. Having to choose up front
>between 2-3 designs, people tend to compromise on stuff, sometimes
>just to get their pet ideas in. At that stage of the process though
>(stage 2), I think we should still be open to discuss everything in
>One day, I created 10 variations of a main screenshot for an imaging
>app (which didn't see the light of day but that's another story...),
>did color prints and pin them in the hallway, asking people to vote
>and otherwise interviewing them whenever someone would come by. It
>was incredibly efficient.
>Sheila Mooney wrote:
>>Due to the high volume of traffic on the design list lately it's
>>likely that not everyone has seen this or had a chance to read it
>>yet (with all the bug fixing going on etc). We haven't received
>>many comments so far and we wouldn't mind getting some feedback
>>from the developers on this process.....when you have a chance to
>>since I know you are all busy.
>>Begin forwarded message:
>>>*From: *Mimi Yin <mimi at osafoundation.org <mailto:mimi at osafoundation.org>>
>>>*Date: *November 8, 2005 11:48:38 AM PST (CA)
>>>*To: *Chandler Design list <design at osafoundation.org
>>><mailto:design at osafoundation.org>>, OSAF Development
>>><dev at osafoundation.org <mailto:dev at osafoundation.org>>
>>>*Cc: *Lisa Dusseault <lisa at osafoundation.org
>>><mailto:lisa at osafoundation.org>>, Sheila Mooney
>>><sheila at osafoundation.org <mailto:sheila at osafoundation.org>>,
>>>Katie Capps Parlante <capps at osafoundation.org
>>><mailto:capps at osafoundation.org>>
>>>*Subject: **Processing Dogfood Feedback*
>>>Pre-0.6 Dogfooding has uncovered some important design issues
>>>which has in turn prompted quick responses that will make it into
>>>the 0.6 release. All in all, it has been a successful experience
>>>and a great opportunity for us to figure out how to deal with
>>>Dogfooding feedback once 0.6 is released for real. This in turn
>>>has prompted further discussion about refinements to the feedback
>>>Given that code freeze for 0.6 is nigh and available resources are
>>>as always scarce...here are some guidelines for submitting
>>>1. Is this something that prevents you from Dogfooding Chandler
>>>calendar in 0.6? (Helps us prioritize.)
>>>2. Is it an "I can't understand this!" issue OR "I can't figure
>>>out how to do this!" issue OR "This is really annoying!" issue.
>>>3. Lastly, some ideas for possible solutions.
>>>Suggestions for solutions are more than welcome, however, it is
>>>important for the group to have a shared understanding of the root
>>>of the usability problem (which is why I have put it as a #3).
>>>Some solutions are not available to us either because they are too
>>>expensive to implement in the short-term or destabilize other
>>>areas of the design. If we can all come to an understanding about
>>>the problem we need to solve, we'll be much better equipped as a
>>>group to brainstorm solutions that work within the context of the
>>>both design and development realities.
>>>Hopefully most feedback will be fairly straightforward, but once
>>>in a while, design issues will arise that require further
>>>exploration. We would like to experiment with more collaborative
>>>approaches to dealing with such design issues. Our branding effort
>>>for 0.6 was one early foray into distributed, collaborative design
>>>and we're looking to incorporate this approach into our core
>>>This is not something any of us have done before (if anyone has
>>>done this, please speak up share your experiences!), so apologies
>>>in advance for changing the rules mid-stream or making up new ones
>>>as we go along. This is going to feel a little like Calvin-ball at
>>>Here's a strawperson proposal:
>>>1. Brainstorm of ideas for solutions. At this stage, we will try
>>>very hard to avoid evaluating solutions for feasibility or even
>>>2. Once a critical mass of ideas have been submitted*, we will go
>>>through a process of whittling it down to a set of 2-3 options.**
>>>The whittling down process consists primarily of:
>>>a. Evaluating how well the proposed solution fits into the
>>>existing design framework AND/OR
>>>b. Considering whether the fix is important enough to merit
>>>re-examining larger design issues.
>>>c. Evaluating the feasibility of the proposed solution and
>>>estimating how much time and resources it will take to implement
>>> 3. Mock ups or prototypes of ideas.
>>>4. Informal usability testing as appropriate to the design issue at hand.
>>>5. Presentation and analysis of results.
>>>Steps 1-5 could all happen within a single day or over a period of
>>>a few weeks. It could happen several times over the course of a
>>>week or a month. It all depends on the scope of the design issue
>>>how ornery the problem is.
>>>Feedback and comments welcome!
>>>* Brainstorming never ends per se, but at some point, we will need
>>>to open up the discussion to evaluation and prioritization.
>>>** Step 2 will be the hardest to do well and potentially full of
>>>pitfalls. We're doing a lot of hand-waving about it right now.
>>>We'd like to see how things work themselves out naturally and
>>>impose structure only on an as-needed basis.
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>Open Source Applications Foundation "Design" mailing list
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>Open Source Applications Foundation "Design" mailing list
More information about the Dev