Early Usability Measurement in Model-Driven Development: Definition and Empirical Evaluation

Abstract

Usability is currently a key feature for developing quality systems. A system that satisfies all the functional requirements can be strongly rejected by end-users if it presents usability problems. End-users demand intuitive interfaces and an easy interaction in order to simplify their work. The first step in developing usable systems is to determine whether a system is or is not usable. To do this, there are several proposals for measuring the system usability. Most of these proposals are focused on the final system and require a large amount of resources to perform the evaluation (end-users, video cameras, questionnaires, etc.). Usability problems that are detected once the system has been developed involve a lot of reworking by the analyst since these changes can affect the analysis, design, and implementation phases. This paper proposes a method to minimize the resources needed for the evaluation and reworking of usability problems. We propose an early usability evaluation that is based on conceptual models. The analyst can measure the usability of attributes that depend on conceptual primitives. This evaluation can be automated taking as input the conceptual models that represent the system abstractly.

A Proposal to Elicit Usability Requirements within a Model-Driven Development Environment

“… Defined Selection: the possible values can be inserted with a ListBox, a RadioButton or a TextBox (free text). According to criterion Minimal Action, enumerated values with less than 9 items should be displayed with RadioButtons, since all the possible values are shown directly (Panach, Condori-Fernández, Vos, Aquino, & Valverde, 2011). However, according to criterion Information Density, items should be displayed with a ListBox, such a way, the list of possible values is hidden until the end-user opens the list.…”

A Usability Model for Mobile Applications Generated with a Model-Driven Approach

“…Several usability guidelines such as [20] and [21] recommend using default value as much as possible. According to [22], at least 20% of input elements should have a default value. Noted that the default value is used twice in our proposal.…”

Incorporating usability requirements into model transformation technologies

“…• Attractiveness: the capability of the software product to be attractive to the user. Since the sub-characteristics have been described abstractly, we have analyzed some usability guidelines presented in the literature [3,11,20] in order to extract and adapt more detailed usability attributes. Table 2 shows our proposal to decompose the former sub-characteristics into measurable attributes.…”

“…It can be measured by means of the total number of interface elements that should not exceed a threshold. Some research studies have demonstrated that the total number of interface elements should not exceed 20 [20]. Having a total number exceeding 20, we propose to associate with each UIUnitSuit a UIWindow instead of a UIPanel.…”

“…It is important to guarantee the usability of the software in its earlier stages since correcting usability problems after writing the source code can be much more costly than if it is done at the beginning. This has led to emergence of a variety of techniques, methods, and tools to address usability from the beginning of the development process [2,10,11,20]. In such methods, usability evaluation is carried out earlier in the development process.…”