Review Request: Humble attempt to improve the ScreenSaver KCM

Sun Oct 14 17:33:38 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
> 
> Aaron J. Seigo wrote:
>     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...
>
> 
> Bjoern Balazs wrote:
>     I think we running in the typical problem of different assumptions and underdefined requirements. I do like the approach of Aurélien and I can the criticism of Aaron. I could add some more: Why not use a wizard, if the task is done is infrequent? How do the screensaver settings fit into activities? But for all of these valid solutions (or questions) we have a totally different user (and probably scopes of this patch) in mind. I really do not how we can solve these kind of discussions, without first agreeing on our target users, their tasks etc.
>     
>     My personal feeling is to go with the Thomas commented ideas from Aurélien, as they seem to be close to what we have and they are somewhat aligned with the rest of the desktop KCM in terms of detail. After agreeing (however we can do that) on personas, sezenarios, goal etc. we should revise this and other KCM moduls. My feeling is that the ideas of Aaron will be picked up then...
>     
>     just my 2 cent :)

Here is another mockup, taking into account feedback from Thomas, Aaron and Marco. http://agateau.com/tmp/locker-kcm/locker-kcm2.png

- Aurélien

-----------------------------------------------------------
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/20121014/b75dd5b6/attachment-0001.html>