Featured Community Plugin - Read it Later
This post is part of a series, featuring the incredible work of plugin authors who grow the TRMNL plugin ecosystem with every contribution. The TRMNL team has individually selected these plugins and authors to be featured.
Read it Later
Community member Brian Seidman created the Read it Later plugin; here are their words on how it was created.
Why did you want this plugin to exist?
I’m continually collecting articles to read. Lately I’ve been trying to convince myself that it’s OK if the number of articles I’ve saved to read is more than the number of articles I ever *will* read, but the unread count in my read-it-later app still bothers me. (Used to be Pocket; I bounced around for a while but landed on Instapaper because it syncs with Kobo.) My TRMNL Read It Later plugin started as something just for me. I use Shortcuts on iOS heavily, and I had the “Get Random Article” Instapaper action for Shortcuts sending an article from my queue to display on my TRMNL with a QR code to open the article on the web. This was an attempt to nudge myself toward reading and clearing articles from my queue by surfacing them on my TRMNL.
Why were you the person to make it?
The Shortcuts basis for Read It Later was already there, and then when I began testing the TRMNL Companion iOS app and its own Shortcuts integration, I saw the opportunity to expand the plugin for a wider audience. Everyone can relate to finding an article online and wanting to save it for later, and having your TRMNL remind you of an article seemed a great use case.My Instapaper shortcut was using the Article object in Shortcuts, which is also presented by sharing any URL from iOS via the Share Sheet, so there were lots of possibilities — the shortcut could be used to send any web article to your TRMNL. It could also be easily integrated with any read-it-later-type service with a Shortcuts action or API to surface saved articles.
Were you inspired by any other recipes or plugin creators?
I was working on the plugin around the time that there were a lot of discussions online about the TRMNL v2 framework and designing for the TRMNL X. My Myers-Briggs Type plugin put the code to generate content into the plugin’s “shared" area, but a lot of the HTML was duplicated between the different layouts, just using different classes. Maybe that's the more straightforward way to go, but I was interested in using the shared layout for all of the HTML code and then the `render` function with variables in each of the layouts to specify CSS classes.User Excuseme's Trending Recipes plugin was an inspiration for that approach, and also Mario from TRMNL opened my eyes to the idea of showing/hiding information based on the layout size — so the full layout has the summary but the quadrant layout just has the title and QR code, for example. I try to make my plugins look good on every screen, all the layouts and orientations on the OG and the X.
How did you balance look vs functionality?
Shortcuts’ Article object will reliably extract the article’s title and URL, but when I was designing the plugin, that felt sparse on the screen, especially for the TRMNL X. I wanted to include an article summary, but unfortunately Shortcuts only offers the article body, and it doesn’t extract that reliably. I ended up using iOS’ built-in AI layer to generate a custom article summary before sending the information to the plugin. One interesting technical problem with Shortcuts and Apple Intelligence: There’s a “Use Model” prompt action, but sometimes this would fail and end the shortcut depending on how well Shortcuts could interpret the article body. There’s also a “Summarize” action to return AI summaries, but sometimes these were so short that the plugin still felt empty. The solution was to have “Summarize” do the first pass on the summary and then to send the summary to “Use Model” to expand or reduce as needed. Using both of those together, I haven’t had the problems that came from using one or the other alone.I set the shortcut so that by default it doesn’t repeat the article title or summary to the user. When I’m using the shortcut to send a random article to TRMNL, this adds a bit of whimsy — the article and summary can be a surprise (and the summary may not be totally accurate, sometimes with funny results). In my GitHub repository (https://github.com/brianseidman/trmnl-read-it-later) I offer directions for modifying these options, but it made a nice package by default — article title, article summary, the QR code, and a few other details.
What, if any, challenges did you face while creating it?
I may have made the Read It Later code too complicated, using a lot of Liquid logic to determine the TRMNL's size and orientation and then applying CSS classes accordingly. For the new plugin I’m working on now, I’m leaning more on CSS cascade, using CSS classes that differ depending on which `screen` class is present at the top. Some additional class prefixes would help me out immensely — not just portrait: and lg:, but vertical, portrait:vertical, lg:vertical, and etc.
Did you learn anything you want to apply to future recipes?
Working with the TRMNL framework on new plugins has challenged me to organize my CSS in different ways. I'm trying to build reusable components especially with the flex class that can be dropped in and modified just by changing the column or row orientation. I’m still iterating on what my default approach is to building TRMNL plugins.
Is there a tip you would give to a new plugin developer?
I think it’s useful to think of plugin components in terms of blocks or sections. Two sections that are side by side in a landscape layout can be stacked in a portrait layout. Also, again, think about entire sections with extra, nonessential details that can be shown on the TRMNL X but hidden on the TRMNL OG. Designing for the different layouts gets a lot simpler when it’s just a matter of showing and hiding elements.
