Comments (0)

By Krishna, October 15, 2006

Compartmentalization of thought is something you need when browsing the web. You can get bogged down or frustrated in the banner ads and all the other clutter that comes up, but if you just accept and train yourself to ignore them, then it will stop bothering you.

This is obviously not a recommendation that Google or other ad providers would support, especially since a significant percentage of web content is sponsored by advertisements. But I digress…

So here is what happened the other day. Google chat has this “cute” feature to save the chat sessions into Gmail. (I wish they would do something similar by integrating Google Reader into Gmail, but again I go on a tangent). So anyway, I was having a discussion with an analyst on my team about the need to explore 3rd party controls for a particular functionality that we needed to have in the application.

After the discussion, I go back to Gmail to check the discussion again. As I said before, I normally tune out the ads displayed, but this time, something caught my attention. The ad engine displayed a few relevant products. I clicked on one of these and found what I wanted, which I passed onto my analyst.

This is the sort of functionality that really does the job for users. By getting it right in this case, the Google ad stopped being a nuisance and served a legitimate, useful purpose for the user. How much of the functionality of your product helps the user and how much of it gets in their way or just plain irritates them? Something to think about!

Comments (2)

By Krishna, October 15, 2006

The Writely service, now renamed Google Docs & Spreadsheets seems to be a step in the direction of where computing seems to be headed: Less of the heavyweight desktop applications and more of web-based applications to do the tasks that one needs to do. This concept is really not up for debate – hundreds of desktop applications have migrated to the web as browsers have increased in capabilities.

Unfortunately, as much as I would like to see a true Word processor web application, I don’t think Google Docs is close to getting there. Here are some of my frustrations:

1. Editing a document of any reasonable length is incredibly difficult. Obviously there is no Outlining function to easily navigate the document.
2. I uploaded a document with a few tables. Copying and pasting the table cells and rows around, which is very easy in MS Word, is a real pain. Matter of fact, it doesn’t work at all in the expected way and instead I had to manually insert rows and copy data cell by cell.
3. The copy and paste function asks about granting permission to Windows Clipboard and whatever I tried to do wouldn’t overwrite what was already there in the Clipboard from another application. An idea: Why isn’t the copied (or cut) data stored on & received back from the server through Ajax?
4. When inserting new content, the document reverts back to its original formatting for the new content instead of the formatting that is used for the text before and after the new content. More work to format.

Even granting that people only use 20% (or less) of the functionality in Microsoft Word, Google Docs doesn’t meet the requirements of a reasonable word processor. It is clumsy, awkward and just doesn’t feel comfortable.

The only argument I can see in favor of Google Docs is that it perhaps has a different value proposition. Multiple users being able to edit the same document, the ability to see multiple revisions of the collaborated-upon document, and the web-based advantages may perhaps make for the lack of good editing capabilities.

In summary, at least in the short-term, I would see Google Docs as a complement to Microsoft Word rather than a substitute.

Comments (0)

By Krishna, October 4, 2006

In many client dealings, there is a conflict between what the development team terms as a “change request” and what the client treats as a “bug”. If new tasks or change requests are treated as bugs, it gives the impression that the team has delivered a poor product.

Change requests need a lot of effort and cannot be fixed easily, especially when the system is very large. As the system becomes larger, the change requests exponentially increase the time to change the design and regression failures become common. When the original architecture was not designed to accommodate the present requests, it makes it all the more harder.

In Agile methodology, there is the concept of “YAGNI” (You Aren’t Going to Need It). This means that one should design architectures without worrying about future requirements. It is useful in some cases to do this so that one does not fall into the trap of “analysis paralysis” – otherwise it is very difficult to move forward with the project. The intent is to expect change.

But the problem is that change is very expensive. Even without extensive documentation needs, here is the time required for a developer

1. Time to understand the requirements
2. Time to understand the code changes required in the specific module
3. Time to understand the implications for code changes and functionalities in other modules
4. Time to understand the validations and error handling

The “time to think” is very important, otherwise the developer will be making more important design decisions as they code (instead of before they code). This wastes time. Also it may hide design decisions from the project analyst, architect or designer.