パフォーマンスを向上させるために、ユーザーが頻繁に使用していない機能を削除する必要がありますか？
アプリ（広告サーバー）用に生成したヒートマップによると、ユーザーはリスト内のアイテムを並べ替えることはほとんどなく、通常は検索を使用して探したいアイテムを見つけます。開発者は、並べ替え機能を削除すると、アプリのパフォーマンスが大幅に向上すると述べています。
長いリストのデータを並べ替えることができるのがベストプラクティスであるため、この変更については非常に懐疑的です（リストは100項目に達する可能性があります）同時に、アプリのパフォーマンス（読み込み時間）は非常に重要です会社。
助言がありますか？
注意事項：
これらの質問をありがとうkettch：
ユーザーは列がソート可能であることを知っていますか？ -はい、ユーザーテストでは、ほとんどすべてのユーザーが並べ替え可能なヘッダーに気付きました
データセットの平均サイズはどれくらいですか？ -通常、ページあたり50行が表示されますが、現在のところ、標準のキャンペーンマネージャー（私たちのターゲット）は、ページあたり4〜5個のアイテムしか必要としません。
この機能を使用して並べ替えを行うユーザーはなぜですか？ -明確な答えはありませんが、ペースやクリック率で並べ替えて、成果の低いキャンペーンを見つけようとしていると思います
データグリッドは非常に遅いので、ユーザーは決して使用しませんか？ -いいえ、実際には高速ですが、どうやら-ソート機能がデータベースに問題を引き起こし、データに矛盾を生じています。
問題に関する開発者のメモ：
- ユーザーの5％未満が実際にこれを使用してソートしている場合に、データを更新するために必要な呼び出しの量のため、postgresqlでデータを取得する問題。
- 今のように永遠に拡張されない
また、私たちが計画している方法でこれを行うことで獲得できるものは次のとおりです。
- リアルタイム。本当に、リアルタイム。ページを更新するたびに、最新のパフォーマンスが表示されます（2分後などではありません）。
- リストだけでなく、製品全体のパフォーマンスが向上します。一部のアプリで「フリーズ」を減らす
- コストの最適化。2分ごとにデータを計算する必要がないためです。ただし、実際にデータを確認することはできません（夜間など）。必要なときだけ計算します
ここの他の良い答えで言われたことのほかに、あなたははるかに基本的な問題を抱えています。あなたはあなたのデータを読み違えています。
ヒートマップは一般に、誰が作成したかに関係なく、ピクセルのすべてのクリックを合計します。そして、あなた（と他の答え）はこのヒートマップをそのピクセルをクリックしたユーザーの割合と解釈しているようです。これはまったく別のお茶です。
あなたがオンラインショップを持っていると想像してください。標準のヒートマップでは、ブラウジング、コメントの閲覧などに関連する機能の大量のクリックが表示され、「チェックアウト」ボタンのクリックはごくわずかです。これは、誰もそのボタンを使用しないことを意味するのではなく、訪問中に他の多くのものをクリックして、注文を1回だけ行うことを意味します。そして、これはまさにあなたが彼らに行動させたい方法です！あなたのケースでは、すべてのユーザーが並べ替えを使用している可能性がありますが、訪問ごとに1回だけ実行する必要があります。それでも、ユーザーのタスクに非常に役立つと見なします。 （私はこれが起こっているにちがいないというわけではありません-しかし、あなたのデータでは、それを除外することはできません）。
必要な情報を取得するには、完全に異なる情報表示を生成する必要があります。これは、クリックをそれらを行ったユーザーに関連付け、特定の要素のクリックをユーザーごとに1回だけカウントします。これにより、関数を使用していないユーザーの数がわかります。
その情報を取得したら、少数の訪問者が使用する機能を削除するかどうかを検討することができます。 （Webショップでチェックアウトしたユーザーの10％だけであることがわかった場合、[チェックアウト]ボタンを削除しますか？）
パフォーマンスは重要ですが、目標を達成することはさらに重要です。
ソート機能を利用しているユーザーの種類を検討してください。たとえば、これらのユーザーは、少数ではありますが、サポートしたいユーザーである可能性があるためです。
A/Bテスト ソートの削除が目標にどのように影響するかを確認することをお勧めします。検索機能を向上させながら、ソートを維持したい場合があります。
ユーザーは列がソート可能であることを知っていますか？
最初の列にソートインジケーターが表示されているように見えても、ユーザーが見出しをクリックできることに気付かない可能性があるためです。
データセットの平均サイズは？
検索の結果、必要なすべての情報が1つのデータ画面に表示された場合、並べ替える傾向がないかもしれません。
機能を使用してするユーザーがいるソートするのはなぜですか？
これは ソート 一種の前の質問に関連しています。すべてのユーザーが検索を好むわけではありません。私は、ユーザーがデフォルトのデータを取り、「n」スクロールで幸福になる方法を見ているのを見てきました。
ユーザーがデータグリッドを使用しないほどデータグリッドが非常に遅くなりますか？
パフォーマンスの問題のために、ユーザーがソートを好まない可能性はありますか？ UXに手を出す開発者として、パフォーマンスを障壁として買うかどうかはわかりません。アプリケーションが並べ替えのたびに巨大な集計を実行しない限り、データを集計してから結果を並べ替えることができない理由はありません。定期的に集計を事前に計算することもできます。ソートの存在そのものが問題になることはありません。
これは、開発の側面に位置するため、少しずれたトピックになる可能性があります。フルスタックの開発者として、検索機能はパフォーマンスを集中的に使用する可能性があると言えます。これはすべて、何を検索するか、どれだけ検索するか、最初に行うフィルタリングの量などによって異なります。開発者に初期検索機能を再評価して、どこで改善できるかを確認してもらいます。通常、常に改善の余地があります。
おそらく開発者から寄せられたこのコメントは、物事が正しく行われている場合は正確ではありません。 「データベースに問題を引き起こし、データに矛盾を生じさせるソート機能」このコメントだけでも、私はそれらにうんざりするでしょう。私にとってこれは怠惰で物事を改善したくないという警戒心です。
それらがページにとって重要である場合は、検索オプションが開始するのにあまり役立たないため、オプションを削除しません。フィルターは3つしかありませんが、これはパフォーマンスに大きな影響を与えるものではありません。
また、フィルターの配置がその使用に影響を及ぼしているため、これを変更すると異なる結果が得られる場合があります。ユーザーが目的を達成し、必要に応じて調整するには、どのフィルターが最も重要であるかを検討できます。
いくつかの良い考えはすでに共有されているので、私が見なかったものを1つだけ追加します。機能の使用に関する定量的なデータは重要ですが、ユーザーがソートしているかどうかはわかりませんwhy。デザイナーがソート関数で何らかの認識された値を想定しているように聞こえるので、それらの想定がユーザーの考えと一致するかどうか（数値を超えて）を理解することは、次の有益な情報になる可能性があります。
機能の削除については常に非常に慎重である必要があります。ほとんどの企業は、なぜ顧客が競合他社よりも自社製品を選ぶのかについて十分に理解していません。あなたが誤ってキラー機能を削除し、自分を廃業させる可能性は常にあります。機能を削除するには、ビジネス上十分な理由が必要です。あなたの質問から、あなたが実際に機能を削除する理由があるとは思えませんbusiness理由。つまり、簡単に言えば、削除しないでください。
次に、パフォーマンスが重要な場合本当に顧客の場合と同様に、製品が遅すぎるために不平を言い、競合他社に向かいます...アプリの一部を切り離して、パフォーマンスを修正することを検討できます。これは、長所と短所、および計算して検討する必要がある予想される結果を伴う実際のビジネス上の決定です。その場合、顧客を失ったために実際に失っている金額と、問題を修正するのにどれだけの費用がかかるか、どれだけの金額が必要か、機能Xを削除するために機能Xを削除した場合に失うと予想される顧客の数を考慮する必要があります。そう。
しかし、これはビジネスの決定であり、あなたのビジネスと顧客に関する特定の情報をたくさん（つまりたくさん）必要とします。基本的に、お答えできる可能性は低いです。
プラスの面では、あなたの質問から、この並べ替え機能を削除するためのNO REASON WHATSOEVERがあるようです。
また、私たちが計画している方法でこれを行うことで獲得できるものは次のとおりです。
Realtime. Like, really real-time. Every time you refresh the page you would see the latest performance (and not 2 minutes after or whatever) Better performance not only for the list, but for the whole product.Less "freeze" in part of the apps Cost optimisation, because we wouldn't need to compute it every 2 minutes, altough no one would actually see the data (during night or whatever). We would compute it only when necessary
それは、ソートとは何の関係もありません。特に、「2分後ではなく、2分ごとに計算する必要がないため」と述べたいと思います。これは、DBアーキテクチャにmajorの問題があることを強く示唆しています。最初に、never計算値をDBに保存する必要があります。これは、データの一貫性が悪夢になるためです。 「どうやら、並べ替え機能がデータベースに問題を引き起こし、データに矛盾を生じさせる」とも言及したので、実際にデータの矛盾を引き起こしているのは、生成/計算された値がDB。
しかし、実際にはそれよりもはるかに悪いです。これは、ソートによってバックエンドデータの不整合が発生する[〜＃〜] possible [〜＃〜]であってはならないためです。ソートは、通常は読み取り専用であるselectステートメントの一部として行われます。検索結果をどのように並べ替えても、結果を取得したテーブルは変わりません。
並べ替え機能を削除すると、実行中のキャンペーンでユーザーが見つけにくくなるようです。これは、主要なアクションではないにしても、重要なアクションのように聞こえるので、ソートをサポートする必要があります。
私の意見では、パフォーマンスの向上は、ユーザーにとっての問題ほど大きくはありません。 0.1の読み込みは遅くなりますが、パフォーマンスの低い/高いキャンペーンをすばやく見つけることができるようになります。
また、パフォーマンスは、使いやすさに直接影響しないさまざまな方法で改善できます。しかし、これはまったく別の分野です。
私にとって、既存の機能を削除または再設計することを決定する際の重要な質問は簡単です。使いやすさの正味の利益は何ですか？一般的な経験則では、（ドメインで重要なメトリックによって）少なくとも20％の増加が見られない場合は、おそらくそれを行うべきではありません。 20％の数値は重要ではありません。重要なのは、アプリが使用可能であることの意味を考え、この定義に対する現在のユーザーパフォーマンスを測定し、提案された変更の影響を測定し、利益が変化する。
あなたがフレームに入れたときの変更のように聞こえるのは、ユーザーよりも開発者に利益をもたらすことです。 UXの専門家として、私は歯と爪を戦いますに対してそれ。ユーザーの5％だけがこの並べ替えを使用している場合でも、他のユーザーがアプリを使いにくくすることはありません。しかし、直接的な結果（怒りのソーシャルメディアやアプリのレビュー、顧客/収益の損失の可能性、サポートコストの増加など）によって、その5％のユーザビリティに深刻な悪影響を及ぼし、何が原因になるのでしょうか。
インターフェイスの仕事はユーザーの問題を解決することであり、開発者の仕事を簡単にするものではありません。
インターフェースはそのままにしますが、開発者にソート処理をクライアント側に移すよう依頼します。
これにより、データベースの負担が軽減され、並べ替えを行わない人のためにアプリが高速で実行されます。
機能の削除を検討する前に（作成にリソースが必要でした）、次のことを考慮してください。
誰が使用しますか？アプリケーションによっては、パワーユーザーのみが使用する機能であり、パワーユーザーを機能から切り離すことは悪いことです。私の経験では（これは他の多くの開発者にも当てはまると確信しています）、パワーユーザーは、製品について最も建設的なフィードバックを提供するユーザーです。パワーユーザーは長続きするユーザーです。彼らはあなたのアプリをチェックアウトして次のアプリに移るだけではありません。これらは、ユーザーベースをオーバーフローさせたい顧客です。ユーザーがアプリに満足していない場合、ユーザーがパワーユーザーになる可能性はなくなります。
これは意図せずに隠された機能ですか？おそらく、現在使用されているアプリのUIのデザインでは、ソートが可能であることをユーザーに実際に示していないため、ほとんどのユーザーはそれについて本当に知らないため、使用していません。この方向で何かを行うと、良い結果が得られるか、少なくともこの機能の使用に関するより具体的な評価が得られます。アプリケーションに何らかのソートのチュートリアルがあるか、少なくとも何が何であるかについての有用な情報を含むオーバーレイがある場合は、ソートに関する情報を（すでに存在する場合はさらに）見える場所に追加してみてください。多くのユーザーが（私にとって）明白なことを見逃していることに驚かされることがよくあります。優れたユーザーインタラクションは、ユーザーに最も速くシームレスな方法でユーザーに製品を使用する方法を教えることから始まります。特定の機能が見つからない場合、実際にユーザーがアプリをダンプして競合他社に行く可能性があります。
開発面について（私はソフトウェアエンジニアなので）：
このデータを更新するために必要な呼び出し量が多いため、postgresqlでデータを取得する際に問題が発生します。これは、ユーザーの5％未満が実際にこれを使用してソートしている場合に、データをソートできるようにするためです。
あまり使用されないものの、定期的に発生するオーバーヘッドが発生する場合は、呼び出しの動作に問題があります。ユーザーの5％がこの5％でのみ機能を使用する場合、オーバーヘッドが発生するはずです。
今のように永遠に拡張されない
ここに複数のオプション：サブセットに並べ替えを適用し、結果をマージ（->並べ替えのマージソート）、事前に並べ替えられたビューを作成（データが変化しない場合、ユーザーに非常に高速な並べ替えリストを提供できるため、すでにサーバーで実行されています）、ソートできるデータの量に上限を設定します（たとえば、1000エントリ後にソートするとオーバーヘッドの制限が多すぎて1000エントリのみにソートされることが判明した場合->ユーザーが選択したサブセットのみをソートすることもオプションです）など。
リアルタイム。本当に、リアルタイム。ページを更新するたびに、最新のパフォーマンスが表示されます（2分後などではありません）。
リアルタイムとは何かについて、私たちは異なる理解を持っていると思います。データのリアルタイム表示（ユーザーがWebページを介して表示できる）を実際に持っている場合、これはページを非常に最小限の待ち時間で常に更新する必要があることを意味します。この場合、並べ替えはあなたの問題の最小です（誰もがすぐに利用可能な（そして高価な！）帯域幅を吸収するモバイルアプリを使用するのが好きです...）。繰り返しになりますが、ここで説明しているのは、アーキテクチャー（ここでは主にバックエンド）の実装の問題や一般的な設計の問題のようであり、その後、ソート機能に関連するものです。
リストだけでなく、製品全体のパフォーマンスが向上します。一部のアプリでは「フリーズ」が少なくなります
上記の引用を参照してください。
コストの最適化。2分ごとに計算する必要がないため、実際には誰も（夜間など）データを見ることができません。必要なときだけ計算します
これは、アプリケーションとそれが処理するシナリオに完全に依存するものです。何も知らないため、フィードバックを提供できません。
奇妙なことに私を驚かすのは、あなたのリストが100アイテムまで達することができるとあなたが言っているという事実です。少しお話ししましょう。リストの100項目は、アプリであってもそれほど多くありません。 100アイテムのリストを並べ替える場合、開発者は適切な仕事をしなかったと思います（各アイテムにメガバイトのデータが含まれていないと思いますが、そうであれば、モバイルアプリでもこのようなデータは何ですか？）このような大きな問題を提起します。あなたが使用しているテクノロジー（JS + HTML、Qt、Javaなど））は何も知りませんが、膨大な数のアイテムを処理するために最適化された、すぐに使えるリストコンポーネントがたくさんあります。おそらくあなたの開発者は仕事のために間違ったツールを選びましたか？
1つは、並べ替えはユーザーが当たり前のことと考える機能です。そのため、ソート機能がどれほど優れているかをユーザーが教えてくれることはありません-彼らはwillを教えてくれて、その機能がなくなったら非常に不満です。
2つ目は、開発者が一部の機能を削除するとアプリケーションがより効率的になると主張する場合は、非常に慎重になるでしょう。 （そして私はAppleのアプリストアにあるアプリケーションを持っていますが、iPhone 4でさまざまな方法で約10,000アイテムをソートすることはまったく問題ありません。これは、最新のデバイスよりも約10倍遅いため、ソートが遅い場合は、これらの人にWTFをやってもらいます彼らのアプリケーションダウン）。
すでに良い答えですが、2セント追加することに抵抗することはできません。
問題は、機能を使用しているユーザーの割合が、機能の重要性または値の正確なメトリックではないことです。
この質問はソフトウェア開発にとって新しいものではありません。私はすべての企業が何らかのレベルでこの種の決定に直面していると思います。たとえば、以前のキャリアでは自転車屋を経営していました。奇妙な自転車や機器で顧客をサポートできるようにするには、自分自身で支払うだけの十分な収入が得られない可能性が高いツールや機器を購入する必要がしばしばあります。それで、おそらくそれ自体は決してお金を払わないであろう高価なツールがあるとしましょう、少なくとも最初の順列での投資収益率はひどいです。買うべき？
答えは「状況次第」です。自転車屋で直面した問題は、十分に広い顧客基盤をサポートしていなかった場合、設備の整った別の場所に行き、別の自転車屋との関係があればそこに行く可能性が高いということでした。簡単で高い投資収益率でも。常にお客様の問題を解決できれば、最初に問題が発生する可能性があります。彼らはまたあなたを友人に推薦する可能性が高いです。
ソフトウェア機能の投資収益率を決定するときも、同様の考え方が当てはまります。
- 潜在的なユーザーがあなたのツールを評価しているとき、彼らは機能リストを比較しているかもしれません、たとえ彼らが特定の機能を決して使用しなかったとしても、彼らがそれを必要とするならそれがそこにあると知って安心できるかもしれません。
- 会社があなたのツールの使用を評価しているとしましょう。ユーザーの99％は機能Xを必要としませんが、1人は必要であり、それなしでは生活できません。彼らは機能Xを提供するツールを選択しますが、Xを使用するユーザー数の統計は、それが重要でない機能であることを示しているように見える場合があります。
機能を使用しているユーザーの割合が、そのような決定を行うには不十分なメトリックであるという他の例を思いつくのは簡単です。代わりに自分自身に問いかけてくださいユーザーとビジネスモデルにとって、機能はどれほど重要ですか？これは難しい質問であり、おそらくドメインとユーザーに対する何らかの視点が必要です。
これを削除することに注意してください。並べ替えは重要な機能であるため、今後はより洗練された検索条件で使用できます。並べ替えは、削除するのではなく、ユーザーが必要とするフィルター条件を取得しないように、より詳細にしてください。
私はそれがあなたがすべきかすべきでないほど単純ではないと思います。パフォーマンスの問題は認識されていますか、それとも実際ですか？大量の結果を生成する検索語句に長いページ読み込み時間が表示されていますか？ Xの結果によって負荷が増加し、Xミリ秒ずつソートされる特定のトリップポイントがある場合は、ページに返される結果の数を減らすことができます。
第二に、利用可能な他のオプションがあります。ページが期待どおりに機能するかどうかに関する主要な指標としてユーザーを考慮しないため、開発者がオールオアナッシングフィックスを適用することは珍しいことではありません。
最初の段落で示したように問題が存在する場合、データのロード方法またはデータがキャッシュに保持される方法を改善することで効率を上げることができますか？データ接続をより効率的にできますか？
これまでのところ、システムに特定の欠陥がない限り、ユーザーに影響を与えることをまだ提案していないパターンに気づくでしょう。
読み込み時間に問題があり、読み込み時間をバックエンドで改善できない場合、ユーザーが好みの並べ替えを無効にできるようにして、読み込み時間を短縮し、甘味料としてのパフォーマンスを向上させて、ユーザーに有効にできることを通知できますいつでも並べ替えますか？
あなたの声明からの私の主な結論は、ソートはすべての人々がそれを利用するのに十分直感的ではないということです。特に結果が出るのを待つときは、検索に時間がかかり、時間がかかります。私の提案は、並べ替えをオプションとして削除するのではなく、ユーザーが喜んで従事するシステムとスタイルにさらに発展させることであり、明確な目標は、フィルター/並べ替え機能に関してヒートマップを改善することです。
問題：私はこの問題のあるチームに参加しています。基本的に、バックエンドのパフォーマンスが要求された機能に追いつきませんでした。経営陣はソートなどの機能を要求し、開発チームの誰かが「簡単に追加できます」と言っており、マークされた実際のデータさえベンチマークしていない可能性があります。テストサーバーはバックエンドで1000行のテストデータを持つことができますが、ライブユーザーは数百万になる可能性があるため、誰かが1日に数回ソートするためにそのボタンをクリックすると、開発者はサーバーを見て怖がる可能性があります。 。
解決策：最初に、実際のパフォーマンスの不満を見たり受け取ったりしているのでしょうか、それとも開発者は将来を調べて怒鳴っていますか？製品が現在混乱状態にあるか、または混乱しそうな場合は、必ず並べ替えを削除し、並べ替えを行うユーザーと話し合い、解決策が見つかるまで開発者に話しかけてください。並べ替えによって製品に深刻な害が及ぶまでに数か月または数年のような時間があれば、開発者に修正を依頼し、インデックスを追加して、役立つ種類のデータベースを見つけてもらうのが最善の方法です。私はそこに行って、ユーザーが並べ替えを数秒間30秒間待機できるようにしましたが、最終的にはデータを新しいデータベースタイプ「elasticsearch」に複製し、高速かつ即時の検索/並べ替え/カウントを可能にしました。
良い答えがたくさんあります。
どれも適切ではない場合、別のアプローチはどうですか：
現在のバージョンの名前を変更します。現在のバージョンの代わりに、並べ替えがないバージョンを置きますが、「並べ替えを有効にする」ボタンがあります。彼らがクリックすると古い高価なバージョンに行き、そうでなければ新しい安価なバージョンを使います。
この機能を削除してはならないことに同意します。私はこれを以前に見たことがありますが、誰かが機能を使用していないと思っているマネージャーが機能を削除しています。ユーザーが不満を言い始めたので、機能が復活しましたが、いくつかの新しいバグにより、コーダーが他の機能を変更したため、これらの「誰も使用しない」機能が省略されています。
ヒートマップは非常に限られています。私はいつもランダムに何かをクリックし、半分の時間は実りがありません。機能の使用法by userを確認することをお勧めします。つまり、次のようになります。どのユーザーがソートを使用しますか？そしてさらに良い調査はwhy彼らはソートを使用しますか？
アマゾンでソートしてください。それはごみの火です。人々検索であり、検索結果はすべて籾殻なので、小麦を籾殻から分離するためにsortを試みます。 そして、うまくいきません、もみが多いので！そして、それはAmazonが真剣に検討すべきものです。フィルタリング、階層化ソートなど。
ですから、より良い質問は人々がソートしたとき、彼らは本当に何をしたいのですか？そして、どのようにしてより適切に提供できるかそれ？
私は完全に同意します、あなたはそのデータベース側をするべきではありません。データベースエンジンは貴重なリソースです。プログラマーは、コーディングが簡単だからといって、データベースに重いジョブを投げるべきではありません。
さらに良いことに、ユーザーのPC /デバイスで要求に応じてソートを実行します。これはネットワークトランザクション時間を節約します。古典的な設計の失敗は、オフィスのギガビットイーサネットでテストすることですが、ユーザーはiPad 2Gをエッジセルラーにフォールバックし、11％のパケット損失があります。したがって、ネットワークアクティビティはユーザビリティにとって非常に重要です。使用状況レポートのために電話をかける場合は、クリティカルパスではなくバックグラウンドアクションにします。