On Wordpress I use a plugin called Post Teaser, which shows up on the front index page under each article summary. The article summary has a couple of sentences and maybe the first graphic. The added Post Teaser has a word count, estimated amount of time to read it as well as the number of graphics. This might be what you are looking for?

There is no need to define short, medium or long articles. These are somewhat arbitrary.

If you can add css to your code you can use an accordion to hide some of the longer content until the user hits a button.

The wp pluggin seems okay, I'm not sure if this will be of much use if the users are landing on the article page directly. I disagree with T.Boy in regards to the accordion, these is no real point for it. If it is a long article, then its long, hiding it doesn't really address the downside of the length.

The biggest issue with a really long article, with 42 photos is the page load time. I would recommend paginating the article such that it can be loaded progressively. Then on the first page you can show the length, time, number of pages and a TL,DR summary. Then if the user is interested, they will invest the time and bandwidth to consume the content, page by page.

The effect on traffic should be positive, faster load time will likely result in better ranking, server load should go down, and bounce rate should almost certainly go down but I wouldn't see this a positive or negative. It simply reflects that people interested in the article will read the next page, so no bounce. Those not interested will bounce. Whereas before everyone "bounced" readers and non-readers alike (assuming that all they did was read and leave). The indirect benefit is you will have a better idea of how interested users really are.

I have noticed that some smartphone browsers such as Opera Mini, they auto-paginate for you. They do not download the whole page, so will not fully download the 42 images until the user scrolls down. I have seen this in my log as well.

Some of the Indian smartphone browsers, specifically the one from Tencent, has an option to not download any images at all. This is beneficial in the Indian market. The downside is that all your info is also transmitted to Tencent's China offices.

It is not so much the length of the article as the attention span of the user. Looking at my logs I see two kinds, those that have one and those that do not, and the latter out number the former 10 to 1.

How to articles must be as long as necessary to get the job done, but if it can be condensed to the shortest possible you'll likely have satisfied users. 42 images seems extreme (I could be wrong), if that can be reduced to 15 or less you'll be better off.

Time is what users are concerned with, not how many words or how many pages. Bear in mind mobile is becoming the defacto device for web browsing and all that means in delivery of content, viewing, and user interaction to complete the task.

Reading time is subjective, but providing that info (averaged) is likely to be more instructive to the user than word count or file(s) size.

Thanks for the input. I have read several places that nowadays people don't like paginated articles...They would rather scroll. The hobby I cover is fairly technical, so the 42 pages were necessary for the article...there were a lot of small steps. The same is true for attention span. I can't imagine anyone with a limited attention span having the ability to focus enough to be interested in a complex subject.

If I were to indicate reading time, where would be the best place to put the indicator. I would want it to show up on SE returns. If someone could see it there, and they were concerned about band-width, they just wouldn't choose it. I would say that about 20% of my articles would be in the longest category...I'm also concerned about reducing overall traffic. I guess, though, that if readers were forewarned, my bounce rate would improve.

Thanks again.

If this is a hobby site with many detailed steps users should be looking at your site on a computer and not a smartphone, then it may not matter how long the article, provided they are interested and the photos are detailed enough for them to see.

I have read several places that nowadays people don't like paginated articles...They would rather scroll.

Whether the user clicks a button or the content is loaded after scrolling to some point, is somewhat secondary. You choose what works best for you and your users. The point is to load the content progressively such that the users does not have to wait while a bunch of stuff that he/she doesn't want loads.

@T.Boy it really depends on the hobby, say your fixing a car or bike or some of that nature, it may be far more practical to follow along on a phone or tablet.

For a really serious hobby the content will get SAVED and PRINTED out. :)

That said, if there are many little steps to completion, is there not a series of steps that has to occur FIRST and another set that occurs SECOND? etc. Long content can be (and often SHOULD) be broken up into logical sections.

I'm one of those "want it all at once" kind of fellows. My brother is the opposite, he likes it in sections. Takes all kinds. But @NickMNS has it most correct: time to serve the content is often the ruling factor for user satisfaction.

One suggestion...have a table of contents with jump links to specific sections of your page. I do that on my long articles (3k to 5k words) and it seems to work well. Average time spent on my longer pages averages around 4-5 minutes or so, so it seems to work without the lengthy articles scaring too many people away.

In-page navigation is very helpful for longer articles - albeit sometimes a pain to setup.

I have read several places that nowadays people don't like paginated articles...They would rather scroll.

If that were true, the big news sites would not paginate; they all do.

Just for the record, the NY Times doesn't paginate, but their articles are text heavy, no photos, so they load quickly. After doing a search on Google, it seems about half of comments (usually in forums) favor scrolling over pagination. I think this may be a cell phone thing.

For what it's worth, even on desktop computers I prefer scrolling over pagination. I personally have come to dislike articles divided up over multiple pages. But that's just me.

As for what I see as a webmaster, I think longer pages are better than multiple short pages not just in terms of useability but also user engagement. Until recently, I had many articles that were paginated across 5+ pages. The first page always had the highest page views, and then it dropped off precipitously beyond that. The 2nd page tended to have half the page views as the first page. The third page tended to drop again by half, etc...

The result was that the last two pages were hardly ever looked at.

Since I combined those paginated articles into one long article (ranging from 3K to 5K words), average time spent on page has nearly tripled.

@jimh009 - when I use the term "pagination" I am not referring to "articles divided up over multiple pages" but hidden texts usually done with JS or Ajax or in some cases jQuery.

The reader gets a paragraph or two loaded quickly, then if they wish to continue they press/click a button or text link and another portion of content displays.

IMO this works best for mobile phones.

The reader gets a paragraph or two loaded quickly, then if they wish to continue they press/click a button or text link and another portion of content displays.

I've thought about using something like that on some pages, but I'm not clear about it.

Is that content preloaded and just not displayed, or is it load upon the click?

Preloaded

The browser renders the entire page of code/content, then displays on command.

The reader gets a paragraph or two loaded quickly, then if they wish to continue they press/click a button or text link and another portion of content displays.

This is called an accordion [w3schools.com...] or bootstrap collapse [w3schools.com...]

Try it.

There are different approaches. You can use the accordion method proposed to T.boy or you can use AJAX to load the data after. The accordion method is the simplest but is only a UI feature, the content is loaded with the initial page request and then simply hidden from view.

When using AJAX, the content isn't loaded. Some event triggers (eg: click on button or scroll to some point) an additional request to the server, and the content is returned typical as JSON and the added to the page using JS. This is the most beneficial in terms of improving page speed, but is far more involved in terms of implementation. The biggest issue is that since the content is not present at page load Google-bot will not see it and thus cannot index it. To get the content indexed, one needs to use the history API in JS, more specifically pushState() to change the URL and then be sure that if one navigates to that URL directly that one gets the same content, in which case Googlebot will be able to follow the links and crawl the content.

I just converted my site to this pattern and I am really happy with the results. I have seen a big improvement in many key metrics like time on page and AVV. But there are many little issue to deal with so this is not for the faint of heart.

The biggest problem is deciding what is a long article. On today's web the load speed of TEXT is the least of the problem. Also depends on the kind of content and the intended audience. For some topics 20k words is a short article.

I always view any action (beyond scrolling) needed by the user as a distraction to the user, and an break point of decision to proceed or not. If the scroll continues, and the reader is scrolling, they just might stay for the whole presentation. Give them a moment to think otherwise and you might lose them.