Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday February 23 2018, @11:11AM   Printer-friendly
from the roar-of-the-dinosaur-publisher dept.

Arnaud Nourry, the CEO of Lagardère Publishing (the parent company of Hachette Book Group), gave an interview to Scroll.in in which he claims, "the eBook is a stupid product."

In the US and UK, the ebook market is about 20% of the total book market, everywhere else it is 5%-7% because in these places the prices never went down to such a level that the ebook market would get significant traction. I think the plateau, or rather slight decline, that we're seeing in the US and UK is not going to reverse. It's the limit of the ebook format. The ebook is a stupid product. It is exactly the same as print, except it's electronic. There is no creativity, no enhancement, no real digital experience. We, as publishers, have not done a great job going digital. We've tried. We've tried enhanced or enriched ebooks – didn't work. We've tried apps, websites with our content – we have one or two successes among a hundred failures. I'm talking about the entire industry. We've not done very well.

For an in-depth explanation of Arnaud Nourry's comments, we go to The Digital Reader:

Hachette's sales are low because Hachette keeps their ebook prices high. If you check the Author Earnings report, you will see that ebooks make up a significant part of the market. And it's not just a tiny group of readers who like ebooks; almost all of romance has gone digital, as well as around half of the SF market.

This guy understands so little about ebooks that it is almost frightening.

[...] They've tried enhanced ebooks, ebook apps, and even ebooks on websites, all because Nourry doesn't understand ebooks as a product. And soon they will be trying video games.

Let me say that again so it sinks in.

The CEO of a major multi-national book publishing conglomerate does not understand his company's products or his company's markets.

This point is so mind-boggling because it is really not that hard to find out why consumers like ebooks: just go ask them.

Consumers like ebooks because we can change the font size. We like ebooks because we can carry a hundred ebooks on a smartphone. We also like being able to search the text, add notes that can later be accessed from a web browser, and easily share those notes with other readers.

Here's an editorial rebuttal from The Guardian:

[...] The built-in, one-tap dictionary is a boon for Will Self fans. And as an author, I'm fascinated by the facility that shows you phrases other readers have highlighted; what is it about this sentence that resonated with dozens of humans? It's an illicit glimpse into the one place even a writer's imagination can never really go: readers' minds. And Kindle's Whispersync facility lets the reader fluidly alternate between reading a book and listening to it. What are these if not enhancements to the reading experience?

And then there's the simplest, most important enhancement of all: on any e-reader, you can enlarge the text. That in itself is a quiet revolution. Page-sniffers who dismiss ebooks out of hand are being unconsciously ableist. For decades the partially sighted were limited to the large print section of their local library, limited to only the usual, bestselling, suspects.

[...] Finally, Nourry claims there is no digital experience. Isn't that the point? If it's got graphics, noise or animation, it's no longer a book – it's a computer game or a movie. Just as I write disconnected from the internet and in silence, I don't want my books to do other stuff. The beauty of the book, in a world of digital noise, is the purity of the reading experience – and there's nothing stupid about that.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by bzipitidoo on Friday February 23 2018, @02:05PM (10 children)

    by bzipitidoo (4388) on Friday February 23 2018, @02:05PM (#642360) Journal

    You've hit on the problem I was going to mention: hierarchical organization. Most file systems are hierarchical. Don't use a file system to organize a book collection, use tags. I've had to learn that lesson the hard way more than once. Thought I'd store the family tree data in HTML, but there were all kinds of problems with that idea, not least the whole hierarchical organization it imposed. Yeah, you can work around the forced hierarchy of file systems with symlinks, but that's ugly. We have suitable tech for these sorts of organization problems: databases.

    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 3, Interesting) by Grishnakh on Friday February 23 2018, @03:40PM (9 children)

    by Grishnakh (2831) on Friday February 23 2018, @03:40PM (#642416)

    We have suitable tech for these sorts of organization problems: databases.

    Which, incidentally, is exactly what a "filesystem" is.

    The problem with your idea (which is presumably to use a relational database to store your ebooks) is that it likely isn't compatible with any e-reader software, and certainly not any hardware e-readers like Kindle (which probably do use a relational database internally, but they don't let you access it or modify anything). This is a pretty good idea for a programming project though: come up with an RDBMS schema for e-books and modify Calibre or something else to work with it as a new FOSS standard.

    The main problem I see with it, though, is that an RDBMS doesn't seem like a terribly efficient way of storing and accessing multi-megabyte ebook files. RDBMSes aren't really meant for storing large blobs of data like that. You'd probably want to store the ebooks in the filesystem somehow, and then use the RDBMS to index them, but now you still have to worry about exactly how to store them in the filesystem: one giant flat directory, or what?

    • (Score: 1, Informative) by Anonymous Coward on Friday February 23 2018, @04:13PM

      by Anonymous Coward on Friday February 23 2018, @04:13PM (#642437)

      With a real filesystem (read as: nothing from mickeysloth qualifies) you don't need symlinks either.

      Just hard link the ebooks into the different locations. Then they physically exist at all those locations, but only one copy of the data exists on disk.

      Now, does Android allow hard links to be created on its filesystems?

      It is Linux based, so the tech is there, but did Google neuter this feature?

    • (Score: 3, Informative) by urza9814 on Friday February 23 2018, @07:32PM (2 children)

      by urza9814 (3954) on Friday February 23 2018, @07:32PM (#642579) Journal

      The main problem I see with it, though, is that an RDBMS doesn't seem like a terribly efficient way of storing and accessing multi-megabyte ebook files. RDBMSes aren't really meant for storing large blobs of data like that. You'd probably want to store the ebooks in the filesystem somehow, and then use the RDBMS to index them, but now you still have to worry about exactly how to store them in the filesystem: one giant flat directory, or what?

      This is not a new or unique challenge. It's been solved already by media players, and the relational index database is exactly what they've done AIUI....with the filesystem storage question being pretty much irrelevant. You can point them at a well organized media folder, you can point them at a folder full of random crap in random folders, you can even point them at your root filesystem...doesn't matter, they'll build a library from whatever they find.

      Just look at iTunes for a common example. You insert a CD, iTunes can rip it, and it'll build it's own hierarchy on your filesystem to store those. Or you can load in a file that's already in your filesystem somewhere, iTunes doesn't care. It doesn't move that file into its existing hierarchy, it just stores the path. Want to sort by genre instead of artist? No problem, all of those fields are in the database, so it's quick and easy to sort by a different column. And once you hit play it checks where the file actually resides and plays it.

      Or look at Plex...Plex can do the same thing with movies, TV shows, and music all at once. It'll show you a list with a title, cover image, and brief synopsis for each one. It'll sort by genre or watched status or artist or title. What's so hard about books? I'd think the biggest problem would be finding a data source -- there's no IMDB for books AFAIK. Then again, I do know there's something like IMDB for music, but I haven't needed to use it in well over a decade. I buy an mp3, and it's got all the information embedded in the file already. EPUB has the ability to include similar tags, although I have no idea if those are actually used in practice. But the capability is all there.

      Maybe I'm missing something as I've never used ebooks...but I cannot comprehend how this is a problem. Is DRM keeping people locked into ebook software with no incentive to improve the features? Are the publishers just too technically inept to include metadata? Or is there some unique challenge with books that I'm just not getting?

      • (Score: 0) by Anonymous Coward on Friday February 23 2018, @07:52PM

        by Anonymous Coward on Friday February 23 2018, @07:52PM (#642592)

        > there's no IMDB for books

        As noted above, the Library of Congress is the master catalog for books, https://www.loc.gov/ [loc.gov]
        When we had a cataloging problem, we fixed it with them and that flowed to all the online book seller catalogs in a short time.

      • (Score: 2) by Grishnakh on Monday February 26 2018, @05:10PM

        by Grishnakh (2831) on Monday February 26 2018, @05:10PM (#644026)

        Maybe I'm missing something as I've never used ebooks...but I cannot comprehend how this is a problem. Is DRM keeping people locked into ebook software with no incentive to improve the features? Are the publishers just too technically inept to include metadata?

        This is probably it.

        You mention iTunes as being able to automatically organize music files, but what about Windows Media Player? Does it do a good job of this? I haven't used it in ages, but I'll bet it doesn't. Now imagine that MS has users locked in with DRMed music that they can only play with WMP. What's anyone going to do about organizing their MS-DRMed music?

    • (Score: 1) by DECbot on Monday February 26 2018, @04:50PM (4 children)

      by DECbot (832) on Monday February 26 2018, @04:50PM (#644015) Journal

      eh, why put the ebook into the database? Have your application store the path to your book repository ~/.myReader/ebooklib/ and then keep a relation database of tags, meta data, file names, and cover images to organize your collection.

      --
      cats~$ sudo chown -R us /home/base
      • (Score: 2) by Grishnakh on Monday February 26 2018, @05:03PM (3 children)

        by Grishnakh (2831) on Monday February 26 2018, @05:03PM (#644023)

        I addressed exactly this point in my last sentence. Do you really want to keep potentially tens of thousands of ebooks in a single, flat directory? I really don't know.

        • (Score: 1) by DECbot on Monday February 26 2018, @07:04PM (2 children)

          by DECbot (832) on Monday February 26 2018, @07:04PM (#644095) Journal

          Me personally, no. But I also don't subscribe to the iTunes method of sorting music.
           
          Speaking of iTunes, the library is not flat--it is artist/album/filename.mp3. Your application can do the similiar author/filename.epub. Then let the database sort out the genre tags and such. Unfortunately, this then requires you to use the application for browsing tags. However, if you know the author, finding your selection is pretty quick.

          --
          cats~$ sudo chown -R us /home/base
          • (Score: 2) by Grishnakh on Monday February 26 2018, @07:37PM (1 child)

            by Grishnakh (2831) on Monday February 26 2018, @07:37PM (#644118)

            Speaking of iTunes, the library is not flat--it is artist/album/filename.mp3

            It is? Many years ago, I had a spouse who had an iPod, and on that thing the music files were all in a single directory IIRC, with some random alphanumeric filenames, and organized by database. There were special FOSS utilities to work with these devices since they never made iTunes for Linux.

            • (Score: 1) by DECbot on Monday February 26 2018, @10:26PM

              by DECbot (832) on Monday February 26 2018, @10:26PM (#644259) Journal

              It's been a long while since I looked at it. I only installed iTunes once to setup an iPod and change the disk formatting from apple to windows (hfs to fat32? can't remember) as the linux drivers only support the windows format. I recall that iTunes had an option on how the hierarchy is structured, but it is very possible that the default structure was flat and I changed it. Again, this was a while ago, before iPhones and such.

              --
              cats~$ sudo chown -R us /home/base