Comment by dredmorbius | Hacker News Reader

Comment by dredmorbius | Hacker News Reader

Parent Full thread

Jack: I just wanted to say that this is awesome, that you're echoing a lot of my own thoughts, and that I'm dying to see this as a browser extension or something integrated into Einkbro directly (I've been a fan of that for years now myself).

I wrote a set of design principles for e-ink displays back in 2022. You especially address #6, of course:

1. Persistence is free

2. Paints are expensive

3. Refreshes are slow

4. Colours are very limited or nonexistent

5. Line art displays beautifully. Raster images not so much

6. Pagination navigation is strongly preferred to scroll

7. Graphics are reflective rather than emissive

8. Touch / Wacom may exist

9. Feature detection capabilities are limited

<https://diaspora.glasswings.com/posts/638a8d10e041013afba844...>

On power consumption: informally comparing battery usage under a web browser (Einkbro) and an ebook reader (NeoReader) on my Onyx BOOX Max Lumi, browser draw is about 10x that of the ebook reader.. It's much more efficient to have fixed layout and limited screen paints.

I've been toying with a vaguely-related project of generating a newspaper-like presentation of news site(s), described and imaged here: <https://toot.cat/@dredmorbius/114356066459105122>. The main commonality is in creating a calmed interface though it's principally a standalone generator rather than an in-browser JS application.

I'd like to try integrating eInk Mode to that page to see how they work together. (I have some concerns given my use of grid + column layouts, but want to give it a shot.)

Wow, I'm really glad someone can echo my thoughts too. Actually, back in 2021, I proposed building a software ecosystem for E Ink displays. The article is right here: [https://jackscogito.blogspot.com/2022/05/the-necessity-of-es...] (This article was rewritten in English in 2022.) And some of your design principles resonate with mine, but yours are more concise and clearly highlight the characteristics of E Ink displays.

Also, your newspaper demo looks fantastic. I think it would be perfect for viewing on a 25.1-inch E Ink display in portrait mode; the effect must be excellent. However, I'm concerned you might encounter difficulties applying Eink Mode to it, as I'm currently grappling with the pagination algorithms for Table, grid, and flex layouts, which are proving quite challenging.

It's a bit jarring having my (usually prolix) writing described as "concise", but thanks. From your "Necessity" article, the point about minimising any ancillary screen elements is another that I strongly support. I'll almost always hide system menus and even the Onyx BOOX navigation ball when I'm reading in depth.

As much as EinkBro's paginated navigation is an improvement over scrolling (to the extent that I keep trying to navigate other apps similarly, and am disappointed), eInk Mode's more complete pagination is a huge step up from that.

I'm admittedly biased, but the newspaper layout really is calming, and looks great on my 13.3" Max Lumi. I'm also viewing it on an iMac 27" display, windowed, full-screen, and resized smaller. A large eInk display would make a cool demo.

For a static or paginated display it's possible to reduce the lede context (displayed story paragraphs) to include more headlines within a single page, or so that each page shows most of a sections' content. I've though of having an automatically-advancing display as well, though sorting how to do that through a Web browser might be challenging (a sequence of URLs most likely).

But yeah, I'm having fun and would like to incorporate your tool into this.

Actually, I know EinkBro's author, Daniel Kao, and I intend to contact him about potentially integrating this module. Four years ago, I proposed and demonstrated the pagination concept to him, leading to discussions that eventually resulted in his release of the first public version of EinkBro. I've been a dedicated EinkBro user ever since.

I'm going to advocate for this as well.

I've mostly interacted with Daniel through GitHub. My most recently implemented suggestion was to provide margins for EinkBro's Reader Mode:

<https://github.com/plateaukao/einkbro/issues/33>

eInkMode would be a much-desired further improvement.

Thank you very much! I need to correct my words, because your newspaper doesn’t contain images, so I think you can use Eink mode for grid or flex layouts without any problems.

I've been thinking through approaches though I haven't yet attempted incorporating eInk Mode yet.

My basic document model is:

  <header>
  <main (flex layout)>
    <nav>
      <.headlines-nav (column layout)>
    <.sections>
      <section>
        <article>
        <article> ...
      <section>
        <article>
        <article> ...
      ...
 </main>
 <footer>

The headlines-nav is effectively a table of contents, and should be preserved as part of the main document. The header and footer can be treated as preliminary and terminal content. I think it makes sense to think of the <sections> as chapters or sections of the document, probably with page breaks. After that, a media query for positioning the articles within each section should make sense.

I've been talking to someone who'd prefer a printed-out version of the page (motor-neural limitations), and this might be one path toward that.

FWIW, I've considered adding images to the output, though in general I find these don't add much, and in fact frequently detract from, actual content. I've done some manual edits to add in images on a few instances. Automating that process of selection and incorporation is another challenge of course.

Reply on news.ycombinator.com