個々のケースでは、HUDはユーザーが望むものを可能な限り正確に推測しようとします。これにより、ユーザーの特定のスタイルにより良く適応するたびに、入力されたものと起動されたものの間の以前のすべての関連付けを記憶します。 いずれにせよ、HUDが最も近いオプションのセットを提供するたびに、必要なものを正確に選択できます。 たとえば、文字「rad」の組み合わせは、GIMPアプリケーションでコマンド「Radial blur」を提供します。「D」を入力すると、ファイルを削除するか、ドキュメントのプロパティを編集するように求められます。
シャトルワースは、HUDを使用すると、新しいメニュー構造を再理解することなく、新しいソフトウェアを習得し、新しいWindowsユーザーに移行することがはるかに容易になると考えています（HUDは従来のサブメニューよりもはるかに直感的で理解しやすいと想定されています） ）
新しいメニューシステムには2つの主な目的があります。 まず、HUDシステムは、ほとんど使用されないコマンドを含むすべてのコマンドに標準アクセス方法を提供します。これには、原則として、階層メニューからシステムにグラフィック表示がありません。 第二に、マークは、このアプローチにより、システムとそれ自体のアプリケーションコマンドのセットの両方を、論理的に統一された空間ですべて見ることができると考えています。 現在、内部アプリケーションコマンドは、システムのすべての機能（Unityインターフェイスの概念の主要な目標の1つ）を組み合わせた、他のコマンドと同じ「ネスト」レベルにあります。
古いアプローチと新しいアプローチの両方に長所と短所があります。 マークは、従来のグラフィックメニューでの作業には多くの時間がかかると考えています。 多くのアプリケーションがあり、ユーザーが正確に必要な場所を覚えていない場合、何かの検索が非常に長くなることがあります。 HUDを使用すると、アプリケーションの名前の少なくとも一部を覚えて、アプリケーションに即座に「手を差し伸べる」ことができます。 マークは、ホットキーがこの問題を部分的に解決した場合、HUDインターフェースはいずれの場合でも簡単になると考えています。なぜなら、短いキーワード（または選択可能ないくつかの単語）、プログラム名の一部、または特定のコマンド顔のないキーの組み合わせよりも。
HUDの欠点は、ユーザーが何を望んでいるかを明確に理解する必要があることです。 また、HUDを使用すると、ユーザーのメモリの負荷が増加し、キーボードとの対話が必要になりますが、Linuxユーザーのコンソールへの傾向を考えると、このアプローチは非常に合理的です。 ただし、これにもかかわらず、HUDと共存する古い視覚メニューは当面は保持されます。
したがって、Markによると、おそらくHUDはUbuntu 12.04で初めて導入され、グローバルメニューをサポートするすべての標準Ubuntuアプリケーションで利用可能になります。 従来のメニューのサポートは完全に保持され、HUDシステムはオプションとして含まれます。 Ubuntu 12.04の現在利用可能なテストリリースでは、unity-team / hud PPAリポジトリからHUDをインストールできます（sudo add-apt-repository ppa：unity-team / hud; sudo apt-get update && sudo apt-get dist-アップグレード）。 HUDインターフェイスは、Altキーを押すとアクティブになります。
しかし、この形式のHUDは始まりにすぎません。 これらの同じコマンドが音声で与えられる場合、2番目の論理ステップは音声認識です。 実際、HUDの現在の「中間実装」は、計画されているすべての変換の主な最終目標である、将来の音声制御のためのグラフィカルインターフェイスの予備的な適応です。
HUDアプローチは、一方でコンピューターユーザーがアプリケーションワークスペースに完全に集中できるようにするために、コントロールの混乱からモニターのワークスペースをクリアするという主要な概念目標を追求します（Microsoftリボンコンセプトに基づく製品で行われる方法とは対照的です）一方、システムコマンドをできるだけ簡単かつ高速にするため。
opennet.ru経由
出典www.markshuttleworth.com/archives/939