Monthly Archives: April 2010

Thinking about user experience is exhilirating


After 3+ years of doing technical marketing for an embedded software B2B product I am only now realizing how much I’ve missed all things connected to consumers, user interfaces and user experience.

Thinking about all the great things we can do with our JustLiked app gets me really excited about the future, so is learning JQuery and Django and brushing up on HTML. But that’s just the boring part of learning, the really cool part is putting our humble assumptions in front of real people and iterating like mad. Alas, I know have the opportunity to do so.

The whole lean startup movement (which I’ve been thinking a lot about lately), its product and customer development cycles, its learn and iterate fast mantra are a natural fit for web/mobile/consumer apps where we don’t ship boxes, manufacture anything or have complicated IP licensing terms for legal to review over the course of 2 months. I know the grass is always greener on the other side, I am just hopeful that everyone on the other side appreciates how good they have it there. I do too now.

To say that consumer play is an entirely different ballgame from B2B is to say nothing at all. It’s two different universes, and I am about to find out how well I fare in this new one.


What do IRC, Twitter and a sense of bewilderment have in common?


My first run in with IRC happened about 10 years ago. I was taking CS3210 class (now defunct) at Georgia Tech where we had to learn about OS internals by finding our way around the Linux kernel. We tried out all of our little kernel hacks on a Compaq iPaq device to which we had root access. Those were some fun projects, and at one point I found myself on an IRC channel dedicated to helping Linux newbies playing with iPaq’s.

Twitter feed circa 1740 (or IRC chat capture, I couldn't quite tell)

I don’t really remember what I was looking for or what brought me there, but what stayed with me was the memory of utter bewilderment and incomprehensibility of this mode of communication. I understood IM; I understood older, 90’s style chatrooms, and I was for all intents and purposes a technically inclined person, a kernel hacker even.

IRC to me was something arcane. This feeling was reinforced by bizarre server messages, cryptic lingo, strange interfaces, and routine and nonchalant rudeness heaped onto newbies. The more I think about it the more negative a user experience I am able to recall. Now here we are in 2010, and I have this conversation with a friend, who is a Twitter virgin, explaining what Twitter is all about (Conversation was shortened and paraphrased, identities of those involved protected.):

me: these are microblogs. every message is like an SMS, just 140 characters long. i.e. there are a lot of small messages on different subjects.

friend: clearly i don’t get it :)

me: here is an example: i know it’s complicated :)

friend: it looks like random ravings, crazy talk

me: thanks :) context is everything. people are exchanging messages, and without context it’s really hard to understand.

friend: is there no better place where messages like this can be exchanged? i mean, this is completely out in the open, right?

me: yes, exactly

friend: it seems people who tweet do so either out of loneliness or sheer boredom. i can’t see any other reason.

<end scene>

So there you have it…

I think the two experiences have more than enough in common. Despite the fact that Twitter and IRC are two applications designed for two ends of technically savvy spectrum, I would argue that neither one offers an optimal experience for its audience and new users especially. Yes, both are immensely popular, but as long as the latter conversation takes place how could anyone argue about Twitter entering mainstream?

I don’t want to knock Twitter (or IRC). Not all apps are designed for Normals. In fact, great apps can deliver great value without being designed for Normals, and I think Twitter is a living proof that. But I also think there are simple things that Twitter and IRC could do, really minor cosmetic stuff in view of everything else that’s been done, that could vastly improve user experience.

But the point is even if Twitters of this world choose not to budge, it doesn’t matter. It only matters that we choose to do it right in our application.

Some thoughts on API use and design


All software is building blocks. Exceptionally good software is constructed from orthogonal pieces that fit together like they belong nowhere else, are interchangeable and make the overall structure only marginally more complicated than the components from which it is built. The “seams” or the interfaces between the blocks are the APIs, and it is here, I claim, that most engineering magic happens.

In my experience API design is extremely labor intensive, generally under-appreciated, hard to learn and harder still to teach. The design is almost never right the first time around (or the second time around, for that matter), yet the difference between good APIs and bad ones can be appreciated by looking at software structures that given API makes possible. To give you another analogy from architecture, bad APIs give us shacks cobbled together and teetering on the verge of collapse and good APIs give us Notre Dame cathedrals.

Increasingly software design is all about combining of-the-shelf components into a coherent whole. I’ve noticed it in my day job and while working on JustLiked. The amount of software packages freely available on the internet is staggering and each comes with its own API. In the end we do less in-house API design and more gluing. And every time we need to glue something together, we are faced with the question of what and how to glue.

I think the temptation to reinvent the wheel is huge, so the answer to the question of what and how to glue is often “let’s roll our own”. I don’t mean we are just tempted to write more software–we are tempted to write software which is designed for more reuse than it will ever see. The latter tendency preempts the process of selecting from available  components with designing our own with its own API. I’ve fallen into this trap myself recently, and all I have to say is:

Don’t reinvent the wheel, instead trust the API you are given.

In my view it’s much better to err on the side of more glue than designing a new self-contained, interchangeable building block to fill the void. The more “exposed” and “universal” you want to make these new building blocks and their APIs the less likely you are to succeed on time and on budget. It’s my subjective opinion, but it’s served me well over the years.

Once you find the component you need, use it in the way that it was intended to be used. Every technology has its sweet spot where it shines, so let it shine. Even if you can’t find something that fits perfectly, don’t kludge together a brand new component with its marginally better API because there are hidden dimensions, the secret sauce of API design that you haven’t mastered yet and it will come back and mercilessly haunt you way past your project deadline.

And even when you know what you are doing, make sure that what you are about to do actually gets you any closer to a business objective. Chances are it doesn’t, unless of course you are building an SDK.

What we learned by polling people (part 2)


Picking up where I left of last time talking about getting people to vote, once you get them to vote, what do they actually vote for?

Here too we were surprised by the results:

  • JustLiked – 66%
  • LikeWisely – 18%
  • Irresistibly – 16%

Frankly speaking before we set out to do the polling I expected JustLiked and LikeWisely percentages to be reversed. I would have probably bet money on it too. Not on the spread, but at least on the winning order. Alas, the people have proven me wrong.

So why JustLiked? Trying to think about it is an exercise in pure conjecture. I think it’s the most understandable and accessible choice, which doesn’t require the mental agility and imagination of the two other choice (if you voted that way, I am sorry :) ).

I am the author of LikeWisely option and I found it heartbreaking that only 18% appreciated subtlety, fine nuance and play on words I worked so hard to mix in there — “wisdom”, “likeness”, and the ever-popular .ly top-level domain all baked into one cool name. What else could you ask for? Apparently, JustLiked.

There was some palpable co-founder tension around the names, and I am glad we are past that now. In fact getting an independent opinion was one of the reasons to do the poll in the fist place. After all you can’t argue with vox populi. The other reason for doing it this was to curb the irrational enthusiasm each one attached to the name he picked.

So thank you all for taking part in this experiment. And just like this we are now JustLiked.