アプリケーションがカスタマイズしすぎるのはいつですか？[閉まっている]

デスクトップアプリケーションを開発していて、ユーザーがメニュー、ボタン、キーマッピング、その他のコマンドやコンポーネントをカスタマイズできるようにしたいとします。どの程度のカスタマイズを許可する必要がありますか？

私の環境は、ほぼ無限にカスタマイズ可能であることが好きです。また、環境に適切なデフォルトのセットを用意して、全体をセットアップする必要がなく、必要な設定を微調整できるようにしたいと考えています。私の好みをサポートしたり矛盾したりするユーザーエクスペリエンスはありますか？

追加するすべてのオプション/カスタマイズは、より複雑なプログラムを作成することになり、使用と保守の両方が困難になることに注意してください。それがほんの一部の人しか使用しないものだとしたら、それだけの価値があるかどうか尋ねます。

カスタマイズを許可することがユーザーに大きなプラスの影響を与える場合。

本質的には他の要件と同じです-それを実装するためのコスト/労力を正当化する必要があります。これは、生産性や使いやすさの向上、またはある程度のユーザー満足度の向上の可能性がありますが、そのためには、それに伴う労力を正当化する理由がいくつかあるはずです。

カスタマイズが好きな人として、あなたが自問すべき質問は次のとおりです。

• 私が支払っている場合、このレベルのカスタマイズには何を支払う必要がありますか？私のような人は何人いますか？そしてそれはそれを開発するコストをカバーするでしょうか？

• 競合他社は何をしますか？この分野の製品に期待されることは何ですか？

• カスタマイズ可能にするための労力を費やす代わりに、他の機能にその労力を費やすとしたら、どちらを選びますか？これは一般的なユーザーに当てはまりますか？

実装することを選択したものはすべて、実際には（少なくとも今のところ）実行しないことを選択したものであるため、必要な労力をすべて正当化する必要があります。

ユーザーがそれぞれの小さなことをカスタマイズできるようにする理由を自問してください。設計上の決定を自分で行うのを避け、代わりにユーザーにそれらを強制することですか？

この件に関するジェフの良い投稿は次のとおりです。http：//www.codinghorror.com/blog/2005/09/the-problem-with-configurability.html

一般に、ユーザーはあまり考えられていないアプリケーションを嫌い、ニーズを満たすためにカスタマイズする必要があります。私の経験では、ほとんどのユーザーはコンピューターをIT担当者ほど快適に使用できず、オプションを指定してもカスタマイズされません。

設計の適切な作業を回避するためにカスタマイズしている場合は、カスタマイズしすぎています。要件ではなくカスタマイズが好きなためにカスタマイズしている場合は、カスタマイズが多すぎます。カスタマイズするための真の要件がある場合でも、それが良いアイデアかどうかを質問し、カスタマイズが必要であると考える根本的な理由を見つける必要があります。多くの場合、要件の実行者との対話を開始する場所としてカスタマイズの要件を使用すると、それらが言及していなかった新しい要件が見つかります。

それはアプリケーションに依存します

これは警官のように聞こえるかもしれませんが、実際にはそうではありません（または、少なくともそうであるようには意図されていません）。

カスタマイズの量は、予想されるエンドユーザーの洗練度にある程度依存する必要があります。エンジニアタイプは、たとえば、私のおばあちゃんがWin98マシンでソリティアをプレイしているよりも、ユーザー設定をいじくり回す可能性がはるかに高いです。

また、アプリケーション自体が何であるかにも依存します。アプリケーションのポイントが使いやすさである場合、ユーザーが構成可能なオプションの束でそれを濁らせたくありません。

構成可能なオプションが多すぎると、アプリケーションが非常に複雑に見えます。これらのオプションがたくさんあるアプリケーションを作成する場合は、少なくとも[詳細...]構成画面またはダイアログでそれらを「非表示」にし、そのアプリケーションの平均的なユーザーが使用するもののサブセットのみを配置します「通常」オプション画面で変更したい。

別の選択肢は、何かを「スキニング」することです。これは、従来の「スキン」機能（たとえば、Windowsの[画面のプロパティ]の[外観]タブ）を意味する場合と、一度に設定されるオプションのセット（たとえば、同じ[テーマ]タブ）を意味する場合があります。ダイアログ）。

私は一般的に気にしないでください。私は多くの異なるマシンで作業しなければならなかった、そしてそれらすべてをカスタマイズされた状態に保つことはそれが価値があると思われるよりも面倒なものになるだろう。あるマシンでカスタマイズを行うと、別のマシンにカスタマイズがないと困ります。カスタマイズを簡単に移動できるようにすることは多少は役立ちます（emacsユーザーとそのサイトlispファイルを検討してください）。

アプリがそのままではうまく機能しないが、カスタマイズする必要がある場合は、失敗しています。

自分の好きなソフトウェアをマシンに入れたいのですが、それがカスタマイズの意味だとは思いません。

カスタマイズの問題の1つは、尊重する必要のあるすべての顧客への約束であることです。バージョンAを送信し、顧客がカスタマイズします。すべて順調です。では、バージョンBで何をしますか？顧客のカスタマイズを壊すと、彼らは動揺します、そして、あなたがそれを複数回行うと、彼らはカスタマイズに非常に消極的であるので、あなたは非常に少数の人々が使用するカスタマイズ機能と悩まされるままになります。顧客。

つまり、アップグレードのたびにどのようなカスタマイズを行ったかに注意を払う必要があります。これは、カスタマイズを台無しにすることを除いて、簡単に実行できるはずの何かを再構築したいときに頭痛の種になるかもしれません。相互に悪影響を与える可能性のあるカスタマイズの可能な組み合わせに注意を払う必要があります。

次のいずれかに該当する場合、プログラムはカスタマイズ可能です。

1. 合理的ですぐに使えるデフォルトの設定はありません。カスタマイズしなくても、ものごとが適切に機能すれば、カスタマイズ性ははるかに口に合います。たとえば、viが嫌いなのは、バックスペースと矢印キーが何をするかという点での箱から出してすぐの動作が、マシンの他の部分の規則とは非常に異なるためです。これはカスタマイズできることはわかっていますが、ストックマシンに近づくと、いじくり回して時間を無駄にするまで基本的に使用できません。

2. プログラムを非常にカスタマイズ可能にしたので、ルックアンドフィールはすべてのマシンやLinuxディストリビューションなどで効果的に異なり、効果的に「一度学習してどこでも使用」することはできません。再び、viを参照してください。

3. あなたは、内部プラットフォームを構築して、ユーザーが外部プラットフォームを使用することで彼/彼女が望むものを達成したほうがよいようにしています。たとえば、テキストエディターまたはコマンドラインテキスト処理ツールが強力になりすぎると、簡単で簡単なPythonスクリプトを記述して、複雑なテキスト操作を実行する方が、使用方法を学ぶよりもおそらく簡単です。内部プラットフォーム。同様に、プロットライブラリが強力になりすぎた場合は、その上に構築されているGUIライブラリをユーザーが直接操作して、プロットの細部をカスタマイズすることをお勧めします。

TL; DR：アプリケーションが威圧的なフレームワークになるとき。

アプリケーション開発者の観点から見ると、ユーザーがアプリケーションのセットアップ方法を報告できないか、さまざまな設定の相互作用が複雑すぎて頭を作れないため、サポートが不可能になるようなカスタマイズがアプリケーションに許可されますまたは尾。カスタマイズシステムを十分に検討し、有意義な方法で情報を提供できるようにします。

アプリケーションのユーザーの視点から見ると、「プログラミング」の緩い定義（これはGUI指向のプログラミングやBlinkenswitchesを含む）にとって、多くの場合プログラミングに似ているため、ユーザーがアプリケーションの設定に困難を感じているときです。

はい、線はぼやけています。

はい、時々、優れたコードまたはGUI（再）設計により、同じカスタマイズ可能な機能セットを使用しても、アプリケーションスイッチボードを作成できます。

「カジュアル」、「上級」、「エキスパート」の設定間の学習曲線を作成します。それは、APIやスクリプトを提供することまで可能です。すべてのユーザーが平等に足を踏み入れているわけではありません。階層化されたシステムは、それぞれがくつろいでいるように感じさせます。また、初心者が「キュレート」から「上級」に切り替えたときに、進歩感と達成感を生み出すこともできます。

さまざまな分野の良い例には、Firefox（設定、about：config、userchrome.css＆al。）、Chrome（基本設定と「内部」）、Mac OS X（設定ペイン、「defaults（1）」、applescript / automator）があります。 、またはVimのvimrcです。悪い例には、設定ペインが迷路のように感じるアプリケーションが含まれます。私はあなたが頭の上から半ダースの名前を付けることができると確信しています（彼らがあなたを傷つけて忘れさせない限り）。

Firefoxが良い例かもしれません-ユーザーはUIをカスタマイズし、必要に応じてさまざまな拡張機能を追加することができます。コアプログラムはカスタマイズできませんが、残りは公平なゲームです。

アプリケーションが顧客や開発者の健全性のために頻繁に壊れる場合、多すぎる可能性があります。

私は.NET、SQL Serverデスクトップクライアントサーバーアプリを使用しています。

    Custom Tables
    Custom Stored Procs & Views (These can have data modification capabilities as well)
    Creation of custom data sources in the application (Inside or outside the 'live' database)
    Creation of custom grid forms based on custom data source or combining of custom data sources
    Creation of custom reports based on custom data sources
    Creation of custom logic script on data entry fields 
    Customizable data import functionality
    Customizable workflow process data entry and notifications
    Customizable selection and placement of data entry fields/controls on standard forms
    Detailed user security settings to all forms, data CRUD, app functionality and reports

真剣に、この会社はカスタマイズ可能な獣を作成しました。垂直市場向けに設計されていますが、他の実装は無制限である可能性があります。

私はカスタマイズ可能性を考慮して設計するのが好きですが、それを実装する前に、他のすべてを本当にしっかりしたいのです。実際、ユーザーがカスタマイズ可能な機能を追加することを考える前に、ユーザーがバージョン1.0を扱えるようにしたいと思います。

それより前は、実際のユーザーにとってどのようなカスタマイズが役立つかわかりません。彼らは、インターフェイスの動作に満足しており、ボタンやメニュー項目の位置を変更できるほどのカスタマイズ性を備えているのではなく、より多くの機能を利用したいと考えています。

多くのカスタマイズを行うよりも、ユーザーの手を少し強制する本当に優れたインターフェースが欲しいのですが、アプリケーションがリリースされるまでさらに6か月または1年待ちます。送料が特徴です！

これの唯一の明確な例外は、キーストロークの組み合わせが必要な場合、ほとんどの場合、それらをカスタマイズ可能にすることです。ユーザーが他に実行しているものを知らないため、他のアプリケーションと衝突するのは非常にイライラするからです。ユーザーが簡単に回避できない方法。

最も基本的で常識的な構成をメニューに追加して、ユーザーインターフェイスから直接調整できるようにすることができます。それ以外のすべては、構成ツールなどからアクセスできる構成ファイルまたはその他の手段に入れることができる、より複雑です。

そうすることで、最も一般的で専門性のないユーザーはアプリを使用するために必要な基本構成にアクセスでき、より専門的で専門家またはその他の関心のあるユーザーは、高度に専門化されたニーズに合わせて追加の構成を使用できます。

これは、ユーザーフレンドリーで高度にカスタマイズ可能なアプリを用意することの間の最良のトレードオフだと思います。ただし、これが成功するのは、構成を分割する方法です。重要なものはどれですか？それは私が考える難しい部分です。そして、誰かが何かを台無しにした場合に備えて、デフォルトにリセットボタンを追加することを忘れないでください。