[Usability]DrWright simplification

[Lars Weber <lars brokenbits de>]

[ 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.