Solprovider Thoughts Kongregate Registration for Free Flash Games and Chat with solprovider

Improving simple communications in applications

Article Categories
Browsers
Business
Cell Phones
Computers
Intellectual Property
Lotus/IBM
Microsoft
Other
Software Development

<<   Recent Articles   >>
Alert Interfaces
OOo Writer
Contacts
Losing the Presidency
Authors for Boys
Monitors
Windows 98 Time Zones (DST)
Windows 98 Sorting
Domino does not require experts
Contacts and Companies can force upgrades
Cars and Planes
Hotmail is Unreliable
Maintaining Windows
Police State
Understanding Google
 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.

Better Specifications

  • Only the front-end application can force message window to front.
  • Applications can check whether a message was answered and receive the answer, preferably asynchronously. Applications freeze only when a response is mandatory and urgent.
  • System may limit frequency of additions and checks by applications to prevent overloading.
  • Every message appears in list interface and log(s).
  • Reactivating a message moves to the top of list. The list combines identical entries to remember the first time, last time, and number of appearances.
  • People can remove messages from list without using application-defined actions (to prevent fear that application dialog box's close action has other consequences.)
  • Closing the current question (by cancelling or choosing an action) opens the next unanswered question with actions for that application.

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.
  • ask_wait("Question"); - With no actions, the application is paused until the dialog is cancelled. Use ask_log() when pausing is not required.
  • action = ask_wait("Question", "Action1", "Action2", "Action3"); - With actions, the application is paused until cancelled or an action is chosen.

Asynchronous functions allow the application to continue. A loop can force an answer.
  • ask_log("Question"); - Add to list without move messaging to front, and continue.
  • ask_log("Question", "Action1", "Action2", "Action3"); - Add to list without moving messaging to front, and continue. Application should check if an action was clicked, but does not suffer if a person ignores the question. This would be useful for asking configuration questions when an application loads.
  • id = ask_new("Question", "Action1", "Action2", "Action3"); - Add question, move messaging to front, and continue. People can cancel question without choosing an action. Applications may loop to force answer.
  • ask_again(id); - Move question to top of list and move messaging to front. An application can use this function when regaining the focus to simulate ask_wait() without preventing normal use if people do not want to answer immediately.
  • action = ask_get(id); - Returns chosen answer or empty string if no 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.

Simplification includes:
  • Window title cannot be specified.
  • One standard font without decorations. This avoids Gnome's practice of using bold for the first line so the critical question at the end is less visible.
  • No images. Some systems add icons to indicate type of dialog. These types are unnecessary. People only care if they need to choose an answer.
  • Text is required for actions, hopefully ending the reign of OK|Yes|No|Cancel dialogs. Win32's messagebox() returns numbers for standard responses and almost forces developers to use this poor interface.

Additional possibilities include:
  • Filter/sort list by application and if actions.
  • Incorporate the messaging system as a status bar in applications.

Example


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.

<< Understanding GoogleOOo Writer >>

Contact Solprovider
Paul Ercolino