Relation entre le développement frontal et la conception d'interaction
[Je ne change pas la question d'origine car il y a des réponses précieuses ici. mais la recherche que je menais est maintenant terminée et les résultats sont publiés ici
et http://hci.me.uk/jqueryperformance/
Question d'origine:
J'essaie de rédiger un document sur la façon de rechercher les niveaux de sensibilisation aux performances de jQuery entre les concepteurs d'interaction. La performance est une partie essentielle de l'expérience utilisateur et jQuery est l'outil le plus largement utilisé pour créer des prototypes basés sur le Web.
Avant de concevoir cette enquête complètement, je voudrais poser 2 questions aux praticiens qui utilisent jQuery dans leur travail:
- À votre avis, combien en tant que concepteur d'expérience devez-vous connaître sur les technologies Web front-end et jQuery?
- Quelle est l'importance des performances de calcul pour vous par rapport aux performances perçues?
Il semble que vous recherchiez principalement des opinions. En regardant l'échantillon d'enquête, je dirais que vous aurez quelques défis. La première est que je ne vois pas beaucoup de groupes UX avec des développeurs frontaux bien équipés. À mon humble avis, cela devrait être une exigence pour une équipe UX, mais, hélas, je ne le vois pas autant que je le devrais.
Deuxièmement, pour le prototypage rapide, les gens ne sont probablement pas du tout en test unitaire, ni se soucient peut-être des réglages fins des sélecteurs jQuery. Cela tombe généralement du côté du développement. Encore une fois, je pense que UX devrait développer le code frontal mais ce n'est généralement pas le cas.
Quant aux exemples de questions, il semble que vous cherchiez principalement à voir s'ils connaissent les techniques d'optimisation de base de jQuery (spécificité du sélecteur, mise en cache des éléments, etc.). De bonnes questions, bien sûr, mais probablement pas un objectif principal de l'UX (encore une fois, même si cela devrait l'être).
Enfin, certains aspects du développement frontal peuvent sembler être un obstacle aux performances pour l'utilisateur final, mais offrent des augmentations de performances de développement interne, qui, à leur tour, peuvent être avantageuses pour l'utilisateur final. Je suppose que cela pourrait être appelé un ajustement pragmatique des performances.
Par exemple, je vais souvent parcourir le DOM pour construire une interaction jQuery plutôt que d'utiliser des ID stricts pour chaque élément et de le passer dans le script pour faciliter l'implémentation et la réutilisation pour nos développeurs non front-end. Une expérience de navigation légèrement plus lente (bien que certes peut-être imperceptible) mais un coup de pouce certain à la vitesse de développement interne.
MISE À JOUR:
Xgreen, merci d'avoir nettoyé la question d'origine. Pour ajouter des réponses plus spécifiques:
Question 1: Le concepteur individuel n'a peut-être pas besoin d'être un développeur frontal, mais le développement frontal est un composant central de l'ensemble d'outils de l'équipe UX. J'ai constaté que les équipes UX qui ne font pas leur propre développement frontal, ou du moins le prototypage frontal, leurs solutions ont tendance à être datées et à ne pas tirer parti de la gamme complète de technologies et de techniques à leur disposition.
Je trouve également qu'il est tout simplement impossible de concevoir tous les détails de chaque interaction sur papier uniquement. Vous devez vraiment entrer dans le code pour bien comprendre toute l'expérience utilisateur et l'ajuster au besoin. Pour concevoir pleinement l'expérience utilisateur, vous devez la créer.
Question 2: C'est une question plus difficile à répondre. Voir ma réponse ci-dessus. Il y a beaucoup de "bien, ça dépend" avec celui-ci. Les problèmes de performance réels et perçus sont importants pour être abordés avec raison.
Concernant 2):
En tant qu'utilisateur, je me fiche des performances réelles. Tant qu'il se sent réactif et rapide, et que cela ne me retarde pas dans la réalisation de ma tâche, cela peut prendre autant de calculs CPU que nécessaire.
Exemples:
- Word donne la rétroaction: le document est ouvert, vous pouvez commencer à travailler - pourtant, en arrière-plan, il peut toujours chercher les pages 100-200.
- l'iPhone montre une image en cache de l'apparence de l'application , une fois chargée, jusqu'à ce que cette application ait complètement démarré - ce qui ne prend pas plus de temps que l'ouverture animation, la plupart du temps
- C'est aussi pourquoi vous utilisez des barres de progression et autres: pour donner à l'utilisateur un sentiment de contrôle et ainsi, le sentiment que cela prend moins de temps (par exemple Gronier/Gomri 2008).
(Je disais, en tant qu'utilisateur , comme le développeur en moi le fait s'inquiéter des performances de calcul, mais plutôt de regarder vers l'avenir: que puis-je faire de plus pour qu'il reste assez rapide?)
Sur la première question, la connaissance du fonctionnement de html, css, jquery et même Sencha ExtJS (que nous utilisons ici) est essentielle pour avoir une bonne relation avec les ingénieurs frontaux. J'essaie également de savoir comment fonctionnent les bases de données SQL et les bases. Je suis assis au milieu des ingénieurs. Une bonne relation avec l'ingénierie est aussi importante que celle avec les chefs de produit. Plus nous parlons la même langue, mieux c'est.
En ce qui concerne les performances, les performances perçues sont beaucoup plus importantes que les chiffres bruts. Cependant, vous avez besoin de chiffres bruts pour mesurer les améliorations.