In fact, URLization is an undefined word, but it’s commonly used in Social Web designing. A social website should have lots of features and how can we find and use them? There are two ways to process – one method is to always fetch them from database, the other way is via URLization.
Before talking about these two processes, I think I should introduce some of these in the Social Web. They come in many different types such as posts (Blogger), photos (Flickr), news stories (Digg), statuses (Twitter), profiles (Facebook), bookmarks (Delicious), entries (Wikipedia), etc.
Fetching objects from database can significantly improve a website user experience and security. Also, development will be much easier. For example, Facebook profiles can only be shown to friends, so these things can be easily be grabbed directly. As for Delicious, bookmarks are for specific people and friends and we can share via the social bookmarking website directly since bookmarks with URL is no meaning. This is because the contents of bookmarks are already in URLs – it isn’t in shortened TinyURL format.
On the other hand, URLization is quite different. For posts in Blogger, we can get the URL from our friends and read the content. Tweets with URLs can enable us to share (re-tweet) them if a user find the article/video/picture interesting. If you’re a Twitterer, you may notice that every status in Twitter has an ID, and we can access it directly unless the user protects it’s profile.
Actually, many Social Websites can’t do URLization that well at the beginning. However, only a few people know that and fortunately, I’m one of them. Let me tell you the story about Flickr described by team member Eric Constello:
Before URLs:
When we first launched Flickr, it was a Flash application that was mainly just a chat environment with real-time photo sharing. So it was quite limited in what you could do.
It wasn’t a photo sharing site, so much as it was a place where you could go to chat and talk about photos. But none of that activity was stored in any asynchronous way.
After URLs:
As we started adding features to the site itself, like pages that hosted the photos so that people could visit them at a unique URL, we had a lot more success with that. People responded to it, and the site began to grow.
Although I don’t know how Twitter first started but I can still guess that the world’s most popular microblogging platform don’t make use of URLization at the beginning as well since its core was posting updates via SMS.
So why do these websites start with fetching, then change to URL? I think the reason is that they intend to make them shareable and searchable. I believe that Wikipedia started with URLs as we can easily access the articles via Google Search results. Digg also need as there are too many information there, we need to have an address in every story so that we can vote easily. After changing to URL, the photos in Flickr can be shared is a simpler way with just a link. We can also search photos via Google. Since many users may write descriptions and URLization makes them effortless to find via Google Images as the core of image searching is webpages.
From this analysis, it tells us that we should implement some URLization on our own websites. However, I feel that URLization is against Rich Internet Application at present as RIA can’t transform everything to URL. It’s like online software instead of webpages. That’s not the problem with Social Web, that’s the problem of Search Engines.
Therefore, this topic gave us two questions, one is “How can Rich Internet Applications URLize?”, the second one will be “How can Search Engines find contents without URLs?”, they are all considerable for the future of Social Web.