Broken Perspective Posted by Picasa

This entry was written by Amit, posted on October 19, 2005 at 1:36 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Upgrading software without annoying users

I like the concept of automatically updating software applications. However, they way it is done in most applications annoys me.

Case in point, Adobe Acrobat Reader. I click on a PDF file and up comes Acrobat. Somehow while its getting ready to perform its “acrobatics” it deems it necessary to see if my software is up to date. All of a sudden, it becomes very important for me to pay attention to the latest available updates and patches. Never mind the document I was so eager to read.

Alan Cooper said each dialog box is a room and there should a good reason to take the user away to a different room.

So I was on my way to a room to read a document but suddenly this friend of mine, acrobat, pulled me away, hurried me into this other room and started showing me all this cool stuff that he thinks I should download right now.

Ok, not interested right now? No problems. ‘Cancel’ and it will let me go where I was going originally.

Until the next time I want to read a PDF document.

Moral of the story: Checking for updates may be fine upon launching the software, however, confronting the user upon launch is certainly rude.

There are times when the software “punishes” the user by not allowing them to proceed unless they update the software right away. Users of MSN or Yahoo Messengers have experienced this on more than one occasion.

Its like going to a party and being greeted at the door with “we cannot allow you to proceed unless you go home and change your clothes. What you have on does not work anymore.”

Wow! What happened here? No one had even forewarned me this was coming. I cannot play unless I “upgrade”. Never mind, what I set out to do originally, it is not important right now.

Hey Mr. developer, how about letting me know in advance a day or two? Also why not upgrade me when I am shutting down, preferrably in silent mode. I don’t like the sentry at the gate asking me to upgrade.

If there is a critical bug that inadvertently slipped into the program and I must upgrade in order to protect myself from the all things evil, then prehaps I would not mind if you upgraded me, without presenting me with an elaborate Yes, No, Cancel choice and Then told me about it later in an unobtrusive manner.

You can even ink this understanding between us, in writing in that beautiful piece of “agreement” that I accepted before you let me install your application.

Here is a partial list of software programs I know that offend with automatic upgrade suggestions and occasional forced commands:

1. Adobe Acrobat Reader
2. MSN Messenger
3. Yahoo Messenger
4. Azureus BitTorrent client
5. Winamp
6. Konfabulator (used to before yahoo bought it)
7. Dell Updates (Dell’s version of Windows Update Balloon, only bigger and more annoying)
8. iTunes
9. QuickTime
10. iPod Updater Software
11. RealPlayer
12. Norton AntiVirus
13. McAfee AntiVirus

And here is a partial list of software that do not have sentries guarding their launch(I am not saying their mechanism is ideal)

1. Mozilla Firefox
2. Grisoft AVG AntiVirus
3. Windows Media Player
4. Microsoft Windows
5. Any Microsoft Office product
6. Calculator

In the same vein, there are some who would argue, that automatic updates without users explicit permission upon launch are purely evil and big-brotherly (see The Risk of Programs that Update Automatically).

If a software company wants to steal information from you, it is likely that by you simply choosing to acknowledge an update is not going to prevent this.

So it seems that we need a better way to be able to update installed software, make it less obtrusive, keeping users informed of exactly what is being updated here and why it became necessary.

This entry was written by Amit, posted on at 11:14 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.


Java Mask (Nothing to do with Sun) Posted by Picasa

This entry was written by Amit, posted on October 18, 2005 at 5:19 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

The world is not enough.

For weeks I have been trying to write an article on a new software process. I think I will just save myself some trouble. The world does not need another software process. However, it could use some new ideas and fresh thoughts.

My basic idea stems from the dismal amount of actual user input used to improve the product in software development in general. The problem is simple, most software developers do not see their product in action enough.

Bottom line: the improvements doled out in general are dismal. This is true for any product. I for one, very rarely will buy version 1.0 of a product. It scares me. I refuse to be the guinea pig, since I know my experiences do not count in the big picture. Unless I plan to start a revolution against the product, no one is listening.

Back in the software company, group of managers, marketing experts and developers are huddled together trying to figure out what to do next. Maybe they even have some user representative (most likely someone on company’s payroll). But you know what, I am not there.

Neither are other hapless users like me.

The developers have no idea what I am going through. We are just not building software like that.

Lets take the example of the telephone. Decades of development must have gone into perfecting the instrument. How many people can transfer a call successfully upon first using a new instrument? I rest my case.

How do we fight back? Simply refusing to accept that our voice will not be heard.

Typically as a user, when I complain, I am not talking to the actual developer. I am talking to a customer support person. This person is probably as ignored in the organization as I am. Moreover, this person is dealing with a SEP (Someone else’s problem). Plus I am probably angry or frustrated(which is why I bothered to call). Now he has a vested interest in helping me, however, he is approaching this from point of view of solving a problem, getting through the call satisfactorily. That’s all.

For software producers, aiming to exceed customer expectations, is not a worthy goal, since via decades of software torture, we have set the bar really low.

For more amusing reading, please visit http://discuss.joelonsoftware.com/default.asp?joel.3.229139.16

This entry was written by Amit, posted on at 9:51 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

How would you improve iPod’s interface?

Needless to say, I think iPod’s navigation system and user interface needs improvement. Don’t agree with me?

The entire navigation system is based on IDE tags. Why such heavy reliance on IDE tags? I haven’t figured out the answer. I can only guess: iTunes relys heavily on IDE tags as well.

Which brings up next question: Why are we forced to use iTunes? My guess at the answer: so we would be more likely to buy music from iTunes store.

So ideally for Apple, every iPod user would conform to their vision of the world of digital music: Buy your songs at iTunes Store, put them into your iPod and viola! life is great.

Well not so much. I already happened to own most of the music I want on my iPod, and most of it does not have IDE tags, because maybe CDDB never heard of a CD called “Flavors of India”, but I would still like to be able to listen to the songs in and be able to find them easily without having to go through and tag each song.

Genre must be the most useless piece of IDE tagging. I have not seen much agreement on what “genre” particular music belongs to. Hence, to me the concept of intelligent genre based playlists is pretty useless. Instead, I would like to create playlists based on artists, albums and at the same time take items off the playlist, all this without having to connect my iPod the computer.

Would it be that hard to provide an alternative means to browse music in iTunes and iPod such as simple directory based browsing with the ability to create new folders.

Of course a way to search for a song or artist would be great as well instead of relying just on the scroll wheel. People seem to be getting on fine using tiny phone keyboards for sending SMS, i am sure something better is achievable for the iPod for text input.

How about a real equalizer instead of forced presets only?

Its difficult to create multiple playlists dynamically while playing ( a problem not unique to iPod). If I download a new album to my iPod and while listening to it, I wish to add a song from the current album to my “Work out” playlist, I should be able to do so without a visit to my computer.

Why on earth will my iPod not let me “delete” songs? Were the designers just worried that my iPod was destined to be passed around among lots of hands and one of them could “accidentally” delete my song? iTunes does not prevent this, why does iPod?

Why not let me enqueue songs as I try to fend multiple requests from friends one after another? And if crossfades the queued songs, that would make it really rock.

Lastly, I would like to be able to manually switch off the backlight once its on.

This entry was written by Amit, posted on October 5, 2005 at 1:27 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

PowerPoint, FluffPoint or PointLess?

In spirit of PowerPoint, this article consists of some bullet points:

  • Do people in top management really love PowerPoint?
  • Is PowerPoint taught as part of Harvard MBA?
  • Would people learn less if you had a blank sheet up?
  • What is the difference between PowerPoint and a Power Tie?
  • Can me and you talk without a bullet between us?
  • What is Bill Gate’s favorite slide?

This entry was written by Amit, posted on October 4, 2005 at 8:45 am, filed under Uncategorized. Leave a comment or view the discussion at the permalink.

Responding to RFPs

I have always wondered why it takes so much effort to respond to a software request for proposal. Well I received an answer not too long ago. My company received a request to respond to a RFP for a software project. The requester gave us one week to finish and ship off the proposal. They had pretty detailed requirements. You know the kind of lengthy requirements document, where every thing is described in painstaking details? Well, we had one of those documents. A fourteen page requirements document, followed by one hundred and fourteen pages of details flowing out of each of the requirements. “Wow”, I said to myself, to thoroughly go through and understand each of these flows themselves would eat up two to three days, leaving no time to actually come up with a proposal. Of course, no desired technology was indicated, leaving it up to the responder to do a lot of guessing.

Day 1
I was responsible for the “solution architecture” piece. The request had already given the code-drop date, which was going to be in three months. This told me that they had probably estimated the project already in some fashion or at least the budget. It also indicated that they already knew what technology it was going to be in and they had a fair amount of idea about what kind of product they were going with.

Someone in technical sales told me, “no Microsoft”. I asked why and the answer was “well I remember hearing somewhere that they are looking for a J2EE solution, and also, we don’t have any in-house expertise on that”. Good reasons? Maybe or maybe not. Again, important to know such tribal knowledge, which can prevent you from going down a tangent path.

Day 2-5
With four days left, my initial thought was that it was sufficient time to come up with a decent very high level architectural proposal, if I took the initial approach of comparing couple of options. I wanted to compare Microsoft’s and Sun’s solution. The project manager immediately questioned this approach and asked why we wouldn’t simply recommend a solution. I thought to myself, well unless I compare options myself, how would I recommend it to a client and on what basis?

The person in-charge of the whole affair asked me my recommendations on building portals with pre-built shopping cart software and other functionality. My response was to go with third party or build one. He said there is no time to build one. I could sense that he was trying to gauge, how confident I was in terms of coming up with a viable solution in ten minutes. On the surface it seemed that everyone else had a pretty good handle on how to go about this. In retrospect, the whole affair was very chaotic. Chaos is not a bad thing sometimes, but it is apparent that we did not have proper process in place which could even guide us towards a goal. So I sat down to write my thoughts on what some best practices should be. I came up with a list which by no means is exhaustive. However, I have tried to capture the approaches which were absent and seemed to contribute to the chaos the most.

Following are some things to keep in mind when responding to a RFP:

Treat the effort like a mini-project with To-dos and Milestones. Using something as simple as an Excel spreadsheet, or a free project created using Basecamp can do wonders to keep everyone on the same page regarding the totality of the work involved, who’s responsible for what and when things are due. Don’t take days to come up with a plan. In a couple of hours, you should be able to come up with the basic outline and then allow others to add/edit it as time goes by.
Must have a document collaboration system in place. Multiple authors working on separate copies of a document adds to the misery of formatting, collating, merging. We actually lost content due to such problems. A document version control system is a must. Some organizations have Sharepoint, but something as simple as a wiki software or open source document management software such as Alfresco will suffice.

A writer & document expert must be on the team from the start. Flair for writing is a talent available in lesser quantities in technical teams. Having a writer guide the proposal effort helps with the language and keeping varies styles consistent. Not all of us are word processing software experts. Someone who does this for a living such as a technical writer or author must be part of team. I cannot recover the hours we spent trying to make bullet points consistent and format tables.

Avoid Copy Paste Misery. Most proposals are not written from scratch. Most are a customized version of bits and pieces captured from previous responses. Given such highly reusable nature of responses, it goes without saying that responses should be easily accessible, word-searchable (google desktop does a nice job of searching word documents), highly modularized. All of the above will make it easy for people to quickly assimilate content from disparate proposals.

Get the team into selling mode. The team must be able to visualize what the requester is hoping for. Upfront there is little or no formal effort spent on this. Key people are sent off in their directions to fetch appropriate content. What exactly defines this appropriate content is based on the requester and their problem. The team must start thinking of what is being expected, what the general tone of the RFP is? A common platform and pitch must emerge in the initial hours and the team must remain on message throughout their effort.

Tackle hard questions early on. A natural tendency for the responder will be to focus on their core competencies and worry about fringe unknown areas later. This translates into not worrying about the fringe areas at all. A good response will have all the areas of the proposal covered, not just the areas they are comfortable with. Make a list of these areas early on and tackle them head on.

Identify risks. The project might be an impossible one, or there might be risks. Hiding or ignoring the risks may prove fatal ultimately. The response should clearly lay out the risks from the beginning with a mitigation strategy. If you see an unreasonable request, it should be pointed out with a possibility of discussion on the topic.

Do not ignore the competition. Its not very hard to guess the competition. The response exercises should include a phase on researching the competition. What are they likely to respond with? What are their core competencies? Can you show in your response, how you are better than your competition?

Do not compete on price alone. Chances are there is some way estimations are done in your organization. Even if you rely completely on developer input based on experience, spend some time on it. Any estimation effort that is only a couple of hours is likely off the target. However, revisiting the estimate and applying couple of different models is a good practice. I saw hours spent in debates over the final price, but I did not see any effort to revisit the estimations. Do this work early on, so later if the top bosses are not happy with your final quote, you can show multiple estimation models to support your numbers.

Keep the last day for formatting and cosmetic fixes only. Editing the response till the last day can prove disastrous. In our case, we forgot to update the table of contents of the final document. It is easy to get carried away with content, and at the last moment, the overall look of the document will suffer. Avoid finishing the content on the last day.

Keep the document interesting and brief. Actual humans are going to read your response. Not only that, they are also going to read many such similar responses. Keep the response succinct. This is a not a writing competition. Neither the party with most words is going to win the bid. If you can demonstrate early on that what you have to say can be easily understood by the requester, you are half way there already.

Figure out the request theme. Early on, before you dive deep into the response, spend some time figuring out some key themes that emerge from the RFP. Write the themes on a whiteboard, discuss them with the team and make sure the response addresses the pertinent themes all the way.

Review, review, review. Chances are by the end, all involved parties in the response creation are suffering from document fatigue. At this point, you need fresh eyes to correct, update and enhance the content. You will need more than one person to review and comment on the document.

Do not overwork the team. If the time to respond is short, the requester probably does not want you to create a weighty door stopper. Keep it short. This will also allow the team to do quality work and not just quantity work. If everyone works around the clock to come up with material, chances are they are not reviewing each other’s work and mistakes are slipping by. The work you demonstrate in the response is the first clue to the requester about the eventual quality of the software you are promising to deliver. Also, to the team it is an indication of how the actual project might be run. Don’t scare them from the get go. Keep the load reasonable and quality high.

In summary, it takes cool heads who can keep the zeal to create reams of document under control, to produce a sharp looking response to a RFP. The best practices you demonstrate while responding are only an indicator of how the actual project will be done. The objective is not just to win the bid with a stellar response, but be able to execute and deliver what is promised in the response. So remember, proposing the plan is the just the beginning of the battle. Keep an eye on the final goal of how the project will be delivered and the response will speak for itself.

This entry was written by Amit, posted on September 20, 2005 at 10:18 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.


» Next Entries