CEROS STUDIO

CREATE & EDIT INLINE TEXT LINKS

Ceros Studio is a SaaS codeless web content creation platform that utilizes a freeform design system for complete control over all visual and interactive elements. While total creative openness can give rise to some amazing outside-the-box designs, at times it can also become a burden to create basic web elements and even affect web accessibility, with inline text links being a great example. Due to these factors and client requests, I developed a streamlined way to add inline links into Studio's existing text components.

ROLES

Research, UX Design, UI Design, Testing

ORIGINAL METHODS

Before we introduced the concept of an actual text link element, users needed to build them out manually in a process that was inefficient and overly complicated. Studio generally requires designers to add On Click, On Hover, or On View interactions to elements they create either directly on the object or using a hotspot on top of the object. These methods can be especially problematic for links inside a text box for a number of reasons.

The hotspot method requires a user to draw a transparent box over the specific words they would like to use as a link and then add a Go to URL interaction to that box. This makes the creation of a hover state very difficult, since there is no direct interaction with the text element, and at the time, Studio required multiple objects per "state" to create a hover effect. Essentially, the resting state would hide when hovered and a completely different object would show as the hover state.

Applying the interaction directly to the text box also has issues, since the entire text component would now be actionable vs just the desired text. People were using complicated workarounds if relying on this method, where a separate text component containing just the text to be used as a link would be overlayed on the text box, have the interaction applied, and then would use the show / hide method described above to create the illusion of a hover state. This method meant that creating a link on a section of text would require three different elements to exist.

PRIORITIZATION & SCOPE

Clients had been requesting a simplified way to create inline links for some time, so we were fairly confident it would add value. Unfortunately, there were higher feature priorities that existed, so adding this functionality kept getting pushed off. However, when we decided to take on our content accessibility initiative, we realized all the old methods of creating links would not work with screen readers, thereby ensuring we could not meet accessibility standards.

There were a few things we took into consideration when determining our scope, with the largest factor being an upcoming text component restructure on the horizon. While not 100% positive what that restructure would ultimately look like, we didn't want to dedicate a large amount of time and resources to develop an extremely robust feature that could potentially need to be reworked or even completely scrapped when the new text components were introduced. We also had designs waiting to be implemented for saved text styles that could affect how some of the visual properties might be handled for text links. In the end, the scope was kept fairly narrow, with basic functionality for creating and editing links while using already existing text property manipulation to control the visual aspects.

POTENTIAL MODELS

Since we knew designers were asking for this feature and we would need to add this functionality no matter what to reach our accessibility goals, we didn't spend a lot of time on further validation. However, after looking into the architecture of the current text boxes and Studio's workflow patterns, I determined we had a few main options we could explore on how links were created and managed, and we would talk to users to finalize the decision.

INTERACTION PANE MODEL

Since Studio already had a way to add Go to interactions to objects in our Inspector Panel's Interact Pane (including URL, anchor, and internal page), we could rely on that established workflow for users. The way the desired link text would be selected and manipulated would still need to be modified, but applying the interaction might not. On the one hand, the methodology would be consistent between links and any other component in Studio, so the pattern would be recognizable and might be expected. On the other hand, we would need to introduce a new mental model of a sub-component - the link would need to be an available component to have an interaction applied directly to it, but that would exist within another component that could have an interaction applied to it - and while Studio does have Groups which can contain multiple components, that model is very different than what we were proposing.

POPOVER MODEL

Another model under consideration relied on an interaction model that would be new to Studio - a user would highlight a section of text and then create a link in a dedicated flow popover. This method seemed to be the most common across platforms, including word processors and presentation software, and while it would require users to use a pattern previously not available in Studio itself, it would most likely be familiar to people in general. My hypothesis was that this model would the be most popular in testing, but there were concerns that we could have competing methods of applying interactions between different component types. Whether or not that mattered would need to be investigated further.

DESIGN PANE MODEL (REJECTED)

The last model I explored would add a new inline link module into the Inspector Panel's Design Pane when a text box was selected. This model was rejected fairly early on, however, as it created issues with the pane's information architecture. It also broke established property patterns in the Inspector Panel and really caused problems when trying to reconcile multiple inline links in the same text box.

INITIAL INTERVIEWS & TESTING

I set up interviews with users in order to understand the expectations they had around creating inline text links. I wanted to understand the pain points in using the old workarounds, and we then dug deeper into some of the use cases for links and what the link targets generally were. The second half of the interviews were dedicated to testing the prototypes I had built for each model to get initial feedback on how effective they might be.

Key Takeaways

Before seeing either of our models, the majority of users said they would expect to create links like they do in Google Docs or some sort of equivelent program
The most common targets for text links were external URLs
Controlling the link's visual style for both resting and hover states would be important for branding purposes
After using both prototypes, the popover method was overwhelmingly favored
There did not seem to be any concern for competing Go to interaction methods across object types

MODEL SELECTION & DESIGN

The user interviews and testing gave a clear answer on which model should be implemented, so design began on the popover method. I mapped out the necessary user flows for link creation, modification, and deletion, and then began to work on potential UI solutions. The design language was already set for Studio, so all UI elements would need to exist within that visual library, and although this particular popover flow was new to Studio, we would still rely on as many established patterns as possible.

Initiating the link creation would happen once the right-click menu was triggered on a selected span within a text box. Modification and deletion flows would be triggered by a click anywhere inside the existing inline text link.

To be sure that users would not have to utilize the older link creation method that used the already existing object interactions, it was decided that each Go to interaction that was available for non-text components would be added to the new inline links flow. This was done using dropdowns and contextual target fields in the popover that closely mimicked the way these interactions were applied via the Inspector Panel.

A good deal of effort was spent determining various smaller yet important questions like what happens when a designer begins typing at the beginning, middle, or end of a link and how a designer could determine a span was actually a link if the visual properties had been changed to look like the surrounding text. At times the architecture of Studio's text boxes made solutioning problems like these much more complicated than they needed to be, but by working closely with engineering, we were able to make sure the design was solid and any gotchas were accounted for.

One of the trickier problems we came across pertained to the visual treatment of the links. Studio allows spans to have different colors within a text box, so changing the resting color of an inline link to match branding was not a concern, but how hover and visited states would be displayed was. This was something that came up frequently in our interviews, so we knew we could not just add a generic color for these states. Allowing users to edit these would also require a completely new model, which was out of scope. In the end we decided to darken or lighten each state - depending on the color immediately behind the text - within the color spectrum of the resting state.

USABILITY TESTING

As the designs were coming together, I was talking to users and having them interact with high fidelity prototypes to get feedback. In general users understood the basic interactions and felt the designs were intuitive, especially since they matched expectations gathered from creating links in other programs. There were some who had issue knowing to use the right-click menu for link creation, however. Additionally, users wished they had more control over the visual treatment of various link states but overall deemed the solution we provided acceptable. We also heard users saying they would like to be able to create global styles for links so they would not need to update colors for each link individually. I had a feeling this would be the case, but I felt these concerns could be handled once our saved text styles feature was built. Because this feature would be released into a beta program, we would be able to gain even more insights as time when on, so we made some minor iterations based on the testing feedback and moved to development.

FUTURE CONSIDERATIONS

As mentioned, the text styles feature would add a lot of value and help streamline the inline text link creation and management process. It would also be beneficial for users if more control was given to non-resting link states. Additionally, I feel that the link creation trigger should exist outside of the right-click menu as a contextual tool in Studio's toolbar. Contextual tools and a reorganization of the toolbar is something I have been championing for some time, so hopefully that sees the light of day soon, as this would add a lot of value even outside of inline links.