One normal way to serve a list of items in a web app is like this:


Where the clients part of the url, renders a list of all clients

In previous apps clients had simple ids, that looked OK when you wanted to see more details, like:


But now, I have an app where the internal ids looks like this:


and well... that was the drop that spilled the cup. What should I do to provide user friendly ids?

One option could be generating an alias for each client:




But although the name is not likely to change, the address is a whole different story.

The ugly UID is mandatory, cannot be changed. I could only imagine requesting the software to maintain a secondary ID for permalinks. Should that be the best solution?

I could go back to the beginning, just simple numbers. I still do not like having something that is not human friendly, but it seems that any unique everlasting permalink cannot look nicer.

  • I don't see why you would want readable urls? Is the user going to interact with the urls? I normally associate human friendly urls with short urls so it can be easily included in a message. Commented Feb 5, 2014 at 12:55
  • I'd say I personally associate them with either short urls or urls that are easy to remember... :) Commented Feb 5, 2014 at 13:03
  • 1
    Readable urls are great if you must send them to coworkers, or take notes outside the app. Commented Feb 5, 2014 at 13:28
  • 3
    Just do it like the SE network does: /clients/82/john-smith the name is superfluous and can be left off just like http://ux.stackexchange.com/questions/51673 and http://ux.stackexchange.com/questions/51673/user-and-url-friendly-object-ids will both take you to this question. Commented Feb 5, 2014 at 13:33
  • 5
    @Paul: URLs are for People, not for Computers
    – JonW
    Commented Feb 5, 2014 at 14:10

3 Answers 3


If you are storing unique 'usernames' in your system then why don't you make use of these to generate a permalink to the user's page like Facebook, LinkedIn, Twitter and other big players do?


This way the responsibility will lie with the user to choose a unique username and you need not worry about duplicate names.


At work we use a ruby gem for generating "slugs" (permalinks): friendly_id. The gem takes an ordered list of god ways to uniquely identify a user.

For a user those candidates could be name, age, address, zip etc, and then when one adds a new user one checks if there's already a user with that name registered if so one ads the next thing in the list to the slug , in this case age and so on until you have a unique string (and then that's saved to the db).

One use case (for me) where this kind of urls beats random strings is when you're trying to get back to a page and the only unique thing you remember is the for example the name then when you enter that into chrome's "omni box" (urlbar) it searches your history/bookmarks for a matching url.

There's a good example on the friendly_id website (the second bullet point after this heading) (if you're a little familiar with ruby)


I'd say you're either going to want a user friendly "nickname" or something stored along with the information, or do nothing.

As Paul says in one of the comments above; how often are users likely to manually type in the URL? They may go to http://example.com/clients, and then find the user they want there. At this point, if they visit the URL often, I'd say they're more likely to bookmark it than type that URL in each time.

  • 1
    They might not type them in, but they sure will read them. URLs are part of the UI, so why would you not want them to be user-friendly? Assuming 'oh, nobody looks at that thing' is a dangerous idea. nngroup.com/articles/url-as-ui
    – JonW
    Commented Feb 5, 2014 at 14:14
  • I never suggested they weren't going to look at it. My comments were based more on the fact that it sounded like this is for a secondary level (that is, the screen after the clients list), where people are unlikely to manually enter a URL to get to. I'm all for friendly URLs, but as a developer, I was also thinking along a more pragmatic approach of "is a user likely to need this in the UI?"
    – Joe
    Commented Feb 5, 2014 at 14:41
  • @Joeb454 but it's a rather trivial thing to fix on the dev side in the grand scheme of things. For example, the URL could simply use an integer from an incremented record count column rather than the full GUID. It'd still be unique.
    – DA01
    Commented Mar 12, 2014 at 4:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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