Background
The read-only project originated from my work on DataStage, IBM’s canvas-based data integration software. DataStage needed a way to present portions of its interface in a read-only state. While exploring designs, it became clear that this was not just a DataStage problem. An effective read-only solution had to be addressed at the design system level. I led the design effort for this work which resulted in two published read-only design patterns. The first pattern outlined read-only experiences for canvas-based products, like DataStage. The second pattern laid out guidance for creating read-only states for components.
Project components
Competitive analysis, usability testing, interactive prototype, design critique, specifications, documentation, design system, accessibility
Canvas read-only mode
The first phase of the read-only work was driven by DataStage’s need to display its canvas and other interface elements in a read-only mode. This work would eventually involve a number of other product teams that contributed to defining the read-only experience for all of IBM’s canvas-based software.
Competitive analysis: Applications
As a jumping off point, I conducted a competitive analysis of 14 desktop and web applications across five software categories: design, notes, presentation, spreadsheet and word processing. The main selection criteria for the applications was the inclusion of a read-only, or equivalent, mode. The main goal of the research was to see how different applications alter their experiences when switching to a read-only mode.
Word Processing
Spreadsheet
Presentation
Design
Notes
Key findings
Persistent read-only label
The majority of applications displayed a persistent label, typically at the top of screen, that explicitly calls out the mode.
Minimal interface changes for desktop applications
Desktop applications maintained a nearly identical interface, including editing actions, while in a read-only mode. Because users were allowed to edit the files, enforcement of read-only occurred when saving.
Restricted editing actions for web applications
All of the web applications hid, or disabled, interactive elements and editing actions while in a read-only mode.
Conceptual designs
Using the competitive analysis’ findings as a guide, I began exploring designs for DataStage’s read-only mode. The designs focused on three main interface areas: toolbar, canvas and properties panel. Throughout the process, I worked closely with my team and other product teams to review, critique and refine the designs.
Toolbar
The toolbar contains a number of editing-focused actions. Our read-only strategy relied on maintaining the toolbar's layout and disabling all buttons related to editing.
Canvas
Aligning with the applications we researched in the competitive analysis, we placed the read-only label at the top of the canvas area.
The read-only nodes were designed to blend into the canvas’ background to create a static feel. However, read-only nodes also needed to be partially interactive so users could open and view their properties.
Properties panel
The properties panel is a form containing fields used to configure a node. The properties used, and not used, tell the user a story about how data flows through the node.
Usability study
Using the conceptual designs, I created interactive prototypes for DataStage to test three common scenarios involving read-only mode. Working with designers from several other canvas-based products, similar prototypes were created and tested to gather feedback from a broader audience.
Research questions
Can the user clearly identify when they are in a read-only experience?
Does the information provided in read-only mode meet the user’s needs?
Do users understand the difference between the two types of read-only modes: read-only and locked?
Key findings
Mode label not prominent
The majority of participants did not immediately see the label at the top of the screen, causing confusion.
Component styling effectively conveyed a read-only state
While in the properties panel, most participants stated that the form felt flat and not interactive.
Editable and read-only content should match
All participants agreed that the information and layout should match between modes. They felt that properties and property options that were not used were just as important as those that were. For example, a checkbox that was unchecked or a radio button array showing the unselected options.
Canvas designs
The final read-only mode designs were restricted to the canvas area of the interface. These designs were used as the foundation for the Read-only canvas design pattern. The other interface areas, the toolbar and properties panel, were deemed out of scope and moved to the next phase of the read-only project (see Carbon read-only state section below).
The salient design changes made for the final deliverables were to the read-only label. To improve the label’s visibility it was given a bigger footprint, larger icon, heavier text weight and higher contrast. In addition, we added tooltips to better explain the types of read-only modes.
specifications
Final deliverable
Documentation
Final deliverable
Design pattern
The canvas designs were adapted into a pattern published to the Carbon for IBM Products design system site, an IBM internal extension of the Carbon designs system.
Read-only canvas
Published pattern
Carbon read-only state
The second phase of the read-only project aimed to fill the gaps in IBM’s Carbon designs system. To meet the needs of DataStage users, we needed a read-only view of our properties panel. The contents of the properties panel relied heavily on Carbon input components like text inputs, dropdowns, checkboxes and so on. However, none of these components had read-only states and Carbon’s guidance for read-only was practically nonexistent. To solve these issues I, along with my colleague Devin O’Bryan, decided to take on the effort of developing Carbon’s read-only state pattern and designing read-only states for all its input components.
Competitive analysis: Design systems
To dive deeper into the realm of read-only, it was important to learn how other design systems have tackled the issue. Strangely, many of the design systems we reviewed had minimal or no content on read-only. The mentions of read-only we did find were specific to input components.
We reviewed design systems from these companies and found little to no information on read-only.
Key findings
Oracle's JET site included a variation of read-only states called, "mixed readonly." These examples were useful because they showed the visual changes between editing and read-only modes.
Google's Material Design site briefly discussed read-only in the context of text fields. The field's visual styling is very similar to the editing mode with the exception of a persistent label.
Additional research
Because our competitors’ design systems did not yield much substance, we sought answers from software development resources. Looking at how HTML input attributes are presented in documentation helped us create definitions for several important elements related to read-only. These definitions provided common language for discussing read-only with stakeholders and contributed to the foundational knowledge used for developing the design pattern.
definitions
Form
An element containing interactive controls or input fields used for submitting information.
Default
Active input fields with values that can be changed. These values will be utilized when a form is submitted.
Disabled
Input fields with values that cannot be modified but will be utilized when a form is submitted.
Read-only
Inactive input fields with values that will not be utilized when a form is submitted.
Input component designs
The component designs were comprehensive, addressing read-only states for all nine of Carbon’s input components and their many variations. The design process was highly collaborative, involving key Carbon team members representing design, accessibility, and development. Over the course of the project, a number of design critiques were held with the Carbon team to gather feedback and refine the designs.
Design explorations done during the first phase of the project were used as the starting point of this design work.
This one-sheet includes all the final read-only state designs juxtaposed with their enabled (editable) and disabled states. It's helpful to view these states together because, in many ways, read-only is a melding of the other two states. Ultimately, read-only states aim to emphasize critical information and deemphasize, or remove, interactive elements.
We worked closely with Carbon’s accessibility lead to determine cursor state changes and focusable elements for each component’s read-only state. Checkbox groups were unique because checkbox items have selectable text and are focusable to accommodate keyboard navigation.
Design specifications
Final deliverable
Design documentation
Final deliverable
Design pattern
The read-only state design pattern is the culmination of both phases of the read-only project. The pattern built off of the earlier canvas read-only efforts and evolved, in tandem, with the input component designs. The resulting pattern provided designers a flexible framework for creating read-only states for the components they design. The next step for the pattern was to expand guidance to the product-level. Taking what I learned from the canvas research and designs, I wanted to provide teams a consistent structure for creating read-only modes for their product experiences.
Read-only state
Published pattern