フリーソフトウェアのユーザビリティが悪い理由と修正方法

マシューポールトーマスによる最近のブログでの記事の翻訳を、ハブロコミュニティに提案します。 Thomasは、最も人気のあるLinuxディストリビューションであるUbuntuの商用スポンサーとして知られるCanonicalの発案者であるLaunchpadプロジェクト開発チームで働くニュージーランドのプログラマーです。

最も興味深いのは：

-この記事の最初のバージョンは 、さらに6（！）年前に発表されました。

-ほとんどの場合、2番目のオプションの出現は、Canonicalの創設者であるMark Shuttleworthの最近の大声明に触発されたものです。

-この記事は、ボランティアデザイナーと献身的なデザイナーの明確な分離をたどっていますが、前者は著者の特別な愛情を使用していません。 トーマスの言葉から判断すると 、彼はそうです。





はい、私は認定翻訳者ではありませんので、私を責めないでください...

6年前にこの記事の最初のバージョンを書いたとき、私はそれを「なぜフリーソフトウェアにこんなに使いやすいのか」と呼びました（これは私の翻訳です。 現時点では、最高のオープンアプリケーションとオペレーティングシステムは、当時よりも使いやすくなっています。 しかし、これは主に開発の遅れとプロジェクトとディストリビューション間の競争の低さによるものです。 ほとんどの部分の主な設計上の問題は未解決のままでした。



これらの問題の多くは、特にフリーソフトウェアに関するものではなく、任意で作成されたすべてのプログラムです。 趣味の結果として作成された独自のプログラムは、多くの同じ理由で使用するのが難しいことがよくあります。 しかし、プログラミングへのボランティアの貢献を得る最も簡単な方法は、プログラムをオープンに宣言することです。 そして何千人もの人々が現在フリーソフトウェアの開発に関与しているので、それらのほとんどはボランティアです。 したがって、オープンソースソフトウェアの世界では、ボランティアによって作成されたプログラムの使いやすさの問題が最も頻繁に見られます。

これは、最初の2つの問題の鍵となります。



1.弱いインセンティブ。 独自のソフトウェアベンダーは基本的に、人々が好むプログラムを作成することで収益を上げています。 これは、それらをより使いやすくするための強力なインセンティブです（これは常に機能するとは限りません：たとえば、Microsoft、Apple、およびAdobeプログラムは悪化することがありますが、その巨大なサイズのために依然として支配的です。しかし、ほとんどの場合機能します）。

ただし、ボランティアプロジェクトでは、インセンティブははるかに弱くなります。

ユーザーの数が金銭的な面ではめったにないような指標は、開発者に影響を与えます。自由に配布されるプログラムでは、一般にユーザー数を計算することはほとんど不可能です。 他のインセンティブがあります-将来の雇用者を感動させるか、人気のあるOSにソフトウェア製品を含めることを達成するためですが、これらは間接的な動機である可能性が高いです。



解決策：より強力なインセンティブを作成します。 たとえば、フリーソフトウェアデザインの分野で毎年賞を発表することができます。これは、優れたデザインに対して開発者に敬意を表するものです。 ソフトウェアベンダーは、ユーザーの何人がプログラムを使用しているか、およびこの数が時間とともにどのように変化するかに関する統計を公開できます。 ボーナスシステムにより、特別な使いやすさを改善した人にお金を預けることができます。 また、リリース管理システムは、競争の迅速化を促進する可能性があります。ディストリビューターは、使いやすさを選択要因として、リリースするアプリケーションだけでなく、アプリケーションブランチから選択するオプションも選択できます。



2.優れたデザイナーはほとんどいません。 一部のミュージシャンも優れた作曲家ですが、ほとんどはそうではありません。 一部のプログラマーも優れたデザイナーですが、ほとんどはそうではありません。 ユーザーインターフェイスのプログラミングと開発は異なるスキルであり、両方の分野で同等に優れている人はまれです。 したがって、ソフトウェアにプロのデザイナーがいることは非常に重要です。 しかし、これを自慢できるのは、フリーソフトウェアの世界のほんの数プロジェクトだけです。 Mozilla、Sun、Red Hat、Canonicalなどのフリーソフトウェア開発者により、複数のユーザビリティの専門家が採用されています。 しかし、それらはほとんどなく、有資格のボランティアデザイナーを見つけるのは非常に困難です。



解決策：プログラマーとボランティアデザイナーに簡単にアクセスできるトレーニング資料を提供して、設計知識の全体的なレベルを向上させます。 プログラマーがユーザビリティの専門家と協力する必要性をコミュニティで育てる。 また、フリーソフトウェアプロジェクトのスタッフに、一流のプログラマー、一流のユーザーインターフェイスデザイナー、参照情報エディター、品質管理エンジニアを雇用することを奨励します。 そして、それは異なる人々であるべきです。

しかし、そもそもなぜボランティアデザイナーが不足しているのでしょうか？ この質問に対する答えは、3番目の問題につながります。



3.設計の改善は歓迎されず、不承認になることがよくあります。 フリーソフトウェアには、「コードを見せて」という長くて便利な伝統があります。 しかし、誰かがユーザビリティの間違いを指摘すると、この伝統は「パッチ歓迎」に変わります。ほとんどのデザイナーはプログラマーではないので、これは役に立ちません。 そして、この状況でユーザビリティの専門家がどのように支援できるかは明らかではありません。



解決策：ユーザビリティの専門家がプロジェクトに参加する方法を確立します。 たとえば、リードデザイナーはプロジェクトのWebサイトに仕様を投稿し、ブログ、Wiki、メーリングリストへのフィードバックを促すことができます。 設計者は、設計を改善するための提案に親切に対応することができます（たとえ間違っていても）。 また、プロジェクトマネージャーは、累積的なバグトラッカーの代わりに編集可能なバグトラッカーをインストールできます。設計提案とエラー報告の実装に注意を払いながら、提案の改善、承認、拒否のプロセスを容易にします。

それでは、なぜプログラマは、技術的なエラー報告とは異なる方法でプログラムの使いやすさを改善する提案に反応するのでしょうか？



4.使いやすさを測定するのは困難です。 ソフトウェアのいくつかの品質を簡単かつ正確に測定できます。それがまったく動作するか、起動する速度、動作する速度、すべてが技術的に正しいかどうかです。 しかし、これは測定が難しいより重要な品質の個人的な代替品にすぎません：ソフトウェアが有用かどうか、応答性、人々の期待どおりの動作、その使用で目標を達成した人々の割合、それをどれだけ早く使用できるか、使用後の満足度。 これらの個人固有の品質は、多くの場合、カスタムテストを使用して測定できます。 しかし、ボランティアが費やしたくない時間または数日かかります。 ユーザーテストは通常​​、解釈するのが難しく、大きな問題に焦点を合わせ、デザイナーに小さな問題の存在をプログラマーに納得させる確固たる証拠がありません。 また、問題が特定された場合でも、ソリューションを開発する必要があります。そのためには、テストも必要になる場合があります。

ユーザーテストを頻繁に使用しない場合、ボランティアプロジェクトは、プロジェクトのメーリングリストに登録するほど情熱的な人々の主観的な経験に依存しています。 しかし、これらの人々が言うことは、通常のユーザーの経験は言うまでもなく、使用の彼ら自身の経験さえも代表していないかもしれません。



解決策：ボランティアにとって便利な低レベルのユーザーテストテクノロジをサポートします。 テストを容易にするスクリーンショット、ビデオ、およびその他のソフトウェアの使用を開発およびサポートします。 ユーザーの意見よりもユーザーのテスト結果を信頼するように開発者を奨励します。 また、ユーザーテストでは追跡できない一般的な小さな問題の解決策を提供する設計ガイドを作成します。

とりわけ、プロのデザイナーの不足は、フリーソフトウェアプロジェクトの3つの文化的問題の原因となっています。



5.最初のプログラミング、次に設計。 おおまかに言って、コードを書く前に設計が行われた場合、ソフトウェアは使いやすくなる傾向があります。 プログラムに必要なユーザーインターフェイスは、データモデル、アルゴリズムの選択、操作の順序、コンベアベルトの使用の必要性、データをディスクに保存するための形式の選択、さらには一般的なプログラム機能のセットの選択に影響を与える可能性があります。 しかし、それはすべて退屈に見えるので、プログラマーはしばしばコーディングを開始するだけです-彼らは後でインターフェースについて心配します。

しかし、より多くのコードが書かれればされるほど、設計上の問題を解決することは難しくなります。したがって、プログラマーはこれを心配することはほとんどないでしょうし、これは実際には問題ではないと確信するでしょう。 そして、バージョン1.0の後に最終的にインターフェースを修正した場合、既存のユーザーは、再学習し、失望し、競合するプログラムの検討について考えることを余儀なくされます。



解決策：新しいプロジェクトまたは新しい機能を開発するプラント設計者とプログラマーのペア。 フリーソフトウェアの世界でカルトを作成するには-最初に設計してからコードを作成します。



6.料理人が多すぎる。 プロのデザイナーがいない場合、多くのプロジェクトアシスタントは、この分野でどれだけ知識があるかに関係なく、インターフェイスの設計に参加しようとします。 そして、多数のデザイナーが、一般的なビジョンと詳細の両方で矛盾を引き起こします。 インターフェイス開発の品質は、デザイナーの数に反比例します。



解決策：プロジェクトには、すべての人の提案を追跡し、実装可能なものを選択する問題でプログラマーと協力する、主要なユーザーインターフェイスデザイナーが必要です。 さらに詳細な設計仕様とマニュアルは、プログラマー固有の欠陥を防ぐのに役立ちます。



7.晴れたウサギの追跡。 独自の特定の設計がない場合、多くの開発者は、MicrosoftまたはAppleが行うことは優れた設計であると考えています。 時々そうですが、時々そうではありません。 設計を模倣して、フリーソフトウェア開発者は間違いを繰り返し、独自の代替品が提供できるよりも優れた設計を得る機会を永久に奪います。



解決策：コンテストやその他の公開イベントを通じて革新的なデザインを奨励します。 既存の設計ガイドを更新して、成功した設計実験の結果を表示します。



プロのデザイナーとは独立した使い勝手の悪さには理由があります。 これらの問題は解決がより困難です。



8.シャツは体に近い。 ボランティア開発者は、彼らにとって興味深いプロジェクトと機能に取り組みます。これは通常、彼ら自身がこのソフトウェアを使用することを意味します。 開発者として、彼らは上級ユーザーでもあります。 したがって、一般的な使用を目的としたソフトウェアは、あまりにもギークで複雑です。 また、ペアレンタルコントロール、インストールアシスタント、競合するプログラムから設定をインポートする機能など、新規ユーザーまたは上級ユーザーが必要とする機能は、放棄されるか、まったく実装されない場合があります。



解決策：シンプルなカルトを導入し、適度なデザインを賞賛します。 ボランティアのプログラマーに、友人や家族が自分のプログラムを使用するのを見て、他のユーザーの問題を解決するように促します。



9.軽微な欠陥を無視します。 プログラムのインターフェースを改善する多くの小さな詳細は、それらに取り組むことからインスピレーションや喜びを引き起こしません。 これらは、たとえば、最初に開くときに最適なウィンドウのサイズと位置を設定する、開いているウィンドウのデフォルト設定に焦点を当てる、エラーメッセージやその他のテキスト情報を適切に表現してより便利にする、進行状況バーを表示するなどの詳細ですプロセスの継続時間のより正確な表示。 そのようなことは賞賛と喜びを引き起こさないので、それらが実現されるまでには何年もかかります。 これにより、ユーザーはデザインの悲惨さについて一般的な印象を得ることができます。これにより、ユーザビリティのスペシャリストがプロジェクトに参加するのを思いとどまらせることができます。



解決策：エラーが存在する期間を判断するためにエラーに取り組んでいます。 これが迅速に実行できる場合、最初にインターフェイスエラーを解決することが可能です。 バグを修正するための計画プロセスに設計者を巻き込み、「はい、それは単なるUIエラーである」ために過小評価されているユーザビリティギャップから保護します。



10.オプションで人々を安心させます。 多くのヘルパーを持つソフトウェアプロジェクトでは、設計に関して意見の相違が生じる場合があります。 雇用された従業員の場合、通常、一貫性がなくても作業は継続されます。 しかし、ボランティアの場合、プロジェクトリーダーは、構成設定を追加してアシスタントを安心させることに同意する可能性が高いでしょう。 そのような設定の量、濁度、および一般性は、一般ユーザーを混乱させますが、最終結果を膨らませ、テストの徹底を弱めることで誰もが罰せられます。



解決策：厳格なプロジェクトリーダーとシンプルなカルト。 リリース管理システムは、適切な機能を備えた独自のバージョンのプログラムを簡単にサポートすることで、プレッシャーを緩和するのにも役立つはずです。



11. 15ピクセルの栄光。 ボランティアが人気のあるアプリケーションに新しい機能を追加するとき、彼らはインターフェイスで誰かを見せて「やった」と言うことができるように、行われた作業に対する認識を受け取ることを期待しています。 これにより、新しいオプションやメニュー項目が表示されることがありますが、実際には個別のインターフェイスは必要ありません。 一方、不安定な機能や役に立たない機能を削除すると、作者に怒りが生じる可能性があります。



解決策：参加者に感謝を表すために、ブログなどの代替宣伝を提供します。 ユーザーインターフェイスに影響するコード変更の設計レビューを実施します。 インターフェイス全体を定期的に検査して、「このコードが本当に必要なのか？」と自問してください。



12.ブロードバンドデザイン、低速インターネット。 ボランティアプログラムプロジェクトは通常、さまざまな都市や大陸からの参加者の間でも広く配布されています。 したがって、プロジェクトの協力は通常、テキスト、電子メール、インスタントメッセージングクライアント、IRCチャネル、またはエラー追跡システムを使用して実行されます。 しかし、集合設計は多次元であり、時間の経過に伴う要素の振る舞いの計画と会計、インターフェース全体でのこれらの要素の編成が含まれます。 開発者が同じ部屋にいるとき、プレゼンテーション、紙上のプロトタイプ、言葉、ジェスチャーを使用して、相互設計について話し合うことができます。 しかし、インターネットではこれが不可能な場合が多く、議論が大幅に遅くなり、誤解を招きます。



解決策：VoIP、ビデオチャット、仮想プレゼンテーション、スケッチ、およびアニメーションソフトウェアの使用を開発および促進し、インターネットを介した設計アイデアの議論を促進します。 そして可能な限り、個人的なコラボレーションのために実際の開発者会議を開催してください。



最後に、いくつかの問題はフリーソフトウェアの開発に固有のものです。



13.より早くリリースし、より頻繁にリリースし、行き詰まります。 「より早くリリースし、より頻繁にリリースする」という一般的な慣行により、設計エラーが蓄積される可能性があります。 ユーザーがプログラムの1つのバージョンでテスターが遵守している1つの方法で操作を実行すると、新しいバージョンの方が優れていても、次のバージョンの動作が異なると自然に不平を言います。 これにより、プログラマーはインターフェイスを改善できなくなり、不明瞭な構成設定の数が増える可能性があります。



解決策：開発プロセスのできるだけ早い段階で設計仕様を公開して、テスターが長期的に何を期待できるかを把握できるようにします。



14.モジュール性による平凡。 フリーソフトウェアハッカーはコードの再利用を高く評価しています。 多くの場合、機能のみを実行するコードの記述について話します。そのため、他のプログラマーは「フロントエンド」（または複数の代替「フロントエンド」）を記述でき、普通の人がそのようなコードを使用できます。 彼らは、代替実装の目的でシステムの任意のレベルを変更できるようにするために、これが重要であると考えています。 これは、1つのコンポーネントへの依存を回避できるため、システムの長期的な実行可能性に適しています。 しかし、それはまた、特にシステムレベル間のインターフェースがユーザビリティを念頭に置いて設計されていない場合、統合の欠如につながり、ひいてはユーザビリティを弱めます。 たとえば、ほとんどの端末コマンドでは、プロセスの完了に関する情報が提供されないか、処理にかかる時間の推定値が提供されません。 これは端末での従来の動作ですが、グラフィックソフトウェアではプロセスの表示が重要です。 グラフィカルユーティリティがターミナルコマンドの「フロントエンド」としてのみ設計されている場合、この情報を簡単に提供することはできません。



解決策：まず、コードを記述する前に低レベルインターフェイスの要件を把握できるように、サンプルのGUIデザインを開発します。



15.閉鎖された開発者コミュニティ。 コンピューターで何かをするときは、さまざまな開発チームが開発したプログラムに依存しています。 , -, -, -, , , , , , , , , . . , . , .



: - , , . .



, , . , , .