Ever since the beginnings of the Internet, its key enabling feature has been the ability to store and display hyperlinks, which are strings of text characters that point to resources stored somewhere else in a server on the public World Wide Web, a private intranet or extranet, or even in your own current device (personal computer, PDA, mobile phone, or whatever).
Such resources are commonly other pages, but of course they can be much more than simple pages: things like executable programs, zipped files, audio-visual files (such as Flash or MP3 files), e-mail addresses, or indeed anything that can be stored and then retrieved (with or without being secured via username/password or other means).
To be pedantic, such a character strings are properly called Uniform Resource Identifiers (URIs). Each URI may be a Uniform Resource Locator (URL) or a Uniform Resource Name (URN), or both, as explained here on Wikipedia.
My personal view is that when you're creating content (web pages, e-mails, or whatever) it's a sort of criminal negligence -- a sin of omission, if you will -- to create regularly refer to web resources by plain text. For example, you'll notice that nearly every one of my resource references on iTWire pages are live links (with pop-up tool tips to boot), and I do the same when I'm creating e-mail messages.
You should make it dead easy for the readers of your web pages or e-mail messages to simply click on live links and not force them to access the resources by some indirect method (such as having to copy-and-paste the URL string).
In particular, I see so many e-mail messages referring to web sites URLs via
plain text strings and with the author's signature at the bottom with an e-mail
address composed of plain text instead of a live link of the form
(probably because many people don't even realize there's a "mailto:" option they
should always use).
One of the banes of the web surfer's existence is the often complex or lengthy character strings that make up URLs on far too many web sites.
It is all too common for URLs to be stored in web pages as plain text rather than as live hyperlinks. It can be a real nuisance to have to type them into a browser's address bar if you have to do it more than a very few times. It's bearable if you only have to do it occasionally, but even then only when the string is short, say, not more than twenty characters or so.
It's very bad practice, and a negative aspect of far too many web sites, to have URLs that are too cryptic, too long, or both. Far too many web designers and developers regularly build URL structures that are not user-friendly.
In some cases, this is not so much their fault but rather due to the middleware infrastructure (web server, database manager, etc) that they use to build their sites. You know what I mean: every now and then you come across a URL that seems to go on forever, way beyond the end of the address bar window, and one which is so complex that you'd never be able to manually key it in even if your life depended on it.
The issue boils down to this. If the URL is longer than 15 characters or so, what's the best way to handle it in the web page that you're posting or the e-mail message that you're going to send off?
PLEASE READ ON...
This is where URL-shortening services come in to play. These allow you to specify a short URL (within our golden rule of being no more that 15 characters or so). This short URL then automatically redirects to the desired long URL. There are many URL-shortening services -- possibly the most famous being TinyURL -- and they're very popular, generally with advantages that outweigh the relatively few disadvantages.
For example, you probably wouldn't bother using TinyURL to refer to the iTWire home page "itwire.com" which converts to "tinyurl.com/6aedc7" and is no saving at all. The only reason you'd do it this way is if you had a style guide policy of referencing each and every resource via its TinyURL shortcut.
But using the TinyURL approach does comes in handy for referencing my iTWire blogging section "itwire.com/content/blogsection/47/1135/" as "tinyurl.com/5fw5mf"
Note that all the examples deliberate omitting the "https://" prefix. This is favoured by web journalists, since it looks neater and saves valuable screen space in print (even though not a precise rendering of the full URLs).
As of August 2008, there's a new player in the field, and it may be setting a scorching pace. It's called bit.ly (the appendage "ly" looks cute, and indicates it's a Libyan domain registration).
It does the same as the others, for example yielding the NASA shuttle and rocket launch schedules site "www.nasa.gov/missions/highlights/schedule.html" as "bit.ly/Flayz"
It goes a bit further, allowing you to try entering (optionally) a preferred keyword string. So when I entered "NASA_schedule" it gave me the friendlier short URL "bit.ly/NASA_schedule" (which may not be quite as short, but certainly gives more sense of meaning to the short URL).
However there's a lot more to bit.ly than this.
PLEASE READ ON...
They already go a fair bit further with bit.ly than merely shortening URLs.
Their introduction of the service here mentions some of the points: remember the last 15 short URLs you created, click/referrer tracking of the bit.ly short URL, an API for creating short URLs from your web page, thumbnail images, automatic free mirroring of each of your web pages if they're visited via bit.ly (saved on Amazon's S3 storage, apparently, which should make this a reliable offering).
Promisingly, they seem to have plans to actively keep beefing up the bit.ly features. A really nice feature, introduced only a week ago (late August 2008), is the bit.ly bookmarklet for Firefox.
You open the bit.ly page inside a Firefox window, and locate the bookmarklet as shown by the red arrow below:
Simply drag the link to your Firefox bookmarklet bar (the wording "to you browser toolbar" is s little ambiguous), then open a web page in the Firefox tab, and click on the bit.ly bookmarklet (circled in green below), like this:
Then, a moment later, the shortened URL appears in the very same Firefox tab:
Easy, eh? There's no similar add-on for Internet Explorer yet (and maybe, ever) -- Nor the new Google Chrome, naturally enough... That's another pat on the back for Firefox's extensibility!
I haven't been using TinyURL so far, and in light of bit.ly turning up on the scene reckon that I'd rather use it. Take a look, perhaps you will too.
some fun with a challenge or two that I've devised for you!