The discussion revolves around the idea of auto-bumping a topic if its title contains today’s date. ChrisBeach proposes this feature to help users find posts about local events on the day they occur.
codinghorror likes the idea but is concerned about potential abuse. david suggests enabling the feature per-category and limiting it to one date or date range per topic to minimize abuse.
However, the implementation is complicated due to varying date formats across different regions and languages. sam points out the challenges in parsing different date formats, while codinghorror proposes a regex-based solution to support a limited set of formats.
mcwumbly and david suggest using a date picker instead, which would be more discoverable and less prone to errors. ChrisBeach proposes an alternative UX, providing a date picker button when a user is entering a date.
The discussion also touches on the idea of linking a Discourse instance to Google Calendar and building a graphical calendar feature. meglio raises concerns about supporting different date formats in other languages.
sam mentions that a similar feature, “timed bumps,” has been implemented in Discourse, which allows admins to set a topic timer to automatically bump at a certain date. The discussion concludes with users bumping the idea and suggesting further development.
On my forum, people post local events weeks or months in advance of the date.
Unfortunately, on the day of the event, the associated post is often long-buried.
It would be handy if Discourse could:
Oh, that’s a neat idea! A nifty form of very lightweight scheduling. I wonder if it could be abused though?
I like this idea - we also have a category on our forum for events, and this kind of interface would be ideal!
I think if it was enabled per-category, and there was only one date (or date range) associated with a topic, then the potential for abuse is fairly minimal?
I think the title would have to include the year? Or maybe just bump if the day and month are in the future, for the current year the topic was created in only?
for a 12 months range from created date, to make it work into the following year.
I think this is a nice case for
The challenge I see here is around parsing,
“11th Feb” vs
“11/2” vs
“2/11” (cause USA) vs
“11-02” vs
“Feb 11” vs
“Feb 11, 2017” vs
“Feb 2 - Come to the maker fair”
“Come to the maker fair - Feb 2”
It is a solvable problem but there is a lot of magic that would need to be added.
I think the first step here would be to build a plugin for it.
I am not that concerned about abuse cause you could simply ban abusers from posting in the category that allows for this magic behavior if you wanted to.
I think a library like this might be a good starting point:
I’d rather see this done with a date picker than use any magic at all.
I think that would also be much more discoverable.
And less prone to breakage with international issues. (Is today 5/8 or 8/5 in your mind?)
That’s the only format I would suggest supporting. Unique enough to not be accidental. The year could be optional, we assume current year unless 4-digit year is provided, e.g.
Feb 11, 2018
Feb 11 2018
Jan 30
Mar 3
So the regex would be
((Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s\d{1,2})(,?\s\d{4})?
And that matches like so
In the UK, and possibly other English speaking countries, these formats are fairly obscure. I would never naturally write a date like that. The day would always go first, like 11th Feb 2018.
I would imagine that across the many languages Discourse is used in, these discrepancies get far harder to cope with.
I agree with @mcwumbly that a date picker would be a good option. I would imagine it is also waaaaaay easier to implement.
If it’s a magic feature, then it needs to support a multitude of formats to allow users to discover it naturally. A date picker is nice and clear, with no confusion (albeit at the expense of some screen real-estate).
Just one data point: I did a quick count of the formats used by our members in recent event listings
Alternative UX suggestion - provide a date picker button when we detect that the user is entering a date.
Fair point then I suggest a 2 pass check. We can also add an “allow two optional word chars after the number” rule to cover 3rd and 11th etc.
Pass one (US English)
((Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec)\s\d{1,2}(\w{2})?)(,?\s\d{4})?
Pass two (other English)
(\d{1,2}(\w{2})?\s(Jan|Feb|Mar|Apr|May|June?|July?|Aug|Sep|Oct|Nov|Dec))(,?\s\d{4})?
Works fine:
It is generally a super mega bad idea to try to “merge” two different regexes like this. Always go with multiple passes, it is far clearer.
I think this is a fantastic idea and would make a great feature / plugin component. I would be in favour of making it use a date picker.
Would be great in future and should be capable of building this into a graphical calendar like the broken calendar plugin that’s out there does.
That’s an excellent idea - I wonder if a Discourse instance could be linked to Google Calendar, and then we can benefit from their UI, and the ability for members to subscribe to this calendar.
As we’re talking about Google Calendar now, I figured I would try all of Sam’s ideas above using Google Calendar’s quick add feature. Any change Google has open sourced this?
Worked (added an event on February 11, 2018):
“11th Feb”
“2/11”
“Feb 11”
“Feb 11, 2017”
“Feb 2 - Come to the maker fair”
“Come to the maker fair - Feb 2”
International issue (added an event on Novermber 2, 2017):
“11/2”
Failed (opened event editor):
“11-02”
What about other languages? The “most used format” might be different.
For instance, nobody ever writes a 3-letter month notation in Russian / Ukrainian. We usually write “6 апреля” (6th of April), or 06.04 (date comes always first).
What? That definitely should not schedule for the following year, especially seeing as this test was done on May 08 2017 - topics talking about recent past events are common.
In general though, this does seem like a good idea, and there’s now support in place with Topic Timers.
That was very likely a typo in my part.
