Regular Collector, Occasional Reader

I'm a regular collector but occasional reader of books.

Currently reading Conceptual Blockbusting: A Guide to Better Ideas by James L. Adams (4th Edition), a book I bought about 8-9 years ago :)

SourceForge.net comeback?

Just when I thought SourceForge.net had become irrelevant, I find myself pleasantly surprised at what they've been upto.

Here are a few reasons I think they are headed in the right direction:

* A new uncluttered homepage with a cool infographic:



* They've kept up with the DVCS trend and now support GIT along with Mercurial and Bazaar.

* They deprecated some of their crufty, less-capable built-in applications and replaced them with some great open-source applications on their Hosted Apps service so that they could focus their development time on providing great service.

* Provide direct support via freenode IRC.

* And most importantly, all of the above seem to be a result of the conversations they are having with their users (blog, twitter).

Conversational Applications

One of the principles of Owe.to was that it had to be conversational. This means that instead of the traditional filling-up-a-form experience of web applications, it should feel like you are talking to Owe.to. I first came across this when I saw the Huffduffer sign up page:



This is what I came up with for Owe.to:



Forms that are conversational come with a unique set of issues that you need to deal with to make them usable for the user. For one, they don't have labels, and the user has to figure out what he needs to fill in based on the context. I came up with a way to provide additional context using a sort of dynamic label that I call Callout Labels that appear when the form field receives focus (think this evolved from a tooltip suggestion by Jinesh):



How about help text? The traditional way of displaying help text around the form field was not feasible, so I had to display greyed out help text inside the form field itself that disappears when it receives focus (look at the previous two images). Although this technique is wide spread (for example, in search forms) it hit home in the context of Owe.to when I came across Twitpay:



Another interesting issue is figuring out how to display validation errors. I'm not there yet with Owe.to, but I like how Huffduffer does this:

Owe.to Design Principles

Principles that help guide Owe.to's personality and the experience it provides:

• Indirect: To overcome the awkwardness of asking friends to pay you back, you should not have to address the friend directly.


• Conversational: Instead of the experience of filling up a form, you should feel like you are talking to Owe.to.


• Peace of mind: Telling Owe.to about a friend, should mean that you can forget about it because Owe.to will remember, and repeatedly remind the friend till a resolution is reached.


• Quick and easy: Collect the least possible information from you to reduce the investment required by you to try-out/use the service.


• Terse: Reduce the amount of information you need to process.


• Incremental: Like real people, the personality of Owe.to and the experience it provides, will keep developing (changing/growing/evolving) over time.

Owe.to's story began when I saw a friend of mine asking another friend of ours, to help him collect money from the people he had paid for the previous night clubbing. At that moment, I realized just how awkward it is for some people to ask friends to pay them back. That incident compelled me to start development on Owe.to, a service to remind friends to pay you back, without the awkwardness!

Why I prefer Prioritylog over Backlog

Backlog has negative connotations for me; of not keeping up (falling behind), of making slow progress, etc.

I prefer Prioritylog instead, because it emphasizes the fact that the list should be prioritized (so that it can be pulled from).