unity-design team mailing list archive
-
unity-design team
-
Mailing list archive
-
Message #01465
Re: Farewell to the notification area
Hi Matthew, Mark,
First of all, I'd like to say thank you for posting this as a
discussion to the list - whether I like or dislike what you want to
do it's best it's spoken about!
I think I agree with the notification area being a bad thing,
however I'm not sure that a set of unmovable indicators located
at the top corner of the desktop is logically any different - you're
just using a different mechanism to coral all the icons together.
However what you propose to do with those icons is a bit different -
but fundamentally I think that could be done on top of the existing
notification area.
Fundamentally I dislike the Opinionated Placement of the set of icons;
I like the fact I can move my placement icon set to where ever is my
preferred place on my panel.
However, I do like the consistent ordering of the set of icons within
the set of indicators/notifications - I dislike how the order of the
icons in notification area depends on the startup order of the
applications.
(Note here I'm expressing that I like to have control of things
but I like to be able to setup multiple machines, multiple boots
of machines to look the same)
I think there are really a few different types of entry in the
notification area and I think it's pretty important to distinguish
between them when deciding what to do:
a) Status+control of fundamental system things
Network manager
Messaging
Printing status?
b) Applications that want a quick way of getting to a function
b.1) the audio players that provide a play/next/etc menu
b.2) Monitor settings
b.3) parcellite (clipboard manager)
b.4) Volume control
c) Status+control of special things
Maybe a device specific thing
I think the indicator scheme probably works well for (a); although
I'm not sure that it's mature enough to be sure - it's starting
to settle out, but the transition has been a bit painful. These
are about displaying something which may change without you doing
anything and which you might then want to take action on.
Set (b) is interesting; you seem to specifically target the
audio players and the like for using notification icons/menus
for control - but it seems to work perfectly well; there is no
particular reason that you want the full GUI just to hit pause,
I can however see your point that using these icons to (de-)minimise
the main window is a little odd - it is however convenient.
I think the (b) set are interesting that fundamentally they aren't
really used to communicate much status to you other than what
you've told it to do (Volume control shows mute because you asked
it to, Audio player shows current status mostly as feedback;
monitor settings don't show any status and I don't think
parcellite does).
q: What menu would you put a monitor setting applet? Or the Volume ?
Menus by themselves like they are at the moment?
c) What happens to categories for special things? Maybe a specific
hardware control thing or background computation task?
q: What happens to categories that you aren't using? If the
number of categories increases the likelihood that you won't
have some of them increases - on this machine I don't have
messaging setup (that's on the one next to it!) but I still have
a cateogry icon for it - that's a bit annoying but if we start
having lots of categories it gets very very messy.
One thing I'd like to add is a consideration of how indicators/notifications
interact with short cut launchers on the panel.
At the moment launchers are entirely passive - if I create a launcher for
an app it might then add a notification icon; this is a waste - what's
really needed here is the ability for the status/menus for an application
to take over the launcher. (I think this is what Macs do these days,
and if I remember correctly what RISC OS used to do many years ago).
Finally, I'd ask that you ensure that the policy of how to display/interact
is as separated as possible from the API; exposing the set of status
and menu interactions of an application is a good idea - whether
it's displayed as an indicator, a notification or elsewhere - so
designing that API well will give the flexibility for future where
people won't have to change their apps much.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
References