Love the Latest Start feature. However, it’s very possible that latest start time can, by default, be created for, say, 3am(!). Not a great time to be notified…usually.
A request would be to limit latest starts outside a user-set time window. Or, delay all notifications that occur in a set window. Or give the user some choices: Delay √Latest Start and √Defer Date notifications but not √Due Date Notifications. Just some ideas.
Can you explain to me what is the point of scheduling a task for 7:00 a.m. when I know that the message will arrive at 3:00 a.m. and I need four hours to complete it, which is a lot of work? What is not working in your daily planning? That would be just as absurd as wishing that no due date notifications were sent at night. It’s a question of how well you plan your day.
I would never think of using your method with a start date notification to schedule my 2026 income tax return in Omnifocus for 8:00 a.m., for which I have allocated about 6-7 hours to complete.
I think there are more important issues for the Omni developers to address than tinkering around here and there. Soon there will probably be a request: “I want the latest start to take into account that I have breakfast for about 30 minutes at 9:00 a.m.”
While effective planning is undoubtedly the user’s responsibility, I would suggest that tools may actually need to better accommodate the complexities of real-life workflows.
Offering customizable notification settings—such as quiet hours or differentiated alerts—would not encourage poor planning habits. Rather, it shows respect for differing schedules, time zones, and the unpredictable nature of daily tasks. A well-designed productivity tool should ideally support users through flexibility, reducing friction rather than adding to it. While the emphasis on self-discipline is reasonable in principle, in practice, thoughtful adaptability often leads to a more human-centered and widely applicable experience—and can help foster a broader and more satisfied user base.
These thoughts are shared for your consideration. Thanks.
Tools I would maintain need to first reflect the vision of the developer because without a belief in the product it will eventually wither on the vine.
Opinionated software can flourish as per Cultured Codes Things as can more flexible products however trying to cater for every edge and sometimes not so edge case leads down the Evernote route to disaster. Whatever feature you add it will never be enough.
I read somewhere that when a feature is suggested you should also suggest one to remove.
Thank you for your thoughtful reply and for sharing your perspective—I really appreciate the insights you’ve provided, especially regarding the balance between vision-led development and flexibility. It’s a valuable reminder of how challenging product evolution can be.
I also appreciate the welcoming note!
As for the ideas I mentioned, I just wanted to put them out there for consideration. Whether they align with the product’s direction or get integrated into future plans will ultimately be up to the development team. I totally respect that building and maintaining a tool involves many thoughtful decisions, and I’m glad to contribute to the conversation.
Thanks again for your response—looking forward to more discussions in the future