unity-design team mailing list archive

[kevin granade <kevin.granade@xxxxxxxxx>]

On Mon, May 17, 2010 at 9:25 PM, James Putt <putt.james@xxxxxxxxx> wrote:
> Would it help to make a deliberate distinction between the service and
> management facilities an app provides? The common examples seem to be
> mail, music, IM, gwibber, and downloads may make a good fit also. So
> in each case I want my service (emails receiving, music playing, being
> available online) but I don't necessarily want the finer management
> provided by the respective app.
>
> The system/category indicators already help in this to an extent. The
> interaction could still be improved, for instance, when I want to
> appear online. At the moment I can't do this strictly from the
> me-menu, I need to first open Empathy (which, minus the functionality
> of the me-menu, is only a contact list). Similarly for music, I need
> to first open Rhythmbox before I can control playing music without
> opening Rhythmbox(!). If services were standalone from their apps, and
> could be controlled via respective indicators, I would only need my
> app window open for deeper access/management (organising email, making
> new playlists, etc).
>
> The problem of distinguishing between minimise and minimise to tray is
> still there, but in the form of how is the user informed which apps
> complement services (and wont stop the service by being closed). Not
> all services (eg email, gwibber) are currently controllable from their
> indicators (besides starting the service by opening it's app), but
> then, perhaps it doesn't make sense to be able to turn off eg
> receiving email.

I don't know if this is helpful, but I think it will at least be interesting ;)

I was reading recently about Android's process model, here are the
salient aspects:
1. User never "closes" an application, a better description would be "dismiss"
2. When an application is "dismissed", the action the user sees is
that the GUI is no longer displayed
3. In addition to not displaying the GUI, a snapshot of the
application is taken, and a timestamp of when it was "dismissed" (also
other things I'm sure, but probably not pertinent)
4. By default, the application keeps running
5. If memory pressure is encountered (could be adapted to other
resource shortages?), the "oldest" "dismissed" application is
immediately killed.
6. When the user activates the application again, either it is still
running, or it's state is restored (fast operation!) from the snapshot
taken when it was dismissed, so it is still in the state it was in
when it was dismissed.

I'm not saying this should be adopted as-is, for Android it required
re-architecting the whole of userspace from what I understand, but I
think some of the concepts are interesting.

Fundamentally, does a user ever really want to close an application?
Well, I can think of a few use cases for that, but in the common
cases, does the user really want the application to stop running, or
are they forced to make that decision due to resource constraints?
After a quick count of my own system, I have 39 user-facing
applications running right now, 42 windows (48 total if you count tabs
separately) ('ps aux | wc" says I have 240).  This is my big, beefy
desktop system though, I can do that with no noticeable performance
loss.  On my older laptop I rarely have more than about 5 user-facing
applications running, and I generally kill off any application I am
not using at the moment, because I quickly run out of RAM and
performance takes a nosedive.  I'd far rather have an illusion that I
can run as many applications as I want, and let the system deal with
resource issues without bothering me about it.

To summarize, "close" isn't something the user should typically have
to worry about.  In an ideal world, the user would let the system know
what they want to interact with, and the system would present that to
them, handling all the opening, closing, suspending, resuming,
resource management tasks, etc... in the background.

This seems to me to be what Apple is getting at with their dock, it
doesn't matter if the application is running or not, clicking on an
application's icon means, "I want to interact with this application
now".

Thank you for your time,
Kevin Granade

>
> James
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>