アプリケーションがカスタマイズしすぎるのはいつですか？
デスクトップアプリケーションを開発していて、ユーザーがメニュー、ボタン、キーマッピング、およびその他のコマンドとコンポーネントをカスタマイズできるようにしたいとします。どのくらいのカスタマイズを許可する必要がありますか？
私は自分の環境がほぼ無限にカスタマイズ可能であることが好きです。また、環境に適切なデフォルトのセットを設定して、すべてを設定するのではなく、必要な設定を微調整できるようにしたいです。私の好みを支持または否定するために指摘するユーザーエクスペリエンスを誰かが持っていますか？
追加するすべてのオプション/カスタマイズにより、プログラムがより複雑になり、使用と保守の両方が困難になることに注意してください。ほんのわずかな割合の人しか使用しないものであれば、それだけの価値があるかどうかを尋ねます。
カスタマイズを可能にすることがユーザーに大きなプラスの違いをもたらす場合。
基本的に、他の要件と同じです。実装するためのコスト/労力を正当化する必要があります。それは生産性や使いやすさの向上、またはユーザー満足度のある程度の向上かもしれませんが、それに伴う努力を正当化する何らかの理由があるはずです。
カスタマイズが好きな人として、自分自身に尋ねるべき質問は次のとおりです。
私が支払っている場合、このレベルのカスタマイズに対して何を支払うでしょうか？私のような人は何人いますか？そしてそれはそれを開発するコストをカバーするでしょうか？
競合他社は何をしていますか？この分野の製品に期待することは何ですか？
カスタマイズ可能にするために労力を費やす代わりに、他の機能にその労力を費やすとしたら、どちらを好みますか？これは一般的なユーザーに当てはまりますか？
実装することを選択したものはすべて、（少なくとも今のところは）実行しないことを選択したものであるため、必要な作業をすべて正当化する必要があることを忘れないでください。
ユーザーにそれぞれの小さなことをカスタマイズさせたい理由を自問してください。自分で設計上の決定を下すことを避け、代わりにユーザーにそれらを強制することですか？
これは、この件に関するジェフの良い投稿です： http://www.codinghorror.com/blog/2005/09/the-problem-with-configurability.html
一般に、ユーザーは、ニーズを満たすためにカスタマイズする必要があるほどよく考えられていないアプリケーションを嫌います。私の経験では、ほとんどのユーザーはIT担当者ほどコンピューターの使用に慣れておらず、オプションが与えられてもカスタマイズしません。
適切な設計作業を回避するためにカスタマイズしている場合は、カスタマイズしすぎています。要件ではなく、カスタマイズが好きなためにカスタマイズしている場合は、カスタマイズしすぎています。カスタマイズする真の要件がある場合でも、それが良いアイデアかどうかを質問し、カスタマイズが必要であると彼らが考える根本的な理由を見つける必要があります。要件を実行している人との対話を開始する場所としてカスタマイズの要件を使用すると、多くの場合、彼らが言及していなかった新しい要件が見つかります。
アプリケーションによって異なります
これは警官のように聞こえるかもしれませんが、実際にはそうではありません（または、少なくとも、そうすることを意図していません）。
カスタマイズの量は、部分的には、予想されるエンドユーザーの洗練度に依存する必要があります。エンジニアのタイプは、たとえば、私のおばあちゃんがWin98マシンでソリティアをプレイするよりも、ユーザー設定に侵入していじくり回す可能性がはるかに高くなります。
また、アプリケーション自体が何であるかにも依存します。アプリケーションのポイントが使いやすさである場合、ユーザーが構成可能な多数のオプションでそれを混乱させたくはありません。
構成可能なオプションが多すぎると、アプリケーションが非常に複雑に見えます。これらのオプションがたくさんあるアプリケーションを作成する場合は、少なくとも「詳細...」構成画面またはダイアログでそれらを「非表示」にし、そのアプリケーションの平均的なユーザーが行うもののサブセットのみを配置します。 「通常の」オプション画面で変更したい。
別の選択肢は、何かを「スキニング」することです。これは、従来の「スキニング」のもの（たとえば、Windowsの表示プロパティの[外観]タブ）を意味する場合もあれば、一度に設定される一連のオプション（たとえば、同じの[テーマ]タブ）を意味する場合もあります。ダイアログ）。
私は一般的に気にしません。私は多くの異なるマシンで作業する必要があり、それらをすべてカスタマイズしておくことは、見た目よりも面倒です。あるマシンでカスタマイズを行うと、別のマシンにカスタマイズがない場合にイライラします。カスタマイズの移動を簡単にすることは、いくらか役立つでしょう（emacsユーザーとそのサイト-LISPファイルを検討してください）が、とにかくあまりにも面倒だと思うことがよくあります。
アプリがそのままではうまく機能しないが、カスタマイズする必要がある場合は、失敗しています。
お気に入りのソフトウェアをマシンにインストールしたいのですが、それがカスタマイズの意味ではないと思います。
カスタマイズ性に関する1つの問題は、それがあなたが尊重しなければならないすべての顧客への約束であるということです。バージョンAを送信すると、顧客がカスタマイズします。すべてうまくいっています。では、バージョンBで何をしますか？顧客のカスタマイズを破ると、顧客は動揺し、何度もそれを行うと、顧客はカスタマイズに非常に消極的になるため、ごく少数の人が使用するカスタマイズ機能が残り、イライラすることになります。顧客。
これは、アップグレードごとにどのようなカスタマイズを行ったかに注意を払う必要があることを意味します。これは、カスタマイズを台無しにすることを除いて、簡単に実行できるはずの何かを再構築したいときに頭痛の種になる可能性があります。相互作用が悪い可能性のあるカスタマイズの可能な組み合わせに注意を払う必要があります。
次のいずれかに該当する場合、プログラムはカスタマイズ可能すぎます。
物事のための合理的なすぐに使えるデフォルトはありません。あなたがそれをカスタマイズしなくても、ものが合理的にうまく機能するならば、カスタマイズ性ははるかに口当たりが良いです。たとえば、viは、バックスペースキーと矢印キーの機能に関するすぐに使用できる動作が、マシンの他の部分の規則とは大きく異なるため、嫌いです。これはカスタマイズできることは知っていますが、ストックマシンに近づいたときは、いじくり回すのに時間を浪費するまで、基本的に使用できません。
プログラムをカスタマイズ可能にしたので、ルックアンドフィールはすべてのマシンやLinuxディストリビューションなどで効果的に異なり、「一度学習してどこでも使用」することは事実上できません。繰り返しますが、viを参照してください。
内部プラットフォーム を構築したので、ユーザーは外部プラットフォームを使用して目的を達成したほうがよいでしょう。たとえば、テキストエディタまたはコマンドラインテキスト処理ツールが強力になりすぎると、より複雑なテキストを実行するために、すばやく汚い、アドホックなPythonスクリプトを作成する方が簡単です。内部プラットフォームを使用してそれらを行う方法を学ぶよりも操作。同様に、プロットライブラリが強力になりすぎたら、その上に構築されたGUIライブラリをユーザーに直接操作させて、プロットの詳細をカスタマイズする方がよいでしょう。 。
TL; DR：アプリケーションが威圧的なフレームワークになったとき。
アプリケーション開発者の観点からそれは、ユーザーがアプリケーションのセットアップ方法を報告できないため、またはさまざまな設定のために、カスタマイズによってアプリケーションが中断し、サポートが不可能になる場合です。相互作用が曲がりくねりすぎて、頭や尾を作ることができなくなります。カスタマイズシステムを十分に検討し、意味のある方法で情報が返されるようにします。
アプリケーションユーザーの観点から、それはユーザーが「プログラミング」の大まかな定義のために、多くの場合プログラミングに似ているために、アプリケーションのセットアップが困難であると感じるときです（これにはGUI指向プログラミングが含まれます）またはBlinkenswitches）。
はい線はぼやけています。
はい、優れたコードまたはGUI（再）設計により、アプリケーションのスイッチボードを作成できる場合があります同じカスタマイズ可能な機能セットを使用している場合でも。
「カジュアル」、「上級」、「エキスパート」の設定の間に学習曲線を作成します。 APIやスクリプトの提供にまで及ぶ可能性があります。すべてのユーザーが対等な立場で始めているわけではありません。階層型システムはそれぞれがくつろげるです。また、初心者が「キュレーション」から「アドバンス」に切り替わると、進歩と達成の感覚を生み出すことができます。
さまざまな分野での良い例としては、Firefox（設定、about：config、userchrome.css＆al。）、Chrome（基本設定と「内部」）、Mac OS X（設定ペイン、「デフォルト」）があります。 （1） "、applescript/automator）、またはVimのvimrc。悪い例としては、設定ペインが迷路のように感じられるアプリケーションがあります。頭のてっぺんから5ダースの名前を付けることができると思います（トラウマを負わない限り）それらを忘れる）。
Firefoxは良い例かもしれません-ユーザーはUIをカスタマイズし、必要に応じてさまざまな拡張機能を追加することができます。コアプログラムはカスタマイズできませんが、残りは公正なゲームです。
顧客や開発者の正気のためにアプリケーションが頻繁に壊れてしまう場合は、多分多すぎます。
私は.NET、SQLServerデスクトップクライアントサーバーアプリを使用しています。
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年待ちます。 配送は機能です！
これに対する唯一の明確な例外は、キーストロークの組み合わせが必要な場合、ほとんどの場合、それらをカスタマイズ可能にしたいということです。これは、ユーザーが他に何を実行しているかがわからず、他のアプリケーションと衝突するのが非常に苛立たしいためです。ユーザーが簡単に回避できない方法。
最も基本的で常識的な構成をメニューに追加して、ユーザーインターフェイスから直接調整できるようにすることができます。他のすべて、それはあなたがいくつかの構成ファイルまたは構成ツールまたは何かからアクセスできる他の手段に入れることができるより複雑です。
そうすることで、最も一般的な専門外のユーザーはアプリを使用するために必要な基本構成にアクセスでき、専門家、専門家、またはその他の関心の高いユーザーは、高度に専門化されたニーズに合わせて追加の構成を使用できます。
これは、ユーザーフレンドリーで高度にカスタマイズ可能なアプリを使用することの間の最良のトレードオフだと思います。ただし、これが成功するのは、構成を分割する方法です。ちょっと凝った調整のためだけの重要なものはどれですか？それが難しい部分だと思います。そして、誰かが何かを台無しにした場合に備えて、デフォルトボタンにリセットを追加することを忘れないでください。