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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
