Programming the web browser....

It had to happen ... so it did. A bunch of Usability researchers have put together a simple little Firefox addon called Chickenfoot that helps you program your web browser to complete simple tasks. Just in case you are going whaaaa? Here is a small example of what you can do in Chickenfoot and you will get the idea.

-----
go("google.com")
enter("Rajesh Vasa")
click("google search")
----

They provide a few more functions to help perform common tasks, and the language they created is an extension of Javascript.

Opera has recently announced on their blog, that they too have started to add similar functionality and should seep slowly into their stable releases. Firefox will most likely not make this a core functionality, since this is not really something most end-users will care for.

Now why is this great? What is the pain point that they are attempting to address?

To start with, this is real cool -- but will developers bother learning it and using it beyond 15-20 min? One area that I think it can help a lot is in making a certain category of testing scripts -- and there is no reason why this cannot be used in a rudimentary way for Test driven development for web applications. The other area that it can be used is for developing Firefox extensions (it has a button in the Development interface to deploy the code as an extension). The language and interface are simple enough to be used as an educational language to teach someone getting into programming (or) is keen to learn a bit more about programming.

It is always good to see incremental developments that have a potential to have an impact.

Problem Space Vs Solution Space

Software systems are generally built to satisfy a set of requirements. Unfortunately, typical requirement documentation states the intended solution rather than present the key problem. But, to build good software, the developers need access to the problem statement, ideally a set of pain points for each category of user. Why bother?? Because the developers are able to make better decisions.

A well stated pain point should be::

1. Specific (Clear, context sensitive and well scoped)
2. Measurable (ideally objectively, but appropriate subjective measures can work)
3. Current (as opposed to may happen in the future)
---
A simple example to illustrate my point::
Solution: "I want to take Road-43 and taken exit-10 to arrive at the airport"
Pain point: "I need to catch an international flight at 4:45pm from Airport-X, I am currently in Location-Y"

Software documentation is often provided as a set of solution statements.
This hides the context as well as the real issue making it harder (than it already is) for the developers (or problem solvers) to find the most effective solution.

Why does this matter? Because, software development is all about making a series of decisions. Decisions made with the context of the real problem are very different from those we make if the input is a partial solution. Good decisions more of then than not lead to good software.
------

Note: I am capturing these thoughts to be refined into a set of notes on how to go about building software systems. Feedback/comments are very much appreciated. I may edit old posts to clarify and better state my ideas as well.