On Fri, Feb 25, 2011 at 2:44 AM, Aaron J. Seigo <ase...@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. > > 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@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > -- Work is punishment for failing to procrastinate effectively. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel