モバイルにおけるテキスト編集：見えにくい問題
(jenson.org)- AndroidとiOSのテキスト編集はデスクトップの慣習を持ち込んだが、モバイルには正確なポインタとメニューバーがなく、1回のタップにカーソル配置・選択・メニュー呼び出しが重なっている
- 問題の核心はテキストの入力ではなく編集であり、10人のユーザー調査では全参加者がターゲティングとクリップボード利用、反復的なエラーを経験した
- テキストハンドル、拡大鏡、ダブルタップ・長押し、ポップアップメニューはそれぞれ妥当な補助手段だが、併用するほどタップ解釈の曖昧さが大きくなる
- Eloquentプロトタイプはタップを常にカーソル配置として解釈し、ドラッグ中心の移動・統合拡大鏡・Drag Press選択・スワイプメニューで編集フローを単純化する
- 改善の障壁は技術より導入と組織の優先順位に近く、モバイルの生産性を高めるにはデスクトップ模倣のハックを超えた、タッチに合った編集モデルが必要である
モバイルのテキスト編集がうまく機能しにくい理由
- AndroidとiOSはデスクトップのテキスト編集方式をモバイルに持ち込んだが、モバイルには正確なマウスポインタとメニューバー／コマンドキーがない
- その結果、1つのタップジェスチャが複数の動作を担うことになる
- カーソル配置
- カーソル移動
- テキスト選択
- ポップアップメニュー呼び出し
- 短いメッセージやソーシャルメディアのコメントでは問題が見えにくいが、複数文のメールのような長いテキストを修正する際には、編集作業が面倒でエラーも多くなる
2017年のユーザー調査で明らかになった編集の失敗
- 2017年にAndroidの作業中、モバイルのテキスト編集に関する既存のユーザー調査を探したが、7年分の研究を調べても関連研究は見つからなかった
- 10人の参加者に、文字を1つ削除する、単語を文末に移動する、といった単純なテキスト編集課題を実施してもらった
- すべての参加者が共通して困難を抱えた
- 目的の位置を正確にタップしにくい
- クリップボード利用が扱いにくい
- 反復的なエラーが多発する
- 参加者は、メッセージングやソーシャルアプリよりも、複数文のメールのような複雑な文章でより大きなフラストレーションを示した
- 半数以上は、テキストを修正するよりも全選択して削除し、再入力するほうが簡単だと答えた
- 問題の焦点はテキスト入力ではなく編集にある
- キーボード、音声文字起こし、タブレットの物理キーボードによって、入力自体は以前より改善している
- ただし、入力した文章を後から直す作業は依然として必要である
- 研究はAndroidの改善に焦点を当てていたが、iOSも細部の動作が違うだけで、同種の問題を多く抱えている
モバイルは消費には強いが編集には弱い
- モバイル端末は、動画、写真、ソーシャルメディア、メッセージングのような移動中の消費に強みを持つ
- 初期のiPhoneにはクリップボード対応すらなかった
- タブレットがデスクトップを置き換えるという期待は繰り返し語られてきたが、デスクトップ代替としては大きな成功を収めていない
- Appleは「What’s a computer?」という広告を出した
- Googleは2013年に、社員が一日中タブレットを使う「Tablet Tuesdays」キャンペーンを試みた
- タブレットの生産性を阻む深いUX上の問題として、テキスト編集とファイル処理が挙げられる
- 目標はデスクトップに戻ることではなく、モバイルをデスクトップ並みに速く生産的に進化させることにある
デスクトップのテキスト編集における基準点
- 2000年以降、デスクトップのテキスト編集は比較的安定した構造を持っている
- デスクトップの基本要素は3つである
- マウスやトラックパッドで動かす正確なポインタ
- クリックしてそのままドラッグする単純な選択操作
- Cut/Copy/PasteがあるEditメニューとX/C/Vのコマンドキー
- この組み合わせによって、テキスト編集は比較的エラーが少なく、曖昧さの少ない作業になる
- 完璧な構造ではないが、モバイルのテキスト編集と比較するための基準線にはなる
デスクトップ方式をモバイルに適応させる中で生まれた4つの補助手段
-
1. テキストハンドル
- モバイルではテキストカーソルの下にしずく型のテキストハンドルが追加された
- ハンドルはカーソルを見やすくし、誤ってタップした後でもドラッグで位置を修正できるようにする
- しかしハンドル自体もタップ対象であり、周囲のテキストもタップ対象なので曖昧さが生じる
- カーソルのすぐ左や右をタップしたとき、ユーザーの意図が不明確になる
- カーソルを移動したいのか
- ハンドルをつかんでドラッグしたいのか
- ユーザーテストでは、正確な位置にカーソルを置こうとしたユーザーが数文字ずれてしまい、再度隣をタップしたが、ハンドルがタップを優先処理して失敗する場面が見られた
- iOSにはしずく型ハンドルはないが、テキストカーソルがタップを奪う問題は依然としてある
-
2. 拡大鏡
- モバイルは小さな文字と相対的に大きい指という問題を補うために拡大鏡を追加した
- 拡大鏡は、タップ前に正確な位置を狙うよりも、誤タップ後にドラッグしながら修正するときにより役立つ
- 指の上に浮かぶ拡大鏡は、実際のカーソルと拡大鏡内の複製カーソルという2つのカーソルを見せるため、視覚的な混乱を生む
- 短いテキストフィールドでは目立ちにくいが、長いメールでは現在位置を見失いやすい
- Appleの拡大鏡はiOS 13で消え、iOS 15で復活した
-
3. テキスト選択
- デスクトップでは、クリックしたままドラッグする動作が自然にテキスト選択へつながる
- モバイルでは同じやり方が難しいため、ダブルタップと長押しが選択ジェスチャとして追加された
- ダブルタップを解釈するには2回目のタップを待つ必要があるため、単一タップへの反応が遅れることがある
- 1語より多く選択するには、単語選択後に両端のハンドルをドラッグしなければならない
-
4. ポップアップメニュー
- モバイルにはメニューバーがないため、クリップボードコマンドを呼び出す別の方法が必要になる
- テキストを選択すると選択範囲の上にメニューが表示され、切り取り／コピーには比較的うまく機能する
- 貼り付けは通常、選択状態から始まらないため、より見つけにくい
- 同じメニューを開くにはテキストハンドルをタップする必要があり、ユーザーは異なる2つのジェスチャを覚えなければならない
- Androidではテキストハンドルが4秒間入力がないと消える
- ハンドルが下のテキストを少し隠してしまうためである
- メニューを開くには再度タップしてハンドルを表示し、さらにもう一度ハンドルをタップしなければならない
- モバイルには切り取り／コピー／貼り付けに相当するコマンドキーがないため、初心者も熟練者も同じメニュー方式を使わざるを得ない
1回のタップが複数の意味に誤解される構造
- モバイルのテキスト編集は、デスクトップ機能をモバイルに押し込む過程で、複数のタップ解釈の可能性を生んでしまった
- ユーザーが1回タップしたとき、システムは次のいずれかとして解釈しうる
- カーソル配置
- すでにカーソルがあるときのメニュー呼び出し
- ドラッグ開始
- ダブルタップ開始
- 長押し開始
- 慎重に操作すれば区別できるが、構造自体が脆弱である
- ユーザーテストで見られたエラーは次の通り
- 太い指問題で狙った位置を外す
- カーソルを修正しようとして隣をタップしたが、ハンドルを押してメニューが出る
- メニューの代わりにごく小さなドラッグと解釈され、何も起こらない
- ダブルタップしようとして隣を押したりハンドルに触れたりして、何も起こらない
- 空のフィールドに貼り付けるには、まず空欄をタップしてカーソルを作り、次にそのカーソルをタップしてメニューを呼び出さなければならない
- カーソルを置いたあと、少し目を離した間にハンドルが消え、ユーザーが混乱する
- 10人調査では、カーソルを正確に置くまで平均5回の試行が必要で、あるユーザーは19回タップした
- 多くのユーザーが実際の編集の代わりに全文を打ち直してしまう理由は、この摩擦とエラーに表れている
既存の補助機能の限界
- ダブルタップ後にドラッグしてより多くのテキストを選ぶ機能や、カーソルを動かせるキーボード機能のような補助策は存在する
- しかしこれらの機能は、多くのユーザーには見つけにくく、根本問題も解決しない
- 核心の問題は、何億人ものモバイルユーザーが毎日タップや選択のエラーを経験していることにある
- モバイルがデスクトップを代替または競合するには、デスクトップ模倣のタップハックを超え、タッチ体験に合わせたより単純で明確な方式が必要である
Eloquentプロトタイプのアプローチ
- Olivier BauとともにEloquentプロトタイプを作成し、この作業はUIST 2021で発表された
- Eloquentは、タップ、選択、拡大鏡、メニュー利用が互いに衝突する問題を同時に扱おうとする試みである
-
単純化されたカーソル配置
- Eloquentの核心目標は、デスクトップのマウスクリックのようにタップの意味を明確にすることにある
- タップは常にカーソルを配置する
- 指が画面に触れた瞬間をすべてドラッグ開始と見なし、タップはごく短いドラッグとして扱う
- ハンドルの横をタップしてすばやく離せばカーソルは新しい位置へ移動し、ゆっくり動かせばカーソルをドラッグする
- テキストハンドルは常に表示したままにする
- ハンドルがテキストを隠さないよう半透明にし、Androidの4秒で消える問題をなくした
-
統合された拡大鏡
- 拡大鏡をテキストカーソルの上に統合し、ユーザーがカーソルを文脈の中で見られるようにする
- Eloquentはドラッグ中心なので、拡大鏡がカーソル配置をより正確にする
- スペースを節約し、テキスト内での位置を保つために魚眼レンズ手法を使う
- 使っていくうちに、タップよりも常にカーソルをドラッグする方式のほうがよいという流れが見えてきた
- 拡大鏡のおかげで、ドラッグで目標地点へ素早く絞り込んでいく新しい振る舞いをすぐに学べた
-
Drag Pressによるテキスト選択
- 現在のモバイル編集の曖昧さは、単一タップジェスチャに多くの機能が集中しているために生じている
- Eloquentは、ドラッグ中により強く押すDrag Pressジェスチャでテキスト選択を開始する
- 当時利用可能だったハードウェアセンサーである、スマートフォンの気圧センサーを用いて押圧を検出した
- 長い移動平均を基準値として維持する
- 短い移動平均が長い平均を上回るとdrag-pressイベントを発生させる
- センサー値の変動がかなりあっても、動作は非常に堅牢だった
- Appleの廃止された3D Touch hardwareのような、より高度な仕組みのほうが優れた解法になりうる
- Drag Pressはその下の単語全体を選択するため、押した瞬間の小さな揺れが大きなターゲティングエラーにつながらない
-
改善されたメニュー
- Eloquentは、コピー／貼り付けのようなクリップボード操作を熟練者がより速く行えるようにしようとした
- AndroidとiOSの現在のテキストメニューは大半が階層型なので、メニューをフラット化しようとした
- ユーザーテストでは、すべての参加者がこのメニューを簡単に見つけて使え、気に入っていた
- Drag Pressで選択を始めたあと、2回目のDrag Pressでメニューを表示し、ターゲティング、選択、メニュー呼び出しを1つの流れの中で処理する
- 熟練者向けには、すばやいフリックジェスチャでメニュー項目を実行できる
- EloquentのT-Menuは切り取りと貼り付けにスワイプジェスチャを使い、階層なしで画面外へ滑り出す
-
ゲーム的なアニメーション
- Eloquentは、ユーザーが状態変化を学び理解できるよう、小さな視覚アニメーションを追加した
- カーソルは位置の間を「scoot」し、到着するとハンドルが「wobble」する
- こうした動きは、カーソルが常に存在し、いつでもドラッグできるという印象を強める
- タップするとカーソルが「dimple」し、拡大鏡を一瞬呼び出して、ユーザーが単なるタップを超えてドラッグを試すよう促す
- Force Pressが単語上で発生すると、ハイライトが「inflate」する
- スワイプメニューのジェスチャは、選択範囲をスワイプ方向にアニメーションさせる
- 上にスワイプして切り取ると、選択範囲が上へ消える
- 下にスワイプして貼り付けると、新しい選択範囲が下へ落ちる
-
既存ユーザーのための互換性
- Eloquentは、既存動作とのつながりを作るために、現在のジェスチャも可能な限り維持しようとした
- タップとドラッグを常にカーソルドラッグとして扱うと、大きく縦スクロールするテキストフィールドで問題が生じる
- ドラッグ開始時、最初の数ピクセルが縦方向なら通常の縦スクロールとして扱う
- それ以外のドラッグは、カーソル配置とカーソルドラッグとして扱う
リリースが難しい理由
- Eloquentのような変化はリリースしにくい
- 多くの人がテキスト編集をすでに「解決済み」の問題だと誤認しており、改善しようという意欲が弱い
- ユーザーは10年以上、エラーの多い現在の方式に適応してきており、今さら変えてほしいと要求しにくい
- AndroidとiOSの競争において、テキスト編集の改善はNet Promoter Scoreを動かすような派手な機能とは見なされない
- テキスト編集のような根本的変化は、ユーザーがスマートフォンをより快適に使えるようにする可能性があるが、効果が現れるまで遅く、何年にもわたる継続的な努力が必要である
- 障壁は技術的問題というより政治的問題に近い
- 現在の流れのままなら、今後少なくとも20年は同じやり方でモバイルのテキストを編集し続ける可能性がある
1件のコメント
Hacker News の意見
モバイルでは、より時間がかかるうえにミスの多い短文を書くことになる。なのでモバイルで入力しなければならない状況を積極的に避け、ノートPCが開いていれば WhatsApp や Signal もそちらで使う。
モバイルキーボードを使わなければならないときは、タイプミス、大文字化の省略、不要な単語の省略をそのまま受け入れることになる。スマートフォンはたいてい、長文入力用のデバイスというより、ニュースやメディアの消費、写真撮影用に近い。
iPad でもキーボードカバーが人気なことを見ると、タッチキーボードの限界が見えてくる。iPad にはキーボードやスタイラスという選択肢がまだあるが、iPhone にはそうした選択肢がほとんどなく、昔の Nokia や BlackBerry のような優れたハードウェアキーボード付きの携帯電話が恋しい。
iPad は結局、出来の悪い QWERTY タッチキーボードを1文字ずつ押さなければならないので、さらに悪い。スワイプに最適化されたキーボード配列があるとよさそうで、以前、母音をできるだけ遠くに配置した配列を計算した記事もあった: https://sangaline.com/post/finding-an-optimal-keyboard-layou...
運転中にメッセージを入れようとすると、最初の試行で完璧に書き取られない限り手を使う必要があり、あと少しで良い状態なのに編集UIのせいで台無しになる。
最近は本当に避けられないときだけタッチスクリーンで打ち、ノートPCが使えなくても座れるなら、スマートフォンをスタンドに置いて小さな折りたたみ式 Bluetooth キーボードを使うようにしている。
スマートフォン業界全体がiPhone化したことで、そうした選択肢を失ってしまった。
それでも iOS のタイピングは改善できるという点には同意する: https://youtu.be/x7qPAY9JqE4?si=9_jnM2Ys8JiTXGqC
この問題が確かにあるのは分かるが、筆者が解決策を見つけたのかは確信が持てない。説明だけ見ると、依然として扱いが難しそうに見える。
タッチスクリーンは、生産性向けのインターフェースとして根本的に悪い。マウスはクリックせずに指し示すこと、左クリック、右クリックをほぼピクセル単位の精度で提供し、キーボードまで加わると選択肢ははるかに広がる。
スマートフォンは、ボタン1つのマウスと、異常に大きく形も不規則なカーソルを備えたコンピューターのようなものだ。カーソル位置はクリックするまでソフトウェアには分からず、キーボードは小さな画面の35%を覆うオーバーレイとしてしか現れない。
これはソフトウェアではなくハードウェアの問題だ。
TeamViewer がスマートフォンで Windows デスクトップのリモートセッションを扱う方法のように、タッチスクリーンを実質的にタッチパッドとして使う実装がある。Android 自体にも切り替え可能なモードとしてあればよさそうだし、関節炎のある指でテキスト選択をするのは文字どおり苦痛だ。
問題は、拡大用のピンチと2本指スクロール以外では、その可能性がほとんど使われていないことにある。
テキスト編集には本当に良い機能だったので、残ってほしかった。
タッチデバイスで長い文章をナビゲート・編集するとき、Vim式のモーダル編集は良いアプローチになり得るのではないかと、ときどき思う
キーボードとマウスのやり方をそのままタッチデバイスに移したのは、機会を逃したように見える。キーボード配列でさえ、2本の親指で画面を押すことに大した利点はない
文字ベースの推論に大きく頼りつつ、片手または一本指入力に合わせてインターフェースを変える方法も興味深い。Dasherのようなアプローチがその例: https://www.inference.org.uk/dasher/dashersummary.html
https://en.m.wikipedia.org/wiki/Dasher_(software)
キー表示が消えるモードなら、そこにマウスボタンのように動作する機能を追加して、テキスト選択や特定位置への貼り付けをサポートするのも、それほど無理はなさそう。今の選択操作はあまりにももどかしい
移動中にプログラミングするには十分
カーソル編集用ページをもう1つ追加して、矢印キー、Ctrl+矢印キー、Home/End、Page Up/Down、選択トグル、Delete、右クリックメニューを提供すれば自然だ。デスクトップキーボードの残りをスマホキーボードに持ち込む程度なので、革新とまでは言えない
Bluetoothキーボードと併用すれば悪くなく、画面が少し小さいだけだ。短い作業には十分だが、長いセッションでは目の健康が心配にはなる
この問題は、少なくとも私にとってはまったく見えない問題ではない。数か月前にも、iOSがまだ業務利用に向いていない例としてテキスト編集を挙げた
テキストの作成と編集は、コンテンツ消費ではない業務利用の核心なのだから、Appleは問題を認めて解決するか、解決できないと認めて、そうした物語を推すのをやめるべきだ
Appleが3D Touchを有効なユースケースなしに投入し、数年後にも見つけられずに終了したことも象徴的だ
GoogleのTablet Tuesdaysも興味深いが、週に1日だけタブレットを使うなら、問題をどうにか耐えてやり過ごせてしまう。むしろチーム全体がタブレットだけを使うTablet Teamsであるべきで、そうすれば問題は隠れなかったはずだ
Eloquentは、より良い方法が可能だという存在証明のように見える。マルチタッチジェスチャーでコピー・貼り付けや選択の問題を解く実験も試す価値がある
一方、Google+のようなソーシャル製品は、一部の社員が使っていたとしても多くはなく、外部ユーザーと同じ機能を必要としていたわけでもない。社内で不満があっても業務の中核ではないため、同じフィードバックループを得るのは難しい
モバイルで編集するとき最大の問題は、長いURLや長い段落のように、1画面に収まらない選択範囲を変更することだ
選択ハンドルを動かしながら縦スクロールし、さらに悪いことに横スクロールまでしなければならない瞬間、ユーザー体験は完全に壊れる
これが最大の問題で、モバイルキーボードになぜコピー/貼り付けボタンがないのかも理解しがたい
ぎこちないが、動作はする
昔のN9やJollaのスマホでは、テキストのどこでもタップしてカーソルをその位置に置けた
iOSは最初のタップでカーソルを有効化するときを除けば、単語の途中を正確に押しても、常に単語の先頭か末尾にカーソルが吸い付く
小さな画面と大きな指でも、狙った文字位置にかなりうまく合わせられるのだから、ただやらせてほしい
なぜそこまで役立ったのか完全には説明しにくいが、カーソルを狙った位置に合わせるのがずっと簡単だった
iOSキーボードにはもどかしさも多かったが、実際にはかなり良い。本当の問題は、古いCodeMirrorのようなサードパーティ製JavaScriptツールが生むことが多い
BlackBerryでは、見なくても分速55語を打てた。画面キーボードはずっと見て直さなければならず、注意を大きく奪い、入力速度を落としてしまう
BlackBerryでのミスは誤った文字が1つ入るだけだったが、スワイプ入力と自動修正のある画面キーボードでは、見当違いの単語が1〜2個入ることがある。雨の日には画面キーボードがまともに反応しない
古いAndroid端末では、内蔵キーボードが重すぎて1秒に1文字程度まで遅くしなければならないこともあり、スワイプとタップの切り替えも滑らかではない。スペースバーのドラッグでカーソルを動かそうとして、最初の試みで単語が挿入されるのもいらだたしい
BlackBerryの編集もカーソルキーだけを使うようなもので、この記事で扱っているタッチ操作よりさらに粗雑だった。要点は誤字修正だけでなく、既存のテキストを大きく直し、文書を整えることをモバイル端末で可能にすることだ
Droid 4のスライドキーボードでは少し遅くなり、タッチスクリーンに移ってからは途方もなく遅くなった。BlackBerryではノートPCとほぼ同じ速度でメールを処理できたが、今はスワイプ入力や予測入力を長く練習しても、中程度の長さのメールは思考の速度に比べて苦痛に感じる
携帯電話でポッドキャストの内容を書き取ろうとすると、頻繁に巻き戻して0.7倍速に落とす必要があるが、ノートPCなら早口でも先回りして打てる。BlackBerry Boldならリアルタイムの発表も書き取れただろうし、思考の速度で入力できたはずだ
タッチパッドと物理キーボードのあるMicroPCで編集するのと、携帯電話で編集するのとの差は非常に大きい
静電容量式タッチの携帯電話でより速く入力したりUIを操作したりすることはできるかもしれないが、カーソルを狙うこととタイピングのストレスは、10年以上スマートフォンを使っていてもなおひどい
人々がこれを問題だとあまり感じない理由も理解できる。時間がたつにつれ、モバイルではテキストを編集しない習慣を身につけてきたからだ。最新のモバイルOSにはかなり強力なオフィススイートもあるが、たいていはメッセージやメモ程度しかせず、カーソルを動かす機会はほとんどない
PinePhoneのSqueekboardでは、スペースバーのドラッグでカーソルを動かす機能とスワイプ入力がかなり物足りないが、Phoshのテキスト編集がAndroidやiOSよりはるかに洗練されていなくても、実際の難しさは大きく増えないという点は多くを物語っている
テキスト編集だけを見れば、数字・必要な記号・修飾キーが基本レイヤーにあれば、VimやEmacsもタッチキーボードで意外と実用になる
精密なポインティングと大きな指の問題は、タッチスクリーンをタッチパッドのように相対入力として使えば解決できる。evdevとuinputに直接つなぐ簡単なユーザー空間プログラムで可能で、デスクトップソフトウェアの実行を単なるお遊び以上のものにしてくれる: https://gitlab.com/CalcProgrammer1/TouchpadEmulator
スワイプ入力は、wvkbdの実験的サポートがかなりうまく動く。長い単語や縮小した辞書に特に合っており、zsh補完をファイルに書き出して活用するといった可能性もある: https://git.sr.ht/~proycon/wvkbd
sxmo_inputhandler.shのレイテンシは理解しがたい。単純なOSシェルジェスチャーを長いシェルスクリプトで処理し、grepのパイプ1つでも遅延が目に見えて増えるプラットフォームでは、非常に非効率に見える
ノートPCからキーボードを外し、OSを弱体化させてから「モバイル」と呼んでいるようなものだ
そのあと誰かがテキスト編集はもはや実用的ではないと言うと、「デスクトップに戻ろうというのではなく、モバイルを前に進めようということだ」と言う
なぜ意図的に弱められたコンピューティング体験を、避けられない未来として優遇しなければならないのかわからない。モバイルが切り開くほぼすべての潮流は悪い
それらの端末のほうが、より劣悪で、よりロックダウンされ、消費中心のコンピューティング体験を提供するからだ。こうした考えが社員にも植え付けられているように見える
テレビがノートPCの代替ではないのと同じだ
そうすることでデスクトップ体験がどう損なわれるのかも不明だ
Termux内であまりに多くのコードを書いているので、今ではノートPCはOpenStreetMapを編集するときだけ使っている。Termux自体で新しいAndroidアプリをビルドする方法を探している
モバイルでは何も大丈夫ではありません。みんなスマートフォンが好きですが、携帯性を除けばあらゆる面で悪いコンピューターです。
実際に何かをしたいならコンピューターを使うべきで、スマートフォンは本物のコンピューターを使えないときだけ使うデバイスです。
だからこそこういう記事が重要です。諦めるのではなく改善すべきで、携帯電話でのテキスト編集が最終形に到達したと考える理由もありません。
iPhone以前に書かれた文章で、モバイルのユーザー体験を最も本質的なものだけに絞り込まなければならないという厳しい必要性を扱っていました。Apple Watchアプリを作りながら、この内容をあらためて思い出しました: https://jenson.org/The-Simplicity-Shift.pdf
それほどの金額を取るデバイスが、有用性よりもトラッキングや広告まわりの小細工を優先し、ひどいユーザー体験を提供するのは受け入れがたいです。
デスクトップほどではありませんが、ほとんどのモバイルデバイスよりはるかに良く、WhatsApp WebやSignalのデスクトップアプリも、一文か二文を超えて書くときはデスクトップで使うようにしています。
携帯電話で少しでも長い文章を書かなければならないなら、キーボードを買うのがいいです。小さなBluetoothキーボードでもずっとましですし、昔のBlackBerryや、それに近い形のAndroidキーボードフォンにも惹かれます。