👀️老眼向けUIを本気で考える① ～リスト表示編～

始まりはお客さんからのクレーム

私は倉庫管理のアプリを作製していますが、以前から"地味な"問題がありました。それは"詰め込み過ぎ問題"です。お客さんとしては様々な情報に手元の端末からアクセスしたい、という希望があって、それにできるだけ応えるよう設計したのですが、如何せん端末は以前はiPhone SEで、現在は業務用のAndroid機で、いずれにしても画面が小さいのです。画面が小さいのは、つまり端末が小さいので、特に手の小さい女性に好まれるようです。

しかし画面が小さいにも関わらず、情報を詰め込むと、当然フォントは小さめになります。とは言え、若い人はそれでも良いのです。問題は老眼になってしまった人たちなのです。

私自身、ここ数年で老眼が入ってきたように思うのですが、なにせ極度の近視のため、思いっきり手元から離さないと見えない、よくある老眼の光景とは無縁です。なので老眼の方の苦労を良く分かっていなかったと思います。ところがある時、老眼の進んだ兄のスマホを見て驚きました。画面に「フォントしかない！」と思ってしまうほど、とんでもないフォントの大きさだったのです。

これらの件で、しっかりとこの問題に取り組まないといけない、と思うようになりました。
※ただ程度問題なので、どんなに進行した老眼の方にも満足いくレベルを目指す、というのは困難ですけど…

そもそも人間が一度に認識できる情報は少ないのでは？

特に作業しながら使うアプリは、そもそもそれほどしっかり画面を見ることは少ないはず。表示する情報をそぎ落とし、何がその画面で重要な情報なのか？ を突き詰めて考えると、これまで当たり前だったUI自体を考え直す必要があるのではないか、と考えるようになりました。

ということで、今回はリストを例に考えてみたいと思います。リストに関してはお客さんからフォントをめちゃデカくしても良いんじゃない？ と言われたこともあったのですが、その通りにすると一度に表示できるリストの項目は２つ３つくらいになって、リストの意味あるんかいな？ と思い、特に対応はしませんでした。

しかし、今になって思えば何か対処法はあったのではないか、と思うようになりました。例えば、リストをスクロールしている間、リストの中央が拡大鏡のように項目が大きくなる、みたいな… そもそも複数項目を一瞬にして認識できる人はほとんどいないでしょう。それを前提とすると、一つの項目だけにスポットが当たり、残りは とりあえずの 存在だけが確認できれば良いのではないか？ と極端ではあるものの、そう考えました。

ではサンプル実装！

いくつかアイディアを具現化したので、これらを紹介します。アカデミー作品賞を受賞した作品をリストとして表示しています。背景色が付いた項目が選択項目で、その項目に紐づいた情報が強調表示されます。"決定"というボタンが付いているので、それを押下するとSnackbarが表示されるのが共通仕様です。

オーバーレイ方式

リスト中のひとつの項目のみ選択され、ダイアログのように表示します。選択される項目はスクロールの動きに合わせて変わります。選択される項目はリストの表示領域の上部としました（理由は後述）。

リストにある各項目の情報はオマケみたいなものであり、基本的に意識しなくても良い、リストの全体数の感覚が分かればイイ程度に考えています。選ばれたダイアログ風に表示されている情報が見せたい情報です。

ダイアログ風に見えるエリアでもリスト上であっても関係なく、タッチし、スクロールを開始できるように工夫しています。またパフォーマンスを考慮し、高速スクロール中は表示をスキップする工夫も入れています（上記サンプルでは分かりづらいと思いますが…）。

元々はパフォーマンスを心配し、スクロール中はダイアログ風な表示はしないようにしていましたが、当初の理想とは異なるため思い直し、上記仕様としました。

スケーラー方式

これは今回の老眼向けUIの実装をお願いしたClaude Codeに提案された方式です。選択された項目がリスト内で大きくなる方式になります。

この方式でもスクロール中に大きく表示したかったのですが、パフォーマンス上の無理が生じてしまい、スクロール中の拡大は止めました（　＾ω＾）・・・ やはりスクロール中に強調表示（拡大表示）が見れない、というのがデメリットです。

固定方式

これはリストの上部、または下部に表示専用の領域を確保し、そこに表示する方式です。

リストと強調表示エリアが離れているため、２つの注目点が生まれてしまい、UX的によろしくないと思います。リストの高さが短ければ実用性があるかもしれません。

なお、オーバーレイ方式同様、高速スクロール中は強調表示エリアは更新せずに、パフォーマンスに気を配っています。

実装上の問題

今回お見せした方式は、いずれも実装難易度は高いと思います。今回はFlutterで作成していますが、どのフレームワークでも基本的には同様の難易度だと思います。

どの方式でも共通して言えるのは、選択する項目を判定する処理の面倒さです。移動スクロール量を取得し、それと各項目の中心Y座標（スクロールに依らない絶対値）とを比較し、移動スクロール量を超えるY座標を持つ最初の項目を選択項目にする、といった判定が必要です（中心Y座標としたのは、項目が半分以上が見える状態になることが選択項目としての前提）。

選択項目の判定以外にも、例えばオーバーレイ方式の場合、ダイアログ風のエリアを触れ、上下に指を動かしても、ちゃんとスクロールできるようにするには、中々の面倒臭さがあります。もし、ボタンが無ければ、ダイアログ風のエリア全体をIgnorePointer（タッチイベントを受け付けず、素通しし、下のリストのイベントとして処理）の対象とするだけでＯＫなのですが、ボタンがあるがために面倒が発生します。

IgnorePointerはその子ウィジェットをタッチイベントの対象としないため、エリア全体が対象となると、ボタンまでもがイベント対象外となります（ボタンが押せない！）。そのため、以下の２層構造で実現しています。

• 層①（下）：表示専用レイヤー　IgnorePointerでエリア全体のタッチイベントを素通しにし、見た目のエリアを表示するだけの役割
• 層②（上）：ボタン専用レイヤー　同じウィジェット構造を透明な状態で重ね、ボタン部分だけイベントを受け取れる状態にする

こうすることで、エリアを触ったタッチイベントは層①を透過して下のリストに届き、ボタンのタッチだけは層②が受け取る、という動作になり、冗長な構成となっています。

ただし、この２層構造はFlutterのイベントに対する設計の所為もあると思うので、他のフレームワークでは２層にする必要がない可能性があります。

この他にも可視領域のリストの上部を選択対象とすることから、通常のリストの考え方ではリストの下の方の項目が選択対象になりません。そのためリスト項目の下部に、リスト表示領域の高さから最後の項目の高さを引いた値の余白をダミー項目として追加しています。イメージとしては下の図のような感じです。

   +-------------+
   |    Item1    |
   +-------------+
   |    Item2    |
   +-------------+
   |    Item3    |
   +-------------+
   |             |
   |    Space    |
   |             |
   +-------------+

実は当初、選択項目を可視領域のリストの中央としていましたが、中央にする場合はリストの上下にダミー項目を配置しなくてはなりません。この場合、リストの初期表示時にリスト上部に余白が存在し、それがユーザに違和感を生じさせると思ったので止めました。

以上、色々と挙げましたが、要は常識的なUI,UXではないので、特別な対応が実装時に生じる、ということです。もちろん、パフォーマンス上の影響もありますね。現状、動作させる端末が限定され、そこでパフォーマンス上の問題が無いことを確認の上、適応させることになるでしょう。

さいごに

今回、３パターンをアイディア出ししてみましたが、いかがでしょうか？ 振り返ってみると、強調表示は全体的にフォントを大きくすべきでしたかね、やっぱり。

自分の理想としてはオーバーレイ方式が一番良いと感じています。リストはあくまで一覧であることを伝える裏方の存在で、大切な個々の項目は一つだけ選ばれて表示される、これは私の理想に適っていますから。

みなさんはどう思われるでしょうか？ 特に悲しい年頃のオメメを持たれる方はどう思われたでしょうか？

今回はリストを例に、老眼の方や小さい画面の端末向けのUI設計を考えてみました。リストの他にも考える場面は様々あると思うので、シリーズ化を考えています。興味のある方は楽しみにお待ちください。