機能の露出とUIの膨張
Webアプリケーションを開発するとき、私は通常、機能/機能ごとにアイコン/ボタンを用意し、通常の作業中にユーザーの注意をそらさずに簡単にアクセスできるように配置する傾向があります。ただし、特定のボタンを複数の場所に配置し、できるだけ表示する必要があると感じているため、管理の一部と対立することがよくあります。
これについてどう思いますか？同じコンテキスト内のボタン/機能に1つの場所がある場合、ユーザーは常にそれを探す必要があります（私のアプローチ）、またはユーザーが必要とする可能性があるすべての場所にボタンを複製する必要がある場合（管理のアプローチ）。
例：
-editオプションはツールバーメニュー内にあり、設定画面のタブのすぐ横に別のeditボタンを配置して、アプリの編集モードに切り替えます。すぐには見えない
-saveボタンをandの上にtextareaの下に置きます。これは、ユーザーが入力を終了している可能性があるためです（下のsaveは近いです） ）または、プレビューの読み取りを終了します（上部saveは閉じています）
議論の背後にある私たちの推論：
私のアプローチ：
+滑らかなデザイン
+未使用のアイコンは非表示のまま
+構造
-ソフトウェアを以前に使用したことがないユーザーは、機能の検索/検索が必要になる場合があります
経営陣のアプローチ
+関数は、必要な場所に表示されます
-まったく同じ機能のための冗長なUIコンポーネント
-整理されていないルックアンドフィール
-UI膨張
私は推論が偏っているように思われますが、それが私が尋ねている理由です。どのアプローチでUIが向上しますか？
アクションの重複は必ずしも悪いわけではありません私の意見では。特に、ユーザーの観点から見た場合、まったく同じではありません。
私は結局のところ、1つの方法はありませんすべてについて従うと思います。それは、複製を行うのではなく、可能な限り複製することではありません。手元のケースを見て、ユーザーがここで何を考えているか、通常のパターンは何か、それがアプリケーションではなく紙の物である場合はどうするか、どのように考えるかを決定します。そしてそれに基づいて、どのようなアクションを提供するかを決定します。
最初の例に入る：
editオプションはツールバーメニュー内にあり、すぐには表示されないため、設定画面のタブのすぐ横に別のeditボタンを配置して、アプリの編集モードにします。
私はこれがあなたの言うことだと思います：
その場合、2つのアクションはユーザーにとって異なる意味を持ちます。最初の「編集モード」では、それらを編集/編集の方法で（また、自分の心の中に）入れ、すべてを編集可能にします。 2番目の「これらの設定を変更」は、このページでのみそれを行います。
2番目の例：
saveボタンをandの上にtextareaの下に配置します。これは、ユーザーが入力を終了している（下のsaveが近い）か、プレビューの読み取りを終了しているためです（上のsaveは近いです）
私は最近同様の状況にありました：
この場合、最初の保存ボタンは変更をすばやく行う方法を提供します。 [編集-何かを変更-保存]は簡単に実行でき、ユーザーはフォーム全体を下にスクロールする必要はありません。また、ユーザーが詳細オプションを設定する必要がある場合は、フォームをたどって下部に保存できます。
（詳細設定を最初の保存ボタンの上にあるリンクの下に置き、リンクをクリックすると展開されるようにすることもできます。ただし、これは必ずしも望ましいことではありません。）
冗長性は常に悪いと誰が言うのですか？同じことをすべて行うメニュー、ツールバー、キーボードショートカットが一般的です。複製がそれぞれ何かを追加しない場合（つまり、実際には完全に冗長である場合）、その後何かを削除するときが来ましたが、ビットではない可能性がありますあなたが最初に考えます。
Gmailでは、replyはメッセージの上およびの下にあります。これは、ユーザーが上または下にスクロールした可能性があるためです。ページの反対側にあるボタンを見つけるのが難しくなっています。この問題はデスクトップアプリには存在しないため、両方の場所にボタンを含めるのに十分な理由はありません。
秘訣は、バランスを保ち、すべてをどこにも置かないようにすることです。 グループ化に関連する機能の原則は両方向に役立ちます-ローカライズされた機能に実際に関連している場合は、物事を邪魔にならないように隠さないでください。ユーザーが実行するタスクを実行するのに役立つ場合を除きます。後者のケースは、ユーザーが一度設定すると忘れるオプションと設定をカバーします。一度クリックするだけの場合は、Optionsボタンを邪魔にしないでください。
アプリの各部分の最も一般的な使用例を把握し、それらの使用例に合わせてUIを最適化します。これがlittle冗長性。
Microsoftの リボン を使用すると、「クイックアクセス」ツールバーにさまざまなコマンドを追加できます。そのアイデアを拡張して、最初にそれらのコマンドを追加するだけで、ユーザーが不要なコマンドを削除できるようにすることができます。
フローティングバーやウィジェットを備えた多くのWebサイトがスクロールに関係なく表示されているのを見てきました。そのようなバーは、「編集」、「保存」、またはその他のコマンドを表示するために使用できないのではないでしょうか。これは明らかに、ページ全体が保存される場合にのみ機能すると思います。
さて、実際のユーザーはそれについてどう思いますか？また、ユーザーテストを行った場合、両方の実装にどのように対応しますか？それらが決定的な要因だと思います。アプリケーションは主に使いやすいはずだと思うので、UIの膨張を回避すること自体は目標ではなく、使用可能な状態を維持する手段です。余分なボタンがユーザーに役立つ（使用頻度の高い機能をより簡単にアクセスできるようにする）場合、それがユーザーを妨げる（ユーザーに混乱を招くインターフェースを提示する）場合よりも、そうするべきだと思います。
（そして、ほとんどのGUIにはすでに冗長性があることに注意してください。特定のオプションは、上部のメニュー項目、ツールバー、コンテキストメニューにリストされ、キーボードショートカットがあります。）
編集モードを多用すればダイレクトボタンに値すると思います。
多くのWebアプリケーションには、コンテンツ（特にショッピングカート）の上下に[保存/送信]ボタンがあります。
ボタンが同じように見え、互いに整列している限り、何も問題はありません。
コンテキストボタン（行の編集ボタンなど）は、それらの行に関連付ける必要があります。多分選択をサポートしている場合を除いて、ツールバーよりも（おそらくホバー上に）行に編集ボタンを配置する方が良いでしょう。