The original theme for this issue was "Designing Applications," and while I still think it's a perfectly reasonable theme I must confess to some surprise at the variety of responses we got from authors. Space limitations forced us to trim the number of articles more than we would have liked, but that's a chronic problem with magazines and is certainly nothing to distinguish this issue. Suffice to say that we are not finished with the topic of designing applications software with this month's articles.
Something that does distinguish this month's issue is Robert Carr's article on guidelines for developers. After reading the article. you might be tempted to dismiss the message---developing for the user. after all, is something that everyone claims to do. Despite the apparent simplicity and familiarity of Carr's advice. I strongly urge you to read the article and then reconsider your development efforts. A careful examination of your current process might reveal a few holes.
It's tempting to dismiss another reminder of the importance of the user in software design. I might even agree (on a good day) that we all learned that lesson years ago, except for the overwhelming evidence to the contrary.
Item: Just a few months ago, a major software house was in the final beta pass for a product with an integrated editor. It was only at this last pass that someone at a beta site complained that the editor was abysmally slow. The reviewer's comments---something about the seasons moving faster than the cursor---caught the developers by surprise: the program had always seemed fast enough on their 386 machines. Alas, the target audience consisted primarily of people using 8088 machines.
Nor are these problems limited to performance issues. A year and a half ago I pretty much trashed Zoom-racks in a review that appeared (substantially rewritten) in BYTE. The keyboard interface was a Byzantine complex of Alt- and Control-key commands, the mouse interface---what there was of it---was buggy as hell, and the file facilities could be charitably described as primitive. (The PC version, for example, couldn't recognize subdirectories.)
The capper to this second story is that Paul Heckel, the designer of Zoomracks, is also the author of The Elements of Friendly Software Design which is a pretty good book on designing applications.
These aren't isolated instances. There isn't a month that goes by that I don't examine a new program that seems hastily thrown together. Little touches like using subdirectories and environmental variables really aren't that hard to add. And besides, we all know better. End of sermon.
This month's news is probably already old to you: Jon Erickson, our new editor-in-chief, is online starting this month. You can meet him back on page 6.
This month's reading list is a short one. Go to the local university library and pull out George A. Miller's classic 1956 paper. The Magical Number Seven. Plus or Minus Two." Then consider the implications of human bandwidth on your next design. A little thought might make a world of difference for your customers.