-
If this bug ever was fixed, this is a regression (otherwise it simply is a bug that hasn’t been fixed):
vs
-
One thing I liked about the previous breaks page was that I could very quickly scroll through the page, picking out goals to take breaks on. That process is now much slower; rather than scrolling through a list of checkboxes checking some as I go, I now need to click twice per goal: first “schedule break”, then “save” on each one. That halves my speed, and thus makes it be that bit more of a hassle to take a break on most of my goals at once. The way I see it, the whole point of the breaks page is to be able to set breaks en masse, so having to “schedule break” and “save” them one by one, instead of just selecting a bunch of checkboxes and then hitting “save” at the end, isn’t as good as what there was before.
However, here’s a workaround: I click on the “schedule break” button fore each goal I want to take a break on (without clicking “save”), then when I’m done selecting the goals I want to take a break on this way, I click on all the save buttons all at once by writing javascript in the dev console. This restores the previous use pattern (of selecting a bunch of goals and setting a break on them all at once), at the cost of being even more mobile-unfriendly than the previous breaks page. (Although I suppose I could write a userscript or extension that would click the “save” buttons instead of having to write the javascript anew in the console each time…)
Can you double check the first one? I thought I had fixed that already, but it was definitely missing when the breaks page switched over.
The second is likely to get some improvement, maybe even a “Save All” button.
However, I want to make it clear that adjusting the form to be more linear wasn’t an accident.
For every person who submitted changes to 20+ goals and they all were fine and it only took 3 seconds, how many people submitted changes and had at least one error? How easy was it to fix the error, or undo the other changes? How often did that take 30+ seconds or minutes to handle? On the old page, you could change your maximum safety buffer, change weekends off and your weekend rate, and schedule a break all on the same goal in the same submission. What should Beeminder do there? Even if there’s a correct order of operations, what are the chances that it’s obvious to most folks using the form?
Before this, the user experience to set dates across the goals was to change URL parameters. By putting the break scheduler behind a click, we were able to add the default date pickers. It seems to be clear to folks that changing the default dates changes any date pickers that aren’t visible, but doesn’t change the ones that are open.
I’d like to experiment with a “Save All” button that effectively submits each row in turn, and I’d like to experiment with a log on the page that keeps a list of changes. I also want to experiment with marking goals as “handled” and making them ghosty or moving them to a “handled” area or something…
-
Thanks, yes, now it seems to be handling the time zone correctly.
-
Yeah, I do appreciate that the new form is an improvement in many ways. It is perhaps a mistake to list only my complaints about it—although I wouldn’t say the new page is a pure Pareto improvement, it is indeed an improvement, and I do appreciate it for that. Take what I say here for what it’s worth; it’s not a condemnation of the new page, but rather my attempt to report how I’m experiencing it.
Beyond anything else, I’m happy that this was an opportunity to try out turbo frames and stimulus, and hopeful that in the long term this will lead to using these in a wider way to improve the Beeminder client-side experience.
All that said, I hope that in the future this page can somehow accommodate a workflow similar to my previous one, such as with that hypothetical “Save All” button experiment you suggest and similar.
I did not find the error handling in the previous setup too terrible—it would show a flash message with the names of the goals with errors, which could then be handled individually, and I never felt the need to roll back changes to other goals based on errors in one (usually that error being that the break was past the goal’s end date.) Nevertheless, one hypothetical improvement would have been do to the updates in a database transaction, which would be committed atomically, or rolled back automatically if there were any errors (although I appreciate that database transactions are typically less used with MongoDB than with SQL databases, despite MongoDB having support for transactions.)
But never mind that—the new setup with individual goal edit forms works great, with the exception of what I detailed above about doubling the work needed to select a bunch of goals for a roughly similar break. A “Save All” button seems like a good way to fix that up and make it be a Pareto improvement on what came before, and as you point out there is even more which can be done with regards to marking goals as “handled” or otherwise allowing the user to think systematically about their break. (In a very hypothetical future “true breaks” world, one could imagine a “break” as a first-class entity, which I imagine might be manipulated in a similar way.)
While doing my calendialing yesterday I thought about how much of a PDP violation this feels like. It doesn’t feel like much of one but I’m eager to hear more feedback.
My own new workflow is like so:
- Fill in the dates for whatever’s on my calendar in [now+1w, now+2w]
- Sort by increasing safety buffer (ok, this annoyingly takes an extra click now; we’ll get to that)
- Walk my way down the list, clicking “Schedule break” for each thing that’s impacted by whatever’s on my calendar
- Optionally change the daily rate from the default of zero
- Don’t click SAVE yet
- Stop when I hit the first goal with 14+ days of buffer
- Walk my way back up clicking SAVE on everything
I like this “walk your way down, then walk your way back up” workflow but I guess this depends heavily on how many breaks you’re setting. I generally have dozens of goals to consider taking a break on but less than a dozen that I decide I actually need a break on. So walking down the list and expanding the ones I want breaks on actually helps me keep my place in the list. Then it’s no big deal to do the half dozen clicks to kinda confirm them.
I do have the opinionated opinion that users should think carefully about each goal and pick a small-ish subset to actually schedule breaks on. Even if you’re going off the grid for vacation, getting enough safety buffer on your easy goals to carry you through the vacation is the preferred way.
(And as @mad pointed out in the Discord, some goals you actually want to do more of during vacation. Another reason walking your way down your list of goals and walking back up to confirm them is a good practice.)
PS: As for these awesome sounding ideas:
I think we sadly can’t actually prioritize those. Definitely not without hearing a louder outcry about the new status quo, I guess.
I’m strongly in favor of a “Save All” button, though I understand if the other experiments are much lower in priority. But the “Save All” button would cover the one way that this isn’t a Pareto improvement—needing to go through the list twice rather than once. (It also would be relatively easier to implement than the other ideas, cool as they are.)
I also have dozens of goals to consider taking a break on, of which usually at most a third or quarter or so will I actually take a break on at once. So my use-case is actually rather similar to yours; though I walk through them in alphabetical order, if only because I typically have very few with more than 14 days of buffer.
When I went to do this on the new breaks page, the experience felt noticeably worse. Maybe it isn’t such a big deal, but it’s definitely not great to have to walk the list twice, for no real reason.
The new page is a net improvement. But if the PDP means anything, it means that you don’t tolerate even these minor regressions to the user experience, at least not without good cause. To wave away the non-Pareto nature just because it’s a net improvement is exactly what the PDP is against, right?
Deploying a change that’s a net improvement but not a Pareto improvement tends to mean tolerating sloppiness, and that can be a slippery slope.
Or to put it another way: what exactly is the tradeoff you’ve chosen to make here by not having the save all button/forcing users to walk the list twice? The PDP post holds that even in the cases that it is worth doing something not Pareto-optimal, one should explain the tradeoff explicitly:
In short, if you want to make a change that degrades even an obscure use case, or would make a single (reasonable) user even slightly less happy, maintain the discipline of proving that the change is fully intentional by spelling out and justifying the tradeoff.
Is the idea that it’s meant to make users think more deeply about which goals they actually want to take breaks on? That doesn’t seem like it was the underlying intent, and even if it was, this is something I’m guessing at and reading between the lines to find; hardly a spelled-out justification of the tradeoff!
I’ll add for whatever it’s worth that I think the support team could really use a save all button. Luckily the number of mass breaks we do for people is relatively small, but this has definitely made it a bit more cumbersome when we do have to do it.
I’d say if it takes more than a couple hours of work tops to add a “save all” button, then it probably balances out better for the support team to be inconvenienced as far as cost/benefit goes, at least in the short term. If it’s fairly simple to add, though, then I think it’d be very useful even over the relatively short term. (Say, by February if it were added today.)
I think of the options suggested, the save all button is the likeliest to help support’s use case.
I’m pretty sure this was one of my original concerns when Adam consulted me originally, and it’s been borne out in practice – I’ve done mass breaks for users on the new page a couple of times, and it was a lot to get used to. (Sorry Adam! It really is so much slicker in so many ways and I love it, but the old breaks page made it so convenient and really took the pain out of adding breaks to people’s goals for admins, and for me at least, this has palpably added the pain back. I hope I don’t sound ungrateful/whiny here!)
As an individual user, I’m like @dreev: I set breaks on a very small subset of my goals at any given time. I have a different workflow for selecting which goals get breaks, though, and the walk-down-and-back-up method feels a little clunky to me because I don’t neatly sort my goals like that first so I can end up missing a save button in the scrolling. As a result, I’ve been clicking save buttons as I go… which leads to me forgetting whether I did that one yet or not. 
It’s not a screamingly urgent thing for me as a user, though.
Aha, yeah, was gonna say, @zzq had pretty much convinced me (or at least convinced me that we either needed the save-all button or a blog post about how Opinionated we are about making it intentionally not too easy to lazily pause everything en masse) so now @shanaqui has made it definitive!
Thanks, y’all!
I spent a few minutes this morning and tidied up what I had been experimenting with for “save all breaks”, added some quals, and deployed it a few minutes ago.
Let me know what you all think!