“Status icons” go by a few different names. A lot of people know them by the area where they appear, which gets described as the “system tray” or “notification area”. Whatever you call it, it’s the place where a string of little icons often gets shown, typically by applications that are running in the background.
GNOME 3 currently shows status icons in the bottom-left corner of the screen, in a tray that slides in and out. We know that this isn’t a good solution. The tray gets in the way and it generally feels quite awkward. There’s a general consensus that we don’t want to continue with this UI for the upcoming version of GNOME 3.
At the same time, the GNOME project has done a lot of work in recent years that reduces the importance of status icons. This includes integrating media controls and weather information into the shell’s calendar drop down, creating the Night Light, and working with third party application developers to reduce their reliance on status icons. In the next release, we will be introducing a new integration API for file synchronisation apps, which will be another positive step.
From GNOME 3.26, we are therefore planning not to show status icons in GNOME Shell by default. We feel that, long-term, this change will enable us to provide a better experience for our users (I’ll go into some detail about this in the rest of the post). We also feel that the consequences of the change won’t be as dramatic as they would have been in the past.
We do recognise that people are using status icons today and that some will continue to want to use them. That’s absolutely fine, and our decision to stop showing status icons by default is in no way a negative judgement on this. If you want or need to continue using status icons, you should feel free to use the TopIcons GNOME Shell extension. This will continue to work and the extension offers a better status icon experience than the current default anyway.
We will, of course, continue to monitor the situation, and will be listening to feedback. There is also a full set of information about the change on the GNOME wiki, including an FAQ and guidelines for application developers.
Advice for application developers
Having reviewed how applications are using status icons, we are confident that the majority of applications that use status icons will not be impacted by the decision not to display them by default. In many cases applications won’t have to make any changes, and if changes are required we have hopefully contacted you already.
It is also worth noting that many of the recommendations for how to provide a good experience without status icons are established guidelines anyway, and can be adopted whether an application is using a status icon or not (such as using existing APIs effectively and having a consistent behaviour when your application is launched). This is a great opportunity to improve applications more generally!
If you are an application developer and are uncertain about whether this change affects you, or how to adjust to it, check out the guidelines on the GNOME wiki and feel free to get in touch if you are still uncertain. We want to help you any way we can.
The rest of this post includes background information on our approach to status icons. It will hopefully help those who are interested to understand the decision a little better.
The why.
Still with me? OK, let’s continue!
As a starting point, it’s worth pointing out that status icons are pretty old. The first version of the spec is dated April 2002, which means that it predated GNOME 2.0. They had “balloon messages”. It perhaps goes without saying, but status icons are something that we inherited, rather than something that was designed as part of the overall experience.
But why don’t we want them anymore? There are some specific issues with status icons, which I’ll get on to, but the main reasons relate to a) the existence of better APIs and b) how they align with GNOME’s wider design philosophy and goals. The following are some of these.
1. Purposeful API
In GNOME we have two closely related goals: to provide application developers with a clear vision of how apps should be built and to provide users with a simple, easy to understand and logical experience. One key ingredient to achieving this is to have a straightforward set of APIs for application integration.
We want to have clearly differentiated APIs, with each one having its own role. Primary examples include:
- Notifications for informing users about events
- MPRIS for media playback
- Search providers for integrating with system search
- libcloudproviders for providing integrated file sync services
Status icons originated prior to all of these, and overlap with three of the four. This creates ambiguity for developers and makes it harder to know which APIs to use. Should you use notifications to notify users, or status icons? Is it best to use a status icon or MPRIS for media controls? While some of these questions can be answered by documentation and guidelines, there’s no avoiding the fact that they generate ambiguity and, inevitably, inconsistent application behaviour. Many applications today use status icons as a notifications system, despite the existence of the official notifications API, for example.
2. Application versus system
One of GNOME 3’s central design tenets is to clearly differentiate system and applications. This is intended to make the structure of the experience clear to users. It is one reason why we call the area in the top right the system status area.
Status icons and system status are both concerned with status and there is therefore a natural pull to merge the two (indeed, back in the GNOME 2 days, status icons were used for both application and system status). This is how status icons are typically presented on other platforms. However, we feel that this would dilute the experience as a whole, since it would introduce a lack of clarity over what belongs to what. The influence of this kind of distinction is a subtle but pervasive one.
3. User control
Another key design principle for GNOME is to put the user in control. We aim to ensure that how the system looks and behaves is determined by the user. The only person who should be able to change your wallpaper, your preferred wi-fi networks, your favourite applications or your default email client, is you. This is one reason why we are so keen on the concept of application sandboxing.
The design of status icons goes against this principle. We know from observation that people often only care about a small fraction of the status icons that they are exposed to, and the rest don’t reflect their interests or activities. This stems from the status icon API and the ethos behind it.
Users don’t opt into status icons. They don’t neatly stay out of the way when they’re not wanted (as with notifications). They don’t reflect a particular type of user activity (like MPRIS integration). In essence, they take control from the user.
4. Accessible click targets
Finally, throughout GNOME 3, we have attempted to ensure that click targets are always easy to target. Teeny tiny click targets pose a challenge in a whole host of situations, from those with poor quality pointing devices, to those who don’t have the same level of motor control as others. Look around and you won’t see many small click targets in GNOME 3, and this is why.
This goal was one of the motivations for the combined system status area that we introduced back in GNOME 3.10. It is why those standalone top bar items that we have retained have been made a little wider, with the addition of disclosure triangles.
Status icons are, in essence, a string of tiny little click targets. They are hard to click.
Scalability
Clearly differentiated API, a distinction between applications and system, ensuring user control and keeping our UI accessible are four design principles which inform our view on status icons.
Another reason for wanting to move away from status icons is more a criticism of the concept itself. Part of the difficulty with status icons is just how appealing they are to application authors. They are visually prominent, giving great advertising and brand presence. They also provide users with quick access to application controls. What’s not to like!?
Unfortunately the very attractiveness of status icons leads to problems. Most obviously, users often end up with too many of them.
Every platform that has embraced status icons has ended up having to wrestle with this problem, from the Windows notification area overflow, merging of application indicators on Ubuntu, and a raft of modifications on Mac. In my mind, all of these management solutions are indicative of an underlying issue.
There’s a contradiction at the heart of a system which on the one hand offers to present application UI in a persistent manner, but which can be used by any number of applications. In the end, you end up presenting more information than users can process. When this happens, some of the icons have to be hidden, which means going back on the central promise of persistent presence. The whole concept eventually collapses.
Conclusion
We recognise that this is a potentially contentious issue. At the same time, we hope that this post has helped to provide some better insight into why the decision has been made and shows how it is part of a more general effort to improve the platform.
My feeling is that we have actually been using status icons as a crutch for far too long – that they have been used to fill gaps in our APIs, gaps which are now thankfully getting filled – and that moving away from them will help us to extend application integration in some exciting directions.
Finally, when we say that we want to hear feedback we truly mean it: there are bound to be issues that need addressing and that we need to hear about. The more information we have, the better.
I’ve used TopIcons for quite some time now, rather than the current corner-icon support, so removing them entirely seems reasonable.
However, it’d be nice to have a better way to integrate messaging applications like Pidgin. They don’t quite fit the “notifications” or “MPRIS” model; it might make sense to develop an MPRIS-like standard for IM-like applications.
Same here for pidgin and steam. Almost impossible to refocus or close these things without status icons.
I mean I hate it when apps put themselves into the background when you close them but that’s how it is right now
Never really liked the legacy tray that magically appears and disappears, so this is much appreciated. Thank you for the insights and all the work you’ve put into writing this, I’m sure it will be very helpful to users and devs alike!
I believe Wire . com is also making use of the legacy tray, but I could not find it on the list you are linking to. You may want to add it.
@John
“I mean I hate it when apps put themselves into the background when you close them”
Agree! I think this is the behavior of the default music player and the worst is that it is “intended” to be like that according to multiple bugreports over the years. It makes no sense that both the X-it and minimize button throws a application to the background. The eXit button should work as what it is really intended to do. The issue is specially obnoxious if you are closing the application and the music just continues to play in the background, so you have to launch the application again – stop it – then exit. It’s so weird! Hopefully Alan or someone else that understand UX will have a look at it.
Hi John, just to be clear: when you say “Almost impossible to refocus or close these things without status icons.”, I assume that clicking the app launcher for these apps shows the window?
Oh, you are absolutely right. Seems like I missed that change.
At least Gnome now has an option for letting applications run in the background, see Polari. Should be included in the Freedesktop specs, maybe.
And I agree with having to implement something for messaging, too. I elaborated this further in:
https://github.com/telegramdesktop/tdesktop/issues/3830
It’s possible to put more status icons near the clock? Something like a weather indicator, not for click, just for quick information, instead of having to open something just to have a quick glance on weather, same with cpu/gpu temperature, memory usage and other hardware specs. Basically a way to the user define what he wants to get quick information directly on desktop, without the problems you guys talked on this post. Sorry for any bad english, not my native language.
I am a big fan of Variety (http://peterlevi.com/variety/) periodically changing my wallpapers. I regularly rely on it to lookup information about my current wallpaper and skipping to the next one. Quick access to such functions is provided by a “tray icon”. Maybe there should be a Wallpaper Manager API for this.
I think we can find a lot of small “tray icon applets” like this. I think it’s a good idea to get rid of as many as possible. But given how much third-party software relies on them – it might be too soon.
Imagine how long it may take to ship to desktops a new API for managing IM clients, managing wallpaper managers, and all the other things tray icons currently do. I think it’s great to find better solutions for all of them and get them ported to better APIs and better UIs quickly.
But on current desktop operating systems, which only update every few months or years – an application that only works with a tray icon in its current versions might not work for an entire operating system release cycle between the time Gnome chooses to remove support for tray icons and the time the application finally gets ported to new APIs – if it ever gets ported, that is.
Is there so much harm in leaving the API up for a few legacy applications?
Also, great – MPRIS is cross-desktop already. But what about libcloudsync – how is that looking on the KDE front? And XFCE and … I’m not arguing for the lowest common denominator. Applications can provide new great Gnome-only features and that’s fine. But to expect every user’s loved applications to quickly port to Gnome-specific features or disappear from the user’s UI seems rash to me.
Are there organizational reasons for this? Is the support for this UI so hard to maintain? If Gnome’s ideal user uses no applications with tray icons – they won’t ever see the UI. However, if they do – they probably lack an alternative.
Please consider being more considerate about compatibility.
This is a good point and I absolutely agree that libcloudprovider should be cross-desktop.
As mentioned in the FAQ every solution we propose is cross desktop.
Not only that, one of the reasons of libcloudproviders to exist in the first place is precisely to have a cross desktop solution.
We all know the current situation is less than ideal. For example the current official support for Dropbox is just a plugin for Nautilus, leaving users of others desktops and file managers without support for Dropbox integration.
I believe developers and users of other desktops and file managers are happy with the work we have been doing on this to make them benefit of something we were supported for already. So I’m convinced we have been doing a great job with the cross desktop history and compatibility.
Absolutely agree here. This is GNOME repeatetly killing something that was once working across all desktop environments.
Along with the constant API breakage killing older applications every 2nd year or so, GNOME helps cleaning out the ecosystem of all the somewhat odd and just functional tools users once had the choice to go with.
At the same time Windows still having the notification area.
As maintainer of Liferea I’ve got hundreds of bug reports and had to explain this to users whose application window was uddenly hidden after a GNOME upgrade when the tray was gone. The application of course having no way to know that the tray was invisible.
A simple scenario – you start Pidgin, then close the window. It asks you whether it should run in the background, you say yes. No window is visible, you probably believe it’s running in the background. You suspend computer. After a while you resume it. Now how do you figure out: a) whether Pidgin is still running b) whether you’re connected b) which state you’re in (online, dnd, chatty, etc).
Please note that running the main Pidgin window again is not a solution here. That doesn’t answer the question whether you’ve been online after resume. That only ensures you’re connected *now*. You can’t distinguish those two cases by running the main window. (That uncertainty might force you to run Pidgin main window periodically, just to ensure you’re still connected, if that’s really important to you. Not a great user experience).
The best way to solve this “is everything OK?” question is with an indicator. A quick glance can tell you all of this immediately and easily. Now, how do you propose to solve it without an indicator?
Hey Kamil,
You’re right that there’s no direct indication that an app is running if there isn’t a status icon. However, there are ways to address the issue. First, the app can inform the user that it will continue to run in the background, the first time that you close it – so the user has advance knowledge. Second, notifications of incoming messages are a sign that the app is running in the background. Third, the more that apps consistently behave in this manner, the more confident users can be in their expectations of whether something is running or not.
Part of the issue that you’re referring to here is that desktop applications have tended to be behave inconsistently (partly because of the existence of status icons, in my opinion). This makes application behaviour unpredictable. As users, we shouldn’t need to be in the situation of having to check whether applications are running or not – we ought to have confidence that they are doing the right thing – running in the background when we need them to. We shouldn’t have to manage our desktops – they should Just Work.
I think this ignores the fact that for a certain class of application that runs in the background, users want:
– infrequent but quick access to the main window and/or a few controls (pause torrents, set presence status), without switching workspaces;
– a way to hide the main window and get it back from any workspace
– check state of a particular application at a glance from any workspace
GNOME currently doesn’t do minimized windows by default, so I end up putting Transmission, Telegram, IRC etc on a workspace every time I start a session. It’s an annoying chore and it feels like clutter.
I get the ideological purity arguments for removing status icons, and I agree that there must be a better way.
I
With that said I think you may be missing the reason they have hung around so long. It’s a window management issue for users. The current activities overview doesn’t fit the ways we want to access long running, infrequently used apps.
Simply removing status icons does nothing to address this.
If I could plus a hundred to this comment.
You need to do UX testing (actual, with links to your methods) I know it’s a pain in the arse and easier if one just assumes a bunch of stuff about users, but honestly what you’re saying makes /sense/ but it doesn’t make /science/.
If it’s important enough to cause millions of people potentially to hate you, it’s probably important enough to sit down with some paper and pens and some different use case scenarios.
Putting things in another workspace is easy, and the correct way to deal with windows you don’t use often. It’s very easy to get back to that workspace or switch directly to that application in Gnome.
Exactly!
> First, the app can inform the user that it will continue to run in the background, the first time that you close it – so the user has advance knowledge.
As Kamil said: This doesn’t address the case when the user turns on his PC from standby.
> Second, notifications of incoming messages are a sign that the app is running in the background.
What if no messages arrive? Is Pidgin running?
> Third, the more that apps consistently behave in this manner, the more confident users can be in their expectations of whether something is running or not.
If they behave consistent like Polari, this just means that the user can be confident that he doesn’t know if an app is running when he turns on his computer from standby.
None of your three points addressed the issue, please give it some more thought.
I have always called them Indicator Applets. Not sure if this is the correct term but at least in Unity, this is what they are called.
Did you get any feedback from the creators of popular applications like Steam or Discord? Will they adapt so that the close button in the title bar or the close entry in the application menu actually closes them?
Steam can at least be properly closed using Alt+F4. The only way to close Discord is to close it from the status icon menu (killing the process works as well, of course). The close button, the ‘Quit’ entry in the application menu, the close button on the application overview, and Alt + F4 all minimize it to its staus icon. Requests to change this behaviour have been filed over a year ago, but the developers plainly don’t want to change it.
On the one hand, abuses like this are precisely why status icons are a pest and have to go. On the other hand, if they don’t adapt, it will be painful to continue using applications like these, and non-technical users might never figure out how to close them once they are open.
Hey Martino, I don’t think that these apps should need to change their behaviour – they should continue to run in the background after their windows have been closed.
I disagree strongly about that. You’re saying that it’s okay for an application to just never close, and instead hide themselves and keep running in the background after a “close” action is performed, with no indication at all that this happening – they don’t show in the overview, and have no icon in the dash.
I’d have to look at what processes are running to find out whether it is still on or not, and if I actually want to make it go away, I’d have to kill the process. That is the opposite of user friendly, and I’m not okay with it. I dislike status icons as much as anybody, but bot being able to close an app and not knowing whether it is running or not is worse.
I think that the UX Scalability and having all controls and buttons be a “minimum size” for touch interfaces is a completely valid point.
I also think that maintaining a simple UX and avoiding duplicity overlap of “Some Application Control’s Here” and “Other Application Controls Over There” makes sense. (I use Dash to Panel).
At first the headline made me sad and think that we might be trying to achieve a level of Idealism that is oversimplifying beyond Practicality, but I think *if* executed correctly this could be an improvement.
I think the next logical step would be to identify what exact “use cases” Status Icons serve in most users workflow and ensure that those use-cases are catered to with adjusted functionality.
For example:
1 ) Status Icons serve to show that a Application is running in the background and to show main controls a user might be interested in when bringing it back.
1a) Example: “No Machine” Icon is a reminder that Remote Access is available but not necessarily important to the user at the time.
1b) Is there a way to denote in the Gnome Dock / Dash to Panel / Dash to Dock that a Application is running in a “Background State” perhaps by I. Rendering the Icon color to monotone blue or by a specialized indicator — perhaps ∞
1b) Another example of a application with a useful indicator is HexChat, HexChat blinks between [ X ] and [ ! ] to indicate messages addressed to the user, and I may not necessarily want to have it open in my standard Window List Dock. I realize that the notification API could serve this purpose. (On a side note it’s really frustrating that Polari [wontfix] automatic user authentication login to IRC rooms like #archlinux, #debian, etc… but I digress.)
1c) Another example of an Application I may want to run in the background is Evolution. Currently Evolution can be “Closed to Tray” — I need my computer to notify me of new email as it becomes available.
These are some use-cases which I think could use some fresh thought.
Derailing again for a moment, if Empathy had group chat functionality it could actually serve as a replacement to Hangouts and other IM Clients and probably integrate with the whole IM Notification API (Whatever it’s called). At present it seems that certain Gnome Apps might need to look for the Use Case Areas that they can improve in where mass adoption hasn’t taken place.
I’ll be excited to see what the team comes up with.
One problem I see is that most applications have the default settings to close in the system tray, that would automatically cause a clueless user to close the application and then could not find it.
As John mentions, an API for messaging applications makes a lot of sense. While text messaging can use the notification system, it is somewhat different for voice calls and video calls. One suggestion would be to add something similar to the MPRIS integration and be able to see a “permanent notification” that allows you to answer a voice/video call or terminate one without resorting to the application window (if at the same time it silences other system sounds even better) . It is very similar to the operation of mobile OS.
You covered the APIs that conflict with Status Icons, but you forgot a variety of other uses of the System Icons. I’ve those icon in my tray:
1. Dropbox and NextCloud: conflict with libcloudproviderapi.
2. Slack and Skye: conflict with what API?
3. Rescuetime: conflict with what API?
4. Steam: conflict with what API?
5. TeamViewer and HelpDesk: conflict with what API?
Status icons usage can’t be covered with specific set of APIs. They’re so generic to do so. main advantages of them:
1. Icons are mostly reflecting a certain status (Chat: Online, Idle, Offline; Cloud: Synced, In-Sync, Cannot Sync; … etc).
2. Right/Left click contextual menu with shortcut to many actions like switching chat status (and some informational menu items: like how many files are being synced, the speed and the remaining time).
3. Icons are also indicators of the background apps.
So, if you gonna replace those status icons, you need to provide an alternative to these features. for example:
– Icons in the Dash or Application overviews can reflect a certain status of an app.
– Icons use the quick actions menu to provide alternative to the status icon contextual menu.
– A way to determine background-running apps.
It’s also important to note that the power of Android notification system (you used to have this power, then lost it with the notification redesign) is something needed to fully replace System Icons on this regard. The actions in the notifications should be accessible from the notification drawer again after missing the notification… etc.
The problem is that this is a very GNOME-focused view – but not everything is a GNOME application.
Don’t get me wrong – I understand the issues with status icons – but the unavoidable fact is that many of us have non-GNOME apps that require status icons. Your cloudprovider API presumably covers the likes of Dropbox, but it still leaves others like the Steam client, which have presumably inherited that “minimise to systray” behaviour from other platforms like Windows.
So, what’s the plan for those kind of things? Is anyone looking to talk to work with the other desktops on this, so that apps have one way of doing things that works on GNOME, KDE, and anything else that implements standard protocols? How about working with Valve and others, to ensure that non-GNOME software can cope without a system tray?
Hey Simon,
As mentioned in the blog post we are tracking and speaking with those apps developers, and as mentioned too we will be adding more apps as we keep contacting them. I have special interest in Steam as you mention.
Not sure I understand your comment about GNOME and KDE, the solutions we propose are cross desktop and work for any Linux distribution.
Good to see them go away!
Are you in contact with Dropbox and Skype developers about this? They are key proprietary users who see their UIs partially break.
I use topicons plus, it makes my GNOME desktop complete, I use to monitor the status of my NextCloud app and Telegram
Please please dont break or remove this functionality. I know that there is no plan to at the moment but just for the record – DONT :-)
Hey Ade,
Nextcloud is actually working with us developing libcloudproviders to move away from status icons, and you will be able to use Nextcloud with Nautilus integration in GNOME 3.26 already.
On the one hand, new tech like flatpak could allow one old app to keep working on newer and newer Linux. This is not everyone goal, still would gradually remove an extremely strong fetter making Linux thus GNOME adoption nearly impossible.
On the other hand, decisions like this , while making lot of sense, cancel this imo. Because proware for example do not want to be forced to adapt to something keeping changing.
But promoting topicons is a nice move. This is useful. Maybe something can be done for users who do not know topicon? So they would be informed via the shell or something
I think we should aim for 3 things:
1. A consistent way for applications to remain running, while not showing an application window — “background applications”. (Moving the window to another workspace is evidently inadequate for some users.)
2. A consistent way for the user to see which background apps are running.
3. A consistent way to open a menu for a running background application.
It feels like 2 and 3 should live in Gnome’s app launcher, but a nice UI design for this escapes me.
Thanks for the detailed blog post and the explanation. This surely explains a bit better the Why. What I am missing a bit is the How. Let me explain this.
I am just looking at my System Status area, and I count 8 Icons. Thats a good average of my standard Icons. There are some that I would not really need (geany and Shutter), but they are great for having quick access to the tools when I need them.
I also see a sealert, that I need to take care of, Zim, which is great to have handy, but minimized when not needed and WMail, which is my mail “app” and also good to have there, but out of the way when I want to focus. The last Icons are: hexchat, Telegram, Slack and these are the really needed Icons.. well. lets better say needed notifications. IM tools are by default communication with teams and colleagues, so they are vital for the job. The blinking of the Icon (or a little number or dot like with Telegram or Slack) shows me hat I have messages I need to take care of.
The current solutions offered (hidden notification bar at the bottom (Gnome 3.8) or the dot next to the Date and time (Gnome 3.22) are just not doing for me what they should do.. give me a clear notification of whats going on. They are basically collected notification from all apps, and I need to figure out by going through it, if it actually makes sense. With the current use of TopIcons, I know exactly what tries to notify me in regards of IM tools.. Telegram is only personal communication, so I do not need to look at it right away.. hexchat.. better have a look, there could be something important.
I currently just do not see how this case is addressed in any of the designs, and I agree with you.. the little bar on the bottom left in current gnome, is having the same issue. it is hidden, which defeats the purpose of a notification for me.
So what are the ideas to tackle these cases.. or am I just a dinosaur that does not see how to do solve the case already today in a better way?
Thanks for your feedback on this,
Oliver
Thanks for your feedback Oliver. I’ve added some of the examples you’ve mentioned to our tracking page.
The issue is in RhythmBox. Gnome Music works as intended, but it has it’s own issues so I guess thats why both music players are included which too is a little weird.
Hey Greg,
1- “background applications”
This is mentioned in the guidelines posted in the blog post. You can check them at https://wiki.gnome.org/Initiatives/StatusIconMigration/Guidelines#Running_in_the_background
2- “A consistent way for the user to see which background apps are running.”
Indeed, unfortunately this is not currently technically possible. One benefit we will have with Flatpak apps is precisely this very same item, and that’s why we are pushing with this technology, it will enable all type of features and benefits for the user.
3- “A consistent way to open a menu for a running background application.”
A menu for a background application? This asnwer is technical, but applications can export menus to DBUS. Or do you mean GNOME Shell should show menus provided by applications in some kind of UI that is not the application itself?
It that would be the case, we are in step 0 again, in a similar situation than with status icons.
Just a thought on 3. A settings panel similar to the notifications one could be developed to allow the user to control which applications are *allowed* to have a menu, those that are not allowed to have one should not continue running in the background when closed.
If you actually wanted to put the users in control you would implement a system that allows the users to control which status icons appear whether the application wants one to or not. Just getting rid of them all together removes control from users who want to use applications that want to use status icons, and removes control from users who enjoy having applications have status icons. Relegating them to an extension prevents most users from being able to take advantage of applications that use them and at the same time does not actually improve the experience of users who want or need to have some status icons.
Whenever you consider altering in any way a long-standing UI convention you should do so *very carefully* and err on the side of not changing it at all because you have limited ability to grasp the ramifications of such a fundamental change. Making small, incremental changes and using feedback from a wide user base on the extent to which those changes are helpful is the best way to avoid strife and make user’s lives better. Not following this path is, to my mind, a blatant declaration of disinterest in helping users.
To shrug your shoulders and say “No solution to this problem exists!” is ridiculous: a solution exists, it’s called “status icons.” The fact that there are some things you don’t like about them does not mean that there is actually an intractable problem. Hard to click? You can trivially scale the icon and make the click box larger. Too many? Provide some way for users to choose what to show. Hidden icons not discoverable? Figure out some UI to indicate that there are hidden icons. “I don’t like that they overlap in some cases with some other APIs,” cry me a river, GNOME developer! Your end users don’t care about API overlap.
I agree that status icons have some issues (like the propensity for programs to treat “close” as “minimize to status area” instead of doing what the user asked for) but removing support for them is a non-starter. I know you *CLAIM* that support is not being removed and that there are ‘merely’ hidden by default, but I have seen this kind of scenario play out with GNOME in the past: Today they’re announced hidden, next release they’re hidden, some users grumble but most restore them with an extension, five releases later someone quietly proposes dropping support, two releases after that it’s quietly done… and then all hell breaks loose as users howl bloody murder over this betrayal while smug GNOME developers say “The plans have been on file with your local planning office for the past nine months!”
Either propose some alternative that addresses *EACH* and *EVERY* use case that are satisfied by status icons now, add support for that alternative and ONLY THEN remove the default display of such icons. Until then *retain support*, users depend on it. Not doing this is an *attack on users* no matter how you want to sugar coat it.
Since we have identified TopIcons Plus as a superior UI to the disappearing icon tray, why not integrate that as the default, to handle the odd use cases which cause apps to grow try icons in the first place, while continuing to work on more purpose-built APIs and the third party apps that would need to grow support. Tray icons solve a need for ad-hoc status indicators and persistent menus that you haven’t built support infrastructure for ahead of time and should be retained as a user-visible feature.
I use Cryptkeeper and the status icon for this application is really useful.
I see Cryptkeeper is not tracked in https://wiki.gnome.org/Initiatives/StatusIconMigration/
Could you please add it?
Thanks
Added! Thanks Egan.
Yes punish your users and applications for using a feature as intended that’s a great idea… Really? Burying your heads in the sand isn’t a proper solution nor is removing a feature that developers and users use because you don’t want to solve the problem.
I’m working with Gnome on a 9-5 basis as embedded developer since many years. In the recent months I noticed that the tray icons are the most uselsess, annoying thing: distracts work flow, is not uniform to application menu, and steals control of my desktop. On Windows (in a vm) it’s even worse. Just let me do my work, and stop distracting me!
I’ve never thought of removing tray icons before, but it makes sense. And it fits to Gnome 3, because eg. there is no concept like minimize. A tough decision for pull this through, like Gnome 3.
I hope seafile, variety and other apps will adopt this somehow. Tray icons are not touch friendly and are a bad ui concept imho (compare with iOS, Android, BB10, Windows phone: no tray icons) . Until app producers notice that, there is TopIconsPlus.
I understand that other people want distraction and nagging, blinking brand icons.
> If you want or need to continue using status icons, you should feel free to use the TopIcons GNOME Shell extension. This will continue to work and the extension offers a better status icon experience than the current default anyway.
Well, currently, both TopIcons GNOME Shell extensions do NOT work very well on Fedora 26 (GNOME Shell 3.24).
They easily crash your GNOME Shell session.
See for example:
https://bugzilla.redhat.com/show_bug.cgi?id=1474022
Simple experiment was: enable TopIcons -> use GNOME Shell for some time -> GS crash -> use some more -> crash -> disable TopIcons -> enable TopIcons Plus -> use GS for some time -> GS crash -> use some more -> GS crash -> disable TopIcons Plus -> no more GS crashes
The GNOME Shell developers don’t seem to care much about such crashes.
Even the linked similar older bug report didn’t receive any attention until being EOLed.
FINALLY!
Would you please add Wire and GEncFSm to your list? ;)
Done! Thanks Frank.
This essay was an absolute joy to read. Serious, clear, intentional thinking on UI is one of the reasons I love Gnome, even when the just and right conclusions don’t sync with the facts on the ground :).
I so dislike the entire status icon interface. It’s bad, lazy, wrong, everything on so many levels. It’s an absolute mess in Windows, where even a new install is already crammed with 6-10 near identical little icons in the shelf.
Just as Apple was “courageous” in eliminating the headphone jack, which was an unnecessary yet maybe essential step to moving to a different level of audio interaction, I applaud Gnome and the author for striking out and doing something that’s perhaps dissonant in the pursuit of finding a better way. This is why we love Gnome. Keep it up!
So, breaking stuff without offering a working replacement really is the Gnome way? Because that will be the result.
I applaud that Gnome wants to find better ways to design the (Gnome) desktop but you simply can’t keep replacing components without ensuring the required/expected functionality is there.
First you remove the working push-down tray and move the tray to a barely working button tray. Then when things don’t work out you remove even more things and tell the users to just install an extension.
Moving the notifications from the bottom, where they were fine, to the top, where they keep getting in the way, shows a similar trend where form is more important than function and the changes are a) not ready for prime time and b) not user-configurable.
Redesigning existing solutions doesn’t work that way. You either come up with something better that actually works for (almost all of) the users, you offer the new and the old solutions side by side, or you simply lose important functionality and upset your users. Creating replacement APIs will probably not completely replace the functionality and lead to broken workflows and more time spent on large bugzilla threads. It also would not work cross-DE from the get go so good luck with getting applications on board of your solution.
For this specific issue I think it is fine to remove the tray and point users to the replacement extension. This does mean that you will finally treat extensions and gnome-tweak-tool as an integral part of the Gnome desktop (i.e. installed by default and available in the control center), right?… Yep, didn’t think so.
For once, please consider to first come up with the required functionality, then when it has proven itself, feel free to remove deprecated things that are no longer necessary. If Gnome wants to keep breaking stuff then please create an unstable release branch so that users that want to run Gnome without living on the bleeding edge can do so and new/replaced functionality is actually properly vetted for prime time. The way it is done now (pushing the development branch to release twice a year and then let the users complain things are not the way they should be) is clearly not optimal.
What Gnome should do is rethink what you are trying to do and how you want to achieve it. Currently the mission objectives are not in balance. Do you want to strive for a) elegance, b) efficiency, or c) a DE where people can get work done. You can pick only two (let’s call it the GNOME theorem).
/rantoff from a 5-year-long Gnome 3 user that finally needed (but didn’t want) to switch to another DE because of no longer being able to get work done due to instability and constantly working around half-implemented components.
Why do you recognize that there is a need for system status indicators and fail to do the same for applications.
Why should users be continuously reminded of their Wi-Fi signal’s strength, and not of whether they appear available/away/dnd?
In other words, why is Wi-Fi first-class citizen and IM second-class?
I understand the reasoning but removing a feature before providing alternatives and breaking people’s workflows for at least 1 cycle is sounds like an irresponsible thing to do. The mentioned new APIs should land first and only then should the old deprecated feature be removed. This is basic stuff. Can’t understand why the decision was made to remove it and replace it with the promise of a replacement.
Also, I’ve not read the notification API linked to in this doc yet but will it support persistent notifications that temporarily highlight the app icon with badge/count/colour somewhere in shell (like Android)? If not it’ll not be a replacement for the status area. I agree apps don’t need to keep presence in the shell all the time but some apps need to need it to function properly. For example a mail app might want to show a icon when an important/urgent mail arrives or an app like slack should always visually indicate when there are unread messages. What is the recommended way to do this for developers of such app going forward?
I apologise if I sounded rude in my previous comment. I don’t necessarily disagree with the direction Gnome is headed in, it’s just that the plan doesn’t look well thought out to me. Sufficient alternatives need to be in place and need to be tested for some time before we remove don’t functions that could be critical to a lot of workflows.
The real question is: why not KDE, neither Windows or Mac, ever has had the urge to drop their system tray?
Sure it’s haphazard. And you don’t want this kind of code in Gnome world, but at the moment there is no cross desktop alternative. Fairly large impact on users clearly outweighs the removal.
Talking about Dropbox, Steam, Telegram etc…they never adopt this kind of de specific workflow. We are lucky that we even them in Linux. But in general Linux world is like this. Not consistent at all. You tried to bring “order” in Linux universe, but you forgot that natural order in Linux is “chaos”.
As a user, I want to have control over which applications are running, have them either show up in activities overview or in a system tray. I don’t like other applications to run without my consent or without having me know. Long-running applications which are in the background don’t fit into this unless they can utilize system tray icons.
Allan,
Thanks, really, for this article.
As you said there are some cases not covered by the four APIs you have
described, in Remmina [1], a Gtk+ remote desktop client, we use the
status icon in one of that particular borderline cases.
As usual one image is better than thousands words, so I hope you don’t
mind taking a look at these screenshots [2].
Our users usually works with some hundreds of servers, grouped per
customer, geographic location, data-center, and so forth.
While they work on other tasks, it happens that the main Remmina window
is hidden or closed and they use the Status Icon to quickly access the
profile they need. Sometimes even if the main Remmina window is not
hidden, they use the Status Icon anyway because they found it useful
and really easy to access (3 clicks at a maximum).
The API I think we should use, it’s the search provider, but I’m
not sure it would be easily accepted and that it would be really tricky
to implement, search a server name on a sysadmin laptop and you will
be disgusted by all the results you will get. Another point is that
this fantastic API will work only on Gnome Shell, so a lot of work for
us and almost no gain.
In fact our biggest hurdle is that there is not only Gnome in the
universe, and those users using other Desktop Environments, that support
a Status Icon like system, they won’t accept that we remove that
functionality just because of the Gnome project decisions. As you can
imagine a FLOSS project maintained, for free (as in beer), by just 3
busy over 40s guys, we don’t have time to maintain different solutions
for each very different DE.
What do you advice if you can? If there are not easy solutions, are
there any hopes we can bring this to the attention of the Gnome
community?
Sorry for the long comment and thanks for your answer!!!
[1] – https://github.com/FreeRDP/Remmina
[2] – https://imgur.com/a/LNSp9
Thanks for your comment Antenore. You shouldn’t have to make any changes to Remmina in order to adapt to this change – the status icon can be left as it is and it simply won’t be shown in some environments. I’ve sent you an email so we can discuss this in more detail, should that be helpful.
Congratulations! Since Ubuntu did the same six years ago, I hope you can benefit from lessons we learned, to avoid mistakes we made.
One big mistake was to introduce a unified UI for cloud sync, the “sync menu”. I don’t see any published UI design for libcloudprovider, but you seem to be trying something similar. We ended up dropping it, because no third-party vendors ever adopted it. This was completely understandable: it would have been more work for them, for less brand visibility, and no obvious benefit. (Contrast this with the sound menu, where appearing in it was just one effect of implementing the Mpris API, which had other tangible benefits.)
This leads to a second mistake: if you’re going to provide “clearly differentiated APIs”, you’d better be able to maintain your boundaries. We had this problem with Ubuntu’s “me menu”: chat and microblogging turned out not to be a useful grouping, APIs or no. Similarly with the messaging menu: our definition was “messages from humans”, but app developers were sometimes tempted to put messages from computers in there as well, making everything murkier. Any libcloudprovider UI would have this problem in two ways. First, if a cloud provider is being used merely as storage for a backup utility or sharing utility that has its own UI, should it still appear in the libcloudprovider UI as well? If so, people will learn to tune it out. And if not, how would the provider “know” whether it’s being used for something that has its own UI or not? And second, what should a backup app do if it provides both local and cloud backup, like Déjà Dup or Crashplan? Should it try to trick libcloudprovider into thinking that the local backup is really a remote one, so that they will appear in the same UI? Or should it have two separate UIs for the same app? For a developer, the obvious answer to all those questions is “screw that, we’ll do our own thing”. And if a few prominent apps do that, it becomes confusing to users why some are sharing a UI and others are not.
Finally and most importantly, a mistake that we avoided. One which maybe you realised as you were writing about it: “Status icons and system status are both concerned with status and there is therefore a natural pull to merge the two … This is how status icons are typically presented on other platforms. However, we feel that this would dilute the experience as a whole, since it would introduce a lack of clarity over what belongs to what. The influence of this kind of distinction is a subtle but pervasive one.”
Don’t be disheartened that you weren’t able to write any specific, practical reason for expressing the “distinction” between two things by banning one of them. Treat it as a hint that the reason doesn’t exist. If f.lux or a similar utility includes more bells and whistles than Gnome would ever include in Night Light, or if a third-party vendor offers a Gnome equivalent of Battery Diag or Coconut Battery that does more than Gnome’s battery status UI would ever do, or if a VPN-specific UI or equivalent to Tripmode has more specific features than Gnome’s networking UI would ever have, or if an equivalent to Fantastical or Itsycal does different things than Gnome’s clock would ever do, then … great! This is what I meant at Guadec when I warned against “trying to do everything yourselves”: you don’t have the resources, and even if you could, you wouldn’t want to. And when others do it instead, there’s no reason to force their UI to have a completely different posture than the built-in equivalents, or to be implemented as a shell extension that breaks every year or so and is needlessly inaccessible and inconsistent with similar extensions.
All those examples demonstrate that whether the status of something is best presented in the status area has nothing to do with whether it’s a third-party app or part of the system. It’s entirely to do with how frequently and how urgently people want to access that status. And if the most appropriate presentation for a function is an always-present item in the panel — whether it’s a Pomodoro timer, or a weather forecast, or a time logger like RescueTime, or an emoji search, or a CPU monitor like indicator-multiload, or a clipboard manager — there is no benefit in depriving people of that presentation. Trying to reduce “ambiguity for developers” by banning it altogether would be like another mistake we made, when we thought we could ban parentless dialogs in Ubuntu Touch: the alternatives turned out to be worse. Even measured against your “distraction-free” goal, forcing app vendors to use windows (which have to be switched to+from) or notifications (which have to be dismissed or waited out) instead would result in more distraction overall, not less.
So, here’s one thing we got right. We recognized that we couldn’t, and wouldn’t want to, implement ourselves everything that would be best presented in the status area. And we recognized that trying to reduce status area clutter by blocking apps from using it altogether would be like trying to stop floods by paving a river. Instead, we provided an application indicator API that made indicators consistent and accessible, which KDE also adopted. And we let people turn off individual system indicators, both to remove distractions they didn’t want, and to set a good example for app developers to do the same.
The tiny number of Linux apps, compared with Mac or Windows, has often made misguided platform decisions seem more reasonable. Don’t let this be one of those cases.
Thanks for your thoughts, Matthew. It’s really useful to hear about your experiences. My feeling is that pitching libcloudproviders as a cloud provider feature rather than a generic sync feature will help with the differentiation issue that you encountered. Its UI will also hopefully make it clear what its purpose is. Certainly your points emphasise the need for good documentation, which we’ll need to work on soon.
Regarding your final point, I think it’s worth emphasising that we’re absolutely not against applications that enhance or modify the system. If someone wants to provide their own implementation of a Night Light-like feature, then they can do so. Likewise special apps devoted to networking, disk usage, and so on should absolutely be possible. The only thing that we’re changing is the expectation that a system status icon will always be visible. The sole change is that applications need to make their functionality available through their window, if they don’t already do so, and this is a good thing to do anyway.
There’s certainly an argument to be made for being able to place items in the top bar. As ever it’s a question of balance and my feeling is that the cons outweigh the pros (there are three or four negative points outlined in the blog post, I think). For some of the cases you mention we do have extensions which allow people to add “widget” style items to the top bar, should they want to.