フリーソフトのUIを改善するには？ 122
ストーリー by hylom
ユーザーのフィードバックも重要ですよね 部門より
ユーザーのフィードバックも重要ですよね 部門より
あるAnonymous Coward 曰く、
本家/.にてMatthew Paul Thomas氏のブログエントリ「Why Free Software Has Poor Usability, And How To Improve It」が取り上げられている。
氏はこのブログエントリで、フリーソフトが抱えるUIデザインに関する問題を15点挙げ、原因を分析し、改善策を提案している。例えば、ほとんどの場合デザイナーはプログラミング出来ないため、「ソースコード公開」かつ「パッチ歓迎」されてもUI改善には繋がらないと指摘する。その上、ユーザビリティの専門家がどのようにプロジェクトに関わればいいか不明なため貢献できないことが多いと指摘する。
これを改善するためには、プロジェクトのサイト等でデザイン仕様を公開し、ブログやWiki、またはメーリングリストでフィードバックを求めるなど、ユーザビリティの専門家がプロジェクトに貢献出来る方法を確立すべしとアドバイスする。氏の分析は的確で、有益なアドバイスも多いのだが、小規模プロジェクトに当てはめるのは難しいものもある。
フリーソフトのUIに関して諸兄方はどのようにお考えだろうか？考察などあれば是非お聞かせください。
日本の場合 (スコア:5, すばらしい洞察)
Re:日本の場合 (スコア:5, 興味深い)
そりゃ、開発チームに対するリスペクトなぞ微塵も無く、彼らの大部分がボランティアであることも忘れ、
「俺の意見は、聞くのが当然」
「俺の不具合報告は、修正するのが当然」
「俺の希望通りに実装するのが当然」
「そうじゃない開発はクソ」といって、外部でdisりまくる
みたいな態度じゃ、追い出されもするでしょうね。プロジェクトにとっては害悪でしかない。
まあ、この手の輩は内外問わず、多いようですが。
意見を聞いてほしいなら、まずそれなりの信頼関係を築くのが先じゃないでしょうか。
それが嫌なら、売り物ソフト買ってサポートに思う存分文句たれるか、別のわがままを聞いてくれるソフトウェアに乗り換えるか、
どっちかしかないのでは?
Re:日本の場合 (スコア:4, 興味深い)
当時巨大になり始めた某匿名掲示板で、ゲームの企画を適当に書き捨てるスレッドがあった。
そこで実装が簡単そうなアイデアが書かれていたため、（ただし、そのアイデアは、ゲームとしては面白くない、）速攻で動くレベルに仕上げて、公開した。
当然ソースコードごと公開。
みんなで、
「こういう機能を追加するために、ここにコードを追加してみたよ。」
「バグがあったけど、ここをこう直せばいいよ。」
みたいなやりとりがあって、良いものを作り上げていければいいなぁ、と。
そこまでハイレベルでなくてもノウハウを蓄積できる端緒になるかなぁ、と。
ちょっと夢見たわけです。
ところが、
「こうすれば面白くなるから、こういうルールに変更しろ」
「この機能を追加しろ」
と表面的な変更の要望が並べられるばかりで、誰も手直ししてくれない。
思いっきり可読性重視に書いたソースも読んでくれない。
おそらく、読む実力が無い。
おいおい、何のためにソースを公開したんだよ。
私の結論。
全員が平等なコミュニティってのは、周囲に同じレベルの人間が大勢いるような、高学歴の学生の幻想。
場違いな底辺層や、スポイラーが存在する環境では、レベルに応じてユーザを階層化したほうが効率的。
信頼関係はその次の話。
Re:日本の場合 (スコア:1, 参考になる)
学歴は関係ないと思う。自分がやっていた時は高校生や中学生でも、頑張って自分で考えて作って見たのを送って来てくれたし。
問題はもっと根本的なところにあって、「ソフトを作る事を共有しよう」って層と、「タダのソフトを使う」って層が明らかに分かれているって事。
そして、後者はどんなに自分に実力があろうと（中には当人もフリーソフトを作っている人も居た）、興味の無いもののソースなんぞこれっぽっちも読まないって事と、クレームはクレームを付ける奴が付けるって事。
Re:日本の場合 (スコア:1)
・作者がどういうスタンスやポリシーを持っているかを読み取った上で
・今の実装に沿った形で （ソースを読んでなくてもだいたい想像付きますよね）
・利用者の利益が最大になるような提案 （機能追加より仕様改善の方がいいことが多い）
をすれば、みんなハッピーになれると思うんですけどね。基本は、Win-Winでしょ？
Re:日本の場合 (スコア:1, おもしろおかしい)
「奴の意見は、聞くだけ無駄」
「奴の不具合報告は、修正するのが面倒」
「奴の希望通りに実装するのが手間」
「そうじゃないユーザーだけが神様」といって、内部でdisりまくる
みたいな態度じゃ、改善するはずもないでしょうね。プロジェクトにとっては害悪でしかない。
まあ、この手の輩は内外問わず、多いようですが。
デザインを改善したいなら、まずそれなりの腰の低さを見せるのが先じゃないでしょうか。
それが嫌なら、シェウェアにして金を払った奴だけに文句を言わせるか、クローズドにフォークして自分でしか使わないか、
どっちかしかないのでは?
Re:日本の場合 (スコア:3, 興味深い)
古参が保守的すぎるプロジェクト。
具体的に名前出すのもアレだけど、今まで見た物で言うと電信八号とかそんな感じでノリが悪くて困りました。
やっていいと言われればなんでも作るんだけど
今でも使えるからこのままでいい(要するにバグ取りだけしろってことなのかと)とか言われるとやる気なんか無くなります。
＃同じような事思ってた人は他にも何人かいたらしくなんか２ちゃんで管巻いてたｗ
ユーザーに開発者と同等の発言権を与えすぎるとグダグダになりやすい気がします。
圧倒的にユーザーの方が多いわけですから。
開発者とユーザーはあくまで隔離して発言のやり取りはフローティング式のToDoでも用意しておいてそこで簡単に案件毎にディスカッションするのがいいと思う。
メーリングリストとか掲示板で同列に語らせるのは愚でしょう。
Re:日本の場合 (スコア:1)
Re:日本の場合 (スコア:1)
> Design suggestions often aren’t invited or welcomed.
と指摘されているんで、あまり変わらないんじゃないかと。
ユーザビリティに関する指摘をすると「じゃぁ、パッチください」と言われるとも。
＃日本では、開発者以外の外野が「お前が書け」とか言ってる気はするけど。
＃＃日本以外の事情は知らない。
Re:日本の場合 (スコア:1, すばらしい洞察)
ここですねぇ
開発者本人が信念を持って「これでいいんだ」というのは全然構わないんだけど
(そのかわり「他をあたることになる」けど)
取り巻きの多くは「慣れてるから変えられたくない」だけだからなぁ
Re:日本の場合 (スコア:1)
単に「不満」だからじゃないでしょうか。
自分が仕事をしていて、「さっさとやれよ」「こんなことも出来ないのかよ」「お前のプログラム／デザイン、つかえねーな」なんて言われたりすると、萎えますよね。仕事ならそこはグッとこらえますが、ボランティアで「楽しさ」を求めてやってる作業では萎えて何もしないことになりかねません。
単なる「不満」を「提案」にまで出来れば「お、いいねいいね」と行く場合もあるのではないでしょうか。『暗いと不平をいうよりも、すすんであかりをつけましょう』というように。
＃他の方が言われているように「取り巻きがうるさいだけ」というのも同意する部分ではありますが。不満を言う人を叩く作業なんて不毛なのに。
美麗なデザインが出来るデザイナーが必要ではない (スコア:4, 興味深い)
（マカー乙とか言われるのをおそれずに）
Macのデベロッパーはたぶん昔からAppleのInterface Guideline [apple.com]があるのを知っていると思うんだけど他のプラットフォームではこういったものはないんだろうか？
Windowsとか。
もしかしたらあるのかもしれないけど、多くのデベロッパーに知られていない気がする。
（あったら教えて）
Macに比べてWindowsでのソフトウェアのインターフェイスや挙動がソフトごとにマチマチなのがいかんともしがたい。
ソフトウェアというユーザとのインターフェイスになる部分のデザインには見た目の美麗で派手なデザインが重要ではなく、統一されて混乱をさせない操作性をユーザに気づかないうちに学習させるような情報をデザインするInformation Architectureのような一見気づかないデザインができるデザイナー、もしくはそれに添えるガイドラインめいたものが必要なんじゃないだろうか。
（Windowsはクラシックデザインで使う僕はVistaがうざがられるのはあのUIもあると思う）
というのをFlickrがダウンしたときのエラー画面で思った。
GNOME Human Interface Guidelines (スコア:3, 参考になる)
FYI.
Re:GNOME Human Interface Guidelines (スコア:1)
KDE User Interface Guidelines [kde.org]
さらに言えばCDEにもOS/2のPMにもOPEN LOOKにもガイドラインはあったはず。
Re:美麗なデザインが出来るデザイナーが必要ではない (スコア:2, 参考になる)
[MSDN Library]-[Win32 and COM Development]-[Technical Articles]-[User Interface]-[User Interface Design and Usability]-[Microsoft Inductive User Interface Guidelines] [microsoft.com]とか
[MSDN Library]-[.NET Development]-[Articles and Overviews]-[Windows Vista]-[Windows Vista User Experience Guidelines] [microsoft.com]など。
まあ「多くのデベロッパーに知られていない」のは確かな気がしますが、このレベルだと守られてるとこが多いと思います。
ダイアログの[OK]と[キャンセル]は、右下にこの順で並ぶとか。
Macで使うなら気にならないけど、Windows 用ソフトで逆になってるのに出くわすとすごく戸惑います。
でも、マイクロソフトのガイドラインってあくまで基本部分だけなんですよね。
あるアプリケーションが持っている「独自な機能」部分では、どうしても「独特な操作」が出てきて、
その部分で統一できてないって面が多いんじゃないですかね。
Re:美麗なデザインが出来るデザイナーが必要ではない (スコア:2, 参考になる)
オンラインで読めるWindowsのUX(User Experience)のガイドラインはここ [microsoft.com]かな。これはVista向けに改版されたもののようです。
最近のWindowsのUXの傾向としては、デベロッパーが機能を実装してデザイナーがXAMLを使ってUXを改良する、またはデベロッパーとデザイナーの間にインテグレータを入れて機能とUXをXAMLを通じて連携する、なんてことを勧めて [windowsclient.net]いるようです。
個人的には、教条主義的にOSやウィンドウシステムの統一された操作性に拘らないで、それぞれのアプリケーションの目的にそった操作性の方が優先された方が良いのではないかと思います。特にMacのiApplicationを見るとそれを感じます。
ではでは、
Re:美麗なデザインが出来るデザイナーが必要ではない (スコア:1)
作る時にちょっとだけ細工をするといいのさ (スコア:4, 参考になる)
あとでなおせばいいやー だとたいていほったらかしなのですよ。
画面を作る前に：
１）必要なもの、画面に置きたいものがなにかメモしてからスタート
２）なんかいっぱいあるなー であればタブわけとかを考える
３）なるたけシンプルにするでも必要ならダイナミックにいっぱいでもよい
４）戻る、決定、キャンセルとかなにか変更とかしたら意思決定するボタンは
できる限り同じ配置にする。右上に置くなら毎回右上。右下なら毎回右下。
画面によってあっちこっちかえない。
コンパイルする前に：
４）タブストップで移動する順番を調整しておく。
これをちょっとやるだけでも、けっこう おっ と思ってもらえるよ。
他のＵＩをパクる、というか、なんとなく「代表的な操作は揃える」
(copyが ^c 、pasteが ^v とか)は、一般的に「標準だと思われている」操作が
すんなりそのまま使える⇒こんらんしない なので、抵抗せずそろえたほうが
いいかもしんないすね。
ヘルプを充実させるより、マウス(キーボード)をどう動かすか を考えて組むと
いいかもしれないです。
( ´・ω・`)いままでとこれからを比べる生活
ぱんかれ
プロジェクトを分ける (スコア:3, すばらしい洞察)
別のプロジェクトが開発する方法は、
オープンソースに限らずそこそこうまく機能しているように思える。
# debianとubuntuとか、lameと各種エンコーダーとか、IEとタブブラウザ拡張とか
なぜ悲しいUIになるのか (スコア:3, すばらしい洞察)
同様にほとんどのプログラマーはデザインができないためです。
いや、アイコン1つこさえるのも一苦労だし、一所懸命作ってもお世辞にもかっこいいとはいえないものができるし。
WPFでかっこいいUIが作れるように・・・なんて話もありますが、そのツールを使いこなせません。
キャラクタベースの頃はよかったなぁ・・・・
Re:なぜ悲しいUIになるのか (スコア:2, 興味深い)
表意文字だから取りあえずOKと言うことで。
「新」「開」「保」「円」「線」などなど。
Re:なぜ悲しいUIになるのか (スコア:1)
あるものは使うという由緒正しい方法 [u-tokyo.ac.jp]ですよね(萩谷せんせを由緒とするのもどーかと思うけど)．
はてな日記 [hatena.ne.jp]継続ちう
Re:なぜ悲しいUIになるのか (スコア:1)
いいアイディアだと思ってやったのに…考えたのに…すごく考えたのに…
Re:なぜ悲しいUIになるのか (スコア:1)
デ「このUIかっこいいと思わない？」
プ「こんなクソ仕様のUI工数かかってしょうがねーよ」
デ「んじゃてめーがやれ！」
～数時間後～
プ「UIできたぞ」
デ「プッ、何このダサいUI」
プ「んじゃてめーがやれ！」
～以下無限ループ～
Re:なぜ悲しいUIになるのか (スコア:1)
さらに自称デザイナの絵描きが混ざって地獄絵図とか。
そんなの (スコア:2, 興味深い)
これしか無いでしょう。いやまじで。
複数の人が使う道具である以上、bestは無理なのでbetterを模索することになります。
アパレルで言えばM（標準）サイズを作る場合、誰にもジャストフィットしないサイズを作ると
よく言われますが、UIもそれに近いのではないでしょうか。
誰にもジャストフィットしない物を作るには大量のリサーチが必要なので
要するに「がんばる」しかないと思ったわけです。
＃眉唾なのでAC
結局好き嫌いだから (スコア:2, 興味深い)
デザインが良くても「いいのはデザインだけ」とか言われてしまう。
まず市販ソフトを買って使い倒せ。 (スコア:2, すばらしい洞察)
「自分で作ればタダ」かもしれないが、本質的には何本も既存の市販ソフトを買って使い倒してるぐらいの経験があって始めてまともなものが作れる、のでは。
だってポリシーが違うんだもん (スコア:2, 興味深い)
UIに対するポリシーが違うことが多々あります。
たとえば、初心者はマウスオペレーションを好むが熟練者は
キーボード操作を好む傾向があるとか。動作スピードを
コンマ何秒だけ速くするためにUIや画面表示を簡素にすることは、
熟練者にとって非常に意味がある（それだけでプロジェクトを
立ち上げるきっかけになる場合もあるかもしれない）とか。
「改善」と一言で言うけど、それはどっち方向を向いての改善なのか、
ある人にとっての改善が、別の人にとっては改悪かもしれない
ということを、よく考えた方がいいかも。
まず「だれにとって使いやすい」デザインにするのかを定義 (スコア:2, 興味深い)
で、ユーザビリティを論ずるときに大切なのは、特定の利用状況において、特定のユーザによって、ある製品が、指定された目標を達成するために用いられる際の、有効さ、効率、ユーザの満足度の度合い。 [wikipedia.org]（ISO 9241-11）であること。
つまり、万人を満足させる「使いやすいインターフェイス」はあり得ないので、どういったユーザー層にとって使いやすくするのかを定義しないと良いインターフェイスは作れないわけですよ。
となると、「フリーソフトのUIを改善するにはどうすればいいのか」の1つの答は、まずどんなユーザー層（ITリテラシーやそのソフトの利用頻度なども含む）をメインターゲットとするのかを定義すること。そうするだけで、デザインが苦手なエンジニアでも「使いやすい」を想像しやすくなるし、複数のステークホルダーがいる場合にも同意をとりやすくなりますよ。
ペルソナ [impressrd.jp]を作ってみる [impressrd.jp]のも良いのですが、コストかかりすぎますよね。
Re:まず「だれにとって使いやすい」デザインにするのかを定義 (スコア:1)
「自分で使いたいから作る」というのが原動力なのだから、そうにしかならないのですが。
その一方で (スコア:1, 興味深い)
(結局UIは大事だよという内容だけど)
パクる (スコア:1, すばらしい洞察)
#いや、冗談じゃなく本当に。
#オープンソースでUIの改善なんて無理ですから。
つまんない (スコア:1, すばらしい洞察)
Re:つまんない (スコア:2, すばらしい洞察)
後から変えるのが非常に面倒だ。
テキトーに始めたにもかかわらず、それなりのUIになっちゃうのが
ウィザード級のハッカーなのだろうなあ。
# ちなみに俺のUIはひどいぞ。GUIはもっとひどいぞ。
Re:つまんない (スコア:2, 参考になる)
その時のUIはパラメータを全てテキストファイルで渡すような感じです。
機能を発現できて周りの人に使いたいって言われてからGUI考えます。
結局、GUI作ってる時間が一番長い気がする。
そういえばココ [geocities.co.jp]をみて笑ってたコトもありました。
こんなことするワケねーだろって。でも、いつのまにかやってたりする…
Re:つまんない (スコア:1, すばらしい洞察)
というか環境というか。
Borland DelphiのComponentを(FOSSとして)作るときなんかは、
「UI(の一要素)としてどんな立ち位置や使い勝手になるか」
がまず重要なんで、UI先行かな。
＃ていうかコマンドライン化するのが面倒だってのもある（ｗｗ＞Delphi
非UIが先行するのは、
UNIXのように
「アプリ(プロセス)開発の支援は強い。UI開発の支援は弱い」
傾向にあるOS/環境では、
やっぱりそのほうが楽なんで
どうしてもそうなりがちなんじゃないですかね。
乱暴にいえば一番簡単なプログラムが「HelloWorld」という
ロジック(??)というか非UI要素ばっかりな代物だ、という環境です。
これがDelphiのような環境だと、
ビジュアル(UI向け)Componentが既存クラスとして存在すれば、
それを継承するってところが第一歩になるので、
一番楽なプログラムはButtonの真ん中に「HelloWorld」って出る代物だったりする（＾＾；
(あまり言われないことですが、
UNIXというかCのmain()を無理やりOOPに例えると、
プロセスというObjectのコンストラクタなんですよね。
つまり自作アプリとは「UNIXプロセスクラス」を継承したクラスのようなもの。
そして「UNIXプロセス」クラスが最初から提供してる便利機能といえば、
stdin/out/errとかforkとかあそこらへんであり、
決してUI系ではない…)
Re:つまんない (スコア:1)
もちろん、俺の場合だけど。
デザイナー (スコア:1, オフトピック)
世に溢れるFlashコンテンツの使いにくさに鑑みると、後者の意味のデザイナーという人種にUIを設計させるのには不安を感じます。
後からやるからまずいんだ (スコア:1, すばらしい洞察)
>みたいな感じで抵抗される。
それはそうでしょう。
あるUIを想定(思い込み含む)した状態で組んだロジックを
「後から」換えろって言われたら、誰だってキレます。
結局「レビューでは遅すぎる」という警句が有効なんじゃないかと思います。
各部品が出来上がりましたって言った頃にレビューして
「駄目ジャンこれじゃ合わないよ」
なんてやっても手遅れってことです。
今までの何日(何ヶ月？)もの工数を返せ！ってことになる。
理想ですが、ペアプロみたいなものは有効なのだろうと思われます。
今書いてるロジックを今脇からデザイナが見ながら
「あ、それだとデザイン困る」
とか(あるいは逆とか)という突っ込みをほぼリアルタイムでする世界です。
そうすれば「合わない実装」に突き進んでしまう無駄工数が
数秒単位で撲滅できることになる。
あるいはそこまでいかなくても「頻繁な結合」で
日単位で不味いところを探すようにする、など。
商用ソフトの方が・・・ (スコア:1, おもしろおかしい)
コマンドラインで使うことができないものばかりだし、インストール時にいちいちIDだの聞いてくるし、
つまらない同梱のセキュリティソフトが動いていたりするからデバッガ類が同時に使えないこともあるし、
商用ソフトの一番の欠点はPCを自分だけのものだと勘違いしてることだね。
動いているのが自分だけだみたいな自己中ソフトが多い。
謙虚さがほしいね、日本人の美徳的には。
これもUIだよね？
大きめのフォントにしてる方が悪いんかな (スコア:1)
ということを考慮してないUIを作ってる所はダメだなぁと思う
・設定ダイアログで、説明文の後に[設定]とかのボタンが有るんだけど、
設定ダイアログの大きさが固定の為、ボタンがダイアログ上に存在せず押せない
・フォントサイズ固定で小さ過ぎで読めない、大き過ぎでウゼエ
・フォントサイズがシェルの設定に合わせて可変になってるけど、
ダイアログ上のレイアウトが固定で、上下の行の文字が重なってる、文字の上下が切れる
そういうのが未だに存在する辺りがなぁ
Re:大きめのフォントにしてる方が悪いんかな (スコア:1)
例えばFasterfoxとか。プリセットが「カスタム」以外に設定されている状態でウィンドウを開いてから「カスタム」を選択すると、増えたタブとキャンセルボタンがウィンドウからはみ出してたり。一旦その状態でウィンドウを閉じて開き直せばいいだけなので実害はないのですが。
昔のMozillaの初期設定ウィンドウでもボタンがはみ出していて押せなかったこともありました。
あとは、フォントリストをリスト上でドラッグで選択（上端／下端位置でオートスクロール）しようとしても、スクロールしてくれなかったり。スクロールバーでやらないといけないのがちょっと面倒臭いです。
Re:UIの場合 (スコア:1)
また、UIで問題になるのは知らない人が直感的に機能を把握できるかってのもあって、完全に機能を把握しきっていて、自分の使う範囲でしか作らない作者がそういった方面のUIの向上を担うのはかなり難しいかと。
コマンドラインベースのソフトだって、作者にとっては必要十分だったりするしなあ。
Re:フリーソフトに限らない (スコア:1)
Re:フリーソフトに限らない (スコア:2, 参考になる)
秀丸のいいところはあらゆる機能を自分の好みのキーバインドに出来るという点。
気に入らなきゃ自分で変えられるというのはいい。
Re:作者の見識 (スコア:1)
私は自作ソフトを公開したことは無いんですが、こういう事ってありそうですよね（笑）
Re:"Free Software"を「フリーソフト」と略すのをやめようの会（-1:オフトピ) (スコア:1)
会の名前を言うたびに殴られるので困ります。
ハードに録画、ハードに保存（オフトピ-1） (スコア:1)
一般人の某女性が「テレビ番組をハードに録画」（＝ハードディスクレコーダ）とか「ワードをパソコンのハードに保存」とか言うのを聞いて背筋がむず痒くなりました。
＃「性癖」を「性的嗜好」と誤用するのを止めたいID
Re:「使えるモノ」と「使ってもらえるモノ」は全く違う (スコア:1)
大変だから使えるモノにとどめておく
でも、使ってもらえるモノになることは大切じゃない
ってとこでしょ
「使ってもらえるモノ」にするのはそれでお金儲けをしたい人の役目であって、フリーで公開してる人の役目ではないと思うし
無料で使えるものにそこまで望むのはどうかと思う
もちろん、より「使えるモノ」にするためにちょっとした要望を出したりはすることもあるけど、
結果的に作者がいらないと判断するなら仕方ないんじゃないかな？