December 8th, 2010 byThe Ubuntu Technical Board is currently conducting a review of the top ten Brainstorm issues users have raised about Ubuntu, and Matt asked me to investigate Idea #25801: Help the user understand when closing a window does not terminate the app. In other words, figure out to signal to the user that an application will continue to run after all of its windows have been closed.
This is more than a good idea, it’s an important gap in the usability of most of the desktop operating systems in widespread use today.
It’s also come up in our user testing: Charline’s research on Unity identified a lack of feedback to users and she observed the same absence of good feedback in the Rythmbox interface, where Rhythmbox can continue running in the background, playing music, with no windows visible.
We do have a few useful elements to work with.
We have been making some changes to the panel, replacing the old system tray with a set of menus known as indicators. One of the innovations there is that background services reflected in indicator menus can signal that they are running, using the triangle on the left – as applications in the Unity launcher do.
We have also been encouraging application developers to think carefully about whether or not an application needs an indicator, or exclusive use of an indicator. We want to reduce clutter in the panel, generally. So we need a solution which will cover 3 different types of applications: those that use their own indicator, those that use a category indicator (such as the Messaging Menu or Sound Menu) and those that don’t have an indicator at all.
The proposal in the Brainstorm idea is a reasonable option, and would work well for all 3 types where the applications without indicators could animate towards their icon in the launcher. This solution does have limitations from an accessibility perspective and an additional solution would need to be designed to cover the accessibility use case. It would be important to mock them up and test them with paper prototypes or simulated (flash?) interfaces. It’s inspiring to see creative proposals – the best way to have a great idea is to have lots of ideas, so more are welcome!
The next steps would be for an animation designer to design the animation and an API designer to design the API. It is also important that the accessibility solution be investigated at the same time.
If you would like help working through ideas on this subject it would be best to jump onto the Ayatana mailing list or #ayatana and look for Otto Greenslade who is working with Mark on exactly this sort of problem. The Ayatana list also has plenty of engineering resource which would mean we would be able to talk about feasibility too. For the accessibility aspect, I would be very interested in working on this as a first point of contact and then we can involve people from the accessibility team for further review and discussion.
The toolkit
23 Responseshide comments
There’s another issue: clicking the X button shouldn’t send the application to a indicator menu but should quit an application. Now for example if i want to quit banshee or rhythmbox i have to kill the process.
The X button function should be replaced by the _ button, but instead of minimizing the application, it sends it to the indicator menu.
It makes more sense to me.
+1
You don’t have to kill the process. Just go to ‘Music->Quit’ in the menu. That terminates the app.
Solution #11: Change color of the close button too
++
I agree with Fire in that clicking the X should quit. That’s what was broken with the minimise to notification area in the first place. It’s also one of the biggest differences between Windows (pre 7) and MacOS/OSX. In the former, the application is the window, so closing the window closes the application. It’s the same paradigm that Gnome uses. In OSX, the window is just a view into the application, so closing the window does just that. It closes that particular view, but does not quit the application. it’s also one of the reasons for OSX having a global menu vs a menu in each app window.
Seeing that Unity is very OSX like (global menu, launcher/dock), it will further confuse matters as Gnome apps are not built with the OSX window paradigm in mind. They’re very much based on Windows.
I mentioned “Windows (pre 7)”, partly because I haven’t used it yet, and partly from what I’ve read in that the new taskbar solves some of these issues.
Looking forward to seeing the findings published
Has any thought gone into looking at some platforms that cease to differentiate between “Launching” an app and “Running” an app? Mobile platforms come to mind. “Multitasking” is a buzzword in mobile markets right now – there might be something interesting and informative to apply here.
This difference in state has been with desktop users for a long time, and frankly it still poses problems to non-technical users. Kind of like the difference between hibernate and suspend – does there need to be a difference?
So does there need to be a difference between minimized and not running? Does it come down to launching times? That’s solvable with a much easier and simple solution that already exists – feedback and progress indicators. Users know what these are and we could innovate on these things with key improvements, rather than introduce something new. I’m all for innovation, but often the most successful ones are incremental improvements on already-proven ideas.
Maybe someone could help provide clarity by describing a use case where a user actually needs to close an app, vs just removing it from their sight? I might just be missing that piece of the puzzle. There may be corner cases such as having to log out due to software updates. However I’m not sure creating such a highly designed and engineered solution (which usually translates into complex and unintuitive) for corner cases makes sense if existing designs can help with the majority of the use cases.
The solution is buy a Mac
That may be a solution for users, but how will it help the design of Ubuntu?
When I want to get something out of sight, but within reach, I use minimize. If I want something to be gone I close.
If closing a window keeps the app running its use is the same as minimizing.
I agree with Fire(1st comment).
If all apps follow the same style. It’ll be consistant.
So close is always close. minimize is minimize to system tray and Unity launcher simultaneously.
Its very very confusing for new user when closing the app minimizes it.
Good news.
Ubuntu:
I’m amazed Ubuntu still does not have a feedback form on its website.
This is so basic, and something open source companies can’t seem to get.
Finally, the Mozilla people figured it out and now accept “Product Feedback”.
What A Concept,
WRogers
Los Angeles, CA
@wrogers: by some strange coincidence I was thinking about this very thing last night. I have been beginning to analyse the results of the contributions survey and was struck by a quote from someone who said that: “every time someone fixes a bug I report, it feels like a gift”. All work is classified into bugs and, while you can classify them as a ‘wishlist’ the ‘bug’ language often feels like something relating to the technical execution rather than product feedback. Separately, within the Ubuntu community, people’s blogs are often used to gather ‘feedback’ while these blogs are very valuable feedback they can be hard to track. It would be great if you could put this idea on brainstorm.ubuntu.com so it can be considered!
having a border that acts like a progress bar such that it goes around along the border in a circle to incdicate that it is still active – running
That first comment by Fire nails it. Click “-” to send it to the indicator menu. Not closing the app when clicking “x” (or the red button) is one of the things I really dislike when it comes to OSX.
I don’t know if y’all just have amazingly powerful computers, but I know that I run into performance problems when trying to run too many applications or too demanding of applications for my machine. Many regular users know that you should close extraneous applications when the computer runs slow.
Use Case Alpha: A music player is running without a window or taskbar button. The resources required, especially if playing from network storage or a CD-ROM, are required for another application the user wants to run right now with good responsiveness.
Use Case Beta: A data-syncing application (such as Dropbox) is causing problems by downloading 500 MB of file changes because the user turned on the computer after massive, temporary changes to the synced folder on another computer. The user doesn’t want this process interfering with streaming video right now.
Use Case Gamma: A user installs a ghetto Gmail-backup utility that “closes” to run in the background without providing an indicator. The user “closes” the application after giving it a username and password only to realize that it is slamming the system’s CPU and network connection trying to download 7GB of email and attachments.
1. Don’t use the same icon/action for two different actions (close vs. minimize to tray). You can put the minimize-to-tray icon in the place of the close icon if you really think users want your application running in the background. How about a dot for minimize-to-tray?
Also, a long-click on the minimize-to-tray icon should bring up the option to close instead, if there is no close icon available.
2. Every application should allow termination via a relatively convenient and user-friendly GUI process.
For those applications with tray icons (“indicators”), it should either be available in the first menu of the indicator if the indicator is for a single application, or in a sub-menu either for that application (e.g. Rhythmbox -> Quit) or a “Quit” sub-menu (e.g. Quit -> Rhythmbox) for highly-integrated indicator menus.
For background applications without indicators, I suggest that the main system/power/logoff menu include a sub-menu item for Close Background Applications. Clicking on one of these options may bring up an educational warning asking if the user is really, really sure, but only terminating services critical to the Ubuntu experience should be out of the common user’s reach.
I come from a mixed environment, using windows (work for design), ubuntu (work for coding/testing) and osx (laptop), and like the idea of closing windows while the application is running (think iTunes, a text editor, iM), because it solves the problem with the notification area: some icons are running apps, some are controls for background services).
Color coding the quit / close window is the simple solution to the problem, but as a previos commenter mentioned, it doesn’t solve the fundamental difference between apps that live in the window (GNOME apps for example) and the ones where the windows are views.
I think its important for a modern UI to have conceptually integrity, so one of these metaphors must be chosen as “the one”, and add a middle layer for the rest of the applications.
An example for this approach would be to make the “windows are views” metaphor “the one”, and when the user closes the window of a non-confirming app, the window is hidden from the user instead of being closed (thereby quitting the program). Quitting via regular means closes the window as usual.
I like the idea of simple color coding, because its nice engineering, but ubuntu is creating a mass-market product instead of a niche one, so users have to come first.
The more I think about this I really think Win7 nailed it. I come from a Linux/Unix background and I’m not using Windows much. In fact, I don’t like Windows at all because it’s lacking a good unix terminal and the directory layout is a mess.
But I must say the taskbar in Win7 is really good. Click the ‘X’ and you kill the application. Click ‘-’ and you minimize it. Hover above the icon in the taskbar and you se all open instances. Even if the application is minimized it’s easy to distinguish from terminated applications that are pinned to the task bar. Simple and intuitive!
Why not considering using multi-dimensional screen / desktop views…
Different level of multi tasking resulting in different level of 3d position on the screen, includiing dead as the last (furtest)layer…
Then you can manage a single spot (x or – or _) on the window which you can use to drag the application to its deserve dimension (background, stop or any other levels / states that could be there…?
This could be both a great graphic enhancement and feature…
I completely agree with Jan Hopmans, what difference is there between minimising to the panel and minimising to the system tray?
It’s about expectations, different users have different expectations, for me if I click X and it doesn’t close the app completely, I’m disappointed.
Consistency is one of the keys to usability. (I know everyone here knows that, but it’s good to remind it from time to time.)
The X button must have one and only one meaning: close the app (because in Gnome closing the window means closing the app). If we don’t want to close the app, but to send it to the tray and/or the launcher, we can’t use the X button. Period.
If Rhythmbox/Banshee/Any-music-player developers don’t want the user to close the app, they should remove the X button (and make it clear somehow that the app can only be closed via the File or equivalent menu).
The _ button minimises to the launcher/taskbar. It should not minimise to the tray some times, to the launcher some times and to both some times. That would be three different actions tied to the same button and that’s confusing. It should always minimise to the launcher and, if there’s an indicator related to the app (such as the sound indicator), have its activity also available there. If a user doesn’t want the app minimised to the launcher, there should be a provision for that in the app’s preferences (so “power users” can customise it to their liking), but the default should be the same for every app: minimise means minimise and, if there’s an indicator for the app, the user will find it there too.
I understand indicators should not be used lightly, so Ubuntu should discourage (or even prohibit) the use of the tray as a minimise area.
@Aleve – if [x] indicates close the application and nothing else, what happens if you have more than one window for the application should it then close all applications?
I think its quite clear that [x] means close a window. If the application hangs around for some reason there simply needs to be a consistent metaphor to show what it is and provide a consistent cross-application method for quitting or opening up a new window.
If general applications can be made to do the equivalent of hibernating (for faster start-up times) that’s fine, especially if its a frequently used program. But as a user I want the system to be smart enough to know that it shouldn’t get in the way of me working with the applications I want running and active. Perhaps Windows7 metaphore for applications pined to a task bar is a good one; for the user to indicate often used programs, quick access to them and showing they are still in some way active (though I have found the “active” status indication to be less clear than it could be).
I wonder if there is a need to differentiate between ‘minimizing to tray’ and ‘minimizing to the launcher’. In both instances, you remove the application window from the screen because you want it to run in the background. I assume that the tray should be used by application that you frequently have running in the background, but this is something that has the potential to be abused by many application that end up being minimized to the tray regardless of their frequency of use. I, for one, think that one method of minimization should be enough.