13.0439 how to get what we need: build it

From: Humanist Discussion Group (willard@lists.village.virginia.edu)
Date: Fri Feb 25 2000 - 06:42:33 CUT

  • Next message: Humanist Discussion Group: "13.0440 new on WWW: law; resources report; good imaging practices"

                   Humanist Discussion Group, Vol. 13, No. 439.
           Centre for Computing in the Humanities, King's College London

             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.

    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&ntilde;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