zui ideas

Aaron J. Seigo aseigo at kde.org
Wed Jul 15 08:00:22 CEST 2009


On Friday 10 July 2009, Chani wrote:
> on sunday me, notmart and ruphy came up with some crazy ideas for the ZUI.
> here are the notes... better late than never ;)
>
> zoom 2 (fully zoomed out):
>
> -the containment is too small to realyl interact with, so put the toolbox
> over top.
> problem: on small devices the toolbox could be bigger than the containment.
>
> -if you have one screen there's always space for 4x4 containments, so when
> containment-saving is implemented we could have 2 columns of active ones
> and 2 columns of saved ones. 

how would you tell the difference? (saved ones would be "greyed out" and not 
actually interactive, i suppose?)

where would the visualization come from for the saved ones? (snapshot saved to 
an image when saved?)

how often would one switch between saved and un-saved?

> you could drag&drop between the areas to load
> and save them (although we could have load/save buttons too perhaps).

buttons on each activity kinds of sucks as it is. adding more buttons.. mmm... 

> we might need to record the last screen they were on, for this. when a

it already is recorded when the screen is removed.

> screen is unplugged, all its containments would be saved out, and show up
> in the saved- containment list on either the first screen or all screens.
> when it's plugged in again they'd all jump back where they were
> automagically. to move a containment from one screen to another, just drag
> it there.

disabling and saving out unplugged screen activities is a nice idea.

keeping screen activities completely separate though makes for some annoyances 
like having to decide ahead of time which screen a containment should be on, 
or else be faced with some odd dance like save the containment, go to the 
other screen and select it to be loaded.

the whole save/load thing feels very artificial at that point.

i do like the idea of a "make this activity inactive" area, perhaps by simple 
dragging it there as you note. but i don't think it can or should dominate the 
screen much if at all.

in fact, to me it would make the most sense to just have a strip of inactive 
activites, sort of like the new add widgets interface will be.

or perhaps just replace zooming with such a listing altogether .. perhaps 
zooming would just put the view into a coverflow-ish mode that lets you flick 
through the various activities. this would also neatly solve the "buttons on 
each activity" problem as one set of controls would be shown below and acting 
on the activity that is currently "front and center".

second zoom out could present a nice grid effect if needed .. this might agree 
nicely with the media center visual goals as well.

it would also make keeping different screens separate deadly easy: each one 
would get it's own row of containments.

> oh, and either painting a screenshot of the active containment, or just its
> wallpaper, instead of the checkerboard. we want this to be shiny as well as
> useful. :)

the challenge with replacing the checkerboard is the same as it was a year ago 
when we discussed it on this list. until those technical issues are resolved, 
it will remain a problem.

painting a screenshot of the active containment just mixes messages: "some of 
these things are zoomed, but others aren't". confusing.

painting the walllpaper of the active containment, or any wallpaper for that 
matter, means having to be able to clearly distinguish between that background 
and the containments themselves. that implies a border/shadow painted around 
containments. that's the technical issue that needs addressing, regardless of 
what zooming techniques are otherwise used.

-- 
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 Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090715/991cf1da/attachment-0001.sig 


More information about the Plasma-devel mailing list