The 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.
[…] ivanka.majic Posted by Bez kategorii Subscribe to RSS feed […]
I see here a focus on the behaviour after clicking the close button. Very well.
But is it not good to create the right expectations before clicking the button? My suggestion is to use a different button icon when it is close the window, but not terminating the program.
This has been a long standing bug with Windows and Gnome: closing the window should quit SDI applications. Always. This is consistent with user expectations since most people think of the SDI window being the same as the application itself. Changing the behavior of ‘close’ to sometimes mean ‘hide’ has always been the incorrect thing to do. And your user testing backs this up. To dismiss a window and keep it in the notification area there should be another button on the window border or it should be done using the minimize button. Some apps will simply ‘minimize to the notification area’. The animation that shows the window sliding into the dock/menubar or whatever will simply show it sliding into the notification area. It’s consistent and fits with the user’s mental model.
I think the difference between minimizing and tray hiding is irrelevant with an icon based task switcher, and that, with the switch from a panel window list to unity, panel hiding should be eliminated.
hiding running apps in the tray***
..no edit post button 🙁
Think about it. When you have a text based window list, hiding an application saves what, 180 pixel columns of window list space? With a dock, that’s down to 60 pixels AND chances are with icon pinning, the icon will be there *anyways* so the gain is 0, and the confusion is both horrible and completely unneeded. If the gnome-panel experience is still going to be important, Canonical should make changes to the window list applet that allow it to hide minimized windows without doing anything bizarre. The indicator area is not the place to manage that kind of thing, and it never has been.
I agree with Klap-in. The icon itself should be different if the functionality is different. Maybe an “o” instead of an “x” and it should have a different tooltip like “Tray-ify” or something..
I find myself agreeing with Ewan here: clicking the X button should always close the application. There seems to be a lot of friction to this idea on the linked brainstorming page, but this is probably just resistance to changing old habits even in the face of a proper solution.
Just how often do users really minimize their applications to the taskbar/dock if the application can be hidden in an application indicator? I know I always send Pidgin, Transmission or Rhythmbox to the notification area (by “closing” them) instead of just minimizing them. I think the proper thing to do is make applications change their minimize icons slightly (to give a clue to the user), and animate the minimization towards the application indicator. I guess proper minimization can then be offered through a right click menu on the window title.
Basically, applications that hide in the notification area when you close the window are like webpages which break the back button. It doesn’t stop us from using the application, but we will curse you under our breath.
[…] Majic, Creative Strategy Lead en Canonical, coincide con ese concepto y ha anotado un WIP (work in progress) en esta idea ya que será un paso adelante […]
[…] one is pretty self-explanatory, and work is already in progress to resolve it, according to Canonical creative strategy lead Ivanka […]
[…] one is pretty self-explanatory, and work is already in progress to resolve it, according to Canonical creative strategy lead Ivanka […]
[…] Close the AppThis one is pretty self-explanatory, and work is already in progress to resolve it, according toCanonical creative strategy lead Ivanka Majic. 8. Ubuntu Software Center Removal of Configuration […]