Strict-Workflow
Strict-Workflow copied to clipboard
matchu
Add options for automatic work, or automatic break.
This adds two separate options for automatically starting the break timer, or automatically starting the work timer. It's integrated into the option system, and makes sure the notifications don't disappear immediately. Since the settings can be set separately, you don't get stuck like in pull request 36.
Personally I only use the starting the break timer automatically. Still, anyone using both can turn the automatic starting off in the settings when they want to stop.
It should work out of the box, but if you don't want to change anything in the default behavior you should set autostartBreak to false in the defaults.
Cheers, Marius
Interesting! I think this is a better solution than #36, but I still don't think Auto Mode is the best way to address the problem—though it's fair to point out that that comment is a year old now and 2.0 has been slow in coming :P I put it off because I was waiting for Chrome on Linux to get rich notifications, but, well, it might be time to stop waiting.
As with most pull requests here, I don't plan to merge this right now but feel like closing it would indicate that the problem is resolved, which it's definitely not. In the meantime, when folks come looking for an Auto Mode, I'll point them to your work :)
Thanks! Happy Thursday!
Works for me, but has the slight drawback that it's difficult for users to install developer mode extensions, and they'll get a pop-up warning them of developer mode extensions every time they start chrome. In theory I could put my version in the web store, if you didn't mind, but I'll have to figure out how to do that first :)
Hmm, I've never seen the developer mode warning popup. What does it look like? Could it be triggered by something else? On May 21, 2014 10:36 PM, "Mqrius" [email protected] wrote:
Works for me, but has the slight drawback that it's difficult for users to install developer mode extensions, and they'll get a pop-up warning them of developer mode extensions every time they start chrome. In theory I could put my version in the web store, if you didn't mind, but I'll have to figure out how to do that first :)
— Reply to this email directly or view it on GitHubhttps://github.com/matchu/Strict-Workflow/pull/39#issuecomment-43850243 .
It doesn't happen if you're on the dev or canary channel, and it's a recent addition. It's triggered if you have any developer mode extensions running.
Hmm, maybe it's a Windows thing—I'd heard they'd started locking down the platform. Sigh.
I don't like the idea of every fork popping up in the web store, especially since most of their concerns will be resolved more smoothly into the 2.0 release (though at this rate one could easily disbelieve that it's ever going to happen :P), but I don't like how inconvenient the Windows Chrome extension platform has become. Users who care could always use the dev build to remove the popup, but that has its own obvious drawbacks, too… but then you could argue that folks who bother to seek out Auto Mode over the decent default behavior are much more likely to be willing to jump through hoops… On May 21, 2014 10:36 PM, "Mqrius" [email protected] wrote:
Works for me, but has the slight drawback that it's difficult for users to install developer mode extensions, and they'll get a pop-up warning them of developer mode extensions every time they start chrome. In theory I could put my version in the web store, if you didn't mind, but I'll have to figure out how to do that first :)
— Reply to this email directly or view it on GitHubhttps://github.com/matchu/Strict-Workflow/pull/39#issuecomment-43850243 .
Yeah, it's inconvenient, but understandable with the developer extensions installed by malware that has been going around.
You still have the other option; if you accept the pull request, users will have a form of the feature they've been asking for for over a year, you show people you're still working on this, and you get some extra time to fix version 2 properly :)
Haha, cute argument :) And a decent point—even if something isn't the right long-term solution, it might be an effective stopgap. Another reason I'm hedging is because I'm not sure how my current summer job's contract affects my ability to work on this project right now; I'll look into it :)
An interesting note—you only use the auto-start for break timers, yeah? Here's a non-rhetorical question: what time management problem does that solve for you? I understand why someone might be taking extra-long breaks and would want the work timer to auto-block their sites immediately; were you taking extra-long work sessions? How did auto-starting the break timer help resolve those? (Again, not rhetorical—since this feature solves a problem that I personally don't have, I need to understand it better.)
It's not a time management solution so much as a practical one. I would occasionally forget to hit the break timer, or if I would stop working for the day altogether I wouldn't hit it either. Then the next time I wanted to start a pomodoro, I would have to start a break first, which is quite weird and inconvenient.
Additionally, as shown by the reviews, there are many people (including me) who at first don't realize that you actually have to click to start the break. They'll think that the extension is not working because it's still blocking sites even after the work timer ended! That's why I made the autostart break the default -- because it's what people expect.
Gotcha. Thanks—that's helpful :D Lemme see if I can rephrase those two issues accurately:
- Users usually finish their work during a work cycle, and the current way to indicate finishing is to run a redundant break timer. This is an unintuitive way to express the idea of finishing, so new users don't know how to do it and regular users don't always remember.
- New users want to take a break, but don't see any obvious control to start the break, so assume that it was an automatic process that failed.
That is, the way to transition from one state to another is not always clear.
One option is to hack around the issue by making the less clear decisions on the user's behalf—though not necessarily entirely correctly: if the user is done working, starting a break timer isn't a bad decision, but also isn't the best decision. (I'm also hesitant to change the default workflow to solve anything other than workflow problems. I don't have data to back up my belief that explicit transitions are better for users, but changing that behavior at this point would require either data or a very strong argument that it's better for user productivity :/)
The better solution to the problem of unclear controls is to make the controls clearer: rather than offer one decent transition behind the tomato icon, offer all reasonable transitions in the block overlay (users look there when trying to unblock pages), the notification (users look there when a timer ends), and the brand new popup interface (users look there if there are no blocked pages or notification).
The buttons-everywhere solution is already largely implemented for the upcoming release—and looks pretty neat! And, now that rich notifications are in the Linux dev build, it might be time to polish it off during some weekend or other.
Anyway. Thanks for forking and for participating in this very helpful discussion :D I'm fairly confident that default automatic state transitions won't be present in the next major release, but I may merge this version as a stopgap if there's a very significant delay before then.
Agreed with 1. You might have a solution where you allow the users to cut the break short.
As per point 2: I agree with you that not automatically starting the break might be better productivity-wise. The problem is that it's currently not expected. Having the option in the options menu signals to users that that's even a thing that can happen, whether it's on by default or not.
Now, I'd say, the defaults should work exactly as users expect. If you don't do that, half of the users will check the settings, and the other half will uninstall the extension and find something else. Additionally, they might rate the extension 1 star for being not functional. New users expect the break to start automatically, and while that may not be ideal, not having the extension at all is even worse :) Perhaps you could update it such that if people already have the extension, it will stick to its previous behavior, but for new installs it will go with what new users expect?
Giving info in the notification would be helpful, but, not everyone allows extensions to pop up desktop notifications. Having it in the settings works as I also described above, but you'll miss out on people that don't care for the settings. I don't know what the popup interface looks like, so that may work.
As a last thing: Having a heuristic that says “I'll merge it only if there will be a significant delay” sounds good, but usually doesn't work. Reason being that a project can be done “in two weeks” for years on end :)
Cheers
Oh, hey, looks like the Chrome team pushed Rich Notifications to Linux just this week! No more excuses, then; sounds like it's time to get down to work :)
Since this hasn't been on my mind in a while, I just remembered another feature under review: the ability to schedule a number of cycles in advance. That grants the convenience of auto-starting each phase without being surprising, sacrificing user control, or significantly disrupting the alacarte flow. Combined with clearer transition controls, I think this might address all the same concerns as the various Auto Mode drafts that've been going around and remove a lot of potentially tempting transition decisions. I'll play with it a bit more this weekend and see how it feels.
Now that we have notifications, the overhaul of the extension is finally at feature parity with the original, so it's now available on the v2a branch if you're interested :)
