No, it provides more.
Actually your brain maps physical properties of the book to actual content, creating an overlay map over the story or the content (and our brain is really good at mentally mapping things). This is that map that is being used to know where in the book a particular piece of information is.
Reading on e-reader is more linear than reading a paper book. See: https://www.scientificamerican.com/article/reading-paper-scr... https://insights.uksg.org/articles/10.1629/uksg.236/ and https://www.theguardian.com/books/2014/aug/19/readers-absorb...
Besides, no e-reader today can let your riffle through pages as fast as paper book.
When you are in a novel, or in a manual, you have some kinetic and touch feedback to build memories of where's what. The book becomes an extension (à la proprioception) with much less friction than an e-read for which you have to wait for visual feedback (screen refreshing).
With paper books things are at the tip of your fingers.
E-reader have more friction.
That's a reason why I only read novels on e-reader and jot notes in a notepad for non-fiction books.
If I had the budget I'd only have physical books.
Any resources detailing this? It's the first I've heard of it.
> Besides, no e-reader today can let your riffle through pages as fast as paper book.
True, though the iPad is actually somewhat faster than a physical book, in my experience.
> you have to wait for visual feedback (screen refreshing).
At least in my experience, the time required to flip a page is at least identical to (greater than, in most cases) that of a modern e-reader showing the next page.
> With paper books things are at the tip of your fingers.
> E-reader have more friction.
I simply can't agree with this. A well indexed ebook is easy to follow cross references in (such as footnotes), you can do an actual search on the content, and the lack of weight is something that can't be understated.
A specific example: I went through the "Physically Based Rendering" book a few years back. I simply can't understate how painful it was to deal with the physical book. It was the size of a large text book (it was a large textbook), heavy enough it never left my desk. More specifically, it was always flat on the desk, making it difficult to read.
It also had glossy pages that, to this day, want to stick together (not to mention being challenging to write on). Finding content in it that wasn't a chapter title included going to a glossary with a ton of page numbers, and flipping back and forth constantly (see comment about sticky pages) to see if page N was the one I was looking for.
There was no 'proprioception' between myself and the book, there was no convenience, there was only inconvenience. Even the authors recognized this, providing a digital copy of most of the code so you wouldn't spend all day typing code.
An e-reader version of the book could only have provided a better experience.
> Any resources detailing this? It's the first I've heard of it.
The link to the guardian article in my previous post has more details and a link to the original study.
> I simply can't agree with this. A well indexed ebook is easy to follow cross references in (such as footnotes), you can do an actual search on the content, and the lack of weight is something that can't be understated.
> A specific example: I went through the "Physically Based Rendering" book a few years back. I simply can't understate how painful it was to deal with the physical book. It was the size of a large text book (it was a large textbook), heavy enough it never left my desk. More specifically, it was always flat on the desk, making it difficult to read.
Apple to oranges. The book you describe is 1200 pages of technical snippets that is largely used as a reference index. It's the perfect example where e-reader outclasses paper book, such is the case for dictionaries and encyclopaedia. I'd even venture to say that a laptop or an iPad would be better than an e-reader considering how important diagrams are in this example.
> Even the authors recognized this, providing a digital copy of most of the code so you wouldn't spend all day typing code.
Providing code for CS book was already common in the 90's when CD-ROM were bundled with books.
That's referencing a fiction novel, whereas you are referencing paper as better for non-fiction (and e-readers better for fiction) - a fairly major distinction.
> The book you describe is 1200 pages of technical snippets that is largely used as a reference index.
Sorry, but you're incorrect on this point. It's an entire physically based rendering literate program, written in such a way as to teach you about PBR in a highly linear fashion (with cross-referencing). It's written to be read from one end to the other.
But you wrote:
> Finding content in it that wasn't a chapter title included going to a glossary with a ton of page numbers, and flipping back and forth constantly (see comment about sticky pages) to see if page N was the one I was looking for.
So either you read it from one end to the other or you used it as reference material (which "(looking) to see if page N was the one I was looking for." strongly indicates).
Frankly, I am not interested in trying to convince you of anything. There are substantial evidences that paper and e-books have different strengths and all you are saying is that the strength I wrote about are wrong because you don't feel like it and your 1200 page monster should be the only point of data to refute what you don't want to agree with.
All the while asking for sources I gave in one of the first post, which tells me you take only what you want from the conversation.
Not interested.
That's a big "if".
My point is that it's not a conscious process, so the book/map isn't replaced by a simple location indicator. The experience of a book isn't reducible in this way.
This sounds a lot like the old "visual/auditory/physical learning" phenomenon to me. Were it truly the case, the old O'Reilly books would be the best possible resources for programmers, and not StackOverflow, blogs, and online programming language documentation.
No, blog posts and online documentation are hardly limited in such a fashion. They cover everything from corner cases to syntax introductions, to setting up the environment. Go, as a single example in a sea of examples, has their entire official getting started and other guides entirely online:
And while SO has recently limited itself to corner cases, it has not always been that way. It has been a resource providing information on culture, machine setups, and "where's the best info on getting started online" for a very long time.
> No, blog posts and online documentation are hardly limited in such a fashion.
I purposefully didn't mention online documentation because it's too easy to make the case that man pages are more often than not too obscure as starting material.
Blog posts don't cover everything. Online doc. does though (that's like... the point).
The way you are trying to build the argument that it's either paper books or online/e-books/blog/SO and there are mutually exclusive won't lead the conversation anywhere (note the usage of the word 'typically').
I am not getting into a cherry-picking argument contest with you. You prefer e-books and online doc and dislike paper books ? Fine by me.
The value provided by a physical map of a book is knowing how far along you are in the book, yet that's also available in a visual form in an ebook as well. You can even riffle through pages on most e-readers as well, seeing a preview of the page as you move quickly forward or backwards.
Aside from weight, what value is the physical map really providing?