Closed coreymckrill closed 3 years ago
If we go this route, we could probably close #50
This might also make #56 easier to implement, since it would be our own date picker instead of the default one.
Just noting here that #94 has another approach, which I like even more, because it's more self-documenting. That is, the flow is the same as normal for updating an existing post, but then the Update button has this easily discoverable dropdown where you can choose to save it for later instead, and then you are guided to the necessary datepicker, etc., via a separate sidebar.
A common theme from testers has been that changing the post's publication date is not an intuitive way to set the schedule for the update, especially since this won't actually change the publication date of the post. @kellychoffman came up with this wireframe for an alternative:
After checking/toggling the control for the update, a new date picker would appear:
I think this flow makes a lot of sense, and could open up opportunities for better inline documentation and other controls in the future (like adding a "pending" option back in).
The wording on these is not final, and we probably wouldn't want to call it a "future" update, since there will eventually be a "pending" update type that is not date-dependent. Also, I'm not sure if we'd want the "Create update" button to be down in the panel, rather than changing the main blue Update button in the top bar like we're doing now.