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
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

October 2014
Sun Mon Tue Wed Thu Fri Sat
     
 

Privacy Policy

Site design: Skeleton

 

Wed, 21 Feb 2007

Makeover time

I'm working on major updates to all four of my currently-released applications. These updates focus less on adding lots of new features and more on giving the user interface of each program a major makeover, to make them more intuitive and simple to use.

What this means is going beyond simply trying to make the interfaces polished; it means trying to integrate as much standard Mac behavior and appearance as possible.

Toward that end, I've purchased a set of commercial Mac-style icons, to replace the open-source icons I've been using. I've also dug deeply into Apple's interface guidelines (and looked at a lot of popular Mac applications) to see what I can do to improve the interfaces of my programs.

Here's a sample of how I'm doing the makeover for VuMan, my man page viewer.

First, the current version, 1.3 (click on the image to get a larger view):

This version uses icons from the open-source Tango icon project. The Tango icons are most popular on the Linux operating system. While not unattractive, they are not entirely consistent with the Mac-Aqua icon style, which tends more toward photo-realism. Also, these icons are based on GIF files, which is Tk's native image format. Thus, they are a bit jaggy.

Other points about the current interface of VuMan: it uses a Mac-native combobox to select categories of man pages, but in a manner not entirely consistent with best Mac interface practices; it also uses a basic search field, not the Mac-native one (look at Safari or the Finder to see what I'm talking about), because my programming environment, Tcl/Tk, does not have built-in support for this interface element. Finally, the list of available man pages is displayed on the right, in a layout that attempts to simulate the Mac-style "drawer." (One of the toolbar buttons closes the "drawer.")

The overall effect of the interface of VuMan as currently released is, in my view, "usable, but not as Mac-native as it should be, and a bit unpolished."

Now, here's the revised version (still in progress):

The new version uses Mac-style toolbar icons. These are modelled after the icons that ship with OS X, although they are not the actual system icons; I purchased these from an icon designer. I think the new icons, by themselves, help the application to feel more Mac-like. I have also implemented the menubutton icon with the "gear" image that is showing up on more and more Mac applications, such as Mail.app; I use that to select the category of man page that is displayed. The new interface also implements a Mac-style search field; it uses a Mac-style search icon, and keeps a history of search terms. (I found some open-source Tcl/Tk code that implemented the basic search field, and I modified it to look more Mac-like.) Finally, the new interface is less "cluttered" than the old one; it places the list of man pages in a separate pane of the main window, where it can be easily accessed.

All of the programs I develop are getting this kind of makeover; there will be certain common elements that I incorporate into each application, such as the new search field, but there will also be design updates specific to each program, based on user feedback.

What's the point of all this work? Foremost, to increase sales. I believe that the more intuitive and "Mac-like" an application is, the more likely a user is to purchase it; the user can more easily evaluate the program's features without being distracted by the sense that things aren't quite "right" in terms of its look and feel. My own test for this is that the first time I launched VuMan with the new look, I forgot I was looking at a program I developed; it felt like just another Mac program. That's progress.

[/business] permanent link

Power and productivity

There's been a lot of blog buzz among Mac developers about Daniel Jalkut's interesting suggestion about programming languages--that an increasing number of Mac desktop programs will be written in scripting languages like Python and Ruby, with developers using lower-level compiled languages like C and Objective-C only for specific, performance-critical parts. Apple itself is promoting this trend by including Cocoa bindings for Python and Ruby in the next version of OS X, Leopard.

All I can say is: Welcome to the revolution, guys.

Context: Much commercial Mac programming is done in Objective-C, which is the basis of Apple's flagship Cocoa programming environment. A large number of commercial applications that date back to the old Classic MacOS days are programmed in C or C++ using Apple's Carbon frameworks. Compiled languages such as C, C++ or Objective-C produce software that is fast and powerful. But programming in such languages is a slow and complex process, because developers must manage many low-level details such as how their code interacts with computer memory; also, whenever a change is made to code, a programmer must recompile the program to test the change, which (in the case of a large program such as Microsoft Office) can take hours.

Scripting languages differ from compiled languages in a significant way: they do not require compiling. Instead, code in such languages is executed by an interpreter (which is usually itself written in a compiled language such as C). Scripting languages are called "higher-level languages" because they take care of many low-level details for the programmer, such as memory management; they also have many built-in libraries for managing data that compiled languages lack. The benefits of using scripting languages include faster development time (because programs do no need to be recompiled for testing, and because the scripting language has more built-in power); and a simpler learning curve, because some complexity is managed by the language itself. The drawbacks include slower programs in some cases; and more accessible source code, since the code itself is not compiled.

(This article provides a useful summary on the benefits and drawbacks of scripting languages.)

If you've read this blog before, you know that I am a huge advocate of scripting languages. All of my programs are written in Tcl/Tk. While not as trendy as Ruby or Python, Tcl is just as powerful, and its Tk GUI bindings (built on top of Carbon rather than Cocoa, as Tk was ported to the Mac OS a decade ago) allow the creation of sophisticated GUI's. I chose Tcl as my main development language for the reasons outlined above: its power required only a modest learning curve. I have learned a rudimentary amount of C--enough to code a small extension to Tcl to add functionality that was not built-in to the language--but otherwise I spend nearly all my time in Tcl. I'm extremely productive in that langauge, while sacrificing very little--if anything--that programmers in C or Objective-C have.

So, again, I say to all you scripting language converts: Welcome.

[/general] permanent link