I’m just not feeling this ’social graph’ stuff

September 4th, 2007

There’s been a large amount of discussion in the blogosphere lately about the notion that there should be some uber social networking platform that all social web applications will be built upon. Most bloggers are calling this ‘the social graph‘. Guys like Robert Scoble and Dave Winer are bringing this up almost daily now.

I have lots of issues with this idea, but let’s discuss two of them now.

1) As far as I can tell, the biggest motivating factor behind all of this talk is that registering for a new social site and seeking out one’s contacts is just too much work for people. Apparently it’s the hardest thing evar.

What is not being acknowledged is that the only people that sign up for more than a few social networking sites a year are web 2.0 entrepreneurs and tech bloggers. It’s a a self fulfilling prophecy. Because we all go around checking out the competition and looking for the next hot thing, we’re constantly signing up for sites that turn out to not be worth the trouble. As a result, we’ve all gotten really annoyed at having to go through this process all the time. Ask any of your friends that majored in the liberal arts in college how many social websites they’ve signed up for in the last year. I’ll bet it’s less than a handful.

2) The second big reason people are giving for such a system is that they don’t want one corporation to control the social graph. They don’t want Facebook to be in control. Instead, the idea is that there should be some sort of open source, decentralized system to handle it that nobody owns.

Well, first of all, Facebook isn’t that universally used. It has a social graph, but it will never be the social graph. Secondly, I’d actually prefer to have a few reputable companies controlling this information than have it floating around in the cloud for anyone to get their hands on. There is a huge amount of sensitive information captured in this graph. Much of it is non-obvious. This is especially true when you remove it from the narrow focus of a site like Facebook.

What happens when adult friend finder hooks into the social graph? Do all of the connections that people make there become public? If this system is going to know that Steve on site X is the same as Steve on site Y, then people will have a field day mining this data. End users will have no idea what they’re getting themselves into. There are implications that need to be considered.

Visual differentiation of scripted links

August 28th, 2007

I’m talking about “ajax” links, or “javascript” links. Anything that results in an action while still letting the user remain on the current page. Let’s call them “scripted” links here.

Scripted links and non-scripted links lead to drastically different user experiences. We should make them look different too.

Clicking a non-scripted link causes the browser to fetch, parse and render an entire new page. The url changes. The screen flickers. The scroll bar shoots back up to the top. It’s kind of a big deal.

A scripted link, most of the time, has less severe consequences for the user. Maybe a tab gets swapped in, or a floating div pops up to display some information. Whatever it is, it’s a very different experience than a non-scripted link. The page doesn’t reload. The scroll bar stays right where it is. You won’t lose any text you may have entered into a text box.

We should let our users know what sort of experience they’re getting themselves into before they click. We should help them make the decision of whether or not a link is click-worthy.

Many great sites use both regular and scripted links together but do not consistently differentiate between the two types. Sites like Facebook, Flickr, Google Video, Yahoo’s Homepage, Digg, Youtube, and many more. Nearly every site out there gets this wrong.

Here are a few screenshots from popular sites with this issue.


On Google Video, the “Comments” or “Collapse Frame” links are safe for me to click on while watching a video. The “Help” link is not. As a user, I don’t have a great way of making the distinction. One wrong click on that help link and I’ll forever be afraid to click on any links until my video has finished playing for fear that I’ll lose my place.


This is from the featured content module on the Yahoo! Homepage. The top two links send me to a totally different page. The bottom link just loads different content dynamically in the module. The links look identical.


Youtube has different styles applied to their links, but unfortunately it’s not consistent. It would be great if all of the scripted links had the dotted underline for example. Then I’d know for sure that clicking on a page number is safe, but clicking a person’s name will interrupt my video and I should be careful.

– ———

As web developers, we probably don’t have as much trouble with this as most people. We have a good feel for which types of functionality tend to get implemented dynamically and which ones don’t. We know what cues to look for. But, for less savvy users, a consistent style differentiation could go a long way to making them more comfortable to click on scripted links. And users that feel comfortable clicking will explore and in turn find your site easier to use.

There are a few ways to go about implementing this (and we’ll have to do it without any built in help from the browser this time). The approach I’ve taken on my newest project is to simply slap a class=”scripted” on all of my scripted links as I’m building my pages and I’ve made links of that class look slightly different. If you’ve already got a large site and doing that manually would be too painful, then you may be able to apply the style to these links at run time via javascript as long as you’ve been consistent in the manner in which you’ve executed your scripted links. You could look for links that have a defined onClick event, or an empty href, something like that.

Today’s Horoscope

August 25th, 2007

This morning I had to take a short bus ride up in SF. The seat next to me had part of the Marin Independent Journal on it, and the comics were facing up, so I grabbed it and started reading. Eventually I stumbled on the horoscopes. This was mine:

LEO
You’ve stuck with your original plan long enough. Time to reconceptualize it. Do this, and finally get the money you’ve worked for. Tonight revel in any morsels of leisure time you can scrounge up.

So, I guess that means I’m going out tonight.

Urls still matter

August 21st, 2007

Nielson stopped ranking by page views! The page view is dead! AJAX only apps are the future! We only need one url now, yay!

No. Stop it. Calm down.

You still need urls for every object in your system. Permalinks still matter. Having one page that just makes AJAX requests to fill in the content is dangerous.

Hey Google Reader team… Why can’t I bookmark a specific feed as I’m reading it and then go straight to it each morning?

Links matter because the web is made up of bite size objects that need names. Those names are necessary because people like to bookmark, share and talk about these objects. Without a link, an object has no name, and that’s just sad. Without a name, people can not do anything with it outside of the application. If they’re locked in that way, then everyone loses out.

Hey Google Calendar team… Why can’t I cut & paste the address bar to send my friend a link to the current view of the shared calendar I’m looking at?

Now, if your application doesn’t have any “objects” to speak of, then go ahead, make an XHR app with just one url. But, I don’t think such a web application exists.

Sometimes using AJAX exclusively makes sense. It can potentially lead to increased speed and usability. However, if you do this you have to utilize the url hash to maintain a permalink in the address bar. Good examples of this in practice are Yahoo! Maps, and Stumble Video. Use those sites and watch the url change as you go.

To some of you this may all sound obvious. But, if Google is making this mistake, then surely many others are due to follow their poor example.

New link type proposal, a:external {}

August 7th, 2007

Today’s CSS specification allows for the browser to distinguish between a few different types of links. Two such types are regular links and visited links.

a:link { }
a:visited { }

By default, visited links are purple. This is a concept that we’re all very familiar with, both as web developers and web users. It’s simple, it’s useful and it’s only really possible because the browser itself is doing the link tracking for us.

Imagine if web developers were tasked with manually applying such a style to each and every link? We’d have to implement some sort of system to track which links our users are clicking on and then programmatically apply a style like <a class=”visited”>s</a> to each link. Would anyone go through the trouble? Nope. We’d be missing out on lots of useful information because it would be nearly impossible to implement.

Thankfully, we don’t have that problem with visited links, but we do have a problem with another type of link. The external type.

An external link is a link that goes to a different domain than the one that the current page resides at. A link can either be internal or external. It would be trivially easy for a browser to apply a pseudo style called a:external for us on the appropriate links. Wouldn’t that be nice to have? Definitely.

Implementing this manually is certainly easier to do than with the visited case. Sites like Wikipedia have been doing it for a long time. You could do it with a little bit of js, or by adding a class=”external” to all the right links. But, it’s still an extra step that only the most conscientious web developers will bother to take. If it were built into the browser and given a subtle default style, then we’d all benefit from it despite the lack of effort or knowledge from the large majority of web developers.

How can we go about making this happen? Who makes all these CSS spec decisions? Can I edit the Firefox source myself and submit a patch?