Necessary Compromise or Unnecessary Surrender?

Four months ago, I had a discussion with a developer about a need for a new Eclipse RCP Table widget that facilitates multi-row selection for novice computer users.

One solution was to use one of the check-box based tables that allow you to select multiple rows by checking them one by one. Once you have a group of selected rows, you can then right-click on one of them and select an operation (delete, print, etc...), and it will be performed on the whole group. If you right-click on an unselected row however, the whole row gets highlighted and you get to perform operations on that single row.

The design seemed good enough for our needs, but it raised a big concern about whether it would satisfy expert users that prefer to hold the shift button and click on a row to make large-scale selections. After some discussion and brainstorming, we ended giving up on the idea all together and reverting back to the traditional Table widget.

I was not satisifed however and kept believing that if we persist in designing a Table widget that would satisfy both novice and expert users, we would eventually reach our goal with little compromise.

Indeed, upon checking the checkbox Table widget in GMail, I discovered that they solved the problem by allowing expert users to first check a row, and then hold SHIFT while clicking within the checkbox area of another row (instead of clicking on the row itself), ending up checking all rows in between.

The lesson learned was that when a decision on something involves a compromise, always double-check it to see if the compromise is truly necessary or is an otherwise unnecessary surrender to the situation. By being super-optimistic about achieving your requirements regardless of the obstacles on the surface, you may often figure out a way to have it all with minimal compromise.