Stabilize Time to Read block

[t-hamano]

The Time to Read block was implemented in #43403 and shipped into the Gutenberg plugin in February 2023, but is not yet bundled with the core.

Issues like #13796, #15350 have been reported related to this block, but all issues labeled with this block are closed and there are no open issues. Therefore, I'm hoping this block will be included in WordPress 6.4.

However, this block relies on the new wp_word_count() function to calculate the number of characters on the server side. A patch has been submitted in the core ticket for this new function, but in order to ship this block in the core, I believe this function needs to be implemented in the core first.

[annezazu]

Wanted to flag this feedback from the 6.4 roadmap from @joedolson:

The “time to read” is something I’m not very comfortable including in core. I have some fundamental reservations about this because the idea that there’s a certain amount of time a post should take to read is inherently ableist. It can create a sense of inadequacy in people who struggle with reading by placing a “normal” value to an experience that real people experience in radically different ways.

@scruffian brought up the idea of a Word Count option instead which might be a better path to pursue for Core.

[t-hamano]

The “time to read” is something I’m not very comfortable including in core. I have some fundamental reservations about this because the idea that there’s a certain amount of time a post should take to read is inherently ableist. It can create a sense of inadequacy in people who struggle with reading by placing a “normal” value to an experience that real people experience in radically different ways.

I can understand this point. However, there is also a Time to Read section in the Document Panel of the post editor. This section was added in #41611. This feature is included in Gutenberg 13.7, so this item has existed since WordPress 6.1.

[torounit]

The same is true for the "Word Count" already included in Gutenberg, but the "Word Count Block" does not work for languages that do not separate words with spaces, such as CJKV.

[scruffian]

What about character count? How does time to read cope with CJKV languages?

[t-hamano]

How does time to read cope with CJKV languages?

This block calculates the number of characters or words, taking into account the site language count type (words | characters_excluding_spaces | characters_including_spaces) first, in order to calculate the reading time. It simply divides that number by the "average rate of reading per minute".

If this block were to be changed to one that only outputs the number of characters or words in the content, I think this could be accomplished by simply removing just the division logic.

Alternatively, it might be a good idea to provide the following UI so that the site creator can change to a count type other than that site language, as shown below.

Also, if it is problematic for this block to enforce "normal" standards, we can provide a UI with variable reading rates as follows.

[joedolson]

I can understand this point. However, there is also a Time to Read section in the Document Panel of the post editor. This section was added in #41611. This feature is included in Gutenberg 13.7, so this item has existed since WordPress 6.1.

Having this data available as a point of reference for content authors and editors is profoundly different from having it present for site visitors. I'm not particularly thrilled with it in the editor, either, but in that context it's only directed at people who are actively working on the document, and can be used as a relative metric to assess the length of your working drafts; the value is more abstract in that context, because the audience is not, in fact, reading the document.

[annezazu]

I think we need more time to determine adding this block to Core and let discussion continue further. Going to punt to 6.5 at this point to focus current efforts.

[t-hamano]

Thanks for the detailed explanation, @joedolson!

I would love to hear from @afercia and @alexstine , who have a deep background in accessibility, about their opinions on this discussion 🙏

[alexstine]

Time to read is always very subjective. It can be based on how much you know about the subject, learning disabilities, ability to consume content, etc. For example, I am sure the time to read wouldn't take into account how fast I can read something at 4X with my screen reader. Not sure word count would even communicate a time to read type feature. I see it as not really an experience improvement.

[afercia]

I can only second what Joe and Alex already pointed out.

The reading time is highly subjective by its own nature. It also varies by age and education level. Such a tool can only vaguely indicate the average reading time, which may not be useful for all users.. Also, I wonder how the algorithm works with languages where a single character represents a whole word or concept.

That said, after some research, it seems there's some data that show length indication is beneficial. Most notably it seems that:

• engagement rates improve
• bounce rate drops down
• time spent on the site increases

WordPress is in the position to set new best practices, when it's beneficial. I wonder if some research and testing could help identify a better way to indicate an article length that is not based on average time.

[t-hamano]

Thank you all for your input. Based on your input, we might be able to make a decision not to ship this block to the core.

If so, will this block remain on the Gutenberg plugin? As far as I know, all blocks that have been developed with the Gutenberg plugin are meant to be shipped to the core, and I'm not aware of any blocks that have been decided not to ship 🤔

[masteradhoc]

@t-hamano i would love to get this block into core. you can see this information on a lot websites and it definately lets the user know in a first place what to expect inside this article. This seems a UX-Improvement for me. If your a fast / slow reader you probably know - and adapt.

I would see it the same as a hiking track - you dont go without an indication. But if your a fast/slow hiker you'll know that it will take you less / more.

I second also @afercia's benefits. Please keep working on this :)

[MaggieCabrera]

I arrived here because I tried to add this block to TT4 but I saw it's still not in core. Hopefully, we can add it to the next default theme then!

[afercia]

I wonder how the algorithm works with languages where a single character represents a whole word or concept.

WordPress is in the position to set new best practices, when it's beneficial. I wonder if some research and testing could help identify a better way to indicate an article length that is not based on average time.

I'd like to point out both the above points are very important.

I'm not sure the average reading time would be appropriate for all languages, as it is mostly based on Western languages.

I wonder how that would work for languages where single characters are either whole concepts (ideographic symbols) or phonetic symbols (syllables). I'm afraid a reading time based on the number of characters would miserably fail in these cases.

I'm not an expert of these languages (although I would love to learn at least some basics) so I'd defer to someone else with better linguistics knowledge than me.

[peteringersoll]

I really don't like the idea of specific times. People read and comprehend at different rates. To imply "If you don't read this in two minutes you are slow" or even worse is unnecessary. Has it been discussed to compromise with description like short, medium, long, very long, etc.? Then we have the indicator without injecting an ability.

[t-hamano]

The WordPress 6.5 beta 1 is scheduled for release on February 13th, so we may want to consider making a decision on this issue.

Personally, I would be happy to see it shipped to Core, as I was involved in the development of this block. However, the consensus among accessibility experts is that this block should not be included in the core. I am of course satisfied with the opinion, so I think it is okay to close this issue.

If you have a user who really needs a block like this, you can enable the Gutenberg plugin or create a custom block.

[masteradhoc]

I'd love to get this further and merged to the next wp version. I see this as a block that people can use in case they want. So people that prefer a solution like "short,long,.." or prefer no times at all dont need to use it.

Minutes will never be exact as everyone is a bit different. But still its a nice hint on how long the article will be.
This leads to a better UX as the user knows what he can expect when he clicks the post.

Just to recap again:
"I would see it the same as a hiking track - you dont go without an indication. But if your a fast/slow hiker you'll know that it will take you less / more."
see #53776 (comment)

Also @afercia's points are quite crucial and i saw this same on some of our client sides. Would be great if this work can be merged.
"That said, after some research, it seems there's some data that show length indication is beneficial. Most notably it seems that:

• engagement rates improve
• bounce rate drops down
• time spent on the site increases"

Thanks @t-hamano

[jamiemarsland]

I would really love to see this in the next wp version - the hiking analogy works for me, and it would be something that would really highlight why folks should try block themes. The https://www.nasa.gov/ is a great example of where it works well.

[peteringersoll]

I've unsuccessfully tried to find actual studies about the improvements. There are articles that state there are studies, but I could not find the studies themselves. Does anyone know where I could find those?

Using the hiking analogy, I think it still follows that there are better ways to indicate the length of an article. Hiking trails around here indicate a length (miles, km), and difficulty (easy/paved, moderate, challenging) - but not time.

[jamiemarsland]

Good points Peter - but for me the number 1 reason to use the time to read block is to encourage people to click and read. Time does this for me whereas number of words, or something vague wouldn't.

[joedolson]

I think that the difficulty with including a number of words is that most people don't know how fast they read, so knowing that an article has 900 words doesn't really tell them anything. A time to read may be horribly inaccurate, but it's easier to understand what it means.

I'm not sure there is any way of providing a measurement that's accurate when we don't know anything about the potential reader, so any value we use has to be considered an approximation.

I like that this block rounds aggressively, ignoring seconds - I wonder if it would be best to switch to math.ceil() so it always rounds up?

Here's an interesting study about reading speed in different languages. This is possibly information we should be taking into consideration - there are some significant differences in these numbers.

[peteringersoll]

I'll bow out. Each site owner can decide whether to use or not use. What I really want to see is real A/B testing to have actual data to demonstrate the value, effectiveness, etc. This topic, and other interface-related topics, often refer to studies - without actually citing those studies so others can understand the data gathering methods. But that's a different discussion. PS. I'd rather see effort going into improving the table block.

[colorful-tones]

I feel like this is plugin territory. I would vote to close this out and not merge.

That is difficult to say, because I know that @t-hamano put effort into this. 🤗

[t-hamano]

Thank you everyone for your opinions.

I think this issue can be removed from the editor task board, or milestone. This issue has been punted once from WP6.4 to 6.5. Deeper discussion and research will be needed to find the ideal approach, so even if we punt it to WP6.6 this time, it will be difficult to make a decision on whether to include it in the core or not, and we might need to punt it further.

I think it's okay to leave this issue open and include it in a milestone when we find a ideal approach to ship to the core. In any case, users who really want to use this block just need to enable the Gutenberg plugin.

[jamiemarsland]

I created a little video about this to get some wider community feedback - the comments are interesting
https://youtu.be/apvDdOb_Vtg?si=R1fZvRLOkSwFMeGp

[masteradhoc]

Thanks @jamiemarsland for the great video!

Just saw the comments and unbelievable how good the feedback is towards the time to read block. Even many people commented that indicate it helps them as indication although they know it will take them slightly longer.

Hope we can push the great work into core soon.

[annezazu]

Thanks for flagging this for the comments! I do want to note that it's not fair to say this has been axed when this is actively under discussion, especially with this new proposal #58773 Just in case anyone else is reading this and think it's been fully "axed". There's more to the story, especially when thinking about core maintained blocks folks can install but that aren't included by default with Core.

[jamiemarsland]

Thanks for clarifying Anne - fyi the context of the video was that it's been axed from the core WordPress install, which it has - hopefully the comments will help in the discussion if the Time to read block is considered for a core supported non core block. A quick follow on question, do you know when the time to read block is scheduled to be removed from the Gutenberg plugin? In my testing today the Time to Read Block is broken in Version 17.9.0 of Gutenberg.

[annezazu]

Update for you all that there's an effort underway to have the time to read block as a canonical block. This is part of a larger effort to have Core created and supported blocks in the block directory that folks can install but don't come bundled into Core. Rather than stabilizing the time to read block, it looks like this is the more viable direction.

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.