Review Request: Humble attempt to improve the ScreenSaver KCM

Sat Oct 13 00:52:30 UTC 2012

> On Oct. 8, 2012, 5:31 p.m., Martin Gräßlin wrote:
> > just an idea: what about hiding the whole X screen saver stuff behind another configure dialog. Looking at the screenshot I find the design puts emphasis on the wrong part: what we want to remove takes more than 50 % of the available screen estate.
> 
> Marco Martin wrote:
>     another idea would be just show the screen saver part only when the screensaver radio is selected (i kept it a bit that way before merging btw, seemed a bit flashy..)
> 
> Aleix Pol Gonzalez wrote:
>     I agree. On the other hand, showing new dialogs it's considered bad practice. :/
>     Maybe we can show the xscreensaver part when it's enabled?
>     
>     **Aleix turns the agateau-sign on** (see bat-signal for further reference)
> 
> Aurélien Gâteau wrote:
>     Played a bit with the .ui file and came up with this: http://simplest-image-hosting.net/png-0-plasma-windowedk16149 . Not sure it is possible, depends on how "previewable" the "simple locker" and "desktop widgets" lockers are. I can provide the .ui file if you want but I butchered it, I doubt it would compile.
> 
> Aleix Pol Gonzalez wrote:
>     It kind of makes sense to share the preview, but it seems it's not that easy to preview the plasma-overlay.
>     Anybody knows how hard would be to invoke it in hte preview thingie?
> 
> Thomas Pfeiffer wrote:
>     I really like Aurélien's attempt! Here is some detailed feedback:
>     - Putting the screensaver selection in a combo box makes sense to make it less prominent. Question here: Is it possible to update the preview while the user navigates through the combo box item list with the keyboard (without closing it)? Usually when people select a screensaver, they want to browse through the available savers before settling on one and that would become tedious if they had to open the box again for each saver. 
>     - I'd rename "Setup..." to "Configure..." as this is the word we normally use for this. Setup sounds more like "First-time configuration routine" to me, like something really complex.
>     - The spin boxes for the timings seem to narrow to hold unit indicators to me, but I suppose this would change in the final implementation

We can do a lot better than this.

Note the complete lack of visual alignment, the mix of widget placement strategies (left, right; vertical, horizontal) .. meh.

So .. let's step back and reconsider our assumptions.

Is this something a person configures *often*? No. So does it need to be hyper optimized for speed usage? No.

How much granularity do we need to offer in the UI for things like how long to wait until a password is required? Not much.

This should lead us to conclusions such as:

A spinner is not needed for "Require password after:". A drop down with a few sensible entries should be enough: Never, Immediately, After 1 minute, After 2 Minutes, After 5 minutes ... is anything more really necessary? This also lets us get rid of the checkbox and shorten the text to "Require a password:"

Note that "require a password" is an anachronism in our newfound QML world -> the Plasma Active locker does not require a password at all. In that light, perhaps this should not even be exposed in the UI at all. If the user intentionally locks the desktop -> it locks hard instantly. If it is an automatic trigger, only require a password after 30s or some sensible timeout. Voila, one more option evaporates and we no longer have a conflict with the QML themes.

the spinner after "Start automatically" should have units in it (minutes) and 0 should be "Never"; drop the checkbox.

"Locker type" => what does that even mean? It's jargon. "Lock style:" might be more descriptive and understandable?

"Simple locker" is meaningless. What is "Simple"? Compared to what? Perhaps "Password entry" or some other phrase that speaks to the user-perceptible function.

The radio buttons also fail in a significant way: we can now have lockers in QML .. which means we can (and will) have multiple options here.

So a drop down next to the label "Lock style:" listing the various installed options.

I'm not sure why "Desktop widgets" is orthogonal here either. They are also somewhat broken in the current QML locker; personally, I think how they are managed needs some rethink. Is fully customized placement of widgets the easiest / most sensible thing? Or would some auto-alignment with simplified access to configuration of the widgets in question be more sensible?

Finally, get rid of both the group boxes in the design; they are visual noise and increase the number of alignments in the dialog.

Would be fantastic if we could get rid of "Test" and "Setup" somehow as well...

- Aaron J.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106768/#review20087
-----------------------------------------------------------

On Oct. 8, 2012, 3:43 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106768/
> -----------------------------------------------------------
> 
> (Updated Oct. 8, 2012, 3:43 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Description
> -------
> 
> After complaining about this KCM last week, I wanted to give it a try to improve it a little. I think that the biggest stopper here is wanting to keep the screensaver here, because we've ended up with a 3-head monster:
> * simple locker
> * plasma-based locker
> * xscreensavers
> 
> Since it seems it's something we may want for the moment. IMHO, we should end up with the Plasma-based option alone. I just tried to re-organize it in a way I like a little better.
> 
> What I did
> - I aligned the locking labels to the left, like the Form Layout suggests. It creates a small puzzle, I'm unsure if that's a problem.
> - I added toolTips and whatsThis in the locking type option buttons, so that we can at least figure out what will happen when we lock.
> 
> 
> Diffs
> -----
> 
>   kcontrol/screensaver/screensaver.ui 6524e27 
>   kcontrol/screensaver/scrnsave.cpp 0125620 
> 
> Diff: http://git.reviewboard.kde.org/r/106768/diff/
> 
> 
> Testing
> -------
> 
> just messed with it for a while.
> 
> 
> Screenshots
> -----------
> 
> result
>   http://git.reviewboard.kde.org/r/106768/s/758/
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121013/77cc9c7f/attachment-0001.html>