L'expérience utilisateurs vue par un psychologue

Cet article est tout bonnement excellent !

Il liste les points essentiels caractérisant les bonnes technique à appliquer pour des expériences utilisateurs réussie, d'un point de vue d'un psychologue.

La plupart des liens disponible dans le document (et dont j'en fait une liste à la fin de cet article) sont des notions importantes à prendre en compte et à connaître pour tout ceux qui réalisent des interfaces utilisateurs. L'auteur à couvert une très grande majorité des points et l'article est simple et rapide à lire, malgré sa grande taille qui peut rebuter.

Je ne peux que vous le conseiller :)

Pour information, voici les points abordés :

  1. L'Homme ne veut pas réfléchir ou travailler plus que ce qu'il devrait avoir à faire.
    • Faire le moins de travail possible.
    • Montrer des exemples.
    • Fournir des fonctionnalités que l'Homme a réellement besoin.
    • Fournir des valeurs par défaut afin de faire moins travailler l'Homme.
  2. L'Homme a des limites.
    • Fournir les informations dont il a besoin au bon moment.
    • L'information doit être facile à trouver et à lire.
    • Utiliser des en-têtes et des petits blocs de textes.
    • L'Homme préfère des courtes phrases mais lis plus longtemps avec de longue phrases.
  3. L'Homme font des erreurs.
    • Anticipez les erreurs pour les en empêcher.
    • Proposez un "undo".
    • Le meilleur message d'erreur est de n'en afficher aucun message.
    • Corrigez une erreur et indiquez ce que vous avez fait plutôt que montrer l'erreur
  4. La mémoire humaine est compliquée.
    • Évitez de demander à un Homme de se rappeler de quelque chose entre différentes pages.
    • L'Homme ne peux se rappeler que de 3-4 choses en même temps max.
  5. L'Homme est sociable.
    • Il utilise des technologies pour être social.
    • Ils copie ce que font les autres.
    • Ils se sent redevant si vous lui offrez quelque chose et attendez autre chose de sa part (comme remplir un formulaire).
  6. Attention
    • L'Homme à tendance à être attentif à quelque chose de nouveau, différent.
    • L'Homme est facilement distrait. Il peux ne pas s'apercevoir de changement qui viennent d'avoir lieu devant lui.
  7. L'Homme est un assoiffé de l'information.
    • L'Homme veux plus d'information qu'il peux en avoir.
    • L'Homme à besoin de feedback pour savoir ce qu'il se passe.
  8. L'inconscient : travail en tâche de fond.
    • La plupart des tâches mental se font inconsciemment.
    • L'ancien cerveau et le cerveau émotionnel agissent sans le savoir conscient.
  9. L'Homme se fait des idées d'une représentation d'un objet.
    • Les métaphores aident l'Homme à se faire une représentation mentale d'un objet.
  10. Système visuel.
    • Les éléments qui sont proches sont censé être liés.
    • Les couleurs peuvent aussi indiquer des éléments qui vont ensembles.

Au niveau des notions apportées par cet article, on peux trouver :

L'article se trouve ici.

Filed under  //  conseil   droit   exemple   experience   principe   règle   technique   travail   utilisateur   ux  
Posted by Cyril Nicodème 

10 astuces pour créer un environnement de travail motivant à la maison

Un article très intéressant sur les 10 astuces pour se créer un environnement de travail motivant à la maison. L'article est très bien réalisé, avec des images qui évitent la nécessité de lire les explications dans chaque parties.

Je vais vous lister les différents points ainsi que l'image associée. Pour le reste, je vous invite à vous rendre sur l'article d'origine, qui est complet et très agréable à lire.

Read the rest of this post »

Filed under  //  General   Projects   astuces   conseil   environnement   motivant   travail  
Posted by Cyril Nicodème 

25 conseils pour motiver votre équipe

Aujourd'hui, le blog de Bas de Baar nous propose 25 conseils/astuces pour motiver son équipe.

Read the rest of this post »

Filed under  //  Projects   astuce   conseil   hiérarchie   idée   liste   motivation   pyramide de maslow   team   travail   équipe  
Posted by Cyril Nicodème 

Vous vous y prenez mal si ...

Le site de postal-code propose une news très intéressante sur comment améliorer son temps de travail en listant les pratiques qu'un programmeur à tendance à prendre.

Donc, vous vous y prenez mal si :

  • Vous ne baptisez pas votre application en se basant sur un framework
  • Vous développez votre propre framework
  • Vous n'utilisez pas une couche d'abstraction au bases de données
  • Vous développez votre propre couche d'abstraction sgbd
  • Vous croyez que vous pouvez développer plus vite, mieux et plus efficacement que des librairies existantes
  • Il y a plus d'un développeur sur votre projet et que ce dernier n'à pas de convention de codage
  • Votre plate forme de bug ou votre roadmap sont vos principaux champs de travail
  • Vous n'utilisez pas de système de gestion de version (type cvs, svn, git)
  • Vous commentez le quoi mais pas le comment
  • Vous tentez de passer des propriétés plutôt que des instances à vos fonctions (méthodes)
  • Votre procédure de déploiement implique n'importe quelle combinaison du FTP et du Drag'&'Drop
  • Votre méthode de développement est faite de telle manière qu'elle ne peut-être testée unitairement (Unit Testing)
  • La première chose que vous faites est un copier/coller
  • Vous ne lisez pas (ou peu) de blogs parlant des langages de programmation que vous utilisez majoritairement
  • Vous n'avez été à aucun meeting ou conférence ces dernières années
  • Le seul code que vous lisez au boulot est le vôtre
  • Vous espérez qu'un jour, votre code sera lu par quelqu'un d'autre et qu'il saura que ce code vous appartient
  • Vous vous y prenez mal si vous n'apprenez pas tous les jours !

Il y a certains points sur lesquels je ne suis pas trop d'accord notament l'histoire sur les meetings... on fait avec nos moyens !! :)

Il y a un adage qui ne s'applique pas en bien pour cette liste :
«Celui qui crée son propre protocole sécurisé est soit un génie, soit un idiot»
(anyone who creates his own security protocol is either a genius or a fool), Bruce Schneier’s.

Vous trouverez le post original à cette adresse : http://www.postal-code.com/binarycode/2008/07/28/youre-doing-it-wrong-if/

Filed under  //  Projects   astuces   conseil   mal   méthode   prendre  
Posted by Cyril Nicodème 

Optimisation PHP

On parle très souvent de l'optimisation de code PHP, mais dans le concret, on se rend très vite compte que tous les conseils ne sont pas appliqués. Après la publication d'un article en anglais, sur 12 astuces d'optimisations PHP, je vais ici traduire ces astuces et indiquer les autres qui me semblent indispensables.

  1. Préférez les méthodes statiques. La rapidité d'exécution du code PHP est multiplié par 4 !
  2. Évitez autant que vous pouvez l'utilisation des méthodes magiques (__get, __set, etc)
  3. Require_once est plus lourd que require (logique puisqu'il va vérifier que le fichier n'à pas déjà été chargé !)
  4. Préférez l'utilisation des chemins absolus, qui évitent au moteur PHP de résoudre le chemin par le biais du système (utilisez $_SERVER ['DOCUMENT_ROOT'])
  5. Pour avoir le temps en secondes, préférez $_SERVER['REQUEST_TIME'] à time (). En effet, time () demande un temps de calcul à PHP alors que $_SERVER['REQUEST_TIME'] est déjà calculé !
  6. Evitez au maximum l'utilisation des expressions régulières (utilisation des fonctions strncasecmp, strpbrk et stripos)
  7. str_replace est plus rapide que preg_replace, mais strtr est 4 fois plus rapide que str_replace ... !!
  8. Preferez le passage de paramètre à des fonctions en String plutôt que Array, ce qui évitera un temps de traitement supplémentaire pour le parcours du tableau !
  9. L'utilisation du @ pour ne pas afficher les erreurs ralentit considérablement le traitement.
  10. $row['id'] est 7 fois plus rapide que $row[id] !!!
  11. Les messages d'erreurs ralentissent votre code ! Normal puisqu'ils sont (peuvent) être écrit dans le fichier de log, affichés, etc
  12. Essayez au maximum de sortir les fonctions telles que count, sizeof, ... des boucles. Car ces fonctions sont appelées à chaque itérations, ce qui alourdit considérablement le traitement !
  13. Préférez l'usage des simples quotes plutôt que des doubles quotes. Les doubles quotes sont parsées, tandis que les simples quotes non ! (le $ est affiché et n'est pas traité en tant que variable !)
  14. Évitez au maximum la redondance de code, en utilisant des classes ou des fonctions. Cela permet aussi une maintenance et une pérennité de votre code, puisqu'il suffira ensuite de modifier qu'à un seul endroit, au lieu de parcourir tous vos fichiers !
  15. Préférez l'utilisation des fonctions preg_* au lieu de ereg_* qui sont maintenant dépréciée !
  16. Préférez l'utilisation de
    if (!isset ($myvar{5}))
            echo $myvar.' is too short';
    au lieu de
    if (strlen ($myvar)
    Isset n'est pas une fonction mais une structure du langage, qui est donc beaucoup plus rapide !
  17. Préferez l'usage de ++$i plutot que $i++, qui est plus rapide (s'applique uniquement à PHP !)
  18. echo est plus rapide que print tout simplement car print retourne un état de succès tandis que echo ne fait qu'afficher.
  19. Tout ce qui n'est pas du PHP doit être en dehors des ?><?php ! Eviter les longs echo '<html>....'; qui seront plus long à parser que des ?><html>... !!!
  20. Préférez l'utilisation de la librairie ctype (activée par défaut depuis PHP 4.2.0) plutôt que des expressions régulières pour valider des entrées utilisateurs simple (tel que des nombres, des chaines, etc). Jetez un oeil à la librairie ctype sur php.net
  21. true est plus rapide que TRUE (sisi c'est vrai ! :p). Pourquoi ? parce que dans la structure de langage de PHP, la valeur booléenne est true. Si vous mettez TRUE, PHP va déjà vérifier si ce n'est pas une constante. C'est donc une perte de temps.
  22. 1 est plus rapide que true (et inversement 0 est plus rapide que false). Et comme PHP n'est pas typé ...
  23. Préferez if (42 == $value) plutot que ($value == 42). Ce ne sera pas plus rapide, mais vous obtiendrez une erreur si vous omettez un égal ! (42 = $value vous retournera une erreur. $value = 42 ne fera qu'assiger 42 à la variable $value, et vous comprendrez pas pourquoi votre code ne fonctionne pas :p)
  24. Il est préférable d'utiliser :
    $myArray = array ('banane' => 0, 'pomme' => 1, 'orange' => 2); 
    if (isset ($myArray[$fruits])) {
            echo $fruits.' exist';
    }
    plutot que
    $myArray = array ('banane', 'pomme', 'orange');
    if (array_exists ($myArray, $fruits)) {
            echo $fruits.' exists';
    }
  25. De plus gros blocs de code php augmentent la rapidité du script plutôt que des <?php .. ?> à chaque lignes
  26. Si vous utilisez echo, la concaténation est plus rapide avec des virgules qu'avec des points !!
    echo 'Bonjour Mr',$sName,', vous avez ',$iMsg,' message(s)'
  27. Utiliser au maximum unset, afin de libérer le plus de mémoire possible
  28. Essayer au maximum de génerer des pages html statiques une fois le contenu mis à jour, afin d'éviter un traitement à chaque affichage !

Toutes ces méthodes vous permettront d'avoir un code performant, ce qui aura pour conséquence d'améliorer la rapidité de rendu de vos pages en cas de forte consultation.

Filed under  //  Development   Php   cache   conseil   eviter   optimisation   préférable   quote   rapidity   rendu  
Posted by Cyril Nicodème