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

usage-centered design of batch processes?

Expand Messages
  • Stanley Sutton
    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
    Message 1 of 2 , Apr 27, 2002
    • 0 Attachment
      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 understand.

      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 process?

    • Larry Constantine
      Stanley, 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
      Message 2 of 2 , May 8 9:18 AM
      • 0 Attachment
        Stanley,

        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
        crazy.

        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
        (http://foruse.com/articles/euc-responsibility.htm).

        Regards,

        --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-----
        From:
        sentto-1175705-106-1019926079-lConstantine=compuserve.com@...
        oo.com
        [mailto:sentto-1175705-106-1019926079-lConstantine=compuserve.com@...
        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
        understand.

        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
        process?



        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      Your message has been successfully submitted and would be delivered to recipients shortly.