Hacker News new | past | comments | ask | show | jobs | submit login
Is there a point to paginating articles online? (ux.stackexchange.com)
74 points by ivoflipse on May 16, 2012 | hide | past | favorite | 47 comments



Obviously ads. Generally I prefer single page (+ Readability), but was surprised that sometimes I prefer multiple pages. I think it's when they act a bit like chapters, giving you a sense of completion. Maybe it's when the content is dense and/or boring. It also makes it easier to "hold your place", if you need to do something else (like research something in the article). I'm one of those people who highlights text to keep my place on the page (so I have to adblock some sites' JS that hijacks highlighting (e.g. NYTimes)).


I agree with all of this. And I also find, both as a reader and writer, that footnotes come across better if paginated. Of course, on the web you have options like having the footnotes popup on hover or putting them to the left or right margins that aren't really available in print.


Thank you for highlighting the horrible (standards breaking IMHO) behavior on the NYTimes website. I, like you highlight words to keep my place in long articles as I scroll, and that 'feature' of the NYTimes site frustrates me more than any.


From a user perspective, short pages in pagination annoy but recently i started to get annoyed with infinite scrolling, too. The best approach changes with time.


When you said infinite scrolling, I assume you mean content that keeps getting added as you go further down the page (Facebook-style)?

In that case I agree with you, but when it comes to articles the whole article could just as well be loaded instantly, in my opinion.


i mean what you understood, i agree totally with you.


I once worked on a redesign for a site, and one of the sections I worked on was the "photo gallery" section. I had a beautiful JavaScript-based photo gallery which had nice transitions between photos, it was pretty slick and nice and fast. It even degraded to full page-loads if you didn't have JavaScript enabled.

In the end, I had to take out my beautiful JavaScript-based gallery and present the "degraded" experience all the time because after it went live, pageviews dropped "dramatically" and the ad people didn't like that.

In retrospect, I probably could've just refreshed the ads via JavaScript when I transitioned to a different photo, but the potential drop in ad revenue meant I was having to work quickly...


In retrospect, I probably could've just refreshed the ads via JavaScript when I transitioned to a different photo

Dynamically refreshing ads usually is not allowed with ad networks, since it can be abused to inflate adviews. For example, look at the AdSense policy:

https://support.google.com/adsense/bin/answer.py?hl=en&a...

"Any method that artificially generates clicks or impressions on your Google ads is strictly prohibited. These prohibited methods include, but are not limited to, repeated manual clicks or impressions, automated click and impression generating tools and the use of robots or deceptive software. "

Whether or not using javascript falls under the category of "impression generating tools" is probably open for discussion, but I wouldn't be surprised if Google didn't like this.


FWIW, GMail loads a new ad when I open an email.


This is true and a good point.

But obviously Google gets to call the shots with their own services. They only answer to their customers, who aren't whining about this.


Yeah, I would think updating ads based on a user click is fine, whether that click is a full page reload or a javascript partial page refresh. But ad networks can be pretty capricious so who knows.


Would it be acceptable to load a new segment of HTML, which includes an img tag and a new ad? You can prefetch the image.


I am in no way an expert in this area. All I know is that the TOSes of ad networks are usually vague but very strict in this area, because of fears of abuse. You should probably talk to your account manager to get an exception / clearance prior to releasing code that dynamically refreshes ads via javascript.


When I talked to ad networks about this, almost all of them would not let us use any method to refresh ads without the user generating a new pageview, even though our users would spend many hours on the same page.


Photo galleries / "Top N Xes for Y" stories which are nothing but link bait -- I lay tracks blasting away from that crap.


Just a heads-up for any Chrome users out there who aren't aware; AutoPatchWork does wonders for eliminating the annoyance of pagination...

https://chrome.google.com/webstore/detail/aeolcjbaammbkgaiag...


Wow. Thanks. Works great.

One question I always have adding these chrome plugins though: when it says "[plugin] can access all your browsing activity", how do I know whether it is (or isn't) sending all of my browsing activity to someone without my knowledge/permission? I wish chrome plugins provided more information on this.


Short of reading the source code for the plugin, you can't know for sure. That's why Chrome just warns you that it can access your browsing activity, that's all you can know. You have to decide whether or not you trust the plugin author with that access.

Assuming (a) the plugin can access your data and (b) the plugin can communicate with some external system, there is no way* to either prohibit the plugin from sending your data to that external system or universally detect that it is doign it.

* No technical way. Of course you can use contracts, TOS, & other legal methods.


I worked as a contract developer for a media website for a couple years. The top priority in all decisions was how to increase ad revenue, since this was their one source of income. If it was a choice of usability or page views taking precedence, page views would win every time.

Increasing page views (like mentioned in this article) was important to them because:

1) It increased the opportunity to feed ads and generate more revenue.

2) Part of their valuation was based on page views, so if they were to be acquired, this improved their valuation.

Unfortunately, usability was often hurt in the process.


In the long term, wouldn't usability increase page views?


How much (if at all) were uniques v. pageviews taken into account? Was it better to have 10,000 people visit the site twice a day or 2,000 people ten times a day?


Ads or not, I just can't stomach reading long non-paginated articles on mobile. Safari mobile rarely keeps view-state when I come back. Without a decent scroll mechanism, it's a lot of finger flicking to try to remember where I was when reading a long article. Pagination lets me bookmark where I left off on longer articles.


I've found that especially in Mobile browsing, the pagination ends up offering little advantage to anyone, beyond statistics. Mobile versions of news sites will often not have ads, only a small header, the text and the pagination links, so I'm not sure why they would continue to use the technique.

On top of this, I find it very irritating when reading a paginated news article that split to a new page right smack in the middle of a sentence. And it's happened more often than I'd care to remember.


Not from a readers perspective. It's annoying.


It would be better if the IAB et al used uniques + time-on-site, rather than raw pageviews/impressions. Most medium-to-high-traffic sites have effectively infinite inventory, and some portion of that almost always gets sold as remainder.

For pagination, why not count a scroll-down (and thus viewing of an extra ad further down the page?) as a pageview? Or, again, time-on-site or time-on-page or something that better reflects user attention.


From a user interface perspective, paging has one great benefit. It provides structure, especially to long texts with no images or layout cues. Think of it as an extended version of the paragraph: a tool of composition that gives readers subtle navigation cues within a text.

If paging means more load time, bad results in search or the like, that's obviously a bad thing.


Pagination feels like it was one of those things born out of need by computational limitations, and then was taken as "just the way things are" by designers.

In a world of infinite computing resources, I see no reason to provide multiple pages at all. Designs can accommodate the data to make it work nicely for the end user.


Pagination -- from a user's perspective -- has nothing todo with computation.

To appreciate what pagination does, just imagine a 500 page book. Now imagine having to read it on an ancient scroll. Pages make it easier for our brains to segment the information of a book or a long article by giving us a higher order rhythm within the content.

Or just take it one step further: why not eliminate line breaks? They're just as arbitrary as page breaks and there is no technical limitation on horizontal scrolling. But again, segmentation helps to form a mental model of the content.


A common way to break the flow of long pages of text is to encapsulate sections within boxes, so to speak. You've probably seen this in word processors, or PDF viewers, to name a couple of prevalent examples.

This also is how many of the popular "reader" applications display the paginated content, and there is no reason a web page couldn't be designed that way from the beginning as well. Or, with the number of amazing designers out there, maybe something completely different.

I agree breaks are important, I'm just not sure multi-request pagination is the best interface for that. We only accept it because it is often necessary due to computing limitations.


I dislike the page metaphor, because, at least in PDFs and most word processors, it means that the page is a fixed width and the text won't reflow to fit my window. If I zoom in, I have to scroll left and right as I read each line! Very annoying.


What are the user click results of displaying the pagination as shown with the "Full story" option?

Maybe this is one of those things where the obvious answer isn't what users actually do or prefer for some reason.


This reminds me of the "life below 600 px" story from last week [1]. So yes, there is a reason to do multi-page content from that point of view.

Unfortunately, it's used as a cheap trick to smear limited content over pages that are riddled with ads. I hope the folks who promote this realise they're making visitors become immune to ads. Anyone remember that television layout from "Idiocracy"?

[1] http://news.ycombinator.com/item?id=3242670

edit:link


Most of these sites will have very detailed monitoring of performance/revenue generated by their ads. In all likelihood they've A/B tested ad impressions, clicks, conversions, and revenue generated by a single-page article versus the same on a paginated article, and discovered that (intuitively) spreading the content out over multiple pages with more opportunities to display ads gives better results. Maybe it's only marginally better, but in the world of online advertising even the tiniest improvement in conversions can mean huge changes in revenue when you throw enough users at it. The fact that some users may be annoyed by or made "immune" to ads is moot. They'll go where the money is.


The only reason is to inspire people to write Readability and similar addons. And another reason is to inspire people to create adtrash-free sites.


I worked on the redesign of a business news site and there were a fair number of vocal readers who really preferred paginating long articles.

Maybe it would be different today since everyone is using fixed headers and footers and sidebars that follow you, but if those aren't present it kinda sucks for the reader to get to the bottom of a long page and having to scroll way back up to find a nav bar.


Yes, you can link directly to a set of results. And if you go the route of sites like Kickstarter that automagically update the URL as you scroll, you still avoid having to load unintended content when you reload it for that set of results.


If you click full story or next page, it allows the site to know how much you read.


This is also possible via scroll position sampling, but it requires a bit more technology.


Is there a good library for that? It would be a major pain to roll your own cross-browser scrollbar sampling code that could correctly tell you what text was on the screen at each sample (compensating for different layout engines, fonts, browser sizes, and zoom levels)


That requires JavaScript to be enabled, which limits it a bit.


google encourages pagination with their 3 ads/page limit. seems like the limit should be based on quantity of content, not a per page metric.


So, does n readers * m pages * 3 ads really matter significantly vs. 3m pages?

On a net conversion basis, do the extra impressions matter, or is this all stuff that people just filter (banner blindness, adblock, whatever) anyway?


Does CPC increase with pagination or only CPI? Why are advertisers still buying on CPI and not CPC?


Website owners don't like CPC because the advertisers try to push branded ads that don't ask for a click (essentially free advertising). It was only with the advent of Adsense that CPC became acceptable due to super efficient targeting, and even then it's often used as a last resort to fill unsold space.

Advertisers want CPC/CPA because it allows them to sit back and get the publishers to do the work, whereas CPM allows the publisher to concentrate on their website's content rather than targeting someone else's ads.


I don't think anyone is purchasing on CPI anymore. What happens is with the multiple pageviews the odds of a click go up. It's not linear, so you won't get 3x the revenue on a 3-page article v. a 1-page article, but it's still an increase.

I've found Cracked is pretty bad with this. "Oh, you wanted to look at a Top 10 list? Here it is over 4 pages."


this is completely incorrect. the majority of (non-adsense) ads are still sold on a CPM impression basis. the rates you get will be better if you have a solid click through rate, however.


More page views.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: