RE: [usage-centered] usage-centered design of batch processes?
Yes, this is a bit of a slow response, but between the relaunch of
forUse.com (http://foruse.com/) and putting together the program for the
upcoming forUSE 2002 conference (http://foruse.com/2002/), things have been
I once had a guy come up to me after one of my classes in usage-centered
design for embedded systems applications. He asked how the techniques
applied to the world of UPS design in which he worked. I asked him about the
UI of his last project and he said, "Well, there was a power switch an LED,
and an audio alarm. The truth is, some applications--such as your batch
processes--have inherently minimal user interfaces. For these,
usage-centered design itself won't buy you much. That is not to say that
usability issues shouldn't be considered in the design of log-on procedures
or error messages, but the ROI of doing a full-blown user role and task
modeling is likely to be limited.
However, there are those who are convinced that abstract (essential) use
cases are still valuable for driving the object design process. See the
Noble et al. paper on this
Director of Research & Development | Constantine & Lockwood, Ltd.
58 Kathleen Circle | Rowley, MA 01969
t: +1 978 948 5012 | f: +1 978 948 5036 | www.foruse.com
oups.yahoo.com]On Behalf Of Stanley Sutton
Sent: 27 April 2002 12:49 PM
Subject: [usage-centered] usage-centered design of batch processes?
I've just finished my initial reading of _Software_for_Use_, and I have a
question about usage centered design and batch processes. By batch
processes, I mean a process which is intended to run with minimal human
interaction. For example, in an airline revenue accounting system I worked
on, there were a great number of file feeds, which needed to be moved into
the relational database on a regular basis, but we wanted it to be as
automated as possible.
A typical example was getting fare information. About once a day, a
scheduling system started a shell script which would FTP a file from a fare
clearing house. It would validate the files received (by checksum), and
enter the file name into a database table for processing. Later on in the
evening, a progrom would be started that would check the database table for
unprocessed entries. The file would then be processed moving the flat file
into a set of fare tables.
The primary human interaction was with the operators, who would receive
detailed error messages if the process failed at any point. Some where
fairly simple, on the order of "Connection to remote site could not be
established, please check network connectivity by ..."; some printed out
several pages of detailed analysis of possible problems in order of probable
causes. Most of those messages were stored in the database, and regular
reviews modified them to keep them current, with feedback from the operators
on useful they were on resolving problems, or how easy they were to
Finally, each fare was subject to validation. Each transcaction was
validated. Any that failed validation had entries created into an error
work queue. The work queues were processed by a seperate process, which was
interactive, but all the batch job did was add entries to work queue.
The only real role I can see is the operator, and, under most conditions,
there were no interactions with the operator. I can remember at least one
period where the fare loading process ran for 4 months without operator
intervention, which was our main goal for this process.
So how do you tackle this sort of process from a usage centered design
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.