Method
The process for designing the Page Restrictions user interface in Confluence involved:
- Collaborative design with the Confluence developers and Technical Writer.
- User walkthrough with a sample user and paper prototype.
- Iterative development through a variety of feedback sources.
Understanding the model
One of the key challenges for this project was to understand and usefully implement Inherited Space Permissions.
Following is a diagram used to illustrate and discuss Inherited Space Permissions.
Permissions versus Restrictions
A minor challenge for this project (and the participants) was the difference between Permissions and Restrictions. Page and Space security in Confluence is set by granting permission to a user, however, in this instance we wanted to restrict certain users from viewing or editing a page – turning the entire model upside down. We found in the early stages that it was quite easy to slip back into conceptualising the model as permissions based. We also found the same problem when walking through the user interface with our sample user. We amended the problem by labelling interface elements appropriately.
Initial Designs
Following are a set of designs that illustrate the evolution of the Page Restrictions user interface.
 |
The first cut of the design followed the existing Page Permissions user interface. At this point we attempt to illustrate the inherited Space Permissions. |
 |
Inherited Space Permissions are illustrated to their full extent within this design. The design at this stage is overly complicated and very hard to use. |
 |
Another attempt at illustrating the Inherited Space Permissions. At this stage we decided to look at other ways to include or display this information. |
 |
We’re getting closer to a viable user interface solution with this version. The Inherited Space Permissions are simply listed within the ‘Type’ column of the table. |
 |
Inherited Space Permissions are now illustrated within a separate table and positioned above the Page Restrictions to indicate the hierarchical relationship. Labelling and language has also evolved to provide the user with more context as to the function of Page Restrictions. |
User Walkthrough
Context…
This walkthrough was performed with a single subject utilising a ‘working’ prototype of the Page Restrictions functionality. This walkthrough was highly informal and the subject’s experience with the Confluence wiki was of a medium-level.
Scenario…
HR would like to hide a page (in Confluence) containing confidential information. This page would be hidden from the organisation and only viewed by the HR Director and the HR Administration Assistant. Additionally, editing of this page would only be done by the HR Director. HR is especially concerned about the confidential nature of their page content.
Findings…
- When presented with the scenario, and a page on Confluence, the "Restrictions" function was found quite easily.
- The section on Inherited Restrictions was unclear and potentially confusing as it required a deeper understanding of Permissions and Restrictions on a Space level.
- Choosing the "Users" link was accomplished quite easily, however, as the ‘Users’ dialog didn’t appear immediately, the subject then proceeded to enter a users name into the entry field on the right.
- The entry field on the right was found to be confusing (received an error message) as there were no examples of what to enter in the field.
- Our subject also felt that it was unclear as to why there were two sets of controls to perform the same action.
- Our subject attempted to add users (or groups) that they wished to ‘restrict from viewing’ the page and didn’t comprehend that the current model would in effect, do the opposite.
- Our subject felt the model was confusing and that they would not be very confident using the functionality to set page restrictions.
Recommendations…
- Provide a concise and easy-to-understand explanation of Inherited Restrictions.
- Change the radio button labels to better describe the model and the outcomes.
- Provide a stronger split (visually) between the ‘Choose’ and ‘Enter’ modes of adding Users and Groups.
Final Design
Following is the final Page Restrictions design implemented within Confluence.
Conclusion
The Confluence Page Restrictions project was the User Interface Team’s first opportunity (we’re only about 4 months old) to work collaboratively with Engineering. The process did take a little longer than expected, however, it was a great learning opportunity for our team and an excellent chance to bond with some Confluence developers. The outcome – while slightly committee driven – is a clean easy-to-use piece of user interface that fits well within the existing Confluence elements. The visual design also fits well with the existing look while at the same time setting new standards for visual design in our products.