or ultra-sloppy URLs
or can your CMS handle this?
I’ve always been interested in the design of infrastructure as much as the design of finished things. On the Internet, I’m fascinated by RSS interaction design – there’s a long way to go, and yet it’s a topic that is rarely mentioned. Another thing I’m interested in is URLs.
Recently, URLs have gone to hell. Content systems mean that uber-long URLs are the norm, full of codes and identifiers not meant for human consumption. No-one knows if copying and pasting a URL will work, now or in the future. URLs are not neccessarily sendable, quotable or sharable. Even Amazon are starting to break their URL conventions of the last 8 years. It’s painful.
I want to take back the humble URL, and at the same time make information more useful. Guessable, functional, glancable, rememberable, usable, useful.
Some websites have tried to hack their way out of the CMS URL shambles – going to http://www.nokia.com/N70 does something, for example. However, many don’t – does http://www.yahoo.com/weather go to where you expect? If http://www.google.com/maps does, why doesn’t http://www.google.com/map ?
I say – scrap the CMS. Make it more malliable, and the URLs will follow. The Internet isn’t about pages, it’s about data, or information, or even just one current view on all this information.
Let’s say you’re a company with lots of kinds of information. Let’s say I’m someone trying to find out the weather for tomorrow.
I could go to http://www.example.com and navigate from there. This is what most sites are designed for.
Hopefully I could get a head start and go to http://example.com/weather. I still have to specify where and when.
What about http://example.com/weather/tomorrow ? Or http://example.com/weather/berlin ? Or even http://example.com/weather/berlin/tomorrow ?
For each type of information you’re trying to gather enough context to show something salient. This is likely to be different for each data blob, but there are some basic fundamentals that boil down to set and setting – constructing a context.
Within weather, we need place, timeframe, and type of display – observations, forecasts, maps, photos. What can we get for free? We can make some intelligent assumptions, that the user can challenge and change.
Let’s assume people want now and next, maybe a map (if you can’t agree on an assumption, it’s easily user tested). Place is harder. If it’s a situated site, maybe just serving one country, or even a town, you’re set. Otherwise, you can hopefully get a base assumption from somewhere else – maybe a user profile, or a geo-lookup of an IP address (on a mobile, we may have country information from the mobile number or operator, or if completely lucky, from a GPS or other location finding technique). A little bit of tech can go a long way. You’ll also need a good lookup db, matching names to places.
The important thing is that from now on the user chooses. Make it easy to manipulate time, place, and access to other views and other kinds of information. Show the working – make sure the URLs are simple and exposed (and preferably kept in the same kind of order as the URL they arrived on). Sites like delicious (congrats, btw, joshua and yahoo) even incorporate it into the UI – maybe a touch too far for some, but it’s teaching people to be power users.
Throw an /rss on the end, and get a feed. Heck, throw /mp3 on the end and get it read to you. Figure out activity, then context, then output mechanism.
Will people hack URLs? Some will – more if it’s easy. But the URL is just the tip of the iceberg of a nimble people-centered information display system, based around tasks and exploration to find answers. It should feel like a good adventure game, not flipping channels through all the ads on a tv.
I wrote a bit about the mess that is Amazon’s URLs a while ago. I too would like to see arcane, implementation-based URLs disappear in favor of informative and navigable schemes.
— Daniel J. Wilson 13.12.05 #
Word up!
We’re using human readable (spoken) urls in our open source cms; umbraco. So the url follows the path and structure in the cms. We even have an option of skipping those lame aspx file-extensions.
We also provide an open achitecture, so you can extend the way urls should work (like the great mp3 or rss sample you provide above).
A good sample of this is our blog extension providing urls like yours (with date stamp in the url).
Another site effect of this, is that it helps people organizing their content in the cms. They know that the urls follow the structure, thus encouraging them to think about structure.
We also provide support for short-cut urls if a page is deep in the structure (as in /get-support in stead of /products/help/get-support).
There’s really no excuse for not doing this – but often a good sample on bloated cms solutions thought by developers who doesn’t really use or understands the way the net works :-O
Cheers,
Niels…
Some thoughts on abstraction (and its effects on URLs) here
— Trevor F. Smith 13.12.05 #
I’d recommend looking at the work of Netmesh’s LID. We’re using it to create a digital ID platform centred around URLs…so any part of a user’s persona can be referenced and remixed through explicit URLs.
I think you present some interesting ideas here, but the problem is that most users won’t think to change the URL to get places in a website. Since it’s inception, the convention on the internet is that you click on a link to go somewhere. I think you need to focus on site navigation for getting places rather than URL strings.
Note that I do agree that URLs should be copy/paste-able, though.
contact
email:
chris is at anti-mega.com
MSN:
chris_heathcote is at hotmail.com
IRC:
ChrisDodo
iChat/AIM:
antimega77