タグ付けされた質問 「usability」

3
UIテキストの「自分のもの」と「あなたのもの」
ユーザーのものを参照するときは、たとえばMyまたはYourを使用する必要があります。 マイカート| 私のアカウント| 私のウィッシュリスト または あなたのカート| あなたのアカウント| あなたのウィッシュリスト あなたの使用を主張するこの記事を見つけました。flikrはこれを行うと言っています。また、MySpaceとMyYahooは間違っていると言っています。 また、アマゾンがあなたの用語を使用していることに今日気づきました。しかし、彼らはバリエーションをテストし、最適なものを見つけることの達人であると聞いたので、彼らのサイトで見たものは最高のバリエーション、または単に彼らが現在テストしているものかもしれません。 個人的には自分の見た目が良いのが好きですが、それは私の意見です。 どう思いますか?顧客へのより良い影響は何でしょうか?それは本当に重要ですか?

4
バグが5年以上前の場合、それは機能ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 詳細の追加を許可します:私は多くのコーダー、テスター、QAアナリスト、製品所有者などがいる施設で働いています。 私たちは、10年以上にわたって、くだらない(かなり機能的ではあるが)ソフトウェアを販売することができました。多くの機能があり、製品は競争力がありますが、そこには深刻なバグがあり、何千もの「ペーパーカット」があります-クライアントが慣れるのに少し面倒です。 コンピューターが私たちの生活を楽にするのに役立たないなら、私たちはそれらを使うべきではないと固く信じているからです。私は同僚に自信を持っています。彼らは賢く、能力があり、それを行うことに焦点が当てられているときに物事を改善することができます。 しかし、古い機能を閉じたり忘れたりすることなくバグを報告することは困難です。「昔のように機能しました」が典型的な答えです。また、QAがリグレッションを行うとき、彼らは、正しくないように見えるものと同じくらい異なるものを探す傾向があります。したがって、古い問題の修正はバグとして書き出すことができます。なぜなら、「それは私の時間よりも前からそうでした」からです。 私の若いコーダーは考えています:このおかしなことを書き直してください!営業に近い機会があったクライアントとして、私はこのアプローチに疑問の余地を与えたいと思います。 あなたの意見/経験にも興味があります。リスク、費用対効果、およびその他の非技術的要因を考慮してみてください。


3
プログラミング言語の構文は、ユーザビリティテストされていますか?
この投稿を改善したいですか?引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細がない回答は、編集または削除できます。 一般に公開される前に、プログラミング言語の構文はユーザビリティテストを受けていますか?もしそうなら、どのような種類のテストが実行され、結果は何で、テスト結果は言語の設計にどのような影響を与えましたか?

7
パフォーマンスの問題と見なされるまでに画面が表示されるまでにどれくらい時間がかかりますか?
さまざまな画面を持つWindowsアプリケーションの開発に携わっています。そのうちの1つは、画面がロードされていることを示すスピナーやその他の表示なしで表示されるのに10秒かかります。私はこれを深刻なパフォーマンスの問題だと考えていますが、心配しているのは私だけだと思われます。 私は熱心ですか?画面が表示されるのを待つ許容時間はどれくらいですか?

3
大画面の不動産の設計の課題をどのように克服しますか?[閉まっている]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか?質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 この質問はもう少し主観的ですが、私はいくつかの新しい視点を得ることを望んでいます。私は特定の画面サイズ(通常は1024x768)の設計に慣れているので、そのサイズは問題にはなりません。サイズを1280x1024に拡大しても、かなりの違いを生み出すのに十分な画面領域は購入できませんが、少し余裕ができます。基本的には、「グリッドサイズ」を拡張するだけで、わずかに小さい画面でも同じ基本設計が機能します。 ただし、最後の2つのプロジェクトでは、私のクライアントはすべて1080p(1920x1080)画面を使用しており、可能な限り多くの不動産を使用するソリューションを求めていました。幅1920ピクセルの幅は、私が慣れている幅の2倍をわずかに下回っています。ワイドスクリーンを使用すると、昔の設計の一部がうまく機能しなくなります。私が遭遇している問題は、非常に多くのスペースが提示されると、いくつかの大きな問題に直面することです。 いくつの列を使用する必要がありますか?ワイドフォーマットは、2:1:1の分割(つまり、コンテンツ列が他の2つよりも大きい)での3列の分割に適しています。ただし、3つの列を使用する場合、その追加の列はどうすればよいですか? 画面の領域を効率的に使用するにはどうすればよいですか?すべてを一度に画面に表示したいという誘惑はありますが、情報が多すぎると、実際にはアプリケーションが使いにくくなります。空白は、複雑な情報を理解するために重要ですが、多すぎると、関連する概念の分離が強すぎます。 私は通常、複雑なデータを持つWebアプリケーションを使用しています。生データを理解するには、視覚化とプレゼンテーションが重要です。ユーザーも大画面(少なくとも24インチ)を使用している場合、一部の情報は視界の外にあり、ポインターを遠くに移動する必要があります。必要なものすべてを視覚的なホットポイント内に確実に収めるにはどうすればよいですか? ブログのような単純なサイトは、幅が制限されていると実際にパフォーマンスが向上し、その結果、多くの無駄な不動産が発生します。テキストボックスとテキストプレビューを並べて表示することは、そのタイプの画面の管理者側にとって大きなメリットになるのでしょうか。(1:1 2列分割)。 あなたの答えとして、私はデザインのほとんどすべてが「依存する」ことを知っています。私が探しているのは: 使用する一般原則 デザインへのアプローチがどのように変わったか この異なる形式での作業方法を自分で再訓練する必要があることがわかりました。私がこれまで取り組んできた解像度のすべてのバンプは、約25%です。640〜800(25%増加)、800〜1024(28%増加)、1024〜1280(25%増加)。ただし、1280から1920へのジャンプは、スペースの50%の増加に相当します。640から1024へのジャンプに相当します。レッスンを徐々に学習するために一般的に使用される中間サイズはありませんでした。
10 design  gui  usability 

7
スケッチUIを使用しないようにユーザーを説得するにはどうすればよいですか?
私は最近、Sketchflowを使用して新しいシステムのプロトタイプを作成しましたが、現在、いくつかの主要な利害関係者が最終製品のスケッチされたルックアンドフィールを求めています。さらに悪いことに、プロトタイプを表示している人々は、かなり主導的な調査の質問を通じて、スケッチされたルックアンドフィールに関するフィードバックを提供するように求められ、回答の80%が肯定的でした。 これは主に内部クライアント向けのエンタープライズアプリケーション用ですが、一部の外部クライアントによる使用も意図されています。 それが悪い考えだと私が考えている主な理由は次のとおりです。 洗練されていたりプロのようには見えません 実際のアプリケーションをスケッチスタイルでスキニングするための多大な労力 スケッチスタイルでは、画面の不動産を効率的に使用できません。 私はアピールが何であるかを理解しようと努めてきました、そして私が思いつくことができる唯一のことは人々がそれのシンプルさに魅了されていることです-特にそれが置き換えられる既存のシステムと比較したとき。 スケッチのルックアンドフィールを使用することが悪い考えであるという証拠の方向に誰かが私を向けることができますか?理想的には、UIの調査に基づくものです。具体的なことを言えない限り、自分の声が聞こえないのではないかと心配です。 [編集] アプリケーションのスキニングの難しさは、Sharepointサイトで1つ以上のSilverlight Webパーツとして配信されることを意図しているという事実によってさらに悪化することをおそらく付け加えておきます。両方のテクノロジーで一貫したスケッチのルックアンドフィールを取得することは、非常に難しい場合があります。 [編集] だれでも、Sketchflowプロトタイプがどのように見えるか(したがって、関係者が何を求めているか)がわからない場合に備えて、本質的には本番アプリケーションに鉛筆スケッチワイヤーフレームのルックアンドフィールを要求しています。

1
複数のAPI、または「chooser」パラメーターを持つ1つのAPI?
データソースの上にビジネスロジックを追加するWebサービスがあるとします。このサービスの各APIはほとんどのように見えます-一連の制約が与えられた場合、これらの制約を満たすデータソースからのアイテムを提供します。APIからデータソースの「ビュー」を取得したと言えます。 ここで、時間の経過とともに、データソースに対してさまざまな種類のビューを返すように求められます。「十分に異なる」ビューごとに新しいAPIを追加するか、ギアを切り替えて、目的のビューの種類を指定するパラメーターを取得するgetFooDataView()APIを提供するオプションがあります。どちらの方法に行くかを決定するために、いくつかの競争圧力があります。 あなたのサービスの既存の大きなクライアントは怠惰であることを好み、データの新しいビューが必要なときに新しいAPIまでコーディングする必要はありません。 ただし、一部のリクエストパラメータ(制約)は一部のビューでのみ意味があり、他のビューでは意味がありません。「XYZビューが必要な場合は、 "foo"パラメータを設定すると、APIコントラクトを緩くする必要があります。一部のビューではそうであるとしても、 "foo"を必須パラメーターにすることができないという残念な副作用があります。 新しいクライアントがサービスを活用したいというケースはますます増えています。どちらがより混乱するかを決定することはできません-異なるがより厳密に定義されたAPIと、パラメーターのどの組み合わせが本当に必要なものを提供するかを知る必要がある1つのAPIを選択する必要があります。 これを抽出するために、既存のAPIのバリエーションとは対照的に、何かが独自のAPIである必要があるという線を描くのはいつですか?2人のクライアントの要求を意味的に区別する理由については、協力しなければならない人によって見方が異なるため、この問題についてコンセンサスを得るのは難しい場合があります。また、将来のクライアントがサービスを利用するのが極端に難しくならないようにする必要もあります。この種の選択を行うためのいくつかのベストプラクティスは何ですか?

1
ユーザビリティテストをどのように整理しますか?
あなたのプロセスは何ですか? どのようにフィードバックを受け取りますか? どのソフトウェアを使用していますか?(のようなもらえのTechSmithから) 彼らは誰ですか? ソフトウェアの品質にどのように良い影響を与えたかを測定しましたか? この件に関するあなたの経験を探しています。これは私が改善したいものです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.