Browse Prior Art Database

User Interface for the Progress of an Asynchronous Task

IP.com Disclosure Number: IPCOM000122021D
Original Publication Date: 1991-Oct-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 75K

Publishing Venue

IBM

Related People

Griffin, DL: AUTHOR [+2]

Abstract

With the advent of SAA*, client-server computing is becoming the de facto standard. Client-server computing, illustrated by applications such as OfficeVision*/2, has clients (end user interface (EUI) plus requester) connecting to servers to get and/or put data. Ideally, the movement of data would be asynchronous. Unfortunately, applications like OfficeVision/2 appear synchronous as the application is locked (modal) until the update occurs. And the longer the distance (e.g., hops between nodes) between the client and the server, the longer the user waits on the request to complete. This makes the applications appear unresponsive. This perception is unacceptable.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

User Interface for the Progress of an Asynchronous Task

      With the advent of SAA*, client-server computing is
becoming the de facto standard.  Client-server computing, illustrated
by applications such as OfficeVision*/2, has clients (end user
interface (EUI) plus requester) connecting to servers to get and/or
put data.  Ideally, the movement of data would be asynchronous.
Unfortunately, applications like OfficeVision/2 appear synchronous as
the application is locked (modal) until the update occurs.  And the
longer the distance (e.g., hops between nodes) between the client and
the server, the longer the user waits on the request to complete.
This makes the applications appear unresponsive. This perception is
unacceptable.

      How should the true asynchronous nature of data movement be
communicated to the end user, i.e., how does the application
communicate to the user the status of his/her request?

      Consider an electronic calendar application that allows users
to add, change or delete data (calendar events).  The application's
EUI runs under some window manager on a workstation while the
application's data (host or server) runs on some other machine.  As a
user changes the calendar data, the EUI acknowledges the request and
allows the user to continue working while the request is transmitted
to the other computer that is providing the server function.

      How does the application "acknowledge the request"? The request
is recorded in its local copy of the data, presented by the EUI, and
forwarded to the server to be committed.  The end user is notified of
the request's status from formulation to finish.

      How does the application "notify the user of the request's
status"? The following types of status can be reported:
O  Request complete
   The request has returned from the server successfully.
O  Request failed
   The request fa...