To those folks saying, "this is easy to code up in JavaScript" or "Pelican already does this for you" -- does it do it for you for other people's content?
I like this because I can just plug in the URL of any old article I might want to read and see what I'm getting myself into, e.g. http://klopets.com/readtime/?url=http://www.newyorker.com/ma.... Now that I know it's a 15 minute read, I'll probably save it for later.
You are right, and thanks for pointing that out. I can generally tell how long it will take to read an article with a little scroll and a glance at the scroll bar. If the scroll bar is small, reading is going to take a while and vice versa.
Great to hear that you have this problem, because in the evenings, I am working on a little extension of Pocket that automatically groups saved links by the length of content :) so it's not only me who has the problem, heh.
I have a lot of quality content marked for later and not knowing how long it is (especially when e.g. commuting to work when I have 10 minutes only) is rather annoying. And managing the list isn't something I fancy doing myself (we have computers for that!).
Drop me an email (in my profile) if you want to talk a bit more about this problem.
Is this specially good? Does it use a better algorithm or something?
Just asking because there's no explanation, and it would be probably better to hack something in JS than to depend on this probably-soon-to-vanish-api. There's already https://eager.io/app/reading-time, for example, which anyone can install in 2 minutes, and is based on a simple algorithm[1], it seems.
Why do we need an API for this? A library seems easier, and even that is a stretch for doing `$wordcount / 200 = minutes required to read`. Does this make an estimate of the article's complexity and adjust how many words a person reads per minute?
We definitely don't need an API. Then again, we basically don't need most APIs. This doesn't estimate the article's complexity as of now, but its main point is not just getting the length of the entire site, but locating the most likely main content area and THEN doing the /250.
You're not the first person to make that kind of mistake, and I assumed it was an obvious enough "attack" that trying to communicate it privately wasn't required.
Though I now have an extra if statement in my code to detect and log this type of 'hacking' attempts in addition to some others, the code was never vulnerable to this in the first place. No file contents are displayed at any time anyway.
There is a plugin[1] for people that blog with Pelican for this. It also will score your Flesch-kincaid[2] values. You can see it in action on my blog: http://caffeineindustries.com/
I do think I should adjust the words per minute values...
It's not showing x minutes AND y seconds, it's x minutes OR y seconds. Minutes is just there for someone who doesn't need precision and can let the API handle the rounding. Seconds is for people who want to do more advanced stuff.
I'm aware of it, thanks. The current approach isn't really that flexible. For example, I've seen the NY Times and The Atlantic not working. I've considered some different potential fixes but haven't implemented them yet. Thanks!
This is just that - a demo right now. I'll most likely keep this as a pet project of mine, trying to make the underlying algorithm a bit more intelligent. I'll then probably release it on GitHub (https://github.com/mklopets).
Thanks for sharing! The point here isn't just calculating the reading time based on a WPM metric, it's fetching a remote page, analyzing it to find the main content and then doing the maths, among other stuff taking into account any images.
I like this because I can just plug in the URL of any old article I might want to read and see what I'm getting myself into, e.g. http://klopets.com/readtime/?url=http://www.newyorker.com/ma.... Now that I know it's a 15 minute read, I'll probably save it for later.
This would be great as a browser plugin.