Re: [Ayatana] unity and notifications
On 16/09/10 16:25, Conscious User wrote: Le jeudi 16 septembre 2010 à 13:29 +0100, Luke Benstead a écrit : On 15 September 2010 17:25, Greg K Nicholson g...@gkn.me.uk wrote: On 15 September 2010 16:54, Conscious User consciousu...@aol.com wrote: I know it's the space for the confirmation bubbles, but I think it would be much better if those appeared in another place entirely, like a bottom corner. I've suggested before that synchronous notifications (e.g. volume) should appear horizontally centred. Then the asynchronous notifications (IM etc.) can appear immediately below the top panel, at the right. No-one has come up with any drawback whatsoever to this design —yet ;) -- Greg That's definitely the best solution I've heard yet. Why are we not doing that? Luke. As a matter of fact, because the confirmation bubbles have a fixed size, they can be placed pretty much anywhere with little issues. If I were to guess the reason of the current placement, is that the designers believe that giving the user two different places from which bubbles can come from is confusing. Can someone confirm? We want to keep notifications and indicators in relatively close proximity. Synchronous (keyboard-response, user-generated, self-overwriting) notifications like volume-up and -down are on top, because that area has more precious content (firefox search, for example) than the area just below it, and because they are fixed-size, where the async ones are variable-size. 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] unity and notifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego Moya wrote on 21/09/10 16:48: On 21 September 2010 15:57, Matthew Paul Thomas wrote: ... For the same reason operating systems don't have visible controls for configuring the appearance of tooltips. If they're designed right, they should be below the threshold of triviality. If a substantial proportion of users want to configure them, there's something wrong that we need to fix. Both situations are not really comparable. Notifications have proven to be a more difficult problem than tooltips, which are basically local to a single widget each time (and notifications are unrelated to the content below them). Notifications are global to the system, so you should ultimately take the whole system into account to get it right. Perhaps scrollbars are a better example, then. Scrollbars as we know them are deceptively complex, and took about three years to get right http://folklore.org/StoryView.py?story=Busy_Being_Born.txt. But pretty much the only configuration you can make to them now is changing their width in Windows, and their arrow button positions in Mac OS X. The smallest misappreciation could produce a less-than-optimal solution. You should be omniscient to create your right design! Not omniscient, just following a standard design process. That scorched earth approach of zero-configuration (if it ain't perfect, disable it!) means that until you get it right some people will suffer in the meantime without a way to fix it, even assuming that the perfect design exists. There's nothing disabled as far as I know. But every added option would make it harder to implement and to test. Also think that configuration doesn't need to be panel with check boxes. Allowing direct manipulation of bubbles (for example to reposition them) would potentially fix with a one-time drag-and-drop any problem of obscured content, without being a burden to the user. ... This is a personal preference, but I really don't like the idea that clicking on a widget hidden below the notification should have some effect. The whole click-transparent notification idea in the current design is disturbing to me, it always felt weird and uncertain on what would be the result. Maybe, then, it would make sense for the bubble to bob out of the way (e.g. down a bit) when you go to the corner, and stay there. No clicking required. - Don't show notifications if there has been user interaction in the previous 5 seconds. ... In my suggestions I'm relying heavily on the notion that missing a notification is not a big deal - I think that was one of the design guidelines. I'm just pushing it to the extreme in order to reduce interruptions to the user flow while working with application content. - Even if the bubble is closed, allow the user to reopen it from the Me menu. Many if not most notification bubbles have nothing to do with social networks or instant messaging, so that would be a poor fit. ... or somewhere else, where logging that class of notifications was appropriate. If there isn't a sensible place where to log the message in a particular bubble, it wasn't that important to begin with. These points seem to contradict each other a bit. Our current approach is that yes, missing a notification is not a big deal, and *therefore* it's not important enough to have a global notification log. One reason it might not be a big deal is because there is an application-specific log, e.g. an IM chat. - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkykmS0ACgkQ6PUxNfU6ecqlgwCghxfvj+l/oR2Bpo7NEv8M+P2I FIcAoJKfR6fy9MuOoUzho7Bjx74EMEj2 =uoVA -END PGP 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] unity and notifications
Hi Appi, On Thu, Sep 23, 2010 at 10:21, Diego Moya turi...@gmail.com wrote: On 23 September 2010 03:00, Apoorva Sharma wrote: Thanks for your approval of my design! I went ahead and made an interactive mockup with HTML, CSS, and JavaScript. Since it uses CSS3, it only works with Firefox 4, Chrome, and Epiphany. (In Maverick) Here's the link: http://dl.dropbox.com/u/510407/Test/index.html What do you think? Also shouldn't it open to the right and cover the calendar and clock area? At least in my browser it's opening to the left of the mail indicator, which is covering the space dedicated to the taskbar. i still suggest morphing out the info text field from the bottom of the indicator array.. Replacing the indicators with a notification is also a good idea, but seems to me to be more of a fancy theme for our notification bubbles, the default imo should be near the indicators yet should not obscure them. Remember: the indicator menus are for interaction, this area of the panel is for interaction, the indicators are not only control LEDs to monitor the state of a service.. obscuring a group of special menu buttons would be too obtrusive.. Also remember that you are consciously adding constraint to the already spartan design up there, this should only happen when your use case's affordance character strongly depends on adding this constraint. Constraint per se has no function other than to limit, prevent, secure or protect. Only critical system alerts would in this case be valid for your design, as great as it is, still.. Thanks for an incredible addition to the markup-based interaction designs.. i hope we will continue to see those css3 mockups here.. :D ___ 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] unity and notifications
i still suggest morphing out the info text field from the bottom of the indicator array.. Replacing the indicators with a notification is also a good idea, but seems to me to be more of a fancy theme for our notification bubbles, the default imo should be near the indicators yet should not obscure them. Remember: the indicator menus are for interaction, this area of the panel is for interaction, the indicators are not only control LEDs to monitor the state of a service.. obscuring a group of special menu buttons would be too obtrusive.. I made a previous point about this, which unfortunately was completely ignored: the indicators are *menus*, which means that interacting with them involves clicking on them and *immediately after* moving the cursor down, thus freeing the notification to reappear. There might be situations when the user has no reason to move the cursor afterwards (ex: he clicked on indicator-datetime just to see the calendar), but in those he also has no strong reason to stand still either. ___ 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] unity and notifications
On 22 September 2010 12:16, frederik.nn...@gmail.com wrote: On Mon, Sep 20, 2010 at 19:00, Diego Moya wrote: The last option (current approach) makes it an all-or-nothing proposition i.e. users that don't find the default design will not benefit at all from notifications, being forced to disable them. Being a bit more flexible should make notifications useful to more people and a smoother experience to those who can use them. The need for flexibility in such a straightforward application would be a clear trait of poor design or poor implementation. There seems to be this idea that allowing user control is poor design. *Requiring* flexibility (i.e. forcing users to configure the tool for common cases) would be bad design. But enabling users to harness the software tool for usages not predicted by the designer, can only be advantageous for both the user and the tool. Concerning the matter at hand, the need for flexibility to reposition notifications follows from bubbles obscuring user content, which is a potential problem and a flaw in the design. The current make translucent on mouse over is at best an awkward workaround for the initial problem, as well as a distracting interaction. Apoorva Sharma proposed in this trhead a mockup that wouldn't need configuration as it only obscures system information, which IMHO is a better design because it avoids the basic flaw of bubbles. ___ 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] unity and notifications
Le mercredi 22 septembre 2010 à 11:01 -0400, Mark Russell a écrit : On 09/22/2010 06:16 AM, frederik.nn...@gmail.com wrote: I think the design of our pretty bubbles is good, implementation not yet complete and i have only one flaw to comment on: Notify only! ATM the bubbles don't only notify, they also relay complete IM messages.. that is an abuse by Empathy, which must be stopped IMO. +1. When people minimize their chat window it's often because they don't want others reading the IMs over their shoulder. The current behavior is precisely what shouldn't happen. This is an interesting point but beyond the scope of this list. The problem exists regardless if the user is using NotifyOSD or the vanilla notification-daemon. It is something to be discussed with the Empathy devs (and Pidgin devs, and Gajim devs, and aMSN devs, and Emesene devs, etc.) ___ 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] unity and notifications
On Wed, Sep 22, 2010 at 2:52 PM, David Hamm davidth...@gmail.com wrote: To be more accurate, the idea is that allowing user control is often a way to sweep problems under the rug instead of actually solving them. Hear Hear And this further reinforces Diego's statement: Apoorva Sharma proposed in this trhead a mockup that wouldn't need configuration as it only obscures system information, which IMHO is a better design because it avoids the basic flaw of bubbles ___ 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] unity and notifications
David Hamm davidth...@gmail.com wrote: To be more accurate, the idea is that allowing user control is often a way to sweep problems under the rug instead of actually solving them. Hear Hear *slams водка mug on table* Yes, but extremism about this is equally dangerous. It results in a design that is well suited for a single, possibly narrow, use case and useless for anything else. That's great if one is designing for a dedicated system like a cable TV set top box. For an operating system, not so much. 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
Re: [Ayatana] unity and notifications
On Wed, Sep 22, 2010 at 5:01 PM, Walter Wittel witt...@gmail.com wrote: And this further reinforces Diego's statement: Apoorva Sharma proposed in this trhead a mockup that wouldn't need configuration as it only obscures system information, which IMHO is a better design because it avoids the basic flaw of bubbles Thanks for your approval of my design! I went ahead and made an interactive mockup with HTML, CSS, and JavaScript. Since it uses CSS3, it only works with Firefox 4, Chrome, and Epiphany. (In Maverick) Here's the link: http://dl.dropbox.com/u/510407/Test/index.html What do you think? ___ 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] unity and notifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego Moya wrote on 20/09/10 15:59: ... Diego Moya wrote on 17/09/10 13:59: Yes, those bubbles are actually quite similar to what NotifyOSD tries to do. But look how Jef required a way for the user to take control of how bubbles are presented. Which was unrealistic. By the time you had remembered, and then typed, the command to reduce the opacity, the error would have faded away by itself anyway. I think it was meant to configure the default opacity to a level at which the user feels comfortable. The Ayatana design dismissed the idea to let users configure notifications to their needs, and I never got the reason for that. For the same reason operating systems don't have visible controls for configuring the appearance of tooltips. If they're designed right, they should be below the threshold of triviality. If a substantial proportion of users want to configure them, there's something wrong that we need to fix. The Ayatana notification design took the original idea and then changed it to its opposite by removing every safeguard feature to put user in control and keep it humane. That is not true. I had read the book years ago, and seen that idea, and thought it was crack (mainly because the mockup was obviously rigged to ensure the error text didn't overlap the background text). But by 2008 I'd forgotten about it. And then you went designing a notification system based on translucent, non-dismissible bubbles? I didn't mean using a similar design was a deliberate decision, but surely it had some influence? No, not at all. When I say I'd forgotten about it, I mean, I'd forgotten about it. :-) ... We could do better with the fading, but I find myself unable to imagine a situation where someone simultaneously (a) needs to see what's under a notification bubble and (b) needs the cursor elsewhere. Can you give an example? I think Michael Jonker already provided one at this very thread; that's why I elaborated on it. When working with the Gimp, he needed to see the layers panel while working on the scene, and it was obscured by the bubble. As Mark Curtis said, that's a potential problem no matter where the bubble appears. And any interaction to move or dismiss the bubble would be just as much of an interruption as moving to fade it. ... When we designed Notify OSD, we did not have touch screens in mind. Does that mean they will not be supported, ever? They're supported right now. Or are suggestions welcome to also support touch screens, even if it implies changing the original design? That too. The starting point i feel is: You touch it and it goes away. ... So, how would you avoid touching it by accident just after it appears? Several viable options to avoid the problem: - Touching it don't dismiss it for the first 0.5 second, enough for the user to notice it. That's a possibility, but we would need to define more carefully what don't dismiss it means. If I clicked on the part of a bubble above a window's close button, 0.45 seconds after the bubble appeared, would it close the window, or do nothing at all? - Don't show notifications if there has been user interaction in the previous 5 seconds. Interesting idea, though it might result in a long queue. - Even if the bubble is closed, allow the user to reopen it from the Me menu. Many if not most notification bubbles have nothing to do with social networks or instant messaging, so that would be a poor fit. - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyYueAACgkQ6PUxNfU6ecrnmACgqwtxbKPfsmpNHIOr7Zx/T2y1 WSMAoMXnuisj7UuaWm1tZKFfSXRz8iFx =7zXZ -END PGP 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] unity and notifications
On 21 September 2010 15:57, Matthew Paul Thomas wrote: Diego Moya wrote on 20/09/10 15:59: I think it was meant to configure the default opacity to a level at which the user feels comfortable. The Ayatana design dismissed the idea to let users configure notifications to their needs, and I never got the reason for that. For the same reason operating systems don't have visible controls for configuring the appearance of tooltips. If they're designed right, they should be below the threshold of triviality. If a substantial proportion of users want to configure them, there's something wrong that we need to fix. Both situations are not really comparable. Notifications have proven to be a more difficult problem than tooltips, which are basically local to a single widget each time (and notifications are unrelated to the content below them). Notifications are global to the system, so you should ultimately take the whole system into account to get it right. The smallest misappreciation could produce a less-than-optimal solution. You should be omniscient to create your right design! That scorched earth approach of zero-configuration (if it ain't perfect, disable it!) means that until you get it right some people will suffer in the meantime without a way to fix it, even assuming that the perfect design exists. Also think that configuration doesn't need to be panel with check boxes. Allowing direct manipulation of bubbles (for example to reposition them) would potentially fix with a one-time drag-and-drop any problem of obscured content, without being a burden to the user. I think Michael Jonker already provided one at this very thread; that's why I elaborated on it. When working with the Gimp, he needed to see the layers panel while working on the scene, and it was obscured by the bubble. As Mark Curtis said, that's a potential problem no matter where the bubble appears. And any interaction to move or dismiss the bubble would be just as much of an interruption as moving to fade it. But less severe than having to wait 5 seconds. Also it usually should be done just once, while obscured content can be annoying every time. The starting point i feel is: You touch it and it goes away. ... So, how would you avoid touching it by accident just after it appears? Several viable options to avoid the problem: - Touching it don't dismiss it for the first 0.5 second, enough for the user to notice it. That's a possibility, but we would need to define more carefully what don't dismiss it means. If I clicked on the part of a bubble above a window's close button, 0.45 seconds after the bubble appeared, would it close the window, or do nothing at all? It should do nothing, because the meaning of the click would be ambiguous. This counts as a mode error, but it's less severe than the alternative which is a misplaced command. This is a personal preference, but I really don't like the idea that clicking on a widget hidden below the notification should have some effect. The whole click-transparent notification idea in the current design is disturbing to me, it always felt weird and uncertain on what would be the result. - Don't show notifications if there has been user interaction in the previous 5 seconds. Interesting idea, though it might result in a long queue. Only in cases of really heavy user interaction, in which notifications wouldn't be noticed anyway. Most user flow (except for typing long paragraphs) is made in small bursts of short interaction, wait, evaluate UI feedback, more interaction. The 5 seconds could be fine-tuned through some user testing, maybe 2 or 3 seconds would be enough. Also, notifications queued for more than one minute could be safely discarded as irrelevant, just as if the user was away. In my suggestions I'm relying heavily on the notion that missing a notification is not a big deal - I think that was one of the design guidelines. I'm just pushing it to the extreme in order to reduce interruptions to the user flow while working with application content. - Even if the bubble is closed, allow the user to reopen it from the Me menu. Many if not most notification bubbles have nothing to do with social networks or instant messaging, so that would be a poor fit. ... or somewhere else, where logging that class of notifications was appropriate. If there isn't a sensible place where to log the message in a particular bubble, it wasn't that important to begin with. ___ 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] unity and notifications
On 21 September 2010 15:57, Matthew Paul Thomas wrote: For the same reason operating systems don't have visible controls for configuring the appearance of tooltips. If they're designed right, they should be below the threshold of triviality. If a substantial proportion of users want to configure them, there's something wrong that we need to fix. Moreover: not even a design as simple as tooltips can be got right once and for all. For example Microsoft did a complete overhaul of their tooltips engine for Office 2007, enabling giant tooltips that contain snippets of the help files. The new tooltips work much better than the old ones in that context (a giant software suite full of obscure features) thus proving that even a simple, general design can be enhanced for particular use cases. (And for the curious, yes, the Office tooltips allow for some configuration, if only for nostalgics to select the old behavior). ___ 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] unity and notifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Jonker wrote on 17/09/10 13:58: It seems that, under the subject of 1)Unity 2)and notifications, the most discussion is concerning the 'Notification Bubble' (Thanks Matthew for pointing to the spec) The specification is a separate document. https://wiki.ubuntu.com/NotifyOSD 2) Yes - the current implementation of the bubble is functional. It notifies the user, it does fade when the mouse cursor is over it and you can work below it. Many people feel though that it hangs around too long Often it does hang around too long, because length-based duration has not been implemented yet. https://wiki.ubuntu.com/NotifyOSD#duration and is visually invasive. Yes. Its current appearance makes it look clickable when it is not, and does not suit any theme other than Ambiance (not even Radiance). How do we make it get out of the way intuatively and quickly without being accidentally dismissed? Suggestions so far: -A heuristic approach -It does not reappear after a 'fade' -It stays in panel (against design guidelines) -It briefly goes to panel as a fading button after dismissal -A combination of above -Apologies if I missed any suggestions 1) The topic of the original post - how does this work in Unity. More trickily - how does it work on touchscreen? In my opinion, if we can solve this elegantly the rest will follow. When we designed Notify OSD, we did not have touch screens in mind. The starting point i feel is: You touch it and it goes away. ... So, how would you avoid touching it by accident just after it appears? - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyXQDUACgkQ6PUxNfU6ecrMuQCgwsJWy6Ss2URx1x6nyJNuM/Yn 5DgAn3omx69i4Y3/4CCxAKM0QB6UG+Gs =Yab0 -END PGP 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] unity and notifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego Moya wrote on 17/09/10 13:59: On 17 September 2010 14:18, Matthew Paul Thomas wrote: ... Well, Jef had some odd ideas about user input and focus of attention. He thought, for example, that error messages should behave rather like Notify OSD bubbles, undismissable and gradually fading, but that there should be a keyboard command to adjust their transparency (The humane interface, pp116-117 http://ur1.ca/1nklv). And he thought it would make sense to insert incoming e-mail messages into whatever document you were editing at the time (p176 http://ur1.ca/1nkq9). Yes, those bubbles are actually quite similar to what NotifyOSD tries to do. But look how Jef required a way for the user to take control of how bubbles are presented. Which was unrealistic. By the time you had remembered, and then typed, the command to reduce the opacity, the error would have faded away by itself anyway. He also thought that a document that stores all messages for later retrieval is essential. That was for error messages, and it was also unrealistic -- because it didn't address the problem of how, when returning to the computer, you would tell that the task had failed in the first place. The Ayatana notification design took the original idea and then changed it to its opposite by removing every safeguard feature to put user in control and keep it humane. That is not true. I had read the book years ago, and seen that idea, and thought it was crack (mainly because the mockup was obviously rigged to ensure the error text didn't overlap the background text). But by 2008 I'd forgotten about it. The current design for OSD notifications is heavily modal - it blocks access to the visible area until the bubble disappears, and it doesn't give the user a way to claim that blocked area. The provided workaround to reach the blocked screen area requires a complex interaction (the repeated fading out and in as the mouse moves away) that can be quite distracting and doesn't work if the user needs the cursor elsewhere. ... We could do better with the fading, but I find myself unable to imagine a situation where someone simultaneously (a) needs to see what's under a notification bubble and (b) needs the cursor elsewhere. Can you give an example? - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyXRcoACgkQ6PUxNfU6ecqwmwCfR1HtHw+bHCf5H1iAmiwOjpgu o3wAoLQoMlsHSAKgzXtx+yDu2xocyAVP =igas -END PGP 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] unity and notifications
I support the NotifyOSD goal to create not intrusive messages, but I think the current design falls short of that goal. Now that it has been in the wild and used in real contexts, some of the initial controversial decisions that were boldly supported should now be reconsidered, in particular the zero-configuration and no-dismissable bubbles. In my opinion some kind of lightweigh configurability would help tailoring the tool and making it useful for frindge cases, avoiding the one-size-fits-all problems. For example, allowing dragging the bubble to persistently change the placement of notifications would put users back in control to fine-tune their experience. Said that, I like the mockup that places notifications at the indicator menus area. At least in that case the only information obscured is system state, never user content. On 20 September 2010 13:30, Matthew Paul Thomas wrote: 2) Yes - the current implementation of the bubble is functional. It notifies the user, it does fade when the mouse cursor is over it and you can work below it. Many people feel though that it hangs around too long Often it does hang around too long, because length-based duration has not been implemented yet. https://wiki.ubuntu.com/NotifyOSD#duration Length-based duration wouldn't help in cases were the user didn't want to see the notification but the content below it. In those cases only closing or moving the bubble would relieve the feeling that the notification is being obstructive. Diego Moya wrote on 17/09/10 13:59: Yes, those bubbles are actually quite similar to what NotifyOSD tries to do. But look how Jef required a way for the user to take control of how bubbles are presented. Which was unrealistic. By the time you had remembered, and then typed, the command to reduce the opacity, the error would have faded away by itself anyway. I think it was meant to configure the default opacity to a level at which the user feels comfortable. The Ayatana design dismissed the idea to let users configure notifications to their needs, and I never got the reason for that. The Ayatana notification design took the original idea and then changed it to its opposite by removing every safeguard feature to put user in control and keep it humane. That is not true. I had read the book years ago, and seen that idea, and thought it was crack (mainly because the mockup was obviously rigged to ensure the error text didn't overlap the background text). But by 2008 I'd forgotten about it. And then you went designing a notification system based on translucent, non-dismissible bubbles? I didn't mean using a similar design was a deliberate decision, but surely it had some influence? The current design for OSD notifications is heavily modal - it blocks access to the visible area until the bubble disappears, and it doesn't give the user a way to claim that blocked area. The provided workaround to reach the blocked screen area requires a complex interaction (the repeated fading out and in as the mouse moves away) that can be quite distracting and doesn't work if the user needs the cursor elsewhere. ... We could do better with the fading, but I find myself unable to imagine a situation where someone simultaneously (a) needs to see what's under a notification bubble and (b) needs the cursor elsewhere. Can you give an example? I think Michael Jonker already provided one at this very thread; that's why I elaborated on it. When working with the Gimp, he needed to see the layers panel while working on the scene, and it was obscured by the bubble. This will happen in general whenever the top-right corner of the application contains an information panel, which is intended to contain readable data that can be read with a glance while working on the main interface. This is quite usual in IDEs and design tools. When we designed Notify OSD, we did not have touch screens in mind. Does that mean they will not be supported, ever? Or are suggestions welcome to also support touch screens, even if it implies changing the original design? The starting point i feel is: You touch it and it goes away. ... So, how would you avoid touching it by accident just after it appears? Several viable options to avoid the problem: - Touching it don't dismiss it for the first 0.5 second, enough for the user to notice it. - Don't show notifications if there has been user interaction in the previous 5 seconds. - Even if the bubble is closed, allow the user to reopen it from the Me menu. ___ 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] unity and notifications
We could do better with the fading, but I find myself unable to imagine a situation where someone simultaneously (a) needs to see what's under a notification bubble and (b) needs the cursor elsewhere. Can you give an example? I think Michael Jonker already provided one at this very thread; that's why I elaborated on it. When working with the Gimp, he needed to see the layers panel while working on the scene, and it was obscured by the bubble. This will happen in general whenever the top-right corner of the application contains an information panel, which is intended to contain readable data that can be read with a glance while working on the main interface. This is quite usual in IDEs and design tools. Also of course, the Google search box in FF which I find regularly obstructed while typing (unless that's been fixed in Maverick or by cursor, MPT meant cursor or caret). Luke. ___ 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] unity and notifications
On 20 September 2010 16:55, Mark Curtis merkin...@hotmail.com wrote: Trying to find an area of the screen that won't obscure all applications is fruitless. There is no single location that won't end up obscuring SOME application's interface. Popular applications such as GIMP (right and left), Inkscape (bottom and left) and Firefox (top) total to using all sides of the screen. OpenOffice.org Impress alone uses every side of the screen and is an application included by default. I can only think of two options to display notifications while trying not to obscure a user's workspace: a.) Don't display notifications in the working area (e.g. display them in the panel, Android-style) b.) Resize the working area to allow the notification to display (e.g. slide up from the bottom resizing all open windows - potentially jarring) If we are accepting we must obscure the user's working area (which isn't really ideal) we should allow the user to either configure the notifications so they don't interrupt their specific workflow, allow them to be closed (still not ideal; interrupting flow), or just be a little arrogant about it and if they don't like it they can remove them (current approach). Luke. ___ 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] unity and notifications
On 20 September 2010 18:25, Luke Benstead wrote: I can only think of two options to display notifications while trying not to obscure a user's workspace: a.) Don't display notifications in the working area (e.g. display them in the panel, Android-style) b.) Resize the working area to allow the notification to display (e.g. slide up from the bottom resizing all open windows - potentially jarring) If we are accepting we must obscure the user's working area (which isn't really ideal) we should allow the user to either configure the notifications so they don't interrupt their specific workflow, allow them to be closed (still not ideal; interrupting flow), or just be a little arrogant about it and if they don't like it they can remove them (current approach). Luke. +1 all you said. The last option (current approach) makes it an all-or-nothing proposition i.e. users that don't find the default design will not benefit at all from notifications, being forced to disable them. Being a bit more flexible should make notifications useful to more people and a smoother experience to those who can use them. ___ 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] unity and notifications
On Mon, Sep 20, 2010 at 3:31 PM, Mark Curtis merkin...@hotmail.com wrote: Wouldn't that block EVERY application's File Edit, etc menu? I'm referring specifically Unity here as the subject is Unity and notifications. I meant just the indicator icons part, since those only display system status, and since the messages display system status, putting those in the same spot wouldn't obstruct nearly as much, and also make more sense. ___ 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] unity and notifications
I think it demonstrates a big pain point for the message indicator, really. So, we get this nice, big message in the panel and then it shrinks down to a menu item inside a little icon surrounded by other little icons. Let's say there are a few different indicators lit up for different reasons, too. There is lots of noise there, and the message which was just given so much importance has been pressed into a tiny corner. We're forcing the user to hunt for something we were just dangling in front of his or her eyes. Not exactly a solution, but it's interesting to remember that the original mockups for NotifyOSD included a subtle minimizing animation which made very evident that the notification went to the messaging menu. http://www.markshuttleworth.com/archives/253 ___ 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] unity and notifications
Le samedi 18 septembre 2010 à 16:57 +0200, zekopeko a écrit : IIRC the main problem with that approach is the movement being distracting to the user. It can be argued, however, that such distraction is much lower if the notifications are given in the panel, like the previous mockup proposes. On Sat, Sep 18, 2010 at 4:51 PM, Conscious User consciousu...@aol.com wrote: I think it demonstrates a big pain point for the message indicator, really. So, we get this nice, big message in the panel and then it shrinks down to a menu item inside a little icon surrounded by other little icons. Let's say there are a few different indicators lit up for different reasons, too. There is lots of noise there, and the message which was just given so much importance has been pressed into a tiny corner. We're forcing the user to hunt for something we were just dangling in front of his or her eyes. Not exactly a solution, but it's interesting to remember that the original mockups for NotifyOSD included a subtle minimizing animation which made very evident that the notification went to the messaging menu. http://www.markshuttleworth.com/archives/253 ___ 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] unity and notifications
On 17 September 2010 05:21, Conscious User wrote: Like I said, it's not necessarily a much more important action. It could be a very mundane action, but whose movement you couldn't stop by reflex. Furthermore, it is one thing to miss one notification because you were away or not paying attention. It is another, and much more annoying, thing to know *something* has happened and never knowing *what*. Au contraire, they are exactly the same thing. Why should it matter if I miss a notification because I'm reading a webpage, or because I'm reading a physical written manual on my physical desk? Or what if I'm away and come back to see it just in the last half second? The reason why NotifyOSD does not keeps a log of notifications is because you will always have a different way to know what happened. Notifications can be ethereal because they are redundant. If there's no way to know what happened without reading it in the available 5 seconds, then you really should keep a log to recover previous notifications. Also, with my heuristic you wouldn't know something has happened while you're active, the notification would wait until you made a small pause in your work - right when you're ready to read it. That's much more humane than interrupting what you're doing. I think you are proposing a *very simple* heuristic to guess *very complex* thoughts. Those are the best heuristics! :-) The important thing is that it provides a consistent, predictable behavior to notifications. You won't be afraid that a bubble will appear right over your target on the screen, which was your original worry. The heuristic doesn't need to second-guess whether your intentions were important or trivial, it works well in both cases. Actually there's a really simple fix that would solve both your problem and the one of obscuring graphical applications, and it's this: don't ever show a notification while the user is working on something else. The way to detect the user work must be heuristic, but there are some good clues to it: I can be typing very fast... to copy a recipe of cake my grandmother sent me. I can be constantly moving the cursor... to play a flash game. I can be working at a fast pace... because I had one coffee too many, not necessarily because the task is important. I though we already established that notifications are even less important than the least important of the user tasks? That's the only possible justification for them being ethereal. I think it was Jef Raskin who said that you should treat user input as sacred. I concur, and that can be extended to the user focus of attention. If the notification is important enough to interrupt the user flow then a transient bubble notification is not the place for it, it should create a persistent warning in the panel. In the examples you mention there's not a single reason to show a notification that couldn't be better placed as a state change in the menus. As I said, you're treating notifications as more important that they really are, and that's creating problems to the design because it conflicts with the 'ethereal' goal. ___ 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] unity and notifications
I though we already established that notifications are even less important than the least important of the user tasks? That's the only possible justification for them being ethereal. To be more clear, I think this goal is *already* being achieved quite nicely by NotifyOSD *when mouse interaction is involved*. The problem is when one of the two following cases happen: a) The user is typing something in a text field right behind the bubble. Your heuristic works in this case, but it's a little bit of an overkill. I certainly don't mind receiving notifications when I'm writing something completely far away from the bubble area. b) The user wants to just read something covered by the bubble. This is more difficult for your heuristic to cover because he might not be actually interacting at that moment. In fact, in the case of long texts he might not be interacting for several seconds. ___ 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] unity and notifications
On 17 September 2010 09:03, Conscious User wrote: To be more clear, I think this goal is *already* being achieved quite nicely by NotifyOSD *when mouse interaction is involved*. The problem is when one of the two following cases happen: a) The user is typing something in a text field right behind the bubble. Your heuristic works in this case, but it's a little bit of an overkill. I certainly don't mind receiving notifications when I'm writing something completely far away from the bubble area. Maybe the heuristic can be refined to not block notifications while typing unless in that case. But then you get the second problem also while writing... b) The user wants to just read something covered by the bubble. This is more difficult for your heuristic to cover because he might not be actually interacting at that moment. In fact, in the case of long texts he might not be interacting for several seconds. I actually support having a quick way to close a notification. I don't think it's the traditional 'X' icon, though, but something more radical: hide the notification if the mouse hovers it, and *don't show it again even if the mouse moves away*. The notification should act as a real bubble, disappearing on touch. As I said, the user moving the mouse over the notifiacion region means that the content was more important at that moment than the notice, so there's no problem in closing it. The information in it should be already in the panels anyway; the user has already taken notice that there existed a bubble, and can go to the appropriate menu to read it. Combined with my heuristic, there's no problem that an involuntary mouse movement would close the bubble before the user notices it. ___ 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] unity and notifications
I like this idea, fwiw. Another point: currently, if when the bubble appears the pointer is already in its vicinity, i.e. the area where fading would occur, the bubble won't fade at all until the user moves away and back. This is in the spec, but seems contrary to the whole point of bubbles fading on hover. I suggest that instead, all asynchronous notifications should be queued until the pointer moves away (similar to a suggestion above). As an exception, high priority (urgent) notices could be shown anyway after x (~30) seconds even if the pointer's still there. As a bonus (though not a goal), this design would enable users who really care to deliberately queue notices while they're away. -- Greg K Nicholson On 17 Sep 2010 09:12, Diego Moya turi...@gmail.com wrote: On 17 September 2010 09:03, Conscious User wrote: To be more clear, I think this goal is *alread... Maybe the heuristic can be refined to not block notifications while typing unless in that case. But then you get the second problem also while writing... b) The user wants to just read something covered by the bubble. This is more difficult for you... I actually support having a quick way to close a notification. I don't think it's the traditional 'X' icon, though, but something more radical: hide the notification if the mouse hovers it, and *don't show it again even if the mouse moves away*. The notification should act as a real bubble, disappearing on touch. As I said, the user moving the mouse over the notifiacion region means that the content was more important at that moment than the notice, so there's no problem in closing it. The information in it should be already in the panels anyway; the user has already taken notice that there existed a bubble, and can go to the appropriate menu to read it. Combined with my heuristic, there's no problem that an involuntary mouse movement would close the bubble before the user notices it. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] unity and notifications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego Moya wrote on 17/09/10 07:10: ... I though we already established that notifications are even less important than the least important of the user tasks? That's the only possible justification for them being ethereal. I think it was Jef Raskin who said that you should treat user input as sacred. I concur, and that can be extended to the user focus of attention. Well, Jef had some odd ideas about user input and focus of attention. He thought, for example, that error messages should behave rather like Notify OSD bubbles, undismissable and gradually fading, but that there should be a keyboard command to adjust their transparency (The humane interface, pp116-117 http://ur1.ca/1nklv). And he thought it would make sense to insert incoming e-mail messages into whatever document you were editing at the time (p176 http://ur1.ca/1nkq9). If the notification is important enough to interrupt the user flow then a transient bubble notification is not the place for it, it should create a persistent warning in the panel. ... Persistent warning, yes. In the panel, usually not. :-) https://wiki.ubuntu.com/NotificationDesignGuidelines - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyTXI0ACgkQ6PUxNfU6ecoNhACglP+fTUF03wV8dqJI6eFYRRpa /NEAn00pUlyVyIQCA7C+F/g8qsjNezC8 =Sl2v -END PGP 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] unity and notifications
It seems that, under the subject of 1)Unity 2)and notifications, the most discussion is concerning the 'Notification Bubble' (Thanks Matthew for pointing to the spec) 2) Yes - the current implementation of the bubble is functional. It notifies the user, it does fade when the mouse cursor is over it and you can work below it. Many people feel though that it hangs around too long and is visually invasive. How do we make it get out of the way intuatively and quickly without being accidentally dismissed? Suggestions so far: -A heuristic approach -It does not reappear after a 'fade' -It stays in panel (against design guidelines) -It briefly goes to panel as a fading button after dismissal -A combination of above -Apologies if I missed any suggestions 1) The topic of the original post - how does this work in Unity. More trickily - how does it work on touchscreen? In my opinion, if we can solve this elegantly the rest will follow. The starting point i feel is: You touch it and it goes away. Michael On Fri, 2010-09-17 at 13:18 +0100, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego Moya wrote on 17/09/10 07:10: ... I though we already established that notifications are even less important than the least important of the user tasks? That's the only possible justification for them being ethereal. I think it was Jef Raskin who said that you should treat user input as sacred. I concur, and that can be extended to the user focus of attention. Well, Jef had some odd ideas about user input and focus of attention. He thought, for example, that error messages should behave rather like Notify OSD bubbles, undismissable and gradually fading, but that there should be a keyboard command to adjust their transparency (The humane interface, pp116-117 http://ur1.ca/1nklv). And he thought it would make sense to insert incoming e-mail messages into whatever document you were editing at the time (p176 http://ur1.ca/1nkq9). If the notification is important enough to interrupt the user flow then a transient bubble notification is not the place for it, it should create a persistent warning in the panel. ... Persistent warning, yes. In the panel, usually not. :-) https://wiki.ubuntu.com/NotificationDesignGuidelines - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyTXI0ACgkQ6PUxNfU6ecoNhACglP+fTUF03wV8dqJI6eFYRRpa /NEAn00pUlyVyIQCA7C+F/g8qsjNezC8 =Sl2v -END PGP 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 ___ 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] unity and notifications
On 17 September 2010 14:18, Matthew Paul Thomas wrote: Diego Moya wrote on 17/09/10 07:10: I think it was Jef Raskin who said that you should treat user input as sacred. I concur, and that can be extended to the user focus of attention. Well, Jef had some odd ideas about user input and focus of attention. He thought, for example, that error messages should behave rather like Notify OSD bubbles, undismissable and gradually fading, but that there should be a keyboard command to adjust their transparency (The humane interface, pp116-117 http://ur1.ca/1nklv). And he thought it would make sense to insert incoming e-mail messages into whatever document you were editing at the time (p176 http://ur1.ca/1nkq9). Yes, those bubbles are actually quite similar to what NotifyOSD tries to do. But look how Jef required a way for the user to take control of how bubbles are presented. He also thought that a document that stores all messages for later retrieval is essential. The Ayatana notification design took the original idea and then changed it to its opposite by removing every safeguard feature to put user in control and keep it humane. The current design for OSD notifications is heavily modal - it blocks access to the visible area until the bubble disappears, and it doesn't give the user a way to claim that blocked area. The provided workaround to reach the blocked screen area requires a complex interaction (the repeated fading out and in as the mouse moves away) that can be quite distracting and doesn't work if the user needs the cursor elsewhere. That's why I support a way to interact directly with the notification, either by pricking the bubble or allowing the user to place it somewhere else. Turning the bubble into an object by allowing direct manipulation would make it not blocking, and thus non modal. As for the curious mail receptions in Jef's book, this was for a system where the whole stored information was a few strokes away through instant search, so moving it to an archive would be as trivial as cut-n-paste. Also have in mind that this design was probably tested on the Canon Cat, in an era way before the Eternal September and spam. If the notification is important enough to interrupt the user flow then a transient bubble notification is not the place for it, it should create a persistent warning in the panel. ... Persistent warning, yes. In the panel, usually not. :-) https://wiki.ubuntu.com/NotificationDesignGuidelines Ok, I was thinking of applications that log their notifications to the information menus. ___ 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] unity and notifications
Here is a quick idea that struck me after I hit send on the last post: 1)The bubble notification makes it's appearance @ bottom right of the screen (unfaded) 2)It moves along a path to the top of the screen (fading away as it goes) 3)It lands in the 'Me menu'. At this point is is completely off screen, not visible. 4)The 'Me menu' changes colour subtly, alerting the user non-obtrusively, that the system has something to say. 5)in the 'Me Menu' is a new call out entry called 'notifications', with a history of maybe the last 10 events. Clicking on any notification takes you to the relevant email, message, app etc. This has the advantage of: If the user is at the screen, they are immediately notified that something has happened. It is no longer NB that they take time out to read exactly what that is. If the user was away for a cup of tea, they can immediately see there were events while they were away and can access them unobtrusively. The visual disturbance of the moving notification bubble is minimal (maybe 2 seconds) and not concentrated on 1 area of the screen where the user may be working. Touchscreen compatible. Heading away for Hols, but if you guys think this idea is worth investigating I can make a video mock up when I am back. On Fri, 2010-09-17 at 13:58 +0100, Michael Jonker wrote: It seems that, under the subject of 1)Unity 2)and notifications, the most discussion is concerning the 'Notification Bubble' (Thanks Matthew for pointing to the spec) 2) Yes - the current implementation of the bubble is functional. It notifies the user, it does fade when the mouse cursor is over it and you can work below it. Many people feel though that it hangs around too long and is visually invasive. How do we make it get out of the way intuatively and quickly without being accidentally dismissed? Suggestions so far: -A heuristic approach -It does not reappear after a 'fade' -It stays in panel (against design guidelines) -It briefly goes to panel as a fading button after dismissal -A combination of above -Apologies if I missed any suggestions 1) The topic of the original post - how does this work in Unity. More trickily - how does it work on touchscreen? In my opinion, if we can solve this elegantly the rest will follow. The starting point i feel is: You touch it and it goes away. Michael On Fri, 2010-09-17 at 13:18 +0100, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Diego Moya wrote on 17/09/10 07:10: ... I though we already established that notifications are even less important than the least important of the user tasks? That's the only possible justification for them being ethereal. I think it was Jef Raskin who said that you should treat user input as sacred. I concur, and that can be extended to the user focus of attention. Well, Jef had some odd ideas about user input and focus of attention. He thought, for example, that error messages should behave rather like Notify OSD bubbles, undismissable and gradually fading, but that there should be a keyboard command to adjust their transparency (The humane interface, pp116-117 http://ur1.ca/1nklv). And he thought it would make sense to insert incoming e-mail messages into whatever document you were editing at the time (p176 http://ur1.ca/1nkq9). If the notification is important enough to interrupt the user flow then a transient bubble notification is not the place for it, it should create a persistent warning in the panel. ... Persistent warning, yes. In the panel, usually not. :-) https://wiki.ubuntu.com/NotificationDesignGuidelines - -- Matthew Paul Thomas http://mpt.net.nz/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyTXI0ACgkQ6PUxNfU6ecoNhACglP+fTUF03wV8dqJI6eFYRRpa /NEAn00pUlyVyIQCA7C+F/g8qsjNezC8 =Sl2v -END PGP 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 ___ 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] unity and notifications
On Fri, Sep 17, 2010 at 2:24 PM, Apoorva Sharma appi2...@gmail.com wrote: I went ahead and made a mockup of my notification in the panel idea, borrowing heavily from what android does. I've attached an animated gif showing a basic notification popping up. I want to make it clear that the entire panel does not fade out, but simply the indicator-menus and notification applet, and like notify-osd, fades out if the user brings the pointer over it, trying This keeps all windows visible, and all panel icons visible. Another failure of the mockup is that the message indicator should light up after the notification. What do you think? Looks really great to me, but on a lower level I think this is stretching the current components pretty far. I think it demonstrates a big pain point for the message indicator, really. So, we get this nice, big message in the panel and then it shrinks down to a menu item inside a little icon surrounded by other little icons. Let's say there are a few different indicators lit up for different reasons, too. There is lots of noise there, and the message which was just given so much importance has been pressed into a tiny corner. We're forcing the user to hunt for something we were just dangling in front of his or her eyes. Here's what I love and respect about Android's arrangement: * Quick, momentary notification bubbles (like NotifyOSD provides) are entirely their own thing and everyone agrees on that point. * Long-lasting notifications (of all sorts) are created under a different interface and appear in the message tray. Again, very specific kind of design. (What libnotify + notification-daemon should have been). There's only one way these can be interacted with (clicking them), but there are lots of possibilities for how they are displayed. For Android's title bar, consider that it doesn't hide messages behind categories. If an application is saying something, Android assumes it's of importance to the user and presents it very clearly. So, that is a beautiful mockup and it's close to the first bit of Android's nice title bar messages, but I think the rest is important, too :) Dylan ___ 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] unity and notifications
On 15 September 2010 17:25, Greg K Nicholson g...@gkn.me.uk wrote: On 15 September 2010 16:54, Conscious User consciousu...@aol.com wrote: I know it's the space for the confirmation bubbles, but I think it would be much better if those appeared in another place entirely, like a bottom corner. I've suggested before that synchronous notifications (e.g. volume) should appear horizontally centred. Then the asynchronous notifications (IM etc.) can appear immediately below the top panel, at the right. No-one has come up with any drawback whatsoever to this design—yet ;) -- Greg That's definitely the best solution I've heard yet. Why are we not doing that? Luke. ___ 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] unity and notifications
A notification appears (the mouse cursor is not below the notification). The user is now notified. When they move their mouse to that area (bear in mind that they are 'notified' and have no further use for the graphic) it once again fades away and reappears when the cursor departs. This, irritatingly hangs around for about 5 seconds. I know! I am notified! Why are you hanging about cluttering my screen? Because hovering your mouse over the notification does not necessarily mean that you have already read it. It could also mean that what you wanted to click on was more urgent than reading the notification or that you were already in the process of going there to click something and didn't want to stop (or simply couldn't stop, as a lot of actions we do in the desktop are repetitive and become automatic and lightning quick after a while). At least for me, both of those cases are not rare. In my opinion (unless the notification does something like launching the relevant app or is dismiss-able by clicking on x) it should simply vanish when the user moves their mouse cursor over it. That would probably cause a lot of accidental dismissals. Believe me, I'm the first in line to complain that NotifyOSD is *far* from being perfect, but as you can see it is not exactly trivial to come up with fixes that do not cause other, significative, problems. There are a lot of different cases to consider. ___ 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] unity and notifications
Le jeudi 16 septembre 2010 à 13:29 +0100, Luke Benstead a écrit : On 15 September 2010 17:25, Greg K Nicholson g...@gkn.me.uk wrote: On 15 September 2010 16:54, Conscious User consciousu...@aol.com wrote: I know it's the space for the confirmation bubbles, but I think it would be much better if those appeared in another place entirely, like a bottom corner. I've suggested before that synchronous notifications (e.g. volume) should appear horizontally centred. Then the asynchronous notifications (IM etc.) can appear immediately below the top panel, at the right. No-one has come up with any drawback whatsoever to this design —yet ;) -- Greg That's definitely the best solution I've heard yet. Why are we not doing that? Luke. As a matter of fact, because the confirmation bubbles have a fixed size, they can be placed pretty much anywhere with little issues. If I were to guess the reason of the current placement, is that the designers believe that giving the user two different places from which bubbles can come from is confusing. Can someone confirm? ___ 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] unity and notifications
With specific reference to Unity and the notification: We need to get ready for the touchscreen market. The present logic of the notification is mouse-centric and will need to be overhauled for touch screen. In this situation, the mouse cursor causing the notification to fade will not be available and the notification will simply take up real estate for a length of time the user cannot control. On Thu, 2010-09-16 at 13:47 +0200, Conscious User wrote: My point is that a x (close) button would dismiss this intrusion to my focussed work immediately - or - moving the notification to a position I can accept will give me the best of both worlds. Best of both worlds for your particular use case, but the truth is: neither option is fully ideal. A close/respond button creates problems with accidental clicks (a bubble popping up exactly when you are clicking in something below it), and there is the fact that it feels wrong to get out of your workflow just to close a notification. The current NotifyOSD bubbles follow this principle quite well with respect to the case where you might need to interact with the mouse: it simply fades away smoothly when you approximate the cursor and gets out of the way. However, you are absolutely correct when you say that the bubbles get in the away when you need to *just see* what is below them, not interact with. Then you need to put the mouse over them to make them fade, which is almost the same thing as closing. So, the question to the Ayatana designers is: how to cover this case of just wanting to see what is below satisfactorily? I remember hearing that NotifyOSD will be getting some love for Natty, so I'm particularly curious about it. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] unity and notifications
Le jeudi 16 septembre 2010 à 16:22 +0100, Michael Jonker a écrit : With specific reference to Unity and the notification: We need to get ready for the touchscreen market. The present logic of the notification is mouse-centric and will need to be overhauled for touch screen. In this situation, the mouse cursor causing the notification to fade will not be available and the notification will simply take up real estate for a length of time the user cannot control. An idea would be placing the notifications in a place dedicated to it, which won't be clicked regardless of the situation. In high resolutions, an excellent candidate is the (currently wasted) space in the middle of the top panel. For low resolutions the problem is a little bit more hairy, methinks... ___ 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] unity and notifications
Indeed, And to start brainstorming potential solutions: 1) Maybe there is a minimum 'appearance' time for the notification of maybe about 0.75 seconds to prevent involuntary dismissal. The ideal timing may involve some investment in research. 2) The notification dismisses to a small, flashing icon in the top panel which hangs around for about 5 seconds so that the user can retrieve a lost notification. I think in 99.9% of cases the user will be aware that they have accidentally dismissed something. The button could potentially bring up a drop down list - just in case multiple notifications have happened in short succession. On Thu, 2010-09-16 at 17:19 +0200, Conscious User wrote: A notification appears (the mouse cursor is not below the notification). The user is now notified. When they move their mouse to that area (bear in mind that they are 'notified' and have no further use for the graphic) it once again fades away and reappears when the cursor departs. This, irritatingly hangs around for about 5 seconds. I know! I am notified! Why are you hanging about cluttering my screen? Because hovering your mouse over the notification does not necessarily mean that you have already read it. It could also mean that what you wanted to click on was more urgent than reading the notification or that you were already in the process of going there to click something and didn't want to stop (or simply couldn't stop, as a lot of actions we do in the desktop are repetitive and become automatic and lightning quick after a while). At least for me, both of those cases are not rare. In my opinion (unless the notification does something like launching the relevant app or is dismiss-able by clicking on x) it should simply vanish when the user moves their mouse cursor over it. That would probably cause a lot of accidental dismissals. Believe me, I'm the first in line to complain that NotifyOSD is *far* from being perfect, but as you can see it is not exactly trivial to come up with fixes that do not cause other, significative, problems. There are a lot of different cases to consider. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] unity and notifications
Another idea would be to only have messages fade in place of the right half of the panel, thus leaving the unrelated Applications Places System menu unchanged. I like this, touching would close/restore the top right. If it was an important event it could be reopened from the calendar app. ___ 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] unity and notifications
I thought the current OSD design was based on the idea that it doesn't matter if you miss one notification. ;-) So what would be wrong if the notification was simply discarded in that case? It collided with a much more important action, so it's only natural that it would yield priority. Like I said, it's not necessarily a much more important action. It could be a very mundane action, but whose movement you couldn't stop by reflex. Furthermore, it is one thing to miss one notification because you were away or not paying attention. It is another, and much more annoying, thing to know *something* has happened and never knowing *what*. IMHO much of those problems are due to the NotifyOSD giving itself too much airs. If it truly accepted its role of being secondary to everything else, and just disappeared when it's unwanted, it would be a lot less intrusive. Actually there's a really simple fix that would solve both your problem and the one of obscuring graphical applications, and it's this: don't ever show a notification while the user is working on something else. The way to detect the user work must be heuristic, but there are some good clues to it: - never show the notification while the user is actively providing input. Typing, moving the cursor, drag gestures. - After heavy user actions (pressing keys, clicking) wait at leas 5 seconds before showing a notification. - If the user is working at a fast pace and the notification remains hidden for this reason for longer than its useful lifetime, simply discard it forever. These small additions would prevent a notification getting in the way. In these cases the user wouldn't have noticed or wanted to read it anyway, so nothing of value is lost. I can be typing very fast... to copy a recipe of cake my grandmother sent me. I can be constantly moving the cursor... to play a flash game. I can be working at a fast pace... because I had one coffee too many, not necessarily because the task is important. I think you are proposing a *very simple* heuristic to guess *very complex* thoughts. ___ 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] unity and notifications
It always has and still appears to me that the notifications should not be completely ephemeral, or rather, not all notifications should be. Instead there should be a log of some kind where I can look up what happened while I was away. Maybe notifications need to come in various levels of seriousness for this to work, though, because I would indeed not be interested to read a log of a hundred IM status changes. Actually, a lot of this is implemented already. Logging missed notifications that require not-necessarily-immediate response is what the Messaging Menu does. And in Lucid notifications have priority levels. Low priority bubbles are not shown when Totem is playing, for example. ___ 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] unity and notifications
I forgot to include a link with a small mockup. as usual, a picture is worth a thousand words. :) http://ompldr.org/vNWpzNg -- Daniel Planas.A www.lightgraphite.com ___ 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] unity and notifications
I'm thinking they should stay where they are BECAUSE there are other things like (w)indicators there. That way the users knows the upper right corner of the screen is for notifications of any kind. From: daniplana...@gmail.com To: ayatana@lists.launchpad.net Date: Wed, 15 Sep 2010 17:36:13 +0200 Subject: Re: [Ayatana] unity and notifications I forgot to include a link with a small mockup. as usual, a picture is worth a thousand words. :) http://ompldr.org/vNWpzNg -- Daniel Planas.A www.lightgraphite.com ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp ___ 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] unity and notifications
On Wed, 2010-09-15 at 18:35 +0100, Michael Jonker wrote: this can get in the way - especially considering that many apps, especially on the graphics sides of things, have their toolbar in that location. I have been caught a few times where I have had to wait for the notification to fade out before I could continue working. But Ubuntu notifications fade out as soon as you move the mouse there (or do I misunderstand you?). This was /the/ big change in Ubuntu's notifications a few releases ago, and along with the non-existing close button in the bubble it caused a lot of controversy initially. I think this worked out pretty great in the end and diminished the obtrusiveness of bubble notifications. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
