← Back to team overview

unity-design team mailing list archive

Re: No "application bucket" needed

 

On 16 May 2010 18:49, Mark Shuttleworth <mark@xxxxxxxxxx> wrote:
>
>
> My comments below are written from the perspective of Unity, because (a)
> that's what I'm running, and (b) that's where our design conversations can
> have the most immediate impact.
>
>> On 16/05/10 15:30, Sense Hofstede wrote:
>>
>> An application bucket where you can dump applications you don't want to take
>> space sounds like a neat idea. The applications could stay in there, even
>> when they're running and have got the focus -- this could be indicated by
>> placing the focus triangle at the bucket icon (the bucket icon is distinct
>> from application by a different background colour or a border around its
>> icon (what icon?)).
>
> The Unity Launcher shows running applications.
>
> If the app fits one of the Category Indicators, like the Messaging Menu or
> Sound Menu, it may also show as "running" there, with the same visualization
> (currently, a little triangle).

I like the consistency of using the same visual element for indicating
whether an application is running. It is easy to lose an application
if it doesn't show up

>
> I think it's reasonable to have apps which *don't* show in the Launcher, but
> are still running. I'd like to hear from MPT, cc'd, on the subject.
>
If this is not done with the greatest care people will lose their
applications. And running applications are costly on netbooks and
phones; both for the battery and the CPU. 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.

Still, I assume that a music player would show up in the launcher as
you'd launch it via the launcher -- the SoundMenu would require some
work on the entry point/icon if it'd be used as the method to launch
the music player -- so that kind of application that could be running
in the background would show different behaviour than the example of
Gwibber I gave above.

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?

> 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.

> But I would object to a third catch-all place where windows might "sometimes
> go", which is how I interpret your "application bucket". The launcher is
> basically that bucket already, and Category Indicators should suffice for
> things which are running but which we consider more like "services" than
> applications; we don't need a third place as well.
>
The 'application bucket' is something I didn't give much thought when
replying to Akshat Jain's mail. The main reason why I liked it was
because of the prospect of clean notification areas and proper use of
indicators; a bright future.
What I had in my mind when replying was something comparable to a
drawer; a thing you can drag an application icon to -- manually done,
such a thing should never be a black hole in which applications
disappear seemingly at random -- if you want to make some room at the
launcher. Especially in case of small screens having many icons on the
launcher could be causing problems.

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'

For my own rest I think that a properly done launcher together with
the keep-running-in-the-background methods discussed above should
theoretically be enough to keep a nice and tidy notification area. The
theory could be complemented by the removal of the GNOME Notification
Area and policing of the packages in Ubuntu.

Also, what applications would be stashed in the bucket? Applications
you don't use often? Applications you want to run in the background?
Applications that don't run often will be accessible via a completely
different way if you want to launch it, but if you are using them I'd
think you'd want a clear way of accessing them, as you may have forgot
that you had put the application in the bucket a while ago, and you
don't remember or have set up the alternative paths to the application
(such as the indicators).
I don't think that applications running in the background should be
hidden away like this, minimising the windows should remove the
windows from plain sight, but the triangle in the launcher doesn't add
much visual clutter.

This mail makes clear I should think more before endorsing something.
;) Learned something! (Though nothing new. :))

Cheers,
-- 
Sense Hofstede
[ˈsɛn.sə ˈɦɔf.steː.də]



Follow ups

References