一括操作UIの設計で感じたセレクトボックスの弱点

たとえばブログの管理画面。記事一覧画面で複数の記事に一括でなんらかの操作をさせたい場合があります。こうした複数項目の一括操作のためのUI（ユーザー・インターフェイス）にはセレクトボックス（プルダウンメニュー）が用いられている例が多く、なんとなくその例にしたがって「セレクトボックス+実行ボタン」の組み合わせでデザインすることが多かったのです。

ですが、セレクトボックスが適さないのでは、と思われる例がありました。それは一括でおこなう操作の中に、特に注意を要する項目が含まれる場合です。ブログの記事一覧画面を例に説明します。

記事一覧の上に一括操作を制御するためのUIがあります。セレクトボックスがあり、その中には以下の要素が入っていました。

1. 記事の公開
2. 記事の非公開
3. 記事メタデータ（カテゴリ等）の編集
4. 記事の削除

絵にするとこういう感じです。

このインターフェイスの弱いところは誤って削除を選択してしまいやすいことです。一括操作の影響は大きいため［削除］は間違って押してほしくないので、他の項目とは視覚的に差別化したいという要望が出てきます。仕様上ゴミ箱（削除した記事を即削除せず、一旦保存しておく領域）が用意できない場合などはとくに注意が必要です。

そこで1〜3をセレクトボックスとし、4の［削除］は独立したボタンとすることにしました。

今度はセレクトボックスの実行ボタンと削除ボタンが隣り合うことになり、こちらはこちらで危なっかしい感じがします。「実行」「削除」が並ぶと、［削除］が［一括操作］というラベルでなくセレクトボックスにかかっているような感覚を覚えてしまいます。

ボタン間のマージンをしっかりとって誤操作を回避することもできますが、そうすると「一括操作のグループである」というグループ感が薄れ、ちょっとしまりがない感じになりそうです。縦罫線を仕切りに入れてみても同様です（下図）。

［実行］ボタンをなくしてセレクトボックスを選択した時点で実行する…というやり方もありますが、一括操作のようなやり直しがしにくい操作には明らかに向いてないので除外（そもそもセレクトボックスを選択した時点で実行されるやり方は操作ミスが多くなりよろしくないと思っています）。

考えた結果、セレクトボックスに代わる方法として今回はボタングループを採用することにしました。それなりに幅はとりますが項目数がそれほど多くないので、すっきりとまとまっています。

こうすれば一括操作系のまとまりは保ったまま、［削除］ボタンだけ独立しているように見え、誤操作を防ぎやすいのではないでしょうか。またできる操作がひと目で分かるようになり、操作に必要なクリック数もかなり減らせます。ただしこれでも削除ボタンが誤って押される可能性は高いので、削除確認のダイアログボックスを用意しこれからおこなう操作への注意喚起をおこなう必要はあります。

以上は実際にUIデザインに関するミーティングの中であったブラッシュアップ過程でした。
その結果いくつかセレクトボックスの弱点というべきものに気づきました。

• セレクトボックスは項目が隠されているため、メニューが出現するまで注意を要する操作が含まれることが意識しにくい
• セレクトボックスは項目を選択してから別のボタン（実行ボタン等）を押すことで操作が実行されるものが大半だが、まれにセレクトボックスの選択肢をクリックした時点で実行されるものがあり、初見のユーザーには警戒感を抱かせてしまう。
• 実行ボタンを含めると結局それなりの幅をとる
• 実行ボタン付きのセレクトボックスによる操作の実行には比較的失敗しやすい3つのクリック（開く・マウスアウトしないように注意しながら選ぶ・実行する）が必要であり、比較的ユーザーの操作負荷が高いインターフェイスである

省スペースかつOSのインターフェイスでもおなじみであるがゆえ、つい利用してしまいがちなセレクトボックス（ドロップダウンメニュー）、場合によってはボタングループやラジオボタンに代えたほうがスッキリ使いやすくなる場合も多くありそうです。UI設計の際にちょっと意識してみてはいかがでしょうか。

追記

続きを見る

公開と非公開は記事ステータスの変更としてグルーピングに違和感はないけど、編集は執筆側の気分としては大きく違う感じがするし、削除はまた別のオオゴト感がある。

— sunami hokuto (@shokuto) October 17, 2017

さっそく @shokuto さんからこのようなツッコミが。たしかに［公開 | 非公開］でグループ化して［編集］と［削除］は独立したボタンにしたほうが多くのケースでよさそうに思えます。ありがとうございます。