UI adaptative vs UI reconnaissable
Je suis lecture d'une thèse qui traite des interfaces utilisateur axées sur les tâches. Ils discutent d'une application qui adapte/filtre les vues en fonction des éléments pertinents déterminés par un historique d'interaction. Ils prouvent que leur interface ( Eclipse Mylyn ) se traduit par une productivité plus élevée pour les programmeurs.
Bien que je ne doute pas que ces résultats soient corrects, je me demande si une telle interface utilisateur adaptative n'a pas non plus d'inconvénients. Personnellement, je compte beaucoup sur ce à quoi m'attendre dans les interfaces que j'utilise. Je me demande si une interface qui change avec le temps (masque/déplace certains éléments) n'aboutit pas parfois à une expérience utilisateur dégradée.
Plus particulièrement, je recherche des études qui évaluent les inconvénients possibles des interfaces utilisateur adaptatives.
Quelque part vers la fin de la thèse, ils font référence à un article de 2004 qui traite de ce sujet. ne comparaison des menus statiques, adaptatifs et adaptables .
résumé
Les applications logicielles continuent de croître en termes de nombre de fonctionnalités qu'elles offrent, ce qui rend la personnalisation de plus en plus importante. La recherche a montré que la plupart des utilisateurs préfèrent le contrôle offert par une approche adaptative de la personnalisation plutôt qu'une approche adaptative contrôlée par le système. Aucune étude, cependant, n'a comparé l'efficacité des deux approches. Dans une étude de laboratoire contrôlée avec 27 sujets, nous avons comparé l'efficacité mesurée et perçue de trois conditions de menu: statique, adaptable et adaptatif. Chacun a été implémenté comme un menu divisé, dans lequel les quatre premiers éléments sont restés statiques, adaptables par le sujet ou adaptés en fonction des éléments fréquemment et récemment utilisés par le sujet. Le menu statique s'est avéré être beaucoup plus rapide que le menu adaptatif, et le menu adaptable s'est révélé être beaucoup plus rapide que le menu adaptatif dans certaines conditions . La majorité des utilisateurs préfèrent le menu adaptable dans l'ensemble. Les implications pour la conception de l'interface sont discutées.
Bien que le menu adaptable ait été préféré par la majorité des sujets (55%), le menu adaptatif a été pris en charge (30%). En revanche, seulement 15% des sujets souhaitaient le menu statique, même s'il s'agissait du menu fractionné optimal (basé sur des mesures préalables).
Ils suggèrent de poursuivre les recherches sur la combinaison des deux méthodes dans une conception à initiatives mixtes. Par exemple. demander au système de suggérer périodiquement des ajouts/suppressions.
En ce qui concerne Microsoft abandonnant les menus adaptatifs lors de la création d'Office 2007, regardez cette vidéo avec le principal responsable du programme de groupe de l'équipe Microsoft Office UX Jensen Harris:
- L'histoire du ruban (vers 07h45)
Désactivez (grisez) les éléments non applicables, ne les masquez pas ...
Sauf s'il s'agit d'un niveau de sécurité/autorisation d'utilisateur (par exemple, administrateur système vs programmeur, manager vs employé - la même personne voit toujours la même chose).
Cela suppose que ce que vous entendez par "au fil du temps" est que le contexte précédent rend les éléments applicables ou non.
Nous avons rencontré le problème exact et si des "écrans" entiers de contenu ne sont applicables qu'à certains moments (nous utilisons des "pages" dans un format de style "assistant"), il est correct de les ajouter/supprimer. Mais l'image de l'écran correspond à ce que l'utilisateur se souvient si les éléments n/a sont désactivés. Sinon, il y a une confusion subconsciente.
Ne masquez pas ou ne montrez pas les choses en fonction de la décision du programme.
Vous remarquez que dans le ruban de bureau, comme il est dimensionné, les trucs se compressent plutôt que se cachent et fonctionnent toujours. Excellent compromis entre l'utilisation de l'espace, l'apparence et la convivialité. Rembmer les menus "adaptatifs" du bureau XP et plus tôt ce truc auto-montré/caché? MAJOR SUCK.
Concernant Facebook. Facebook fait des choses inutilisables. Pourquoi font-ils cela? Parce qu'ils sont bons pour un look à 100%, car il s'agit avant tout de l'opinion des utilisateurs. Pourquoi? Les utilisateurs ne savent pas ce qu'ils veulent. Les sondages/préférences des utilisateurs renvoient des résultats qui peuvent favoriser des approches moins efficaces (plus difficiles à utiliser). Lorsque vous ne trouvez pas ce que vous voulez faire dans le livre de visage, vous et tous les autres vous blâmez. Faux. Facebook sait que c'est ce que vous faites. La convivialité est un beau-fils roux à la beauté.
résultat
Si vous voulez de belles applications dans lesquelles les gens devront acheter pour mettre le souper sur votre table, optez d'abord pour l'apparence, ensuite pour l'utilisabilité (les gens doivent toujours être en mesure de le faire fonctionner). En d'autres termes, cachez-le s'il a l'air bien.
Si vous écrivez pour une entreprise qui a besoin d'utilisations pour choisir votre gamme d'applications professionnelles et l'efficacité = $, passez d'abord à la convivialité. En d'autres termes, activez/désactivez, mais ne masquez jamais les éléments à l'écran de manière dynamique.
Du point de vue de la conception de la simplicité, il est logique que le comportement de l'utilisateur simplifie l'interface et lui facilite la vie sur la route (car toutes les options ont été canalisées vers les seules utiles). Livre recommandé: Simple et utilisable par Gilles Colborne.
Mais, je suis d'accord sur votre inquiétude, que se passe-t-il si l'adaptation de l'interface aboutit à une confusion pour l'utilisateur? Je me demande si Facebook a mené des études sur l'impact de leur approche "système jamais fini", où les utilisateurs doivent faire face à des changements importants sur l'interface graphique au moins une fois par an.
Je suis surpris de ces résultats - j'imagine qu'en tant qu'utilisateur, je serais confus lorsque des objets ou des fonctions disparaissent de la vue. Si `` l'adaptation '' n'est pas bien indiquée, je pourrais confondre un `` réarrangement '' pour un changement d'état, des autorisations utilisateur ou autre chose qui `` me verrouille '' dans une certaine sorte de comportement. En tant qu'utilisateur, je supposerais immédiatement que j'avais changé le "mode" de mon application d'une certaine manière, et plutôt que de chercher le contrôle caché, je chercherais les contrôles qui ont effectué ce "mode".
En tant que tel, je suggère que vous ne fournissiez qu'une interface utilisateur adaptative avec certaines précautions et avec trois mises en garde spécifiques:
Un: Ringfence la partie "adaptative" de votre interface utilisateur dans son propre widget ou contrôle visuellement distinct. Combinez-le avec d'autres fonctions "contextuelles", afin que l'utilisateur ait toujours confiance dans le reste de l'application
En tant qu'utilisateur, je ne m'attends généralement pas à ce que les menus et autres changent. Si les choses commençaient à bouger, je pourrais arrêter de faire confiance au reste de l'application pour rester statique. Si, cependant, l '"adaptation" était limitée à sa propre zone visuellement distincte (comme une fenêtre flottante de "contexte"), et sa nature était bien communiquée (avec un titre comme "Vous pourriez vouloir ...", par exemple) , Je pouvais profiter des avantages d'une interface utilisateur adaptative sans perdre la confiance dans le reste de l'application.
Un autre avantage de cette approche est que vous pouvez inclure d'autres contenus "contextuels" au-delà des contrôles et des données. Imaginez ma fenêtre "Vous voudrez peut-être ..." suggérant des articles d'aide contextuelle ou des articles sur des effets et des conseils intéressants. Imaginez qu'il explore même le Web pour trouver du contenu pertinent! En distinguant votre composant "expérimental et amorphe" du "reste" de l'application, vous pouvez exploiter "contextuel" sans perdre la confiance de vos utilisateurs, ou créer une application qui semble à moitié terminée ou peu fiable.
Deux: assurez-vous que vos algorithmes de "pertinence" sont à la hauteur
Si vous allez changer une interface utilisateur en cours d'utilisation, vous devez vous assurer qu'elle fait rendre le programme plus pertinent et utile. Si j'ajoute à plusieurs reprises des en-têtes puis des puces, je ne veux pas que mes contrôles de puces disparaissent sur la troisième en-tête, simplement parce que votre application pense "trois en-têtes = beaucoup de structuration de document = peu de chances d'ajouter un nouveau contenu de puce". Vous devez vous appuyer sur des données empiriques et être capable de repérer des modèles assez complexes, sinon vous risquez de laisser tomber vos utilisateurs. Chaque fois que votre adaptation frustre votre utilisateur, vous perdez beaucoup, beaucoup plus de bonne volonté que lorsqu'elle améliore la pertinence de l'interface utilisateur.
Trois: laissez les utilisateurs le désactiver!
Le pire vient au pire, laissez au moins les utilisateurs désactiver l'adaptation. Laissez-les réinitialiser leur historique d'utilisation et passez en mode "non enregistré" (afin qu'un ami prenne le relais ou qu'une tâche inhabituelle ne "perturbe" pas les commandes contextuelles). De cette façon, même si votre interface utilisateur "adaptative" risquée ne paie pas pour certains groupes, votre risque est atténué.