ツールバーボタン-存在するかどうか
アプリケーション用のツールバーを作成する必要があります。外部の制約により、リボンではなく通常のツールバーである必要があるとしましょう。アプリケーション自体には多数の機能があり、問題は次のようになります。ツールバーに配置する機能をどのように選択するか？
さまざまなユーザーインターフェイスのガイドラインでは、ツールバーは「最も一般的な機能」をホストする必要があると述べています。しかし、それが何を意味するのかは本当に不明確です。ツールバーに含まれるに値する関数はどのくらいの頻度で使用する必要がありますか？どのようにユーザビリティテストを行って、ツールバーにあるボタンを理解し、すでに存在するボタンを削除する必要があるかを検出する方法を教えてください。
私自身の経験に基づくと、アプリケーションがツールバーの機能を正しく使用することはほとんどありません。たとえば、Total Commanderツールバーは次のようになります。 
私never自分で置いたボタン以外のボタンは使用しません。
Notepad ++ツールバーはおそらくより優れています（少なくとも、ほとんどのボタンの機能を理解しています）。 
それでも、キーボードショートカットを使用する代わりに、ツールバーから「カット」、「コピー」、「貼り付け」、「元に戻す」、「やり直し」を使用するユーザーを想像するのは困難です。また、「ユーザー定義ダイアログ」または「マクロの記録」を作成する必要がある頻度はどれくらいですか？
ボタンのためのスペースがあるという理由だけでボタンをスローするのは良い方法ですか？それとも、それを最低限に保つというGoogle Chromeのアプローチはより良いですか？
ユーザーがメニューから同じコマンドを選択するよりも速くクリックできるという点で、ツールバーボタンがあることには一般に利点があることを理解しています。ただし、インターフェイスが煩雑になり、他のツールバーボタンが見つけにくくなるという点で、各ツールバーボタンに関連するコストもあります。この場合、どのようにしてコスト/メリット比を評価できますか？
編集：役立つ場合、私が書いているアプリケーションはIDEであり、ターゲットユーザーはプログラマーです。これはデスクトップアプリケーションであり、当初はWindows専用に開発されました。
ここではデスクトップアプリについて話していると想定しています。さらに、私はあなたが構築しているアプリのタイプを本当に知りませんが、「良いUXに到達するためにどれだけのクリックが必要か」という質問に悩まされることなく、ユーザーのニーズを調査するのにいくつかの助けを提供できます。あなたの例のほとんどはテキストエディタにあるようです。それで、私たちはそれで行きます。
私の推奨事項は、最初にビルドしてユーザーがそれをどのように使用するかを比較すると、少し奇妙なものです-「それ」はツールバーそのものです。
反復数0.1-ツールバーを完全に削除し、キーボードショートカット-メニューのみ。一部の内部関係者（あなた自身を含む）が少しの間それを使用するようにします（それがあなただけの場合、1日か2日をyoと同じようにアプリで遊んでください-あなたは自分のアプリを使用します、そうです）、そしてそれらのユーザーと考古学を実行します（IDEOから採用された概念）彼らは何度も何度も行くメニューアイテムですか？メニューに移動する前に、キーボードショートカットがあるかどうか尋ねたり、想定したりしていますか？あなたがしなければならないのは、特定のメニュー項目へのクリック数を数えることだけです。
この方法でアプローチすることの利点は、とにかくメニューを構築する必要があることです少なくともMacでは）個々のベンダーによってリリースされたアプリケーションのほとんどの無視された部分の1つ-この方法では、1つを構築する必要があります。
だから、あなたはホットボタンを知っています-クリック数が最も多いもの。今度はラウンド0.2-ユーザーが最もクリックしたメニュー項目のキーボードショートカットを作成します。繰り返しますが、これらのものを測定します。ユーザーがキーボードショートカットを確認した後、メニューの---（代わりにを使用する頻度はどれくらいですか？これらはおそらくツールバーのどこかにいる素晴らしい候補です。
想定をテストすることなく、ほとんどのことを想定しないでください（多くのアプリを見たり、CEOの話を聞いたりして、「ユーザーは知っているので...それは可能な限り）
これで、ツールバーを作成する準備が整いました。あなたは人々が最もよく使う機能を知っています。あなたは人々がキーボードショートカットを学ぶために最も速く試す機能を知っています。また、ユーザーがすでにキーボードショートカットを持っていると想定している機能と、その機能についても理解しています。人々がメニューに頻繁に行った関数は、すでに0.1からのキーボードショートカットがあると想定されていますおよび 0.2ではメニューの代わりにショートカットの使用を開始しました-実際にツールバーに移動する必要がない場合があるため- 0.1にショートカットがあると想定している場合や、0.2にショートカットを記憶している場合は、デフォルトでthatインタラクション方法（カット、コピー、貼り付けなど） ）。
人々がメニュー項目を頻繁にクリックしたものは、0.1にショートカットがあるとは想定していませんでしたが、0.2で初めてそれを見てすぐにショートカットを学びました-ツールバーにあるかなり良い候補（太字、斜体、下線など）。ドロップダウンが含まれるもの-かなり良い候補（font-faceや-familyなど）。
ここで、より不明瞭な機能と考古学の部分に触れます。通常、これらすべてのアイテムが関係しているため、実際には0.1や0.2をクリックしていませんでした（おそらく、ショートカットも追加していません）。しかし、ユーザーがメニューでそれを見つけようとしているのを見たとき、彼らは欲求不満になり、早く見つけたいように見えましたが、できませんでした。これらのアイテムは、どういうわけか簡単にアクセスできるようにすることを検討したいものですが、必ずしも「ユーザーの顔」にあるわけではありません。たとえば、MS Wordの「スタイル」メニューをApple Pages：
MSのリボンの例では、スタイルは常に存在します-ツールバーのスペースを占有します-多くのユーザーが実際にそれらをあまり使用していない、および/またはヘッダースタイルを変更する必要があるドキュメントを作成していないにもかかわらず、箇条書きに変更します。これは、スタイルペインからまたはで実行できます。 AppleのPagesの例では、青色の段落記号を押すとスタイルドロワーが表示されます-もう一度押すとスタイルドロワーが非表示になります-オプションで常に表示されるか、ユーザー設定に基づいて非表示になりますが、トグルはツールバーにあります。
これを0.3としてもう一度テストします。その後、人々があまり使用しないそれらの三次機能を発見します。彼らが見つけることができず、ショートカットがないほどひどく動揺していない。次に、それらにアクセスする方法を作成します。ページの場合、これはインスペクターを介して処理されます。これは、タブ付きのナビゲーションでポップアップする単なるダイアログボックスです。
これで、完全に（比較的言えば）機能的なメニューが作成されました。実際の使用に基づいたショートカットキーは、推測ではありません。ツールバーで常に何を利用できるようにするべきかについてかなりの知識があります。そして、あなたはあなたがすぐに、しかしオプションで利用可能にしたいかもしれないアイテムを持っています。ユーザーのクリックが途中のどこかにあったアイテムを見て-あなたの最善の判断を使用してください（たとえば、ページでは、私はその列ボタンを決して使用しませんが、必要な場合はあります-ドロップダウンでもあることに注意してください、これは一般的にツールバーの主要な領域です）。
これがIDEであることに応じて。おそらく、これらはコンピューターのマニアである可能性が高く、おそらくショートカットを頻繁に使用しているでしょう。 「メニューを作成する」という最初のコンセプトを使用するのは問題ありません。
私が知っている「彼らがX回クリックした場合」というルールは本当にないので、それが役に立てば幸いです。
まず最初に、カードの並べ替えを使用して、同じグループに含まれる機能を特定します。その後、最もよく使用される関数をツールバー自体に直接表示したままにし、残りをドロップダウンメニューで非表示にすることができます。
最も使用されている機能を判断するにはどうすればよいですか？そのためには、構築しているアプリケーションのコア機能を評価する必要があります。テキストエディタの場合、通常のテキスト編集のショートカット、カット、ペースト、編集などは、通常、ツールバーに保持するのに適したオプションです。どんな申請をしていますか？教えて頂ければもっと具体的になります。
さて、必要なものだけが残るまでインターフェースからすべてを取り除くという概念は、優れたデザインの本質です。ブラウザでは、表示されているページコントロールと検索機能（firefox、chrome、safariなど）を除いてすべてを削除するのが理にかなっています。残念ながら、アプリケーションの場合（Webページを表示するよりもはるかに多くの機能があるため、より難しい仕事。
最後に、ユーザーテストは、ツールバーで必要な機能を確認するための優れたテストツールです。
編集1私の個人的な経験から、テキストエディタIDEの2つの極端を説明できます：フルスケールのツールバーを備えたNotepad ++と、コード自体の概要のみを備えたインターフェイスを取り除いたSublime Text。
これら2つのエディターを比較してみましょう（UI的には）：
崇高なテキスト：主な機能は、ここに表示されるテキストの概要です。それを除けば、あなたを威圧するボタンやツールバー、標準のテキストエディターメニューバーはありません。
Notepad ++：テキスト編集、マクロなどのさまざまな機能を備えた巨大なツールバーに直面し、その上にいくつかの追加のIDEメニューが付いた標準メニューがあります。
主なIDEとして崇高なテキストを使用している多くのプログラマー/開発者を知っています。主な理由は、インターフェースのシンプルさと美しさです。主な理由は、ユーザーが経験豊富なユーザーであれば、テキストエディターIDEが提供する必要があるすべての機能を十分に認識していることです。メニュー内に移動して、環境の設定をカスタマイズできます。それはそれだけです。環境はプログラマーが時々（その場で）変更するものではありません。そのため、永続的なツールバーは必要ありません。崇高なテキストがこのスイートスポットに当たり、素晴らしい概要機能が追加されました。
レッスン：美しさとシンプルさは、かさばる機能よりも勝っています。
ツールバーのボタンをクリックするだけであると想定しないでください。クリックだけでボタンの有用性を推定しないでください。
Notepad ++の画面写真を見たとき、私はそれを考えました。 Notepad ++では、[元に戻す]/[やり直し]ボタンをクリックすることはほとんどありませんが、頻繁に使用しています。 それらを見るだけで。これらのボタンは灰色または緑色で、元に戻すまたはやり直すことができるかどうかを教えてくれます。これは私にとって非常に便利です。私はEclipseでこれらのボタンを見逃しています。
Microsoft Outlookのようにカスタマイズ可能なツールバーの場合ボタンの追加/削除についてはどうですか？
UXに関しては、個人ごとに好みが異なります。特にパワーユーザーです（そして、投稿によると、ユーザーはプログラマーであり、おそらくパワーユーザーです）。では、このツールバーに表示したいものを選択させてみませんか？
補足として（これは質問の最初の範囲から少し外れるかもしれませんが、UXに関しては、ビューを広げる必要があります）ツールバーは、関数にアクセスする唯一の方法ではありません。他にもさまざまな方法があります。探索できます（特定のユースケースに適用できる場合）：
- キーボードショートカット
- 右クリックメニュー
- コマンドライン（一部のアプリケーションは、コマンドを実行できるコンソールを提供します）
- マウス/トラックパッドのジェスチャー