18 Nov 2014
A colleague asked me if I had a good reading list for API design,
since that's part of my job these days. I did quite a bit of reading
before I dug into doing design work, but never collected the best
resources in one place. Until now! So, here are texts I've read that
I would recommend familiarity with before setting out to design an
RESTful Best Practices
Todd Fredrich's book
RESTful Best Practices
is a concise, free book filled with useful guidelines. You'll never
get complete agreement on lots of API design issues, but if you're
just getting started, this book will certainly set you on the right
path. I agree with most everything in this book.
HTTP API Design
An even more compact resource is the
HTTP API Design
repository. It covers much of the same ground that Todd Fredrich's
book does, but also includes more technical peripheral recommendations,
like using TLS and passing version information via the Accept header.
Steve Klabnik's Nobody Understands REST or HTTP
In a passionate
Steve Klabnick gets back to basics to explain why so many APIs succumb
to basic mistakes that were so clearly outlined correctly in
He's come back to many of the points in subsequent posts and
revisions, so it's worth reading. He's given these topics a lot of
RESTful Web Services
A somewhat dated book from 2007,
RESTful Web Services
covers the basics of RESTful design, and is now available in its
entirety under a Creative Commons license. It was written in a time
where SOAP was all the rage, and was thus championing the virtues of a
stateless server implementation. One of the ways it shows its age is
by focusing on XML as the primary interchange format, though JSON is
discussed to a fair degree. Never mind that, though, the fundamentals
are all there, and for the most part, still sound.
RESTful Web APIs
A 2013 follow-up to RESTful Web Services,
RESTful Web APIs picks up
where the Web Services left off, delving deeply into the details of
HATEOAS. While HATEOAS is
an important concept, many aspects of it may not be suitable for some
use cases. Web APIs is a great read because it explores some of
those nuances, although it is perhaps not necessary for those just
getting started on API design.
Thoughts on RESTful API Design
Thoughts on RESTful API Design
is a well-written, relatively detailed overview of good API design
guidelines. It covers a bit of theory, but it is predominantly
focused on the real practicalities of API design, like how HTTP verbs
should be used, pagination, and how to design a solid URL structure.
Perhaps I'll put together a discussion of some of the API design
challenges I've faced. There are many practical challenges beyond the
basics covered in these resources that are worth looking at, like how
to design an API for multiple products that utilize the same
information, when to inline one resource inside another, and how to
design for both high-performance and bandwidth-constrained clients.
16 Mar 2014
This post is designed for those that have decided RSS is something to
look into, but aren't sure where to start.
Get a Feed Reader
I'll address potential reader demographics in turn. This is not
intended as a survey of available software. Rather, these are my
picks after using more than a dozen RSS readers over the years. My
prime pick, Google Reader, is no longer with us, but two worthy
successors takes its place if you're looking for professionally hosted
If you're reading across multiple devices (computers, phone, tablet),
a web-based reader is almost mandatory, because RSS readers are
stateful: they store which articles have already been fetched as well
as which articles you have read. Even if you're only reading on your
laptop, web-based are the easiest to set up and maintain, while also
providing the best user experience.
For the Casual User
The best options that are hosted professionally are
Feedly or The Old Reader. Both sprang from
the ashes during the Great Google Reader Exodus of 2013. I would love
to pick only one of these, but both are truly excellent. Both sites
allow you to create an account very easily using your Google account.
I find that The Old Reader is the most exciting, because it builds a
social network out of RSS, something I've wanted to see happen for
Feedly has mobile apps for Android and
iOS, as well as their flagship web interface. If you're
using The Old Reader, it has a whole page of
native app options for the mobile platforms and beyond.
For the Web-Savvy
If you run your own website and are comfortable deploying your own web
app, there's always an advantage to running your own server. You have
more control over your data, when you upgrade and whether or not you
want to shut the service down.
The superb, open-source TT-RSS is the best-in-class for such
users, and I've been using it for more than a year. It has an
open-source Android app, and there is extensive
third-party support for it as well.
The power of the open-source nature of the project and high community
involvement is easy to appreciate if you browse through TT-RSS's
If you're not into running your own servers, hosting providers like
Bitnami offer a TT-RSS based stack that you can deploy
For the Offline Afficionado
If you strongly believe that using a webpage to aggregate web pages
doesn't work for you, there are several offline options.
The best, in my opinion, are the Firefox-based readers. They work
across platforms as extensions to Firefox. They each have their own
style, but by far the best is Brief, which provides the essential
river-of-news experience that makes RSS so powerful.
On OS X, there are a few paid options, but the reader I used 'back in
the day' on OS X, Vienna, is open-source and still alive and
On Linux, the best reader is still Liferea. I used it for a few
weeks some years back, but moved to web-based readers because of their
For the Emacs Hacker
If you can't bring yourself to ever leave Emacs for anything, check
out Elfeed. It's amazing, and the
engineering behind the database is very interesting given
the limitations imposed by Emacs.
OK, so you've got a feed reader. But how do you find feeds? Most
browsers have removed their built-in mechanism to identify pages with
RSS. Fortunately, good browsers are easy to extend.
If you're using Firefox (you should!), then the extension
RSS Icon in Awesomebar will add the RSS icon back to the URL bar,
giving you one-click access to RSS subscription. If you're using
Google Chrome or Chromium, get the RSS Subscription Extension,
which provides almost identical functionality.
Once you add these extensions, you should come back to this site, and
you'll immediately notice that it has an RSS feed because there is an
orange RSS icon in the URL bar.
Integration With Your Browser
When you click on that orange icon to subscribe to a feed, your
browser will bring up a preview page of the feed, and then ask you
which program to use to read the feed.
The simplest approach at this point is to simply press Ctrl-l, Ctrl-c
to select the URL and copy it (Cmd-l, Cmd-c on OS X) and then paste it
into your feed reader's 'Add Feed' box.
A more sophisticated approach is to let your browser know what reader
you're using, so it can add it with one click. If you're using Feedly, there is an extension for both Firefox and Chrome.
TT-RSS has a has a whole topic on
integrating with Firefox.
If you're using Chrome or Chromium, the drop-down on the subscription
page provides you the option to manage your feed readers, allowing you
to provide a endpoint to call with the feed URL to subscribe.
Pro Usage Tips
Each of these probably deserves a (short) article of its own, but here
are some tips I've picked up in 10 years of daily RSS reading:
- Move through a combined view that aggregates all your feeds in
reverse-chronological order. This is called the river-of-news.
Don't visit feeds one-by-one, because you'll forget to visit the
less frequently updated feeds. Use the river-of-news.
- Use the keyboard to move through, visit and star articles. In most
good readers, you can press '?' to get a quick help screen.
Don't use the mouse.
- Star/bookmark/favorite items that you might want to come back to
later. RSS is good for reading, but is also a good database of
Good luck, and stay tuned for more RSS articles soon.
14 Mar 2014
RSS is a simple, easy technology that allows you to stop opening 30
tabs in your browser to check the news sites you care about.
RSS unclogs your inbox of all the newsletters you subscribe to. RSS
puts you in control. RSS is simple, distributed, ubiquitous, and
free. You should be using it. But what is it?
RSS is way for computers to read websites.
Consider: much of the web is designed only for humans to read.
about designing web pages for one scenario: a reader visiting the site
with a browser. It's all about the all-powerful User Experience.
But in focusing so much on a user's experience on a single site, we've
completely neglected the user experience of the web as whole. That's
where RSS comes in.
RSS is one of many ways websites can be made easier for computers to
parse. Separating content from form is at the core of CSS. But
content itself can contain markup that gives computers clues about
what kind of content it is. Microformats
are designed to provide exactly that kind of metadata.
RSS takes things a step further, providing a simple format the strips
away all the style and layout information, and just provides raw
structure, metadata, and content. An RSS parser examines the
structure to identify given entries in an RSS feed. For each entry,
the parser examines the metadata, like the title of the entry, the
date the entry was made, and the author of the entry. Finally, the
parser examines the content itself. Using this basic methodology, the
parser can build a database of the website.
But what is gained by parsing RSS and building the database? To
answer that, we should look at how people use the web for both search
Search and Discovery
The decentralized nature of the web makes it difficult to jump
directly to what you're looking for, so search engines sprang up to
solve exactly that problem. By having computers follow all the links
on all the pages and store what words are on what pages (and what
those pages link to), users can quickly jump to content related to
keywords they enter.
But what about data you don't know exists? News is an obvious
example, and has at least three aspects.
- News from people you don't know but from sources you may trust,
like the BBC (actual news)
- News from people you are interested in, but aren't necessarily your
friends (blogs, social networks), and
- News from friends (social networks),
There's also non-news sources.
- A wiki that covers a topic you're interested in. What's been
- Blogs, either personal or professional, updated frequently or not.
How do you find out when they've changed?
- Questions posed about a particular topic in a Q&A forum. How do
you discover new questions?
Search engines address none of these use cases, since search engines
handle search, and these issues are about content discovery.
The Flawed Model of Email-Powered Discovery
The most common way to address these issues is via website newsletters,
wherein a reader submits their email address to the website and gets
notified about interesting stuff via email.
There are three problems with this approach:
- It gives the reader's personal information (their email address) to
a site needlessly.
- Rather than the website acting as a passive source of information,
it now takes control, deciding when a reader gets notified about
new content. This leads to the oft-cited problems of
- Unsubscribing becomes an error-prone transaction that puts the
reader at the site's mercy. If the 'unsubscribe' link doesn't work
for any reason, the reader is left little recourse besides email
filters and the 'Mark as Spam' button.
The whole system is much more complex than it needs to be, and it
dilutes the importance of email, since messages from your bank about
your account being overdrawn carry the same importance as the latest
web-comic from a friend-of-a-friend.
Introducing the Feed Reader
We can avoid the problem of email dilution and email overload by
moving non-actionable content away from email and into a feed
reader. A feed reader is a lot like a second email client, but
rather than being a gateway to communication with humans, a feed
reader is designed to be a gateway to the web.
Remember that database of information the computer gathered by parsing
RSS? It's essentially a one-stop shop for all the data from web pages
you care about, stored in a single location, much like email. Unlike
email, though, it is non-urgent content, so you can treat it more like
a magazine than an email client. A feed reader maintains a list of
all the sites you're interested in getting updates about and
automatically fetches new entries from them regularly, storing them in
the database, and presenting you with a stream of updates.
This approach puts you back in control, but alleviates the burden of
checking many sites manually. The browser becomes much less
cluttered: rather than a tab for each site that may have interesting
content, tabs are opened by the feed reader if a particular entry
looks interesting enough to read through in its entirety.
Besides the reduction in email noise and enhanced organization offered
by RSS, it also allows you to enjoy content that was previously
inaccessible. Consider the
Harvard Journal of Law and Technology.
It's simply not updated often enough to warrant visiting it every day,
but when it is updated it has some great content. With RSS, updates
magically appear in the same place you get all your information on the
web: in your RSS reader. There's tons of content on the web produced
by amateurs that is excellent, but because they're not paid to write,
updates can be sporadic. RSS opens the door to enjoying that entire
category of content.
So, if you see an interesting site, you don't have to worry about
bookmarking it, signing up for a newsletter, or remembering to visit it
again. You simply click the feed icon and content from the site
magically appears in your usual news stream. It's like teleporting
information directly into your brain.
RSS is a Way for The Internet to Know Itself
In his 1980 TV series Cosmos, Carl Sagan said "We are a way for the
cosmos to know itself." The internet exists on a unimaginably smaller
scale, but RSS gives the internet a way to read itself. RSS brings a
beautiful publishing, aggregating, filtering, and analyzing platform
to regular people, making the vastness of the web just a bit more
manageable. If you're not using it, you're spending a whole lot more
time absorbing a whole lot less information.
17 Feb 2014
In 2011, Canonical made Unity the default desktop environment for it's
market-leading distro Ubuntu. Unity has been in development since
2009, but remains the least sophisticated desktop environment
available for Linux, and not only fails to innovate in any meaningful
way, but represents a regression in the quality of software on Linux
with respect to stability and configurability. As a result of
Canonical's insistence on using Unity (which was developed in-house at
Canonical), entire Ubuntu spinoffs have been created with a goal of
allowing users to easily avoid using Unity. Distros such as Kubuntu,
Lubuntu, Xubuntu differ from Ubuntu only as much as necessary to
provide a different default desktop experience from that provided by
stock Ubuntu. Even the more distantly-related Linux Mint has taken it
upon itself to move away from Unity, creating not one, but two
alternative desktop environments, MATE and Cinnamon, based on Gnome 2
and Gnome 3, respectively. This has not deterred Canonical in it's
mission to push Unity as the de facto desktop interface in an effort
to unify the user interface for Linux across desktops, laptops,
netbooks, tablets, and phones.
I was reading a thread over on Hacker News in which Canonical was
getting praise for not actively fighting the community's decision
to switch from Upstart to systemd. In this discussion, past Canonical
projects that bucked the community were discussed, including Unity and
Mir. One comment read "[Unity] is a breath of fresh air compared to
most alternatives on linux."
That has not been my experience with Unity, and I commented as
such, but was immediately questioned as perhaps being part of a
community of "power users" that "never really used Unity". Au
Many of Unity's shortcomings stem from Canonical's ongoing proclivity
to attempt to reinvent common desktop interactions, regardless of the
cost it imposes on Ubuntu's least experienced users. Power users can
simply change environments, but new users are stuck with Unity's
limitations until they gain the expertise to switch away from it.
Caveat: I'm Using Unity 5.x
It's worth noting that the machine I've most recently used Unity on is
using the latest LTS release of Ubuntu, 12.04, which, as of this
writing, is still recommended on Ubuntu's site as the latest stable
release. Nevertheless, I realize that there's a good chance Unity 6
and Unity 7 have introduced improvements, and that not all features
have been backported to the 12.04 distro, so some of my comments may
be somewhat dated. That said, they do reflect the current state of a
fully-patched 12.04 system. With that caveat out of the way, let us
In writing this post, I fired up a Unity session on my Ubuntu box and
used it for an hour to refresh my memory on exact details of Unity's
behavior that disappointed me. In the first thirty minutes of usage,
Unity crashed twice during execution of routine operations (opening
the launcher to launch a program in both cases, actually). So Unity's
stability leaves something to be desired, even in 2014. I just moved
from Cinnamon to KDE4 a couple of weeks ago, and in that time, KDE
hasn't crashed even once. In months of Cinnamon usage on three
machines prior to that, I experienced only one crash. Having core
elements of your user experience crash regularly is undesirable, to be
Making Easy Things Difficult
One mistake Canonical continually makes is releasing beta software to
its user base, and making that software the default. Unity is perhaps
the canonical example of this (pardon the wordplay). The first commit
to Unity was made in October 2009, and it was made the default
environment in Ubuntu in the 11.04 release, after about 18 months of
development. Not surprisingly, the lack of maturity in the codebase
How Do I Add a Program to the Dash?
In most desktop environments, it's a common and simple operation to
create a menu item for an application installed outside of the usual
package management mechanisms. In KDE, for example, simply
right-clicking on the the menu icon and selecting "Edit Applications"
brings up an interface to add, remove and edit applications. It's a
common operation for many users.
Despite the utility of modifying entries in the Dash and Launcher,
Unity makes it difficult, simply by virtue of the fact that the
functionality is not included at all. Users that wish to change an
icon, description or simply add an executable that is not already
present have two options:
- Open a text editor and navigate to a hidden directory, creating a
.desktop file in a very particular format to make a new
program appear to Unity.
- Install a third-party applications like gnome-panel and
alacarte to allow programs to be added to the Unity
Launcher and Dash.
The fact the there is an extensive wiki page describing a series of
complex contortions a user must go through to access such basic
functionality is inexcusable. I don't mind steep learning curves, but
a product that makes simple actions time-consuming and complex doesn't
respect my time.
How Can I Resize the Launcher?
This is more of an illustrative point -- Unity absolutely allows users
to resize the launcher, even from within the GUI. But how? Can a
user just right click on the launcher and select the "Resize" option?
Or perhaps move the mouse to the edge of the Launcher and drag to
resize it? In fact, neither option works -- the setting is buried
inside of the settings application, under "Appearance". There, in a
panel that allows you to change the background for the desktop, there
is a slider that allows you to choose a launcher size between 32 and
64 pixels. That was only added in 2012, actually. Before that, it
was a hidden option, made available through custom configuration
editing or the use of the MyUnity tool.
Using KDE 4 as a counterpoint again, simply right clicking on any
panel on the screen pulls up a menu that allows the user to choose
"Panel Settings". From the settings interface (which is actually
attached to the panel being modified), panel position, width,
alignment, included widgets and auto-hide behavior are all easily
accessible. Compared to Unity, it is a triumph of design. For what
it's worth, similar functionality is available in Gnome 2, KDE 3,
Cinnamon, MATE, LXDE and XFCE.
In fact, Unity does so poorly at affording such obvious settings like
this that a whole ecosystem of tools has grown up around Unity in a
community-wide effort to add back all the basic features users expect
from their desktop environments, like resizing panels, adjusting
transparency, tuning auto-hide behavior and many others. It's worth
noting that features like this have been in Linux desktop environments
since the late 1990s, and having them missing in 2014 is simply
What's With Reordering Programs in the Launcher?
If you want to change the order that programs appear in the launcher,
you might think you could simply click on the icon of the program you
want to move and drag it to the desired position. Instead of moving
the program as intended, users will instead find that the entire set
of programs in the launcher is pulled in the direction the user drags,
only to snap back to the original position when the user releases the
mouse button. To actually rearrange the ordering of the icons, users
must first drag the icon out of the launcher (toward the center of the
desktop) and then back into the launcher in the desired position.
Making Advanced Features Impossible
OK, perhaps not impossible; just about anything is possible if
you're willing to write plugins or extensions. Unity relies on this
fact extensively, pushing basic functionality out of Unity and into
various plugins written by the community, each varying in terms of
quality, performance and maintenance. The result is a shoddy, ad
hoc ecosystem of spotty software each user is responsible for
cobbling together on a per-machine basis.
Hey, Mind if I Move the Launcher?
The Launcher panel is placed on the left side of the screen. That's
great for widescreen users, but it might be desirable to move it for
some users, either to the right side or even to the top or bottom. It
turns out that moving the launcher is impossible using the stock
software (one might imagine editing a configuration file somewhere).
Instead, moving the location of the Launcher requires an
unofficial Compiz plugin, not because of limited developer
resources, but rather by design. Here's
Mark Shuttleworth himself on this exact issue:
I think the report actually meant that the launcher should be movable
to other edges of the screen. I'm afraid that won't work with our
broader design goals, so we won't implement that.
Shuttleworth maintains this sort of an Apple-esqe attitude toward
dictating how users should use their computers. But it doesn't work
nearly as well in the Linux ecosystem as it does among Apple's users
that have come to expect a strictly controlled experience, from the
hardware all the way through the OS to the software (via app stores)
and into their cloud offerings and content store. Linux poses a
significantly different value proposition, and targets a different
What's My CPU Doing?
Every desktop environment on Linux supports adding some kind of system
monitoring applet that sits next to the system tray and task switcher.
Unity managed to not only launch without that one, but lacks most
other applets common to other desktop environments as well. Common
functionality that allows users to customize their environment is
completely absent in Unity, with right-clicks yielding identical
results to left-clicks on almost every visible UI element.
So, what does it take to get a simple CPU graph next to the system
As it turns out, users must install another custom piece of software
provided out-of-band from the main Unity development pipeline. Not
only does a user have to install the software manually, it's not even
included in the default repositories. Instead, the extension is
only available from a PPA (which must be added manually).
The situation with the CPU monitor is hardly unique. It turns out
that modifying practically anything about the top panel in Unity is
extraordinarily difficult, requiring research, custom hacks or entire
add-ons to obtain features built-in to KDE, Gnome, LXDE and XFCE.
Simple actions like adding another panel at the bottom of the screen,
adjusting auto-hide behavior, tuning transparency, and changing the
order of the icons on the right side are not possible in the default
In short, customizing Unity in common ways almost uniformly results in
a project. The sad part is that there are a lot of pieces of software
that afford the user a lot of customization and power, but it comes at
the cost of the learning curve. Unity actually is less powerful than
other desktop environments while simultaneously being harder to use.
It's the worst of both worlds.
The sad part is I can imagine how this all came to pass. The design
meetings for Unity must have been tough. A product manager was
charged with creating a unified interface suitable for both desktop
and touch-based devices. By that point, Unity already lost, simply
because of the design constraints imposed by such a goal. Consider:
- Right-click had to be removed from most elements, since
touch-based devices wouldn't be able to easily access the
- The launcher had to remain on the left side of the screen,
probably because different interaction expectations were designed
for the right side. You can see this clearly in their designs for
- Since the launcher could be packed full of the "favorite"
programs, it might overflow. But because it had to support touch,
it couldn't be shrunk to accommodate the program icons (as seen in
Apple's OS X). So instead, it had to allow the user to scroll it,
removing the ability to easily rearrange programs via dragging,
resulting in the contorted "drag out of the launcher and back in"
- Common panel widgets, like CPU monitoring, were put on the back
burner, if considered at all, since smaller devices don't have the
space to include them, or the battery life to constantly update
them. (See Dan Sandler's comment on Android battery life for
These are just examples, but the point is that by trying to present a
unified experience across all devices, Unity seriously compromises
quality as well. Touch devices don't feel quite right (why is there a
program launcher on the left side?), and desktops get a dumbed-down
version of a desktop (no right-click, for example).
So, What's Better?
The good news is that if you're looking for something better than
Unity, you don't have to look far: just about everything is better.
MATE (a fork of Gnome 2) is quite serviceable and I used it happily
for nine months. Cinnamon (a reskinning of Gnome 3) is equally usable
and, while light on features, perfectly serviceable. XFCE is my go-to
environment on my Linux gaming box.
I'd have to say the gold standard today, though, is really KDE 4. It
took years, but that team has taken all the lessons learned from KDE 3
and created a superbly powerful, well-designed and sleek desktop
environment. So, if you've got the Unity blues, KDE is just a
sudo apt-get install kde-full
11 Feb 2014
Back in 2012, when I joined the startup scene in San Francisco, I was
surprised to learn that so many took Klout seriously. They tracked
their Klout rating over time, comparing it with others, and even had
playful competitions to see who could increase their Klout score the
most over a couple of months.
When I first learned of Klout shortly after it came out, I didn't
think too much about it. It basically seemed like a one-number metric
to determine your influence online. As the years have passed since
Klout was launched, I see it more as an example of a how a deeply
flawed model of the internet has been popularized.
In the early- and mid-1990s, the internet was a loose federation of
institutions, mostly in the .gov and .edu spaces. Email was still
highly decentralized, since webmail didn't exist yet. If you were 'on
the internet', it was likely through your university or research
institution, and they might offer you 'web space' where you could
publish some HTML files that constituted your website (much like the
site you're reading right now). It was a beautifully organic system,
but was still nascent, reserved mostly for the technical elite.
Fast forward to today, and we find that almost all of the power on the
internet has been consolidated. Home pages have been replaced by
social network profiles on corporate-controlled sites like Facebook
and Twitter. Rather than providing space and bandwidth, these
companies are 'identity brokers', a much broader and more lucrative role
than a simple web host. I've never heard that term used before, but
it seems apt.
But with this inevitable commercialization of identity online comes
second-tier services that analyze the resulting structure. Where
Google sought to analyze the inter-connectivity of the sites on the
internet, Facebook sought to rebuild the internet from the inside out,
replacing home pages and web hosts with profile pages that Facebook
could track metrics on, like popularity. As competition grew and
other niche networks joined the fray, an opportunity arose for
companies like Klout to act as a sort of meta-analyzer, analyzing
identity and profiles across social networks, delivering a satisfying
number letting you know your worth online.
As I was sitting at lunch earlier this week, a coworker asked me "Hey,
what do you think of Klout?" I paused only for a moment before
replying "Honestly? I think it's bullshit."
There are a couple of problems with Klout, one flowing from the other.
Klout is built on the idea that a person's influence online is
governed by the profiles they keep in large, corporate-controlled
networks. If a person doesn't buy into the notion that social
interaction online should be mediated by these identity brokers, Klout
simply ignores them. It's not the worst assumption to make, however,
in an age where The Pope has a Twitter account.
The second problem, an inevitable outgrowth of the assumption that
social networks are the source of influence, is that Klout completely
ignores other sources of influence. If someone has a blog with 500k
subscribers via RSS, it is invisible to Klout. If someone is a top
commentor on Slashdot, a top poster on Reddit, in the top 1% of
StackExchange users for C++, or has 10k followers on YouTube, they
might be completely invisible to Klout, and at the very least, all
those contributions online won't contribute to Klout's notion of
And that's the crux of the issue. My identity online is a handle I've
spent years building across dozens (probably hundreds, to be honest)
of sites. While it's in Facebook's and Google's and Twitter's best
interest for my identity to be tied to their service, I believe that
identity and influence cannot be so easily corralled.
And that's the real problem with Klout: it reinforces this notion that
the identity brokers dictate reality. When I joined the startup, a
senior employee told me "You don't exist online!" I was confused,
since I have at least two different blogs, and have fairly active
accounts with G+, Youtube, Reddit, Twitter, StackExchange, Slashdot
and GitHub. When I asked her what she meant, she simply said "You
have no Facebook profile!" Even in my case, where I maintain multiple
profiles on sites controlled by identity brokers, it still wasn't
enough; they have to be the right identity brokers.