Code by Kevin
   


About
Code by Kevin: Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.

Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

        home
Thu, 02 Aug 2007

Listening to user feedback: look and feel

Based on some feedback from users, it appears I've finally gotten the "look" of PortAuthority right. However, the "feel" isn't quite there yet. Here's a rundown of issues identified by one user in an e-mail to me:

  • Things that should work with a single-click require a double-click--for instance, filtering ports by selecting a category in the tree view.

  • Things that should work with a single-click don't work at all--for instance, getting the information about a port with a single-click in the table view.

  • Things that should happen infrequently happen all the time--for instance, the program beeping an alert when it completes an operation.

  • Things that should stay the same get changed abruptly--for instance, when a package is installed, the table view shifts to the complete list of packages, rather than updating the existing view.

  • Things that should happen quickly take forever--for instance, filtering packages by category.

Why do these glitches exist? Several reasons:

  • My own limited perspective as a developer: I've made certain design decisions and have grown accustomed to the program working in the way I designed it, and no one has ever provided an alternative perspective. For instance, no one has ever complained about the double-click vs. single-click issue before. But, as this user noted, iTunes switches table views with a single-click in the tree display, and my program should too. Once I gave this idea some thought, it was obvious, and not very difficult to implement, but it took another perspective to get me to see it.

  • A sense of "if it ain't broke, don't fix it." PortAuthority was originally designed to be a simple graphical interface to the MacPorts command-line infrastructure: it simply piped commands to MacPorts and displayed the data that MacPorts returned. As the program evolved, however, I began adding more capabilities: for instance, MacPorts provides no mechanism in itself to filter ports by categories, but PortAuthority does. In adding these capabilities, I tried to do so in a conservative way by building on the way PortAuthority already worked: by fetching all my data from MacPorts and then performing whatever transformations I needed to get it to display in the fashion I wanted. Unfortunately, this had the effect of slowing the program down. A user noted that PortAuthority might be faster and simpler to use if it didn't have to call out to MacPorts for everything it did; after investigating this further, I found that it is possible fetch complete data from MacPorts on PortAuthority's startup, cache the data, and extract needed information from the cache; this speeds up PortAuthority considerably, and greatly reduces the number of times I need to call MacPorts to update my data. The old method of calling to MacPorts for everything worked, but the new method of caching my data works better.

I'll be rolling these improvements into a new version of PortAuthority very soon. And, just as importantly, I'll be rolling these improvements into my other programs as well. What I've learned represents a fundamentally better, more sophisticated way of designing my programs: it will raise the bar on all my applications. And I have user feedback to thank for that.

[/general] permanent link