Group items tagged

Pour les sites complexes avec beaucoup de JS, surveiller DOMContentLoaded (fin du parsing) plutôt que juste Load (fin du chargement) pour améliorer le ressenti utilisateur

Où comment la manière de servir des fichiers change l'expérience utilisateur. Quand la mécanique influe sur l'aspect pratique.

Intéressant mais rien de vraiment nouveau... les Streams, ça existe depuis Java 1.0 (1996), et sans doute avant dans d'autres langages. Tant mieux si ça arrive dans node.js !

Pourquoi créer 2 sites différents pour le mobile et le desktop (toujours pas de traduction/adaptation potable en français ?). Principalement pour des raisons techniques, d'expérience utilisateur et de performance (poids d'images, structure de page, usage adapté).

Si l'article le mérite on peut toujours ouvrir un Google Doc et essayer de traduire à plusieurs s'il y a des gens motivés. Eric pourrait même publier la traduction sur son blog. Perso j'ai déjà une traduction sur un long article UX en cours.

On fait quoi avec Retina et HiDPI ? On propose une image à résolution plus importante alors qu'on s'est battu des mois à améliorer les performances de nos sites Web ? Comparatif de compressions et de rendus pour haute densité … et où l'on peut constater que cette réduction de poids sera plus efficace et simple à gérer qu'une multiplication des résolutions d'image.

L'approche est maligne mais me dérange sur quelques aspects : 1. Si elle vient à se populariser on va se retrouver avec un Web remplies d'images de qualité médiocre uniquement exploitable sous forme de miniatures. En outre, nous pourrons faire une croix sur les recherches d'images ciblées par dimensions. 2. La contribution par des utilisateurs lambdas ne sera pas aisée de par la validation du rendu après réduction du visuel. 3. Quid de l'automatisation ? Les images présentées dans les exemples de Daan sont de qualité studio et supportent parfaitement le traitement. Enrichir le billet par des photos de moindre qualité serait intéressant.

"Il existe une conviction partagée chez les grands du Web : la performance perçue par l'utilisateur est critique. Cette performance a en effet un impact direct sur l'adoption du service et son utilisation dans la durée. Et le ressenti utilisateur est directement lié à la rapidité d'affichage des interfaces."

25% des français sous les 2MBPs

- fait par Steve Souders - le but avoué est d'en faire un standard - calculs basés sur l'API WebTiming, la google toolbar, un plugin firefox, ou simplement JS + un cookie

Je vous en parlais il y a presque deux mois, JSON c'est lent à interpréter si on le fait bien. C'est même globalement plus lent que XML parce que le code est en javascript, côté utilisateur, alors que XML est géré nativement par les navigateurs.

À partir de quand une page est-elle lente ? Combien de temps est prêt à attendre un utilisateur ?

- "améliorer" les perfs a diminué le revenu - les développeurs n'ont regardé que les scores ySlow et PageSpeed + le waterfall d'une page - ils ont oublié que les utilisateurs naviguaient sur plusieurs pages - une meilleure mesure a été obtenue en posant un javascript sur les pages pour mesurer le temps de chargement effectif

Github a mis en place quelques fonctionnalités innovantes pour améliorer la performance et l'expérience utilisateur.