2 posts tagged “software development”
Over the past few months, I've been immersing myself in the ubiquitous computing literature with a focus on context, notifications, and interruptions. Over the past month, I've been looking at ways that I could apply some of the theoretical academic research to real world environments and scenarios. Lately, I've been learning the Growl notification framework from both the perspective of an end-user developer with an application that emits notifications and that of the interface designer who is responsible for crafting an aesthetically pleasing and informative display for those notifications. Earlier this spring, when I discovered Twitterrific, I was impressed at how its use of sound was a pleasant addition to my environment.
One of the things that frustrated me about the Growl system was that there didn't seem to be any systematic approach to combining audio and visual notifications on the basis of the emitting notification. For one thing, plugin developers seemed more interested in creating interesting visual displays than exploring other output modalities. There is a speech plugin that uses MacOS X's built-in speech synthesizer, but that was it. To scratch my particular itch, I decided to create a plugin of my own.
I also included a feature where rules may specify that the visual notification is to be suppressed. This has proven to be useful with my use of NetNewsWire. NetNewsWire does not include any sound effects of its own, but does emit Growl notifications. By associating a sound effect with the "Feed Updated" notification, I now hear "tinks" when new news is available. Likewise, I can suppress the sound effects for notifications where that would be a problem. I did exactly that with the iTunes notifications. I receive a nice visual indicator with an album cover and song title when a new track plays, but no sound effect interrupts the music.
Adding new sounds to the system is simple. Copying an AIFF file to the standard sound locations (Library/Sounds) will make that sound available the next time you configure the plugin. I've found a number of interesting effects to customize my environment at The FreeSound Project.
Technically, this plugin is a modest extension to Walton's already stellar Smoke plugin. However, I've been discovering novel ways in which it can be used to create a more pleasant ambient environment. I don't know how I lived without it and hope that others feel the same. I've posted it online as part of my context and notification project, and it can be downloaded from Google Code. If you do give it a spin and have some feedback, I'd be glad to hear it.
I finished reading Alan Cooper's "The Inmates Are Running the Asylum" earlier today. This is a book about the importance of interaction design that looks at the computer interface problems and proposes an approach for making better software by focusing on personas (the people who will use the software) and goals (what those people want to accomplish by using the software). It is an interesting book on the intersection of design and software development and it has many good lessons to impart.
I was particularly intrigued by one design principle that he introduces: polite software is self-confident. A quick blurb:
If I tell the computer to discard a file, I don't want it to come back to me and ask, "Are you sure?" Of course, I'm sure, otherwise I wouldn't have asked. I want it to have the courage of its convictions and go ahead and delete the file.
On the other hand, if the computer has any suspicion that I might be wrong (which, of course, is always), it should anticipate my changing my mind and be fully prepared to undelete the file. In either case, the product should have confidence in its own actions and not weasel, whine, and pass the responsibility off onto me.
This blurb hit on a problem that I've been working on for a little while now. At the moment, I'm in the process of giving Books a bit of a user interface overhaul. I'm not changing the look and feel of the windows or anything like that. Instead, I've been looking at the little things that I can do to make the app smoother and more intuitive for my users. I've been doing this by revamping preferences, slightly modifying the behavior of existing interface elements, and eliminating vestigial ones where possible.
Cooper's paragraphs above instantly reminded me of the dialog boxes that Books throws up when you want to delete a list or book record. Currently, unless the item being deleted is an empty list, Books asks for confirmation that you really want to get rid of the data. Cooper's principle suggests that I should get rid of these timid modal dialogs that interrupt the flow of using the application. Books is built upon CoreData, which provides a nice data store that includes undo and redo functionality. I could eliminate the dialogs and it is possible to undo the deletions.
The problem that I have with doing this is that I'm not sure that all of my users understand how to undo something. I suspect that undo makes sense in the context of editing text or other individual fields, but I worry that they don't know that it works in the context of adding and deleting objects that hold data, such as book records and lists. To further complicate things, CoreData keeps its "undo" information in memory, meaning that quitting the application forgets the "undo" information between program sessions. I can easily imagine a user accidentally deleting a list of books, quitting the application, and restarting it to find their data missing. After this happened, I would probably get an angry e-mail about the incident.
One solution to this problem would be to implement an analog of a trash bin in the application. Users delete records and they get moved to the trash bin. They are only truly deleted when the user "takes the trash out" and deletes the contents of the bin. The trash can could be saved between sessions (it could be just another list), thereby conforming to Cooper's principle. On the other hand, I wonder if the addition of a trash can adds complexity to the interface. Another problem with the trash metaphor is that it would function for all intents and purposes as a list. This works fine when book records are deleted, but what happens when a list is deleted? Does the list show up in the trash or are lists simply deleted instantly?
Another question that demands an answer is one of recurring costs. If records were being added and deleted regularly, a metaphor like the trash can would be necessary. I would become annoyed if my e-mail application constantly asked me whether I wanted to delete a message. On the other hand, within Books, records are added more often than they are deleted and these deletions are relatively infrequent. Is this infrequent timidity less troublesome than introducing a new complexity to the user model (the trash bin) that is present the entire time the software is in use?
I've been thinking about this throughout the day. I go back and forth between the status quo and implementing changes that would make my code more bold and confident. I don't have an answer yet, but this book has forced me to think about details such as these and to ask myself whether I can be making my own code more usable and humane. By forcing me to confront these questions, this book has already had a positive influence on my own work.
