About
Code by Kevin: Programming, code, business, and other pursuits
Your Host
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
2010
2009
2008
2007
2006
Categories
Business
Software
General
Tue, 28 Apr 2009
While doing a bit of research on how Cocoa developers create user interfaces, I was struck by the difficulty this developer faced in trying to create a user interface similar to that used by Apple in several of its applications:
"That's what I wanted for my new application: a source list on the left, a content list on the right, and a detail view below that. All with no margins. Unfortunately you just can't whip this up with Interface Builder."
This seems hard to believe, but the developer had to do a huge amount of work to implement the basic interface. He wound up collecting code components from several different sources--one package implemented a "split-window" view, another implemented a gradient list selector and icons in the list, another implemented custom layout in a table's cell, and so on.
The results are below:
Nice, but hardly easy or rapid--the major arguments that Cocoa developers make for their toolkit.
Here's what I use in Tk to achieve a similar interface: a BWidget Tree on the left, a Tablelist view on the right, and a text view below that, all wrapped up in ttk::panedwindow or two, and with their appearance options (such as the background, the list selector, etc.) customized to match OS X conventions.
Here are the results:
Fortunately, you can whip this up in 150 lines of code, or thereabouts. (That 150 lines doesn't include the code for the toolbar, search field, and so on, but this is an apples-to-apples comparison.)
I'd suggest that my Tk interface is very close in its appearance to the native Cocoa interface developed with Objective-C code...and I was able to develop this basic approach with far less work than the custom Cocoa interface, leveraging components that are either part of the Tcl/Tk core (text widget, paned window) or part of the standard Tcl/Tk extension library, and thus well-maintained and readily available.
I'm sure this example won't persuade any Cocoa developers to give Tk a try--heavens no!--but it does show the surprising power that Tk has, and demonstrates why I choose to develop my programs with this toolkit.
A recent favorable comment about Phynchronicity online--the commenter said that Phynchronicity "has evolved into a fine package"--was very gratifying, and also thought-provoking. The idea of "evolution" is what spurred my thinking, because this is a very accurate description of my approach to development.
When I begin developing a new program, I have a certain number of features and functionality in mind. My basic strategy is to implement the absolutely essential features and functionality in version 1.0, with an eye to getting the program out as soon as possible. Some refinement and polish of the program occurs after this point, especially in response to user feedback. However, my main goal is to implement the rest of the major features I've envisioned and move to version 2.0 in a reasonable time frame.
Once I reach version 2.0, I usually shift gears away from a big laundry list of new features, and my approach becomes much more evolutionary. Some developers use the laundry list approach as way of demarcating major versions of their software, to 2.0 and 3.0 and beyond, and also as a way of justifying upgrade charges. That's not how I prefer to do things. Once I get to a point where a program does what I want it to do, I want to continue to improve it by refining its polish and usability--not by dramatically changing the scope of what it does. This approach doesn't rule out new functionality and new features, but it does rule out a huge number of new features that may bear little resemblance to the program's original purpose.
That's how Phynchronicity has evolved. The program's core functionality--installing and removing software--has remained from the start. What has changed is how the program goes about its tasks, and the experience it presents to the user.
When I first started work on Phynchronicity, it installed and removed software, but it was slow, ugly, and unituitive. Today I started version 1.0, and almost laughed at how unpolished it was. I then looked at version 2.4, which was just released earlier this week, and the difference was night and day. This is what the comments above focused on--initial reviews of the program complained about version 1.0, while version 2.4 is what the current comment was based on.
Between version 1.0 and 2.4, here's what changed:
With the exception of one big jump--to version 2.0--all of these changes and enhancements were added bit by bit over time. The change from version 2.0 to 2.1 did not seem like a big jump, for instance--just a few little tweaks and enhancements. But the sum total of these enhancements is a program that is vastly improved, indeed one that bears only a passing resemblance to the program it was when first released.
This evolutionary approach to software development is one reason why I shy away from charging upgrade fees--it's hard for me to draw a line in the sand and say that this update is big enough to merit an upgrade fee. Over a couple of years, the changes are dramatic, but not from one released version to the next. Still, even if this means I'm passing up some revenue, I still prefer this iterative, evolutionary approach to the "laundry list of features" approach. I think it means better software over the long run.