it-swarm-ja.com

ユーザーエクスペリエンスとUI JavaScriptコンポーネントライブラリ

恐ろしいユーザーエクスペリエンスでUIコンポーネントライブラリ(PrimeFacesとIceFaces)を使用するアジャイル開発チームに出くわす人…コードを変更してより良いユーザーエクスペリエンスをサポートしない人。ユーザーエクスペリエンスを保護し、UIコンポーネントライブラリが悪いユーザーエクスペリエンスを提供していることを上級管理職に納得させる方法に関する回答を探しています。

2
Ashlie

私はステレオタイプが嫌いですが、まあ、それはこの場合多少妥当です:JSF開発者はプレゼンテーションレイヤーコードもユーザーエクスペリエンスも理解していません。 Web開発ツールとしてのJSFの進化に関係していると思います...ほとんどすべてのフロントエンドコードは開発者の手に負えません。これはすべて、サーバー側のJSFタグを介して自動的に(そして不十分に)生成されます。そのため、JSFはクライアント側のコードをJSF開発者からほとんど隠しているため、優れたUXクライアント側を気にする必要や動機はありません。

PrimeFacesのようなものは役立つことを意図していますが、私見では、実際には役立ちません。

唯一の「解決策」は、JSFがクライアント側のマークアップを停止するようにすることです。そのためには、ソフトウェアのアーキテクチャ全体を変更して、JSONやAJAX=などの機能を活用し、JSFでデータを処理できるようにする必要があります。しかし、フロントエンドの開発者によって処理されるページの実際のレンダリング。

かなりまともなUXを提供する品質の高いUIコンポーネントライブラリがたくさんあるため(jQUery UIを検討する必要があります)、「UIコンポーネントライブラリは悪いユーザーエクスペリエンスを提供する」と一般的に述べることに注意してください。

だから、悲しいかな、それは多くの入力ですが、私があなたに答えがあるかどうかはわかりません...どちらかと言えば、私はまったく同じ質問があると思います!

考慮すべきいくつかの議論:

  • JSFは、Web開発のサーバー側モデルに基づいています。それは時代遅れのコンセプトです。
  • JSFは、クライアント側のコードベースを大量に生成する傾向があります。これはUXに影響します。
  • JSFライブラリーはかなり厳格になる傾向があり、UXチームがお客様のエクスペリエンスを調整する能力を低下させます
  • 非常に多く使用されている最新のクライアント側ライブラリーはたくさんあり、UXと開発哲学の両方ではるかに前向きです。
8
DA01

私の考えでは、これはアジャイル開発プロセスに固有の問題ではありません。この質問は、UXが開発プロセスの一部であることを保証するという問題に関係しています。質問の最初のコメントの1つ 「アジャイル作業環境で開発プロセスのどの時点でUXを使用する必要がありますか?」 、ユーザーAaron McIverは(正しく)「アジャイルは何でもエンドユーザーに価値をもたらします。現在取り組んでいるアジャイルチームがUXを考慮していない場合、それはプロセスではなくチームと関係しています。」

あなた/あなたのUXチームは開発プロセスに適切に関与していないではないようです、プロセスの一部である開発者は協議なしにUIを実装していますUXでは、そのUIは悪いですが、それでも彼らはそれをより良くするための推奨に耳を傾けません。

これは悲しいことに典型的なものであり(ソフトウェア開発方法に関係なく)、私の経験では、解決策はUXバイインで「問題レイヤー」より1レベルか2レベル高いため、チームの全員が責任を明確にできるようにする必要があります。あなたはできる:

  • 引き続き、UIに関する優れたUXベースの推奨事項を提供する
  • 文書化すべて推奨(明らかに)するが、実際に何が行われたかを直ちに文書化し、実装がどのように推奨されていないかを非常に明確に述べる
  • プロジェクトのUX部分が実装部分によって損なわれていることをプロジェクトマネージャーと常に通信します。平均的な方法ではなく、ドキュメントに基づいて定量化できる方法で通信します。
  • UXとDevが製品開発ライフサイクル全体で相互に連携していることを確認する方法を見つけます(自分の場所の階層に応じて、またはマネージャーを通じて)。
  • 優れたUXに関する推奨事項とドキュメントを提供できる最善の仕事を続けます。UXがそこに評価されていない/設定を変更できないことに気付いた場合は、どれだけ激しく戦い続けるかを決定します。

基本的なプロセスの問題があることを人々が理解するまで、私にとっての鍵は常に自分自身を害虫にし、その後I/UXの作業に戻ることです。チームは、「Aは良い。Bは悪い。Aをお勧めします。開発者はBを実装しました。開発者がBを実装し続ける場合、発生する問題は次のとおりです。」結局のところ、経営者は何を使いたいかを決定します。関係者がUXがサポートしていないものを承認した場合、それは残念なことですが、それは彼らが行うことです。

DA01が行った私の回答には、コンポーネントライブラリ自体に対処するためのタックはしていません。それは、より大きな問題がプロセスと管理の1つであると私が見ているためです。開発プロセスにUXが組み込まれていない場合、非UX/UI指向の開発者は、誰かが止めるまで、好きなように/快適に使用できるものをすべて取得して使用します。

2
jcmeloni

はい。 CSSで完全にカスタマイズできる限り、Primefacesをツールキットとして選択した開発チーム(私たち(ユーザビリティチーム)の恵み)に問題がありました。

しかし、Primefacesをカスタマイズするのは非常に難しいため、現在のところ標準に準拠していないか、ユーザーのニーズを満たしていなくても、拒否することができます。

私が理解していないことは、Primefacesとともに他のツールを(JQueryのような)ベースとして簡単に使用して、私たちに必要なことを実行できるということです。

ただし、私の理解では、Primefacesは、カスタムUIをまったく扱いたくない場合に選択するツールキットです。

それは本当の問題です。プライムフェイスと優れたユーザーエクスペリエンス/確実なユーザビリティは、うまく調和していないようです。

(初期状態の)Primefacesはユーザビリティの要件を満たしていないという問題に関する論文を書きます。うまくいけば、彼らはそれを放棄するか、それをベースとして使用して、私たちが必要とすることができないときに、より堅牢なテクノロジーでそれを補足するでしょう。

1
user34510

あなたの痛みが分かります。現在、当社ではJSF 1.2を使用しています。非常に古く、時代遅れであり、残念なことに、私たちがサポートできる最新のアプリケーションフレームワークです。 JSFの欠点を回避するために、私が現在取り組んでいるユーザーエクスペリエンスチームをまとめました。不可知論的なテンプレート/フレームワーク、カスタムJavaScript API、および可能であれば他のテクノロジーを使用するためのガイダンスを作成しました。現在、私たちは「ベータ」段階にありますが、開発グループは可能な限り私たちの標準を採用しています。

ビジネスニーズによっては、同じことができる場合があります。私たちが使用するテクノロジーのいくつかは、開発者に以下を提供します:

  • jQueryおよびjQuery UI
  • Modernizr
  • jQuery DataTableプラグイン
  • jQuery Qtipsプラグイン
  • 多くのカスタム開発プラグイン
  • JSFの構造的欠陥のスタイル設定に役立つカスタムCSS。

次に、私たちが提供するすべての機能とスタイリングがJSF 1.2の上に構築されているという点で、私たちは食べたり、毒を所有したりします。 「アプリケーション」は実際のアプリケーションを必要としないので、フレームワークがやや堅固であることを証明しています。また、スタイルと機能の実装方法を示す構文の強調表示も提供します。ほとんどの場合、開発者はテーブルのような要素にクラスをアタッチする必要があり、クライアント側のデータテーブルプラグインはそれに応じて自動的に機能のスタイルを設定します。

現在、私たちはUXガイドラインへのリンクを提供することはできません。まだそれらに取り組んでおり、一般向けサーバーにまだ昇格していないためです。しかし、それは私たちのバックログにあります。

お役に立てれば!

0
JeffH