mieki256's diary



2013/03/26(火) [n年前の日記]

#2 [pc] プラグインメニューが長くなってきてちょっと困ってる

GIMPのプラグインメニューがちょっと長くなってきていて。どうしたもんか、どうにかならんかと。
GIMP menu

ついでに言えば、Audacityのプラグインメニューも長過ぎて困ってたり。
Audacity menu

さらについでに言えば、Metasequoiaのメニューも長過ぎて。
Metasequoia menu 1
Metasequoia menu 2
まあ、Metasequoia は、 _Custom Menu というプラグインを使うとこのへん劇的に改善するのでアレなんですけど。本当に、このプラグインはありがたい…。

FL Studio も…。いや、これはまだ、横に広げてくれるだけマシですけど。
FL Studio menu

とにかく、その手のアレは、メニューを選択した瞬間、こんな気分に。
うわ…
*1

「ちょ、おま、プラグイン入れ過ぎwww」とか笑われそう。いやいや、でもさ、「これは便利そう!」→「いつか使うかもしれない!」→「とりあえずインストール!」てのがプラグインってものじゃないですか? だから仕方ないよね? ね? *2

しかしこのあたり、ユーザの性癖を笑って馬鹿にして済ませられる程度の話ではないよなー、と思っていたりもするのです。要するにコレって、GUIにずっとまとわりついている問題なわけですよ。

GUIにまとわりついてる問題。 :

  • Microsoft Office 2007 がリボンUIを導入したのはなぜか?
  • Windows Vista/7 がスタートメニューの大改編を行ったのはなぜか?
  • Ubuntu Linux が Unity Dash を盛り込んだのはなぜか?
さて、なぜでしょうか、と。

「GUIを用いた製品は、高機能化に伴って、メニュー項目数が膨大になってしまう」
「メニュー項目数が増えると、目的の項目を探し出すことすら困難になる」

そういう問題が、GUIにはずっと存在しているわけですよ。そして、各OS・各アプリは、その問題をどうやって解決するか悩みに悩んで、それぞれがこういう解答を出してきた、というのが現状なわけで。

前述の、プラグインメニューのスクリーンショットもソレで。プラグイン追加で、機能はどんどん増えていく。増えていくけど、呼び出すことが困難になっていく。その実例の一つ、と言えるわけです。

実は、今から15年以上も前、Windows 95/98の時代ですら、一応そのあたりについて解答は盛り込まれていました。
  • スタートメニュー内の項目の並び方を、ユーザが好きなように変更できた。
  • スタートメニューが入っているフォルダの中にサブフォルダを作ってショートカットファイルを移動すれば、ユーザが好きなようにメニューを階層化できた。
つまり、メニューにおける「並び」と「階層」、この2つをカスタマイズすることができたわけですが。個人的には、この2つをユーザがカスタマイズできるだけでも結構違うだろうと思っているのですけど。
  • 並びを変えられたら、自分がよく使いそうな項目だけを、選びやすい場所に持ってくることができる。
  • 階層化ができれば、一度に表示される項目数を絞れる。画面全体にメニューが表示されて「うへえ」と思わずに済む。

しかし、前述の、GIMP、Audacity、Metasequoia、FL Studio などのアプリは、それすらできないわけで。
  • 各プラグインが、自分がどの階層に配置されるべきかの情報を持ってしまっている。ユーザがその情報を任意に変更できず、階層をカスタマイズできない。
  • メニュー項目の並びが、アプリ本体が持つ特定のルールに支配されていて、変更できない・固定されている。
今更、プラグインの仕様をUIを快適にするために変更します、なんてことはできませんし。プラグインは、そのアプリにとっての貴重な資産ですから、ソレを一旦捨てるなんてことはできない。なので、改善しようにも、これはなかなか厳しい。…言い方は悪いですが、それらアプリのGUIに対する取り組み・思想は、Windows 95が発売された1995年のレベルにも未だ至っていない、とすら言えてしまうのかもしれないなあ、とチラリと思ったりもします。

もっとも、各アプリは、メニュー表示をライブラリに任せてるだけなのでは、という気もするわけで…。もし、それぞれが使っているライブラリが、メニュー表示の処理に関して、何か改善を盛り込めば、それだけでずいぶん印象が違ってくるかもと想像していますが。例えば…。
  • 縦方向にだけ項目を並べず、FL Studio のように(あるいは昔のWindowsのように)横方向も活用するとか。せっかく16:9の横長ディスプレイが普及してるのに、ドット数が少ない縦方向ばかり使うのは理に適ってないですし。
  • 画面内に項目が収まらない時は、スクロールバーを出してしまうとか。何がツライかと言えば、最上部 or 最下部の三角マークを押し続け、目的の項目がスクロールで出現してくれるのをじっと待ってるのがツラいわけで。スクロールバーで「大体このへんにあったはず」と一気にスクロールできたら、能動的に操作してる感が得られて、全然違うだろうなと。
もちろん、アプリ本体でもできそうなこともありそうですが…。
  • pluginsフォルダ内に、特定の命名規則でフォルダを作り、そこにプラグインを入れたときだけ、フォルダ名に従った階層表示にするとか。例えば、「!生成」「!変換」等、頭に「!」をつけたフォルダ名にすると、そこだけ階層として扱いますよ、等々。
もっとも、そんな修正してる暇があったら、画像編集、波形編集、3DCGモデル制作等、目的とする作業に関する内部処理を改善したい、機能を追加したい、とフツーは思うでしょうし。

まあ、このへん色々と難しいですよね、ってことで。あの Microsoft ですら、毎回悩んで、違う解答出してきますし…。

とりあえず、そういう問題がGUIにはあるよねえ、てなだけの話でした。まあ、GUIに限らず日常生活の中にも似た問題がゴロゴロしてそうですけど。…なんとなく、「その手があったか!」てな解答がどこかにありそうな気もするんですが。

ジョブズは、パロアルト研究所でAltoとGUIを見て、ビビッときてLisaやMacを出したらしいけど。その当時、メニュー項目数が膨大になったらコレどうしようか、みたいなことを考えてた人は居るんだろうか。実はその当時の研究内容の中に、改善するための種があったりしないのかなあ。

Windows Vista/7のスタートメニューやUbuntuのDashとかそのへん。 :

余談。昨今のWindowsのスタートメニューや、UbuntuのDashを使ってると、これってGUIからCUIに戻ってるよなと思ったりするわけで。メニュー選択型のADVから、コマンド入力型のADVに逆戻りしてる印象が。

コマンド入力型は、以下の条件を満たしてる時は便利で速いわけですけど。
  • メニュー項目数が膨大で画面に収まらない。
  • 項目名をユーザがある程度覚えている。頭の中に、使いたい機能名・アプリ名が既に浮かんでる。
逆に、上記の条件を満たしてない時は、メニュー選択型のほうが便利で速いのですが。
  • メニュー項目数が少ない時は、マウスなりカーソルキー(十字ボタン)なりで選んだほうが速い。
  • 項目名をユーザが忘れてしまっていたら、コマンド入力型は手も足も出なくなる。
Emacs系のエディタとかそうですよね。「こういう機能があったはず。でも、なんてコマンド名(関数名)だったっけ…?」てな状態に自分はたまになるんですけど、こうなるとかえって時間がかかってしまう。

つまり昨今のWindowsやUbuntuは、大昔、皆がCUIでバシバシと操作してたあの感覚を、一般ユーザにも強要しようとしてる、とも言えそうな、そんな気もしていたりするわけで。…まあ、補完機能が強力なら、どうにかなるのかもしれないですけど。

いや、Ubuntu はともかく、Windowsは違うか。Windows8 のデスクトップは、またGUIに揺り戻しをしているような気もしてきた。指でポンポン選ぶだけで使えますよ、と嘯いて(?)ますもんね…。メニュー選択型へ戻ってるよな…。

おそらく、初心者に優しいのは、メニュー選択型ですよね。ファミコンのADVやRPGがコマンド入力型だったら、あんなにヒットしなかったと思うのですが。…本当にそうかなあ? どうなんだろう。

*1: _PAKUTASO - WEB制作向け無料写真素材 の写真を使わせていただきました。この写真、実に使えますねえ…。
*2: まあ、単に自分のコレクター属性が云々、てな話でしかないのかも、とも思うのだけど。

以上です。

過去ログ表示

Prev - 2013/03 - Next
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project