Task time editing UX/UI advice

[thesamim]

Hi folks,

Need some UX/UI advice please.

Problem statement: TickTickSync has to deal with times in task dates. The Task plugin does not handle times. I would like to give the user the ability to enter and edit times for dates without affecting the Task plugin functionality. Task requires the date to be the last thing on the line, and will not parse a date with a time. Here’s the Task task format

Use case: Users want to enter times with dates. I want to give the users the ability to edit those date/times.

Entering a date/time is easy enough. They enter
-[ ] 📅 2024-07-20 15:00
and I parse the components.

Displaying the task and allowing the user to edit the time is where I need help.

Option 1:

User enters:
- [ ] this task 📅 2024-07-20
TickTickSync converts it to:
- [ ] this task 📅 15:00 📅 2024-07-20

User can edit the time following the appropriate emoji.

It gets a bit fraught if they have a start date, scheduled and created date because there would be multiple emojis:

- [ ] This is a task with a due date 📅 2024-07-29 15:00 and a scheduled date ⏳ 2024-07-29 14:00 and a created date ➕ 2024-07-29
becomes
- [ ] This is a task with a due date 📅 15:00 and a scheduled date ⏳ 14:00 and a created date 📅 2024-07-29 ⏳ 2024-07-29 ➕ 2024-07-29

Easy enough to code, not pretty.

Option 2:

User enters:
- [ ] this task 📅 2024-07-20
TickTickSync converts it to:
- [ ] this task 📅 2024-07-20
the time component is hidden

User edits the time by double clicking the date, or hovering over the date and a modal is presented to edit the date.

- [ ] This is a task with a due date 📅 2024-07-29 15:00 and a scheduled date ⏳ 2024-07-29 14:00 and a created date ➕ 2024-07-29
becomes
- [ ] This is a task with a due date and a scheduled date and a created date 📅 2024-07-29 ⏳ 2024-07-29 14:00 ➕ 2024-07-29

Again double click or hover to edit.

Any other suggestions/recommendations?

[ClareMacrae]

You could review what other plugins do to track time and maintain compatibility with Tasks - to at least see if you can avoid inventing another new standard…

For example, Day Planner does the following (source):

---
tags: "#task"
---

- [ ] 08:00 - 10:00 This task uses the shorthand format ⏳ 2021-08-29
- [ ] 11:00 - 13:00 This task uses the Dataview property format [scheduled:: 2021-08-29]

It’s interesting that Day Planner has concepts of start and end time, or start and default duration…

[ClareMacrae]

@thesamim

15:00 2024-07-20

I feel it’s best to avoid one emoji having two different meanings to it, and this is likely a recipe for confusion.

Also, I am likely to start making the Tasks plugin report errors to users if they have task lines with un-parsed emojis in, as it trips up so many users.

This would mean that the above line would trigger an error report in Tasks, that there is a in the description line…

[ClareMacrae]

I feel that the ideal solution would be to teach the Tasks plugin to read dates with optional times.

There was an attempt to do that recently for adding Reminders support but unfortunately it was done without writing tests along the way, and turned out to be too buggy to merge…

Trying to fix these issues revealed this, which would need to be fixed before any more date/time related work were done:
Data in Task and TasksDate are accidentally mutable - dates can be edited unintentionally.

As this is such a core area of Tasks, it would need to be done by someone with a really thorough understanding of TDD.

Update: I am expecting to do some consultancy work on the Tasks plugin some time this year, and I suspect that it may involve teaching Tasks to support optional times on dates.

[pshev]

A while ago I saw a suggestion and since I’ve been starting my descriptions with the time and length:

• [[startTime: 08:00]] [length:30m]] rest of description 📅 2024-07-20

you can then:

sort by date
sort by description

and get a date/time list. i used the dataview format for date and length in case tasks eventually supports mixed tasks/dataview format and adds a sort by time

[thesamim]

@ClareMacrae : Thanks so much! This makes the most sense. This is what I will implement.

@pshev : Thanks for the suggestion. I will start with Clare’s recommendation as it’s the easiest to implement. I will look into your suggestion as a later (possibly optional) enhancement later.