The rate limit is 20 calls per minute, and unfortunately, we have to use 7 calls when checking a location.
I intended to aggressively cache the values on that page, but it shouldn’t cache a failure 
I should have a fix out today.
3 Likes
Can we fetch and cache all three values or is it necessarily seven hits per value which inconveniently comes out to 21 calls?
1 Like
For each inbox/later/shortlist/archive/feed/all, there are counts for all/article/email/rss/highlight/note/pdf/epub/tweet/video. The all count includes highlights and notes, which is… well, seems extremely unexpected to me. If I have 5 articles in my inbox, and a bunch of highlights and notes, I would expect the inbox count to be 5.
When we fetch counts, we’re currently fetching counts for inbox articles, inbox emails, inbox rss items, inbox pdfs, inbox epubs, inbox tweets, and inbox videos, then summing them.
We could save a few calls by fetching counts for all inbox items, inbox highlights, and inbox notes, and subtracting them, saving us 4 API calls per logical fetch. This could also let us prefetching inbox, later, shortlist like that all in one fell swoop.
2 Likes
wow. Though with that list of types, not surprised that fetching ‘all’ gives the sum of the other counts, including highlights and notes. More surprising that notes and highlights are the same type of thing as the others in the list.
As you say, fetching all and subtracting highlights and notes could save some calls and also futureproof against them adding additional media types.
1 Like
I reworked the goal creation javascript to work backwards, fetching all and subtracting the things we don’t expect to be part of all. This saves us enough calls that I felt fine being dumber about the rate limiting, and the refetch button is only blocked if there’s an active call in transit. All in all, Readwise goal creation should be more typical.
2 Likes
Officially launched!
1 Like
Thanks for this integration, I love it!
Copying my question to @dreev from the email newsletter per request:
Now that the integration is official, I would love to hear everyone’s opinion on setting up this integration to best support their workflow? I see a couple different approaches for using Reader in this thread, each with its own optimal beeminder integration strategy.
My (fairly new) Reader approach:
-
Inbox: I use inbox for active short and medium length items that I intend to actively work through. I sort it by “last opened, oldest first,” so I try to always make progress on the items I have opened least recently. I think the Beeminder integration of tracking total queue size makes great sense so I don’t overdo the number of items I want to work through actively. I have used this integration for the past week enthusiastically (and without bugs!).
-
Later: I’m struggling a little more with this one. Similar to @philip, this is a catch-all that I anticipate will grow with time. I don’t have a strong desire to have a hard barrier to the number of item stored here, but some mechanism to push me to refresh the oldest items would be nice. I was reminded of the old unofficial Pocket integration, which tracked article-days in the queue; @dreev mentions the downsides of this approach on the blog (Control Systems For Backlogs | Beeminder Blog), but I did like that it gently incentivized me to dispatch the oldest items first (but didn’t mandate it).
For ‘Later’, if/when the API allows, I would also vote for using a ‘+1 for each archived/moved-to-inbox item’ approach, rather than a queue limit. In the meantime, I am just setting the limit high enough that if I reach it I have likely been fairly indiscriminate in capturing and could dispatch/delete a few with ease then change the limit as needed.
- Shortlist: I use this for long-form documents (mostly books in EPUB and PDF form) that I am slowly reading in parallel. I would welcome any suggestions on a metric to auto-beemind these, as neither of the above approaches would seem to work.
3 Likes
(The Readwise Reader API does support tracking reading progress per item.)
To know what metric I’d like to track for something like how you’re using shortlist, I’d first wait to see what breaks down when I “just do it”. Do I end up adding 10 items a day, and only clear out 1 item a week? Do I never ever make progress on any items? Do I never get past 50% on any item?
3 Likes
I had over a hundred items in my Readwise Inbox and I wasn’t making any progress on reading or purging them. I wasn’t using Later at all. I moved all my Inbox items to Later, and set up the integration to slowly whittle-down Later.
I’ll keep adding new items to Inbox. I’m hoping that I’ll just naturally stay on top of the Inbox now that it’s manageable but I suspect it will get out of control again. If so, once I’ve finished my current Later goal, I’ll restart it with a new backlog from the Inbox.
I’m considering beeminding the Inbox separately to force myself to keep it low, but I probably won’t. Some days I might add a lot of articles to it but not have time to read about the same number, but I don’t think that’s “bad” behaviour that “deserves” a derail - it’s just how a read-it-later app is meant to work.
This is all a very rough strategy, but that’s fine for my purposes. Readwise is mostly just for fun / interesting articles, not a critical work tool, so I don’t need a perfect, robust strategy.
I’ve set up filtered views on my Readwise home page to help me manage the Later and Inbox collections. It has these sections in this order:
name: Take Action
description: Articles with action tag. [I apply my “ACTION” tag to any article where I want to investigate it further / make notes / tell someone / etc.]
filter: tag:ACTION
name: Highlighting In Progress
description: Highlighted, not archived, not action-tagged, so assume that more reading/highlighting is needed.
filter: has:highlights AND in__not:archive AND tag__not:ACTION
name: Continue Reading from Inbox
description: Started, not highlighted, in Inbox, not action-tagged, so assume reading is in progress.
filter: progress__gt:5 AND has__not:highlights AND tag__not:ACTION AND in:inbox
name: Continue Reading from Later
description: Started, not highlighted, in Later, not action-tagged, so assume reading is in progress.
filter: progress__gt:5 AND has__not:highlights AND tag__not:ACTION AND in:later
name: Inbox
description: Not started, not highlighted, not archived and not in Later, not action-tagged, so assume have not read at all yet.
filter: progress__lt:5 AND has__not:highlights AND in:inbox AND tag__not:ACTION
name: Later
description: Not started, not highlighted, in Later, not action-tagged, so assume have not read at all yet.
filter: progress__lt:5 AND has__not:highlights AND tag__not:ACTION AND in:later
The idea is that I should work through each of those filtered views in order. Ideally I would:
- handle all Action items first (and then delete or archive them)
- then finish articles that I’ve started highlighting (because they’re likely to be the most interesting/important articles) and archive them
- then finish reading any Inbox items that I’ve already started (to keep the Inbox low)
- then finish any Later items that I’ve already started (to keep my goal on track)
- and only after all that should I start reading the other backlogged Later items or new Inbox items
In practice I often just jump about all over the place with whatever catches my attention, but it was fun to set up all those views. 
6 Likes
Very interesting to reflect on this. For the shortlist I’m limiting the addition of items in a 1-in-1-out fashion, but right now I am feeling a lack of push to make progress consistently. I don’t care as much about the size of the progress, only that progress is being made.
In a sense we are using Inbox and Later in opposite ways, and I agree with this sentiment for my Later queue, which is why I don’t care so much about the size of the queue but that I am making some progress.
Interesting approach! I hadn’t used a filtered view yet, but I like the cascading idea.
Thanks for the insights!
4 Likes