How Often are Librivox Books Listened To?

[TriciaG]

I would also mention that showing the numbers in brackets does go some way to addressing the issue you raise below, at point 4. If you can see on a book's catalog page that it has the keyterm "history" but that 2447 other books have the same keyterm (and I did just make up that figure), you'd have to be pretty stupid to click the link for that keyword and imagine you were going to be "narrowing down your search".

HA! Quite true!

My thought #3 wasn't very serious. And yes, some readers do have a tome in the summary. When we make covers, sometimes we have to *ahem* make sacrifices to that in order to make it fit in the space!

Having the keywords displayed was, I think, one of the original desires when we redeveloped the site in 2013. So yeah, it should be a desire now. They're certainly a lot less useful (to speak mildly) when they're not accessible

I hope you didn't take my post as discouraging. I'm one of those personality types that takes a new idea and, even if I think it's a good one, I go to work picking it apart to foresee any complications or unforeseen consequences.

[TheBanjo]

I hope you didn't take my post as discouraging. I'm one of those personality types that takes a new idea and, even if I think it's a good one, I go to work picking it apart to foresee any complications or unforeseen consequences.

Not in the least! You've just described my own natural temperament and disposition to a tee. We'd all have been eaten by sabre tooth tigers long ago if there weren't a few of us around to point to those impressive teeth and say "Hang on a minute..."

[InTheDesert]

That would be a lot of programming. I'm not sure it's feasible.

It's actually pretty clean and small.

[TheBanjo]

That would be a lot of programming. I'm not sure it's feasible.

It's actually pretty clean and small.

I agree that it should be technically possible, with enough effort, to achieve the effect you are after — though to be honest I really can't see why you would want to single out this one tiny element (in many cases only a single line long) out of all the other elements on this page for the special game of hide and seek you're proposing. Why stop at hiding keyterms? What about zip file size, say? What about all those different downloading/accessing modes listed on the page? What about Genre? Why single out keyterms alone for such treatment?

As for "pretty clean and small", everything at w3schools is "pretty clean and small". That's quite appropriate, because the site only intends to deliver rudimentary tutorials. I'm not knocking that site at all. I've learned a lot from there over the years - but one of them is that the solutions they offer are only rudimentary, and often need a lot of modification and extension before they're of any use in a realistic scenario.

If you want to see what anyone implementing the kind of "pretty clean and small" solution would actually be up against, please use the option in your browser that allows you to view the source code of the catalog page for any Librivox audiobook. Scroll to the bottom, and you will see several hundred lines of Javascript. That Javascript is a little more complicated than anything you'll see in a w3schools tutorial. Once you've viewed that code, ask yourself (a) how the w3schools "pretty clean and small" solution that seems so apt as a matter of general principle could fit in with what's already there, and (b) how you can be sure that by implementing the w3schools "pretty clean and small" solution you won't be breaking anything that's already working.

If I come across as a bit of a defensive nark in what I've said here, I should apologise right now. I can only say in my defence that the discussion in this most thought-provoking thread have led me to a completely new appreciation of (a) how few resources librivox.org has to fall back upon when it comes to implementing technical changes, and (b) the actual complexity of what's involved in setting up a development environment to try out even seemingly "pretty clean and small" changes for possible incorporation in the live site, and the rather steep learning curve that anyone wanting to step into these waters is likely to face (unless they happen already to be familiar with the architecture of an application like the librivox catalog's). It IS possible to step into these waters with enough determination and effort, I have found — but it's certainly nothing like as simple and easy as your "it's actually pretty clean and small" appears — at least on the surface — to imply.

I do think it's important, though, with limited resources, to focus on things that actually matter — and I don't think hiding keyterms actually does.

[InTheDesert]

The reason I bring it up is that if your keywords proposal is likely not to be implemented because it would increase the page size, hiding the tags and then showing them upon clicking increases the chance that you work doesn't go to waste. Showing and hiding page elements seems a very legimate use of a short chunk of Javascript to me.

I hadn't looked at the long chunk of JS at the end of each page. It looks to me like the advanced search functionality is implemented on every catalog page and the first thing it does is to check whether the current url is https://librivox.org/search which is... an interesting approach. There isn't really a clear distinction between catalog pages and search pages which is why the code seems so busy for a static page. It doesn't look like something chunk of hiding/showing code would break.

Anyway, I don't want to come across as an armchair critic. When I modified an offline version of the page to implement it, it seemed to work fine. But I'm not a web developer so I probably shouldn't wade into these things...

[TheBanjo]

The reason I bring it up is that if your keywords proposal is likely not to be implemented because it would increase the page size, hiding the tags and then showing them upon clicking increases the chance that you work doesn't go to waste. Showing and hiding page elements seems a very legimate use of a short chunk of Javascript to me.

I hadn't looked at the long chunk of JS at the end of each page. It looks to me like the advanced search functionality is implemented on every catalog page and the first thing it does is to check whether the current url is https://librivox.org/search which is... an interesting approach. There isn't really a clear distinction between catalog pages and search pages which is why the code seems so busy for a static page. It doesn't look like something chunk of hiding/showing code would break.

Anyway, I don't want to come across as an armchair critic. When I modified an offline version of the page to implement it, it seemed to work fine. But I'm not a web developer so I probably shouldn't wade into these things...

Thank you! Appreciate your motivation.
For what it's worth, I wouldn't really call myself a web developer either — more, an enthusiastic Librivox reader who just happened to start reading a dangerously provocative and interesting thread....

[TheBanjo]

2. While on your local device, the project count for each keyword comes up quickly, I'd be concerned that it would slow things down on the live server when searching through and compiling results from the entire database, in real time.

I have now done some load testing using a tool called locust, and this testing very much validates the concern you have raised here (although I should state up front that load testing is not a field where I have any experience whatsoever).

In my development environment, the average response time for the web server to deliver a catalog page was 491 ms without any of my code implemented, but 876 ms with my code as I first wrote it: a very significant degradation indeed.

redrun, however, came up with a great idea for addressing this degradation, namely, to count up the number of instances of usage for each keyword in a nightly job, and use those statistics for the next 24 hours, rather than calculating the statistics dynamically each time a user displkays a catalog page.

Under the test scenario I have used, implementing that method dropped the average response time back to a level that is statistically indistinguishable from what we get with no keyword information displayed at all.

For anyone interested in getting into the bowels of this, full details are at https://github.com/LibriVox/librivox-catalog/issues/210