wiki:NiceUrls
Last modified 4 years ago

Nice URLs in BW-Rox

An url is the string in your browser's address bar. BW-Rox (PlatformPT) uses RequestRouting to determine which page to build, given a request url.

It is benefitial for usability, if these URLs are human-readable, self-explaining, easy to remember, not too long, and reliable for permanent use in bookmarks.

General Guidelines and Arguments

Human language

Some usability guidelines to follow (would be cool to have a web source for that):

  • use english words or user-valued abbreviations, instead of machine-valued codes and numbers. If you use numbers, make it obvious what they mean.
    • a username is better than a user id
    • a language code is better than a language id
    • page numbers can go with a 'page' or 'p', like 'p5' or 'page5'
  • Sometimes you have to use numbers, because the human-language terms are not reliable. There are tricks to get around this..
    • In the forum, we (will) use urls like "forums/s62-questions-and-answers---a-game". The request router does only look at the "forums/s62", and doesn't care about the rest. For the human user, however, the "questions-and-answers---a-game" is more informative.

Meaningful URLs

  • define urls that reflect a model of the navigation structure, as seen by the user. For instance, pages which are under the same tab of the main menu, can share the first part of the request.
  • define urls that predict what's behind.
    • if it's a forum thread, you could include the thread title in the url. if it's a single post, evtl give the poster and the date?
    • if it's an image, you can include '.jpg' or '.gif' as a suffix, even if this is not necessary from a technical pov.

Spelling, special characters

  • be careful with special symbols
    • whitespace will be turned into '%20', which looks plain ugly, reduces readability, and makes the request longer. Better replace them by something else (like hyphens).
    • underscores can become invisible in some address bars, so they will look like whitespace. A solution can be to replace them by hyphens.
  • use lowercase - that's easier to type and to say.

Persistent, reliable URLs

  • try to redirect mistyped or old urls, either to the correct page, to a search page, or to the startpage (maybe with a message "... not found" ?).
    • 404s: for our own sake (we can get a fairly good idea of where things go wrong, as it's easier to log traffic to a 404 than to 5 million different old urls), for the sake of users (no matter what, you do not expect to get redirected when you type in a url - you expect a certain page to come up. And it's almost certainly not the front page) and for search engines (google does NOT like 301s - but it DOES like 404s).
    • 'avatar' and 'avatars' should be redirected to the same page.
  • one url should always mean the same, even 3 years later
  • ideally, one page should always be in the same url (otherwise, redirect)
  • for images, try to make different and meaningful filenames, even when they are in different folders already. When people store the file in their filesystem, all the folder information is lost, only the filename remains.
  • be careful with POST queries!! if you copy+paste to another browser, all the information is lost.

Nice URLs for images

With RequestRouting, the filename in the URL does not have to be identical with the filename of the image in the filesystem!!

  • different and meaningful filenames, even when the images are in different folders already. When people store the file in their filesystem, all the folder information is lost, only the filename remains.
  • you can include '.jpg' or '.gif' as a suffix, even if this is not necessary from a technical pov.
  • if the image is available in different resolutions, the image size can be included in the filename.

Consider what users might want to do with an url!

In 80% of all cases, they just click on a link and only subconsciously take notice of the url in the browser address bar. !NiceURLs are meant for the subconscious peace, and for those few cases where users DO care about the url:

  • copy and paste into another browser
  • retype it in another browser
  • dictate it on the phone
  • store it in a bookmark
  • modify a part of the string, to get to another page. -> this requires to understand the structure of the url
  • use raw urls in emails, wiki pages or forum posts.. Then the reader has to guess which url leads where.
  • store an image in the local filesystem -> only the filename remains, not the path.
  • look at the url in a search engine result -> better if the url looks promising!
  • look at a bunch of urls in a list (like the browser history), and try to make sense of them.

Discussion of Details

Items with ids

Often an url wants to point to an object such as a forum thread, a blog comment, a picture, etc, that can be identified by a unique id. What's the best format for a link to this item? 

bewelcome.org/forum/topics/22 // i would prefer this - but at this depth or not much lower
bewelcome.org/forum/topic-22   // looks better to me (lemon-head)

Hierarchic structures

Sometimes there is a parent item with a child. It can make sense to reflect that in the url. A question is if we should have the absolute comment id as found in the DB table, or a relative id that only counts the comments for this particular blog article? 

bewelcome.org/blogs/article-344/comment-7  // 7th comment for article 344
bewelcome.org/blogs/article-344/comment-1205  // 1205th comment of all bewelcome blogs.
// with absolute comment ids, we can omit the article id.
bewelcome.org/blogs/comment-1205

Refering to a parent id is tricky when the parent can change. For instance, what if a gallery picture is moved from one album to another?

  • Do we make a http redirect, so we get a valid combination of parent id and item id?
  • Or do we show the new location of the picture, ignoring the parent id?
  • Or do we show the old location, with a note saying "picture has moved to xxx" ?
  • Or do we totally forget about parent ids, and make urls that only point to the item itself? 
bewelcome.org/jeanyves/gallery/album-3/picture-28  // what if pic-28 is moved to album-4 ?
bewelcome.org/jeanyves/gallery/picture-28  // what if pic-28 changes the owner, or if the owner changes his/her username? (heaven forbid)

Items with id and name

Most items do not only have an id, but also a name. Some of these names can be considered almost permanent (usernames), others can be changed easily, and even worse, they can be language-dependent (forum topic titles, FAQ questions).

  • Permanent names (for instance, usernames) can be used instead of an id.
  • Non-permanent names (picture titles) should not be used to identify anything in the URL, but they can still be part of the url.
  • Some items can be given a permanent name in addition to the non-permanent title. (for instance, many CMSes allow to give such permanent short names to blog articles). 
bewelcome.org/members/jeanyves  // usernames are mostly permanent, so it's ok to have it in the url.
bewelcome.org/in/de  // language codes are mostly permanent (if we use an official list)
bewelcome.org/gallery/picture-44  // no information about the picture title
bewelcome.org/gallery/pic44-dancing-pandas  // picture title is added for convenience reasons
bewelcome.org/gallery/pic44-bogus-title  // picture will still be found even with the wrong title
bewelcome.org/gallery/pic44  // picture will still be found even without a title.

Hash URLs for AJAX

If we have some advanced ajax navigation, where we do not request complete new pages from the server, we can still reflect these "locations" in the url using hashes, to allow bookmarks/permalinks. 

bewelcome.org/jeanyves/gallery  // open jean-yves' gallery
bewelcome.org/jeanyves/gallery#picture-4  // after clicking on a picture

The js code to make this happen is 

showPicture(picture_id);
location.hash = "picture-"+picture_id;

Media/Files? (especially pictures)

Especially with pictures, it can often happen that people want to right-click and save. In this case, the last part of the url will typically become the filename of the stored picture.

  • In the user's filesystem, the picture will be swimming in one bucket with pictures from anywhere, so it will be enormously helpful to know that this one is grabbed from bw.
  • It's also interesting to know the owner of a picture. So, why not put it in the filename?
  • Another helpful info is the picture resolution. 
bewelcome.org/picturefiles/picture-55.jpg  // not much information.
bewelcome.org/picturefiles/bw-jeanyves-pic55.jpg  // tells about bewelcome and the owner's username
bewelcome.org/picturefiles/bwpic-55.jpg  // this is much shorter, and still gives a hint that the pic is from bw
bewelcome.org/picturefiles/pic55-thumb88x88.bw-jeanyves.jpg  // giving a lot of information, with the meta infos preceding the id and resolution.

Questions

  • Which infos should be first in the filename?
  • How much meta info is too much? How long can a filename be?
  • Is grabbing pictures really something we should support? - lemonhead thinks yes, because: (i) people will do it anyway. (ii) If I watch the pictures of my friends, then what's so bad about downloading? (iii) Some people might be on a slow connection, and downloading allows to view the pictures offline.

Legacy URLs

No matter how we optimize our URLs, there is one thing we should not forget: We can not change the URLs that people have stored in their bookmarks, or that were sent in a mail.

Therefore, we have to make sure that all the old URLs do still work. This can be:

  • Showing the intended page, no matter if the "modern URL" would look different.
  • Redirect to a modern URL, showing the intended page.
  • If the content does no longer exist (for instance, if a picture has been deleted), show some useful information about when, why and how this happened, and propose some alternatives.

Bottomline

Some of these guidelines are very clear, others need compromises and tradeoffs. In any case, it is useful to be aware of all arguments.