Work on the STATUS project has produced a usability attribute decomposition, setting out various different aspects which help to improve software usability. Here I compare these with the work done by Bass et al at SEI on software architecture and usability (see their paper), and add my own thoughts to try and identify which of the usability attributes may be affected by software architecture.
Enabling users to interact with software using their access method of choice (mouse, keyboard, touch screen, foot pedal... screen, audio...) will increase usability. Users who are physically disabled may not be able to use conventional input devices (mouse/keyboard). They may also not be able to read information on the screen if their sight is impaired, or be able to sense sounds if they are hard of hearing. Allowing the software to work (or be easily adapted to work) with a variety of input and output devices is an architectural issue. It requires separation of the input and output controllers from the data processing component of the software, so that they can easily be switched in and out. If a user has a disability that means that the accuracy of their input is inhibited (for example an arthritic typist) then the system should do its best to compensate for this (auto-correction of common typing errors etc). If an alternative input device is being used, it may be appropriate to change on screen instructions. Things that say "click here" may be inappropriate if using say a voice controller. Actions that can be performed need to be separated from their physical manifestations.
All of the written messages and labels used in a software application need to be able to be tailored to the user's language of choice, in order that the application may be used by as wide a user base as possible. It is important that this is easily extensible, that new languages can be added to the system when needed. Although the text on buttons and in dialogs might seem to be a user interface issue, in order for it to be easily changed and added to, the software architecture needs to be designed in such a way that all text is sourced from a central language module which can be replaced with one for a different language. Different locales may need more than the substitution of different strings. Characters may be read right-to-left or vertically. Icons may be in appropriate and need changing.
A user will be able to learn a system more easily if they feel free to explore and try things out. To aid this, the user should be provided with the ability to undo their actions and to cancel commands so that they can try things out without risking causing irreperable damage to their work or causing the system to go into an unresponsive state. These again are architectural issues, as the system must keep a history of the user's actions and enough information about previous states to be able to restore them. This is not always easy to implement in an efficient manner. While it might be possible to have an architecture where all the events that a user triggers (select a word, underline, etc..) are recorded, it is not always easy to go back. What if the last command was "delete everything", just because you know that that was what the user just did, you can't then restore the previous state. Could a global undo mechanism be implemented that was shared across all applications? How about keeping a full version history of all files in the filesystem? Should it be necessary to give a "save" command to record the current state of an application to disk, or should everything be saved anyway? (compare using a word processor to writing on paper).
It is important to note here that we are considering the efficiency of the user, or the combination of user and machine, not that of the system on its own. Increasing the efficiency of algorithms to improve system performance may in fact be detrimental to usability. Bass et al talk about the importance of working at the user's pace, giving as an example the scrolling routines in Microsoft Word, which on a high specificaton machine scroll the page more quickly than a user can read or control.
However, if the user is having to wait for the machine, then this is not the most efficient operation. If the machine was concious of it's own limitations, it could trade off, say the amount of detail drawn to the screen during processing to speed things up. This might be especially important when the user is manipulating complex graphical objects. A smooth movement will help with positioning, but it is probably not necessary to draw the exact detail of all surfaces until the new position is chosen. However, if the machine has sufficient processing resources free to do the detailed drawing, it should do that. Listening for commands for the user should not take a back seat to drawing the display. An application should not lose key presses just because there was not a currently in focus text window when the key was pressed.
Considering examples of techniques for improving the efficiency with which the user completes tasks using the system, providing the ability to aggregate data (in the form of groups of objects) and then performing one command on all of them simultaneously, or aggregating commands (in the form of user defined macros) for oft repeated sequences of commands will help. These both have architectural implications, as items of data must have a representation which can be grouped into some larger container (and hopefully this operation can be carried out recursively, grouping groups), and commands must have some sort of representation apart from the source code of the method which allows them to be grouped.
Although it does not necessarily follow that a reliable system is a usable one, the opposite may well be true. An unreliable system will often be unusable, especially if the problems lead to loss of data, or cause the system to become inoperational. There are many architectural techniques for improving system reliability, e.g. redundant fault tolerance mechanisms. Other possibilities involve making checks as to whether system resources are available before starting processing to avoid blocking/locking on unavailable resources.
From a different point of view we could consider the problems caused by the user having to move data from one part of a system to another manually. Retyping information is likely to lead to inconsistencies, and even using cut-and-paste mechanisms, information may be reassembled in the wrong order. It should be possible to design the system architecture in such a way that once a piece of data has been input once, it can be re-read by any other parts of the system which need it, without the user having to act. This will also aid efficiency of use.
If the system can build a model of the user's use of the system, then this model can be used to try and provide information (help etc) relevant to the user's level of experience. Taking a web example, a site may present introductory instructions to a user on their first few visits, but remove this and tell them about more sophisticated features later on based upon its model of the user's preferences/usage patterns. Building a model of the user and using this to drive aspects of system operation is obviously an architectural issue. Care must be taken with this approach. Many people say that the "You appear to be writing a letter... " feature of Microsoft Word is just annoying and not helpful. Information should be provided so that the user can look at if they want to, but they should not be forced to read it or acknowledge its presence.
Allowing the user to personalise an interface to suit their own needs and tastes will often make it more usable for them (at least they will find using it a more satisfying experience, due to their perceived level of control over the system). Provision in the architecture for components that the user interacts with to be independent of their positioning within the interface, and not dependent on other tools will aid this, and provide maximum flexibility. Also, a provision for identifying a user, storing and reproducing each user's settings is required. Having system colour schemes set on a per user basis rather than defined at startup (or having defaults that can be overridden) may also be desirable. However, the user may not be a usability expert(!) and may create a really unusable interface for themselves. Perhaps it would be possible to have checks to make sure that there is enough contrast between foreground and background colours etc.
In a web scenario, having personalised versions of pages may lead to confusion if a pages are being served from a cache. A default (or a different user's) configuration may be returned if a new page is not generated by the original site to serve the request.
Providing good, targeted, help is important here. Again building a model of the user, see adapting to the user's experience level.
This is primarily of concern for web applications. Taking a slightly different view of architecture, the structure of the site should be designed so that URI's (and on screen navigation) can give a good idea of current location and context within an overall structure. It may be that the technologies employed to create a dynamic site hinder this, especially where URLs become polluted with parameters, session identifiers etc.