Saturday, May 06, 2006

Evolution of a Feature: The MacGourmet Relationship Manger

On Software DesignEver wonder how application features evolve and change during development? Wonder what goes into these evolutions and changes? I thought I'd post an example of how this process can sometimes work using a feature from MacGourmet 2. This is by no means the only example of how things work for everyone, or even of how things always work when I develop or change a feature, but I thought it might be a good example of how sometimes a solution is far simpler in the end than at the beginning.

In the current version of MacGourmet there is a utility window that allows you to set up relationships between things say, two recipes, or a recipe and a wine. I've never really liked how this works. There were essentially two problems with the version found in MacGourmet 1: one is that the selected item could change when you didn't want it to, which could make the drag and drop method of setting up relationships difficult. The second was that there was no way to get from the listed items to the actual items in your recipe box.

For my first attempt at fixing things I had this bright idea to make the drag and drop shorter by adding a list of searchable items to the utility window. This, however, wasn't a great idea, because you would essentially be duplicating a lot of information, and using more memory, which would especially be a problem for people with very large lists. To get around this fact, I tried making the search field an actual search rather than a filter. This isn't the way any of the lists work in MacGourmet though. In MacGourmet, you start with the full list of items and trim that list down based on what is entered in the search field, so making this a search rather than a filter introduced inconsistencies. This change also didn't really solve what proved to be the REAL problem anyway, that being accidentally changing the selected item when you didn't want to. Allowing users to double-click on related items in the utility window actually made things worse, as doing this changed the item selected in the window. So at this point what I had was pretty much a solution looking for a problem.

Then it dawned on me that what was really needed was a way to "lock" the current selection, so that you could do whatever you wanted and the selection would be maintained until you were done with it. This worked much better, and in the end, made the search list absolutely pointless, as you already had a browse-able, searchable list in the main recipe box window. You could already find what you were looking for, and drag the recipes or notes to the relationship manager, so the extra search list was overkill. So in the end, the solution was much simpler than originally planned. So you see, sometimes things don't go the way you originally thought, or as designed, until something is implemented, which is why I like to do prototypes for certain things. You really should never be afraid to throw something out that doesn't work right and start over either. The worst excuse for not revising a feature that doesn't work correctly is that it's "done."


Post a Comment

<< Home