皆さんも見たことがあると思います。「ComboA が選択されると、その選択内容に基づいて値を照会し、テキストボックス B に入力する」、または「ButtonC が押されると、テキストボックス C と D を無効にする」などのロジックを持つ基幹業務 UI。 . 上記のロジックの順列が複数ある場合は特に悪くなります。
これらの素敵なスクリーンの 1 つを再設計する機会が与えられたら、どのようにアプローチしますか? UI の前にウィザードを配置しますか? 単一画面のパラダイムを維持し、他のパターンを使用して UI 状態のロジックを保守可能にしますか? これが理想的にどのように提示され、実装されるかを決定するために使用するプロセスは何ですか?
これは応答にとって重要であるとは思いませんが、現在、この「機会」だけが提示されています。これは、JavaScript を使用してユーザーの選択に応答し、コントロールを無効にし、追加の ajax 呼び出しを行う ASP.NET Web ページです。データ。
あなたが見たいと思うかもしれない何かは、それらの依存関係のいくつかが、似ているように見えて同じ機能を提供している間、これらの要素が似ているが実際には異なる複数のページに分割されるべきであることを意味しないかどうかです。十分な類似点があったため、誰かがこれらをページにグループ化した可能性があります。
問題がまったく実装されていないかのように見てみることができるとしたら、今すぐ実装する必要がある場合、ユーザーインターフェイスをどのように構成しますか。それが根本的に異なり、既存のユーザーが大きな問題を抱えている場合は、妥協する必要があるかもしれません。しかし、エリーが言ったように、ユーザーの視点からそれを見てください。彼らはあなたの製品で動作しなければならないものです。
UI全体の状態を1つのオブジェクトでモデル化します。そのオブジェクトは、コンボボックスのオプションのリスト（そしてもちろんどのオプションが選択されているか）を含め、各UIオブジェクトが存在する必要がある状態を追跡する必要があります。
つまり、1つの状態オブジェクトを使用すると、画面全体を正しく再描画でき、UIで壊れた状態になることはありません。もちろん、何かが変更されるたびにすべてのコンポーネントを更新することはできません。そのため、状態オブジェクトの各セッターからのコールバックでコンポーネントを更新します。これにより、必要に応じて、同じ状態で2つのUIを使用することもできます。
KISSの原則から始めて、そこから作業を進めます。ソリューションを過度に設計しないでください。ユーザーのPOVから問題について考えてみてください。優れたUIは直感的であるため、優れたレイアウトを作成するための第一印象は、おそらく構築すべきものに近いでしょう。
そうは言っても、単一画面と複数画面、JavaScriptまたはAJAXのどちらでも、実際には問題ではありません。見栄えがよく、理解しやすく、舞台裏で、コメントが付けられ、明確なコードで記述されている場合は、機能します。保守可能である必要があるため、明確な機能を備えたモジュラーコードブロックを目指してください。
最も重要なのはユーザーエクスペリエンスであり、コードの保守性はそれほど重要ではないと思います。Webでは、ラウンドトリップを可能な限り最小限に抑えるようにしています。そのため、ユーザーが複数のページを移動したり、AJAXを介してページのほぼ全体を置き換える必要があるため、ウィザードのアプローチを採用するかどうかはわかりません（これは間違っているようです）。 。私は通常、顧客と協力して必要な機能をキャプチャしますが、実装ではなく機能を目指しています。いくつかの例をモックアップして代替案を示したり、ホワイトボードに手書きで描いてアイデアを出したりする場合があります。結果としてユーザーインターフェイスが大幅に改善された場合は、アプリで「難しい」または「複雑な」ことを行ってもかまいません。もちろん、私はそれをできる限りシンプルにし、Javascriptでも確実にグッドプラクティスを使用します。