Loading ...
Sorry, an error occurred while loading the content.

151RE: [usage-centered] usage-centered design of batch processes?

Expand Messages
  • Larry Constantine
    May 8, 2002

      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


      --Larry Constantine
      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

      -----Original Message-----
      oups.yahoo.com]On Behalf Of Stanley Sutton
      Sent: 27 April 2002 12:49 PM
      To: usage-centered@yahoogroups.com
      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.
    • Show all 2 messages in this topic