Re: [Usability] Screensaver and idle time

[William Jon McCann <mccann jhu edu>]

Hi Joachim,

Joachim Noreiko wrote:
[snip]
> This caused us a number of headaches in the UI review,
> and the more I think about it, the more illogical it
> seems, for a number of reasons.

My recollection was that the difficulty in the review was related to:

 1. This feature having a cross-module scope
 2. The specific language to use for the label text (session and idle)

By cross module scope I mean that this is one example of a different 
kind of problem then we may be used to.  As the desktop becomes more 
integrated it will become increasingly difficult to maintain preference 
panels that are per-application.  For example, gnome-screensaver and 
gnome-power-manager are two distinct modules with fairly well defined 
roles at this point but the policy/preferences UI needs to become more 
integrated.  Exactly how this integration will occur I don't know.

> Firstly, we couldn't work out a good way to label the
> controls. That should be a red flag to begin with.
> The order that springs to mind is:
>  [*] Use the screensaver
>    - start it after [-------] minutes
>    - lock the screen
> That's the way the user conceptualizes it: do I want
> the saver or not? Supposing I do, how do I want it?
> The current way is quite simply backwards, and the
> logical way is not possible because of what the
> controls actually do.

Maybe.

> Second, I am currently writing the docs for this.
> What do I say about this slider?
> "Use the slider to set the screensaver delay time. The
> screensaver will" ... um, no, it won't!
> "Use the slider to set the session idle time"...
> meaningless jargon that users don't understand.
> "Use the slider to set the computer idle time"... I
> don't want my computer to be lazy!
> "Use the slider to set the time that your computer
> must be unused to count as "... to count as what?
> Again, I am depending on jargon.

Right, we haven't come up with a good way to describe this.  This is 
partly due to the problem I described above in that this function is 
scoped wider than just screensaver stuff.

In the UI review we just gave up.  We probably should have tried harder 
to get this right.  Sometimes there just isn't enough time to get it 
perfect.

Perhaps we could have used "desktop" instead of "session" and "inactive" 
instead of "idle" to avoid *new* jargon.

Or perhaps if we had this slider in the same dialog as the 
gnome-power-manager screen and computer suspend sliders, and we don't 
care to advertize a desktop wide idle/away setting we wouldn't have to 
make the distinction that it is the baseline idle time at all.

So, do we care to have an integrated desktop-wide idle setting?  I think 
it is useful.  I'd like some other opinions on this though.  There are 
lots of technical reasons why we'd want this which for the most part are 
either presence/communication related or boil down to a contract with 
the user that after this time applications should be free to do stuff 
that might otherwise piss the user off (eg. run backups, rebuild 
databases, etc).  But this is a usability list... So why might this be 
nice for people to have.  Well, there would only be one place that 
someone has to set this instead of in a screensaver, in a power-manager, 
in a chat client, in ekiga, in a backup client, etc.  I think it also 
makes the Desktop experience more personal in that it gets closer to 
knowing what you think.  We already can detect presence by proximity 
using bluetooth without using something as crude as a time slider bar. 
However, until we can ask the user "Is there anything else I can help 
you with for now?" we need to use a slider bar and try to detect the 
human activity from input devices.  So, that time slider bar has to go 
somewhere and it has to be described somehow.

> If you can't explain something cleanly and simply,
> then there is probably something wrong with it.

Probably more accurate to say there may be something wrong with it.

> The user opens the Screensaver prefs to do one thing:
> set the screensaver properties. When the screensaver
> starts, what it shows, and whether to lock the screen.
> That's it.
> We should not be overloading these settings with other
> things.

I agree.  This is partly due to the name of the menu entry, yes.

> Thirdly, there is no logical reason to tie screensaver
> activation to session idleness.
> The user may want several things to happen when the
> computer is unused. I can think of:
> - mark IM as away
> - show screensaver
> - power down monitor
> - hibernate

I think we disagree here.  I think there is a clear reason for relating 
screensaver activation and session/desktop idleness.  In fact, that has 
always been the case.  Just because there may be other things that are 
also interested in the session/desktop idleness doesn't mean that it 
shouldn't be related to screensaver activation.

> The last two have to go together. But why tie the
> others? 
> If I set my monitor to power down after 10 minutes,
> and my screensaver to show after 15, then I won't get
> to see it. Tough.

No not tough - wrong.  Why on earth should we allow settings that are 
meaningless?  That is super confusing.

> But the first two have no predefined order.
> For example, suppose I run BOINC as a screensaver. I
> want it to start early on, say 2 minutes. But I might
> be in front of my PC reading paper documents while
> that is happening. I want GAIM to be able to return me
> to the desktop if one of my contacts comes online or
> messages me, so I don't want GAIM to mark me as idle.

I don't mean to insult you but I hardly think this is normal behavior. 
Most people don't sit and watch screensavers.  Perhaps it should set the 
away message as "I'm really here but I'm watching my screensaver" ;) 
There are some other subtle points here regarding the effect of IM 
messages and DPMS suspend that I won't get into here.  Some more thought 
needs to go into how IM and messaging will work on a desktop appliance.

> It's obviously too late to do something for 2.14, so
> I'll try my best to come up with something for the
> documentation for this as it stands.
> But please could this be reconsidered?

Almost everything can be reconsidered.  As always, I welcome and 
appreciate more people being thoughtful about this stuff.  And thanks 
for working on the docs.

Thanks,
Jon