ブラウザ内の小さなJSウィンドウに対して優れたUXガイドラインが存在しますか
ブラウザ内に小さなウィンドウシステムを本質的に実装する多くのWebアプリケーションに遭遇しました。あなたのウェブページには、ウィンドウのように見える小さなボックスがいくつかあり、移動、サイズ変更、閉じなどができます。これまで見たほとんどすべての状況で、これは設計原則の多くに違反する非常に悪い考えですこのサイトで話しました。例えば：
- 一部の情報で小さなウィンドウを開くことはできますが、ブックマークして後で戻ることはできません
- これは通常、「戻るボタンを壊さない」という規則に違反しています。
- これらのアプリケーションでは、標準のブラウザタブを使用できません。新しいウィンドウで開く/タブが機能しない。
- アプリケーションの異なる部分を異なるモニターで開くことはできません。すべてのモニターよりも大きくなるように引き伸ばされる可能性がある1つの長方形の領域にすべて存在する必要がありますが、これは非常に不便です。
- これらの小さなウィンドウはブラウザのタブと同じようには機能せず、他のアプリケーションとうまく混ざりません。
これは単なるサンプルリストです。問題の詳細な調査は行っていません。この種のことは本当に悪い考えであることを明確にする深刻なガイドラインはありますか？それとも私は間違っていますか、そしてこのように物事を行うには本当に正当な理由がありますか？
私が見るところの問題は、この種のUIは、企業が使用するアプリケーションを購入する人々にとって非常に見栄えがよいことです。 FlashまたはHTML5を使用して、そのページ内を移動できる小さなウィンドウを作成すると、それが良いGUIであるという表面的な感覚が得られます。通常、そこには素晴らしいグラフィックがあり、洗練された外観を持っています。しかし...実際にそれを使用しなければならないときに、使い勝手が悪くなります。
RESTアプローチでは、小さなJavaScriptの模倣ウィンドウではなく、実際のブラウザウィンドウ/タブを使用する方法を実装する方がはるかに良いと思います。1つのアプリケーションは、動作するフォームを表示するFlashベースのUIを使用しますこのフォームの使用に関連しない他の情報の上にポップアップウィンドウレットとして表示されます。アプリケーション内のほとんどの時間はポップアップフォームで費やされます。また、ブックマークしたり、誰かを参照したりする方法はありません。 ..常にアプリケーションのルートを入力し、その特定のドキュメントに戻る方法を参照する必要があります。この種のユーザーエクスペリエンスの問題を説明するための優れたリソースはありますか？
独占的な金儲けの作家として、UX、エンタープライズソフトウェアは気にしない;-)ここで、AgileProがいくつかの有効な質問をしていると言わざるを得ません。
私の見解では、jsウィンドウシステムを作成することで、ユーザーに優れたエクスペリエンスを提供できる限られたケースがあります。しかし、いくつかの背景が最初です。
アプリケーションのクライアントとしてブラウザーを選択すると、多くの点でブラウザーの設計目的の制限が拡大します。多くの点で、まだ1プロセスずつのエクスペリエンスであり、そのため、ブラウザーは非常に優れた機能を果たしています。ただし、アプリケーションフレームワークとしては、悪臭を放ちます。
複数の小さなjsウィンドウが内部にある1ページのアプリは、小さなアプリではうまく機能しますが、「より大きく」独占的でお金を稼ぐ、I-got-the-users-by-their-ballsアプリケーションでは機能しません。 Dユーザーは閉じ込められたと感じます。
このアプローチを試みた「ウェブ上で新しいOSを構築する」ためのプロジェクトもかなりあります。試してみる前は、最初はこのアイデアが気に入りましたが、今ではほとんどがなくなっていると思います。
「意図したとおりに」ブラウザを使用する場合、エンタープライズアプリケーションUXは適切に動作し、戻るボタンと互換性があり、単一プロセスであり、エラーがなく、ユーザーを夢中にさせるでしょう。どうして？概要、複数のウィンドウ、マルチプロセス、モーダルダイアログ（その機能）が表示されず、関連する、または関連しない何かの新しいプロセスを開始することはできません。前のウィンドウの状態が失われるリスクはありません。
プロのユーザーは多くのタスクを実行する必要がありますAT同じ時間です。明らかに、これは最新のブラウザー設計の強みではありません。しかし、私は愚痴を言っていますか？私は望んでいません。コストと配布という2つの主要な問題を解決します。基本的には無料でどこにでもあります。欠点は、私たちが何をしようとしているのかを考慮して設計されていないことです。
結論：
- 限られた1ページのアプリはうまく機能しますが、小さなアプリケーションに限られます
- 大規模なアプリケーションの場合、余裕がある場合、完全な制御が必要な場合、完全に頭がおかしい場合は、独自のクライアントを作成します。
- 他のすべてのケースでは、ブラウザを使用してイライラする準備をし、現在設計しているものはすべて、数年先のブラウザでは絶対に機能しないことを認識してください。
これがあなたを捨てないことを願っています。結局のところ、簡単だったとしたら、私たちには仕事がありません。 =）
トリガーされるJSウィンドウは、シングルサインオンやユーザーからの承認などのトランザクション項目にのみ使用する必要があります。トランザクションの状態として情報または知識の共有を表示するために使用する必要があります。 RESTベースのアプローチを採用できますが、プロジェクトが投資する予定の金額に大きく依存します。このような依存要因もUXに影響します-技術的な制約のある設計です。これは明示的なJSだけに限定されませんWindows、むしろJSモーダルボックスの実装。
幸いなことに！または、タブやフローティングウィンドウなどの確立されたUI要素を使用しないことを推奨するのはなぜですか？このようなガイドラインを適用するための参照として、悪い実装を実際に使用することはできません。
タブやフローティングウィンドウを防ぐと、ユーザーの利便性が大幅に向上するからです。そして、実際のブラウザのタブを開きますか？本当に？
最後に;そのようなことに反対しないでください。開発者がweb-2のきちんとした古い学校に追いつくのを待ってください。
忘れないでください。ブラウザは、この種のアプリケーションを実際にかなり難しくします。多くの場合、インスタンスのクラシックキーボードストローク（タブの変更）は上書きできません。
ps：私は何年も前からWebベースのIDEを開発しており、ユーザーの最後の状態（ウィンドウレイアウト、位置）を復元することは本当に大きな課題であると認めなければなりません。 ）。報酬として、Webベースのテクノロジーの弱点を克服し、それらを「ネイティブ」の対応物よりも改善して、web-uxの究極の現状に到達することさえできました。
g