Hey Bastien, thanks for your reply.
I feel that this sort of leans into what I am saying though… would it not be fair to say that tasks without a date on them are the tasks that need to be tackled immediately, before any other task, as the first action should be to set them a date? Instead, in the current implementation, these are lost below a see of tasks that have been assigned a date.
In my opinion, it’s important to design software for how the user will experience things rather than how you think they should use the app to best effect. Doing the latter makes things harder to use as you building in an expectation that people need to be very well informed and unlikely to make mistakes.
You could go down the route of making the due date a required field on the task, but the extra rigidity would break a lot of ease of use. So, if you aren’t going to do that, should you not to try to account for tasks that don’t have dates as well as tasks that do?
Instead, again in my opinion, you end up in a much better place by designing things to work effectively when used optimally but also support users when things aren’t going so well. For me, one of the real benefits of Asana is to help catch things that are falling through the cracks