私は、雇用されている工場のAndroidタブレットで実行されるWebベースのアプリケーションのドキュメントをいくつか書いています。
ユーザーがタッチで画面上のボタンを操作する必要がある手順を説明するのに問題があります。
たとえば、「1。時計の番号を入力またはスキャンしてから」...「ボタンをクリック」、「ボタンを押して」ですか?
クリックは私にとって最も自然に聞こえますが、それでも適切に「感じ」ません。
マウスが関係しているかどうかに関係なく、画面上のボタンとの相互作用を説明している間、「クリック」という言葉は至る所にありますか?
ここに「正しい」答えはありません。さらに重要なことは、自分のドキュメント内で一貫していることです。
タッチインターフェイスに関しては、典型的な相互作用は「タップ」です。
デスクトップに関しては、典型的な相互作用は「クリック」です。
どちらの場合も、タッチデバイスとデスクトップの両方を他の方法(キーボードなど)でナビゲートできるため、これは唯一の操作ではありません。
個人的には、「選択」などのより一般的な用語を好みます。「選択」はオプションを選択するために特に予約されていることが多いと指摘している人もいますが。
Androidを使用するので、おそらく独自の 設計原則のドキュメント ?を参照してください。彼らは「タッチ」を使用します。
お気に入りトレイの中央にある[すべてのアプリ]ボタンをタッチして、アプリとウィジェットのコレクション全体にアクセスします。
タッチスクリーンデバイスで何をしているのではないので、「ボタンをタッチする」とも言いますか?それは確かにマウスでボタンをクリックすることと同じです。例えば;
- 時計の番号を入力またはスキャンし、[確認]ボタンをタッチして続行します...
FWIW、Apple彼らの「タップ」を使用 iOSヒューマンインターフェイスガイドライン :
人々はタップ、ドラッグ、ピンチなどのジェスチャーを使用して、アプリやiOSデバイスを操作します。
クリックは物理スイッチを押すことを意味し、「クリック」サウンドを作成します-通常、入力デバイスが接続されているデバイスで(マウスなど)
プッシュは、物理的なボタンに典型的な、元の位置から何かを移動することを意味します。これもまた、マウス(またはより多くのキー)入力に似ています。
Pressは、何かとの物理的な接触に移動することを意味します。移動するものとターゲットは解釈の対象です。これは、接触を含む任意の数のモーションを参照できます。
選択は、通常はリストからのアイテムであるため、同等の状態のものよりも何かを選択することを意味するため、スイッチのオン/オフまたははい/いいえ機能にはあまり適していません
そのため、デバイスにとらわれない目的のために、提供されたリストに限定されている場合は、「プレス」を使用します。
Tap回答で前述したように、タッチスクリーンデバイスに関連付けられる傾向があります。その場合、ボタンの操作に関連して言及することは完全に適切です。
Androidセットアップ画面でユーザーにtouchを指示するために使用されます== Android開始するが、私は個人的にtapタッチに関連するすべてのものに対して、それは小さいので、命令を可能な限り単純化します。
ボタンに単にここをタップと表示されている場合は、テキストを変更して目的を明示することを検討する必要があります(例:連絡先に追加)。
最後に、ユーザーがボタンをタップする必要があることがユーザーに明確でない場合は、ボタンの再設計を検討する必要があります。
モバイルデバイスでは、ジェスチャーの動きを使用します。この場合は、TAPです。 Wordのクリックを使用できますが、古くなっている、またはタッチされていないものとして読み取られます。
ボタン(何らかのアクションをトリガーする)は押された、押されたまたはアクティブ化されたです。
Webフォームでこれを行うには、マウスをポイントしてclick it(デスクトップPCの場合)またはtapをエレメント(タッチデバイスの場合)のいずれかで行います。 。
ボタンのセットから1つを選択しているように聞こえる「選択」という用語は使用しません。
個人的には、「タップ」が好ましい説明であると思います。これは、短時間のタッチも推測するためです。何かに触れるように求められた場合、ユーザーはかなりの期間、そのものに触り続けることが合理的にできます。多くのUIは、タッチアンドホールドを代替ジェスチャーとして解釈します(iOSなど)。
「クリック」、「プッシュ」、「プレス」はすべて何らかの機械的操作を示唆し、「選択」はいくつかのオプションの選択が行われていることを示唆しています。
ボタンの場合、「押し」と「押し」は常に正しいでしょう。
多くのUI要素と同様に、ボタンは実際のオブジェクトを模倣しています。コンピュータアプリケーションでボタンを「押す」ことは、入力方法とは関係ありません。タッチしている画面、マウス、トラックボール、ストローのいずれであっても、最終的には要素に「ホバー」し(CSSでは:hover)、ボタンを押し下げます。
ボタンのデフォルトの外観を見ると、実際の生活を模倣しています。多くの場合、上から光が当たっていて、下に影があり、わずかに丸いボタンにグラデーションがあります。オペレーティングシステムに関係なく、それらはわずかに3次元に見え(フラットなデザインはこのルールの例外です)、ダウン状態にはいくつかの影が含まれ、深さの違いを表しています。
「クリック」は、実際のボタン(マウス)がないと不可能です。
「選択」は、CSSでの:focusに似ています。ここでは、押すことなく、選択せずに選択します。
実際には多くのタッチスクリーンアプリケーションが現在、タッチしてハイライト表示/ドラッグして選択してリフト/コミットするようになっているので、「選択」を選択します。その相互作用シーケンスは、最初の誤ったタッチとキャリブレーションの問題を他の何よりもはるかにスムーズに処理します。あなたはそのシステムでcanタップしますが、そうしないと精度が向上します...そして、組み込みの確認/修正機能を備えたバージョンを使用するように微妙に訓練します。 (IBMがこのアプローチをITSプロジェクトと1992ワールドフェアキオスクの一部として開発したことを知っています。誰かが独自にそれにつまずいて、以前に公開したことがあるかどうかはわかりません。)
(ボストンの公共交通機関システムでは、近接カードをリーダーに提示する動詞として「タップ」を選択するという深刻な問題が継続的に発生しています。「タップ」を通常行う人は、カードを読み取るのに十分な時間をシステムに与えていません。「保留」は、実際のやり取りをより適切に説明したものです。残念ながら、人々はドキュメントにもかかわらず学習するため、それを変更する動機はありません。)