Plasma/Kwin cooperation to achieve efficacy of Activites spatial metaphors

Jud Craft craftjml at gmail.com
Tue Feb 10 16:27:37 CET 2009


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.


More information about the Plasma-devel mailing list