unity-design team mailing list archive

[Dylan McCall <dylanmccall@xxxxxxxxx>]

On Tue, May 18, 2010 at 10:38 AM, David Hamm <davidthamm@xxxxxxxxx> wrote:
> Close=quit, some apps could just minimize to tray by default (music
> player). The music tray would already provide more function then the
> taskbar, no reason to minimize it there.

That doesn't make sense to me. How, then, do we differentiate between
these two? How do you quit Rhythmbox if Close=Quit, and why does
Media›Close in its menu not do the same thing as Media›Quit? ;)

More importantly, though, why should users know this? Close means
close; it precisely communicates “I am really not using this any
more.” For most cases (eg: gedit) an application's services are
entirely contained within a window, so it makes sense for the
application to exit when that window is closed. For others, like
Rhythmbox or Empathy, the application provides other services (music
playing in the background, podcasts being downloaded, more than one
window being open), so closing a single window does not exit the
application.

My belief here is we need to establish a scenario where users never
think about Quitting applications; just doing things with them, then
putting those things away. Applications should quit themselves when
they aren't useful, and in doing so nothing in the surrounding UI
should change, so those applications can be reactivated seamlessly
when the user wants them again. I think we're getting there, too. The
messaging indicator is a step in that direction because a messaging
app is there whether it's running or not. Unity's launcher looks kind
of cool, and Gnome Shell may be doing something quite smart.


I think smartphone OSs are seriously awesome stuff, making do without
minimizing, or maximizing, or resizing, or any of that bother. When
they multitask, it is especially fascinating design. Android has an
interesting design to this end:
http://android-developers.blogspot.com/2010/04/multitasking-android-way.html



Dylan