Best practice for truncating similar titles in data grid?

Question

I have the following table, where the names are truncated up to 14 characters, because there's no enough room for the table itself (in real world there are some more columns).

^{download bmml source – Wireframes created with Balsamiq Mockups}

But... there's a case where that list may consist from very similar names (and may be very long), and as you can see, the users don't know what's the actual name behind each entry.

I was thinking about the following UX patterns:

• Adding tooltips - it's not good idea as lists may be very long
• Fixture position of furst column and add a horizontal scroll for other columns?

Please note that columns are illustrative, but I can't exclude any column(s) to get some space.

Answer 1

Truncate the titles so that meaning can be derived from both ends.

Use case:

• SomeBrandname Chocolate
• SomeBrandname Bread
• SomeBrandname Tea

Split it 8:6 (total length is still 14)

Truncated becomes:

• SomeBran...colate
• SomeBran... Bread
• SomeBran...me Tea

Split it 8:5 with additional logic

The logic:

• part 1 is the first 8 characters
• If longer than 8 characters add part 2
• part 2 is the first 5 characters counted from the last index of a space (or dash)

Truncated becomes:

• SomeBran... Chocol...
• SomeBran... Bread
• SomeBran... Tea

---

Update

It would be better if the Brandname could be separate, but even then important information can go missing. Example:

• Organic Green Tea Leaves
• Organic Chamomile Tea Bags

With complicated server-side logic the titles can be truncated to save a bit of the unique parts. If we keep to a 16 chararcter limit the example could become something like:

• Org.Gre.Tea Leav
• Org.Cha.Tea Bags

But even then: Is the second one "Chai" or "Chamomile" tea?

Trancation leads to information loss

Questions to ask yourself:

1. How much information loss is acceptable?
2. What's the impact caused by any amount of information loss?
3. When creating the data can it be structured so that the system can easily truncate it in such way that the information loss is kept to a minimum?

---

Just looking at the examples above, it's clear that truncation can lead to confusion. Nonetheless, in the spirit of truncation, here are 3 prototypes https://jsfiddle.net/phaze_phusion/vwdb72f3/

Answer 2

Some approaches to truncate a long text could be:

• Use two lines, where necessary.
• Use the ellipsis in the middle of the name, or in the less significant part.
• Use two ellipsis, one at the beginning and another at the end.
• Reduce the font-size. While keeping the text legible, you could reduce the font-size so a few more characters can fit.

I would discourage about using a horizontal scrollbar inside the fields or columns.

To display the full text you could make use of a tooltip that displays on hover in desktop devices or on tap in touch devices. You could make use also of an icon or similar to be interacted on click/tap. (This other question might be relevant)

Answer 3

Is it possible to change your table design? Here's a rough idea of what I'm suggesting, the colours, headings and backgrounds need more thought if implemented.

Answer 4

personally, I don't like truncated table, not as a Product Manager nor as a user since it contradicts the meaning of table. A table should present complete data and not part of it. I don't need to hover on each field to see the entire content. Moreover, I can't copy paste text from the tooltip.

this is what I would do:

Combine Brand name and address to one column. you can play with colors, font sizes, line spacing and etc.. this will add a lot of space to the table since those columns are the long ones. moreover, I think it is better to combine this information together for a better reading flow and scanning.

second, all the columns with checkbox- it's boolean, so I would use the icon with two different colors- one if true and one if false (as in parking icon

As for location, I guessed it is relative, so here you can either specify the distance or the text with/without a specific color to each state. another option is to have only the icon with a tooltip to understand what the color is for.

as for the titles - they can be broken into two lines or play with font size

Answer 5

Option 1: Allow user to select columns he wants to see, so that we create space for Name
Option 2: Resizable columns

Answer 6

Truncating words degrades the user experience - it makes the user work harder to figure out what it really means.

So how about not using a tabular table?

For example, you could use a card-based design instead, but this will depend on how many records your are showing in the table.

https://www.smashingmagazine.com/2016/10/designing-card-based-user-interfaces/

Cards organise information into chunks of content, and users appreciate chunked content because it aids for scannability: it helps avoid walls of text, which can appear intimidating or time-consuming and allows users to dive deep into their interests quicker. Cards divide content into meaningful sections, similar to the way text paragraphs group sentences into distinct sections. They can gather various pieces of information to form one coherent piece of content.

The advantage of a card is there is much more space for the name and the content, which means you probably do not need to truncate it. It allows you to organise the content a little better than you could in a tabular table.

You could even add a photo to make it much richer (if you want), and it will port to mobile much easier in the future (assuming you might want to do this).

If you have lots of records you could still use a card-based design, however you will need to provide additional Search & Browse mechanisms to make it easy for the user to find the card(s) they are interested in, e.g. Faceted Navigation.

http://alistapart.com/article/design-patterns-faceted-navigation

Also called guided navigation and faceted search, the faceted navigation model leverages metadata fields and values to provide users with visible options for clarifying and refining queries. Faceted navigation is arguably the most significant search innovation of the past decade. It features an integrated, incremental search and browse experience that lets users begin with a classic keyword search and then scan a list of results. It also serves up a custom map (usually to the left of results) that provides insights into the content and its organisation and offers a variety of useful next steps. That’s where faceted navigation proves its power. In keeping with the principles of progressive disclosure and incremental construction, users can formulate the equivalent of a sophisticated Boolean query by taking a series of small, simple steps. Faceted navigation addresses the universal need to narrow. Consequently, this pattern has become nearly ubiquitous in e-commerce, given the availability of structured metadata and the clear business value of improving product findability. Faceted navigation is being deployed rapidly across an impressively wide variety of contexts and platforms. In the world of search, faceted navigation is everywhere.

Some of the columns in your table become the facets that allow you to filter the cards in to a more manageable set, e.g. Parking, Wi-Fi, Family Room, Locations and Discount.

Answer 7

I would do the following:

1. Leave as tubular table since it helps to compare data vertically and horizontally between each entry, instead of using cards.
2. Combine Parking + Family Room + Wifi on one column called "Extras" and use an icon for each of those extra instead of the checkmark. A tooltip would appear on each of those icons to explain what's the meaning. This way to get more space for the columns that require more length.

Answer 8

IMHO your question is more broad; what you're really asking is "How do I get the user to find easily the information they want"? Here are my suggestions.

The user should be able to resize the columns' width. If a string is not fully visible when the columns' width is too small, the string should be ellipsized in the middle, as already suggested.

In addition, you should also add a filter textfield where the user can enter search terms; all the rows not matching the filter are hidden from the user's view.
You can make the textfield filter only the first column, or all of them. You might also choose to have a different textfield filter for each column, if columns contain similar data; this really depends on your application.

Another good idea would be to have the table sortable by column.

Answer 9

Keep it in the tabular form but you can combine the brand name, address and opening hours as it will give you more space to expand horizontally & you can show the data without truncating. just differentiate brand name, address & opening hours by font styling. instead of writing excellent or bad use icon which will save more space.

Thank you!

Answer 10

My response is very similar to noadavi's - Here's a mockup, which I'll follow by explaining the differences.

Notes

I've not applied any colour, as I don't want to convey information with it for accessibility reasons. Colour could easily be added, but it should be purely for visual interest, not as part of the message being conveyed.

I've included the brandname and address into two lines in the same cell, much as noadavi has. That provides more width, and they're effectively two parts of the same information from a user perspective - if a human being was looking for a place, they'd probably treat the name of the place as the first line of the address! (An assumption, of course, so worth checking with some research)

Variations to noadavi's approach:

• I've tweaked the presentation of cost to make it a narrower column
• I've kept the columns for parking, wifi, family room, but rather than using checkboxes, I'm using an icon to display the presence of those properties. The icons are aligned in columns, and with good alt-text they could convey similar meaning - I'm just using them instead of the checked version of your checkboxes, with a blank space instead of the unchecked versions.
• I've made the column header for those icon columns span those columns. The icons each convey the meaning of their column well enough.
• I've moved "good location" into the details... but I'm not 100% sure what's actually intended by it. Nobody is going to want to advertise "bad location", so I'd think hard about who's going to be benefit from that bit of info, and if it's going to be a reason people object to their data being present!

So, all of the data is there (except "discount" - I forgot it and don't have time to add it. It'd be another "detail") and it's in the same columns, but presented in a much more condensed way.

Noadavi also added a distance to the location column, which, if it's what "location" being good or bad is about (as opposed to "it's near a loud place" or "it's in an amazing setting") could be replicated here if the location column is put as the last of those icon columns. If it's the other kind of thing, those could also be broken out to icons for "quiet place" or "pretty place" - essentially a visual "tags" column.

Added 17/02/2017, following comments

Prompted by comments from Joao Carvalho below, I should clarify my reasons for moving "per night" out of the cost column header and into the data cells themselves. I have two such reasons for doing this.

1. Column width - "per night" in the header forces the column to be much wider, and reducing width was the original goal of the question
2. It adds flexibility to the design, in that it caters for accomodation which is available on a basis other than per-night. As an example, timeshares and holiday lets are often only available on a weekly basis and price scale - offering a daily rate for such things is counter-intuitive for somebody trying to book a short stay based on a daily rate.

But there is a trade-off. There are very strong reasons not to do it.

1. It adds an extra step of interpretation and translation which the user must go through to be able to make a comparison between rows.
2. If adds flexibility to the design, which means it makes it easier to misread, misinterpret or otherwise just plain confuse.

On balance, I would agree with Joao about the common time unit being better in most cases... but it doesn't help as much with compressing the width of the table and it risks user frustration if a per-night price is being offered when per-night accomodation is not an available option for that place.

If places are offered on different timescales, I would expect to see more done to make those timescales visually distinct from each other than I have shown here, but that distinction would be needed.

Answer 11

Another approach is to use a Longest Common Subsequence algorithm between adjacent items. Then if the text is too long, remove some of the subsequence (if you can).

For example

SomeBrandWidget -> S...Widget
SomeBrandGizmo  -> S...Gizmo
ACMEWidget      -> ACMEWi...