Re: Usability and Semiotics
David Dirlam (ddirlam who-is-at weber.ucsd.edu)
Thu, 6 Nov 1997 10:12:26 -0800 (PST)
On Thu, 6 Nov 1997, Louise Yarnall wrote:
>
> To me, the issue of teacher assessment in relation to how to use these
> multimedia tools for learning is pretty pivotal. Teacher assessment exerts
> social pressure on the kids that is at least as powerful as the actual
> programmed structures of the software. (ZPD) The larger point I'm getting at
> here is that, nothing in any design seems etched in stone (or silicon, for
> that matter). The users (their context and their activity) negotiate the
> ultimate workable design of any cultural artifact. The goal of usability
> research, as far as I can understand it, is to keep chasing this butterfly,
> trying to get at the problems that emerge in practice and come up with
> adequate responses...
>
As somebody who spent seven years custom designing data processing
systems for small businesses and organizations, I found Louise's
description of the design process more realistic than Jay's. But I think
it would be useful to distinguish between custom design and standard
designs made for large, diverse groups of users. Standard designs are
obviously where the money is -- the design costs are recovered and the
product can be sold at ever more efficient prices. Consequently, I
started out with standard designs in the early 1980s, but in all of San
Diego, I couldn't find a business or organization that fit one. The choice
was to frustrate the user or to customize the product. In the latter case,
it became incompatible with new changes in the standard product. As long
as I was around to adapt the system to new business or organizational
needs or could teach somebody in the business or organization to do the
adaptation, the custom settings were much happier. But this made the group
more dependent on me or their member, who could do the adapting. This is
not a social power issue so much as it is an issue of how to get a job
done given the constraints of the people and tools available to do it.
These issues have driven standard software developers to create
ever richer applications (e.g. word processors and spread sheets that take
take as much space as it took to run a manufacturer with a hundred
employees ten years ago). Now, we do get a power issue. To maintain these
enormously complex programs becomes a task not for one person but for
armies of them. I worked with a system that I could customize very quickly
and that ran faster than most accounting programs run today, even though
the machines were 50 to 100 times slower. It was entirely created by three
assembly-language programmers. If there was a flaw in the programming
language that I was using, I could call the designers, tell them, and they
would fix it. At the same time ATT put 1,000 programmers on the
development of unix and today IBM (not Sun, but IBM) has 20,000
programmers working on Java. If Microsoft forgets and leaves out a command
from a new release of Windows CE, can a solitary ant get attention from an
elephant?
So now we are back to Jay's "trust" problem. Does the elephant
"trust" the ant. If the ant tickles or bites, it is likely to get
displaced somewhere where it can't tickle or bite any more. So far from
control, elephantine corporations dealing with programs or products so
complex it takes thousands of "designers" to maintain them become very
wary of change. It costs too much. Designers in them are bound to ask,
what can we do besides change? Its the answers to that question that end
up frustrating us(ers).
Rather than asking, who has power and who trusts who, it is
probably better to asks what are the various ways that people can adapt
to the situation, what are the resources, how much do they cost, and what
happens to these questions when an activity is "scaled up"?
David