TinyURL and Disambiguation Pages Should Become Web Standards

There are two pieces of the web infrastructure that need refreshing:

• The ability to generate short URLs so when I want to point someone to a book they don’t get this: http://www.amazon.com/Made-Stick-Ideas-Survive-Others/dp/1400064287/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1238028638&sr=8-1
• Disambiguation pages for domain names, and the ability to have duplicate domain names.

(And I’ll preface this by saying that I know jack about web infrastructure, ICANN, etc. so some of this will probably be laughably naive for someone who does. I’m just looking at this from a user point of view.)

Short URLs

TinyURL has gone from being something you’d see occasionally to pervasive, especially with the short message needs dictated by Twitter and Facebook. But it’s also a great way for print to leverage online content, but right now most publications resort to typing out the entire URLs, which is both visually distracting and hard as a reader to enter into a browser accurately.

It seems like something so valuable should be more formalized and turned into a real function, rather than something left to a private company (Gilby Productions). I don’t know who Gilby Productions are, but I sure appreciate Tiny URL. But they also have a strangehold on an awful lot of content. If they close up shop for whatever reason, all of a sudden tens of millions of links become useless. The same goes for the other URL-shortening sites that have sprung up recently due to increased popularity of Twitter, Facebook, etc.

We should have a better way of doing things.  It should be built into browsers, email apps, social networking, etc. This would make things more convenient, more robust, and avoid the roundtrip through a third party site to generate the short url. Tiny URL itself offers an API and people have made plug-ins for various things that make the process smoother.

Nevertheless, I still worry about a single company, no matter how good their track record to do date, having this much “power”. One other url-shortening site I used for a little while (forget the name) disappeared without warning and probably took all those links with it. What if these sites forced us to watch an ad or pay a fee before revealing the destination? For highly transient stuff like Twitter feeds maybe the possibility of these companies disappearing and taking their coded links with them is not such a big deal, but for other uses a more permanent solution should be developed.

Duplicate Domain Disambiguation (DDD)

In this hot, flat crowded world we live in, we need a way to distinguish different companies, organizations and individuals that may have the same name. It used to be that when choosing your company name you only had to worry about local infringement (ie your town) or clashing with a Mega Corp. Today that is still the case from a legal point of view, but from a web findability and advertising point of view it is a non-starter. If a good name hasn’t already been claimed by a legit company, chances are a squatter is sitting on it, waiting for you to dream it up.

We need something like the disambiguation page from Wikipedia. An interstitial page that asks which of the, say, six “acmecorporation.com” you were looking for, along with a brief description of each to distinguish them.

Google serves this purpose today, but even then there can be confusion. And it doesn’t solve the basic problem that we should be able to have exact duplicate urls (at least from an end-user’s perspective), just as there are many Acme Corporations out there making all kinds of different things. Someone at each of those Acme’s today has to come up with a clever variation on acme.com in order to get noticed on the web.

Update on Monday, July 6 by Adam

As I was sayin’… Cnet has an article about the perils behind url shortening services, pointing out some that I didn’t think of.

Facebook and the Downsides of Software as a Service

The tizzy created by Facebook’s page design changes point out some valuable lessons that we should keep in mind as we head more into a SaaS and cloud-based world.

1. Choosing when to change

There are lots of differences between how shrink-wrapped applications and software as a service (Saas) work, but one of them is that customers of shrink-wrapped software choose when, and if, they upgrade. They kick the tires to look around at the changes beforehand, download a trial, poll other users, wait for the .1 rev and the kinks to get worked out.

With Saas, changes get pushed out without those wait-and-see possibilities. Facebook is discovering that this can lead to unpleasant surprises for customers, who have no say in whether they want to adopt them right then.

When something is embedded into the flow of everyday life in the way that Facebook (or Twitter) is for many people, any change, whether it’s ultimately better or worse, is going to cause complaint. People get used to patterns of doing things. Even when you change their work-arounds sometimes they don’t like it.

2. Conversation is a double-edged sword

Having said that, on the flip-side, SaaS is more responsive when there is feedback. It can turn-around updates based on input more quickly, and obviously more universally. But do this too often and you whiplash your users with multiple changes that set and un-set particular features, preferences, design decisions, etc.

Facebook is going to have to tread carefully in the coming weeks as it decides how to respond to the considerable complaining about the new layout. Facebook is quite different than most “applications” because there are such a variety of ways that people use it, and the experiences that each user has are going to be quite different. (All the more so because of the open-ness of the platform.) That makes it hard to design for, and all the more important to check one’s assumptions at the door about what people want to do with it, and what features will support those needs.

On a more macro scale, Facebook (and Saas in general) are emblematic of the more 2-way relationship that now exists between companies and customers. The real-time nature of the conversation, and with something like Facebook the ability of customers to vocalize and organize, is a precursor to what the majority of companies will have to deal with in the future. As the Cluetrain Manifesto presciently argued, all markets are going to be more conversational in the future.

3. Don’t design by committee

But that doesn’t mean everything should turn into design by (user) committee, or tyranny of the majority. That’s not how excellent products get made. There has to be a balance between responding to feedback, and recognizing when you see possibilities that your users, for the time being, do not. Your job as a designer and a company is to create capabilities on their behalf, and not just implement exactly what users ask for. (Not in a high-handed way; users’ needs and best interests should always be the focus.)

(It so happens that we had a very lively email thread running around the frog offices about this exact topic recently. Do you stick to the vision or respond to feedback by changing the vision? The answer: “It depends”. Not very satisfactory perhaps, but unfortunately basically true. There are well-known examples of hits and flops based on both approaches.)

Watch what happens…

We should all be watching very carefully how Facebook acts in the coming weeks as it responds to the conversation. It will undoubtedly provide lessons for the future for all of us.

Update on Sunday, March 22 by Adam

Robert Scoble has posted an even more acid view:

Anyway, all those who are saying the new design sucks should NOT be listened to. Yeah, I know a lot of people are going to get mad at me for saying that. After all, how can a blogger say to not listen to the masses? Easy: I’ve seen the advice the masses are giving and most of it isn’t very good for Facebook’s business interests.

Read more >