フォーカス (GUI)

フォーカス: focus)は、グラフィカルユーザインタフェース (GUI) で現在入力を受け付けるよう選択されているコンポーネントを示す概念である。キーボード入力またはクリップボードのペーストは、その時点でフォーカスを持っているコンポーネントに送られる。

この概念は、テキスト環境でのカーソルに似ている。しかし、GUIでは同時にマウスカーソルも関係してくる。マウスを動かすとマウスカーソルも動くが、フォーカスは変化しない。フォーカスは通常、マウスボタンのクリックでフォーカスを付与するコンポーネントを指定することで変更する。多くのデスクトップ環境では、キーボードからもフォーカスを変更できる。一般に「タブ」キーを押す毎に順次フォーカスを付与されるコンポーネントが変わっていき、 Shift+ Tabで逆順に変化していく。状況によっては、矢印キーでフォーカスを動かす場合もある。

ウィンドウフォーカス

デスクトップでのフォーカスの振る舞いは、ウィンドウ管理のポリシーが支配している。マイクロソフトAppleのGUIでは、クリックに追随してフォーカスが移動するFFC[1]である。すなわち、あるウィンドウ内でマウスをクリックすると、そのウィンドウがフォーカスを得る。その際に同時にそのウィンドウが最前面に表示される。

UNIXX Window System では、マウスの移動に追随してフォーカスが移動するFFM[2]というポリシーもある。すなわち、マウスカーソルの現在位置に従ってフォーカスがウィンドウからウィンドウへ移動する。このポリシーの当然の帰結として、マウスカーソルの下が背景であってどのウィンドウの上でもない場合、どのウィンドウにもフォーカスがない状態になる。そこで、マウスカーソルがどのウィンドウ上でもない場所に移動したときは、直前までフォーカスを持っていたウィンドウが引き続きフォーカスを保持するというポリシー(: sloppy focus)もある。なお上述のとおり、マイクロソフトのGUIは通常FFCポリシー動作だが、Windows 10ではコントロールパネルでの設定によりFFMポリシーで動作させることも可能になっている。

どのポリシーがよいかは議論の分かれるところである。FFMの場合、マウスに何かが当たるなどしてマウスカーソルが意図せずに移動したとき、知らないうちにフォーカスも移動するという状況があり、初心者が戸惑うことがある。しかし、慣れてくると便利であり、特にフォーカスを得たウィンドウを最前面にしないポリシーと組み合わせると、様々な制御が可能になる。例えば、大きなウィンドウが背面にあって小さなウィンドウが前面にあり、これらウィンドウ間のコピー・アンド・ペーストをするときに、ウィンドウ配置(前後関係)を全く変えることなく実行できる( Alt+ Tab でアクティブウィンドウを切り替える必要がない)。

FFMは、メニューバーが個々のウィンドウ内に組み込まれているようなインタフェースでのみ実施可能である。macOS のように単一のグローバルなメニューバーが画面上端にある場合、画面下部にある小さいウィンドウのメニューを使おうとすると、まずそのウィンドウにマウスカーソルを移動させてフォーカスを与え、続いて画面上端まで他のウィンドウを横切ることなくマウスカーソルを移動させなければならない。したがって、非常に使いにくくなる。

ウィンドウ内のコンポーネントのフォーカス

テキストの入力や編集ができるコンポーネントには、それぞれにカーソルが存在する。そして、そのカーソル位置でテキスト編集をするには、そのコンポーネントにフォーカスが無ければならない。

ウィンドウ内でどのコンポーネントがデフォルトでフォーカスを得るか、コンポーネント間でどのようにフォーカスを移動するのか、はインタフェース設計の重要だが難しい問題である。間違ったところにフォーカスがあると、ユーザーはフォーカスの移動に時間を浪費することになる。逆に適切なところにフォーカスがあれば、ユーザーエクスペリエンスの向上につながる。

関連項目

脚注