Nodes, connections, and context

For a user, the Internet is just a dynamic application. All of the websites and apps and everything else add up to the same abstract features that are present in any desktop app:

  1. Store/read data
  2. Query for data
  3. Write/edit data

That’s a useful conceptual framework for planning a successful startup in today’s internet.

The 3 pieces of the Internet experience

The dynamicism derives from the constellation of websites that any specific person uses, but the person is still just entering URLs, reading text, clicking buttons, and entering data. Websites provide roughly 3 experience types:

  1. Nodes
  2. Connections
  3. Context

(This is probably familiar lingo for social networking geeks.)

To map those 3 experiences to a high-level software architecture:

  1. Nodes are data in the database, the raw “thought stuff”
  2. Connections are relational tables and queries, the data organization and logic
  3. Context is the application layer, the tool that says “we’ll use these nodes and connections to buy airplane tickets, so we’ll need to read and write in the following ways”

A rough history of the Internet seems to show that important startups are progressing from Nodes to Connections, which leads me to think that the future interesting startups will either make better attempts at owning the whole architecture or will find sophisticated approaches to the Context experience.

  1. Early websites focused on content (Nodes), with hyperlinks solving the Connections problem.
  2. Portal sites (Yahoo!, DMOZ) try to organize the content, thereby “owning” the Nodes by creating a map of all of the data. They’re not scalable. Search wins by providing access to any Node the user desires. Web rings are an interesting sidenote in the Node race, as they allow site owners to associate their data with each other and collaboratively increase exposure of their Nodes.
  3. Web 2.0 is about Connections. Social networks evolved nodes from encyclopedic data to social data, and now there is a lot more data in toto that it becomes far more valuable when interconnected. Standards are a critical sidenote in facilitating Connections. XML was interesting but not standardized enough. RSS, oauth, hcard, and microformats create a flurry of experimentation, first as mashups (connected nodes), then widgets (encapsulated, decontextualized nodes), then apps (widgets that connect nodes within standardized contexts, whether Facebook or Open Social). Social networking is all about connecting a user’s data (nodes) with related nodes – LinkedIn, Friend Feeds, Twitter, etc.

So what about Context? Facebook began as a narrow Context play (college students), created a popular standard for Nodes (profiles) and Connections (friend feeds and app APIs). Nowadays, they nearly own Connections the way Google owns nodes. It’s interesting to me to see FriendFeed try to compete there and own Connections by aggregating them (a Connection portal? Is this what Imeem is?).

Facebook is also abstracting their Context so they can own that, too, and become the de facto context for all Nodes and Connections.

I think startups succeed really well when they create an abstracted tool within one of these three experience types:

  1. Google (Access to nodes)
  2. Yahoo (Node filtering)
  3. YouTube, Flickr, Photobucket (Node hosting)
  4. MySpace, Facebook (Nodes and Connections – Myspace is more the former, Facebook is more the latter)
  5. Twitter and AIM (Connections to people Nodes)

Being an app container means Facebook is basically saying “we control the primary Nodes (people), and the Connection standard. We’ll allow you to plug your secondary Nodes (favorite albums) into our Connections and also create secondary Connections (other people who like El Ten Eleven) atop our standards.” Doing so allows Facebook to create a popular Context for the user experience (interacting with other people, which is very popular right now). Facebook is trying to abstract the context by reaching beyond college students but I think they’re hitting a conceptual wall – Facebook’s core context is still messaging and keeping tabs on people.

I think there are a couple ways to succeed in this framework, at this time:

  1. Build a better connection solution. I think the nodes problem is mostly solved, so now it’s interesting to try to connect those nodes. I think FriendFeed has the biggest potential here because it can theoretically play with any node (due to the popularity of RSS) whereas Facebook is trying to own Nodes and Connections, putting them in conflict with other Node hosts.
  2. Solve context problems. I think Meetup could improve vastly if they allowed:
    1. Registration via OpenId and oauth.
    2. Full integration with Flickr, YouTube, WetPaint, vBulletin, etc.
    3. Integration (rather than competition) with other event services: Evite, Eventful, Upcoming, etc.

    In this way, Meetup would defer the first 2 experience layers to point solutions and instead provide a contextual container for using them, like an app that could pull from many databases and mash up functionality from other apps. In that way, Meetup would become the best context for social gatherings, in the same way that Friend Feed is a connection(al?) container for all kinds of media and message Nodes.

I think #2 is the most compelling case today. People are solving context in specific ways, but I don’t think it’s paradoxical to try to create an abstracted solution for specific contexts (as opposed to a very broad context, a la Facebook).

How to fail, in this model

Trying to solve a problem at one experience level without dealing with the tier(s) below.

I think this is most commonly seen with niche social networks. What’s the point of creating a SN for stickball players if they have to create a whole new account? You won’t get enough nodes to make the connections valuable, so the context won’t exist. It’s like creating a ticketing system that can only book Delta flights out of Des Moine. Yes, it’s useful to business travelers in Des Moine that have a ton of Delta Sky Miles, but that’s probably not going to lead to your billion dollar IPO/buyout.

I think this also happens when web sites try to “own” all 3 experience levels within a walled garden – it expects Context to be so compelling that users will ignore the weakness of the lower 2 levels on 2 levels: they aren’t as sophisticated as specialist point solutions and the user is restricted to a subset of all of the Nodes and Connections that might be relevant to the Context.


So a lot of this is an argument for the business value of integrating feeds, widgets, and external APIs into a startup (and providing all of these tools for other sites, so they’ll resell your features and data). I have a blue-sky concept of a permeable SN framework called Buhnilla. The goal would be to put as little data or application logic in Buhnilla as possible, just push it all out to point solutions (e.g. users can’t upload photos but they can display galleries of their Flickr photos, filtered by tags; users can’t create profiles but they can use oauth to log in and show their Plaxo and LinkeIn data). If Buhnilla were a Facebook and Open Social container it would be even more powerful, because it would then basically become a merchant for Nodes and Connections. Open source Buhnilla and people could shape it to any Context they desired.

Why SEO matters for user-generated content

Lately I’ve been surprised to hear people say something to the effect of “when it comes to social networking and UGC, SEO doesn’t matter” in a number of different conversations. Nothing could be farther from the truth. In fact, SEO is more important to a successful social networking and user-generated content than for editorial content.

UGC, including media uploads, blogs, profiles, comments, message boards, and the like, is nearly free content. Unlike editorially-generated content, which requires writers, editors and sundry other creative professionals and associated payrolls, UGC is as simple as making a space and inviting people to join the conversation. Once the technical framework is in place and people have joined it, they’ll begin contributing their own content, whether it’s MySpace profiles, Amazon book reviews, or Yuku message boards.

I write “nearly free” because the community voluntarily creates this content – the only incremental costs come from supporting the infrastructure, which becomes cheaper every day, and policing the community, a cost that can be spread to the community itself in the form of volunteer editors and “digg down” or “flag as inappropriate” links. In addition to being nearly free, UGC is also generally low quality and has relatively limited appeal. However, a business that can cheaply monetize a large body of UGC has a nice asset on their hands. Cheap monetization means the niche audience that appreciates a particular piece of UGC can find it without any editorial effort – the best way to achieve this is SEO.

The often-unstated assumption of “no SEO for UGC” is that the user-generated content isn’t valuable. It’s ugly, mostly pointless, not shaped for general consumption. But 1 million ugly MySpace pages don’t lie – people want to create and consume UGC. 20 million people might want to read Hilary Clinton’s professionally ghost-written book while only 2 people want to read this blog (thanks for being here!), but if I can find a way to make those 2 page views pay more than they cost, it’s a small, good business decision to write a barely-popular blog post. If you can aggregate a lot of those small, good business decisions it really starts to make sense. UGC is valuable beyond echoing editorial content – it’s often the only way to build a library of truly niche content. If you’ve ever used Google to troubleshoot an obscure problem with an electronic device, you probably found your answer on a message board, written not by the device manufacturer but by a fellow consumer. If you’ve ever read wikipedia you’ve gloried in ugly, mostly pointless, barely factual information.

With SEO in place, every piece of UGC becomes as valuable as possible. A single piece of editorial content might generate a lot of page views, but it’s often cheaper to “create” many UGC pages and if each one gets 100 page views you have some great traffic numbers. The only way this long tail content strategy works is if the 100 people in the world who care about your photo of a rare bird that landed in your backyard can find that photo. And that depends critically on SEO.

Editorial hierarchies don’t work when it comes to UGC (and some people would argue that they don’t work for editorial content either). There’s no point hiring a bunch of editors to review all of the photos on Flickr and categorize and rate them – it would take forever, cost too much, and most of the photos are crap anyway. “Should this one go into the ‘blurry drunk party’ category or ‘dysfunctional family gathering’?” While the photos can be organized according to tag-based taxonomies, favorites, and the like, the cheapest option to make meaningful sense of all those photos is search. More specifically, Google search. Just let the user tell Google what she wants and they’ll find it in the pile, with no special effort, engineering know-how, or server load on the site that’s hosting the photo.

UGC SEO is a slightly different game than editorial SEO. With editorial content, you’re typically trying to get to the top of one very big heap (“We want to be the number one search result for ‘motorcycle’!”), but with UGC you’re getting to the top of many very small heaps, which is a lot easier and generates traffic that is generally far more relevant to your site (“We’re the number one search result for any combination of ‘motorcycle’ and a city name!”).

Searchability is a fundamental concept of long-tail economics – it depends on a perfect consumer who can access every part of the tail with equal ease. Without Google, the blockbusters continue to survive on marketing and reputation, but the quirky UGC stuff needs placement on the search results page before it can become valuable on it’s own.

Improve your share price with social media

Mashable summarized a report from Hindustan Times that Rediff’s addition of social media functionality has dramatically improved the Indian portal site’s stock valuation.

This from Hindustan Times:

Rediff’s stock has witnessed a sharp jump in share price and volume on Nasdaq over the past week, when it also launched a Website to help consumers upload voice, video and photographic content for free.

In 8 days Rediff’s share price spiked up 40%, from $17.94 (on July 5) to $25.41 (on July 13). HT goes on to report a possible sale to Google or Yahoo for over $1 billion (US).

I’m looking forward to the day when adding social media functionality is as commonplace as including forms on a your website. Then we’ll really get back to our roots.

Fitts versus the Cyclops

Usability implications of ocular-kinesthetic dissonance

The fingers you have used to dial are too fat. To obtain a special dialing wand, please mash the keypad with your palm now.

The Simpsons

Fitts’ Law is a conceptually simple prediction model for explaining the ease of acquiring an interface target as a function of the target’s size and distance from the users’ starting point. Simply summarized as “bigger and closer is better,” its wide application has generated much of Web 2.0’s childish, playschool look. A striking example of a design that pays heed to Fitts’ Law is the Vimeo registration form, which includes enormous input fields, far larger than are typically seen on other sites.

Defining a limit to usable sizes

Good news dude! 3″ is enough for the average user!

If a login form is the most important UI component on a page, shouldn’t we make it bigger and bigger and BIGGER? Fitts’ Law prescribes large interface components, but there are some factors that cause diminishing returns. One is information density – big buttons are nice, but not if they’re the only thing on the page. Another often overlooked limiting factor is the user’s field of vision.

Google wisely leaves most of the page unused for its form field and input.

The eye’s focal width on a page or screen is roughly 3 inches (the fovea centralis provides a sharp field of view of 2 degrees). That’s all we can clearly see in a single instant. Our eyes actually flicker around constantly, taking many images with a surrounding blurry field (about 24 per second), which our brain compiles into a larger image of the world. So an ideal visual “object” measures roughly 3″ or smaller – something we can literally take in at a glance. As the size of a visual object increases beyond 3″, the user’s visual, physical, and mental effort increases. At even larger sizes the object loses its distinction and risks becoming a background/field instead of a foreground/object. Other visual indicators factor into this consideration (color, pattern recognition, borders, etc.), but I believe that usability rises, plateaus, and then declines as visual objects increase in size.

You can see an excellent example of an overzealous application of Fitts’ Law on the Web 2.0 job site Krop. The search field is so large (especially on lower-resolution monitors) that it reads as a non-functional color field rather than a form input for some users. I only noticed it after browsing the site and thinking “Gee, don’t job sites normally include a search box?”

Your user is a blind Cyclops

Remember the story of Jason and the Cyclops, who despite his awesome size was cruel and quick, always scanning the ground for prey (sounds like a MySpace user, no?) Jason’s initial encounter with the Cyclops did not go well: prefiguring Star Trek’s red shirts, a handful of Argonauts became a quick meal for the Cyclops. Captured and scheduled for the stew pot, Jason’s crew hoists a burning beam from the Cyclops’ cooking fire and – POIK – stick it in his single eye. Blinded, the Cyclops searches flails about for his prisoners. The Argonauts finally escape by covering themselves with sheepskins and crawl beneath his groping hands, impersonating his flock of sheep.

In addition to the ancient lesson of not going toe to toe with one-eyed giants, the story also provides a gruesome depiction of user error: blinded and disoriented, the Cyclops is forced to downgrade from his preferred interaction method (visual) to a less effective kinesthetic method. The Cyclops acclimates to an alien sensory landscape by relying on preexisting conceptual patterns to facilitate his decision making process: “sheep are small and feel sheepish, therefore these things must be sheep and not tricksy Argonauts.”

Until users stop using browsers in favor of personal homepages and feed readers, they’ll have to contend with a perpetual learning curve on myriad evolving sites and internet applications. A valuable tool for accelerating this curve is a reliance on patterns and scanning. When users scan interfaces, they use quick appraisals to efficiently assign expectations to interface objects. It is critical to balance usability concepts like Fitts’ Law with approachability concepts like easy scanning and adherence to expectations. An Argonaut should not look like a sheep, no matter how warm and soft it may seem.

If your visual objects are too large, they’ll be improperly scanned

The Krop search field provides a simple example of the complications that result from overemphasis of a single usability concept. Form text inputs are already at a disadvantage because they are visually bald interface objects – it’s not easy to display “space.” A quick does of elephantitis (and in Krop’s case, a subtle gradient style commonly used in backgrounds) pushes that blank field out of the user’s “object” pattern set and into the background.

When designing for users, remember the new users who are so critical for any increasingly popular interface: not quite blind but hampered enough by hurry, worry, and ill-conceived design that their behavior becomes, to some degree, cyclopean.

The joy of reg

Recently-enjoyed registration forms

Bigger is better!
Red bars in the inputs? It’s the first time I’ve been delighted by required fields.
Overdone, but at least they tried.

Your reg form is your (un)welcome mat

I’m always bothered by web designers who like to kick off site designs with the homepage. Typically, users spend the least amount of time on your homepage. Better to figure out that content page template, no? Google is your real homepage these days — if you’re smart about SEO and navigation tools, many users will never browse to your index page.

But registration forms are still a common gateway in many web-based experiences. So why do designers ignore them? Forget the homepage, the registration form is the real time to say “hey, it looks like you’re ready to join the family — welcome!” This is your user’s wedding, why are you making it feel like a shotgun trip to city hall?

Common reg form mistakes

tiny asterisks indicate required fields
“Game over man! Game over!”
too many fields
incomprehensible error messages
Misspent youth
nonexistent helper text

A proliferation of Web 2.0 websites, communities, and applications means a proliferation of registration forms to consider. Until OpenID saves us from relentless registration repetition, it’s up to designers to make reg forms better.

This is important: at Meetup, we saw small changes like removing an unnecessary input field (less fields = less work for users) increase form completion by several percentage points. How many users, actions, or sales are you losing to bad form design?

Quick Widget Update

Techcrunch points to an interesting Widgets overview on Yahoo’s Widget blog.

I’ll repeat the comment that I made on the Techcrunch blog to write that beyond all the hype, Widgets are still in their infancy, and engineers are still figuring out how to identify and leverage their strengths.

In addition to my earlier post describing Widgets as the Internet’s potential “connective tissue”, I think Widgets are interesting as a more pure implementation of the Ajax philosophy; they’re truly asynchronous.

With Widgets, we’re starting to see a hack that gets us past some of the big problems with an Internet based on HTML pages rendered by browsers:

  • Widgets shift the ownership of a user’s “state” from pages to users
  • Widgets make websites invisible and make their services visible

The next interesting implementations won’t come from people who are asking “what kind of flashing light can I put on your blog or website?” Instead, they’ll come from people asking “what kinds of constraints and inefficiencies am I taking for granted when I think about web content and applications?”

I think we’re already seeing this with disruptive technologies like RSS feeds and mobile devices. I expect that we’ll see many real Widget innovators rise above the noise in the coming year.

Notes on simplicity

Just a brain fart while reading The Design of Everyday Things:

Increased complexity leads to an increased likelihood of what Donald Norman describes as “slips”. Thinking about this, I realized that it’s not only due to the obvious math of “more options equals more wrong options”; if we think of actions stemming from a neural model of patterned relationships, increased interface complexity increases the sum of patterns and mental relationships, therefore decreasing pattern comprehension (or pattern matching, a critical component of task completion).

A great example of this is the “Rule of Seven”: humans have a hard time conceptualizing more than seven discreet items in a list (for most people, the max is closer to five). Beyond that, they begin clustering the information, and the items within a cluster lose their individual relevance. There is a pattern cap happening.

If you see a control panel with 100 undistinguished knobs, the chance of mismapping your pattern of desired action to the pattern of necessary action is very high, because your mental model can only include the correct answer, not all of the wrong answers (to be avoided).

There is a concept in programming of a “null” number. It isn’t zero, it doesn’t exist at all. UI actions have a binary completion/error result set, but UI designers should be aware that there is also a “null” result present in complex systems where a user simply cannot comprehend all of the options and action paths.

An easy solution here is to decrease complexity. An alternative solution is to provide surrogate patterns to aid mental modeling – Don Norman talks about positioning light switches within a floor map. Even an “important/unimportant” schema helps users find markers along a path to action completion.

Boring Interfaces May Be More Effective

Catching up on Jakob Neilsen’s articles, I came across this piece on users’ reading patterns. This is a good one to bookmark, so you can easily explain to someone why “clever” section headings aren’t generally a good idea. If a heading doesn’t clearly explain the content’s value, the user moves on pretty quickly.

It also raises questions about the trend towards placing site navigation along the right side of a page. I think it’s a good idea in blogs, where we can expect that a user is really only interested in the current article – don’t distract their eyes with a left-side list of links.

Give ‘Em What They Expect

I can hear the design hack saying “well, my site is deliberately different – we’re going to excite and engage the user with our avant-garde interface.” Prepare for an uphill battle to achieve that engagement, because ignoring the “F” means ignoring years of pre-existing experience, during which the user has been physically and cognitively training to perform an “F” scan on thousands of standardized pages.

Simple QA Cheat Sheet

Testing a complex website or web-based application can become especially tedious when you don’t have a good sense of when you’re “done”. After working on several projects where I’ve either handled User Acceptance Testing personally or outsourced to a temp, I’ve come up with a baseline boilerplate QA checklist.

If you’re a web designer or project manager, it might provide a nice starting point for QA. If you’re non-tech person looking to evaluate a website, it’s a nice way to make sure all of the bases are covered.

Step 1: New Functionality

Review any specs, work orders, mockups, etc.

  1. Does the site/application perform the tasks as expected?
  2. Are emails sent or confirmation/error messages displayed as expected?
  3. Are records saved and calculations performed correctly?

Step 2: Design/User Interface

  1. Text
    • Spelling
    • Capitalization
    • Spaces
    • Abbreviations
    • Are dates and times formatted correctly? (Programmers have a tendency to leave unfriendly system-generated dates and times in
      an interface.)

    • No remaining greeking or “Insert text here” messages
    • Is all functional text logically written? (Intro text, field labels, helper text, error messages)
  2. Images
    • Are images sized correctly?
    • Are images compressed appropriately? Nothing looks too grainy?
  3. Branding
    • Are all copyrights, trademarks, etc., displayed correctly?
    • Do site colors match any style requirements?
  4. Colors
    • Are hyperlinks underlined or otherwise marked?
    • Are titles displayed prominently?
    • Is all body text legible?
  5. Layout
    • Are all page elements aligned correctly?
    • Are widths and heights set correctly?
  6. Cross-browser testing. I usually make sure all pages look good in these browsers:
    • Windows Internet Explorer 5, 5.5, 6, and now 7
    • Windows and Mac Firefox
    • Mac Safari
    • Opera (sometimes)
    • AOL’s Browser (sometimes)

Step 3: Functionality

  1. Check every link from every page (there are some free automated solutions for small websites)
  2. Does the HTML/CSS validate?
  3. Do pages render correctly or display appropriate error messages when browsers’ JavaScript and Plugins are disabled?
  4. Do all filters and table sorting options work correctly?
  5. Does the application function appropriately for different user states (logged-out, member, etc.)?
  6. Does the application handle invalid form input appropriately?

Step 4: Goldilocks

And finally, the grandaddy of of gotchas:

Zero, one, many

The basic idea is to fill every dynamic content block or form field with zero, one, or many items and make sure the system works well with all three
situations. Try too little, too much, and none at all. Oftentimes, we design an interface expecting just the right amount of content or data –
this is the time to look for all those weird edge cases.

That’s it! Let me know if you think of anything I could add to this list.