アプリケーションに「管理できない」数の設定がある場合はどうしますか？

Question

Googleのマテリアルデザインがアプリケーション設定のパターンにアプローチする方法が好きです。

設定は適切に構成され、予測可能であり、管理可能な数のオプションを含む必要があります（強調が追加されました）。

私の質問は、アプリケーションにある設定の数が管理不能になった場合に何が起こるかです。

現在取り組んでいるアプリケーションでは、さまざまなクライアントが新しい機能を要求したときに出てきた1回限りの構成のダンプ場所として、「その他」セクションがいくらか使用されていました。ご想像のとおり、ここ数年でかなり多くの編集可能なフィールドが増えてきました。

私が今持っているタスクは、すべてを一般的なその他のカテゴリに分類しないように、それを調べて再編成することですが、問題の核心は、ユーザーがアプリケーションを構成できる方法の数があまりにも扱いにくいことです。

オプションを分類するほど、セクションが多すぎて見つけて通過できないため、ユーザーがナビゲートしにくくなります。カテゴリーの数を制限し、各グループ内にできるだけ多く含めるようにすればするほど、実際には属さない設定をグループ化するという古い問題に遭遇します。

実際、私たちの問題はすべて、アプリケーションが高度にカスタマイズ可能であり、多数の構成可能な設定が含まれているという事実から生じています。

アプリケーション内で、本質的に大きく、やや管理できない量の設定を管理しようとすることに関する資料はありますか？それは矛盾しているように見えますが、それは私が自分を見つけた現在の状況です。

ありがとう。

tohster · Accepted Answer

いくつかの補完的なアプローチがあります...

...複雑さを軽減します。多くの場合、効果的な設計は、ユーザーベースに合わせて調整された複数のアプローチの適切な組み合わせに依存しています。たとえば、Eclipseユーザー（ここで別の回答を参照）は、複雑さをナビゲートする方法を理解しており、多くの制御を必要とする可能性があるプロ/エキスパートユーザーである傾向があります。 Google Chromeユーザーは異なります...彼らは必ずしもエキスパートユーザーではないため、Googleは設定の多くの複雑さを隠しています。

構成の複雑さを軽減するためのいくつかの一般的な手法を次に示します。

1.頻繁に使用する設定とほとんど使用しない設定

パレート原理は通常、複雑な設定に適用されます。 20％の設定が80％の時間使用されます。したがって、ほとんど使用されない80％の設定を、 More settings または Advanced settings ボタン。

2.通常の設定とエキスパート設定

これは、複雑さを軽減するもう1つの方法です。高度な設定を Advanced settings エキスパートユーザーが微調整できるセクションですが、通常のユーザーは膨大な数のオプションを視覚的に処理する必要はありません。

3.ユーザーに検索を許可する

これは、複雑さを軽減するための実証済みの方法です。 Appleの設定UIは、関連する領域を強調表示する検索機能を提供し、用語のオートコンプリートも提供します。

4.分類法を使用する

設定を論理的な階層またはカテゴリのセットにグループ化し、視覚的にそのようにレイアウトします（例：表示、時刻/日付、ファイル処理、データソースなど）
タブレイアウト、ツリーコントロール、ナビゲーションバー、メニュー/サブメニュー、ページセクション、およびレイアウトアイランドは、分類法を理解したら、カテゴリを提示する効果的な方法です。しかし、それは適切な分類から始まります。

5.ガイド付きパス

ワークフローを必要とする、または依存関係を伴う構成/設定の場合、構成プロセスを通じてユーザーを支援する必須またはオプションのウィザードを提供すると効果的です。
- たとえば、工場のシステムで1つのコントロールを変更すると、別の一連のマシンに影響する場合、ユーザーが静的設定ページを使用してシステムを構成するのを支援するのは難しい場合があります。ウィザードUIがこれらの特定のワークフローに役立つ場合があります。

6.アプリの複雑さを軽減する

アプリの機能を統合し、めったに使用されない機能や冗長な機能を削除し、共通要素の同様のワークフローをより汎用的で柔軟なフローに統合します。
エンジニアリングのコストのため、カスタムアプリでこれを行うのは困難または費用がかかる場合がありますが、広く使用されているアプリ（Gmail、Excelなど）の場合は、UXの全体的な複雑さを軽減するためにいくつかの機能を統合する価値があることがよくあります。

繰り返しますが、ここでの効果的な設計は、ユーザーが誰であるかを十分に理解し、これらのアプローチの1つまたはいくつかをどのように採用するかを慎重に選択することによって決まります。

Simon White · Answer

設定を削除。限目。

理想的には、アプリケーションにはzero設定があります。ユーザーhate設定。ユーザーは、実行しているコアタスクから時間を費やします。たとえば、描画アプリでは、ユーザーは描画に100％費やすのが理想的です。

設定を削除する方法は、設計上の決定を行うことです。アプリに管理できないほどの量の設定がある場合は、設計の決定をユーザーに任せている可能性があります。各設定の適切なデフォルトを決定するのがいかに簡単か難しいかに注意してください。デフォルトを簡単に決定できる場合は、その設定を削除できます。デフォルトを決定するのが難しい場合、たとえば、ユーザーの50％がデフォルトをオンにし、ユーザーの50％がデフォルトをオフにしたい場合などは、その設定をそのままにしておく必要があります。

Daniel Beck · Answer

多数のユーザー設定/設定が適切である、または予想されるアプリケーションもあります。そして、これらの設定をいじるのを楽しむ観客がいます。

この特定のケースの歴史は、あなたがあなたのケースではないことを強く示唆しています：

さまざまなクライアントが新しい機能を要求したときに登場した1回限りの構成。

これは偶発的な設計の悪い例のように聞こえます。ユーザー設定としてそれらをダンプすることにより、設計の決定を延期してきました。特異な顧客の要求または一時的なものは決してUIへの道を見つける必要があります-何かが1人の人にのみ役立つ場合、それを全員に置く理由はありません他の方法。これらを1日中並べ替えることはできますが、それでも、ほとんどの場合はそもそも存在すべきではないという根本的な問題を解決することはできません。

最初のステップは、これらの設定ごとに既存の顧客データを調べ、次のカテゴリに分類することです（「この設定を使用する」とは、「デフォルト値以外の値に設定した」ことを意味します）。

現在の顧客はこの設定を使用していません-これらの多くが見つかります。それらを削除します。
単一の（重要な）顧客が使用する1回限りのものです-UIから削除し、顧客固有の構成ファイルに移動します。
少数のお客様がこの設定を使用しています-これを構成ファイルに移動する価値があるか、次のステップのために保持するか、単に削除するだけの価値があるかを判断します。設定が主に表面的なものまたはワークフロー指向である場合、つまり、ユーザーが設定なしで同じ結果を得る方法がある場合、それを排除することを誤る。
大多数のお客様はこの設定を同じ方法で使用しています-これを新しいデフォルト値にして、UIからオプションを削除することを検討してください。（「デフォルト以外の設定を選択したすべての人」は、「これをデフォルトのままにしたすべての人」よりもはるかに強いシグナルです。）
これは頻繁に使用され、広範囲の設定値で-最後に、良いものに到達していますが、これらもサブカテゴリに分類されます。
- 純粋な化粧品、製品の使用に機能的な影響はありません：化粧品のカスタマイズが製品の重要な機能でない限り、理想的には製品の全体的な化粧品の再設計の一部としてこれらを排除して、ユーザーが使用しないようにします「あなたは私の特別な雪片の設定を取り除いた！」
- Bike-shedding「製品が通常行うのと同じことを行いますが、当時は重要であると思われた理由のため、少し異なる方法で」に要約される設定：上記のように、設定を削除します
- Set-and-forget意味があり有用な設定ですが、一度設定すると特定の顧客が変更することは決してないか、ほとんどありません。これらを設定ファイルに移動することを検討してください（特にこれらが多数ある場合）。日常のUIではなく、新規ユーザーの「ウィザード」などをオンボーディングプロセスの一部にします。または、少なくとも頻繁に変更される設定とは別にしてください。
- 実際の意味のあるアプリケーション設定これらはキーパーです。これらを要約すると、おそらく何が残っているかを整理する方法が明らかになります。

Michael Lai · Answer

1つの可能な解決策は、特にユーザーがアプリケーションを使用しているときに調整または変更される可能性がある場合（特に、ユーザーが設定ページに戻ります）。あるいは、同じページに設定を表示したくない場合に、ヒントまたはツールチップとして表示されるリンクにすることもできます。

他にできることは、命名規則について考えて、完全に意味のある設定ではないにしても、設定にラベルを付けて、グループ化または順序付けを簡単にできるようにすることです。そうすれば、少なくともユーザーがそれらを学習して見つけるのが面倒になるのを少し減らすことができます。

Cai · Answer

タブで設定をグループ化する

最近の question から画像を取得すると、タブを使用して設定をグループ化する方法に関するいくつかのオプションが表示されます。

オプション1は良い解決策ではなく、本質的にはあなた（そして私）が始めた問題です。オプション2と3は、目指すべきものです。オプション3は視覚的には理想的なソリューションだと思いますが、設定の論理的なグループ化が優先され、使用するグループ化は実際の設定と使用方法によって異なります。

考慮すべき最も重要なことは、設定を十分に説明的なラベルで論理的にグループ化する必要があることです。これにより、設定を簡単にナビゲートできます。

前の質問のicc97の answer から：

Jacob Neilsenのタブ、使用済みから：

タブの背後にあるコンテンツを論理的に分割するため、ユーザーは特定のタブを選択したときに何が表示されるかを簡単に予測できます。

YetAnotherRandomUser · Answer

設定には何らかのタイプの説明を実装し、関数の名前、その説明、および設定を説明するために使用されるいくつかの一般的な単語を検索する検索機能を用意する必要があります。スタック交換では、これらの一般的な単語はタグと呼ばれます。

リスト、階層構造、またはタブベースの構造のいずれを使用する場合でも、検索機能はユーザーが探しているものを見つけるのに非常に役立ちます。

このための鍵は、優れた検索エンジンを使用して、使用可能な結果を生成することです。適切なタグをバックグラウンドでシードできれば、それほど難しくありません。

Adrian Long · Answer

フリッパーの答え：
選択肢が少ない。

少ないフリッパーの答え：一般的な使用パターンを探すことで、オプションと設定の数を減らすことができるかどうかを確認します。

なぜそれらすべてのオプションがあるのですか、そしてそれらは何に関係していますか？通常、各オプションが含まれるのは、質問への回答がわからなかったためです。そのため、回答の作業はオプションの形でエンドユーザーに返されます。

設計の問題に対処するのではなく、その問題をユーザーに投げかけることが、最善の解決策になることはほとんどありません。

したがって、この種の質問に対処するには、誰のために構築しているのか、何のために解決または提供しようとしているのかを理解することが重要です。設定は誰のためのものであり、設定は何を提供しますか？

非常に役立つ1つの方法は、事前に設定をマップすることです。

これを行うには、次のことを試してください。

1つの列のすべての設定と可能な値のリスト（例：「設定A-値1」、「設定A-値2」、「設定B-値1」）
次の列で、ユーザーが値を指定する必要があるかどうか、または実用的なデフォルトがあるかどうかを指定します（ヒント：問題なく実行できる場合は、常に適切なデフォルトを設定してください）
次の列で、setting + valueがもたらす利点-何ができるかofferを要約します
次の列で、offerのペルソナを指定します。

それらのいずれかが列に複数の値を持つ必要がある場合は、行を複製して、各行に1つの値を配置します。

これが完了したら、手順3で作成した列を少し簡略化または正規化して、「Better X」、「Easier Y」、「More Detail but more noise」などが表示されるようにします。

次に、列を列3または4で並べ替えて、どのようなグループが出現するかを確認します。

例1-「詳細はあるがノイズが多い」または「詳細は少ないがノイズが少ない」に関連する設定が30または40ある場合、これらの設定をすべて1つのスライダーに集約できる場合があります。

例2-ペルソナAが常に必要とする一連の値と、ペルソナBが常に必要とする別の一連の値がある場合...提示するのではなくすべて、「（ペルソナA）モード」または「（ペルソナB）モード」を提供するスイッチを提示します。 reallyがその1人のユーザーの数千の微調整を許可する必要がある場合は、それを「詳細設定」ページにパントします。ユーザーが混乱している場合は、通常の使用範囲を超えていることをユーザーに明確に伝えます（chromeの「chrome：// flags」ページのように）。