The Ripple Effect
Software by it’s very nature, tends towards complexity.
When a program is in it’s infancy, with few features and few lines of code, adding a new feature can usually be done quickly. But as the program evolves, although adding a new feature may still be quick and easy it may cause little side effects in other parts of a program. So adding the new feature may not take long but adjusting the rest of the program so that everything flows properly will take time.
Think of stable software as a calm pond, with a surface smooth as glass and adding a feature is like throwing a pebble in that pond, which causes ripples that need to be dealt with. One of the things that distinguishes a junior from a senior programmer is that the junior programmer will not foresee these ripples and will think he has completed his task prematurely.
To illustrate what I’m talking about I’m going to talk about a new feature that will be in the next SunFlower release.
The Problem
Snapshots in SunFlower can pile up, and eventually you need to delete some. To delete a snapshot you must control-click on the snapshot and choose delete.
This interface works but is kludgey. It’s not convenient when you need to delete many snapshots because control-clicking on each snapshot is slow and cumbersome. There is definitely room for improvement in this interface.
The Solution
The solution is simple. Add a delete button that appears when the user positions the mouse over the snapshot. This is an established interface, it’s how Safari deals with the close buttons for tabs without making the interface feel cluttered.
The Ripples
So what were some of the ripples caused by adding the delete button?
Because the user can navigate the snapshots with the keyboard, we need to detect if the mouse is over a snapshot after keyboard events. We cannot simply use mouse move events to detect if the delete button should be shown. ((Ripple.))
In this case most of the ripples were design based. Snapshots have a state of being “read” or “unread”, and an image is displayed on the top right corner when the snapshot is brand new.
Having two images represent different things with varying red colours is not good. So the unread marker image now needs to be changed. ((Ripple.)) I could change the colour of the unread image to green but I’d prefer that both images weren’t the same shape to prevent confusion. ((Ripple.)) The delete button has nice shading and puts the unread marker image to shame so the ante has been upped. ((Ripple.))
Addendum (Aug 03 2009)
Brent Simmons describes this concept in more detail in a recent blog posting.
It’s not enough just to write the basic functionality and add a menu item that runs it. Even a feature as simple as this one requires some up-front thinking, some design.
…
The code behind the feedback window is, again, bigger than the http-call code. (By now you’ve gotten the idea that the core functionality of a feature is often the very smallest part.)