Faut-il supprimer les fonctionnalités que les utilisateurs n'utilisent pas fréquemment pour améliorer les performances?
Selon la carte thermique que nous avons générée pour notre application (un serveur de publicité), les utilisateurs trient rarement les éléments dans les listes, ils utilisent généralement la recherche pour trouver les éléments qu'ils voulaient trouver. Les développeurs ont déclaré que cela améliorerait considérablement les performances de l'application si nous supprimions la fonction de tri.
Je suis très sceptique à propos de ce changement car il est préférable de pouvoir trier les données dans les longues listes (nos listes peuvent atteindre 100 éléments) mais en même temps, les performances (temps de chargement) de l'application sont très importantes pour l'entreprise.
Aucune suggestion?
Remarques:
Merci à Kettch pour ces questions:
Vos utilisateurs savent-ils que les colonnes sont triables? - Oui dans les tests utilisateur, presque tous les utilisateurs ont remarqué l'en-tête triable
Quelle est la taille moyenne de l'ensemble de données? - Habituellement, vous obtenez 50 lignes par page, mais un gestionnaire de campagne standard (nos cibles) n'a besoin que de 4 à 5 éléments par page pour l'instant
Pourquoi les utilisateurs qui trient utilisent-ils la fonctionnalité? - Je n'ai pas de réponse claire à cela, je dirais qu'ils essaient de trouver des campagnes sous-performantes en les triant par rythme ou CTR
La grille de données est-elle si douloureusement lente que les utilisateurs ne l'utilisent jamais? - Non, c'est rapide en fait, mais - apparemment - la fonction de tri cause des problèmes dans la base de données et crée des écarts dans les données
Notes du développeur pour le problème:
- Problème d'obtention des données dans postgresql en raison de la quantité d'appels nécessaires pour mettre à jour ces données, juste pour que nous puissions les trier, si moins de 5% de nos utilisateurs l'utilisent réellement pour trier.
- N'évolue pas pour toujours comme il est maintenant
Aussi ce que nous gagnerions en procédant comme nous le prévoyons:
- Temps réel. Comme, vraiment en temps réel. Chaque fois que vous actualisez la page, vous voyez les dernières performances (et non 2 minutes après ou autre)
- De meilleures performances non seulement pour la liste, mais pour l'ensemble du produit. Moins de "gel" dans une partie des applications
- Optimisation des coûts, car nous n'aurions pas besoin de le calculer toutes les 2 minutes, bien que personne ne verrait réellement les données (pendant la nuit ou autre). Nous ne le calculerions que si nécessaire
Outre ce qui a été dit dans les autres bonnes réponses ici, vous avez un problème beaucoup plus fondamental. Vous lisez mal vos données.
Une carte thermique résume généralement tous les clics sur un pixel, peu importe qui les a créés. Et vous (et les autres réponses) semblez interpréter cette carte thermique comme la proportion d'utilisateurs qui cliquent sur ce pixel, ce qui est une tasse de thé entièrement différente.
Imaginez que vous ayez une boutique en ligne. Une carte thermique standard affichera une tonne de clics sur les fonctionnalités liées à la navigation, à la consultation des commentaires, etc., et seulement très peu de clics sur le bouton "Commander". Cela ne signifie pas que personne n'utilise ce bouton, cela signifie que les gens cliquent sur une tonne d'autres choses pendant une visite, puis ne passent la commande qu'une seule fois. Et c'est exactement comme ça que vous voulez qu'ils agissent! Dans votre cas, il est tout à fait possible que chacun de vos utilisateurs utilise le tri, mais n'a besoin de le faire qu'une fois par visite - et le considère toujours comme extrêmement utile pour sa tâche. (Je ne dis pas que cela doit être ce qui se passe - mais avec vos données, vous ne pouvez pas l'exclure).
Pour obtenir les informations que vous souhaitez, vous devez générer un affichage d'informations complètement différent, qui relie les clics à l'utilisateur qui les a créés et ne compte un clic sur un élément donné qu'une fois par utilisateur. Cela vous indiquera combien de vos utilisateurs n'utilisent pas la fonction.
Une fois que vous avez obtenu ces informations, vous pouvez commencer à considérer si une fonction utilisée par quelques visiteurs doit être supprimée ou non. (Si vous découvrez que seulement 10% des utilisateurs finissent par commander dans votre boutique en ligne, supprimeriez-vous le bouton "Commander"?)
Les performances sont importantes, mais encore plus que vos objectifs sont atteints.
Considérez quel type d'utilisateurs utilise la fonction de tri . Parce que, par exemple, il peut arriver que ces utilisateurs, bien que peu nombreux, soient ceux que vous souhaitez soutenir.
Je suggérerais test A/B pour voir comment la suppression du tri affecte vos objectifs. Vous découvrirez peut-être que vous souhaitez améliorer la fonctionnalité de recherche tout en conservant le tri.
Vos utilisateurs savent-ils que les colonnes sont triables?
Je pose cette question, car même s'il semble y avoir un indicateur de tri dans la première colonne, les utilisateurs peuvent ne pas se rendre compte qu'ils peuvent cliquer sur les en-têtes.
Quelle est la taille moyenne de l'ensemble de données?
Si, après une recherche, j'obtiens toutes les informations dont j'ai besoin sur un seul écran de données, je ne suis peut-être pas enclin à trier.
Pourquoi les utilisateurs qui trient en utilisant la fonction?
C'est trier sorte de lié à la question précédente. Tous les utilisateurs n'aiment pas effectuer de recherche. J'ai vu des utilisateurs simplement prendre les données par défaut et faire défiler le chemin vers le bonheur.
La grille de données est-elle si douloureusement lente que les utilisateurs ne l'utilisent jamais?
Est-il possible que les utilisateurs n'aiment tout simplement pas le tri en raison de problèmes de performances? En tant que développeur qui expérimente l'UX, je ne suis pas sûr que j'achète les performances comme une barrière. À moins que votre application n'effectue d'énormes agrégations à chaque tri, il n'y a aucune raison pour que vous ne puissiez pas agréger les données, puis trier le résultat. Vous pouvez même pré-calculer périodiquement les agrégations. La présence même de sorte ne devrait pas être un problème.
Cela peut être un peu hors sujet car il se situe davantage sous le côté développement des choses. En tant que développeur full stack, je peux dire que la fonctionnalité de recherche peut être gourmande en performances. Tout dépend de ce qui est recherché, de la quantité recherchée, de la quantité de filtrage initialement effectuée, etc. Je demanderais aux développeurs de réévaluer la fonctionnalité de recherche initiale et de voir où elle peut être améliorée. Il y a généralement toujours place à amélioration.
Ce commentaire qui vient probablement des développeurs n'est pas exact si les choses se font correctement. "fonction de tri provoquant des problèmes dans la base de données et créant des divergences dans les données" Ce commentaire à lui seul m'en lasserait. Pour moi, c'est une dérobade pour être paresseux et ne pas vouloir améliorer les choses.
Je ne supprimerais pas les options si elles sont importantes pour la page car elles ne sont pas beaucoup d'options de recherche pour commencer. Je ne vois que 3 filtres et cela ne devrait pas être un impact significatif sur les performances.
Il se peut également que le placement des filtres affecte leur utilisation et que ce changement puisse donner des résultats différents. Vous pouvez considérer quels filtres sont les plus importants pour que l'utilisateur atteigne son objectif et les ajuste au besoin.
Quelques bonnes pensées ont déjà été partagées, alors je vais juste ajouter une chose que je n'ai pas vue. Bien que les données quantitatives sur l'utilisation des fonctionnalités soient importantes, elles ne révèlent pas pourquoi les utilisateurs trient ou non. Il vous semble que le concepteur assume une certaine valeur perçue dans la fonction de tri, donc déterminer si ces hypothèses correspondent à la pensée de vos utilisateurs (au-delà des chiffres) pourrait être une prochaine étape informative.
Vous devez toujours être extrêmement prudent quant à la suppression d'une fonctionnalité. La plupart des entreprises ne savent pas très bien pourquoi leurs clients choisissent leurs produits plutôt que ceux de leurs concurrents. Il y a toujours la possibilité que vous supprimiez accidentellement une fonction de tueur et que vous vous mettiez en faillite. Vous devez avoir une très bonne raison commerciale pour supprimer une fonctionnalité. D'après votre question, il ne semble pas que vous ayez réellement entreprise raison de supprimer la fonctionnalité. Donc, la réponse courte est, ne la supprimez pas.
Maintenant, si les performances vraiment sont importantes, comme pour vos clients et que vous vous plaignez et que vous partez pour votre concurrent parce que votre produit est trop lent ... alors vous pouvez commencer à envisager de déchirer des parties de l'application pour corriger les performances. Il s'agit d'une décision commerciale réelle avec des avantages et des inconvénients et des résultats attendus qui doivent être calculés et pris en compte. Dans ce cas, vous devez considérer combien d'argent perdez-vous réellement en raison de la perte de clients et combien cela coûtera-t-il pour résoudre les problèmes par rapport à combien d'argent/combien de clients vous attendez-vous à perdre si vous supprimez la fonctionnalité X afin de le faire donc.
Mais c'est une décision commerciale qui nécessite beaucoup (et je veux dire beaucoup) d'informations spécifiques sur votre entreprise et vos clients. Fondamentalement, il est peu probable que nous puissions répondre à cela pour vous.
Du côté positif, de votre question, il semble qu'il y ait NO REASON WHATSOEVER pour supprimer cette fonction de tri.
Aussi ce que nous gagnerions en procédant comme nous le prévoyons:
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
Rien de tout cela n'a rien à voir avec, ou n'est lié en aucune façon au tri. En particulier, je voudrais aborder "et non 2 minutes après ou autre" et "parce que nous n'aurions pas besoin de le calculer toutes les 2 minutes". Cela suggère très fortement un problème majeur avec votre architecture de base de données. Tout d'abord, vous devez jamais stocker les valeurs calculées dans la base de données car la cohérence des données devient alors un cauchemar. Étant donné que vous avez également mentionné: "apparemment, la fonction de tri provoque des problèmes dans la base de données et crée des incohérences dans les données", je vais m'exprimer et dire ce qui cause vraiment votre incohérence dans les données, c'est le stockage des valeurs générées/calculées dans le DB.
Mais c'est en fait bien pire que cela, car il ne devrait même pas être POSSIBLE pour que le tri entraîne une incohérence des données de backend. Le tri est effectué dans le cadre des instructions select, qui sont généralement en lecture seule. Peu importe la façon dont vous triez vos résultats de recherche, le tableau à partir duquel vous avez obtenu vos résultats ne change pas.
Il semble que si vous supprimez la fonctionnalité de tri, les utilisateurs auront du mal à trouver des campagnes moins performantes. Cela ressemble à une action importante, sinon la principale, donc vous devez prendre en charge le tri.
À mon avis, le gain de performances ne serait pas aussi important que les difficultés que cela va créer pour les utilisateurs. Il sera préférable pour eux de charger 0,1 plus lentement mais de pouvoir trouver rapidement des campagnes à faible/haute performance.
De plus, les performances pourraient être améliorées de diverses manières sans impact direct sur la convivialité. Mais c'est un tout autre domaine.
Pour moi, la question clé au moment de décider de supprimer ou de reconcevoir une fonctionnalité existante est simple: quel sera le gain net de convivialité? La règle générale est que si vous ne voyez pas un gain d'au moins 20% (quelle que soit la ou les mesures importantes pour votre domaine), vous ne devriez probablement pas le faire. Le nombre de 20% n'est pas important, ce qui est important, c'est que vous pensez à ce que signifie que votre application soit utilisable, mesurez les performances actuelles des utilisateurs par rapport à cette définition, puis mesurez les effets de votre modification proposée et décidez si les gains justifient la changement.
Cela ressemble au changement que vous avez défini, c'est plus pour les développeurs que pour les utilisateurs. En tant que professionnel UX, je me battrais bec et ongles contre ça. Même si seulement 5% des utilisateurs utilisent le tri, cela ne rend certainement pas votre application moins utilisable pour les autres utilisateurs. Mais vous pouvez parier que vous compromettrez sérieusement la convivialité de ces 5% avec des conséquences directes (colère des critiques des réseaux sociaux et des applications, perte possible de clients/revenus, augmentation des coûts de support, etc ...), et pour quoi faire?
Le travail de votre interface est de résoudre les problèmes des utilisateurs et non de faciliter le travail de votre développeur.
Gardez l'interface telle qu'elle est, mais demandez aux développeurs de déplacer le traitement de tri du côté client.
Cela allégera la base de données et l'application fonctionnera rapidement pour les personnes qui ne trient pas.
Avant même d'envisager de supprimer une fonctionnalité (qui nécessitait des ressources), pensez aux éléments suivants:
Qui l'utilise? Selon l'application, le tri peut être une fonctionnalité que seuls les utilisateurs expérimentés utilisent et couper vos utilisateurs expérimentés d'une fonctionnalité est une mauvaise décision. D'après mon expérience (et je suis sûr que cela s'applique à de nombreux autres développeurs), les utilisateurs avancés sont ceux qui vous donnent les commentaires les plus constructifs sur votre produit. Les utilisateurs avancés sont des utilisateurs durables. Ils ne se contentent pas de vérifier votre application, puis de passer à la suivante. Ce sont les clients avec lesquels vous souhaitez que votre base d'utilisateurs déborde. Si un utilisateur n'est pas satisfait de votre application, les chances qu'il devienne un utilisateur avancé passent par la fenêtre.
Est-ce une fonctionnalité cachée involontairement? Peut-être que la conception actuellement utilisée de l'interface utilisateur de votre application ne montre pas vraiment aux utilisateurs que le tri est même possible, donc la plupart des utilisateurs ne le savent pas vraiment et sont donc ne l'utilise pas. Faire quelque chose dans ce sens pourrait donner des résultats positifs ou au moins vous donner une évaluation plus concrète de l'utilisation de cette fonctionnalité. Si votre application comporte un didacticiel quelconque ou au moins une superposition contenant des informations utiles sur ce qui est quoi, essayez d'ajouter les informations sur le tri quelque part (plus, si elles sont déjà présentes) visibles. Je suis souvent surpris du nombre d'utilisateurs qui manquent (pour moi) de choses évidentes. Une bonne interaction avec l'utilisateur commence par enseigner à l'utilisateur de la manière la plus rapide et la plus transparente comment il/elle peut utiliser votre produit. Parfois, le fait de ne pas trouver une certaine fonctionnalité peut conduire l'utilisateur à vider votre application et à se tourner vers vos concurrents.
Quant aux aspects de développement (puisque je suis moi-même ingénieur logiciel):
Problème d'obtention des données dans postgresql en raison de la quantité d'appel nécessaire pour mettre à jour ces données, juste pour que nous puissions les trier, si moins de 5% de nos utilisateurs l'utilisent réellement pour trier.
Si quelque chose est rarement utilisé et pourtant introduit un surdébit se produisant régulièrement, alors quelque chose ne va pas avec la façon dont vos appels fonctionnent. Si 5% de vos utilisateurs utilisent la fonction uniquement dans ces 5%, la surcharge devrait se produire.
N'évolue pas pour toujours comme il est maintenant
Plusieurs options ici: appliquer le tri sur des sous-ensembles, puis fusionner les résultats (-> sorte de tri par fusion), créer des vues pré-triées (si les données ne changent pas si souvent, vous pouvez offrir à l'utilisateur une liste triée très rapide puisque vous avez déjà fait sur le serveur), limitez la quantité de données pouvant être triées (par exemple, si vous avez découvert qu'après 1000 entrées, le tri produit une limite de surcharge trop élevée à seulement 1000 entrées -> permettant à l'utilisateur de trier uniquement un sous-ensemble sélectionné est également une option) etc.
Temps réel. Comme, vraiment en temps réel. Chaque fois que vous actualisez la page, vous voyez les dernières performances (et non 2 minutes après ou autre)
Je pense que nous avons une compréhension différente de ce qu'est le temps réel. Si vous avez vraiment une vue en temps réel de vos données (que l'utilisateur peut voir à travers une page Web), cela signifie que la page doit être constamment mise à jour avec une latence très, très minime. Dans ce cas, le tri serait le moindre de vos problèmes (tout le monde aime utiliser une application mobile qui aspire la bande passante disponible (et chère!) En un rien de temps ...). Encore une fois, ce que vous décrivez ici ressemble davantage à un problème d'implémentation ou à un problème de conception général avec l'architecture (principalement ici, en arrière-plan), puis à quelque chose lié à la fonction de tri.
De meilleures performances non seulement pour la liste, mais pour l'ensemble du produit. Moins de "gel" dans une partie des applications
Voir la citation précédente ci-dessus.
Optimisation des coûts, car nous n'aurions pas besoin de le calculer toutes les 2 minutes, bien que personne ne verrait réellement les données (pendant la nuit ou autre). Nous ne le calculerions que si nécessaire
C'est quelque chose qui dépend totalement de l'application et du ou des scénarios qu'elle gère. Puisque nous n'en savons rien, je ne peux pas vous donner de commentaires.
Ce qui me semble étrange, c'est le fait que vous mentionnez que vos listes peuvent atteindre même 100 éléments. Permettez-moi de vous dire quelque chose - 100 éléments dans une liste, même pour une application, ce n'est pas beaucoup. Je dirais que vos développeurs n'ont pas fait un bon travail en triant une liste de 100 éléments (je suppose que chaque élément ne contient pas de mégaoctets de données mais si oui, que font ces données même dans une application mobile?!) pose un si gros problème. Je ne connais rien de la technologie que vous utilisez (JS + HTML, Qt, Java etc.) mais il existe de nombreux composants de liste prêts à l'emploi qui sont optimisés pour gérer un grand nombre d'articles. Peut-être que vos développeurs ont choisi les mauvais outils pour le travail?
Premièrement, le tri est une fonctionnalité que les utilisateurs considéreront comme acquise. Donc, aucun utilisateur ne vous dira jamais à quel point cette fonctionnalité de tri est géniale - ils le feront vous le diront et seront très mécontents si cette fonctionnalité a disparu.
Deuxièmement, je serais très, très prudent si un développeur prétend que la suppression d'une fonctionnalité rendra une application plus efficace. (Et j'ai une application sur l'App Store d'Apple qui n'a aucun problème à trier environ 10000 éléments de différentes manières sur un iPhone 4 qui est environ dix fois plus lent qu'un appareil moderne, donc je demanderais à WTF ces gars-là font si le tri ralentit leur application vers le bas).
Bonnes réponses déjà, mais je ne peux pas m'empêcher d'ajouter mes deux cents.
Le problème est que le pourcentage d'utilisateurs utilisant une fonctionnalité n'est pas une mesure précise de l'importance ou de la valeur d'une fonctionnalité.
Cette question n'est pas nouvelle dans le développement de logiciels. Je pense que chaque entreprise fait face à ce type de décisions à un niveau ou à un autre. Par exemple, dans une carrière précédente, j'ai dirigé un magasin de vélos. Pour pouvoir aider les clients avec des vélos et du matériel étranges, je devais souvent acheter des outils et du matériel qui ne généreraient probablement jamais assez de revenus pour payer par eux-mêmes. Supposons donc qu'il existe un outil coûteux qui ne sera probablement jamais rentabilisé, le retour sur investissement, du moins lors de la première permutation, est terrible. Dois-je l'acheter?
La réponse est "cela dépend". Dans le magasin de vélos, le problème auquel j'ai été confronté était que si je ne soutenais pas une base suffisamment large de clients, ils iraient dans un autre endroit mieux équipé, et une fois qu'ils auraient une relation avec un autre magasin de vélos, ils iraient probablement là-bas - même pour les choses faciles et à haut retour sur investissement. Si vous pouvez toujours résoudre les problèmes d'un client, il est probable qu'il viendra en premier. Ils sont également plus susceptibles de vous recommander à des amis.
Lorsque vous décidez du retour sur investissement d'une fonctionnalité logicielle, des idées similaires s'appliquent.
- Lorsqu'un utilisateur potentiel évalue votre outil, il peut comparer des listes de fonctionnalités, même s'il n'utilise jamais une fonctionnalité particulière, il peut être rassuré de savoir qu'il est là s'il en aura besoin.
- Supposons qu'une entreprise évalue l'utilisation de votre outil. 99% de leurs utilisateurs n'ont pas besoin de la fonctionnalité X, mais UNE personne en a besoin et ils ne peuvent pas s'en passer. Ils choisiront l'outil qui fournit la fonctionnalité X, bien que la statistique du nombre d'utilisateurs utilisant X puisse sembler indiquer qu'il s'agit d'une fonctionnalité sans importance.
Il est facile de trouver d'autres exemples de la façon dont le pourcentage d'utilisateurs utilisant une fonctionnalité est une mesure insuffisante pour prendre une telle décision. Au lieu de cela, demandez-vous quelle est l'importance de votre fonctionnalité pour vos utilisateurs et votre modèle commercial? C'est une question plus difficile et nécessite probablement une certaine perspective sur votre domaine et vos utilisateurs.
Non, vous devez noter supprimer ceci. Parce que le tri est la fonctionnalité importante, vous pouvez l'utiliser à l'avenir avec des critères de recherche plus raffinés.
Je ne pense pas que ce soit aussi simple que vous devriez ou ne devriez pas. Le problème de performance est-il perçu ou réel? Voyez-vous de longs délais de chargement des pages pour les termes de recherche qui produisent une quantité importante de résultats? Peut-être que le nombre de résultats renvoyés à la page pourrait être réduit, s'il existe un point de déclenchement spécifique où les résultats X augmentent la charge et le tri de X ms.
Deuxièmement, d'autres options sont disponibles. Il n'est pas rare que les développeurs appliquent un correctif tout ou rien car ils ne considéreront pas les utilisateurs comme leur principal indicateur du fonctionnement d'une page comme prévu.
Si un problème existe comme indiqué dans le premier paragraphe, pourrait-il y avoir des gains d'efficacité en améliorant la façon dont les données se chargent ou les données sont conservées dans le cache? La connexion de données pourrait-elle être rendue plus efficace?
Vous remarquerez un modèle jusqu'à présent en ce que je n'ai pas encore suggéré d'affecter l'utilisateur, à moins qu'il n'y ait un défaut spécifique dans le système.
S'il y a un problème dans les temps de chargement et que les temps de chargement ne peuvent pas être améliorés dans le back-end, pourriez-vous permettre aux utilisateurs de désactiver le tri dans leurs préférences avec l'avantage de réduire les temps de chargement et les performances en tant qu'édulcorant, en les informant également qu'ils peuvent tourner trier à tout moment?
Ma principale conclusion de votre déclaration est que le tri n'est pas assez intuitif pour que tout le monde puisse l'utiliser. La recherche est lente et prend du temps, surtout en attendant les résultats, semble-t-il. Ma suggestion serait de ne pas supprimer le tri en option, mais de le développer davantage dans un système et un style dans lesquels les utilisateurs sont plus qu'heureux de s'engager, et un objectif clair serait d'améliorer cette carte thermique en ce qui concerne les fonctions de filtrage/tri. .
Le problème: J'ai fait partie d'une équipe avec ce problème, fondamentalement les performances du backend n'ont pas rattrapé les fonctionnalités demandées. La direction demande une fonctionnalité comme le tri et un membre de l'équipe de développement dit "c'est facile à ajouter" et n'a peut-être même pas de données de référence réelles. Un serveur de test peut avoir 1000 lignes de données de test sur le backend, mais les utilisateurs en direct peuvent en avoir des millions et maintenant vous, les développeurs, pourriez avoir peur de regarder leurs serveurs commencer à prendre feu lorsque quelqu'un clique sur ce bouton plusieurs fois par jour pour trier .
La solution: Tout d'abord voyez-vous ou obtenez-vous des plaintes de performances réelles ou les développeurs sont-ils simplement en train de regarder vers l'avenir et de crier? Si le produit est actuellement ou est sur le point de sombrer dans le chaos, supprimez par tous les moyens le tri et parlez aux utilisateurs qui le trient et parlez aux développeurs jusqu'à ce qu'une solution soit trouvée. S'il y a un certain temps, comme en mois ou en années, jusqu'à ce que le tri endommage sérieusement le produit, la meilleure chose à faire est de demander aux développeurs de le réparer, d'ajouter un index, de trouver un autre type de base de données qui vous aidera. J'y suis allé et nous avons laissé les utilisateurs attendre 30 secondes pendant quelques années, mais nous avons finalement cloné nos données dans un nouveau type de base de données "elasticsearch" qui a ouvert notre monde à une recherche/tri/comptage rapide et instantanée.
Il y a beaucoup de bonnes réponses.
Dans le cas où aucune ne serait adéquate, comment adopter une approche différente
Renommez la version actuelle. À la place de la version actuelle, mettez une version qui n'a pas le tri, mais elle a un bouton "activer le tri". S'ils cliquent, ils passent à l'ancienne version chère, sinon ils utilisent la nouvelle version bon marché.
Je suis d'accord que vous ne devez pas supprimer la fonctionnalité. J'ai déjà vu cela, où un gestionnaire supprime une fonctionnalité parce qu'il pense que personne ne l'utilise. Les utilisateurs commencent à se plaindre ... donc la fonctionnalité est de retour, mais avec de nouveaux bugs, les codeurs qui ont changé d'autres fonctionnalités ont omis ces fonctions "personne n'utilise".
Les cartes thermiques sont très limitées. Je clique au hasard sur des trucs tout le temps, et la moitié du temps ce n'est pas fructueux. Il est préférable de regarder l'utilisation des fonctionnalités par utilisateur . C'est-à-dire: lequel de nos utilisateurs utilise le tri? Et une étude encore meilleure est pourquoi utilisent-ils le tri ?
Prenez le tri sur Amazon. C'est un feu de benne. Les gens recherchent , et les résultats de la recherche sont tous des paillettes, alors ils essaient de trier pour séparer le blé de la balle. Et ça ne marche jamais , car il y a tellement de paillettes! Et c'est quelque chose qu'Amazon devrait regarder très attentivement. Filtrage, tri par niveaux, peu importe.
Donc, la meilleure question est quand les gens trient, qu'est-ce qu'ils recherchent vraiment? Et comment pouvons-nous mieux livrer cela?
Je suis tout à fait d'accord, vous ne devriez pas faire cela côté base de données. Le moteur de base de données est une ressource précieuse. Les programmeurs ne devraient pas lancer de tâches lourdes dans la base de données simplement parce qu'il est plus facile de coder.
Encore mieux, faites le tri à la demande directement sur le PC/l'appareil de l'utilisateur. Cela permet d'économiser temps de transaction résea - une erreur de conception classique consiste à tester sur l'Ethernet gigabit au bureau, tandis que votre utilisateur a un iPad 2G retombant sur Edge cellulaire avec 11% de perte de paquets. L'activité réseau est donc très importante pour la convivialité. Si vous téléphonez à la maison pour les rapports d'utilisation, faites-en une action d'arrière-plan et non un chemin critique.