Re: [Usability]DrWright simplification

["Adam D. Lopresto" <adam cec wustl edu>]

You've got some good ideas, but I wonder whether thinking about DrWright in
isolation is the right approach.  Really, I think DrWright and the screensaver
are two sides of the same coin, and should be considered together.  Issues like
locking with the password are already there, and in general screensaver and
locking needs to be hooked together in some reasonable way (so that when I go
to take my tea, someone doesn't come in after my break finishes and starts
using my computer).  I'm not sure all of this really consitutes a simplifation,
but it seems all related to me, and having two separate sets of controls
watching activity and locking the screen in different ways seems confusing.

> [ Cc'ed to usability gnome org so other people can comment if they want. ]
> 
> Greetings!
> 
> A short while ago I started using DrWright[0].  While this is the first
> time I ever used one of these type of programs, overall I have to say that
> I like both the general idea[1] and the implementation[2].
> 
> However, while there are seemingly implementations with a considerably
> more difficult UI, I still think that the current UI of DrWright
> (specifically the preferences dialog) is not as simple as it could/should
> be.  Ideally, I think, the preferences window would only contain the
> following two preferences:
> 
>   Work interval:  [      ] minutes
> 
>   Break interval: [      ] minutes
> 
> These two options, I think, are the only ones that almost any user should
> really ever have any interest to change and everything else should, if
> possible, just work in a sensible way without configuration.
> 
> So, what are the remaining options and why do they exist?  First, there is
> the `Warning time'.  Why this option is configurable in the first place is
> something that I do not understand.  Is there really any advantage for
> users to have their own personalized setting here over getting used to a
> sensible default?
> 
> The other two settings that I think are superfluous are those under
> `Advanced': `Warning method' and `Unblocking'.  Leaving the possible
> requirement for a password aside for the moment I think that both of these
> options exist basically for the same reason: to workaround a
> usability-problem that is inherent to the current approach DrWright takes.
> The approach I'm talking about is to have a fixed break at a certain time
> and the problem with this approach is that if such a break comes as a
> surprise to the user at a time where he/she is not prepared to simply
> accept it (e.g. she just started chatting with a friend), it might at best
> be taken as a mildly annoying, and in some situations even as a really
> frustrating interruption.
> 
> DrWright currently implements two workarounds to this problem:
> 
>   1. In addition to the (often unnoticed) status area indication of an
>      upcoming break it can show a more noticeable warning window.
> 
>   2. It has a way of allowing the user to prematurely end the break.
> 
> Because these workarounds do have their own problems, however, they are
> implemented as user-settings (that way the user can decide for
> him-/herself which of the problems -- or combination of problems -- is the
> most tolerable to him).  This, of course, is a less then perfect solution.
> 
> Sooo.... do _I_ have a solution to this problem?  Well, perhaps not a
> perfect one, but at least one that I'd personally _expect_ to work quite
> nicely for most people.
> 
> What I suggest as a lower-level, non-option workaround is quite simple:
> always have a button (similar to the current unblock button) on the break
> screen that can be used to *postpone* (not end!) the break for something
> like, say, 3 minutes.
> 
> That way there would basically be two different ways for a user to react
> when a break happens:
> 
>   1. "Uhm what!?  Oh, it's break time again.  Hmmm... Nethack can wait.
>      Let's go and get myself a nice cup of tea!"
> 
>      ...thinks so and walks off for some tea.
> 
>   2. "What the...!?  Aaaaarrgh!!  I'M JUST ABOUT TO BEAT MY ALL-TIME
>      HIGHSCORE IN MAHJONGG!!  At the very least I'd have to hit pause
>      before I go of for a break now..."
> 
>      ...thinks so and hits `Postpone Break'.  However, as he now lost his
>      concentration anyway because of the interruption, he pauses Mahjongg
>      and clicks on the still red status icon to restart the break[3].
>      Finally, he also walks off for some tea.
> 
> Now... whether the option to postpone a break should still be available
> for breaks that have already been postponed (perhaps with shrinking
> time-intervals before new breaks) or only for a fixed amount of times
> (i.e. only once or twice) is something that I'm not completely sure about
> (and that should perhaps best be experimented with anyway).  What I'm at
> least inclined towards though, is the former, because the latter still has
> the potential of really annoying users sometimes.  And given that the user
> has setup DrWright voluntarily, I think that the recurring break screen
> should be enough to make him take the break eventually.
> 
> What remains now is how to integrate a password/phrase, for situations
> where the user wants to walk off during a break while knowing that his
> computer is secured against other peoples use (for as long as the break
> lasts, at least).  An alternative to have a password-related setting in
> the properties might here be to:
> 
>   1. make a password automatically (i.e. independently of any settings) be
>      required to unlock the screen _except for the first 10 / 15 seconds
>      after activation of the break screen_.
> 
>   2. make the passwort automatically the users' usual login password
>      (perhaps pam could be used here, or whatever).
> 
> Doing it that way there would be no need for special configuration options
> while the password still wouldn't get into the users' way in the most
> common situation because of the short delay that is introduced before it
> is required.
> 
> The only regression I see here is in situations where there is a user at
> the computer that doesn't know the login-password.  In this case, however,
> I think it's acceptable to say that, if the user wasn't fast enough to hit
> the `Postpone' button in time, then it's just bad luck and ok to have him
> live with the break.
> 
> Anyway, that's basically what I wanted to say... sorry for the long mail.
> The above is all just meant as a suggestion, of course, and I'll happily
> accept that there might be differing views :-)
> 
> Regards,
> Lars
> 
> [0] http://drwright.codefactory.se/
> 
> [1] Not only does the break considerably drive up my tea-consumption, it
> also really helps me to stay focused by regularly forcing me to stop and
> think about what it was I was actually doing :-)
> 
> [2] Thanks!
> 
> [3] This just to sneak in another small feature -- had he waited long
> enough, the `Take a break' screen would of course have returned on it's
> own.
> 
> Manually starting a break by clicking the status icon could perhaps be
> enabled whenever the icon is red, not only after postponing a break.
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
> 

-- 
Adam Lopresto (adam cec wustl edu)
http://cec.wustl.edu/~adam/

That which does not kill me can only make me stranger.