Scenarios/Storytelling

Michael Rudolph michael.rudolph at gmail.com
Mon Jun 9 15:45:10 CEST 2008


On Sunday 08 June 2008 23:22:16 Aaron J. Seigo wrote:
> On Sunday 08 June 2008, Michael Rudolph wrote:
> > Without further ado, I'll just paste the little story here. Fell
> > free to ask any questions.
>
> this is essentially the idea behind zooming+activities, or at least
> where we are trying to go with them.

Hello Aaron,

I hope so. Afterall I'm not trying to write a fanboy wishlist here, but 
write down the vision for plasma for those who did not read your blog 
in recent years or have trouble to understand the reasoning behind all 
the new concepts in plasma. One could say, I'm writing about the ways 
of the plasma :-)

> now, the trick is to map between your story and what we currently
> have, leaving a map of what is left to do.
>
> one thing in your story that i haven't gotten around to thinking
> about yet are things like "most recently used activities"; i like
> where you are going with that though. perhaps you could flesh out a
> detailed technical description of how that system would work in your
> mind.
>
> the zooming as you note it is how i originally wanted it (where
> activities become iconified, have an attached description and icon,
> etc0, but we ran into various technical obstacles we didn't have the
> time to work past.
>
> one thing in your mockups that isn't on the current plan is multiple
> zoom levels: in one mockup you show an activity zoomed in enough to
> see the plasmoids in it, but all the rest zoomed out fully. perhaps
> that could be done on mouse over in the largest zoom factor, but may
> also prove to be unecessary and even disorienting to the user: we'd
> have to either move other items out of the way to give the zoomed
> activity room, or cover other activities (really not an option i
> don't think). there are some nice algorithms out there for moving
> nodes "out of the way" that are pretty simple, but i'm not sure it's
> worth it given a decent pan-and-zoom system.

In hindsight the mockups probably hindered understanding more than they 
helped it.

The idea is to have three zoom levels. The first level is the mindmap 
view, the second one is the project management view and the third is 
the actual working area.

In the mindmap view you have all your tasks and activities in front of 
you. Related nodes, like university and the seminars, are connected 
through rubber bands. Thus, when you move one node around, the related 
nodes will be dragged along. On the other hand, non related nodes, like 
hobbies, can be pushed away, when you move, for example, university 
near it. The purpose of this is to allow a form of fisheye 
visualization for the mindmap. Nodes that you drag into the middle of 
the screen are displayed larger than those on the periphery. Depending 
on the number of nodes you have in your mindmap, not all nodes might be 
displayable in a legible size, especially if they're deep down in the 
hierarchy. If this is the case, you just drag an ancestor node into the 
center and thereby make all related nodes more visible (larger).

This fisheye visualization, the ability to make things larger by moving 
them to the middle, would also be necessary when we use the mindmap not 
just to display relations between tasks, like "a seminar is related to 
university", but also to convey other aspects of a users digital life. 
When you have a node "photography" in the hobbies section, but haven't 
used it in a while, the withering of this aspect of your digital life 
could be visualized by shrinking this node down to a point (bubble, 
dot, whatever), so small actually that it has no text on it anymore. 
But by dragging it into the middle, by making it the temporary center 
of your digital life, you have revived it (until it shrinks again :-). 
This way completed tasks will also automatically be "archived" and 
moved out of the way.

Besides the strong focus on visualizing relations that a mindmap 
affords, the first zoom level also allows other visualizations. You can 
display activities/tasks based on recency or priority. The idea is to 
basically have a set of saved nepomuk searches available. When you 
perform a search the most relevant activities will be displayed 
prominently in the center of the screen. Non relevant activities will 
be momentarily marginalized.

The second zoom level is a project management view of the activity. This 
zoom level uses the same canvas as the previous one, so you still see 
your other activities at the margin of the screen, but in the center 
you have your expanded activity. At this level it not only shows a 
title (and perhaps a little description) like in the first zoom level, 
but allows you to set various kinds of metadata for the project/ 
activity/ task. Since it is a containment, you can add plasmoids to it 
as you please. And thereby finetune the level of control you can exert 
for managing the project. Really just "name and description" or a 
calendar, due dates, priorities, collaborators, a Gantt chart, whatever 
you need. It should be possible to download complete sets of "project 
management plasmoids" for this second zoom level.

Zooming in once more will get you to a working area, probably most 
closely resembling today's desktops. There you have the tools to 
complete the task at hand. The tools at your disposal will be 
determined by the type of project, that you selected at the previous 
level. This is like a combination of desktop wide sessions, kate 
sessions, konqueror view profiles and templates in various 
applications. So if you have a "plasma development" node, at the third 
zoom level you would get a kate window, with relevant files loaded, a 
mail plasmoid, displaying panel-devel@ email messages, an irc client 
logged into #plasma, a plasmoid plugged into bugs.kde.org. I don't want 
to go into advertising this idea too much, but it occasionally strikes 
me, how mind-blowingly ingenious it is (can one say that without 
sounding too swell-headed? :-). For example session management in kate 
would be completely intrinsic to such a system, because just by zooming 
in, the user gives so much context, that kate can save the "plasma 
development" session without any further user intervention. A nice case 
of interaction being the interface.

There are still some (read: a lot) rough edges here. But I guess this 
suffices to raise another round of questions, so I'll leave it at that.

michael


More information about the Panel-devel mailing list