問題タブ [user-experience]

私は Flex フレームワークがとても気に入っていますが、500KB 程度の SWF ファイルを日常的に扱っています。

どの時点でファイルが「大きすぎて」インターネットで提供できないと判断されたのかはわかりませんが、Web アプリケーションを使用するためだけに 500 KB のダウンロードを行うと、一部のユーザーは確かに不快になると思います。

コンパイル済み SWFS のサイズを小さくするためのヒントやテクニックはありますか?

ちなみに、500KB の SWF ファイルは実際にはそれほど大きなアプリケーションではありません...

J2EE アプリケーションでのエラー処理について質問があります。現在のアプリケーションは多くのユーザーによって使用されており、その結果、多くのサポート チケットを取得しています。これらのチケットのほとんどはユーザー関連ですが、5 ～ 10% はシステム関連の例外、未処理のエラーなどです。

コードには基本的な例外処理チェックがありますが (作業が必要です)、私の経験から、一般的なメッセージをユーザーに表示しても、トラブルシューティング プロセスを迅速化するのには役立ちません。

私が探しているのは、適切なエラー処理の設計パターンに関する推奨事項です。シナリオを考えてみましょう。

1. コードにエラーがあります
2. エラー処理
3. ユーザーには、特定のエラー コードを含む非技術的なエラー メッセージが表示されます。
4. テクニカル サポート以外のチームは、このエラー コードを使用して、アプリケーション内でこれが発生した領域 (ページ、セクションなど) と、ユーザーが何をしていた可能性があるか (カスタマー サポート リファレンス ガイドで開発チームが事前に入力した情報) を確認できます。
5. 技術サポート チームは、コードを使用して、クラス/JSP などと、その例外をトリガーしたコード行をゼロにすることができます。
6. ほとんどの(すべてではない) Tomcat stdout エラーがユーザー セッションによってログに記録されるロギング モジュールを使用します。ユーザーが受け取るエラー コードに、ログ ID が存在する場合はそれを含めて、技術チームがそれを確認できるようにします。それも。

基本的に私が興味を持っているのは、サポートの分析、説明、調査のサイクルを短縮し、すべての部門がそれぞれの仕事をより迅速に開始できるように、すぐに情報にアクセスできるようにすることです。

1. カスタマー サポートは、このエラー コードについて定型的な説明を提供したり、ユーザーが実行できる代替手順を提示したりできます。
2. 技術チームは、コード行またはその行をトリガーしたユーザーの操作のトラブルシューティングを開始できます。

必須の各エラー コードは、各部門に必要な次のステップをトリガーし、事実上、問題の調査段階を減らし、解決段階に移行します。

上記が良い考えであるかどうかはわかりません。そのようなニーズに適した「デザインパターン」についての提案をいただければ幸いです。または、それが一見の良いルートでさえある場合。

前もって感謝します。

SP

Web を使用していると、定期的に実行時エラー (通常は JavaScript) がポップアップで報告されます。これにより、他の点では優れた多くの Web サイトで本当に満足のいくユーザー エクスペリエンスが得られない可能性があり、また、どの機能にアクセスできないのか疑問に思うこともあります。

なぜこれが一般的な問題なのですか？これはテスト不足によるものですか、それともブラウザの互換性の問題ですか? この種の問題を最小限に抑えるにはどうすればよいでしょうか。

ちなみに、「スクリプト エラーごとに通知を表示する」にチェックを入れていません。

Struts と Hibernate を使用して JSP で Web サイトを作成しています。ボタンだけでなく、豊富な UI を実装する方法を探しています。たとえば、ドラッグ アンド ドロップ、さらに文字を入力するとリアルタイムで更新されるドロップ ダウン リストなどです。Struts や Hibernate で Swing のようなものを使用する方法はありますか? または、リッチ UI を作成するために利用できる他のオプションはありますか?? (より良い代替手段があれば、Struts や Hibernate を放棄することもできます)

根本的な問題:私が働いている組織は、使用できる開発ツールとオープンソース ライブラリについて厳格な規則を定めており、承認リストの更新が非常に遅いです。AJAX のもの (GWT、dojo など) はまだリストにありません。

この投稿を読んでいただきありがとうございます。

理論的には、エンド ユーザーに内部エラーが表示されることはありません。しかし実際には、理論と実践は異なります。問題は、エンド ユーザーに何を表示するかです。ここで、まったく技術に詳しくないユーザーの場合は、表示される情報をできるだけ少なくしたいと考えていますが (「ここをクリックしてバグ レポートを送信する」など)、上級ユーザーの場合は回避策があるかどうかを知りたがります、それがしばらくの間知られている場合など。そのため、何が問題なのかについてのある種の情報も含めたいと考えています。

これを行う古典的な方法は、filename:line-number を使用した assert または同じスタック トレースのいずれかです。これは開発者にとって良いことです。ただし、ユーザーにとってはいくつかの重大な欠点があります。特に、非常に不可解であり (不親切など)、コードを変更するとエラー メッセージが変更されます (エラーのグーグル検索はこのバージョンでのみ機能します)。

これらの問題に対処したい場所で書くことを計画しているプログラムがあります。私が欲しいのは、アサートの周りのコードを編集しても変更されないように、すべてのアサートに一意の ID を付ける方法です。(たとえば、別のファイルにカット/ペーストした場合、同じ情報が表示されるようにしたい) 何かアイデアはありますか?

私が考えている 1 つの方法は、エラーを列挙することですが、それらが複数の場所で使用されないようにする方法は?

（注：この質問では、コーディングエラーによって引き起こされたエラーのみを見ています。不正な入力のように合法的に発生する可能性があるものではありません。OTOHこれらのエラーは、コミュニティ全体にとって何らかの関心があるかもしれません。）

(注 2: 問題のプログラムは、ユーザーのシステムで実行されているコマンド ライン アプリです。ただし、これも私の状況です。)

(注 3: ターゲット言語はDであり、メタプログラミングに飛び込みたいと思っています。他の言語の回答は大歓迎です!)

(注 4: 実際のコードの場所ではなく、エラーに何らかの記号名を使用することを明示的に望んでいます。これは、コードが実質的に何らかの方法で変更されると、コードの場所が変更されるためです。)

ソフトウェア開発の歴史の中で開発された多くのユーザビリティ評価手法があります。しかし、それらが実際に使用されることはめったにないように思えます。

ユーザビリティ評価のツールや手法が実際にあまり使われていないのはなぜですか。

それとも、私が信じさせられている以上に使われているのでしょうか?

私はどこかで読んだことがあります（ソースを忘れてしまいました、申し訳ありませんが、MS Office開発者のブログだと思いますか？）。多くの場合、彼らはすべての小さなことを望んでいるとは言いませんが、収集されたメトリックは、最終的に、ほとんどの人がこれらの機能の99％を使用しないことを示しています。ブログ投稿からの一般的なメッセージは、人々に何を使用しているかを尋ねるのではなく、自分で追跡する必要があるというものでした。

これは、次に追加する新機能を見つけようとするときに、不幸な鶏が先か卵が先かという状況につながります。この機能がすでに導入されていないと、実際にどれだけ使用されているかを測定できません。有限の（そしてひどく拡張された）リソースがあるので、すべての機能を追加してから未使用の機能を削除する余裕もありません。

ユーザーにとって何が役立つかをどのように見つけますか？調査が唯一の選択肢である場合、特定の方法で質問を構成する必要がありますか（たとえば、可能な機能のリストを表示しないでください。そうすると、質問が先導されるため）。

この質問は、Ed Burns が著書「Riding the Crest」で尋ねたものです。ロックスターのプログラマーのほとんどは、新しいクールなガジェットがあれば役に立つと感じたことを覚えています。プログラマーは、自分の仕事にも影響を与える可能性のある最新の設計、ハードウェア、およびソフトウェアの実装と連絡を取り合っています。

この質問についてどう思いますか。

Adobe AIR のおかげで、Rich Internet Applications (RIA) を作成する境界を、ブラウザーの垣根を越えて押し広げることができました。一部の企業は、Rich Desktop Application (RDA) などのアプリケーションを差別化しています。

Web、デスクトップ、および RIA アプリケーションごとに使いやすさのガイドラインがあります。しかし、Adobe AIR により、Web テクノロジ (HTML、Java スクリプト、AJAX、Flex、AS..) を使用してデスクトップ アプリケーションを作成できるようになったため、このジャンルのアプリケーションは上記のカテゴリのいずれにも当てはまらないようです。

だから私の質問は次のとおりです。AIR アプリケーションはユーザーのデスクトップに存在し、ブラウザ上のアプリケーションとは対照的にデスクトップ アプリケーションを使用する場合、ユーザーは異なるメンタル モデルを持つため、AIR アプリケーションを RIA と区別することは正しいですか?

b. Adobe AIR 用のアプリケーションを作成する際に従う必要があるユーザビリティのガイドラインは何ですか?