Hey, On Thursday, November 22, 2012 13:31:40 Aaron J. Seigo wrote: > On Thursday, November 22, 2012 13:05:05 Sebastian Kügler wrote: > > The idea is to make locked mode the default > > so to do anything to the system, one first has to discover that it can be > unlocked, then unlock, then to return to the optimized-for default, re-lock > it. > > it creates a system that only works as intended when done so in strictly > divided modes. > > can we imagine any way to make interacting with the system more baroque, > less discoverable and more labor intensive?
This increased modality is a problem I have with my PoC approach as well, but haven't solved yet. There are I think two aspects to it, which we may want to make as seamless as possible (i.e. reducing the labor to switch between modes, increasing the discoverability how you do changes to the widget, resizing, moving, configure, etc.). Right now, we're defaulting to unlocked, and show applet handles on hover events, on the left or right close to where the mousepointer entered, when the desktop is locked, one always has to go through the toolbox or context menu to unlock first. Configuring the containment is possible in both cases (locked and unlocked). Configuring an applet is possible through the context menu also when locked, but only via unlock -> applethandle when locked. Actions such as open in $Application are only available via the applet handle, so only unlocked (although it has nothing to do with manipulating the applet itself, it's directly content related). So for many workflows, we rely quite heavily on the desktop being unlocked. Also, when something is dropped onto the containment, it would make sense to give feedback (instead of just making it impossible to drag). We do something similar in the containment's config dialog, which mentions "you first need to unlock, [do that]" at the top. I think it makes sense to think in two different workflows for the user: - content aware: the user types something in the notes plasmoid, reads a feed, basically uses the widgets that are there - workspace management: the user adds a widget to the containment, or removes it, rearranges the widgets One should not get into the way of the other, it should be intuitive, easy and precise to switch between these workflows. Viewing it from this angle, would probably also mean to streamline which actions are offered in which mode. One idea I had bouncing around was to unlock the widgets also on certain actions. For example when the widget is dragged beyond a certain threshold. My biggest question mark for this idea is when to trigger the unlock, or rather: How to detect if the user wants to manage the widgtets. If widgets can dragged, we need to communicate "this is how you drag" (currently our visual indicator for that is the applet handle). On touchscreens, tap-hold-drag is quite natural. An equivalent on the desktop is drag and drop, so this behaviour would be consistent with what users are used, a common metaphore. Unlocking is I think easier, idea: While the desktop is unlocked, we show a small information frame at the top, with a "Lock widgets" button, and maybe a timer which locks the widgets after a certain amount of inactivity (i.e. the user is using some other program or hasn't moved / resized in the last N seconds. This is a bit of a braindump of the part "what problem are we solving here?", not a solution at this point. :) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
