It is the height of audacity to come out of the woodwork and suggest design ideas for a system that I do not create myself. Nevertheless, you might actually like some of these.
I promise it will be entertaining. Broken into two sections, A and B. Also long. Have a great day! A. Effective Communication of Activities' Design ---- First, for KDE to effectively continue its embrace of Plasma, a good campaign must be focused on explaining the benefits of the Activities system to the casual user. It doesn't help that until now it has seemed mostly at cross-purposes with the old idea of virtual desktops. (I didn't say it was. I said it _seemed_. If it didn't, there wouldn't be so much ill-will about it.) It doesn't help that the transitioning-between-Activities bears little distinction from transitioning between workspaces/virtual desktops. It's sometimes hard for the user to figure out exactly what the big deal is. Personally, I rationalize it myself this way: --Virtual desktops are like having a really huge desk in your office. There's plenty of room for stuff, but you have to reach around to get to any of it. --Plasma Activities are like having _different_ desks in your office. For example, one for essay writing, one for your reading, and one for communication (memos, letters, in and out boxes). The idea of "having more than one desk VS having a huge desk" is immediately apparent to any office and home user; in fact, if you ever create an in-KDE tutorial to explain how Activities work, and maybe guide the user through creating one, I highly suggest you use that metaphor pervasively. 1. In fact, perhaps you should re-do the nomenclature and describe them as "Desks" (formerly activities) and "Desk size" (formerly virtual desktop dimensions). I could have a "Internet" desk that is 2x2 screens wide, and a "Programming" desk that is 4x4 screens wide for example. This resolves ambiguity between "just more space" and "space dedicated to a special purpose". 2. There should be a freaking-easy-as-dirt way to switch between Activities (though I do like "Desks"). The Zooming-User-Interface doesn't cut it, especially since it's at cross-purposes with the traditional zoom-in/out on a surface metaphor of virtual desktops. There is an inherent spatial conflict, don't ignore it. The typical office user doesn't care what your spatial metaphor is (or even what they _are_), but he _will_ notice if it's inconsistent. A simple menu widget that when clicked, presents a list of Activites. With two clicks, you can select any Activity. (You'll assume the user won't have 10+ Activities. That's too enthusiastic). Perhaps this menu can pop up when the Cashew/Acorn-thing is clicked, as opposed to strange terms like "Zoom Out", which does nothing to describe the contextual novelty of the Activity idea. Activities describe different abstract spaces, not a web page. This same Activity Menu could be integrated into Kicker (a tab for a list of all current activities -- you could switch with just one click!) or into a panel-widget that triggers the menu. B. Working With Kwin to Resolve Spatial Conflicts ---- The main interaction layer with Activites, the Zooming User Interface, in its current form isn't gonna cut it. Even further development isn't gonna cut it -- maybe you guys have some sort of brilliant vision that pops up in ephemeral IRC logs, but I haven't seen it on this list or Aaron Seigo's blog. (No offense of course. You might not post it here, it might be at Techbase, or it might not exist). Suggestions. 1. Team up with Kwin for Activites-transitions. Kwin is the only framework for screen-level transitions and animations that is well developed enough to be used immediately in the near future, and there's no need to reimplement screen transitions when Kwin has them already there! 2. Re-adopt the ZUI (whose name, being utterly meaningless to Activities, should disappear soon except perhaps as API and developer nomenclature) to use Kwin when present for switching between Activities. Be able to apply any desktop-switch-effect, perhaps, to Plasma's ZUI transitions instead. (Ex., switch between Activities with the Cube and Wall). This makes for more spatial conflicts, I know. Wait for it. 3. The default method of Activity transition interaction should be --Switching immediately to a particular Activity (see Cashew-Menu idea in A-2 above) And nothing else. No "zoomed-out" overview of all possible Activity desks. Interferes with zooming-out of virtual desktops. (Feel free to debate on this). 4. Kwin needs to lay down the law and demand a single consistent metaphor for Activities, and a single consistent metaphor for virtual desktop switching. Virtual desktop switching for a long time has long called home the metaphor of "different spaces on the 2D plane". Since you remember my parallel earlier (Virtual desktops = A big flat desk with tons of space) I highly suggest that the Desktop Grid becomes the permanent and unchangeable effect metaphor for Virtual Desktop/Space switching. Why? --Offers more flexibility. The Cube, though beautiful, is an abstraction of a 1-dimensional list of spaces that you can cycle through. The Desktop Grid allows 2 dimensions of spaces. --For sake of usability (debate me), there should be one and only one virtual desktop metaphor. The Compiz schizophrenia of "cube, sphere, wall, plane, dodecahedron!" is not something Kwin should ever have aimed to copy. For consistency across KDE installations. No one should try to switch desktops on two different KDE computers, and find themselves assaulted with a "grid" on one and a "3D pentagon" on the other. 5. In my personal opinion, once the ZUI-transition-to-Kwin-effect development is complete (I highly suggest you get on that, even if you disagree with everything else I say) the Cube should be selected as the default metaphor for Activity switching. Why? The 3D concept of "different faces on the same cube" is the nearest you get to the idea that your computer's KDE desktop can be used for different purposes. While DesktopGrid conveys the idea of a "big space you move around on", the different faces of a Cube convey the idea of "separate spaces entirely". C. Conclusion ---- Whether you agree with my choices for the Space metaphor vs. the Desk/Activity metaphor, you must agree that they must be consistent, and not conflict. The days of the user arbitrarily deciding his desktop metaphors must come to an end -- especially since only the foolish care whether their desktop is a sphere or a cube (Seriously.), and was indicative of the kind of "freedom-for-freedom's sake" that unfortunately embodies every disadvantage with Free Software Development. Do Compiz one better here and actually lay down a design for your metaphors. Users don't want components they can mix and match. Developers do. Users just want a well-designed system that they can _use_ however they want. And since Activities is a relatively new concept that you seem determined to push, you _must_ take care to separate the idea, spatially, from virtual desktops. Since it _is_ a different idea (see the big desk vs. many desks summary in part A). Inconsistency in how the environment treats transitions between desktop spaces and desktop Activities will ultimately determine how well users can adjust to them. They must occupy an entirely different spatial context than mere Virtual Desktop/Spaces. For this reason I suggest the 3D Cube for them, while for the sake of 1) consistency and 2) greater flexibility, I suggest Desktop Grid for Spaces alone. This is very important usability-wise: my design ideas may need refinement, but the idea of internal inconsistency does not. Kwin and Plasma must cooperate to set in stone these metaphors. Mixing and matching them, I repeat, will only hurt you in the long run. Get Plasma to work with Kwin for transitions (since Kwin has the framework to do it), and then decide what effects/metaphors to use for which desktop abstractions. And it works for audiences either way: traditional Linux desktop users can ignore your Activities and use Desktop Spaces just the way they like. Whereas perhaps a user who doesn't care for a huge virtual screen area, but really likes the idea of desktops for different purposes, can use the Activity/Desk concept. And since they'd both use different spatial metaphors, they would never conflict, and you would always tell when you were merely moving through the same desktop, as opposed to switching to a different task-based desktop entirely. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
