When designing a feature or product, User Experience (UX) designers undertake extensive user research to create the best user experiences possible. However, users can be unpredictable and there are guaranteed to be some edge cases we haven’t accounted for.
An edge case is a problem or situation that occurs only at an extreme operating parameter. In the world of software, there are two main types of edge cases: one is a backend edge case, which can be related to things like database capacity or performance throttling. The other type is a frontend (user-facing) edge case, which relates to user needs.
In this article, I’ll examine ways to address one the most common front-end edge cases I’ve encountered: how to handle long text.
‘Long text’ refers to textual elements that users can customize within the application. In our product, Tasktop Integration Hub, an example of long text would be the name our users give to an integration. Unlike labels, which I can shorten or provide a tooltip for, long text is completely up to the customer to set.
When I design a screen in my design tool, I usually design for a textbox with an ideal length, but often fail to anticipate that the amount of text users provide can be quite different from what we expect.
To solve this problem, there are mainly two paths to follow:
Prevent long text from occurring: this is one of the most common ways to solve the problem, and it has been adopted by many websites and apps. In this solution, we simply limit the number of words users can enter within a text box. This method requires enough user research to be able to set a reasonable limit. You need to know that users will be unhappy with a 100 word limit, when they would typically need 200.
Allow long text and provide solutions when it occurs: In some situations, we must give users the freedom to enter as much text they want – such as when they’re writing a blog. There are two key ways to solve this:
Add another field or split the fields into multiple fields. A publishing site like Medium allows users to use as many words as they want for the main content. However, to display a list of blogs with a preview of their content, writers are also provided with another input field for a summary of their article, which is limited.
Instead of asking users to limit text in one field, the tool offers them another field to provide a shorter input.
In our product, Tasktop Integration Hub, we provide one “Name” input for users to describe the configured integration element, but have found that users often exceed the character limitation on this field. We solved it by by providing an additional “Description” field, where users can enter a much longer description about their configuration.
Truncate the long text and provide a hover tooltip. An example of this solution can be found in Google, where search results are truncated with “…” at the end. Depending on the type of content, sometimes you will see other solutions that truncate text in the middle, such as long names of documents on MacOS, when viewed within a folder.Which part of the text to keep? That depends on which part of the text makes more sense and can be distinguished from other parts of the text. In our product, we truncate differently based on what information is presented. For a descriptive label like the name of a collection, which is entered by a user, we truncate the text at the end. For artifact names that are directly retrieved via API from the external tool and are not controlled by users in the product, we truncate the text in the middle, since the identifier is usually found at the beginning and end of the phrase. Users can hover over both types of truncated text to see a tooltip showing the whole text.