[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Dialog behaviour [Was: "Re: KDE 3.2 beta and taskbar flashing"]
From:       Allan Fields <kde () afields ! ca>
Date:       2004-01-04 7:00:51
Message-ID: 20040104070050.GB3850 () afields ! ca
[Download RAW message or body]

On Sat, Jan 03, 2004 at 03:58:34PM +0100, Lubos Lunak wrote:
> Dne so 3. ledna 2004 11:42 Quattro [Jason P.] napsal(a):
> > Lubos Lunak wrote:
> > >  There's no option to turn if off. And it doesn't flash at you constantly
> > > until you switch to the window. It flashes at most only  1-2-3-4 ... uhm,
> > > well, 4 and half times, then it stays highlighted. I didn't consider it
> > > flashing a few times to be greatly annoying, and it's supposed to be
> > > noticed by the user after all, that's why it's there - you wouldn't want
> > > to notice only hours later that something happened, would you?
> > >
> > >  But I guess I could lower the number of times it flashes ... say, only 2
> > > and half times?
> >
> > There really should be an option to turn it off entirely..my eyes are
> > quite sensitive to changes like that. Again, back when I used Windows,
> > it drove me crazy every time my taskbar would flash, and when I switched
> > to Linux and KDE I was so relieved I'd never have to be subjected to
> > that again.
> >
> > [...]
> >
> > I know some people like the flashing, and I'm not advocating removing it
> > entirely. I just want a way to turn it off for those of us who don't
> > want it.
> 
>  But this is not only about starting applications in the background, it's 
> about anything that could interrupt your work. If some application decides to 
> show some dialog out of the blue, focus stealing prevention will make sure it 
> won't get in your way, and only marks its taskbar entry. But you wouldn't 
> want to notice it only after hours, would you? I know what kind of bugreports 
> I'd get then. Moreover, I'm afraid we have i18n freeze now. Disabling focus 
> stealing prevention entirely is the way that turns it off.
>
> -- 
>  Lubos Lunak
>  KDE Developer

Although flashing on the taksbar (in Windows for example) to solicit
user attention, doesn't bring me great itchiness - so to speak...

Forward Looking: I would think it prudent to offer the high
configuration of any features that might interrupt a user or impede
usability.  I have a few suggestions with regards to dialogue boxes.
Far apart from focus stealing, I'm not convinced message dialogs
are a wise methodology under which to convey all messages to the
user in a windowed environment: even in the case where the intent
is immediate notification.  The Macintosh popularized the "OK Computer"
dialog: and it seems to have stuck ever since.

The traditional (standard) behaviours of Macintosh and Windows might
best be left as configurable options (perhaps set by default for
familiarity).

Personally, I prefer an asynchronous message event/response user
paradigm, where by any notification, approval or choice/specification
request blocks on user input with-out implicit creation of a new
window and with-out blocking other non-dependent threads.  The idea
of decoupling the message event from the dialog window is appealing
as it follows the approach of modularity.  One idea, in its stead
is a generalized user messaging framework with event=>action mappings
(for instance based on a dispatch: (message type,originator,message
regex,...) => [action,...]  This could be implemented efficiently
using hashing.

In this way an event would result in any of a set of user-configurable
actions dependent on the originating object and message type --
example: on HTTP error from khtml => {add message to message frame
of application window, highlight message in message frame, trigger
beep, if recording errors: log to user's khtml_errors.log file}
-or- whatever you fancy..  Some users might not favour an audible
notification for DNS resolution failures, thus it could be easily
disabled for this specific case while it would still be enabled on
server timeout.  A "catch-all" global queue rule could be configured
to receive all message events not matching.

By allowing a user to determine how and when their applications
will display messages: urgent messages and errors can be kept
separate from those of lower priority (as dictated by the user/work
environment).  The combination of global and application scoped
message queues/frames in KDE would allow for even easier recognition
of messages and for redirection to the appropriate destination(s)
to be dealt with at an optimal time.  If Konqueror fails to load a
page on desktop 11, the panel might turn on the message indicator
lamp (which when pressed (or on mouse-over) would popup the most
recent entries on the global queue.)  If konqueror can't communicate
with the kio process, I might opt additionally for a dialog to
appear on the active desktop bringing this to my attention.

Inter-linkage between blocked applications/threads and messages at
different queues could be indicated by some sort of a widget which
changes focus to the corresponding object on activation.  (On the
application view would be a standard widget to pending messages,
and vise-versa.)

Pedagogical Catch-All Message Queue View:
+=========+======================+=====+=======+=================+===+==+==+===+
|Date     |Message               |Prio |Origin |Actions          |Del|Go|Up|Dwn|
+=========+======================+=====+=======+=================+===+==+==+===+
|20040102 |Overwrite File: Import|High |kate   | [Yes] [No]      |[X]|()|/\|\/ |
|12:43:03 |ant_info.txt?         |(7)  |       | [Cancel] [Rename|   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+
|20040102 |File System Error:    |High |....   |                 |[X]|  |/\|\/ |
|11:22:01 |read only filesystem  |(9)  |       |                 |   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+
|20040102 |HTTP Login: https://ww|Mediu|konquer| User:[    ]     |[X]|()|/\|\/ |
|11:22:03 |w.sssshh.org/secret/  |(6)  |       | Pass:[    ] [OK]|   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+
|20040102 |Accept Cookie From:   |Mediu|konquer| [Yes (5)] [No]  |[X]|()|/\|\/ |
|11:16:07 |.google.com           |(5)  |       | [Never] [Always]|   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+
|20040102 |Failed to contact serv|Mediu|konquer| [Retry (14:59)] |[X]|()|/\|\/ |
|13:00:35 |er: somedomain.kom .. |(4)  |       | [Cancel]        |   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+
|20040101 |Happy New Year        |Low  |kremind| [OK]            |[X]|()|/\|\/ |
|00:00:00 |Peace On Earth, etc.  |(2)  |       |                 |   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+
|20040102 |DEBUG: fam problems,  |Debug|kio_sla|                 |[X]|  |/\|\/ |
|12:06:09 |reverting to ...      |(0)  |<7647> |                 |   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+
|20040102 |DEBUG: fam problems,  |Debug|kio_sla|                 |[X]|  |/\|\/ |
|12:07:11 |reverting to ...      |(0)  |<7650> |                 |   |  |  |   |
+---------+----------------------+-----+-------+-----------------+---+--+--+---+

A timeout could be placed on prompts such as "Failed to contact
server, retry?", such that they would chose the default action and
remove/replace the message in the queue without disturbing the user
or filling up the queue with duplicate messages.

A message in the queue could be expanded to a stand-alone dialog
by double-clicking or dragging it out and put back into a queue
by dragging it over and docking.  Queue views could be ordered by
clicking on a header.

An applications window that is waiting for input on a "dialog" event
could gray out the region which is serviced by the blocked thread
and/or the controls/widgets.  This user feedback in addition to
bringing pending dialogs to the front upon clicking in the inactive
region, would assist in finding the right message.

The GUI and text consoles are not so different in some senses: the
comparison could be drawn that message dialogs are the graphical
equivalent of a console application which writes messages on your
terminal, possibly while you are editing a file.  While in the GUI,
dialogs are movable / removable; some users will find it similarly
frustrating to receive messages while at work that require "immediate"
attention to dismiss.  Focus stealing prevention is very helpful,
but even more effective would be to avoid creating new windows for
unimportant messages all-together.  Just as root might not favour
spammy console logging from syslog, KDE can use a common streamed
approach for dealing with application generated messages, the primary
difference being the addition of a user response component.

-- 
 Allan Fields                  _.^.  ,_ ,. ._ .
 AFRSL - http://afields.ca    <,'/-\/- /\'_| /_
 Ottawa, Canada                `'|'====-=--- -- -
                                 `---- -- -
 Got 0..n completeness?
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]