Common User Access and the worrying compromises that are beginning to surface some 20 of the IBM System Journal pages are dedicated to scrutinising the consistent and usable human computer interface for the Systems Application Architecture environments, better known as the Common User Access. To date, the component takes the shape of a publication, which lists a number of design rules and guidelines, and is firmly targeted at application designers, managers and interface planners. In time, promises IBM, the user-interface specifications will be swept off the page and made available, via toolkits: the Common User Access has already served as a specification basis for the OS/2 1.1 Programmer’s Toolkit, Presentation and Dialog Managers. Meanwhile, trapped in the realms of the abstract, Richard E Berry is forced to reiterate a familiar string of benefits – decreased learning time, improved productivity, and increased user satisfaction – and examine the intentions behind the specification criteria. The Common User Access, argues Berry somewhat piously, is not a substitute for conscientious design to achieve usability, or an attempt to stifle creativity. Instead, the goal of the specifications should be seen as cross system consistency, achieved through the prescription of identical appearances and interaction techniques within the four SAA-stipulated operating environments – MVS, VM, OS/400 and OS/2 for those who have forgotten – and of course the whole thing remains such a moving target that DOS/VSE is halfway in there as well – and specified adaptations where and when environments differ. The overall benefit, he concludes, is the transfer and preservation of users’ learning at both conceptual and implementation levels. In other words, all those expensively trained but scarcely motivated policy entry clerks down at the insurance office, who spend their days cooped up like battery hens in front of a 3270 screen endlessly keying in details of policies sold by the travellers on the road, will not be flummoxed when the company decides to switch from 3270s to PS/2s under OS/2, but will take to the new machines like battery ducks to distilled water with the minimum of retraining – that’s the theory and the point anyway.
Common User Access design principles
Common User Access design principles are divided accordingly: general ones, culled from a selection too numerous to list, and ones unique to the SAA environments. In the former category comes the suggestion that users’ actions should be reversible; that context – panel titles and scrolling location – should be provided; that the interface should be highly visual to ensure minimal reliance on the user’s memory – and attention span, no doubt; that feedback should be provided for almost every user interaction, and that potentially destructive actions should require confirmation (yes indeed: funny how we still seem to have a PC-DOS machine around here that happily reformats the hard disk if you key format at the prompt and drop a book on the keyboard before you key in a:, it happily starts reformatting the hard disk. CP/M doesn’t do things like that…)Unique principles include the concurrent provision of mouse and keyboard support; the support of graphical representations when graphical capabilities are available; efficient keyboard interfacing for most common office applications, and ensuring that programmable workstation capabilities are taken advantage of where possible. Expanding on the latter point, however, appears to muddy cross consistency waters. Avoiding what Berry sees as the inherent danger of plumping for lowest – common – denominator – type solutions has clearly necessitated elevating the programmable workstation to the rank of design front-runner, with non-programmable terminals adapting to keep up (sorry if you just spent a fortune on a whole bunch of 3270s). Choosing options on a PS/2 or programmable workstation, for example, means selecting from a list of numbered choices by keying in the number; on non programmable terminals, users enter the n
umber via a typing cursor, placed at an entry space near the choices list. Setting what could be seen as a worryingly heretical precedent, Berry concludes that in this case, the advantages provided by immediate keystroke and recognition and feedback were deemed more important than consistency.
Windows an assumed Access environment
Back on safer ground, Berry zones in on a distinct set of prescribed, common interface topics. First comes windows, an assumed environment for the Common User Access model, thanks to its development in conjunction with the OS/2 Presentation Manager. As far as panel design is concerned, the interface specifies three distinct areas: an action bar to display choices, a panel body to display information, and a short or long form function key, providing a touch area for mouse users, and a visual reminder for key assignments. Prescribed panel types fall into menu, entry and list categories, with the rider that only application-specific panels need differ from one application to the next. Selection and entry fields
Under the heading selection and entry fields, Berry cites a point-and-select interface to single-choice, multiple-choice and extended-choice selection fields. For moving between fields in a panel, the use of arrow, tab and backtab keys is specified. For dialogue control actions, the Common Access interface claims to favour those which place the user in control – Refresh, for reversing changes on the panel, and Cancel for taking the user one step back. Meanwhile, dialogues with pop-up window must be completed before any dialogue with an underlying window is resumed. Two user aids are provided: non-intimidating and prompting messages, and an on-line, contextual help facility. On terminology Berry unsurprisingly suggests that, once a term has been chosen for a particular concept, it should be used throughout the design to convey the same meaning. Final words are saved for implementation: application developers are advised to become familiar with the spirit and intent of the interface, and implement as much of it as is possible, using current development tools. By now it should be clear that the primary mode of access to a Systems Application Architecture program is a Personal System/2 under OS/2, and it’s bye-bye 3270s, but then we all saw that creeping up on us a while ago, didn’t we? Application Architecture appeared in CI No 1,049.
Content from our partners
