unity-design team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Conscious User wrote on 30/11/11 20:08:
> 
>>> Which reminds me, shouldn't we stop pretending that synchronous
>>> and asynchronous notifications are similar enough to deserve
>>> being close? They are not, and the current approach causes more
>>> problems than solves.
>> 
>> What problems does it cause?
> 
> The most obvious one is the ugly gap when no synchronous 
> notification is being shown. But I personally think that making 
> synchronous and asynchronous informations have the same appearance 
> and positioning is a mistake by itself.
> 
> One is to notify and is supposed to call the user's attention. The 
> other one is to provide feedback and is something that the user 
> expects to appear. So much visual similarity for such different 
> things is confusing.


Fair enough.

>> What problems does it solve?
> 
> I am *supposing* that the idea is concentrating all notifications 
> in a single place of the screen, thus simplifying things for the 
> user. But this only makes sense if their purpose is similar enough 
> to deserve such concentration, and I don't think they are.


I don't remember that there was ever a conscious decision about
whether they should be presented the same way. (That's not covered in
the specification's Rationale, at least.) It was just assumed that
they should be.

> I do admit that the positioning is good when changing the volume 
> with the scrollwheel, but that's the only case I can think of.
> 
>>> If we must insist that their appearance must be the same, then 
>>> the synchronous bubbles should at least be moved to somewhere 
>>> else, like the lower corner (they can be there with no 
>>> problems, since their size is fixed)
>> 
>> In December 2009 I drew up some possible alternative 
>> placements.<https://wiki.ubuntu.com/NotifyOSD#position>
> 
> Ops, sorry. I'm using the old "sync vs. async" terminology when I 
> should be using "confirmation vs. notification".
> 
> Anyway, is it my impression or the current placement is not even 
> considered a valid one according to the specification?


Correct.

> Option 3 is by far my favorite. I remember Option 2 being tested 
> and receiving some bad feedback (of questionable value, though, as 
> I remember it was available for a very short period of time)
> 
> Are there any reasons for not testing option 3?


Only that no-one has implemented it.

>>> But I don't think even the appearance should be the same. In 
>>> the attached screenshot you can see what appears when I click 
>>> the play button when no player is open (I suppose it's a bug 
>>> that notify-osd is not handling this), and in my opinion is 
>>> much better.
>> 
>> Why do you think it's better?
>> 
>> (I'm not necessarily disagreeing with you on any of these, but we
>> need to be able to explain *why* something is worse or better.)
> 
> It's visually and positionally different enough to not be confused 
> with async notifications, and provides a very clear feedback. And 
> at least in my opinion the exposition time is short enough to avoid
> intrusiveness (like volume gauges on TVs)
> 
> ...


And with a more transparent appearance, it could be even less intrusive.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7mQQcACgkQ6PUxNfU6ecokpgCdHYmoG7cDQfRiKCRddcX0shoM
SfkAn2SUgJxgNrEov7Ihg4+28AFArOqc
=0Fmi
-----END PGP SIGNATURE-----