Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First time user, locked out of options #23

Open
ianfixes opened this issue Nov 26, 2012 · 9 comments
Open

First time user, locked out of options #23

ianfixes opened this issue Nov 26, 2012 · 9 comments

Comments

@ianfixes
Copy link

This is a minor point, but a huge annoyance. I'm using this for the first time, so I want to play with the settings a bit to make sure I'm blocking the right things. The only problem is that once the session starts, I have to wait 25 minutes before I can make my next edit (which will be turning the session time down to 1 minute until I get everything properly configured). Sadface. Even disabling/re-enabling the extension just re-starts the schedule where it left off.

There are several ways that this could be improved:

  1. The first time a session is started (on new install), bring up the options instead so the user can review the blocklist.
  2. Have a "test mode" (only available on new installs) that allows you to turn the blocking on and off as desired. That is, until you click the big red button that says "ok, from here on out, it's strict mode".
  3. Default to 1-minute sessions and suggest turning it up once the user has configured everything.
@matchu
Copy link
Owner

matchu commented Nov 26, 2012

Sorry for the trouble :/

It's actually just an illusion that the timer resumes when the extension is
re-enabled: Chrome fully resets the extension's internals, but restores the
button's previous state, so, even if it's dark red and says 25m, that's
just because that's what it said when disabled. The options panel is fully
functional. I haven't looked into how feasible it would be to force the
button back into its default state, though it's enough of an edge case
(disabling isn't really part of an extensions UX) that I'm not sure it's
worth it.

Part of the Pomodoro philosophy is that the creators of the technique
really do know more about productivity than the average user, so the
defaults really oughta work well for everyone. So, I'm not really into the
idea of forcing users to visit the options page: it should work out of the
box.

But there's definitely a case to be made that there wasn't fair warning: if
the user was expecting the button to pull up some further UI rather than
locking them into a work session, that's not good.

In that case, one solution would be to pop up a dialog using the nifty
button popup UI: "Distracting sites will be blocked for 25 minutes. (undo)"

This allows new users to click without fear, while maintaining the
simplicity of out-of-the-box one-click behavior and preserving the
strictness of no-cancel since cancellation is only available for a limited
time.

I'm not in a position to implement this right now (impending exams and
all), but I'm very interesting in seeing this happen down the road, and
would definitely accept a pull request that implemented this feature well
:) Thanks!
On Nov 26, 2012 8:34 AM, "Ian" notifications@github.com wrote:

This is a minor point, but a huge annoyance. I'm using this for the first
time, so I want to play with the settings a bit to make sure I'm blocking
the right things. The only problem is that once the session starts, I have
to wait 25 minutes before I can make my next edit (which will be turning
the session time down to 1 minute until I get everything properly
configured). Sadface. Even disabling/re-enabling the extension just
re-starts the schedule where it left off.

There are several ways that this could be improved:

  1. The first time a session is started (on new install), bring up the
    options instead so the user can review the blocklist.
  2. Have a "test mode" (only available on new installs) that allows you to
    turn the blocking on and off as desired. That is, until you click the big
    red button that says "ok, from here on out, it's strict mode".
  3. Default to 1-minute sessions and suggest turning it up once the user
    has configured everything.


Reply to this email directly or view it on GitHubhttps://github.com//issues/23.

@ianfixes
Copy link
Author

Well, I thought I would have to wait 25 minutes... but here I am during the break, the icon is green, and I get the same "To remove temptation, some settings cannot be edited during a work session. Patience, please." message, with no indication of how long it will be before I'm allowed to edit the settings.

@ianfixes
Copy link
Author

Seriously, WTF do I have to do to be allowed to edit the settings?

@matchu
Copy link
Owner

matchu commented Nov 26, 2012

Eek. I've heard of options lockout, but have never been able to reproduce
it :/ Sorry!
On Nov 26, 2012 9:03 AM, "Ian" notifications@github.com wrote:

Well, I thought I would have to wait 25 minutes... but here I am during
the break, the icon is green, and I get the same "To remove temptation,
some settings cannot be edited during a work session. Patience, please."
message, with no indication of how long it will be before I'm allowed to
edit the settings.


Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-10716334.

@matchu
Copy link
Owner

matchu commented Nov 26, 2012

Note that the break session has to actually start: click the icon to
start the 5min timer. (If I don't notice the work timer ending, I don't
want it to keep the cycle going, or else I get cheated out of break time
:/) Worst-case scenario: disable/enable again, since no matter how the
button looks, timers don't resume.
On Nov 26, 2012 9:05 AM, "Matchu" matchu1993@gmail.com wrote:

Eek. I've heard of options lockout, but have never been able to reproduce
it :/ Sorry!
On Nov 26, 2012 9:03 AM, "Ian" notifications@github.com wrote:

Well, I thought I would have to wait 25 minutes... but here I am during
the break, the icon is green, and I get the same "To remove temptation,
some settings cannot be edited during a work session. Patience, please."
message, with no indication of how long it will be before I'm allowed to
edit the settings.


Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-10716334.

@ianfixes
Copy link
Author

How I got where I am now:

  1. Start session
  2. Start session again
  3. Open settings
  4. Disable extension
  5. Re-enable extension
  6. Wait for session to end.

If I had to guess, I'd say that disabling the extension disables the timer'd function to restore the functionality of the settings:
https://github.com/matchu/Strict-Pomodoro/blob/master/options.js#L116-121

The solution might be to refresh the state of the settings page on a separate timer, or every time the settings page is loaded.

@ianfixes
Copy link
Author

Aah, if I click the green tomato icon, then the break begins. How I was supposed to know this "out of the box" is beyond me -- I thought the break began automatically, and that I was on it. After your exams, I'd suggest adding some sort of status page (put it on the settings page if you like) that explains what state the plugin is currently in, and what options you have: getting to next states, accessing various features, etc.

I'd also suggest changing the "Strict Pomodoro" menu option to "Strict Pomodoro..." to indicate that it's not an option for starting a new strict pomodoro session.

Even just a small legend somewhere indicating what the various tomato icons indicate would be a start (faded red, red + number, green, green + number, etc).

@matchu
Copy link
Owner

matchu commented Nov 26, 2012

When an extension is disabled, all of its processes end. So, yeah, the
re-enabling of the options page never happens, but that options page no
longer exists, anyway, so the read-only state isn't preserved anywhere. At
least, that's the behavior I'm seeing on Chrome 23, and, to my knowledge,
that's how it's always behaved.

So, to be clear, if a timer is started, the extension is disabled, then
it's enabled, then its options page is opened, the options page is
read-only and the button is counting down? If so, what version of Chrome is
this and in what environment, since that's not the documented behavior: all
pages, including background pages and options pages, should be totally
reloaded during that process and not preserve their local variables' state.
If they do preserve state, we need to file a bug report with the Chrome
team.

It might help to set the timers to durations of the format "0:SS" for
seconds, a nice debugging feature :)
On Nov 26, 2012 9:12 AM, "Ian" notifications@github.com wrote:

How I got where I am now:

  1. Start session
  2. Start session again
  3. Open settings
  4. Disable extension
  5. Re-enable extension
  6. Wait for session to end.

If I had to guess, I'd say that disabling the extension disables the
timer'd function to restore the functionality of the settings:
https://github.com/matchu/Strict-Pomodoro/blob/master/options.js#L116-121


Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-10716627.

@matchu
Copy link
Owner

matchu commented Nov 26, 2012

Yeah, sorry for the trouble. I'd be interested in the idea of having both
the options page and the overlay on blocked pages better explain
themselves. Honestly, this extension was built 100% for my use and was
published only as an afterthought, so UI hints were crazy-low priority. I'm
kinda amazed that people are figuring it out at all :P

Thanks for your help :D
On Nov 26, 2012 9:22 AM, "Matchu" matchu1993@gmail.com wrote:

When an extension is disabled, all of its processes end. So, yeah, the
re-enabling of the options page never happens, but that options page no
longer exists, anyway, so the read-only state isn't preserved anywhere. At
least, that's the behavior I'm seeing on Chrome 23, and, to my knowledge,
that's how it's always behaved.

So, to be clear, if a timer is started, the extension is disabled, then
it's enabled, then its options page is opened, the options page is
read-only and the button is counting down? If so, what version of Chrome is
this and in what environment, since that's not the documented behavior: all
pages, including background pages and options pages, should be totally
reloaded during that process and not preserve their local variables' state.
If they do preserve state, we need to file a bug report with the Chrome
team.

It might help to set the timers to durations of the format "0:SS" for
seconds, a nice debugging feature :)
On Nov 26, 2012 9:12 AM, "Ian" notifications@github.com wrote:

How I got where I am now:

  1. Start session
  2. Start session again
  3. Open settings
  4. Disable extension
  5. Re-enable extension
  6. Wait for session to end.

If I had to guess, I'd say that disabling the extension disables the
timer'd function to restore the functionality of the settings:
https://github.com/matchu/Strict-Pomodoro/blob/master/options.js#L116-121


Reply to this email directly or view it on GitHubhttps://github.com//issues/23#issuecomment-10716627.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants