地図作成タッチアプリケーションの要素との相互作用
私は現在、地図作成と要素操作を扱うタッチタブレットアプリケーションを設計しています。地図上の要素を操作してタッチ操作できるようにする必要があります。
- 情報を取得
- 地図上のアイテムを移動する
- アイテムを削除する
- メールアイテム
- アイテムレイヤーを変更する
したがって、ある種のコンテキストメニューが必要です。タッチメニューに対応し、エラーを最小限に抑える必要があります。私は3つの州法を念頭に置いています。
- サイドコンテキストメニュー
- パイ/ラジアルコンテキストメニュー
- 下部画面のコンテキストメニュー
大規模なモノタッチデバイスでのこれらの戦略の実装の成功または失敗に関するフィードバックはありますか？ （12インチまたは15インチ）
誰か他の戦略を考えていますか？
どんなフィードバックもありがとう！
「サイドコンテキストメニュー」とは、クリックした場所の横に表示される通常の右クリックメニューを意味すると思います。
円グラフメニューは、テキストではうまく機能しないことを除いて、すてきです。パイメニューの最も適切な実装には、アイコンのみが含まれます。テキストのみのアイテムもいくつか見ましたが、見た目はめったにありません。そして、私はこれまでにアイコンとテキストのあるものを見たことはないと思います。
画面下部のメニュー、または固定された場所の他の場所には移動しません。お使いのデバイスは大きく、多くの場合、選択したオブジェクトとメニューの間を移動するのに長い距離になる可能性があります。少なくとも場合によっては、メニュー項目をアクティブ化した後でオブジェクトに戻る必要があります。地図上のどこかに移動します。 「その場で編集」のアプローチを使用することは、タッチデバイスの一般的なガイドラインであり、あなたのケースはそれほど変わらないようです。
サイドメニューを使用すると、オブジェクトが画面の端にある場合を簡単に解決できます。反対側にメニューを表示するだけです。ただし、パイメニューを使用すると、オブジェクトをその中心に配置しようとすると、注意が必要になります。別のオブジェクトの中央に配置される可能性があるため、オフセットで表示することはできません。サイドメニューではこの問題は発生しません。
最近、他のケースの中で、ユーザーが大きなセンサー画面（17〜22インチ）の右側/下側にあるシンプルなコンテキストメニューとサイドメニューを操作することをテストしました。つまり、タッチゾーンの近くに表示されるクラシックコンテキストメニューはるかに感謝しています。
その理由は、クラシックコンテキストメニューはクラシック（パンを許して）であるため、ユーザー（私の場合は保守的）がタッチ領域の近くに表示されることを期待していたため、ほとんど直接的な操作になっていました。
画面の面積が大きく、ユーザーが近くに座っている傾向があるため（手で操作するため）、視野角は通常のキーボードとマウスのインターフェースよりも大きく、気付かないことさえあります。 、その新しい何かが画面の端のどこかに現れました（特に下部の細長いメニューの場合）。 Edgeでコンテキストメニュー項目に触れるために、画面上で手を大きく物理的に動かすのも不便でした。
私の場合にクラシックコンテキストメニューを使用するもう1つの理由は、将来アイテムを追加できる可能性であり、下部のメニューにはグループ化の実質的な制限があり、7〜10を超えるアイテムを含めることができました。区切り記号や色分けは、通常のコンテキストメニュー定規の場合ほど明確ではありませんでした。それも、ラジアルメニューが考慮されなかった理由です。以前のプロジェクトでも、ラジアルメニューのユーザーが、現在の要素のコンテキストではなく、ある種のナビゲーションコントロールとして認識していることがありました（プラス/マイナス/矢印アイコンが含まれていませんでした）。おそらくGoogleマップとの類似性が原因です。ユーザーが精通しているローカルジオサービスコントロール。そのため、アイコン付きのラジアルメニューのアフォーダンスは非常に低くなりました。
移動にコンテキストメニューを使用しないでください。代わりに、ユーザーがピンを長押ししてピン移動モードに切り替えることを許可します。
コンテキストコントロールは、ユーザーがタップする要素の近くに表示する必要があります。たとえば、Googleマップでピンをクリックしたときにgoogleがポップアップを表示する方法や、Appleのポップオーバーなどです。ただし、これによりマップの一部が不明瞭になることに注意してください。ラジアルメニューの場合、すべての方向が見えなくなります。