Considerations for the current Event content type

[mandclu]

As someone who has had a lot of conversations with site builders working with dates and times over the years, I thought I would share so initial reactions from the current Event content type in the Starshot prototype:

• a common requirement is a view that list upcoming events, typically ordered by start date (ascending). Often there is a companion display of past events, and a block display of the upcoming events. I would suggest that this be included in the recipe
• currently the date field is last in the form, even though it is the only required field, and often one of the most important data points for an event. I would suggest that the date field be first both in the form and the display
• personally I prefer to call the date field "When" to more explicitly communicate the relevance, but this is a very minor point
• the prototype currently uses the "default" Smart Date widget, even though for legacy reasons the Smart Date module actually defaults to a newer version, the Inline widget, designed to resemble popular calendar software
• currently the date field provides no default value, which means that all of the start date and time pieces need to be manually provided a value, even if zero. If the field was a Smart Date field instead of a datetime range field, it could use a "next hour" default, which often reduces the amount of input required and also aligns with how popular calendar software tends to work
• using a Smart Date field would also allow for managing timezones and/or recurring dates with just a few configuration changes (particularly if the field allowed unlimited values by default, though the empty field set can be hidden on first load)

I'd be happy to provide a PR for any or all of the suggestions above, but thought I would gauge the level of interest/agreement first

[phenaproxima]

a common requirement is a view that list upcoming events, typically ordered by start date (ascending). Often there is a companion display of past events, and a block display of the upcoming events. I would suggest that this be included in the recipe

I think that's a great idea - let's also expose a link in the main menu. I'd happily merge a PR for this, if you submit one. Let's have the starshot_event_content_type recipe package all of this up so that it just works as soon as you apply the recipe.

currently the date field is last in the form, even though it is the only required field, and often one of the most important data points for an event. I would suggest that the date field be first both in the form and the display

Happy to consider a PR for this. Can you make a separate PR, though, so that I can see the result on Tugboat before merging?

personally I prefer to call the date field "When" to more explicitly communicate the relevance, but this is a very minor point

Let's leave this as-is for now; it's trivial to rename.

the prototype currently uses the "default" Smart Date widget, even though for legacy reasons the Smart Date module actually defaults to a newer version, the Inline widget, designed to resemble popular calendar software

😲 I didn't even realize this! By all means, let's have a PR for this.

currently the date field provides no default value, which means that all of the start date and time pieces need to be manually provided a value, even if zero. If the field was a Smart Date field instead of a datetime range field, it could use a "next hour" default, which often reduces the amount of input required and also aligns with how popular calendar software tends to work

💯 agreed on a default value of "now". Can you submit a PR?

I think these are all common sense no-brainer improvements, and I don't think we need to wait for broad agreement to merge these things.

[mandclu]

Sounds great, I can work on some PRs for these. It sounds like we need three:

• Add a view with a couple of displays
• Change to the inline widget
• Change to a Smart Date field and set the default to "next hour"

Is there a preference on the order in which I work on these?

[phenaproxima]

No preference, no deadline. :) Whatever you do, is appreciated!

[simesy]

I supprot smart date and we should use the recurring field in it to avoid this issue being a blocker (to me, probably not that critical):
https://www.drupal.org/project/drupal/issues/2794481

[timplunkett]

Let's continue discussion on https://www.drupal.org/project/starshot/issues/3454547 (and any sub-issues)

[TravisCarden]

• Related: Node paths falsely imply hackable URLs #133