[Dev] Fwd: Processing Dogfood Feedback

[Sheila Mooney]

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.

Thanks,
Sheila

Begin forwarded message:

> From: Mimi Yin <mimi at osafoundation.org>
> Date: November 8, 2005 11:48:38 AM PST (CA)
> To: Chandler Design list <design at osafoundation.org>, OSAF  
> Development <dev at osafoundation.org>
> Cc: Lisa Dusseault <lisa at osafoundation.org>, Sheila Mooney  
> <sheila at osafoundation.org>, Katie Capps Parlante  
> <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 submission  
> process.
>
> Given that code freeze for 0.6 is nigh and available resources are  
> as always scarce...here are some guidelines for submitting feedback.
>
> 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 design process.
>
> 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  
> first. http://www.geocities.com/SoHo/Nook/2990/cb_rules.htm
>
> 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  
> usability.
>
> 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!
>
> Mimi
>
> * 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.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20051109/a880682b/attachment.html