禅ノート(zen-note)を作った話(自転車モード編)：キーボードを消すのではなく、上だけで完結させる

本記事にはAmazonアソシエイト・プログラムによるアフィリエイト広告を含みます。商品の購入等により、当サイトが紹介料を得ることがあります。

実装編ではv1〜v3の技術的な経緯を、思想編ではその設計思想をまとめました。今回はその続きで、v4として作った「自転車モード」の話です。

きっかけ

v2(禅モード)を自転車に乗りながら使っていて、はっきりと使いにくさを感じる場面がありました。それをそのままAIに相談したのが、このプロジェクトの出発点です。

「自転車に乗った状態で、音声入力に特化したバージョンのモードを作りたい」。今のバージョン2は、自転車に乗っているときにも操作が簡単にできて入力できる。文字がほとんど見えなくてもいいけれど、入力モードに入りやすいUIが理想。具体的には、下の部分にキーボードが上がってきてしまうので、上の部分だけで見た目が完了するようになってほしい。それと、画面が黒だとほぼ何も見えなくて、入力し始めのカーソルを合わせることができない。つまりダークモードだけじゃなく、ライトモードの実装が必要になってくる——。

そんな相談から始まりました。

音声入力そのものに使っているマイクも、自転車モード用に選び直しました。イヤホン型だと両耳を塞いでしまい、走行中の安全確認に支障が出ます。耳を塞がずに使えるピンマイクなら、周囲の音を聞きながら喋れるので、ここは譲れないポイントでした。

BOYA mini 2 ピンマイクワイヤレスマイク(5g超軽量・2段階AIノイズキャンセリング)¥8,999Amazonで見る ▸

現状調査で見えた制約

まずは既存のv2・v3の実装を読み込むところから始めました。v2は禅モード(カーソル中央固定のタイプライター)、v3はそこにAI漢字変換を足したもの。どちらもiOSでPWAとして動かす前提の構成です。

ここで一つ、大きな制約にぶつかりました。ブラウザ単体で音声認識を完結させるWeb Speech APIが、iOS Safariでは使えないという事実です。「ブラウザだけで音声入力を完結させる」という最初のイメージは、この時点で崩れました。

3つの論点を先に決める

実装に入る前に、方向性を絞り込むための質問をもらい、それぞれ答えました。

対象端末は？ → iPhoneのみ
バージョン構成は？ → 既存のv1〜v3を触らず、新規のv4として独立させる
走行中の編集方針は？ → 文中編集はせず、末尾に追記していくログ形式のみ

この3点を先に固定したことで、実装の途中で判断がぶれる場面をかなり減らせたと思います。

「キーボードを消す」のではなく「キーボードの上だけで完結させる」

Web Speech APIが使えない以上、OS標準のディクテーション機能に頼ることになります。つまり、キーボードは出る。これを前提として受け入れました。

そこで発想を変えて、visualViewportというAPIでキーボードの高さをリアルタイムに検知し、ログ・録音状態・保存ボタンといった必須要素を常にキーボードの上に収めるレイアウトにしました。技術的な理想論を先に立てるのではなく、実機の制約を先に確定させてから、その上でUIを組む。この順番を守ったことが、結果的に一番効いたところです。

「カーソルを合わせる」という行為自体をなくす

「暗くてカーソルが見えない」という課題に対しては、ライトモードを足すだけでは不十分でした。そもそも、v2の「文中カーソル固定+自由編集」という思想自体が、自転車モードには合わないと判断しました。

喋ったら末尾に1行積み上がるだけのログ形式にすることで、「今どこにカーソルがあるか」を走行中に意識する場面自体を、構造としてなくしました。誤字の修正は停車後にまとめて行う前提にすることで、走行中のUIを削れるだけ削っています。

ライトモードは「対応」ではなく「既定」

既存のv1〜v3はすべてダーク基調でした。自転車モードだけは、これを明確に逆にしています。屋外・直射日光下での視認性を優先し、ライトモードを既定にしました(ダークモードは任意で切り替え可能)。

保存に失敗しても消えない、を優先する

走行中はネットワークが不安定になりがちです。そこで、音声認識の結果が確定するたびに、まずlocalStorageへ即座に退避するようにしました。GitHubへの送信は非同期で行い、失敗しても自動で再試行します。見た目の綺麗さより、走行中に喋った内容が消えないことを優先した判断です。

走行中に設定を求めない

既存のv2には、必要な設定が未入力のまま保存しようとすると、自動で設定モーダルが開く仕様がありました。自転車モードでは、これを意図的にやめています。走行中に予期しないモーダルが開くこと自体が危険だと考えたからです。

公開まで

v4/index.htmlを新規作成し、ライトモード既定・ログ追記型UI・visualViewport追従レイアウト・GitHub自動同期を実装。トップページとREADMEも更新してブランチにpushしました。

その後「GitHub Pagesで見れるか」と聞いたところ、まだmainブランチに入っておらず公開されていない状態だったので、その場でPRを作成してマージし、GitHub Pagesに反映しています。

—

「キーボードを消す」という最初のイメージは、実機の制約(Web Speech APIの非対応)によって崩れました。でも、それで終わりにせず「キーボードが出てもいい、その上だけで完結させればいい」と発想を切り替えたことで、むしろ元の相談で言っていた「文字がほとんど見えなくてもいい、入力モードに入りやすいUI」という理想に、別の角度から近づけた気がしています。