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
-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
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
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
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
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
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
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
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
-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.
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
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
-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
-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
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
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;
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
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
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
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
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 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
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
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
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
-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
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
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
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
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
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
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,
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
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
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
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
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.
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.
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
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:
+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
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
42 matches
Mail list logo
