unity-design team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----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-----