Why you should never truncate in UI
I make very hard-line rules with my design team and expect them to have a very good argument for breaking them—and then we probably re-assess the entire rule. This is to protect our users, from our egos. Or our whims. (Btw, we’re hiring, if this sounds fun!)
I’ve become well-known for some of them among our wider Product-Engineering team: especially some of the more seemingly “draconian” rules. I get a lot of flack for them (I believe it’s in jest). One of those rules is this: Respect our users’ content. Do not truncate words they type in.
This didn’t go down so well when I first started expressing it. At Vend, we’re always trying to cram in as much information as possible on very small screens to describe transactions that are sometimes very complex. It’s a tough problem. And it means we had developed a bad habit (my view) of truncating text, like Product, Customer or even our Retailer names in our UI. To fit more line items on the Sell screen, we’d truncate the Product names to one line. To make sure our “top bar” looked nice, we truncated the Retailer name. To make sure our Customer badges looked nice in tables (and didn’t throw the row sizes out of whack) we truncated the Customer names. I hated this. I campaigned strongly against it, and very slowly we’ve been eradicating truncation in Vend.
We’ve had to become smarter about how we go about solving problems like:
- How do we get more line items to be visible at once on the Sell screen so retailers have to resort to scrolling less for longer transactions?
The answer is that we introduce complexity (more information) only when it becomes pertinent. Everything on screen has value, and is needed there. Otherwise, hide it. It means we scroll less important line items (like Tax and Sub-total) off-screen before we scroll line items like Products off-screen. It means we don’t display blank rows for Discounts or Notes until they’ve been added to the sale. - How do we deal with long strings in tables what create big awkward holes in the columns?
Tables are only one way to bring structure to information. We’ve developed a system where we combine tables (which are rigid), with ID badges (which are more flexible) to get the best of both worlds. - How do we make sure long Retailer names don’t make our top bar look ugly?
We get over ourselves. An “always pretty” top bar is less important than one which gives all the necessary information to our users. If Retailers realise they have extraneous information in strings that they create, then they’ll change those strings if they bother them. Let’s assume that what people type is important.
Our design team agree—they defend our users’ content with vigour. Our developer teams are starting to agree, I think. They still mock me about it, but I think they agree. And I think they do because we recently posted an article on Medium about how we’re hiring. PS: We’re hiring.
And then this happened.
One of our Lead Engineers, Ben Anderson, pointed out to our Chief Engineering Officer, another Ben, Ben Gracewood, (who had a lot of Medium bio-line updating to do, okay!), that his bio line sometimes gets truncated, and it’s weird: “Recovering Manager” becomes “Recovering Man”.
So he fixed it. But not quite.
On mobile, Medium decides to do some more truncating. Which led to Ben Gracewood unwittingly claiming that he was “Co-creator of Sep 11”. That’s awkward.
I am always telling everyone about truncation. And this is why.
PS. Vend is hiring Product Designers. And Engineers. And Product Managers. And Data Scientists.
