Open trueberryless opened 4 months ago
Thanks for the suggestion.
Adding a reading time was on my list of things to do, but it's not something I've gotten around to yet. I even thought this was something I wanted to delay until some changes in Starlight but I think I got things mixed up with another feature.
Regarding the features itself, I see a few important points to consider:
Considering it's already possible for users to add this information through overrides, I think it makes sense to address and resolve the above points before implementing this feature.
My 2 cents regarding the points to consider.
- I don't think the reading time should be a frontmatter field but rather automated based on the content.
- This feature would need to be optional, as some people might not want to display it and I've also seen some usage of this plugin that would not benefit from it, e.g. a changelog.
- As optional, should it be enabled by default or not? I'm leaning towards not.
Definitely. I don't have a strong opinion on whether it should be enabled by default, but I'd lean towards not enabling it.
- UI-wise, there are multiple ways to display this information:
- Near the creation date
- Near the title
- Other? May need to do some research on this and see what other people are doing.
FYI, I've done it after the title in this article. I like the final result because it's easy to find and separated from the overall information in the blog post. However, I'd like to highlight that this was not purely a UI choice; it was more practical for me since I have both a guide in pure Starlight and blog posts in Starlight Blog. You can see the guide part here.
- Should this only be visible on the post page or also on the list of posts?
Including this information in the list of posts can be quite useful. For shorter blog posts, readers might choose to read immediately, while posts with a reading time of around 30 minutes might be saved for later.
Please note that it can be inconsistent if we decide to display the reading time after the title.
As a reference, I've created a callout in my guide that lists the reading times for all sub-parts. This approach might offer some valuable ideas for Starlight Blog as well. You can check it out here: Open {re}Source Guide.
Technically, it also means that the reading time rendering should adapt to hours and not only minutes.
I fully agree on all points discussed above. I was thinking about implementing it dynamically with word count or something, but was kinda lazy at first. Nonetheless, it would be very beneficial...
Positioning: Under the title is a great placement, I'd also like to appreciate the idea of the time icon. When exactly do you (@julien-deramond ) mean there could be an inconsistency? In the list of blog posts or somewhere else?
I personally would say, default should be on, but actually I have no idea in how many places people use the plugin, so default off is completely fine of course!
When exactly do you (@julien-deramond ) mean there could be an inconsistency? In the list of blog posts or somewhere else?
Yes exactly. In the list of blog posts, it would probably be weird to be under the title, like it is for the blog post itself. I haven't tested TBH, but it could be maybe better grouped with the other elements. Some UI design to do there, and probably some testing too :)
I don't think the reading time should be a frontmatter field but rather automated based on the content.
I prefer it being calculated too, but a frontmatter override wouldn't be terrible.
See Hugo's ReadingTime for reference.
Is your feature request related to a problem?
Many blog posts have a short timespan given in minutes as a estimated reading time for the whole blog post. This feature would perfectly fit for this project to I think.
Describe the solution you'd like
Add another frontmatter field which is called something like
readingTime
and put the{value}min
next to the creation date or something.Describe alternatives you've considered
No response
Additional Context
I'm willing to create a PR for this.