|
|
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
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.
|