11

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).

mockup

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.

  • Why do you say that tooltips are not good idea as lists may be very long? – Alvaro Jan 27 '17 at 10:16
  • 2
    Because I need to walk through all items to find the one I'm looking for. – kav Jan 27 '17 at 10:19
  • 1
    Now I see what you mean: Some... Some... Some... is Something Somewhere Someone but the user can't know until the tooltip appears. – Alvaro Jan 27 '17 at 10:21
  • I see a lot of waste of "real state" in some of the columns. Parking, wifi, family room, Discount, and probably any other additional data maybe substituted by icons. And for your question, there's no easy way to abbreviate or truncate, depends on the data itself. If its a compound name you may show part of the first word, and part of the second word... or as mentioned in another answer, truncate in the middle. Anyway, truncating degrades UX. If the data is important, then show it complete and look for "real state" elsewhere. – roetnig Jan 30 '17 at 11:34
  • 1
    Tooltips should never contain mandatory information because the world is moving away from computers and mouse cursors. – DaveAlger Jan 31 '17 at 20:54

11 Answers 11

8
+50

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/

  • +1 because this approach is far superior to tooltips. I would even say if the most distinguishable information is likely to be at the end rather than the beginning of the string then show 5 characters ... 15 characters – DaveAlger Jan 31 '17 at 20:57
  • 1
    It seems like a hack to perform string logic in the UI like this. For example, "SomeBrandname Green Tea" or "SomeBrandname Organic Green Tea" would both result in "SomeBran... Tea". A cleaner way to do this is to separate brand name from product name on the server side. Then you'll have more flexibility with formatting in the UI. – Ben Harrison Feb 1 '17 at 17:46
  • I'm wondering if this answer got accepted because it was the easiest to implement in the OP's current project? Maybe a redesign of the grid would be too much? From a technical standpoint this isn't that bad, but from a usability perspective I think it is. If a usability goal is to not make the user think, then removing and replacing important data with an abbreviated, almost cryptic, version does exactly the opposite. The user MUST learn and figure out what these namespace-looking strings of text mean and translate them into plain English. – Ben Harrison Feb 2 '17 at 20:44
  • @BenHarrison I agree and it would also be my recommendation that a UI redesign should always be considered before truncating. But the OP's question was clearly about truncating and not a redesign like some of the other answers suggested. – Phaze Phusion Feb 2 '17 at 21:34
  • If you know most of the long brand names beforehand (so there are for example 10 brands) you could replace the brand-name part with a logo. So Instead of Super Yin Yang Tea bags just ☯ Tea bags – Falco Feb 7 '17 at 15:04
7

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)

  • Like the idea about breaking the name in half - the start may not differ, but the end usually does. – Jason Cemra Jan 30 '17 at 1:40
  • I would upvote for the “other approaches” if I didn’t disagree that much with the first sentence. – Crissov Feb 1 '17 at 21:49
  • @Crissov I'm curious, if the name needs to be truncated, how would you show it with full length if it is not with a tooltip that triggers either on hover or when clicking a button/icon? – Alvaro Feb 1 '17 at 21:52
  • A tool tip would be a last resort. That does not make it a “good idea”. Usually I’d prefer line breaks (possibly restricted to active/focused rows). – Crissov Feb 1 '17 at 21:56
  • @Crissov I see what you mean, I should rephrase that. Thanks for the comment. – Alvaro Feb 1 '17 at 21:57
6

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.

Revised table

  • 1
    Depending on how the data is used, you might consider adding an expand/collapse concept to this and only show the "Cost/opening hours/parking/..." section after they expand the row. Certainly an expand all/collapse all would be essential for this design as well. (This would be a trade off between gaining screen real estate and reducing clutter VS reducing scannability and ease of comparison between rows...) – maxathousand Jan 30 '17 at 18:52
6

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: enter image description here

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

  • I'm going to make a similar suggestion - almost didn't, as my thoughts are so close, but I think it's different enough. I can't fit the differences in a single comment, anyway. I'll try to give credit, though! – Adrian Long Feb 1 '17 at 16:53
  • This answer is better than the accepted answer. If important data doesn't fit inside your grid, then re-evaluating your grid design and the priority of the data that goes in it is a much better approach, for the sake of usability, than truncating data. – Ben Harrison Feb 2 '17 at 20:19
3

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

2

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.

  • 2
    Seriously ? Using cards for a moderate amount of data is plainly useless and degrades UX. – roetnig Jan 30 '17 at 11:22
  • @roetnig It was just a suggestion, and I did state that if you have lots of records you will need to create additional search & browse features. – SteveD Jan 30 '17 at 11:28
1

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.
1

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.

1

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!

1

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

mockup of a decompressed table

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.

  • The only change I would add in your wireframe is to place "per night" below the label "Cost" instead of displaying it on all prices. – Joao Carvalho Feb 6 '17 at 10:02
  • I put it in the field rather than the header for flexibility - in the header it forces costs to always be listed per-night, which may not always be appropriate. eg. many holiday lets are priced per week, rather than per night, and I've encountered several timeshares priced the same way. Without knowing more of the context, I tried to cover alternatives which may well not be needed here, on the understanding that if they aren't required, it's easy enough to make the change you're suggesting. I should have called that out explicitly, though, so thanks for the reminder! – Adrian Long Feb 16 '17 at 12:56
  • Even if there are cases where prices are listed per week, the use of a common measurement unit (per night) helps the user compare all listings equally. I'm thinking if he just focus is attention on the Cost column and scrolls up/down the table to compare all the values quickly. Having variations p/week and p/day can get confusing – Joao Carvalho Feb 16 '17 at 13:37
  • Generally, I agree, but presenting something as priced per day, when it's not available on a per day basis would be unwise. Like I say, I was trying to present flexibility in a mockup to cover different bases. Largely because the use-case has been left deliberately vague in the original question, rather than saying I think it's the right call. Fundamentally, I agree with you - but I can also see cases where what's probably the correct approach (single unit) could be utterly the wrong one (when that single unit is the wrong one). I'll add a note to the answer that effect. – Adrian Long Feb 17 '17 at 17:10
1

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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.