Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


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

by solprovider (#26228241) Attached to: Shuttleworth Proposes Overhaul of Desktop Notifications

"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.

... though his invention worked superbly -- his theory was a crock of sewage from beginning to end. -- Vernor Vinge, "The Peace War"