UI Patterns: What's in a (User)Name?

Originally published at: http://www.sitepoint.com/ui-patterns-whats-username/

When learning to design for the web, there are two lessons that I hold very dear and important.

The first one is – Everything is a rectangle

It helps to think of everything as rectangles. Take any web page and you can instantly visualize the grid, if you can blur out the content and look for rectangles. This principle has helped me understand and design for the web better.

The other principle warrants some discussion first.

Name-in-app-bar pattern

Displaying a username on the app bar in either web and mobile apps, is a common and interesting problem to analyze. The physical dimensions of the screen dictates that the username portion has a finite amount of space it can occupy. The problem is obviously accentuated in devices of smaller sizes.

We also know that usernames — possibly more than any other data type — can vary the most wildly. From

There are a variety of solutions for this problem.


I chose Facebook as an example for this, because the usernames are a central component of this app. I wouldn't know the last names of a lot of my friends had it not been for Facebook. For an app that was built on the idea of using your full name, it is quite interesting that it only displays the user's first name on the app-bar.

The intention could be personalization. Calling someone by the first name makes the communication more personal. It is also a convenience because that space might not be practical for longer usernames.

Here's how Facebook handles this design problem:

  • They display first names only on desktop home screen, which is odd
  • They don’t display usernames on mobile home screen, but do display full username in the settings screen
  • The can display a fairly long first name on desktop (24 characters, 175 max-width on my 1366px screen)


My immediate thought when it comes to truncating usernames was, where else is the username so important that it can't be truncated? Publishing, of course.

All articles are works of an author and their names are as important as the content itself. It is core to the application and I went on to investigate how a fairly popular publishing medium (wink) would handle this scenario.

As it turns out, medium handles this in a pretty interesting manner.

  • The top right on the app bar does not use the usernames at all. Just the avatar. This is what you would notice if you were reading content.
  • But, while writing an article, the avatar is displayed twice in the app bar. In the left, it also includes the username.
  • Usernames here are given ample space and can be insanely long
  • On smaller screens, username is given priority and the rest of the menu items get kicked down


I also took a look at OneDrive because they handle this in a pleasantly surprising fashion. Not only does it display the full user name, but it handles multiple use cases really well.

One drive facilitates the full user name on long screens. As it is, the names can be really long and have a lot of space.

On mobile, the entire app bar becomes minimal including logo and menu options.

One Drive's mobile banner

But the surprise was when I deliberately made the username super long just to see what happens. It cleverly responds by hiding the menu options to make room for the username.

Important menu choices like create and upload are hidden behind ellipses and space is made to accommodate a super long username. While this is an edge case and I am thrilled by the solution, I can't help nitpicking on why this decision was made.

Continue reading this article on SitePoint

Great post, Vinay.

It’s really an interesting how unexpected variations of content can really break a design.

Another favourite of mine is how really wide or really tall images break lightboxes (see: Facebook).

We have responsive designs for different viewports, but I’m not sure if there are any real responsive design patterns for different content?

Super long words, multi line headlines, extreme image ratios, multiple nestings (think super long comment threads indented by each reply to a point where the comment is no longer readable), counters… all things that help break the careful pixel perfect designs of web products…

@inkovic Thank you. And well said. Working with dummy text in any of the cases you mentioned is bad. I reviewed a few websites for this post. Publications like NYTimes, Fastcompany have really embraced the ideology. You can see how the design does not pose restrictions on how long a headline can be. It will just accommodate it.

Multi level nested comments are very interesting use cases.

Regarding images, that is a whole new discussion. There just isn’t any correct way of doing it. All solutions we have right now are okay but I think it’s still getting there.