unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 16/05/10 18:47, Sense Hofstede wrote:
> And running applications are costly on netbooks and
> phones; both for the battery and the CPU.

If you do a "ps ax" you'll see there are many things running, all the
time. They are system services. They should be written in such a way
that they sleep as much of the time as possible, and it's certainly
straightforward to measure the extent to which they do, and fix bugs in
them.

>  Where would those
> applications be show up if not in the launcher?
>
> They could show up in the various indicators, of course. But it'd be
> hard to switch to the Gwibber window if it would not show up in
> launcher. Of course, you could only hide Gwibber when it's running in
> the background -- letting the window run in the background as well as
> the service is not such a bad idea considering the long time it takes
> to load the Gwibber GUI.
>   

To me, it's not about time-to-load. It's about the fact that you want to
know about new tweets even if you are not actively using  Gwibber. If
you are actively using it, you want  the window. If not, you just want
the notifications.


> Do you have any examples where you would think it would be suitable
> for an application to run but not show up in the launcher?
>   

Yes - things that we think of as services. They listen on the network
and monitor particular things, but we don't think of ourselves as using
them *until something happens*.

For example, the SMART hard drive monitoring tool. You don't want to
have to start it and stop it manually. But if your hard drive is
failing, you want it to appear and help you understand the problem and
take action.

>> I'm not sure if it's worth making that an explicit configuration option
>> (those cost a knuckle at least, remember ;-)). I've seen spec's from MPT
>> where that behavior is sometimes implicit (you close a music player window,
>> and it keeps running in the background if a song was playing but not
>> otherwise), but I'm a bit uncomfortable with that myself, because I'm not
>> sure what the IM analogy would be.
>>
>>     
> Implicit behaviour can work confusing, so I would only use it in case
> the implicit behaviour can and will be consistent. Now, this
> specification could be implemented per application-type -- keep a
> music player running in the background when you close it while it's
> playing a song, keep IM-clients running when you close them while
> online,  -- but maybe it should be researched whether users will
> understand the logic of such behaviour and will be able to reliably
> predict when an application will close or will continue to run in the
> background.
>   

I don't think we should worry too much about whether people know if it's
running in the background. We can drive apps to be efficient with CPU
and swap if they are in the background. Most users don't know or care
about what's running on their systems - only advanced users really dig
into it to clean out processes that are "stealing cycles".

I think we *should* be careful about these background processes, but not
reject them out of hand.

And I think the main thing is that users can easily understand the
*effect* of the background process. For example, they should easily be
able to see if they are online, and easily be able to go offline.
Similarly, if Gwibber is running in the background, they should be able
to see tweets.

> Two arguments _against_ the 'application bucket':
>  * Using the scrolling mechanism of the launcher and making sure it
> can be used easily even when the launcher is full should solve this
> problem in a more intuitive way
>  * A drawer in which you have to put applications _manually_ doesn't
> look like the most elegant solution.
>  * The argument above against hiding applications from the launcher
> also applies to the drawer since it is not clear from the outside what
> -- if any -- applications are inside the 'bucket'
>   

Yes.

Making the Launcher work well with lots of apps is a key goal for 10.10.
There were good design discussions at UDS, and I like the direction the
team is headed in.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature