Simple UI Refinements Increase Developer Productivity

Recently I have been thinking a lot about what it takes to create a good user interface versus one that just gets the job done. Whole books are available about UI design, but I think most developers steer clear of them, adopting a Git-R-Done attitude instead.

Most developers that do UI work know how to use the various widgets, can follow the general patterns that can be observed in other platform applications (i.e. copy the UI “feel”), and have a vague sense of how to lay out the elements of a dialog box. What we all seem to forget is that the field of human interaction is separate from programming, and that there really is something to it.

A very good example of how subtle changes in a UI can make all the difference can be found in Visual Studio and Xcode; the development environments for Windows and Mac OS X. In both tools a dialog is provided for manipulating the compiler and linker settings that control how the project is build.

Visual Studio 2005 – nice set of property pages that can be navigated by a tree on the left. The problem is, you have to already know where all the properties live (under which tab) in order to quickly navigate to the properties you want to change. Take a look at the screenshot to see what I’m talking about.

vc2005_properties_thumb.png

Apple took a similar but subtly different approach on their project properties dialog box. They list all properties by default, grouping them by category. The developer can scroll up/down through the complete list to browse all of the properties. The search box at the top of the dialog provides a more powerful user interface than the tree control in Visual Studio. This one little addition makes all the difference in the world for a busy developer.

Xcode Project Properties_thumb.png

Here we see how this simple addition can increase the productivity of a developer. By simply letting the developer type a free-form string that describes part of the property he/she wishes to change the list of properties is narrowed to display only those that are a match. In the screenshot below you can see how this makes it very easy to get at the preprocessor definitions to make a quick change. In Visual Studio the developer is expected to remember which category the property appears in, remember the name of the category, and then navigate to that tab before he/she can make the change.

Xcode Project Properties (Narrowed)_thumb.png

This is just one small example of how similar user interfaces can be very different when actually used. Both provide a way to manage the properties of a project, but only Xcode provides solid UI features that support the day-to-day use cases for a busy developer.

So, it should be clear that spending time on UI design can pay off. Your users may not recognize the amount of effort that was put into the UI, but they will appreciate the increased productivity that a well though out UI provides.

Advertisements

iPhone developers put on hold by Apple

The Apple World Wide Developer Conference (WWDC) for 2008 kicked off Monday with a keynote presentation by Steve Jobs. As was expected, a new 3G iPhone was announced and there was a lot of discussion about the new capabilities in iPhone OS 2.0. Steve mentioned that the iPhone SDK has been downloaded 250,000 times since the release in March and that 25,000 developers have signed up for the iPhone Developer Program. Of those 25,000 developers Apple has selected 4,000 for participation in the beta program.

No mention was made of when (or if) the remaining 21,000 developers who wish to participate in the beta program will be permitted to do so.

Based on the numbers I think it is clear that developers are very excited about building and selling applications on the iPhone platform. Unfortunately, Apple seems far less excited about helping these developers get started. They have let a mere 16% of interested developers into the program. The remaining developers cannot build and test applications on real devices. Effectively Apple has put all these developers on hold. They want to build applications that use the accelerometer, the camera, the GPS, etc., but cannot since the simulator has none of these capabilities.

To illustrate what a ridiculous approach this is for supporting developers take a look at the following post that recently appeared on craigslist. Whoever this developer is, he/she really wants to get their application tested and running in time for the Apple AppStore launch.

Someone with influence at Apple Computer needed (santa clara)

I need my application to the iPhone developers program approved so I can get a certificate to test my applications on a real iPhone. Without one I can only run it on a simulator. I have a compelling application that I am working on that will be sold commercially.

Apple computer received my application two months ago and they have my credit card number for the $99 fee.

In return I can give you some cash or services or maybe a gift certificate for dinner someplace. Whatever you think is reasonable.

Apple and Steve have been positioning the iPhone OS (CocoaTouch) as a new platform for application development. The developer community seems to agree with this and wants to develop applications for the platform. Apple, please let the remaining developers who signed up for the beta program in. We all want to give you $99 so we can start running our applications on real devices. We all want you to take 30% of any revenue from the sale of our applications when they are sold through the AppStore. We all want to help make this a great new platform for application development.

The simulator just doesn’t cut it! Give us the ability to run on actual devices, PLEASE!!!!!

How to enable MSI Logging

If you are trying to debug an installer problem it is probably worth having MSI logging turned on. This will produce a file in your %TEMP% directory that contains a detailed trace of the activities that took place in MSIEXEC. This can be very helpful when an install or uninstall fails without any clear indication as to why it failed.

Log files are stored in the directory pointed to by the TEMP environment variable. The filename format is MSIxxxx.LOG, where xxxx is replaced with a random string. A new log file is created for each invocation of MSIEXEC.

To enable logging through group policy, do the following:

  • Start / Run… / gpedit.msc
  • Drill down into Local Computer Policy / Computer Configuration / Administrative Templates / Windows Components / Windows Installer / Logging
  • Enable logging with the setting “voicewarmup”. These are the command-line arguments that MSIEXEC will use.

These links contain more information on setting up logging: