The Perl Journal November, 2004
When measuring an application's usefulness, it's hard to overstate the importance of the interface. Sure, your subroutines have to do their job, and your code needs to run reasonably fast, and certainly, it needs to not crash. But if users are going to get any real work done, an application's interface has to make sense.
Case in point: A certain app that I use almost daily (which shall remain nameless) violates just about every interface principle I've ever heard of, much to the program's detriment. Under the hood, this app has world-class processing, but good luck trying to find out how to make use of it. I could catalog all its faults, but there's one interface bungle that sort of sums up the entire app's GUI ineptitude—it has several interface widgets that perform completely different functions when clicked on their left and right halves, though they have no visible markings distinguishing the left half from the right half of the widget. Gems like this make me wonder if the designers aren't having a bit of a laugh at users' expense.
But enough criticizing. There's a good reason why these sorts of interfaces persist in the software world: Interface design is hard. Interface designers break the rules for what seem like good reasons. They create new widgets because they find that, in many toolkits, supplied widgets don't do enough. All too often, though, these new widgets make little sense to users because they merely visually encode some idiosyncratic notion that exists mainly in the designer's head. Here's a tip: If your new widget requires three paragraphs in the manual to explain its use, you've blown it.
GUI toolkits exist in the first place because some group has communally decided that certain interface "best practices" are universal enough that we should make them standard. You can argue the relative merits of some of the widgets and concepts present in various GUI toolkits, but some things are pretty universal—we all understand the function of buttons and checkboxes, for instance. Of course, there are geniuses out there who can carry off a revolutionary interface design, but I, not being confident in my status as genius, will stick to the established concepts.
One good way to confine yourself to a safe GUI sandbox is to make your app web-based. HTML has a wonderful way of limiting you to well-understood interface conceits. Yes, it's limiting in other ways, too, but often those limitations are a price worth paying, as they can force you to simplify your design. In his column this month, Simon Cozens makes good use of HTML, and packages up a browser-based interface, a simple web server, a web app, and a browser into a single executable using PAR, Perl's answer to Java's JAR. It's a great technique that eliminates many dependencies that can make it very hard to ship cross-platform Perl apps.
Also in this issue, Blair Sutton makes use of standard Win32::GUI interface elements, further abstracting them into XML files that can be more easily manipulated than standard Win32::GUI objects.
Neither Simon nor Blair buck any interface trends with these techniques. They don't reinvent any wheels. They simply do what Perl folks everywhere do everyday—they stand on the shoulders of giants to write code we can all understand and make use of.