マーキングメニューが線形メニューよりも効率的である場合、なぜそれらが採用されていないのですか？
マーキングメニューを使用したユーザーの学習とパフォーマンス KurtenbachおよびBuxton（1994）の論文 demonstrates マーキングメニューがより効率的であること線形メニューよりも。そして私には、彼らは直感的に同じように見えます。
それらが業界で採用されなかった理由は何ですか？一般の人がいなければ、パワーユーザーの方が効率が良いと思います。
ここ は論文の要約です。
私はいくつかの理論を持っています。
マーキングメニューの効率は、「心の中の知識」に依存しています。ドンノーマンは、UXの「心の知識」と「世界の知識」の違いについて、本「Design of Everything Things」で語っています。心の知識は素晴らしいですが、学習と親しみも必要です。コンピュータはまだ多くの人にとって、そして80年代から90年代にかけてはそれほど親しみのないものでした。この時点で、その前線に大きな変化が生じるまでには、しばらく時間がかかります。
ポイント1は重要ではないと言えるかもしれません。マーキングメニューは通常どおりに使用でき、これは本当のことですが、当時のプログラミングはかなり難しく、開発者は抵抗が最も少ない経路をたどる傾向があると思います。また、マウスは当時はそれほど良くありませんでした。私は、メニューのマーキングに関するアクセシビリティの問題があり、器用さが制限されている一部の人々が使用するのを困難にすることを想像しています。
それらは使用されます。たとえば、「スワイプタイプ」のキーボードや画面ロックなど、すぐに認識できるわけではありません。
多分それほど広く使われていない理由は-デビッドが言うように-記憶への認知的負担です。
理由：ショートカットとジェスチャー
従来のメニューは、頻繁に使用され、常に同じように見えるため、頻繁に使用しない場合と同じくらい高速で、摩擦が少なくなります。
ユーザーが多くの異なるケースで同じアクションを繰り返したい場合、通常はアクションのキーボードショートカットを学習します。これはさらに速く、信頼性が高く、広く使用されています。したがって、マークメニューの唯一の使用例は、ショートカット/キーボードにアクセスせずにアクションをすばやく繰り返し選択する必要がある場合です。
また、これらの場合、ヒント付きのジェスチャー（本質的にはマークメニューによく似ています）が一般的です->スマートフォンでギャラリーを閲覧し、左右にスワイプして[次/前の画像]オプションにアクセスし、上にスワイプして画像を削除します。
もちろん、これについて理論化することしかできませんが、開発者の観点から、HTMLの始まりについて考えてください。ほとんど（すべてではないにしても）のメニューは、（現在のように）ULである必要があるにもかかわらず、テーブルでした。円形または放射状の形状は、画像以外には存在しませんでした。線形ビルドはその制限の結果だと思います。
現在、直線性を使用して数十年が経過した後、ほとんどの人はメニューの動作を一目で理解できます。 XEROXマシンを使用している場合は、ラジアルメニューを使用していないことにも気付くと思いますので、今日の結果は同じではないでしょう。
個人的に、プロジェクトの 循環ナビゲーションチュートリアル に基づいてこのようなことを試してみましたが、結果がかなり悪いことがわかりました。テストでは、誰もが美的観点からそれを気に入っていることを示しましたが、誰もが本当に混乱していました。また、複数のレベルがある（本当に面白い）ビデオとは異なり、1つのレベルのみを使用していたので、破棄したことを覚えておいてください。したがって、私は人々が線形メニューが伝達するアフォーダンスを理解していると仮定しなければなりません
このアプローチはスケーラブルではありません。メニュー項目を追加するとターゲット領域は小さくなりますが、線形メニューの場合は同じままで、多数の最上位メニューオプションを簡単に処理できます。
オプションの数が少ない状況では、メニューパラダイムに変化の可能性があり、この変化には認識上の負担があるため、おそらく行う価値はありません。
いくつかのことが頭に浮かびます：
- 学び、適応する時間。キーボードレイアウトと同様に、Dvorakレイアウトはおそらくより高速ですが、ほとんどの人はすでにQWERTYを学習しています。平均的なユーザーの潜在的な速度向上は、新しいアプローチを学ぶのに十分重要ではありません。
- 私の経験では、マーキングメニューはタッチパッドではうまく機能しません。多くの人はラップトップでマウスを使いません。