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

No default due dates #260

Closed
dreeves opened this issue Aug 28, 2018 · 1 comment
Closed

No default due dates #260

dreeves opened this issue Aug 28, 2018 · 1 comment
Labels
ADO Consensus needed on what to Actually Do (or "much ado about ∅"), AKA question RFE Request For Enhancement AKA feature request UVI User-Visible Improvement zzz (closed as) postponed

Comments

@dreeves
Copy link
Contributor

dreeves commented Aug 28, 2018

(This was originally bundled with a proposal to kill create-on-GET (#251) and then was bundled with a proposal to change the default due date to 5pm the next business day (#257).)

Prescript: I wrote this when the default deadline was a week. Not sure if it will still apply now. We'll snooze it in the meantime.

Background / Whining

I've found that defaulting to a week for the due date is often quite bad for me. I make an off-the-cuff "I will" statement with no explicit due date but where "today or tomorrow" is what makes most sense. Of course the path of least resistance is to let the one-week deadline stand, which always seems fine at the time. But what ends up happening is that by the time the deadline comes around I've lost the mental context and the task seems daunting and maybe I decide it's not so bad to be a day late. I don't know how typical I am but it's a real problem for me.

So I'd like to experiment with commits.to forcing me to explicitly pick a due date (if I don't specify one in the URL).

Proposal

  1. The GET request still creates the promise and presents you with the standard promise edit screen but with an expanded (as in non-collapsed) datepicker.
  2. If Sherlock parsed a date, that's what's selected on the datepicker and there's nothing to do, but you can easily change it if Sherlock was wrong.
  3. If Sherlock didn't parse a date, nothing is selected on the datepicker, but since it's pre-expanded it's just one click to pick a due date.
  4. (Aside: see footnote 2 in issue Revamp colors for promises based on status and time to deadline #247 about making it obvious that a new promise was just created.)
  5. As also discussed in issue Revamp colors for promises based on status and time to deadline #247, if you don't pick a due date then THERE JUST IS NO DUE DATE.
  6. Promises without due dates are handled fine scoring-wise (they count as pending / unscored). The only trick is that they have to goad you into picking a due date.

How To Force The User To Pick A Due Date

We need something where it's just not reasonable for the user to let due-date-less promises accumulate like a to-do list. Ideas:

7a. A literally blinking "N/A" in place of the score and you have to pick a due date to make the godawful blinking stop.
7b. If there are any promises without due dates then all other promises are hidden.
7c. Garish colors?

@dreeves dreeves added RFE Request For Enhancement AKA feature request zzz (closed as) postponed ADO Consensus needed on what to Actually Do (or "much ado about ∅"), AKA question UVI User-Visible Improvement labels Aug 28, 2018
@dreeves dreeves closed this as completed Aug 28, 2018
@dreeves
Copy link
Contributor Author

dreeves commented Oct 11, 2018

Also still on the table: the status quo where the system just picks a default due date! I still like this proposal of forcing the user to make an explicit choice but I'm not totally confident of it. Keeping it snoozed for now...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ADO Consensus needed on what to Actually Do (or "much ado about ∅"), AKA question RFE Request For Enhancement AKA feature request UVI User-Visible Improvement zzz (closed as) postponed
Projects
None yet
Development

No branches or pull requests

1 participant