Here are some other principles of UI design that apply to program design:

Reduce Cognitive Load. This guideline in UI design is about minimizing the amount of things a user has to know in order to be able to use a tool effectively. Likewise, a programmer shouldn’t have to subclass five different classes just to effect one small change to an application. For instance, I often find that in order to add a new behavior interactive application I may have to learn the logging framework, the undo/redo mechanism, the localization framework, and the validation framework–on top of whatever complicated hierarchies exist in the model and views. Things usually reach this state when developers anticipating future needs and striving for reusability and generality in their frameworks end up sacrificing simplicity and, ultimately, usability.

Continued »

Category: Design, Guest Blog: Kayser, Programming | 5 Comments »

Not long ago Ken Arnold wrote an article for Queue magazine called Programmers are People Too. In it he talks about applying the principles of User Interface Design to the design of APIs. It turns out the practices of Human Factors and Usability Engineering have a lot to offer the implementors of public APIs and frameworks. Think of an API as the “user interface” of a larger programming model. Users are application programmers and the usability of the API is judged not just by it’s richness, but on the ease of use and learnability of the API. It’s not sufficient to address usability with thorough documentation any more than it’s sufficient to compensate for a bewilderingly difficult user interface to a mobile phone with a five pound user manual.

Continued »

Category: Design, Guest Blog: Kayser, Programming | 6 Comments »

If a program is to be a work of literature, then where does that leave object-oriented programs? In the era of functional decomposition, programs were built around algorithms and data structures. They executed in a single thread as a sequence of steps and subroutine calls, not unlike a story. Our object-oriented programs, on the other hand, don’t have such a fixed path of execution. Whether server or client applications, they start up multiple threads and make heavy use of message passing and asynchronicity. The essence of a program is not in a sequence of steps and subroutine calls but in the subtle relationships between classes spread across many frameworks and subsystems, relationships such as inheritance, aggregation and collaboration. So how does one read a Java application like a story? The whole idea of object oriented programs seems at odds with literate programming.

Continued »

Category: Guest Blog: Kayser, Java, Programming | 14 Comments »