Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Improve by increasing irrelevance? (and solution) (Score 1) 306

"Notifications are only for things which you can safely ignore or miss out on." Fred explains well -- do not display anything that nobody needs to see.

The best portion of this proposal is everything using Mark's 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. Multi-threading has been used for performance rather than interfacing with people.

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, but people can switch applications freezing the current application if the response was 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. List remembers 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.)

The new API is simple. Only the first string is required in each function. Answers are the text of the parameter (so changing the order has no other effect.)
Synchronous (application waits for answer, gaining focus automatically reopens message):
action = ask_wait("Question", "Action1", "Action2", "Action3");
Asynchronous (application can continue):
ask_log("Question"); - Add to list without move messaging to front, and continue.
id = ask_new("Question", "Action1", "Action2", "Action3"); - Add question, move to front, and continue.
ask_again(id); - Move question to top of list and move messaging to front.
action = ask_get(id); - Empty string if no answer.

Should be easy to create library for use with Gnome, KDE, and Win32. 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.

Future possibilities include:
- Filter/sort list by application and whether actions exist.
- Incorporate the messaging system as a status bar in applications.

An early version of this text was posted on the original article. The comment either will not appear until moderated or failed moderation. My website contains an expanded version.

Slashdot Top Deals

You should never bet against anything in science at odds of more than about 10^12 to 1. -- Ernest Rutherford