ツールチップは、アプリケーションを理解するための非常に便利なインターフェイス パラダイムです。これらは、ビジュアル コントロールと、そのコントロールに関連付けられたアプリケーション固有のアクションとの間のマッピングです。ユーザーは、マウス ポインターをホバリングするだけで、アクションを呼び出さずにアクションを探索できます。
タッチ デバイスは、このパラダイムを基本的に不可能にします。これにより、アプリの使いやすさが制限され、場合によってはかなり不可解になります.
ツールチップの概念に代わるタッチ デバイスが存在するかどうか知っていますか? それらは実質的に、UI インタラクションにおける 1 つの自由度、つまりポインターの位置を欠いています。この通信チャネルを効果的に取り戻す方法は?
誰に尋ねるかによっては、理解するためにツールのヒントが必要なインターフェイスをひどく再設計する必要があると言われることもあります（Jef Raskin：The Humane Interfaceを参照）。
実際、ツールのヒントは、非常に具体的な問題の解決策です。ツールバーに表示されるような、ラベルのない象徴的なボタンです。ラベルがあるときはいつでも、それらを使用してください。特定のコントロールが何を実行するかを示すテキストがすでにあるため、ツールチップを提供する必要はありません。
さらに、タッチインターフェイスは今日のWIMPインターフェイスモデルにあまりよく対応していません。多くのコントロールはマウスポインタで処理するのに適していますが、指で使用するのはイライラします。メニュー、チェックボックス、ラジオボタンが頭に浮かびます。したがって、タッチインターフェイスのインターフェイスパラダイムは、今日のマウスおよびキーボード駆動のインターフェイスとはかなり異なって見える必要があります。
したがって、ここで問題となるのはツールのヒントの欠如ではなく、過去30年間にコンピューターと対話するための多くの新しい方法を探求しなかったと思います（基本的には、DougEngelbartとXeroxPARCによる調査以降ではありません）。 60年代と70年代）。
タッチ入力は、ほとんどの目的で機能するのに十分似ています。ただし、タッチなしの位置コンポーネントだけでなく、精度も不足しています。基本的に、すべてのタッチ入力は、何かに触れてドラッグするのに適しています。ダブルタップでさえ難しいので、私たちが本当に必要としているのは、タッチインターフェイス専用のUIを設計および作成する方法の根本的な変更です。
これの一部は、iPhoneなどの専用デバイスで見られます。これは、iPhoneがマウスポインタもキーボードも持たず、タッチするだけのプラットフォームだからです。これは、考えられるすべての対話方法で使用できるUIを構築する必要がないことを意味します（現在、Windowsを悩ませている問題です。私はマルチタッチのラップトップを持っていますが、多くのタスクでタッチが機能しません）しかし、1つだけです。しかし、「通常の」ソフトウェアとコンピューターの汎用ソリューションは、現時点ではかなり遠いものだと思います。
したがって、UIの設計方法について少し異なることを考えることをお勧めします。前に述べたように（そしてAlanCooperのAboutFaceで読むことができます）、ツールのヒントは、ラベルがない、またはラベルを配置するのに十分なスペースがないコントロールにラベルを付けるためのものです。ここでの主な使用シナリオはツールバーです。しかし、タッチ用に設計されたインターフェースは、とにかくすべてのコントロールを大きくします。密接にグループ化された多くの小さなアイコンは、ツールチップがある場合でも、精度が不足しているという理由だけで、タッチ入力で使用するのは面倒です。
ここを読んで考えさせられました。ツールチップは通常、テキストのないボタンにラベルを付けるために使用されますが、インターフェイスで使用できるスペースを減らしてより多くの情報を提供する優れた方法でもあります。場合によっては、状況に応じたヘルプや、1 つのウィジェットの詳細な説明を提供するために使用されます。
すべての GUI 要素に共通の動作を 1 回のクリックで提供し、ダブルクリックでツールチップを提供するというTchalvakのアイデアにはメリットがあり、要素に関係なく、表示されるすべてのものをダブルクリックすることに多くの人が慣れているため、多少発見しやすくさえなります。 .
?しかし、何年も前に非常に人気があり、クリックするとカーソルが疑問符に変わる古いボタンを思い出しました。ウィジェットをクリックすると、小さなツールチップまたは情報バルーンが表示されます。そのようなものは、タッチインターフェースで簡単に使用できると思います。カーソルがないため、別の視覚的な合図をユーザーに提供して、ユーザーがヘルプモードであることを知らせる必要があります。画面の色合いを変更して小さなテキストを表示する場合があります。ツールチップを取得するために別のウィジェットを押しながらボタンを押すことを要求することにより、マルチタッチを介して行うこともできます?(指で不明瞭にならないように、少し離れた場所に表示する必要があります)。
しかし、私たちプログラマーがツールチップを持つのと同じ技術的機能を維持することが可能であるとしても、それを何に使用するかという目的について考える必要があります。
小さな画面に直面しているときに拡張ヘルプを提供するためにのみ使用します。それ以外の場合は、「ウィンドウ」の下部に常にヘルプ領域が表示されるようにします (あらゆる種類の正方形の io インターフェースを指します)。 、その内容を変更して、選択したウィジェットの詳細な説明および/またはヘルプを提供します。これは、ホバー時の一部の設定ウィンドウで行われます。
結論として、使いやすいツールチップを提供できたとしても、そこに何を入れるかを考える必要があります。タッチ インターフェースでは、理解するためにツールチップが必要なラベルのないあいまいなボタンは配置しませんが、状況依存の高度なヘルプとトラブルシューティングを提供するために使用します。
この問題に対するいくつかの解決策を考えることができます
1) ツールチップを必要としないようにアプリを設計します。ボタンにテキストを配置する (小さいが)、わかりやすいアイコンを使用する、または「ボタンを最初に使用する」ときに「ヘルプ バブル」を表示する (ユーザーがボタンの目的を理解したら、「これを再度表示しない」オプションを使用)
2) タッチダウンではなく、タッチアップでイベントに応答します。「ヘルプ」バブルを表示して、0.5 ～ 1 秒間保持されたタッチに応答します。ヘルプ バブルが表示された場合、ボタンの通常のイベントはタッチアップ時に発生しません(ヘルプを探しているユーザーが最終的にアクションをトリガーすることはありません)。
3) @voyagerが提案した「疑問符」のドラッグ アンド ドロップ パラダイムを使用します。または、まず疑問符を「タップ」してから、ヘルプが必要な項目をタップしてもらいます。
オンスクリーン キーボードのツールチップ (タッチされた文字をエコーする) は、ツールチップがタッチ インターフェイスで非常に役立つことを示す十分な証拠です。この記事にたどり着いたのは、それをモバイル Web ページに実装する方法を確認するためです。
ツールチップは非常に役立つと思います。優れた UI デザインにツールチップは必要ないと主張する人は、非常に限定的なものだと考えています。
アイデアを提供するだけです...
一般的に、優れた UI デザインは (生活の他の多くのものと同様に) 、一定の使用時間にわたって効果的かつ効率的なものです。効果的な手段とは、できると思っていたことを実行できることです(例:携帯電話で電話をかける)。効率的とは、最小限のユーザー労力で実行できることを意味します(たとえば、最初にいくつかのメニューをナビゲートする必要がなく、数字を入力して「ダイヤル」ボタンを押すだけです)。一定期間が経過すると、最初の使用時に最適ではない可能性があることを意味します。空港ターミナルの画面は、Adobe Premiere のような専門家向けのビデオ編集ソフトウェアよりも、1 回限りのユーザーの「ダミー」に焦点を当てる必要があるかもしれません)。
これは、次のような状況でツールチップが非常に役立つことを発見したと述べています。
ここで、タッチ インターフェイスの制限と可能性に戻ります...
タッチアンドホールドはどうですか？使いやすさと実装の両方の点で、それはかなり単純なインターフェイス ルールになると思います。使いやすさに関する多くのことと同様に、1 つのアイデアがさまざまなコンテキストで使用されるのを確認するために、少し時間がかかるまで言うのは難しいでしょう...
私の答えはおそらくそれほど実用的ではありませんが...
すべてのアプリが元に戻す機能をサポートしていれば、この問題は解決するでしょう。
Andreas が言うように、「機能についてよくわからない場合は、ボタンをクリックするのをためらうでしょう」。
しかし、元に戻す機能をセーフティ ネットとして使用すると、より多くの「実行」を行うことができ、「躊躇したり、心配したり、タップする前に何が起こるかを調べたりする」ことを減らすことができます。
これが、[戻る] ボタンが非常に人気がある理由の 1 つであり、Android ではオペレーティング システム全体で使用されるようになりました。
残念ながら（これは非現実的です...）
アインシュタインを言い換えると、タッチは必要なだけ単純である必要がありますが、それ以上単純ではありません。
ここでの根本的な問題は、タッチではなく、状態です。触ったときのオブジェクトの状態は？タッチはその状態を変えますか？状態の変化はユーザーにどのように反映されますか？
設計の観点から、すべてのアクションをワンタッチで網羅しようとすると、最も単純な場合にのみ機能します。より便利なアプリケーションの場合、最初のタッチで状態が変わる可能性があり、その状態は、オブジェクトの画像の変化、ツールトップ（設定された時間の後に消える一時的なツールチップでさえ）、またはその他の手段によって反映されます。選択したオブジェクトに触れることは、選択されていないオブジェクトに触れることとは異なる意味を持つ必要があります。これは、インターフェースの検出可能な側面である必要があります。