Addressing Usability Requirements in Mobile Software Development
Rafael Capilla1; Laura Carvajal2; Hui Lin2 1 Universidad Rey Juan Carlos, Madrid, Spain
2 Universidad Politécnica de Madrid, Madrid, Spain
Abstract
Usability is an important quality requirement for many of today’s software applications, with the complexity of modern user interfaces and the quick reaction required by users demanding highly usable software. However, usability is many times poorly addressed because usability requirements often require an additional implementation effort. In addition, usability is sometimes rarely described in the software architecture so it is difficult to perceive where and how usability impacts the software design. In this chapter, we analyze the impact of two usability mechanisms in the software architecture of a mobile software application, because this kind of software demands stringent usability requirements. We also map the generic architectural responsibilities of the usability mechanisms analyzed to concrete classes in the software architecture of the mobile application supporting such functionality.
Introduction
The software architecture community recognizes the importance of quality attributes for both software design and implementation methods, but such qualities are many times neglected and poorly documented. Software quality evaluation methods such as ATAM or ARID (Clements et al., 2002) are often used in the early stages of the software design process.
Today, one key relevant quality attribute for modern software development is usability because, since the 1980s, usability features have played a key role in building more usable software. Usability has been defined in various ways in literature throughout the years. One of the most widely known definitions, proposed by the ISO 9126 standard (replaced by the standard ISO/IEC 25000:2005—http://www.iso.org), describes usability as “the capability of the software product to be understood, learned, used and attractive to the user, when used under specified conditions.” Other authors (Kumar Dubey and Rana, 2010; Seffah, 2004) recognize the importance of usability in multiple factors and the difficulty of putting usability into practice, but the majority of the proposed definitions consider usability as a critical aspect for interactive systems. Such relevance has been highlighted in several studies (Black, 2002; Donahue, 2001; Moreno et al., 2013) aimed at demonstrating the benefits of usabilities, including reduction of documentation and training costs, improvement of productivity, increasing morale and e-commerce revenue, and more. Accordingly, large-scale companies such as IBM and Boeing Co. have begun to consider usability as a key factor when developing and buying software.
Nonetheless, despite the obvious potential rewards, we keep falling short of producing usable software, and even when developers are convinced of the need to introduce usability features, this process is far from straightforward. One of the main reasons behind these difficulties is the lack of integration between the two communities involved in the process of building usable software, namely the human computer interaction (HCI) and Software Engineering (SE) communities. Generally speaking, the former knows which characteristics have to be included in a software system to make it usable, and the latter knows how to build software correctly. The differences in terminology and development approaches used by both communities lead to well-known HCI practices that are not integrated in SE common practices.
In addition, some application domains such as mobile software demand stringent software requirements and usability mechanisms tailored for this kind of apps. Challenges related to the size of the interface, performance, notification to users when the mobile loses the connection, and customized text entry, among others, often drive the selection and use of usability mechanisms specific to mobile software. At present, there are a number of challenges related to the integration of usability features into common SE practices and where software designers demand assessment guidelines on how to introduce and describe usability mechanisms both in the architecture and in the code.
The remainder of this chapter is organized as follows. Section 12.1 discusses the related work. In Section 12.2, we describe a taxonomy of usability mechanisms that can be applied to mobile software development. Sections 12.3 and 12.4 outline the use cases and major architectural responsibilities of two usability mechanisms presented. In Section 12.5, we analyze the impact of the two usability mechanisms selected in the architecture of a mobile application, and we discuss the implications at the design level. Finally, Section 12.6 provides a discussion of the presented approach, and in Section 12.7 we draw conclusions.
12.1 Related Work
In order to understand the relationship between usability and software design, we describe in this section experiences and related work between usability and software architecture and related experiences in the mobile applications domain.
Bass and John (2002) describe 27 relevant usability scenarios and propose a solution to design them in the form of architectural patterns. The authors later evolved this work in John et al. (2005), introducing what they termed Usability Supporting Architectural Patterns, which propose Model View Controller (MVC)-specific sample solutions for usability concerns in Unified Modeling Language (UML). Some years later, John et al. (2009) sought to test this solution in industry. In their experiment, the authors realized that the general response was a resistance to the use of UML-based solutions. The feedback they obtained led them to remove the UML diagrams and replace them with textual descriptions that explain the structure and behavior of the solution without imposing a particular architecture. Complementarily, Ferre et al. (2003) identified 20 usability patterns and provided a design solution for incorporating them into the architecture of software applications. A different approach (Seffah et al., 2008) suggests design patterns as a solution to address concrete scenarios that illustrate how internal software components may affect the usability of the system.
Today, the importance of mobile software in many application domains requires stringent software requirements that need more and more usability attributes in order to facilitate the usage by end-users (e.g., quick reaction, interfaces easy to use, adequate feedback). Consequently, usability becomes a major concern for modern mobile applications for building highly usable interfaces. Several studies and experiences highlight the role of usability in mobile phone applications, and the evaluation and effects of usability might be different in a usability lab versus a real environment (Beck et al., 2003; Kaikkonen et al., 2005), because if the mobile user depends on location properties, physical motion (Kjeldskov and Stage, 2004), and specific contexts (e.g., mobile context), the effectiveness and efficiency as a quality of use in a particular environment may vary (Bevan and MacLeod, 1994; Kim et al., 2002; Ryan and Gonsalves, 2005; Terrenghi et al., 2005).
Moreover, the evaluation and study of HCI in mobile devices have been analyzed in Hussain and Kutar (2012a,b) in order to identify usability problems with apps installed in mobile phones (e.g., enlarge or minimize the interface). Also, the nHIMSS App Usability Work Group (2012) reported the results of the study of usability features that influence the feedback of user tasks in different scenarios because such results impact the design of the target system. Furthermore, Lundhal (2009) analyzes usability concerns in mobile apps for the NFC (Near Field Communication) technology, where usability is not only implemented in terms of usable interfaces, but also in the form of specific usability mechanisms such as a Progress Bar, which increases user satisfaction because it provides the necessary feedback during user interaction with the mobile device.
The majority of the approaches describing the relationship between architecture and usability only provide guidelines and recommendations to introduce usability patterns or mechanisms but not the details about how to perform this task or how to introduce such mechanisms in concrete architectural styles. The approach described in this chapter goes a step beyond because we define the generic and concrete architecture responsibilities for three-layered architectures and based on our previous experience using the MVC pattern. Moreover, most usability research aiming to analyze the impact of usability features in mobile apps has focused on testing and evaluating the effects of usability attributes, such as context, flexible interfaces, displaying different resolutions, and data entry methods, among others. However, they don’t describe the impact of usability requirements in the software architecture and how to implement such mechanisms in the architecture of mobile systems.
12.2 Usability Mechanisms for Mobile Applications
Based on the deficiencies summarized in the related work, we analyze the usability mechanisms that are of special interest for mobile applications in order to help software developers introduce usability mechanisms into the software architecture. Our study focused on of five PDA and Smartphone mobile applications developed at the Rey Juan Carlos University between 2005 and 2011 andanalyzed the usability features implemented on them. We also base our analysis on our previous experience of classifying usability mechanisms for the MVC pattern. As a result, we provide the following classification of usability mechanisms that we believe is suitable for mobile apps, and we include examples of use.
System status feedback usability mechanism: Inform users about the internal status of the system.
Mechanisms/functionality implemented: Status Display.
Examples: A status icon or bar when a Web page is being accessed using a Smartphone. A status window to notify that a resource is not available (e.g., a Bluetooth device). Check if a connection is available before doing something. Show an icon indicating connection.
Interaction usability mechanism: Inform users that the system has registered a user interaction. In other words, the system has heard users.
Mechanisms/functionality implemented: Interaction Feedback, let user know what’s going on.
Examples: The mobile device shakes when accessing an application.
Warning usability mechanism: Inform users of any action with important consequences.
Mechanisms/functionality implemented: Warning.
Examples: Warn about an unsecure Web site or inform about removing data from the agenda.
Long Action Feedback usability mechanism: Inform users that the system is processing an action that will take some time to complete.
Mechanisms/functionality implemented: Progress Indicator, let user know what’s going on.
Examples: A bar indicating progress, an icon with a timer, a message displaying the remaining time to complete a task (e.g., progress connecting to a service).
Global Undo usability mechanism: Undo system actions at several levels.
Mechanisms/functionality implemented: Go Back One Step.
Examples: A mobile Web app including a questionnaire that allows you to reset values.
Abort Operation usability mechanism: Cancel the execution of an action or the whole application.
Mechanisms/functionality implemented: Go Back One Step. Emergency Exit. Cancellability.
Examples: A mobile Web app including a functionality to fill several questionnaires that allows you to cancel the process while filling any questionnaire going back to a specific place. Cancel sending a file.
Go Back usability mechanism: Go back to a particular state in a command execution sequence.
Mechanisms/functionality implemented: Go Back to a Safe Place, Go Back One Step.
Examples: Home button, Back button.
Structured Text Entry usability mechanism: Prevent users from data input errors.
Mechanisms/functionality implemented: Forms, Structured Text Entry, Structured Format, and Structured Text Entry.
Examples: Forms. Reduce the number of screens to introduce and display data. A phone agenda.
Step-by-step execution usability mechanism: Help users with tasks that require different steps with user input and correct such input.
Mechanisms/functionality implemented: Step-by-Step.
Examples: Configuration of a new mobile application that is downloaded and installed in the device.
Preferences usability mechanism: Record each user's option.
Mechanisms/functionality implemented: User preferences.
Examples: Configure mobile phone settings or customized settings in a mobile app.
Favorites usability mechanism: Record certain places of interest for the user.
Mechanisms/functionality implemented: Favorites.
Examples: Favorites Web pages only for mobile apps using a Web interface.
Help usability mechanism: Provide different help levels for different users.
Mechanisms/functionality implemented: 1-help level.
Examples: In contrast to standalone applications where multilevel help is common, small interfaces like those used in mobile applications often implement 1-help level.
From our previous classification of usability mechanisms that can be employed in the development of mobile software, we analyze the use and impact of such usability mechanisms in the design process, which we formulate in terms of the following research questions (RQs):
RQ1: Which are the responsibilities of usability mechanisms from the software architecture point of view?
RQ2: How do usability mechanisms impact the architecture of mobile applications?
In this research, we will focus only on two usability mechanisms that we believe represent important usability concerns demanded by modern mobile software apps. The two usability requirements we will study are:
a. System status feedback: Many mobile applications should inform users about the status of an action and let users know about the status of a given task, such as using a message or a warning.
b. User Preferences: All modern mobile devices include support to configure user preferences for a variety of configurable options such as wireless and radio settings, display, sound, privacy, and energy consumption. Therefore, users are allowed to check and change the current phone configuration and enable/disable some settings of the applications installed.
In the following sections, we outline how the aforementioned usability mechanisms impact the software architecture. We describe the functionality of each usability mechanism through use cases, and we map each use case to generic and concrete architectural elements that implement such functionality.
12.3 System Status Feedback
In this section, we focus on the system status feedback (SSF) mechanism. According to Table 12.1, the status display of a mobile application can warn users about the availability of a resource. More specifically, the use cases we identified for the SSF mechanism are described in Figure 12.1:
Table 12.1
Usability-Enabling Design Guideline: Concrete Object Responsibilities (Three-Layered Architecture)
| System Responsibility | Objects and Layers | |||
| Presentation Layer | Application Processing Layer | |||
| Display Status | Status Manager | Status | DomainClass | |
| SSF_SR-1 Be aware of system statuses (and their changes) | The Presentation Layer must subscribe to each Status object upon system initialization. | Upon system initialization, the StatusManager subscribes to each DomainClass that it knows can execute status-changing actions | The Status object holds all the information related to one system status and the means to change and query this information. It must notify all subscribers (Presentation Layer) of any changes | The DomainClass represents the domain object(s) responsible for executing actions that lead to system state changes. It must notify all subscribers (StatusManager) of any changes |
| SSF_SR-2 Handle user-initiated status changes | The Presentation Layer listens to user’s requests for execution actions action and forwards it to the Application Processing layer The Presentation Layer displays the status display for every notification of status change received | The StatusManager determines the corresponding Status object to update and does so with the information sent forth by the DomainClass | The Status calculates the effect, if any, that the received information has on its current active status value, change it, if applicable, and notify its subscribers (Presentation Layer) | The DomainClass executes the (status-altering) action and for notifies the StatusManager |
| SSF_SR-3 Handle system-initiated status changes | The Presentation Layer changes the status display for every notification of status change received | The StatusManager determines the corresponding Status object to update and does so with the information sent forth by the DomainClasses | The Status calculates the effect, if any, that the received information has on its current active status value, change it, if applicable, and notify its subscribers | The DomainClass executes the (status-altering) action—triggered by an external resource or other parts of the system—and to notify the StatusManager |
| SSF_SR-4 Present system status notifications to users | The Presentation layer knows which type of status notification to give for each status change. It also knows how and where to display each type of status notification and does so upon notification of Status objects | |||
SSF_UC-1 Change Status: A status change can be triggered by a user, who must be aware of system status and its changes.
SSF_UC-2 Handle User-initiated Status Changes: Changes in the status initiated by the user must be handled by a specific component and the parties involved notified about the results. A status manager often takes care of such status changes and updates the status information.
SSF_UC-3 Handle System-initiated Status Changes: In some cases changes its status; this action must be handled similarly as in the SSF_UC-2 use case.
SSF_UC-4 Display Status: Changes in the status must be displayed and notified to users.
12.3.1 SSF generic component responsibilities
According to the use cases of Figure 12.1, the description of the major usability design guidelines and the generic component responsibilities (SSF_SR stands for Status System Feedback System responsibility) that can be used to delimit the impact of a certain usability feature in the design is as follows.
SSF_SR-1: Be aware of system statuses and their changes.
Generic component responsibility: Certain Domain Components can execute actions that will change one or more application statuses. A StatusManager Component is responsible for monitoring said Domain Components and listens for their status-altering actions. A Status Component is responsible for holding all the information relating to a particular status and for modifying it according to StatusManager orders (please see SSF_SR-2 and SSF_SR-3 for details on how this happens). All Status Components can have one active status value at any given time (i.e., “online status” can be “online,” “idle,” “busy,” “offline,” etc.). The component responsible for handling user events (UI) must monitor all Status Components and notify the user of any changes.
SSF_SR-2: Handle user-initiated status changes.
Generic component responsibility: The component responsible for handling user events (UI) listens for user actions and orders their execution. The component in charge of delegating actions (if any) is responsible for ordering the appropriate Domain Component to execute said action. Upon execution of actions that are status-changing, each Domain Component is responsible for notifying any interested parties (specifically the Status Manager Component, in this case). The StatusManager component then forwards the updated information on to the appropriate Status Component. Said Status Component is then responsible for determining the effect, if any, that the received information will have on its current active status value. It will, when applicable, change said value and notify any interested parties (specifically the UI Component in this case). The UI Component will update the status display for every notification of status change received.
SSF_SR-3: Handled system-initiated status changes.
Generic component responsibility: Upon execution of actions that are status-changing—invoked by any other class in the system or an external source—each Domain Component is responsible for notifying any interested parties (specifically the Status Manager Component, in this case), as is the case when such an action is invoked by the user through the UI (see SSF_SR-2). The StatusManager component then forward the updated information on to the appropriate Status Component. Said Status Component is then responsible for determining the effect, if any, that the received information will have on its current active status value. It will, when applicable, change said value and notify any interested parties (specifically the UI Component in this case). The UI Component will update the status display for every notification of status change received.
SSF_SR-4: Present system status notifications to users.
Generic component responsibility: The UI Component is responsible for knowing how and where each status (and its possible values) is displayed within the interface, and, thus, for updating the status upon receipt of notifications of status value change.
12.3.2 SSF architectural component responsibilities
In this section, we describe how the SSF impacts the design of the software architecture, for which we have selected a layered architecture, which is one of the most common architectural styles used in many modern software applications. Because the level of responsibility of each layer in the architecture is different, we need to map the system responsibility for each use case of the SSF mechanism. The generic responsibilities of SSF mechanism at the design level are as follows:
Display status: This component is responsible for showing status changes motivated by a user request or a change in the system status. The component also informs users about the new system status or the status resulting from a specific action.
Status component: A status component supports all the information related to one system status and notifies the subscribers of any change in a particular status.
Status manager component: This component handles the management of the status changes based on user and system requests, determining which new status the system must change and which information must be updated.
Domain component: A domain component represents the part of the system that is ultimately responsible for executing the actions requested by the user. For instance, in an e-mail program, clicking the Send button may have many intermediate effects (checking that the Subject field is not empty, loading attachments, etc.), but the part of the system that is actually responsible for sending the e-mail is referred to as the domain component in the context of these mechanisms
More specifically, we detail the concrete responsibilities of SSF for a layered architecture. The display status component is supported by the presentation layer of any client-server Web or mobile application, because the status display shows the results of the new status to the clients at the presentation layer. The status manager and status component act at the application processing layer, where the functionality of the application, accepting user and system requests, changes the status accordingly to a new one and informs the subscribers about a new status. Finally, the Domain component is represented by the DomainClass, and it must be considered an entity to be substituted at design time by the class that actually performs the requested task. Table 12.1 shows how the responsibility of each use case affects to each component for the layered architecture. However, because the data management layer does not have any responsibility in the use cases mentioned before and does not support any component regarding the SSF mechanism, we didn’t represent it the table.
Figure 12.2 describes the UML package diagram of a three-layered architecture representing the distribution of the classes belonging to the SSF mechanism. As we can see, these classes should be attached to those describing the functionality of a concrete application and specify which new relationships must be added to incorporate the SSF mechanism in the software architecture.
12.4 User Preferences
The User Preferences usability mechanism covers user needs in a centralized place or database where the user can alter the application’s settings. Different types of user preferences can be organized around categories, which lets users tailor these or set their personal preferences for a given time frame. Moreover, in case of any software problem, mobile phone users can roll back these changes and set the default settings stored in the mobile phone. The use cases belonging to this mechanism are described in Figure 12.3 and are the following:
PREF_UC-1 SavePreferencesForUser: Upon making changes to one or more preferences, the user requests that they be saved. This will trigger the included use case PREF_UC-4 StorePreferenceValuesToPersistence.
PREF_UC-2 LoadCannedSettings: User request that a group of canned settings be loaded, allowing them to set a number of preferences all at once. This use case triggers PREF_UC-5 LoadPreferenceValuesFromPersistence when loading the canned settings.
PREF_UC-3 LoadPreferencesForUser: Users request that their preferences be loaded directly or indirectly. For example, starting the application is an indirect way to request that preferences be loaded into certain systems. This use case also triggers PREF_UC-5 LoadPreferenceValuesFromPersistence, as each of the preferences to load needs to be “filled in” with its value stored in persistence.
PREF_UC-4 StorePreferenceValuesToPersistence: This use case is triggered by PREF_UC-1 SavePreferencesForUser every time a user chooses to save his or her current preferences. It writes the preference values onto the predetermined physical medium.
PREF_UC-5 LoadPreferenceValuesFromPersistence: This use case is triggered by PREF_UC-2 LoadCannedSettings when loading a canned setting. Each of the default values for the preferences contained in that setting need to be loaded from persistence.
Like in the SSF usability mechanism, the description of the uses cases for Preferences, including the generic component responsibilities, are shown in Table 12.2.
Table 12.2
Usability-Enabling Design Guideline: Concrete Object Responsibilities (Three-Layered Architecture)
| System Responsibility | Objects and Layers | |||
| Presentation Layer | Application Processing Layer | Data Mgmt. Layer | ||
| User | Preferences Manager | Settings Manager | StorageFront | |
| PREF_SR-1 Set Preferences | The User requests its Setting object to update all of the sent preference values Requests are forwarded to the Preferences Manager | The Preferences Manager orders each Preference to update itself with the new value Each Preference object updates its value to be the new value sent The Preference object updates itself as requested by the Preferences Manager | For each value sent, the Setting object within the User updates its internal Preference objects. The Setting saves itself once all of its internal Preferences have been updated The Setting object rolls itself out by loading all of its pref-value pairs from the StorageFront and loading them onto the “live” Preferences, via the PreferencesManager For each pref name in the received pref-value pairs, the Setting asks the PreferencesManager to update the corresponding Preference object with the designated value | The StorageFront stores the saved Setting object to the appropriate persistence medium |
| PREF_SR-2 Provide Default values | The User forwards the call to its Setting object | The Preference object, responsible for knowing and setting its default value, sets its currentValue to that default | The Setting orders each Preference to reset itself to its defaultValue The Setting saves itself via the StorageFront | The Storage Front writes the updated Setting to the appropriate storage medium |
| PREF_SR-3 Allow “canned settings” | The User load the canned setting via the Settings Manager object | The Preferences Manager orders each Preference to update itself with the new value The Preference object updates itself as requested by the Preferences Manager | The Setting object rolls itself out by loading all of its pref-value pairs from the StorageFront onto the “live” Preferences, via the PreferencesManager For each pref name in the received pref-value pairs, the Setting asks the PreferencesManager to update the corresponding Preference object (live) with the designated value | The StorageFront loads all of the pref-value pairs belonging to the Setting in question and returns them to it |
| PREF_SR-4 Organize Preferences | When preferences are loaded, these are displayed in groups or trees if applicable | |||
12.4.1 User Preferences generic component responsibilities
Based on the use cases of Figure 12.3, the major usability design guidelines and the generic component responsibilities for the User Preferences usability mechanism are as follows (PREF_SR stands for User Preferences System responsibility).
PREF_SR-1: Set preferences.
Generic component responsibility: A Preference component holds the information related to a single “live” system preference, minimally its name (i.e., Background color), its possible values (i.e., green, red, blue), and its current active value. A preference is “live” once it’s been loaded (as opposed to a preference setting that may be stored in the hard drive for later use). A PreferencesManager component is responsible for knowing, handling, and retrieving all live Preference components within the system. A Setting Component represents a group of predetermined value pairs (preference name-preference value) that can be loaded from the hard drive (through the Storage Front Component) and rolled out into the live preferences. The StorageFront component represents the link between the application logic and the repository where the preference values are saved. A Setting will load its values through the StorageFront, because only this class has direct access to the information stored in the hard drive (or other media).
PREF_SR-2: Provide default values.
Generic component responsibility: The Preference component is also responsible for knowing what (if any) is its default value and for setting itself to that value if/when requested by the UI.
PREF_SR-3: Allow “canned settings.”
Generic component responsibility: A SettingsManager is responsible for loading stored Settings when asked by the UI.
PREF_SR-4: Organize preferences.
Generic component responsibility: If preferences are to be grouped, a Group Component is responsible for holding related preferences and for providing the UI with them.
12.4.2 User Preferences architectural component responsibilities
In this section, we describe the responsibilities of the major components of the User Preferences usability mechanism and their roles in a three-layered software architecture.
Preference component: This component is responsible for holding the basic data related to a “live” preference where an attribute is set to a value (e.g., the wireless network provider is set to a certain “local operator”).
Settings component: The Setting component represents a group of Preferences with an assigned value (e.g., using canned settings).
PreferenceManager component. This component handles individual Preferences within the system.
StorageFront component: The StorageFront Component stores and retrieves preference values into persistence. It can access the physical media where these values are stored.
SettingsManager component: This component is in charge of saving and loading Settings upon a request to the system.
User component: The User Component is in charge for holding and accessing a sole Settings component. This particular Settings component holds all the preference values stored for this particular User.
Group component: The Group component handles one or several Preference objects, where preferences are often grouped in a tree structure.
Each of the aforementioned components can be represented as classes in the architecture with the following functionality. The Preference Component is represented by the Preference class, and it handles the currently assigned (or active) value that the user has set or loaded. Preference objects are always contained within a Setting component, which is represented by the Setting class in the architecture. In addition, the so-called “canned settings” are described, for example, by a single Setting object containing a certain number of preferences with an assigned value. In multi-user systems, each User will contain a single Setting object, holding and managing all of its preferences at any time.
The PreferencesManager Component is represented by the PreferencesManager class, and it is responsible for ordering the Preferences that change and to retrieve these when they are requested. The SettingsManager Component represented by the SettingsManager class is the responsible for ordering newly created settings to be saved and to retrieve them. The User Component’s responsibilities are carried out by the User class, in charge of holding and managing the Setting object that contains all users’ preferences. Moreover, the Group Component is represented by the Group class for organizing and arranging Preferences according to a particular structure. Finally, the StorageFront Component is represented by the StorageFront parent class and by any of its subclasses. These classes are responsible for storing any saved data on a physical medium. Each subclass of StorageFront implements this functionality for each needed particular physical medium (e.g., a Database or a text file). The components described in Table 12.2 describe the low-level responsibilities which are mapped to classes in the layered architecture of Figure 12.4. However, in order to simplify the descriptions in Table 12.2, we have grouped some classes described before in more than one column (e.g., The PreferencesManager class includes the functionality of Preference and Group classes).
12.5 A Mobile Traffic Complaint System
In order to study the effects of usability in the software architecture of a real application, we describe in this section how we introduced the aforementioned usability mechanisms in a mobile application for a Smartphone. The system consists of a modern Android application for managing traffic tickets (M-ticket) issued by local police. The mobile application captures traffic infraction data and sends them to a Web server. The M-ticket application enables the police officer to capture an image and the location of the infraction via GPS and record the car and the infraction data using a text form. In this chapter, we do not care about the functionality of the Web application located in the police station to manage the traffic tickets received from the mobile application—we will only focus on the usability of the mobile app.
12.5.1 Usability requirements
The M-ticket system was developed in 2010, but it only included usability features regarding the design of the user interface, colors, size of menu buttons, and navigation. Because none of the usability mechanisms described in Section 12.2 were included, between 2012 and 2013 we decided to add the two mechanisms described in this chapter and evaluate their impact on the architecture. Consequently, the first step was to define the following usability requirement aimed to support the introduce usability mechanisms in the M-ticket application.
UR1. Alert message to users for pending tickets: In case of a loss of the radio signal between the mobile terminal and the server, an alert message will be displayed to the user of the M-ticket application indicating that the ticket cannot be sent. In addition, the mobile M-ticket application will show in the status bar an icon advising the user that there are pending tickets to be sent.
UR2. Configure alert messages: The user can configure the following options for the alert messages in the application: activate/deactivate shaking the phone when a new alert arises, activate/deactivate a sound, and the number of times the user should be notified about an alert.
Both usability requirements must be implemented in terms of concrete usability mechanisms, such as those described in this chapter.
12.5.2 Impact on the software architecture
This section describes the changes we performed on the software architecture of the M-ticket system to support the usability requirements and how these impacted the existing functionality. Figure 12.5 shows the new package diagram of the modified software architecture. The three layers of the design are as follows: (a) the presentation layer containing the entry screen to the Android applications, (b) the business logic layer of the M-ticket application containing the functionality of the app and the usability mechanisms introduced, and (c) the middleware and data access layer supporting the connection to the GPS and images captured by the phone that are sent to the Web server database.
The three-layered architecture of the M-ticket application depicts the new classes (red color) introduced in the design and the classes that changed (blue color). It also handles the two usability mechanisms (i.e., SSF and User Preferences) introduced in the system, which we explain below:
System status feedback: As we can see in Figure 12.5, in the Android application we modified two of the existing classes (NewComplaint, SendComplaint) in application logic tier in order to support the SSF mechanism. The NewComplaint class allows the police officer to create a new traffic ticket using the Complaint class shown in Figure 12.5. The functionality of the M-ticket app also implements the location of the vehicle using the GPS of the mobile phone, then it sends the form, the location, and a picture of the vehicle to a remote server. The changes introduced by the “Status Feedback” mechanism affect the notifications sent to the policeman using the mobile phone. In this way, we used the android.app.NotificationManager Android library to warn the user about events that may happen, such as a complaint already sent or no GPS signal. In addition, the changes to the SendComplaint class refer to the list of pending complaints stored in the mobile phone before they are sent to the server. In those cases of no pending complaints stored in the phone, the notifications will be removed.
User Preferences: Changing the user preference of the alert messages supported by the status feedback mechanism led us to introduce new classes (PreferenceManager, AlertMessages, StorageFront, and M-ticket Android database classes in Figure 12.5) in the architecture. However, this usability mechanism affected the functionality of all layers in the architecture. In the presentation layer, the MainScreen class, which acts as entry point of the mobile application once the user has logged onto the system, was modified to incorporate specific methods to set and edit the preferences of the alert messages. In the logic tier, we added two new classes, PreferenceManager and AlertMessages, which handle the specific preferences (i.e., shake, sound, and repetition) of each alert message. Finally, the implementation of the classes supporting this usability mechanism require a new class, StorageFront, located in the data access layer to store the user preferences, As we can see, there is another class in that layer, M-ticket Android database, which represents where the user preferences are stored. We added this class for the sake of clarity for designers, but in our system the storage of the user preferences data is located in a specific database of the M-ticket application.
In order to provide a better understanding of the classes we added and changed in the original architecture of the M-ticket app when usability was introduced, we describe in Tables 12.3 and 12.4 the association between the generic components of each usability mechanism and the classes that implement such functionality in our system accordingly to the architecture of Figure 12.5.
Table 12.3
Mapping Between the Classes of the SSF Usability Mechanism and Those Implemented in the Architecture of the M-ticket Application
| Usability Mechanism | Generic Component | Classes in the M-ticket Architecture | M-ticket Architectural Responsibility |
| System Status Feedback | Display Status | New Complaint | This class displays the status to the user |
| Status Manager | N/A | We don’t need this functionality as we only support one type of status | |
| Status Concrete Status | New Complaint | This class checks if there are pending complaints stored in the phone and updates the status when the complaints are sent to the server | |
| Domain | NotificationManager (Android) | This library performs low-level operations when the status changes and assigns an ID for the status. In case of a loss in the connection between the phone and the server, the New Complaint class will inform the Notification Manager with an ID, which will be used by the Send Complaint class when the notification need to be removed |
Table 12.4
Mapping Between the Classes of the User Preferences Usability Mechanism and Those Implemented in the Architecture of the M-ticket Application
| Usability Mechanism | Generic Component | Classes in the M-ticket Architecture | M-ticket Architectural Responsibility |
| User Preferences | User | Main Screen | Users can configure the options of their alert messages using the Main Screen interface |
| Preferences Manager | Preferences Manager | It handles the preferences set by the user | |
| Preference | Alert Messages | The alert message is the configurable preference supported by M-ticket | |
| Group | N/A | Not supported | |
| Settings Manager | N/A | Not supported | |
| Setting | N/A | Not supported | |
| Storage Front | Storage Front | It acts as an intermediate class to store the preferences edited by the user | |
| Mobile Phone Database | M-ticket database | This class relates the Storage Front with the access to the M-ticket database where preferences are stored |
The mapping between the generic components of each usability mechanism and the concrete classes in the M-ticket application described in Tables 12.3 and 12.4 guide software designers to introduce the concrete architectural responsibilities. Hence, software architects can use these mappings to determine the concrete responsibilities of new and existing classes in their application for supporting a particular usability mechanism. In our example, only one class is assigned to one component, but in more complex mechanisms, several classes can be assigned to the same component. However, we do not suggest guidelines for coding the usability mechanisms because these may depend on the current functionality of the application and the code in which the usability feature will be added.
12.5.3 Usability and interactions between entities
Because introducing usability in the software architecture introduces new relationships between the existing classes from the old design and the new classes supporting the functionality of both usability mechanisms, new interactions between the entities participating in the possible M-ticket scenarios arise. Because other stakeholders might be interested in the interactions that happen when a usability mechanism is activated or invoked by the system or the user, we describe in Figure 12.6 an example of a sequence diagram that exemplifies the dynamicity of the system and the calls made between the mobile user, the M-ticket application, and the server.
The aforementioned scenario shown in Figure 12.6 describes the interactions between the entities when a policeman sends a traffic ticket to the server application using the mobile device and the case where the usability mechanism SSF notifies the user if the ticket has been sent or the case when,due to a loss of the radio connection, the pending tickets have to be stored in the mobile device and the connection has to be rechecked before the tickets are resent.
12.6 Discussion
This chapter illustrates the importance of usability mechanisms and their implications at the architecture level when usability requirements demand specific usability mechanism, such as those described in this work. Research question RQ1 is answered in Sections 12.3 and 12.4, where we describe the architectural responsibilities for the two usability mechanisms analyzed. Also, we have highlighted the importance of this question by describing the role and the use cases of both usability mechanisms and which are the generic and concrete component architectural responsibilities for different scenarios.
Research question RQ2 is partially answered in Sections 12.3 and 12.4, but it is detailed on the example presented in Section 12.5 where we detail how the usability mechanisms describe the affect of the architecture of a mobile application. We discuss the implications at the design level of the changes that should be made for each of the usability mechanisms discussed in this chapter and provide a guiding example that shows the mappings between the generic classes of each usability mechanism and the real classes of the mobile application used.
In addition, usability requirements UR1 and UR2 defined for the M-ticket application are handled by the two usability mechanisms (SSF and User Preferences) described in the chapter. As a result, three of the existing classes were modified and four new classes were added. In order to estimate the impact of introducing both usability mechanisms in the design, the classes modified in the architecture represent around the 19% of the overall design, while the new classes represent around the 20% of the existing design. We didn’t take into account the changes or new relationships between classes, but the overall design effort in terms of classes added or modified represent the 39% of the design. However, the implications at the code level might not be exactly the same, because, for instance, implementing the SSF in the M-ticket application required only 4.2% new code. Hence, even if software designers perceive that redesigning the architecture to support a certain number of usability mechanisms involves changing or adding a considerable number of classes, the changes at the code level can be lower.
In the example shown we have only addressed two usability mechanisms, but more usability features can be incorporated. However, dealing with them will have its corresponding impact and cost in a clear competition with other quality attributes. Therefore, a trade-off between usability and its implications needs to be carefully studied for each application, identifying the more relevant usability requirements from the user perspective in each situation. This usability study should be done as soon as possible during the development process to avoid rework.
Additional trade-off analysis between usability and other quality requirements can be carried out in order to address the conflicts between the quality attributes. For instance, the results reported in Henningsson and Wholin (2002) show that usability and reliability have a positive influence, while usability and efficiency exhibit a negative influence. In our M-ticket application, we can say that the usability mechanisms introduced enhance the reliability of the application because mobile users are informed when a traffic ticket cannot be sent to the server. Hence, a quality trade-off analysis aimed to balance quality attributes becomes key relevant for software and product operation.
12.7 Conclusions
The introduction of usability mechanisms in any software has clear implication for the design. In this chapter, we show how the architecture of a mobile application is affected when we add usability mechanisms and which classes are needed to handle the responsibilities of each usability mechanism. We have also outlined the role of the major classes in the architecture when these usability mechanisms need to be introduced in any mobile application. In order to educate software designers about the introduction of usability mechanisms in their systems, and based on our personal experience, we have described the case of a real mobile application for which two usability mechanisms were introduced.
Consequently, we provide evidence about the need and impact for considering usability requirements in mobile software development. The usability requirements we have referred to in this work are general recommendations from the HCI community aimed at improving the usability of any software system. In this sense, our approach is complementary to existing works that address usability testing in similar applications.
Regarding the generalizability of the results, we observed from our study that many of the usability mechanisms analyzed in this work can be found and used in many Web applications or in mixed Web-mobile software. More specifically for mobile apps, because many modern smartphones share a similar interface, we believe using the same usability mechanisms in other mobile apps will have the same outcomes (also for Tablet PC).