Your input needed for the date feature! [Ended]

The feedback phase has ended and we’re now planning out the work. Stay tuned!

We’re starting to working on dates, woohoo!

After reading through feedback from you guys and the discussion on Trello, we also referred to what the other apps do (primarily Evernote and Slack). Below is what we plan to include in the very first version of dates:

  • You will be able to bring up the date picker with a special trigger character, “!”. There must be a space before “!”, or it must be the first thing in an item.
  • You can pick the date and time in the date picker. There are maybe 7,352 types of date pickers out there that looks and works differently from each other; we’ll try our best to pick one that’s both efficient and good-looking.
  • After you pick a date, a date that roughly follows the ISO format will be generated for you. Something like YYYY-MM-DD HH:MM. Not finalized yet, but it would something that’s usable for people from all around the world and is relatively easy to understand. Without the date picker, you can probably write it yourself if you want to.
  • We haven’t decided on what the date markdown should look like, but it’s gonna be something that’s easy to write.
  • When displayed (when you’re not editing the item that contains dates), the date will show up as a relative date (e.g. “Today 3 pm”).
  • You will be able to filter items by a date range relative to now. The syntax will be something like “within: 1d” or “within: -7d”, which would show all items that contain dates during today (from midnight today to midnight tomorrow) and during the past week, respectively.

As mentioned above, we can’t stress enough that this will be our first step to incorporate dates in Dynalist. We know that other things are super important too: date sorting, integration with other calendar applications, task snoozing, etc. The purpose of building it in chunks like this is to adjust early if we make a mistake, and also to put something in your hands as soon as possible.

We might have missed some scenarios or use cases in the design proposed above, so here’s where we need your help. There will be another week before we start to work on this, and until then, please send in your feedback if you have any comments! You can comment below, @ us on Twitter, or send us a message inside Dynalist. Any way of contacting us would be fine. Thanks!

  • skyue


    • 你好,确切的时间我们无法预测,但我们在尽力!

      暂时 Dynalist 在浏览器里也是可以用的,也可以添加到主屏幕,iOS app 需要支持离线编辑,这是我们当前在做的。我们在推特、博客和 Trello 都会更新的。


      • skyue

        多谢提醒,今天试用了下。感觉不错,提个小建议: 如下图,编辑的时候,工具栏始终显示在上方,视线一般都是从上往下,这样遮挡了视线。workflowy是固定放在顶部,感觉也不是非常友好(尤其是大屏幕),跟光标,但是放在光标的下文,会不会好点呢?

        • 我们以前试过放在最底部(键盘上面),但在苹果的设备上因为技术原因做不到。所以我们就做成和苹果自带的菜单差不多位置的地方,见截图1。

          另外也有点模仿很多现在的在线编辑器,比如 Medium 的(见截图2),希望能让用户更习惯。目前还是很少见到放在下面的,所以我们应该不会贸然那么做。等有了 iOS app,也许可以克服网页的技术困难,把菜单直接放在键盘上方,这样按起来比较方便。


  • Nick Wright

    As you suggest, it’s good to make a start with simple building blocks. Clearly one of the next things would be rendering the ISO date in a personal/national style by a setting, with the ISO version ‘underneath’. The punctuation seems fine though I was worried for a moment about Spanish speaking users who sometimes start a sentence with an exclamation mark, but then I remembered it is always upside-down in that position.
    As a complete aside, though related of course, have you thought of providing a macro language interface to Dynalist as a whole? I was prompted to this thought by reflecting on the different styles of dates that people are going to want.

    • Thanks for the feedback! It was very helpful 🙂

      Regarding the macro language interface: it might be an overly complicated solution for formatting dates. We can just let them select a formatting option, which doesn’t require them to know how to code.

      Macros will have other more advanced uses, but it’s too far away from now so I can’t say anything for sure. Very exciting ideas though!

  • Oliver Jakoubek

    Hi – German keyboard here 😉

    Using the ISO format is a good idea, as it’s the only international date standard and (at least for Europeans) far better than “mm/dd/yyyy”.
    If you are working with times please keep in mind that many prefer the 24-hour clock over 12pm/am/whatever. Users should have a setting to configure this (maybe in a future version).

    • No worries about the 24-hour clock! The ISO standard uses the 24-hour clock, so we’ll most likely do the same.

      And yeah, having the 12-hour clock option on the date picker is a good idea. Many people are used to that way. But still, I bet everyone can read a 24-hour clock time. I think in v1.0 we’ll do the 24-hour clock and see if how many people complain about it 🙂

      • Bruce Dillahunty

        Although I would “insist” on 24hour clock, you would probably find most US people can’t deal with 24 hours… unless they have dealt with it in their career or military service, it just isn’t used. I commonly have to convert for people.

        • Well, the date picker would allow them to pick a 12-hour time, so I guess it’s fine for them.

          • Bruce Dillahunty

            I agree… just didn’t want you to get surprised after your “I bet everyone can read a 24-hour clock time” comment if you weren’t familiar with that being a missing component of US folks 🙂

          • I always use 24-hour myself, and I can convert between 12-hour and 24-hour without conscious effort, so I may be thinking from my own perspective a little too much. Not good.

            Thanks a lot of the tip!

  • ninthspace

    Everything you propose seems fine to me. Just a couple of suggestions:

    – Make the time optional
    – Don’t display the time in the long form YYYY-MM-DD format if none is given
    – Add buttons to the date picker for common dates and times, e.g. ‘today’, ‘tomorrow’, ‘next week’, ‘9am’, ’12pm’ etc., e.g.:

    For ‘power’ users, it would be good in the future to allow date-time entry via text, without requiring to invoke the picker, much like Fantastical’s natural language parser.

    • Make the time optional

      A time would still be needed for date filtering purposes. The default time would be midnight, so is that kinda like option?

      Don’t display the time in the long form YYYY-MM-DD format if none is given

      Sorry I’m not sure I understand. If not time is given, date should still be shown, right? HH:MM can be omitted, but I don’t thinik YYYY-MM-DD can be omitted.

      Add buttons to the date picker for common dates and times, e.g. ‘today’, ‘tomorrow’, ‘next week’, ‘9am’, ’12pm’ etc., e.g.:

      Great idea! Just curious, which app is the screenshot taken from?

      For ‘power’ users, it would be good in the future to allow date-time entry via text, without requiring to invoke the picker, much like Fantastical’s natural language parser.

      Yep, definitely. That would be a neat feature for any app that deals with dates.

  • brandon5228

    In my opinion, Todoist has THE best natural language date parser. Check out their examples in the tables here:

    • Hi Brandon,

      Thanks for the input! We’ll definitely take a look when we get to the natural language parsing part in the future.

    • Dimitry Jacobs 

      Agree, hope that can be integrated

      • Got it! Will open a feature request even more and more request for it 🙂

  • EdJr

    Just pasting this here from the discussion at Trello, since Erica asked me to do it (and already replied!):

    Hey, great news! This and the mobile app are the two things that will make me a Dynalist user for life! I wish I’d seen this before. Unfortunately, it seems it’s a little too late for suggestions for this round, but I do have some and I hope they’ll be helpful for future enhancements.

    The first one is about a possible issue. If I understand this correctly, dates will be just plain text so it will be possible to search for, say, `2016` and get all items from 2016. But that also means the search will return *any* item that happens to have the text “2016” even if it’s not a date, right? Not a huge problem in many cases, but it can be annoying if many items happen to include it (many URLs do, for instance). It would be nice if another keyword, such as `d:2016`, constrained the search to only show items with the date markup. Of course, depending on how you decide the syntax will be, this may not be needed.

    Another one is about periods of time. It’s already great that we’ll be able to search for ranges, but it would be awesome if we could also *declare* them. In many cases, events are best visualized as periods of time (“from around 11 AM to 5 PM”) rather than as points (“precisely at 8 AM”). An example where this would prove to be useful is if I must remember an event that starts in January and ends in March. It should appear in the results if I search for all events in February.

    Another interesting feature (for me, but possibly not as much for other people) would be custom “prefixes” – just like tags, but specifically bound to a certain date. For example, if I’m assigned some task, I might add different types of dates to it: When it was assigned, when it’s due, when I’ll start working on it, etc. So I could type something like `due@2016-06-30` (and `assigned@`, `start@`….) and then search for these specific “types”, filtering out the rest.

    I believe there are some possible workarounds to all these issues, but all of them would have too many limitations and gotchas to be useful, so an “official” syntax would definitely make things easier. Just as a side note (not a suggestion), I currently declare dates like this: `@2016-jan-05@20:00`. This way I can search for individual components relatively easily, but, again, with several limitations. I came up with some other rules for shorthands, ranges (basically, `_`) and other stuff, but they’re probably too complicated for the value they add.

    Once again, I really hope this huuge text was of some use. Thanks for the awesome work!

  • Dimitry Jacobs 

    Hopefully we can later in upcoming version an search range of date like Tasks this Week, Task this Month…..