[opensuse-artwork] Request for icons for updater applet
Hello everyone!
NOTE: Cross-posted as this involves both teams, IMHO.
We have a need for icons for the updater applet for both GNOME and KDE.
The current icons have certain limitations in areas of usability and
accessibility. Please refer to bug 246157 [1] for an example.
I have made some proposals in the wiki [2]. One might also check the
parent page [3], which also holds the current icons.
Currently we have 4 icons, based on a blue dot with a small label on the
bottom right. Each label indicates a certain state:
* Red: Error occured
* Yellow: Updates available
* Striped(Yellow/Black): Checking for Updates
* Green: No updates
We want to have another state: "Applying Updates", which could be merged
with "Checking for updates" into "Updater working/Busy"
So, UX teams should verify which states need distinguishing from a
usability perspective and artworkers should then find a usable and
accessible solution.
Links:
[1]: https://bugzilla.novell.com/show_bug.cgi?id=246157
[2]: http://en.opensuse.org/Updater_applet/Icon_proposals
[3]: http://en.opensuse.org/Updater_Applet
Thanks in advance!
Josh
--
Jörg Kreß
On Tue, 2007-05-22 at 16:46 +0200, Joerg Kress wrote:
Hello everyone!
NOTE: Cross-posted as this involves both teams, IMHO.
We have a need for icons for the updater applet for both GNOME and KDE. The current icons have certain limitations in areas of usability and accessibility. Please refer to bug 246157 [1] for an example.
I have made some proposals in the wiki [2]. One might also check the parent page [3], which also holds the current icons.
Currently we have 4 icons, based on a blue dot with a small label on the bottom right. Each label indicates a certain state:
* Red: Error occured * Yellow: Updates available * Striped(Yellow/Black): Checking for Updates * Green: No updates
We want to have another state: "Applying Updates", which could be merged with "Checking for updates" into "Updater working/Busy"
So, UX teams should verify which states need distinguishing from a usability perspective and artworkers should then find a usable and accessible solution.
Links: [1]: https://bugzilla.novell.com/show_bug.cgi?id=246157 [2]: http://en.opensuse.org/Updater_applet/Icon_proposals [3]: http://en.opensuse.org/Updater_Applet
Hi Joerg,
I've already talked to the original author, Robert Lihm, but I'm happy
you bring this up.
Current Icons
-------------
The current icons are less than ideal on many levels. The color button
(as the 'unifying' element) is just noise, especially at small sizes,
which is what the default panel ships by default. The silhouette is
exactly the same. Pretty much the only differentiating factor is the
color. From usability perspective this is really bad.
Proposal
--------
The naming spec [1] defines some icon names very much appropriate for
our situation and we should aim to make use of themeability here.
Usability should have the upper hand on branding.
updates available - software-update-available
urgent updates - software-update-urgent
getting/applying updates - process-working
refreshing sources - network-receive
The standard theme icon lookup is described in the icon theme spec [2].
[1] http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.ht...
[2] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
cheers
--
Jakub Steiner
Hi Jimmac! On Wed, 2007-05-23 at 20:36 +0200, Jakub Steiner wrote:
I've already talked to the original author, Robert Lihm, but I'm happy you bring this up. Glad, I can help ;-)
Current Icons ------------- The current icons are less than ideal on many levels. The color button (as the 'unifying' element) is just noise, especially at small sizes, which is what the default panel ships by default. The silhouette is exactly the same. Pretty much the only differentiating factor is the color. From usability perspective this is really bad.
Proposal -------- The naming spec [1] defines some icon names very much appropriate for our situation and we should aim to make use of themeability here. Usability should have the upper hand on branding. I'm totally with you on that. Jan already raised this issue in the TODO v 1.0 for the GNOME applet [1].
updates available - software-update-available urgent updates - software-update-urgent Not available yet. Just checked my directories and cvs upped tango. We should bring this up in tango-artists.
getting/applying updates - process-working Don't you think an animation is to much of an distraction? I'd prefer a static icon and using tooltips/popups to indicate details [2].
refreshing sources - network-receive This is a hard one. Your proposal might be to close to the nm-icon when connected by cable. My current preference (view-refresh) is to close to what we need for indicating the need for a reboot.
Maybe we should also consider a "merge" of refreshing and
getting/applying to one 'busy' and give additional info via tooltip.
[1] http://en.opensuse.org/GNOME_Updater_Applet
[2] http://en.opensuse.org/GNOME_Updater_Applet/Future_Plans
Cheers,
--
Jörg Kreß
On Thu, 2007-05-24 at 16:54 +0200, Joerg Kress wrote:
updates available - software-update-available urgent updates - software-update-urgent Not available yet. Just checked my directories and cvs upped tango. We should bring this up in tango-artists.
I will take care of those in tango icon theme (and eventually in gnome icon theme). I hope I can get Rodney to release 0.8.1 soonish.
getting/applying updates - process-working Don't you think an animation is to much of an distraction? I'd prefer a static icon and using tooltips/popups to indicate details [2].
refreshing sources - network-receive This is a hard one. Your proposal might be to close to the nm-icon when connected by cable. My current preference (view-refresh) is to close to what we need for indicating the need for a reboot.
Maybe we should also consider a "merge" of refreshing and getting/applying to one 'busy' and give additional info via tooltip.
On a second glance, I think the real message it gives here is that it's
doing something and it didn't die. The spinner sounds like a good
solution for both events.
If the refresh can trigger on its own, it may be a little obtrusive to
have an animated spinner. I would still consider this to be the best
solution, but I'm open to try something else for 'refreshing sources'.
cheers
--
Jakub Steiner
participants (2)
-
Jakub Steiner
-
Joerg Kress