Home > Latest topics

Latest topics > 設定を簡単に変更できるようにすること、を必ずしも重視しませんよという話

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

設定を簡単に変更できるようにすること、を必ずしも重視しませんよという話 - Jul 24, 2009

掲示板で書いた事を改めてここにもまとめてみる。

  • ツリー型タブの設定ダイアログを「ツール」メニューなどから簡単に呼び出せるようにして欲しい。
  • 閉じているサブツリー内の子タブがフォーカスされた時に、ツリーを展開するのではなく、現在見えている親のタブにフォーカスする、という風なオプションが欲しい。

この2つの要望にはどちらも応えるつもりはない、というよりも、安直に応えてはいけない種類の要望だと思ってる。

あらかじめ言っておくと、過去の「タブブラウザ拡張」ではこのどちらも応えていた。いや、要望に応えたと言うよりは多分、自分から進んでそうしてしまっていた。でも今の自分の考えでは、そうするべきではなかったと考えている。なので、もうしない。

そもそもを言えば、こういう要望が出てきてしまっているということが「失敗」の何よりの証拠だと僕は考えている。「何故、そういう要望が出るのか?」「どうしてそうして欲しいと思うのか?」そこを考えないといけないと思う。

  • 設定ダイアログを簡単に開けるようにしたいのは何故?
    • →設定を頻繁に変えたいから。
    • →設定を頻繁に変えないと使い物にならないから。
    • →だったら、設定を頻繁に変えなくても十分に使いやすいと感じられるように、自動判別の部分や初期設定をよく考えた方が、ユーザはハッピーになれるんじゃないの?
  • 閉じているサブツリー内の子タブにフォーカスが移った時に、そのタブが含まれているツリーを自動展開するのではなく、閉じられていない親タブに代わりにフォーカスして欲しい、と思うのは何故?
    • →本当は閉じられたツリーの中のタブではなく、親のタブの方にフォーカスして欲しかったから。
    • →というか、そのタブ(閉じられたツリーの中のタブ)がフォーカスされるなんて思いもしてなかったから、そうなってビックリした。
    • →使っていて自然と頭の中に思い浮かべるようになった「こう動くはずだ」という予想が裏切られてしまった。
    • →そのように想像させる挙動を他の部分がしているのなら、その想像に合った挙動をするように統一するべきなんじゃないの? 無駄に選択の余地を増やすんじゃなくて、「自然と思った通りに動いてくれる」状態を目指すべきなんじゃないの?

前者の要望は、色んなアドオンがそういう項目を「ツール」メニューにどんどん加えていったらメニューが一杯になってしまう!ということを見過ごしている。絶対に、多分別の人が「ツールメニューの中の項目は使わないので、非表示にするオプションを加えて欲しい」って言ってくるだろう。そしたらまたそれに応えるの?

後者の要望は、タブの一覧のリストやサムネイル一覧などからそのタブを選んだという風な、「本当にそのタブにフォーカスしたかった場合」にはどうすればいいのか?ということを考慮に入れずに安直に対応すると、泥沼に嵌ってしまう。不用意にそのオプションをいじってしまった人が「フォーカスしたいタブにフォーカスしてくれない!」と(自分がそう設定したからだと言う事にも気づかず)「バグ報告」してくるだろうし、それにまた安直に応えて「じゃあ、そういうケースだけは特別に、閉じられたツリーの中のタブにもフォーカスできるようにしよう」なんて後手後手の対応を続けていたら、どこまでいってもきりがない。

そういう安直な対応を繰り返した果てにあるのが、かつてのタブブラウザ拡張であり、今のTab Mix Plusであると、僕は考えてる。「多機能で凄い、良い物だ」と人は言うけれども、今の僕にはこれらは「考えることを放棄し続けた結果、肥大化の一途を辿った末路だ」という風に見えてる。既にツリー型タブもそうなりつつあると僕は思ってるので、今後は「設定項目を減らしていく」方向にシフトしたいくらいだ。

アプリケーションを作る立場の人は、要望として口に出された言葉の裏にある本当のニーズを読み取る努力をしておかないと、最終的には自分で自分の首を絞めることになると思う。「その方が格好よさそう」とか「その方が賢そう」とかのあまり意味のない自己満足なこだわりだろ、という風に切り捨てないで、自分自身の身を守るための現実的な対策のひとつとして、実践してほしいなと思う。

そしてその結果、それをエンドユーザとして使う立場に僕がなった時に、またハッピーになれるわけだ。

つまり「情けは人のためならず」とか「自業自得」とかそういう話。

分類:Mozilla > 拡張機能 > treestyletab, , , , , , , , 時刻:03:29 | Comments/Trackbacks (4) | Edit

Comments/Trackbacks

確かに

機能が多ければ多いほどいいというわけでもないんですよね(機能が多い場合、逆に言えばいらないという人もいるわけで)
小分けの方がいいというのは確かですけど、そのバランスって結構難しい
単機能アドオンが多いとインストールの手間がありますし(だからこそ次のエントリの一括インストールという話なんですが)

しかし、単機能アドオンをたくさん入れるとと多機能アドオン1つ入れるのでは安定度とか重さとかどんな感じなのかがいまいちわからなかったりします

Commented by ひで at 2009/07/26 (Sun) 11:34:19

no title

中を見ている人間からすると、「安定度」とか「重さ」とかの主観的な尺度を、ひとつのオールインワン型アドオンと複数の単機能アドオンとの組み合わせの比較において使うのは、不適当と感じます。
しかし以下のようなことは思っています。

●単機能アドオンを複数使う場合、読み込むファイル数(物理的なjarファイルの数もそうですが、XULのオーバーレイの数、JavaScriptのファイルの数、CSSのファイルの数なども含めて)が増える以上、Firefoxの起動に要する時間は確実に増加するでしょう。

●例えば「タブのクリック時の動作」にかかわるアドオンがオールインワン型の1つであれば、1つのイベントリスナでイベントを捕捉してそのあとifとかswitchとかで条件分岐するのに対し、アドオンが3つあれば3つのイベントリスナが登録されることになりますから、イベント処理にかかる時間も全体では増加するでしょう。(これはJavaScriptの条件分岐やループよりもDOM2 EventsのAPIの方が遅いという前提のもとでの仮定に基づいています)
→保守性の高い多機能オールインワン型アドオンは、設計上、内部的には「単機能のアドオンを組み合わせて連携させている」のと同じ構造になる可能性が高いです。そのようなオールインワン型アドオンと、単機能アドオンの組み合わせとを比較した場合、この点では差が無いことになるでしょう。

●Firefoxがクラッシュするとか、フリーズするとか、機能同士が衝突するとかの問題は、アドオンの規模が大きくても小さくてもあり得ます。複数アドオンを組み合わせる場合、意図されない組み合わせによって偶然問題が起こる、という可能性はもちろんありますが、お互いがきちんとAPIを介して連携するように手直ししていけば解消できると僕は考えています。それに対して、個人で開発しているオールインワン型アドオンにおいて同じ問題が起こった時には、スパゲッティ化したコードの中から問題を一人で見つけ出して一人で解消しないといけない(そのためモチベーションが低ければ放置の対象になり得る)のを考えると、「安定性」という点ではどっちも大差ないと僕は考えています。

●http://piro.sakura.ne.jp/latest/blosxom/mozilla/extension/2009-04-17_compatibility.htm で書いた通り、オールインワン型で「あれも、これも」と詰め込んだ物は、コードの見通しが悪くなりがち・スパゲッティ化しがち(このエントリで書いたような安直な対応を取ってしまいやすい)と僕は考えています。その結果僕は、Firefox 1.5以前のコードベースに強く依存したスパゲッティコードの塊であったTabbrowser Extensionsを、Firefox 2以降に対応できる形に作りなおす事に挫折してしまいました。単機能のアドオンであれば、全体の見通しがしやすく、新しいバージョンのFirefoxへの対応も比較的容易に行えると思いますし、動かなくなった機能(アドオン)だけを切り捨てて他の機能(アドオン)を使い続けるという選択も取れます。

そもそもTab Mix自体、Tabbrowser Extensionsというオールインワン型のアドオンを「不安定」で「重い」の感じた人達の手によって開発された、多数の小さな単機能アドオンを、ひとつのパッケージの中にまとめて提供するようにした、というところから開発がスタートしています。
「よくできたオールインワン型アドオン」>「そこそこの出来の単機能アドオンを複数組み合わせる」>「出来の悪いオールインワン型アドオン」
ということなのだと僕は考えています。また、「よくできたオールインワン型」の提供と維持は有志の開発者の手だけで行うのは荷が重いんじゃないか、とも。

Commented by Piro at 2009/07/26 (Sun) 14:30:32

no title

回答、ありがとうございます。
非常にわかりやすかったです。


多機能アドオンを入れることの最大の問題点は、他のアドオンが入れづらいということにあると思います。
確かにfirefox自体はデフォルトじゃ使いづらいのでアドオンを入れることになるのですが、多機能のものを入れると他のとぶつかって逆に不自由になるんですよね……(勿論、それは単機能を複数入れても起きますが)
正直、最近のfirefoxどっちつかずの印象が強いので、その辺りははっきりさせて欲しい感じではあります(アドオンに頼るのか、ブラウザ自体を強化するのかという点で)

先のリンク先を読ませていただきましたが、モチベーションという点では非常に難しい問題です(それが当然や当たり前になってしまったりしてはいけないとは思います)。

昔は多機能型の方がよいとは思いましたが、ひとつのアドオンの中にいらない機能が多いと気づいたため単機能や低機能のものを求めるようになりました。
安定や重さなどもそうですが、扱えない機能はあっても面倒なだけと最近思い始めた次第でもあります。

支離滅裂な文章になってしまいましたが、改めて回答ありがとうございました。

Commented by ひで at 2009/07/26 (Sun) 18:34:49

設定を簡単に変更できるようにすること、を必ずしも重視しませんよという話

Yoichiさんちより。対応と結果がきちんと描かれているのでとてもためになる話だと思った。 10年くらい前の自分だったら設定というのは選択肢であってどちらが正しいというものじゃないし製作者が押し付けるものではないんじゃないの?くらいの感想だったかもしれないが、今は

Trackback from Zinnia hacks tomorrow. at 2009/08/21 (Fri) 22:30:08

TrackBack ping me at


の末尾に2020年11月30日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2009-07-24_prefs.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。

Post a comment

writeback message: Ready to post a comment.

2020年11月30日時点の日本の首相のファミリーネーム(ひらがなで回答)

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき