Is usability an architectural quality? Does the easiness on how users do their tasks has an architectural impact, such that it has to be considered during the design of the system software architecture?
Let’s start by considering one aspect that seems far fetched from having any impact on the architecture: the colors used in the interface. The use of the right colors may improve the usability of a user interface but should the architect worry about it?
First, the architect cannot ignore the usability qualities of the system if they are raised by the stakeholders, and like any other quality they have to be explicitly stated. Then, if the usability qualities are agreed among the stakeholders to have a relevant business value, it is necessary to assess their impact on the architecture. In the above example, the use of the right colors may, or may not, have impact in the architecture depending on the concrete requirements and on the technology on top of which the system is going to be built.
Suppose that the usability requirement states that the end user can customize the colors of his user interface. In this case the architect will have to consider a module that supports that functionality. On the other hand, suppose that web designers will be in charge of deciding which colors to use in each interface. This is a situation where the use of a technology like cascading style sheets (css) can solve the problem and there will be a very limited impact on the architecture. Note, however, that this last situation may raise another requirement that is the decouple of the web designers work from programmers work, which actually has an architectural impact that fortunately some web development technology explicitly address, for instance the use of thymeleaf allows offline work.
In the Graphite case study we find two usability qualities. The first one is stated as:
The Graphite webapp allows users to request custom graphs with a simple URL-based API. Graphing parameters are specified in the query-string of an HTTP GET request, and a PNG image is returned in response.
This scenario describes a stimulus where the end user, actually an experienced user, wants to efficiently request graphs, which means that that by typing a query-string she can get a graph. The tactic to accomplish this scenario is the definition of a language, which impacts on the architecture design because the language sentences need to be parsed into commands that generate the graph.
On the other hand, the second scenario has non-technical users as source of the stimulus:
Graphite comes with its own Composer UI, shown in Figure 7.3, that does this using Javascript to modify the graph’s URL parameters as the user clicks through menus of the available features.
This usability requirement states that the system should guide the build of a graph to minimize errors but at a cost of efficiency. To support this scenario the system should have a model of the steps necessary to create a graph in order to guide the user. Curiously, the two tactics correspond to two different architectural styles for a compiler design, the first tactic separates the writing of the sentence from its processing, while the second allows the iterative construction and processing of the sentences.