Ask HN: あなたの経験では、e-ink UI開発の健全な慣行は何ですか？

私が見つけたら教えてください！ReMarkable Pro向けのExcalidrawの移植に取り組んでいて、30Hz以上の画面でゴーストが最小限であることを前提としたUIインタラクションの多くを当たり前と思っていることに気づきました。レイアウトは、特にユーザー操作がない場合には、できるだけ単調にする必要があります。つまり、アプリ自体が、ページ全体をクリアしない限り、以前のレンダリングを独自に妨害することをしてはなりません。ユーザーがアプリと対話するときは、その操作が生成する中間状態の数を最小限に抑えるようにしてください。これは「中間状態をレンダリングしない」という意味ではなく、操作自体に中間フィードバックを必要としないようにすることを意味します。本質的に、ユーザー（および開発者）は副作用なしに物事を操作できることに慣れすぎているため、すべての可能な操作をできるだけ意図的にし、リフレッシュを見たときにフラストレーションを軽減する必要があります。リフレッシュを引き起こす操作は、ユーザーが意味的な境界として理解している瞬間に行われるべきです。これを常に回避できるわけではないので、継続的なフィードバックが必須の場合には、劣化した/安価な一時表現を使用し、そのアクションのコミット時にリフレッシュします。E-Inkでは、すべての操作がゴーストとレイテンシのトレードオフになります。私がよく戻ってきた一般的なパターンは、UIアクションが「完了」するまでゴーストを犠牲にしてレイテンシを最適化する中間状態です。これにより、リフレッシュが最終性の満足感と関連付けられるようになります。

リサイズ時には、高速更新モードでシェイプの輪郭を描画し、ゴーストを許容しつつ、ユーザーが指やスタイラスを離すまで待ちます。その後、少しのラグ（「ああ、もう少し大きい/小さい」という微調整のため）の後、古い領域と新しい領域の和集合のローカルリフレッシュを行います。輪郭は意図的に薄く描画されるため、デルタが小さい場合、リフレッシュの強度を抑えることができます。

ストリーミングLLMのケースでは、チャンク単位で行うことをお勧めします。送信時に、入力ボックス以外のすべてをハードリフレッシュし、最後に送信したメッセージの末尾とストリームの先頭を上部に移動します。もちろん、これはレスポンスの長さを正確に知っていることを前提としていますが、実際にはわかりません。レスポンスが画面の途中までしか届かない場合に見苦しくならないUIパラダイムを考案し、オーバーフローして上部に移動する必要があることが明らかな場合に、事前にクリーンなリフレッシュを適切に行うことが課題です。前者の場合、部分的な表示が見苦しくならない方法を見つけ、ユーザーが次の返信を入力するために入力ボックスをクリックしたときに、チャット履歴エリアをリフレッシュして適切な位置に移動します。後者の場合、下部に残りスペースメーターを埋め込んで、この移動+リフレッシュアクションが必要なタイミングを示す（直接ラベル付けしない）ことで、ユーザーが予測しやすくなり、突然のフラッシュに驚かず、フラストレーションが軽減されます。

実際のストリーミングでは、テキストの配置が、行が画面にレンダリングされたらその配置が最終的であるように機能することを確認する必要があります（つまり、単語内ストリーミングは避けます。単語が行の残りスペースに収まるかどうかをレンダリング前に知る必要があるため）。基本的に、PDF文書のような固定レイアウトで、右下にリサイズハンドルがあるこのテキストボックスのような遡及的なリフローを避けてください。また、生成中のスクロールも無効にするか、少なくとも前後に移動するための離散的なページネーションメカニズムを作ることをお勧めします。