Live data from Hacker News

Ask HN: In your experience, what are sound conventions for e-ink UI development?

news.ycombinator.com

71–76 of 76 posts

Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?

#71

TRMNL recently open sourced a CSS framework made specifically for ePaper display [1], you can use the opensource firmware[2] and quickly hack together a good solution using off the self components. Disclosure: I work at TRMNL. [1] https://github.com/usetrmnl/trmnl-framework [2] https://github.com/usetrmnl/trmnl-firmware

I responded to one of your surveys: dive in to supporting "xbox + index.html + trmnl.js" as a BYOD / demo target! s/xbox/raspbpi/...etc... I've got extra monitors and RPI's dangling around, and it's not out of the question to splash $50 for a BYOD license and get a "free" TRMNL display that I could have running during daylight hours, or wired to a smart outlet or something?

Also: wouldn't it be great to have an "advanced" timeline customizer, eg: lambda-ish functions? (this I didn't bother sending to y'all...)

I've generally got mine wired to `Calender(15m) => Weather(5m) => Calendar(15m) => MotivationalQuote(5m) => Calendar(15m) => ...etc...`, but that's extremely gross (as you can imagine) with a bunch of `Calendar (copy) (copy) ...` because I can't be bothered to spend time fixing it up.

Thinking it through, I'd kindof like "primary queue (15m)" vs "secondary queue(5m)" and have "the algorithm" automatically merge them at runtime (ie: two pointer heads as you alternate queues), but the end game is effectively:

    def next_card(handle):
        if handle.time.hour == "12:00":
            return ( "Lunch Break", "30m" )
        elif handle.time % 60 == 0:
            return ( "Calendar", "15m" )
        else:
            return ( handle.plugins.shuffle()[0], "5m" )
        ...etc...
<3 ... the AI stuff looks tasteful + cool, please thank your support staff, and excited to see where y'all end up going! (Reminds me, need to figure out the supposed firmware update...)

Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?

#72

Spitballing an idea. I don’t use e-ink stuff but had my hands on it back when personal readers were new to the market. When scrolling arbitrary text on a computer via keyboard, I generally become mildly frustrated hitting Spacebar, PageUp, and/or PageDown because I lose continuity with what I’m reading. (Perhaps the momentary 60hz blur makes it worse?) I attribute that to having a hard time identifying where I last r…

I used Oberon [1] in school, and it had a bunch of funky UI ideas. One I liked it if you clicked on the scrollbar then it would scroll that position to the top. Like if you click the exact middle of the scrollbar then it would scroll up exactly half a page. Right click went the opposite direction, and middle click went to an absolute position. When reading that means you can choose a paragraph as the break point, cli…

In some cases (linux) you can middle click the scroll bar to jump to that position. Do some searches for "gnome xwindows scrollbar warp" for more references.

Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?

#73
I love this question. Most eink UIs feel like they just took interaction patterns from smartphones and crammed them in. I would love to see more innovation on eink UI patterns that works from first principles given the nature and limitations of eink!

For example, I consider dragging operations an anti-pattern on eink devices. Both latency and touch precision are just not at the levels we expect from years of using phones, leading to an experience that is prone to errors and frustration. A particularly common problem is messing up your state just as you lift your finger. I can't tell you the number of times I have carefully highlighted a passage only to have it jump to the wrong words as I release. Dragging is also just an inherently physically awkward maneuver, especially when performed prone.

I think a better pattern would be to use discrete mode changes with modal controls for refining state. As a simple example, highlighting could work like this: 1. Touch and briefly hold to enter selection mode. 2. Selection mode brings up large buttons around the current selection to refine it. Refinement happens via taps, not drags. 3. Selection mode is exited via another button tap. Confirmation is explicit, not implicit. This feels like it would be a lot more relaxing and less error prone.

I could also see a hybridized approach for interactions (like highlighting) where refining exclusively via button taps might be tedious. In this case you could use drag gestures while in selection mode to quickly add/remove large sections to/from the current selection state. This would give you a shortcut for highlighting large sections quickly, which could then be detail-refined via button taps. Having it be modal would also allow you to undo any accidents.

A further refinement for this interaction pattern would be to offer intelligent controls that give the user context-inferred options for their refinement. For example, if you have part of a paragraph highlighted, a button could appear to highlight the rest of it, and subsequently buttons could appear to highlight the adjacent paragraphs. This could even be combined with the hybrid drag gestures idea - after quickly dragging over a rough area, the system could offer multiple proposed selections if there is ambiguity what the user may have intended.

Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?

#74
post #66

Earlier quoted context omitted.

I'm constantly hitting the wrong button because some animation shifted it, some dialog popped over shit, or some notification decided now was a good time to cover the thing I was trying to do. The animations make things feel sluggish. And they don't even look good. The only advice that doesn't improve all UIs is the bit about filling in with white and adding black after.

This stuff is user tested, many people prefer animations because they get confused if the UI changes instantly. For example if a button moves position when a sidebar is collapsed, the animation tells the user where the button has gone. You are probably more observant and have good visual processing, so the animation is superfluous to you. Luckily it can be turned off on Android. On Linux I use XFCE which is almost in…

> For example if a button moves position when a sidebar is collapsed, the animation tells the user where the button has gone.

That's also why you don't do automatically collapsible sidebars.

Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?

#75
post #46

Earlier quoted context omitted.

> 10. Line-art or halftones over shade gradients (images). This is particularly true for eink, because black white is dramatically faster and more reliable (less ghosting) than anything involving any gray. It's why basically all of the "fastest" modes are pure black and white, and why UI shapes are generally pure black and white (though text might have grays).

Not just faster but far more dramatic . The sleep / boot / screensaver patterns for ebook readers tend to be line drawings, woodcuts, and the like. One image I find especially apropos is Dürer's Rhinocerous, which looks phenomenal, especially on a larger screen. https://en.wikipedia.org/wiki/D%C3%BCrer%27s_Rhinoceros#/med... >

I have this exact image (plus one of Dürer's hare images) in my 'sleep screen' folder for my larger readers. I also love German Expressionist woodcuts on ePaper, particularly on smaller screens. Drama is high (maybe too dark/bleak for some) and the stark, high-contrast compositions carry over to the tech beautifully.

Re: Ask HN: In your experience, what are sound conventions for e-ink UI development?

#76
post #66

Earlier quoted context omitted.

I'm constantly hitting the wrong button because some animation shifted it, some dialog popped over shit, or some notification decided now was a good time to cover the thing I was trying to do. The animations make things feel sluggish. And they don't even look good. The only advice that doesn't improve all UIs is the bit about filling in with white and adding black after.

This stuff is user tested, many people prefer animations because they get confused if the UI changes instantly. For example if a button moves position when a sidebar is collapsed, the animation tells the user where the button has gone. You are probably more observant and have good visual processing, so the animation is superfluous to you. Luckily it can be turned off on Android. On Linux I use XFCE which is almost in…

Did you read the recommendations that I was wishing were universal? Specifically: avoid moving elements around the UI.
Post reply on HN