The future of virtual desktops

[Gábor Lehel]

2011/2/25 Gábor Lehel <illissius at gmail.com>:
> On Fri, Feb 25, 2011 at 2:44 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
>> On Thursday, February 24, 2011, Hans Chen wrote:
>>> What I want to know is the following: Are there any plans or outlines
>>> regarding how to proceed with virtual desktop (and activities)? Are they
>>
>> they are orthogonal concepts and i don't think we should at this time get too
>> worked up about them.
>>
>> for those who don't use virtual desktops now -> not an issue
>> for those who don't use activities -> not an issue
>> for those who use both happily -> not an issue
>>
>> people who know virtual desktops but who are learning and using activities are
>> the only ones really affected, and i think it's likely to be a "growing pains"
>> issue as they adjust. it may just as well work itself out naturally.
>
> Doing this kind of case-by-case analysis is a great idea: many times
> something which sounds sensible in the abstract ends up looking quite
> different when you look at the individual cases it applies to. But I'm
> not sure if these are necessarily the most appropriate lines along
> which we should be separating things into cases.
>
> First of all, though, a question: what is the Plasma project's goal
> with activities? I'm assuming the goal is to have people notice them,
> be intrigued by them, start using them, benefit from them, and tell
> other people about them, who then start the process anew; but maybe
> that's mistaken and it's something different -- say, something more
> modest like, "well it's there if people want it, but if they don't we
> don't really care", maybe.
>
> Going ahead with my assumptions, my concern is that the way things
> usually work isn't "I'm using X / want to start using X" -> "let's
> figure out what X is, understand it, and learn how to use it"; rather,
> it's "X sounds really interesting, I understand how it might help
> improve my experience/productivity" -> "let's start using it". In
> other words, the part covered by "notice them, be intrigued by them,
> start using them" above. If we view 'understanding' as a necessary
> precondition for 'want to start using', rather than the other way
> around, then the cases break down like this:
>
> a) those people who are familiar with / understand / use neither
> virtual desktops nor activies
> b) those people who understand virtual desktops, but not activities
> c) those people who understand activities, but not virtual desktops
> d) those people who understand both of them
>
> For (d), obviously there is no issue. For (c) (if there are people
> like this at all), if the goal is to have people use activities, there
> is also no issue. For (b) and especially (a), I think there would be
> issues. Simply put, trying to understand two superficially similar but
> fundamentally different things at the same time -- or even something
> superficially similar to but fundamentally different from something
> you already know -- can be very confusing. A lot of assumptions get
> triggered by the superficial similarity, a lot of them very wrong, and
> it takes a lot of time and pain before you realize which ones are
> wrong, how they are wrong, and what you should be assuming instead.
>
> For a familiar example, let's look at the time when both activities
> (groups of plasmoids) and virtual desktops (groups of windows) were
> presented spatially, as a grid. Both of them tried to occupy the same
> mental area at the same time: switching between groups of things using
> a spatial grid. No amount of explaining succeeded in making people
> understand that really, the two are different. (And even having to
> explain things is bad; it's much better if they are intuitive and/or
> obvious.) The resulting confusion is a big part of why the evil
> separate-activity-per-virtual-desktop option was born. Now, activities
> are no longer spatial, which was a good decision; but instead
> activities are invading the conceptual territory of virtual desktops
> from a different direction: managing groups of windows.
>
> My fear is that when people are confronted with two advanced features
> which are both intended for grouping windows, the result will either
> be that they get royally confused (as with spatial activities), or
> that they go "eh, this is a bit difficult, I don't feel like dealing
> with it right now", and then they never get around trying it, and
> instead are just left with a vague negative impression.
>
> I would assume that only a few very advanced users would really want
> to use both at the same time; therefore my proposed solution would be
> to move virtual desktops into the settings alongside other power-user
> window management features like tabbing and tiling (though I'm open to
> being persuaded of others). The case for activities could be made much
> more effectively if you didn't have to detour into "how is this
> different from virtual desktops, why do we have both" every half
> sentence, and could instead say "activities are better than virtual
> desktops: here is why". And then you could just say at the end "we
> acknowledge that while activities are better for the majority of use
> cases, there are still some where virtual desktops are useful; if you
> want them, you can still turn them on in the settings". The whole
> message is much simpler and clearer if you don't have to keep muddying
> the two concepts together.
>
> Going meta for a bit, I think it's clear that both of us are being
> informed by our own experiences (or at least the whole thing is hugely
> coincidental): you understand and appreciate both activities and
> virtual desktops (not surprisingly, given that you had a hand in
> implementing them), and you assume other people would be able to make
> the distinction as well; whereas I find the distinction between the
> two confusing (and I'm a hacker also!), and don't have the patience to
> read mile-long blog posts explaining it, and assume that other people
> would also have trouble with it. Do we have an actual, honest-to-God
> usability expert around here somewhere? I think it would be a decent
> idea to get an outside opinion.

Wow, this was long; sorry. To make up for it I'll write even more.

I think replacing virtual desktops with the idea that you can simply
have the area-windows-are-in extend as a strip in either (horizontal*)
direction would be a great idea. I don't think the background (or
plasmoids, or panel) should even enter into it; windows float above
them, and you'd be able to 'scroll' them to the right/left. Maybe
there'd be a scrollbar/viewport/panner-like thing above the panel (or
at the top of the screen, or wherever) you could drag left/right to
move the strip of windows correspondingly (and maybe using the
scrollwheel over the desktop background could do the same, though it'd
be awkward when a window gets scrolled underneath the cursor).

Anyway, I think this would resolve the conflict. You'd no longer have
one feature for managing groups of windows, and another for managing
groups of groups of windows (or two features managing windows into
distinct groupings, which is even worse); you'd simply have groups of
windows, and the amount of space the windows have to fit in would be
greater so you could fit more of them.

(Semi-relatedly, I wouldn't feel any remorse at all about ripping out
activities-per-virtual-desktop; all along, all that people wanted was
to be able to switch between their plasmoids and their windows
together as a set; now that activities can manage windows, they have
that, and they have it better.)

* Or, I guess, whichever direction is the one the panels are in. If
you have both horizontal and vertical panels, I guess that could be
awkward. Either way I think the window-area should only extend along
one axis; having to navigate around in two is too much of a pain.

>
>
>
>>
>> we don't know what their resulting work flows will be yet. that would be a
>> matter for a field study or we can just wait and see. if/when we do know what
>> the resulting work flow typically is for a virtual desktop and activities
>> user, we can then take this topic up if we wish to.
>>
>> but imho right now it's "not an issue" :)
>>
>> --
>> Aaron J. Seigo
>> humru othro a kohnu se
>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>>
>> KDE core developer sponsored by Qt Development Frameworks
>>
>> _______________________________________________
>> Plasma-devel mailing list
>> Plasma-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>>
>
>
>
> --
> Work is punishment for failing to procrastinate effectively.
>



-- 
Work is punishment for failing to procrastinate effectively.