|Kongregate Registration for Free Flash Games and Chat with solprovider|
Improving simple communications in applications
Originally written 20081224 for Slashdot |
This article responds to Mark Shuttleworth's ideas about changing the "notification" API in Ubuntu. From that article, "Notifications are only for things which you can safely ignore or miss out on." Fred explains my thoughts well -- do not display anything that nobody needs to see.
The best portion of Mark's proposal is everything using his API can be safely disabled completely. The bad is wasting effort on something completely useless. The worst result is splitting the interface for applications communicating with people. This interface does not allow actions, therefore any communications requiring actions must use a different interface so using this project requires multiple interfaces for communicating with people.
Programmers were (and most are still) not trained about usability. A good interface for a messaging system would have been easy if dialog boxes with standardized buttons had not become common. Windowing systems also kept the modal model from the single-thread paradigm -- freezing applications with modal dialogs has become standard . Multi-threading has been used for performance rather than interfacing with people. Non-modal dialogs are difficult to create and use on most windowing systems.
This API is simple. Each function takes one or more strings as parameters. Only the first string is required. Answers are the text of the parameter so changing the order has no other effect.
The first function is synchronous so the application waits for answer. The application gaining focus automatically reopens the current message for that application.
Asynchronous functions allow the application to continue. A loop can force an answer.
Creating a library for use with Gnome, KDE, and Win32 should be easy. Each platform has standard functions to show the dialogs. Code for maintaining the list of active messages is trivial. Replacing the standard functions to use the new API could be tricky since the standard functions could not be used by the library, but would automatically update existing applications to use the new interface.
Additional possibilities include:
Pretend Firefox is using this API.
The status bar uses the messaging interface. Messages without actions appear in the status bar. Clicking the status bar opens the message interface so previous messages can be seen. Link targets are combined into one message to prevent creating very long lists, and people can filter the no-action-required messages.
Messages with actions open the message interface with the latest message. The omnipresent standard cancel button removes worry that the cancel button will open more windows. Requiring text for each action removes uncertainty. With the asynchronous functions, pages can be accessed while dialogs are still active, allowing navigation to other pages without closing the current process. A negative is choosing an asynchronous action for a page that has been closed would have no effect. Use the modal ask_wait() if forcing an action is worth upsetting people.
Other applications can send messages and ask questions without gaining focus and interrupting the person's work. Messages from other applications appear in Firefox's status bar, but can be filtered if annoying. The message interface opens to the other application's questions when the person returns to the other application.