[Ayatana] Questions
1) are features such as display position and display timeout part of the notification spec, and are they handled by the notification daemon or display? 2) are display decisions, such as whether to show a notification or not (e.g. in presentation mode), handled by the notifcation daemon or display? 2) will notification display systems be interchangable in Karmic? -- Celeste Lyn Paul KDE Usability Project usability.kde.org ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Fwd: Things I have noticed
Nate wrote: > What if the notification bubbles started neatly in the corner, but > after a moment slid down the screen and slowly faded while it moved > down a few inches, where it would disappear? New bubbles would pop up > in the corner, but would slide down while their duration ran out. > More important bubbles might pause in the corner longer and slide > slower. It's a cute idea, essentially providing subliminal feedback using the behaviour of the bubble. However, I would agree with Nick's followup, that movement increases the difficulty of reading the notification (especially if it is getting appended to while it is moving). On balance, I would try to avoid arbitrary movement of the bubbles. In the original design, we had a lot of "sliding bubbles", as new ones were added (before we decided to queue them) and as older ones died (and existing ones slid up to fill in the gaps). We came to the conclusion that simpler was better, and ended up trying to optimise for the minimum of sliding. For example, we specified that appends to a higher async bubble should be paused while a syncronous bubble was being displayed below it. So, say Joe starts talking to you, and his comments are being appended in a bubble in the top right. If you then hit the volume down key, you get a syncronous bubble underneath that. If Joe talks to you while you have that, we decided to defer the append until the volume bubble had died and gone away so that the append wouldn't cause the volume bubble to slide down. In our 9.10 experiment, we will eliminate that completely, because syncronous bubbles will ALWAYS be the same size and ALWAYS be "just above the half-way line", while async bubbles will be "just below the half-way line". The async bubbles might grow or shrink (with content appending and replacement) but they won't slide around. We'll have scrolling in the bubble, for long content and long content with appends. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Fwd: Things I have noticed
Mark Shuttleworth wrote: > Nate wrote: >> What if the notification bubbles started neatly in the corner, but >> after a moment slid down the screen and slowly faded while it moved >> down a few inches, where it would disappear? New bubbles would pop >> up in the corner, but would slide down while their duration ran out. >> More important bubbles might pause in the corner longer and slide >> slower. > It's a cute idea, essentially providing subliminal feedback using the > behaviour of the bubble. > > However, I would agree with Nick's followup, that movement increases the > difficulty of reading the notification (especially if it is getting > appended to while it is moving). On balance, I would try to avoid > arbitrary movement of the bubbles. > sliding bubbles adds a slick interface , but as Nick said , sliding would make reading difficult... How about the *bubble sliding works when the user is typing* to catch his attention , but as soon as the typing stops, the sliding stops and the bubble timer starts. that way sliding serves as a means to attract attention, when user is concentrating on some other part of the screen. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Fwd: Things I have noticed
But if the user is focusing on something else, the worse thing to do would be to force him to break his focus. I quite like notify-osd as it is (apart from the terrible lag when using the backlight change keyboard shortcuts). Mark, do you mind explaining what you mean with an "halfway line" ? Does it mean the notifications wouldn't go in the top of the screen if there's no sync notification ? That'd be space eating in netbooks and laptops, imho. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Questions
Celeste Lyn Paul wrote: > 1) are features such as display position and display timeout part of the > notification spec, and are they handled by the notification daemon or display? > I would consider both of those to be implementation decisions, and outside the scope of the "standard". If, however, it turns out to be good practice to have longer notifications visible for longer, then we'd want to codify that as a best practice and encourage other display agents to adopt the pattern. > 2) are display decisions, such as whether to show a notification or not (e.g. > in presentation mode), handled by the notifcation daemon or display? > At the moment, things like "presentation mode" are pretty much an ad-hocracy. We'd like to elevate that to a more rigorous science, having a well-defined set of modes and statuses, with clear meanings that are relevant to LOTS of applications. What does it mean to be "Busy" or "Offline" or "Available"? Right now, that's a hacked up combination of whatever the screensaver / office / browser / notification / XXX dudes decided, and it's not consistent, therefor there's no incentive for the user to set and maintain the state. We'd like to elevate that, so that multiple apps follow consistent guidelines in adapting to those states, increasing the value of getting it right. > 2) will notification display systems be interchangable in Karmic? > They are already interchangeable. YMMV, on Ubuntu we will only test with notify-osd. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Questions
Celeste Lyn Paul wrote: > 1) are features such as display position and display timeout part of the > notification spec, and are they handled by the notification daemon or display? > 2) are display decisions, such as whether to show a notification or not (e.g. > in presentation mode), handled by the notifcation daemon or display? The Galago spec let an application specifies a timeout, but no positioning. This is up to the implementation. There is no separation between daemon and display. On Jaunty GNOME desktop, you run either notification-daemon (the original implementation) or notify-osd (our implementation). You can select which one will be used at login time [1]. Aurélien [1] http://martinpitt.wordpress.com/2009/02/23/the-stracciatella-gnome-session/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Notifications and user presence
(Apologies, but this got a bit long. I've warned ya...) Hi all, I'm interested in the idea of making user presence more useful desktop-wide, and notifications seem like a good candidate for integration. notify-osd intends to solve certain issues by: * not getting in the user's way (click-through bubbles, queuing) * not interrupting the user's thoughts (subtle, no actions, not for critical information) * looking pretty :) In other words, notifications are just that: notifications, not requests for immediate response. Although notify-osd does its best not to interrupt me, notifications seem inherently interruptive. (One catches my eye, I want to read it. One doesn't catch my eye, then I wasn't notified of anything - did it even need to be shown?). I could think of the following classes: 1 Confirmation messages: (like in the wiki) Visual acknowledgement of user action, e.g. keyboard-caused change of volume/brightness, a/c plugged in/out, wireless enabled/disabled, music player attached, etc.) 2 Critical messages: Messages which demand attention and the user ideally *must* see. Note these don't require action by the user; the system is being forced to act to prevent data-loss or damage. The only case I've thought of is an emergency hibernate/shutdown to preserve the user's data in the case of extremely low power. There might be others..? 3 Interesting messages: Messages the user *wants* to see. This should be decided by the user (with "typical" defaults). We can use presence to indicate to the system exactly what notifications the user deems worthy of his attention. Each status can hold the interestingness (namely, something is or isn't) of reasons for notification. 4 Trivial messages: Messages the user *doesn't want* to see, i.e. whatever isn't considered Interesting (or Critical or Confirmation). So what's Interesting when I'm surfing the net might be Trivial when I'm watching a fullscreen movie, or working on my report, or... Thinking of notifications in this way, when would a trivial message be shown? Hopefully never! Does this (adequately) ease the issue of notifications interrupting a user's workflow? The only notifications shown are known to be desired by the user, thus the user wants to break her thoughts to address them. There's those two special cases there, Confirmation and Critical. Critical should be shown no matter what; the user deserves some explanation why his computer is shutting down unexpectedly. It could even pulse between black and scary red (#92?) to differentiate it. Confirmations are generally expected. I up the volume, I'll see a bubble. I plug in the a/c cord, I'll see a bubble. These would probably(?) be interesting; I want to see what level my volume is when my movie is too quiet. Even if it's something unrelated, like attaching my camera during writing a report, the bubble won't be distracting me as I've been thinking about attaching the camera. - It would be interesting to see others' thoughts. I don't imagine I'm the first to think this sort of thing; it seems hinted at by Canonical but it would be cool to flesh out. Gee re-reading this I sound a bit pretentious or know-it-all, but I certainly don't! I'm not every use-case out there, but I thought I'd chuck a few thoughts down into the mix (keep on stirring everyone :) Jim Putt - I've left out my desire to replace 'click-through' with 'single click dismisses' (Ha! but I snuck it in just now!) but my instinct when seeing something popup is to focus on it with my eyes and have my mouse at the ready, but then it suddenly disappears when my mouse hovers over it! (Serious question,) does anything else in the desktop behave like that? And to continue with the click-to-dismiss thing, the bubble absorbs clicks from when it starts to appear till x00 milliseconds after appearance, and it provides feedback to mouse hover (highlight?). The end. Really. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Things I have noticed
On Monday 11 May 2009 13:06, Mark Shuttleworth wrote: > We won't bring actions back, even if a patch is contributed to do so. > The user experience of "racing to click on the action" is fundamentally > broken, and can't be fixed even though many people will clamour for it. > So, actions require completely different presentation - we think they > should either be in windows which call for attention, or in dialogs. Our > current action handling is a half-way house to tolerate badly-behaved > apps while they get fixed. I think that given the current set of design choices and the way you've balanced the different user requirements you've decided on, that is true. There are other ways to do it that would allow actions on notifications without causing this race that would also generally meet the requirements you've set. Scott K ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
