Thu, Mar 24, 2005
More Usability Sprint Fallout
#
More fallout from the FLOSS Usability
Sprint. A number of participants, spearheaded by JoelAufrecht, have
launched the Open Web GUI
project. The idea is simple: Create highly usable web pages for common
administrative CMS tasks and distribute them under an OpenSource
license. The motivation is simple. The administrative function of
most OpenSource CMSes are largely the same. One way they could help
each other is to collaborate on developing a highly usable UI
(including menu layout, workflow, etc.) for common tasks that any
project can use. They're looking for visual designers and usability
folks to help out; check out the web site for more information. (IG9)
I spoke at BayCHI on March
8. We had a
great turnout, including many of the participants from the sprint.
It was great to see those familiar faces. (Has it really been only a
month?) RichardAnderson
blogged about my talk and contributed some anecdotes of his own.
TonyChang also blogged the
talk, and reiterated a problem that RashmiSinha had made: (IGA)
What are the incentives for usability analysts to help open source
projects? Eugene mentioned having public work that one can cite in a
resume, but there must be more than that... (IGB)
Marketing isn't the only incentive. There are folks who pay for
OpenSource work, but most of these folks aren't hiring usability
practitioners. One reason for doing this sprint was to make these
people realize that they should. The money is there; it's a matter of
making the case that the money would be well spent by investing it in
usability. (IGC)
Finally, MaryHodder has been taking the notion of ExtremeUsability,
which emerged from the sprint, and has been
running like
crazy with it. Her anecdotes are great, and I have a feeling that
where she's taking the notion will be even better. (IGD)
/blueoxen |
Posted at 4:07pm
Kwiki::Purple, Wiki Deep Thoughts
#
My ex-partner-in-crime, ChrisDent, has been busy coding and
expounding. Last month, he
released Kwiki::Purple, a
PurpleNumbers plugin for Kwiki. You can play with it on his
test site. (IFZ)
This is fantastic news on a number of fronts. First, it's further
validation of our strategy to have the ideas take over the world,
not the code. As I've said from the beginning, the purpose of
PurpleWiki is to be a vehicle for ideas. Our goal was not for
PurpleWiki to become the Wiki, but for other Wikis to steal our
best ideas. There are now three Wikis with PurpleNumbers --
Kwiki, Zwiki, and
PurpleWiki -- with hopefully more to come. (IG0)
Second, the fact that Chris was able to implement this as a Kwiki
plugin makes Kwiki a more viable option for BlueOxenAssociates as its
Wiki platform of the future. This is a good thing for many reasons. (IG1)
Chris has also been doing some expounding on Wikis. His entry,
"Why
Wiki?", is old hat for folks who know Chris, but it's a nice, clean
summary of his views for those who don't. His framing of
augmentation versus automation (discussed in much more detail
in his paper,
"The
Computer As Tool: From Interaction to Augmentation") is powerful, and
I've borrowed it in my own thinking and writing. I also liked
this line: (IG2)
Architecting these sorts of tools may not solve poverty and hunger,
or alleviate suffering in the aftermath of a
disaster, but the
tools can augment people actively doing that work. I happen to be good
at making the tools go, so that's where I look to fit myself into the
puzzle. (IG3)
Chris's thoughts on Wikis as an
external
cache is another good piece. Two quick comments. First, viewing
Wikis as an external cache reveals an important constraint. They are
most valuable to folks who are already immersed in a conversation,
because those folks already have some context that aids them in
exploring the Wiki. For example, Wikis used for self-documenting
events are not so good at involving those who did not participate, but
they are extremely valuable for those who did. At the same time, they
are better than nothing. If someone is motivated enough, they can use
Wikis as a springboard for acquiring the context they need, and thus
gain value that way. ThinkOutLoud is good. (IG4)
Second, Chris
writes: (IG5)
I've found that in order for outboard processing to work there's
several design and process guidelines that have to be reached. Here
are some: interaction must be highly responsive, noise in the
interface must be minimized, structural mechanics and metaphors in
content need to be consisent, names must have value, it must be there
when you want it, when there is a shared brain its context is shared
as well (e.g when some members of the company have a discussion about
design it it is done in an archivable fashion). (IG6)
(Emphasis is mine.) It's ironic that Chris cites highly responsive
interaction as a requirement for collaboration on an asynchronous
medium to work. I agree that this is an important pattern of
effective collaboration, but I wouldn't go so far as to say it's a
requirement. There is an alternative mode, one that emphasizes deep
thinking augmented by infrequent, but deep interactions. A big void
in the collaborative space are tools that augment this mode of
interaction. See my design notes on Abelard for an example of
what such a tool might look like. (IG7)
/collaboration/tools |
Posted at 3:18pm
Peter Jones Blogs
#
Catching up on some much overdue blogging. Wanted to welcome
PeterJones to the blogosphere. Peter
has been an active member of the BlueOxen CollaborationCollaboratory
from the start, and I've been encouraging him to blog for about as
long. His blog, (:techanarti),
covers tech and politics. (IFY)
/personal |
Posted at 2:45pm
