Humanist Discussion Group, Vol. 13, No. 439.
Centre for Computing in the Humanities, King's College London
<http://www.princeton.edu/~mccarty/humanist/>
<http://www.kcl.ac.uk/humanities/cch/humanist/>
Date: Fri, 25 Feb 2000 06:34:36 +0000
From: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
Subject: Re: 13.0423 what we need: a provocation
At 08:17 00/02/21 +0000, you wrote:
>Here is the lash:
>
> >The perceived lack of adequate software has provoked several mostly
> >amateurish attempts to draw up a list of what is needed so that some
> >efforts at development could begin. Apart from lack of time and money,
> >these attempts have been flawed by seriously underestimating even the
> >sociologically ordinary difficulties in extracting ideas reliably from
> >actual practice. More specifically, they have not been framed to separate
> >the operations of scholarly research from habits formed by existing
> >software and so have boxed in the imaginations of those questioned by the
> >limitations of the tools we need to outgrow.
>
>Comments?
The bad news is that getting input from users on new features for software
is notoriously hard work. Eliciting, from users, a description of a new
kind of software is even less likely to succeed easily. So I don't have
much hope of survey-driven software development -- even if we get surveys
designed and performed with more sociological acumen than those of which
the lash-wielder complains. I am more sanguine about the prospects of
success if people who know they want a particular kind of software build
it, and show it to other people to see if they like it. The results will
have no statistical validity or significance at all. But they may include
some useful software.
If one has a small group of users willing to work collaboratively, some
of the cost of developing duds and throwing them away can be eliminated:
instead of developing the software, you develop a non-functional mockup
and show that to the prospective users. Using this method, you don't develop
working software and then find that your user does not want it; instead,
you develop a fully worked out mockup of the user interface, and then
find out that your user has not got a clue what good this is going to do
her. A few rounds of trial and error and 'Well, then, uh, what DO you
want to see on the entry screen?' interviews later, you may have a mockup
that looks like software those users think they might like to use. (That's
not the same as software they will like to use, or will use, but it's
better than a poke in the eye with a sharp stick.) I do not know how to
scale this approach up to handle more than one or two or three users; it
will never look as persuasive as survey results. But it has a better chance
of producing useful software.
Notice that I am proposing something even more amateurish, in some ways,
than the amateurish surveys which serve as your unnamed interlocutor's
whipping boys: namely, individuals and small groups just building what they
think will be worth building, on spec. This is even less likely to
avoid boxing in our imaginations -- except that when we build new tools,
we sometimes find out later what they are good for. And when we build new
tools for *ourselves*, we build tools that at least one user wants.
The lowest-hanging fruit in the area of software development are people
who want to get some job done, not people who are pretty happy with what
they have now, but would like life to be better. "Make it possible for
me to edit English, Hebrew, and Arabic on the screen, so I can work on my
edition of the Cairo Geniza" is a good starting point for collaboration
between technical people and humanists. "Let's develop some software so
we can persuade the foreign-language teachers to use computers in their
instruction" is a lot less promising a starting point.
The reason is not solely that a tightly-focused felt need is more likely
to be readily translatable into a good description of requirements, and
then a good design, than a vague desire for "better software." It is
not solely that when needs are clearly articulated we have a better chance
of determining whether some software meets them or not. It is that software
which solves real problems for people will be used -- and thus has a
chance of being used in new ways, and revealing new needs -- than software
which no one feels a real need for.
So if we have to have surveys of what users want or need, ask them this
question: what do you want to do that you cannot do now?
But if surveys are good, prototypes are better. Show me a prototype of
a tool, and we will have a lot more interesting things to talk about than
surveys and survey results.
-C. M. Sperberg-McQueen
-- **************************************************** * C. M. Sperberg-McQueen * * Research Staff, World Wide Web Consortium * * Route 1, Box 380A, Española NM 87532-9765 * * (that's Espanola with an n-tilde) * * cmsmcq@acm.org, fax: +1 (505) 747-1424 * ****************************************************
This archive was generated by hypermail 2b29 : Fri Feb 25 2000 - 06:47:42 CUT