Async Clipboard APIでコピーbuttonを作るときは書き込み処理と通常の選択コピーを分けて残す
公開日： 執筆：佐藤
住所、電話番号、振込先、申込み用のcodeなどをpageからcopyしてもらうときは、copy buttonがあると便利である。ただし、buttonを押せば必ずclipboardへ書き込めるとは限らない。Async Clipboard APIを使う場合も、copyしたいtextを画面で選べるように残し、成功した場合とできなかった場合を分けて伝える。copy buttonは入力を楽にする補助であって、必要な情報を渡す唯一の入口にしない。
Chromium Blogは3月21日、Chrome 66 BetaでAsync Clipboard APIを案内した。このAPIはPromiseを使ってclipboardを読み書きでき、従来のexecCommand('copy')より扱いやすく、Permissions APIとも連携すると説明されている。記事基準日ではtextの書き込みと読み取りが例示され、画像などの豊富なdata typeへの対応は今後のChrome releaseで予定されている。新しいAPIを使う場合は、現在できるtextのcopyを小さく試し、まだ予定の機能を前提にした画面を作らない。
copy buttonの役割を一つに絞る
copy buttonは、画面にある文字をclipboardへ書き込むために使う。まず、何をcopyさせたいかを一つにする。電話番号をcopyするbuttonなのか、問い合わせmail addressをcopyするbuttonなのか、注文時に使うcodeをcopyするbuttonなのかで、表示する文言と置く場所が変わる。一つのbuttonでpage内の文章全体をcopyさせると、利用者がどこへ貼り付けるか分からず、余計な情報まで渡してしまう。
たとえば、電話で予約を受けるpageなら、電話番号は画面に大きく表示し、電話できない環境の人がcopyして別の端末で使えるようにbuttonを添える。このとき、buttonに「copy」とだけ書くより、「電話番号をcopy」のように対象を示す方がよい。buttonを押した結果も、「copyしました」と対象を含めて表示する。利用者が今どの情報をclipboardへ入れたかを確認できる。
copyする文字列をJavaScriptの中だけに置かないことも大切である。画面に読めるtextとして出しておけば、APIが使えないbrowserや、scriptを止めた環境でも、文字を選んでcopyできる。電話番号ならtel link、mail addressならmailto linkを別に置く方法もある。copy buttonを作るために、既にある連絡手段を消さない。
書き込みの成功と失敗を同じ表示にしない
Async Clipboard APIのtext書き込みはPromiseを返す。処理が終わる前に「copyしました」と表示すると、失敗した場合に利用者へ誤った案内を出す。buttonを押したあとに書き込みを待ち、成功したときだけ成功の表示を出す。失敗したときは、もう一度試す案内か、文字を選んでcopyする案内を出す。
失敗時の表示をconsoleのerrorだけに任せない。siteを使う人はDeveloper Toolsを開かないため、画面上に何も出なければ、buttonが壊れているのか、自分の操作が足りないのかを判断できない。「copyできませんでした。表示されている文字を選んでcopyしてください」のように、次にできる操作を短く示す。
読み取りと書き込みも分けて考える。clipboardへtextを書く機能なら、利用者がpageに表示された情報をcopyするだけで済む。clipboardからtextを読む機能は、利用者が別の場所でcopyした内容をpageへ渡す仕組みになる。入力formへ貼り付けた内容を補助する場合でも、何を読み、どこへ表示し、送信前に利用者が確認できるかを決める。便利だからといって、clipboardの内容を自動で送信したり、画面に出さずに使ったりしない。
APIが使えない画面でも用件を進められるようにする
Chrome 66 Betaで案内されたAPIであるため、すべてのbrowserや利用環境で同じように動くものとして設計しない。buttonが使えないときに、利用者が文字を選べるか、linkを開けるか、別の連絡方法へ進めるかを先に確認する。APIの有無を調べる処理は、buttonを消すためでなく、通常の方法を残したうえで補助を出すために使う。
たとえば、銀行振込の案内にaccount numberを載せるなら、番号はcopy buttonのlabelに隠さず、ページ上の文字として表示する。copyできなければ、利用者は番号を選んでcopyするか、必要なら控えられる。番号を画像だけで置くと、copy buttonが失敗したときに手で入力するしかなくなる。読みやすい文字とcopy buttonを同じ画面に置けば、通常の操作と補助操作を両立できる。
copy buttonを追加した後は、buttonを押す操作だけで終えない。PCとmobileで対象のtextを選び、copyできるかを確認する。buttonを押したときは、成功表示が対象のbuttonの近くに出るかを見る。失敗を再現できない場合でも、scriptを止めた状態やAPIがない状態を想定し、文字とlinkが読めるかを確かめる。画面の見た目が整っていても、利用者が必要な文字を取れなければ、機能を足した意味がない。
予定の機能と現在の機能を混ぜない
Chromium Blogは、将来のChrome releaseで画像を含むrich data typeのcopyとpasteにも対応すると案内している。これは、2018年4月1日の時点で画像をcopyできるUIを作ってよいという意味ではない。今使えるtextの機能と、予定されている拡張を分ける。
新しいAPIは、codeを短くできることがある。しかし、codeが短いことと、利用者が迷わず操作できることは別である。buttonの文言、成功時の表示、失敗時に選べる文字、通常のlinkを確認する。clipboardを使う機能ほど、何をcopyし、失敗したら何をすればよいかを画面に残す。
Async Clipboard APIは、copyを便利にする選択肢である。利用者が必要なtextを見つけ、buttonでcopyでき、できない場合も選択してcopyできる状態を作る。まず情報を画面へ出し、次に書き込みの成功と失敗を分け、その後に対応するbrowserへ補助を加える。この順序なら、新しいAPIを使っても連絡先や案内の入口を狭めずに済む。
関連記事
