But my advice: do not count on anything refreshing ever. Do not have animations, or transitions. Preload things to the correct spaces, then fill in. Reserve fixed white areas for output, and then fill in with black. (This works much better than the reverse!)
For quite long running processes, it might be worth having it behind a second page load.
If you find out, let me know! I have been working on a port of Excalidraw to my ReMarkable Pro and it's opened my eyes to how much we take for granted in terms of UI interactions when we assume we have a 30+hz screen with no to minimal ghosting. Layout has to become as monotonic as possible, especially in the absence of user interaction; in other words, the app itself should never be doing anything to disrupt prior renders on its own unless you are clearing the whole page. When it is the user interacting with the app, try to minimize the number of intermediate states their interactions produce. This does NOT mean "just don't render those intermediate states", however. It means make the interactions themselves not require intermediate feedback. Essentially, users (and developers) are so accustomed to just being able to manipulate things with no side effects that you have to make every possible interaction as intentional as possible, leaving them less frustrated when they do see a refresh. If an operation is going to cause a refresh, it should happen at a moment the user already understands as a semantic boundary.
You obviously cannot always avoid this, so when there is a hard requirement for continuous feedback, use a degraded/cheap transient representation and refresh at commit of that action. With E-Ink, every interaction has to be a trade off between ghosting and latency. One common pattern I ended up coming back to is intermediate states that optimize for latency at the expense of ghosting until the UI action is 'complete'. This will allow refreshes to be associated with the satisfaction of finality. Funny enough, many of them harken back to old UI paradigms from when computer graphics weren't as powerful as today. When resizing, I simply draw the outline of the shape with a fast update mode that tolerates more ghosting until the user releases their finger or stylus, at which point, after a small lag to account for an 'oops, just a tiny bit bigger/smaller', I do a localized refresh of the union of the old + new area.
The outline itself is deliberately faint, so the refresh doesn't have to be as intense if its a small delta.
For your streaming LLM case, I would recommend doing it in chunks, like you said, perhaps doing a hard refresh of everything but the input box + moving the tail of last sent message + beginning of stream to the top upon send. Of course, this implies that you know exactly how long the response will be, which you don't. The challenge will be coming up with a UI paradigm that doesn't make it look awkward if the response only goes down to the middle of the screen while also nicely doing a clean refresh pre-emptively if it's clear it will overflow and need to move to the top. For the former case, find some way where it looks not completely awkward if it's partial and then do refresh of the chat history area and move it to its proper fitted position once the user clicks on the input box again to type their next reply. For the latter, perhaps embedding some kind of remaining space meter at the bottom that indicates when you'd need to do this move + refresh action (don't directly label it that way) would enable the user to anticipate it more and be less frustrated when it happens, as they are psychologically awaiting the next part of the answer/reasoning, not surprised at a sudden flash.
For the actual streaming, you'll have to ensure that your text alignment works in such a way that once a line is rendered to the screen, its placement is final (in other words, no streaming intra-word, as you need to know if the word will fit in remaining space on the line before rendering it). Basically, avoid retroactive reflow like a PDF document with a fixed layout, not like this text box I am typing in with a resize handle at the lower right. You'll also probably want to disable scrolling during generation as well, or at least make some sort of discrete pagination mechanism for going back and forth.
In any event, I look forward to seeing whatever it is you're building!
I’d focus more on print usability and readability guidelines than computer guidelines. 5Hz eink is closer to a moving newspaper than a slow computer.
https://www.mediapoint.com.au/design-tips/composition-layout... might be moderately helpful.
But my advice: do not count on anything refreshing ever. Do not have animations, or transitions. Preload things to the correct spaces, then fill in. Reserve fixed white areas for output, and then fill in with black. (This works much better than the reverse!)
For quite long running processes, it might be worth having it behind a second page load.
Not a web UI, but I recently built this[0] for my Boox Note Air 5c tablet. You may find it useful (check the source code in GitHub)
[0]: https://inka.page
If you find out, let me know! I have been working on a port of Excalidraw to my ReMarkable Pro and it's opened my eyes to how much we take for granted in terms of UI interactions when we assume we have a 30+hz screen with no to minimal ghosting. Layout has to become as monotonic as possible, especially in the absence of user interaction; in other words, the app itself should never be doing anything to disrupt prior renders on its own unless you are clearing the whole page. When it is the user interacting with the app, try to minimize the number of intermediate states their interactions produce. This does NOT mean "just don't render those intermediate states", however. It means make the interactions themselves not require intermediate feedback. Essentially, users (and developers) are so accustomed to just being able to manipulate things with no side effects that you have to make every possible interaction as intentional as possible, leaving them less frustrated when they do see a refresh. If an operation is going to cause a refresh, it should happen at a moment the user already understands as a semantic boundary.
You obviously cannot always avoid this, so when there is a hard requirement for continuous feedback, use a degraded/cheap transient representation and refresh at commit of that action. With E-Ink, every interaction has to be a trade off between ghosting and latency. One common pattern I ended up coming back to is intermediate states that optimize for latency at the expense of ghosting until the UI action is 'complete'. This will allow refreshes to be associated with the satisfaction of finality. Funny enough, many of them harken back to old UI paradigms from when computer graphics weren't as powerful as today. When resizing, I simply draw the outline of the shape with a fast update mode that tolerates more ghosting until the user releases their finger or stylus, at which point, after a small lag to account for an 'oops, just a tiny bit bigger/smaller', I do a localized refresh of the union of the old + new area.
The outline itself is deliberately faint, so the refresh doesn't have to be as intense if its a small delta.
For your streaming LLM case, I would recommend doing it in chunks, like you said, perhaps doing a hard refresh of everything but the input box + moving the tail of last sent message + beginning of stream to the top upon send. Of course, this implies that you know exactly how long the response will be, which you don't. The challenge will be coming up with a UI paradigm that doesn't make it look awkward if the response only goes down to the middle of the screen while also nicely doing a clean refresh pre-emptively if it's clear it will overflow and need to move to the top. For the former case, find some way where it looks not completely awkward if it's partial and then do refresh of the chat history area and move it to its proper fitted position once the user clicks on the input box again to type their next reply. For the latter, perhaps embedding some kind of remaining space meter at the bottom that indicates when you'd need to do this move + refresh action (don't directly label it that way) would enable the user to anticipate it more and be less frustrated when it happens, as they are psychologically awaiting the next part of the answer/reasoning, not surprised at a sudden flash.
For the actual streaming, you'll have to ensure that your text alignment works in such a way that once a line is rendered to the screen, its placement is final (in other words, no streaming intra-word, as you need to know if the word will fit in remaining space on the line before rendering it). Basically, avoid retroactive reflow like a PDF document with a fixed layout, not like this text box I am typing in with a resize handle at the lower right. You'll also probably want to disable scrolling during generation as well, or at least make some sort of discrete pagination mechanism for going back and forth.
In any event, I look forward to seeing whatever it is you're building!