Zenreader: A 4.7" E-Ink RSS Reader
tnhh.net
tnhh.net
It's far less convenient, but just running the articles through Pocket makes for a superior reading experience (particularly on the Kobo), since Pocket will extract and display only the readable text, and avoid the nightmare that is trying to display your average webpage on an e-Ink reader browser.
That said, I'm finding that for Substack, at least, RSS works just fine. You get the whole article, no fuss, and it works the way it should, it's just https://example.substack.com/feed.
I'm pleased to see Substack do most things right. I almost wonder if their pitch deck explicitly said "we will zig every time Medium zagged".
If you'd like to turn partial feeds into full-text versions, the project I work on might help. Doesn't work on all feeds, but will work on many: http://ftr.fivefilters.org/
A huge annoyance for me too. It's infuriating to me that marketing people are continually breaking things like RSS. It's unfortunate that there's no way for users to give negative feedback to people who abuse a protocol and render it less useful to everyone, which is worse than not adopting it at all.
There are some non-commercial blogs with no ads, nothing but text on them, but still giving you only the title in the RSS feeds. I suspect it's the default configuration of whatever software they're using for the blogs, and they may not even be aware that RSS is a thing. Maybe I should start writing mails to them to inquire why that is and maybe change their minds on that, since I really can't see a reason for it.
FWIW Most of the feeds I subscribe to are full-text.
I've heard it's quite simple: the browser was only ever included in the first place as a way to log into public Wi-Fi networks like coffee shops which have a screen you need to log in through.
As long as the browser is good enough to log you in, Amazon's happy. Which is why, after almost 10 years, I think the browser is still labeled as "experimental". (At least last I checked.)
I’d get voicemails (transcribed) and text messages to my Gmail and could text back from there. Gmail even had a lite version that worked quite well on the Kindle’s experimental browser. Fortunately, my needs for making/receiving an actual call on-the-go were nearly non-existent so it worked quite well.
Was really sad when they pulled the plug on the free 3G.
> The ESP32 is a microcontroller that has very little RAM and isn't quite suited to deal with HTML and such. So I had to use a Raspberry Pi as a rendering proxy and transforms the RSS and the text on the page so that the ESP32 can digest.
The Kindle doesn't come with a lot of onboard horsepower, and putting the same class of SoC as a Raspberry Pi in one would likely increase cost and have other tradeoffs.
I picked up an Onyx BOOX a couple of months ago. The stock browser is a slightly modified (and slightly crippled) Chromium fork. Via F-Droid, I've installed Fennec Fox (mobile Firefox), and other browsers are available.
There are some benefits, and compromises, to e-ink displays. Pixels are cheap, paints are expensive, persistence is free, colour is unavailable (well, on grayscale devices, there are now full-colour e-ink displays at not-unreasonable prices).
My biggest persistent gripes are:
- Scrolling on e-ink really is not how you want to navigate, pagination is much preferred. Neither browsers nor most other apps support paginated navigation.
- The assumption that I'm using a palm-sized full-colour emissive display, rather than a monitor-sized, greyscale, reflective one, means that most "mobile-optimised" apps and websites are highly frustrating.
I've inquired in a few places (including HN) about what app design guidelines / practices exist for e-ink. Apparently there are none. This is disheartening.
That probably has a lot to do with the intended audience of e-ink. The most consumer facing application are e-readers, a market that is served by a handful of companies. Most of the remaining applications are commercial.
With respect to guidance, you may want to check out the Mobileread forums. There are a few people who develop software for e-readers there. Notably in the section for Kobo, and likely for other e-readers as well. There are also some open source projects that you can look into. KOReader and Plato come to mind. I also recall a mention of an e-ink guideline in a video by Ralph S Bacon on YouTube, so there is something out there. (Apparently colour e-ink displays should be refreshed at a regular, albeit long, interval in order to maintain image quality.) I realize that most of these source are for palm-sized, or smaller, screens but at least they will understand the physical properties of e-ink.
No doubt.
My own experience, a couple of months using an e-ink device heavily, is that there's a great deal of foregone potential.
Battery life, recharge time, outdoor viewability, overall display quality, and the fact that the devices really are general-purpose / mobile devices (there are Linux, Android, and a few other OS variants out there) means that apps can be tailored to them.
What I like about the BOOX is that it's a pretty good e-reader, and ... somewhat OK Android tablet. That's not faint praise, it's actually "I kinda wish it were a worse tablet so I wouldn't be so distracted by it". Given the present state of mobile device addiction, that could be a fairly broad potential market. Even a small percentage of 4--8 billion is a large number.
Use as a terminal disiplay (using Termux) is surprisingly good. Given that terminals were originally based on teletypes, this isn't entirely surprising.
I'll follow up on your suggestions, thanks.
And can confirm that any e-ink device should be refreshed fairly frequently. The BOOX default is 20 displays, in practice 5--10 would be preferable, though that depends in part on the display mode used (the BOOX has five, from highest quality render to fastest update/paint rate).
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/upda...
In CSS Level 5, "update", "color", and "resolution".
It runs de-googled Android out of the box, so it can run most apps. Some of my other favorite apps to use on it are it's integrated ebook reader with pen support and integrated machine translators, F-Droid, Firefox, Nextcloud to sync my ebook collection with Calibre, and Materialistic for reading HN.
I've also got Twidere for Twitter, Frost for Facebook, Instagram, Telegram, Messenger and Goodreads on it, but I'm trying to wean myself off of those platforms.
reMarkable has a Chrome extention to send stuff to its devices, though it's a bit less seamless.
You don't even have to say goodbye to original firmware, you can just restart into original. Its interface leaves a lot to be desired though.
I don't know, I often find myself having to click random things to find the feature I'm looking for, even having to fall back to DDG a couple of times because I cannot find what I'm looking for.
I save links to Pocket during the day, and in my down time I read them on my Kobo.
Now I’d like to find something as straightforward as the Firefox integration for Pocket to send any page in PDF to my reMarkable tablet.
I'm finding that ... exceedingly poorly suited to e-ink devices, on top of existing Pocket annoyances.
For latter, see: https://old.reddit.com/r/dredmorbius/comments/5x2sfx/pocket_...
Of the listed issues, only find-in-page has been addressed.
It's still not possible to cross-reference articles by tag within the app (this does work on the Web client), nor are tags readily searchable or editable (again, the Web app does somewhat better).
On e-ink, where pixels are cheap but paints are expensive, Pocket suffers greatly from:
- Not providing a persistent scrollbar to indicate position-within-article.
- Not offering pagination as a default, persistent, fixed-render-for-document option. That is, documents are paginated, the pagination is set from the start of the document, not whatever arbitrary point pagination was "flipped" on.
- Access to document annotation features from within the paginated view.
- Ability to add tags directly from selected document text (with an option to edit).
There are other gripes, but Pocket remains immensely frustrating to use in practice, and the more you use it, the worse it gets.
(if you don't like telegram or don't use reMarkable, it also comes with a public rest API to generate epub out of urls)
Would LOVE one of these devices, but unfortunately I don't know if I'll get to have one. Really hope to see more devices that are this form factor in the future. I loved my palm pilot way back when, and would love to be able to replace it.
I feel like this is an unfortunately common take. "If it's not widely used, or pretty, or innovative, it's not worth sharing." Chances are I've seen more duct tape on production code than whatever simple hacks you've done to make the server work.
If it works and it's not going to leak your personal data or credentials, just share it. Anybody who's judging you by the state of your repos clearly doesn't understand that coding is iterative and happens better in the open, and is probably safe to ignore. Even if you never get a single star or MR, it's now out there to at least be something people can learn from. And really, all you've done is increase the chances that you might learn from somebody else, or help somebody else out.
But I guess you made a good point, here you go :) Welcome to the wonderful world of random code copy-and-pasted from Stackoverflow!
https://gist.github.com/htruong/692b1bca7b94db20051b601c89a4...
...
Just kidding. :)
m5stack has several other example applications in their repo, but I learned a lot from reading their source code in the test app. Their code is quite sane and organized. You just need to be tolerant to their spelling from time to time, I figure English is not their first language (just like me).
I had no idea that Readability.js was available as a standalone library. That’s awesome!
We need more people to take this approach for things they want to share. It makes for a better community.
We as a community also need to do a better job of embracing unpolished projects and emphasizing a “don’t be bashful” approach. I’ve seen far too many hobbiest projects posted here where the comments have nitpicked them apart in a derogatory, non-constructive way.
Absolutely. One thing I've found is that the tone of HNers varies a lot. As you pointed out, many are very constructive ("have you thought about...") while some are more critical ("you don't have ..." or "the UX is horrible").
If more people could work on doing the former, then I think we can create a more constructive environment for people to do this.
In my opinion, work in progress type projects (or "research projects" should have only constructive feedback, while Finished Products(tm) can take a more critical approach to comments.
Nice work regardless!
My use of the iBus was to emulate the CD changer in the trunk (basically just a heartbeat every 7s or so) which allowed me to use that line-in. I also picked up button presses on the bus in order to respond and control audio playback. Tied it all together by using a raspberry pi as a bluetooth sink and command hub between connected phone and the iBus.
"Working on cars" is way different than it was in Grandpas day, but it's nice to know there are still people hacking together cool stuff.
Counterpoint: I applied for a job a few months ago which required a coding sample. I listed a link to a project of mine on GitHub. Rather than commenting on that project, they instead found another repo under the same account -- an open source project I started 6 years ago, but had not returned to since -- and told me they weren't happy with the quality of the code they saw represented there, which killed my application.
I was annoyed. That wasn't a project I had looked at in some time, and I don't feel it represents my best work. It was just a proof of concept that I hoped to later refine. But it cost me an employment opportunity.
I deleted the public repo.
It’s easy to tell someone to share something without understanding there’s usually more harm than good.
Quite honestly, the employers who are out there that would look at code I've put out there, see a bug, and pass up my resume, are the kind of employers I would almost certainly be just wasting time with if I was to work there. So in that sense it probably only does me good too; I get to spend my time at companies that understand the journey, understand differences of opinion and design, and don't expect perfect code that 100% matches their style guide every time.
The reason I write code is not at all exclusively to make money. And the code I use daily is free and open source by probably a factor of 10:1. So I like to give back where I can. I'm not looking to make a buck, but I'm also obviously gonna put my GitHub on my resume because I'd much rather be matched to employers who can observe my approach and appreciate it enough to bring me to the interview stage.
This may sound like perfectionism, but if you have incomplete installation instructions, many of the people currently complaining about lack of code will complain about that instead.
Calibre can also download them and output them to e-pub and push them to your device.
Which already has inspired me to think about doing something similar only for the whole web. I think I could scale it down to be usable on a smart watch too.
It's essentially a complicated script that I run on a server every 24 hours to fetch news from rss lists, and compile them on a (very long!) epub or pdf, complete with index and good typography. It even gets around a few paywalls thanks to a couple tricks, and the output is complete articles with reasonable/good output quality.
I then have a script on my kobo to fetch the daily digest every morning when I open it. On a kindle you could just have a script email the result to it.
Overall I'm really happy with it, it's the perfect solution to read the news for me.
Its a pretty decent way to read a good chunk of the content you find online.
https://shop.m5stack.com/products/m5paper-esp32-development-...
I cannot recommend it enough. I've built some neat stuff, like this device[0] for triggering my door buzzer over the web.
[0] - https://jeremypoole.ca/posts/put-your-door-on-the-internet/
1. Come across interesting long-form articles on the Internet 2. Click the "Save to Pocket" icon in my browser (some time passes) 3. Read these articles on my Kobo e-ink reader using the Pocket app.
It works really well.
I made a (free) very simple RSS reader for Kindle e-ink devices. It works with the built-in web browser.
They’re great devices, and you can even download the Kindle app and read your DRM’d books on them :)
Just had the thought that it could be used as a handheld Gemini Protocol reader. Gemini (or Gopher) being lightweight and text-only could fit really well.
Not a great Pocket support (for example: no highlights), but reading experience is fine.
[0] - https://p2k.co
So not really an RSS reader.
Can't back it up, but I'm pretty sure some online RSS services use the same trick. Makes for a better UX than "click here to read the full story".