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.