[Zope-CMF] CMF Usability

Tim Maroney tim@maroney.org
Fri, 12 Jul 2002 10:15:23 -0700


> I will second Alan here;  I value *tangible* feedback enormously, where
> my ranking scale goes something like this:
> 
> - Working patch against current CVS, +10
> - Submitted to the collector, +5
> - clear recipe to reproduce the problem, +5
> - access to a site which demonstrates the problem, +3

That's good for design problems that are self-evident or clear from user
complaints -- for instance, that a permission failure shouldn't redirect to
a login dialog for an already logged in user. Most design issues aren't
quite as clear-cut as most software bugs, though, and trying to work them
out by consensus is often frustrating due to subjectivity and different
value systems. In design the tangible feedback comes down to user testing.
It's the one thing I've seen that can cut across value systems and convince
everyone from management to design to development to quality that an issue
needs to be addressed.

Prototyping is also valuable in that it provides the opportunity for
informal self-user-testing and expert review, but it's much more subjective.
Nothing beats seeing subject after subject fail at the exact same point in
the task that everyone had thought was going to be ever so clear. User test
results are usually very convergent, and they cut through a lot of the
subjective back-and-forth that often stalls design decisions.

So for instance, I'm quite willing to submit CVS patches for the problems
I'm addressing. But if the problem is that the text on a page is verbose and
unhelpful, that's not likely to present a compelling argument to you to
accept it. In fact what it's more likely to do than anything else is touch
off an argument. I may have realized there was a problem because in watching
someone go through my registration process I realized that the text was not
guiding them through the steps, and that they tuned out all of it because
there was too much of it. That's an argument we wouldn't need to have if
we'd both been behind the two-way mirror watching that user stall out.

User testing is not always feasible. I don't know if Zope is one of those
cases, because I'm not familiar with the company as such. It's not very
expensive by software development standards -- you can do a good test in any
major market for under $2,000 outlay, not including payroll of your people
who are involved. Field observation of users is another excellent design
exercise, but it is more likely to require travel. If user testing is not
feasible, then prototyping is a decent fallback. Another possibility is for
designers to create their own skins or branches, based on their own
judgment, and avoid wrangling that way. None of these will result in designs
as good as ones that have been iteratively developed with user testing,
though.

> Note that some things may be "de gustibus non est disputandum", which
> means that they *belong* in skin customizations:  "chaqu'un a son
> gout".

The issue of what belongs in skins or settings, and the potential for
"preferences overload," is one that I'm seeing more people talk about these
days. Personally I think that on a development platform you need many more
settable options than you would need in, say, a desktop application.

> To some extent, this is the genesis of Plone as a separate
> project:  Alan, Sidney, Alex, et al. had a vision for a type of site,
> based on CMF, and implemented it as an add on, rather than lobbying me
> to agree with and check in the hundreds of stylistic / design-level
> choices they made;  I *applaud* this strategy.

Right, and this is basically the tack I'm taking. I don't imagine, though,
that I can do it all myself, or that the scattered and informal testing I'm
able to wheedle out of friends is going to make my independent effort a
really professional-quality one. I'm working it from my end but I'm also
wondering what can be done to create some more pervasive design involvement
and testing in the development of the platform and its products and skins.

To take one example, JavaScript form validation is a clear win from a
usability perspective, but it's not popular with server-side developers. If
it's not taken up by other products, then I'm faced with the impossible task
of adding it to every form in every product I integrate into my site.
Similarly, I could personally simplify the security displays for quite a few
products, but if this has to be done for every new product I integrate,
there's no way I'm going to be able to contain the continuing sprawl.

Traditionally this need for a minimum usability level has been filled by a
set of user interface standards. Adoption of such a set of standards is more
a cultural issue than an issue of one person's hard work.

> I will probably finalize the 1.3 release of the CMF next week;  until
> that point, I consider the software in "feature freeze", and only want
> to be checking in "showstopper" fixes to the 1.3 branch.  After release,
> I would be delighted to entertain the kinds of fixes you describe.

Seems very sensible!

> Perhaps the best strategy would be to get you CVS contributor access,
> and have you work on a "tmaroney-annoyingly_picky-branch" :), where we
> could all try out your changes, and then merge them if we can reach
> consensus.  Interested?

I'm open to the idea and I appreciate your generosity. Skinning is going to
be easier for me at first, though. Once I whack through my current
high-priority bug list I could set up a separate skinned site for evaluation
purposes and you could take a look at my version of how things should work
to judge your interest level for a branch or for direct adoption of
particular changes.

On the other side of the fence, while I'm a good programmer, I'm new to
python and Zope, so I'm finding that for now I need help with some things.
For instance, I'm not getting why my Plone site's createMemberarea routine
installed by assigning to MembershipTool.createMemberarea isn't getting
called a la 
http://www.zope.org/Members/gregweb/cmf_add_objects_at_member_creation, or
how to override CookieCrumbler's unauthorized routine to go to an error page
when the user is already logged in. Is this a good place to ask for help
with things like that?

Anyway, thanks to you and runyaga for these great responses.

--
Tim Maroney    tim@maroney.org