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 pay
On Fri, 2010-09-17 at 05:26 +0200, Conscious User wrote:
> 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 no
> 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 o
> 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
"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.
__
> 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...
>
That is just what I was thinking. How about an android-esque model, where
the entire panel contents fade out
On Thu, 2010-09-16 at 17:19 +0200, Conscious User wrote:
> 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 t
Yes - the minimise and maximise buttons are redundant in this model, so
you can put your hat back on :D
Several (unmaximised) windows are a tricky detail and has been touched
on in this thread already:
https://lists.launchpad.net/ayatana/msg03660.html
I think it will be possible. Something like
Hats off to you for your attention to detail. If case nobody noticed, the
pin icon does actually work in this last version of the mock up. This means
every original screen has been duplicated to the two possible states of the
pin.
One little detail bugs me. In this interaction model, the maximize
On 16 September 2010 17:19, 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 aga
I have attached the webstats for the mock up page.
In a very simplistic fashion, this gives data about user interaction and
experience.
If development of any UI could happen transparently on the web in the
form of an advanced, fully usable dashboard (such as my mock up would
like to be), I can s
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 ic
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 thi
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 availab
Le jeudi 16 septembre 2010 à 13:29 +0100, Luke Benstead a écrit :
>
>
> On 15 September 2010 17:25, Greg K Nicholson wrote:
> On 15 September 2010 16:54, Conscious User
> wrote:
> > I know it's the space for the confirmation bubbles, but I
> think it
> >
> 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,
My point is not about wanting "just to see what is below". It is about
the notification (as well advanced as it is) being obtrusive and in the
way for a wide variety of use cases, not just mine.
You make a good point:
"A close/respond button creates problems with accidental clicks (a
bubble poppi
That sounds very interesting.
It would be great if the UI development could be accessible to a wider
community with a more graphical focus.
Also, this sounds more flexible to issues such as switching from
landscape to portrait as the apps could be doing their needed reshuffle
in a common language
On 15 September 2010 17:25, Greg K Nicholson wrote:
> On 15 September 2010 16:54, Conscious User 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
> 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.
Sorry I wasn't around for the initial discussion :)
Yes it does fade, but is still there. For me, it is still difficult to
work with an app below this faded notification, eg.
1) In Gimp I am working heavily with layers, creating new iterations of
a scene at a workrate of about 1 second per scene.
21 matches
Mail list logo
