Previously, anything that appeared in the DNA editor was able to be edited. With the latest software update, DNA that was labeled as a part was no longer able to be edited.
Engineers put together an interim solution to communicate the lack of editing capability. However, the yellow toast that they chose to use was physically far away and not clearly associated with the parts designation. It was difficult to understand that the toast was appearing as a result of the user attempting to type or otherwise edit the part.
Furthermore, the yellow toast raised unnecessary alarm. In other parts of the product, the toast is used to alert users when there is an error such as an unsuccessful upload or inability to render a graph view. Not being able to edit seemed much lower on the error hierarchy.
Because the initial solution had been an error toast popup, I had initially thought about this project as improving error messaging. I realized after stepping through the intended communication and end goal, however, that we were not actually messaging about an error. Rather, we just needed to message about the status of a section of DNA — uneditable. There wasn't an issue being raised with trying to edit a part, just that the status of "part" didn't allow for it.
With this new framework, I considered toast alternatives that would indicate status change.
One attempt was using a "no entry" symbol associated with the type cursor to indicate no typing. However, this solution was too broad. Other click actions, such as click+drag to highlight or right click, are still available. This does not clearly indicate that just editing was unavailable.
A different attempt used what I like to call the "Wordle shake" to indicate the area that would not allow the user to go forward with their action. However, this solution was jarring and did not follow the movement patterns of the rest of the product. Furthermore, it required the user to guess what was wrong.
The solution I decided on was a tooltip that would appear as the user tried to type. It provides explicit guidance for users to diagnose their error. It also places the messaging physically close to the area of interest, and implicitly communicates the appropriate degree of urgency (low) to the user.
It was fun to explore what message should appear on the tooltip. As a big believer in user control, I felt strongly that the message should not just instruct the user how to edit if they wanted to edit that section of DNA, but also provide the action needed to let the user actually do it.
The option with the button would provide the most efficient path to the user's end goal. However, adding an "Unlink part" added both a significant information redesign and an engineering burden. If the user had a section where two parts overlapped, which would be unlinked? Would both be unlinked? Because parts was not originally built with overlaps in mind, the existing infrastructure could not support such an action button. Given time and personnel constraints, we opted to use the 'better' option for now, with the 'best' option noted as a potential future project when DNA parts were next updated.
While the tooltip provided reactive messaging, I also wanted to create an "always on" visual indicator to continually remind users that parts were not editable. This would improve users' experience through continuous communication, and avoid the need to navigate through disruptive messaging. A common way of indicating a disabled state is by graying out an item to reduce contrast.
Graying out parts within the DNA sequence tested very well with users. It was an elegant solution because it was a clear visual cue for users to understand that some functionality was disabled while keeping the sequence available for copying or other non-editing actions. However, with the aid of online tool-based inspection, the lowered contrast presented a clear accessibility challenge for users with low vision. This was doubly a problem whenever parts overlapped and the contrast continued to lower. The proposed coloring below shows the drop in readability when text was lightened to indicate a disabled state.
The default text on Benchling was a dark gray color on a white background that was fairly accessible. However, the visual designation for a part included a gray background. When combined with a lighter gray text to indicate function "disabled," the sequence becomes unreadable for differently abled users. The problem is exacerbated when parts are overlapping and the gray background becomes darker.
Designing for inclusion is important because we want everyone to be able to use Benchling. Furthermore, improving usability for users with low vision increases general usability for all. With that in mind, I turned to a different "always on" visual cue to indicate that parts were not editable.
The blinking cursor changes into a non-blinking cursor when clicked into a part, providing a reminder that there is a change of status and editability in these specially designated areas.
As a user attempts to type, a tooltip appears to provide more explicit messaging. For users who are familiar with this functionality, the subtle change of the non-blinking cursor may be enough to remind them that they can’t edit that section. But if a user does attempt to type, a tooltip appears to provide more explicit messaging.
Altogether, the messaging that appears when a user attempts to edit a part looks like this:
