Sunday, March 27, 2016

Papyrus Modeling Tool: Usability Issues and Reasons

By Amal Ahmed Anda

Papyrus Mars release (1.1.3) Modeling Tool


Systems modeling is a difficult task that is likely to suffer from errors. Modeling has tools that
should be usable and easy to learn. We conducted cognitive walkthrough and usability testing
methods to gain a more comprehensive evaluation of the interface of the Papyrus Mars release
(1.1.3)  Modeling Tool.  I listed some of the usability problems of the tools detected by both
evaluation methods organized by related task. For each problem, we displayed the reason, rate
of participants from user testing results, severity and responsible part of the interface.

A. Create a New Papyrus Project Task:

Problem number 1:

When users enter the project name and want to do the next task, both the “Finish” and “Next”
buttons are enabled (as shown in Figure 1). This confuses users, and some of them may click on
the “Finish” button before completing the task. 
Failure story: Users may not have realized they should go to the next step to choose diagram 
language, so they may click on the “Finish” button.

Figure 1. Create Project Wizard

Reason
Severity
User Percentage
Interface Part
Confusing screen design
 Major
50%
Create Project Wizard

Recommendation: The best solution is to eliminate or disable the “Finish” button, so the
only available choice is “Next”, which is the right choice. Now users cannot miss their goal.

B. Create a Requirement Model Task:

Problem number 2:

When users add a relational to the requirement diagram, they may write the rationale name
in the rationale body (as shown in Figure 2).
Failure story: Users may not realize they have to write the rationale description because
they learned from interacting with the tool that the component name is the first text they
have to type.

Figure 2.Rationale body looks like as rationale name.



Reason
Severity
User Percentage
Interface Part
Poor feedback, labeling or
error message
 Major
Not tested by users
Model editor View

Recommendation: The system should move the text down and add a “Body” label so
users know they  are going to write the description not the name of the rationale component
(as shown in Figure 3).

Figure 3. the suggested solution of rational body issue.

Problem number 3:

The alternative way to add a rationale link is by using:
the properties dialog => UML=> Annotated element.
The user can add or delete any related element. However, the system does not always display the
link in the model editing view (as shown in Figure 12).
Failure story: Users may not realize that they succeeded, and they will keep looking for how to add
the rationale link.

Figure 4. Mismatching between properties view and model view

Reason
Severity
User Percentage
Interface Part
Bug
 Major
50%
Properties View

Recommendation: The system should draw the relation line between the two
components in the model view when the user adds it using the properties dialog.
In this way,  the user can realize that they did the right action and stopped looking for
another way to reach their goal.

C. Modify Requirement Table Task:

Problem number 4:

To modify the requirement table, users click on the Requirement table choice on the
bottom of the page to display its properties dialog. However, the system displays the 
error message, Properties are not available” (as shown in Figure 4). Sometimes, the 
tool displays the properties dialog of another element (as illustrated in figure 5). The user selects the requirement table, and the tool displays the properties dialog of
the sensor requirement.
Failure story: Users may keep searching for another way to view the properties
before they give up.

Figure 5. The error message system displayed when user clicked on Requirement table 

Reason
Severity
User Percentage
Interface Part
Bug
 Major
100%
Properties View


Figure 6. Mismatching between properties view and the selected item.

Recommendation: The properties dialog should be displayed correctly when users click on the table
requirement on the tape located on the bottom of the model view. Users learn from the system that
when clicking on any element on the same tape, the related properties dialog will be displayed.

Problem number 5:

When users change the value of the Root element” property in the properties view of the
requirement table, the system does not refresh the table in the model view (as shown in Figure 6). 
Failure story: Users may not realize that they have succeeded. Thus, they keep looking for a solution.

Figure 8. Mismatching between properties values and the model editor view. 

Reason
Severity
User Percentage
Interface Part
Bug
 Major
33%  (all participant who reach this step)
Properties View

Recommendation: The proposed solution is that the system should refresh the table by displaying
the related information when the user changes the root element value. As a result, the user will see
the progress and stop looking for another way to change the root of table elements.

Problem number 6, 7:

In the properties dialog => advanced,
 “Current Column Axis Provider” and "Current Row Axis Provider”,
These properties have vague values.When the user clicks on the “...” button beside the
property, the system displays repeated vague values to the property (as shown in Figure 9).

Failure story: Users may not realize that changing these values could change the way of 
displaying the requirements in the model view. Users may become confused because of 
these values.

Figure 9. Repeated values of column and row properties.

Reason
Severity
User Percentage
Interface Part
Poor feedback, labeling
 Minor
Not tested
Properties View

Recommendation: The solution is to eliminate the repeated values so they do not
confuse the users, and replace technical terms with users’ words such as data source
instead of a provider.

Responsibility of Which Interface Parts 


To figure out which part of the interface that responsible for most usability errors, we classified
 the detected problem based on their related part of the interface (as shown in Table 1). Properties
View interface is the most part of interface suffering from errors.

Table1. The number of detected problems distributed on relevant interface parts.
Interface Part
Problem’s number
of both method
Rate
Create Project Wizard
3
17%
Project Explorer
1
6%
Pallete
2
11%
Properties dialog view
10
55%
Model editor view
3
17%


 CONCLUSION


Although the Papyrus tool does not have any critical errors, it didn’t provide a clear mental model
due to lack of feedback, invisible software elements, or bugs in the software itself. These kinds
of defects make the software difficult to learn by changing users’ mental model about performing
the task. I recommend to fix properties view’s issues and strengthening its relation with the model editor view, so more than half of the usability problems will be solved. Which increase the
system usability and ease of learning.




No comments:

Post a Comment