unity-design team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

frederik.nnaji@xxxxxxxxx wrote on 29/09/10 08:43:
>...
> On Tue, Sep 28, 2010 at 15:34, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx
>...
>> frederik.nnaji@xxxxxxxxx <mailto:frederik.nnaji@xxxxxxxxx> wrote on
>...
>>> With a persistent indicator for activity or progress, we can also
>>> see, when the computer is idle: very important state to be aware of!
>...
>> It really isn't.
>
> Oh, sure it isn't *really* idle: only regarding the services we know to
> reside in this proposed menu, e.g. downloads or file transfer
> operations

No, it really isn't very important state to be aware of. :-)

I think there are two categories of use case here.

1.  I want to leave home/work/wherever, and log out / shut down / take
    my USB key with me. Has the download/copy/whatever finished yet?
    That doesn't require "persistent awareness"; it requires the OS to
    tell me, when I try to log out / shut down / disconnect the USB key,
    "whoa, you shouldn't do that yet, I'm still working".

2.  I want to know whether it makes sense for me to check e-mail /
    grab a drink / go to the toilet / go for lunch, while waiting for
    this task to finish. That doesn't require "persistent awareness"
    either; it requires me seeing, momentarily, an estimate of time
    remaining. And persistent awareness would actually be
    counterproductive if I was trying to concentrate on something else
    on the screen (like that e-mail) while waiting.

Are there any cases that don't fit into those two categories?

>> Ubuntu is a multitasking OS, and applications can inhibit logout if
>> necessary.
>
> ..logout is not a problem here, my point is rather that options arise
> with such an indicator available:
>
> We discussed prioritizing downloads for example..

That would be easier in a window than a menu -- first because a window
could be wide enough to show much more information about each task,
second because dragging to prioritize tasks in a window wouldn't
conflict with the usual drag-to-select behavior of menu items, and third
because it would be quicker to recover from mistakenly dragging off the
edge of the container (a menu would close, a window wouldn't).

> or think of seeing your overall downloading progress at a glance..
> or knowing how much time is approximately left, before evolution will
> finish syncing your emails from the cloud, or how many files Ubuntu One
> has completed syncing from what total number of objects..

Both of these would also be easier in a window than a menu, because if
you really wanted to, you could leave the window open beside your work.
(For example, when I made screencasts of my software tests earlier this
month, the video encoding would take a few minutes, so I had the
encoding progress window open alongside the browser window where I was
doing bug triage while waiting.)

> Personally, i would love to see information from System Monitor here,
> i.e. whether an app is frozen or unresponsive (of course again
> transparently), perhaps using the warning colors we discussed so
> vividly before.
> The frozen/unresponsive information would then again be useful in other
> places, e.g. window list, Unity's dock, ALT+TAB dialog etc..

That is interesting, if rather indirect (why not show it on the window
itself, like Compiz does?), but I don't see what it has to do with
progress of downloads and copies.

> my gut feeling tells me that this thinking is going in the right
> direction, especially with all the GSoC work done in the direction, as
> Dylan pointed out..
> Do you think that approach in general is not yet ready for
> consideration here, or rather implementing it as persistent indicator
> would be too far fetched an idea for the moment?
>...

I don't think it is far-fetched, just mistaken. There seem to be two
kinds of design mistake here: duct-tape-ism, and misaggregation.

When you have duct tape, a lot of things start looking like ducts.

An old example of this in interface design is tooltips. When GTK
application developers learn how to add tooltips, a lot of things start
looking like they should be explained by tooltips. This is why you
sometimes see a checkbox or an entire listbox with a tooltip, for
instance, when it should instead have a caption or be a different
control altogether.

Another example is notification bubbles: When you have a "notification
system", a lot of things start looking like "notifications". We
inherited that vague term from the API, so it's been hard work to
clarify that a notification bubble often is *not* the most appropriate
method of notifying people of something.

So when you have something as vaguely named as "indicators", a lot of
things start looking like they need to be "indicated". That vague naming
was our fault. They are menus. So whenever you think you want something
as an "indicator", take a deep breath and ask two questions:

1.  Is it something people will want to access frequently and/or
    hurriedly? (For example, many people who use multiple keyboard
    layouts change between them frequently. Conversely, changing the
    volume is usually infrequent, but often hurried when it does
    happen.)

2.  Where there is related information, does it make sense to present
    that information in a *menu*? If it needs to be persistently
    visible, perhaps you should use a window instead.

On the other hand, Salomon Sickert's GSoC TaskView work, and Mathusalem
before it, is mere misaggregation. "This is all progress of tasks, let's
present it all together!" Never mind that some of the tasks don't have
anything to do with each other, so they wouldn't actually make sense
presented together. It's hard to come up with a good analogy, but it's a
*bit* like saying "Here's the current text selection from each window,
let's present them all together!" It's interesting technically, but not
usefully.

Now, TaskView *is* very cool as a redesign of Nautilus's progress window
(I say modestly, having done the original design;-). It might also be
useful to have, for example, a unified cross-protocol download manager.
Or a smart API that all native Ubuntu applications would use for file
moves and copies, which handles pre-flighting and disk space and name
conflicts and allows for user reprioritization of tasks. It's just that
a menu is not the right presentation for those things.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkykUZsACgkQ6PUxNfU6ecpatQCeJkiYEjKz4rHKgD7EMR/87+6Z
9+wAoMewM7GlaU4MfuJ6dD01dd21o9kk
=oq37
-----END PGP SIGNATURE-----