Vous avez des envies de sortie grandiloquentes ? Ou juste besoin d’un peu de ménage à l’arrêt de la machine virtuelle de Python ?

Il y a un module pour ça™.

import atexit
 
# la version courte
@atexit.register
def strange_game():
    print "What about a nice game of chess ?"
 
 
def last_word(word="rosebud"):
    print word
 
# la version qui autorise des arguments
atexit.register(last_word, word="Monde de merde")

Les fonctions ne sont pas garanties d’être appelées dans un ordre précis.

Dans la lignée du (Très) Grand listing des libs tierce partie les plus utiles en Python, voici la même chose mais pour les libs qui sont fournies en standard avec Python.

Bien entendu, il y a déjà une liste (bien plus complète), dans la documentation officielle. Mais la version ci-dessous vous propose uniquement les modules les plus utiles, en français, et surtout, avec une description de ce que vous pouvez faire avec (plutôt qu’une définition abstraite). Bonne découverte !

Parfois votre client va vous demander un truc tordu, ou vous poser des contraintes à la con. Parfois votre cousin relou vient passer le WE la même date que votre plan cul. Parfois on donne une formation Python sous Windows…

Quand ça m’arrive, j’essaye de me souvenir de l’exemple d’Alexandre Orion, un artiste Brésilien qui a été plusieurs fois interpellé brutalement par la police pour avoir décoré, petit à petit, les murs d’un tunnel à fort passage avec un énorme ossuaire.

Sa protestation contre la pollution ne l’a néanmoins jamais mené en prison, car il connaissait les règles. Il a juste un peu triché.

Au lieu de tagger des os sur les murs, il a choisi les endroits les plus sales, et a nettoyé la surface jusqu’à laisser apparaître la couleur blanche sous-jacente, dessinant par extrusion des cranes bien visibles.

La police l’a chopé plusieurs fois, mais il n’a jamais eu de problème avec la justice, car il n’y a pas de loi qui interdise de nettoyer un tunnel.

La prochaine fois que votre client vous demande un thème rose fluo, que votre meuf vous invite au dîner dominicale avec belle-maman, que votre pote super adroit vient vous emprunter votre bagnole, rappelez-vous qu’il y peut-être quelque chose à jouer avec la contrainte.

Tout comme il n’y a aucun courage à ne pas avoir peur, car le courage c’est de se bouger le cul malgré la trouille, on est pas créatif si on à les mains complètement libres. Ne vous plaignez pas que la situation n’es pas idéale, changez juste légèrement plan.

Je suis ergonome de formation. La première chose que j’ai apprise, c’est que mon intuition est à chier. Dit très clairement: si je design un site Web basé sur ce que je pense être utilisable, je vais me planter.

Même après des années d’expérience, mes premières idées sont très classiques, formatées, et Max me met des taquets derrière la tête régulièrement en guise de rappel.

Pour rendre une interface utilisable, il n’y a qu’un moyen fiable: le test. Pour apprendre en une journée tout ce que sais de l’ergonomie, vous pouvez en fait plus ou moins vous limiter à lire et appliquer le bouquin culte de Steve Krug.

Et c’est quelque chose que les designers ont du mal à comprendre. Ils font souvent des choses très belles, mais n’est pas Apple qui veut. Faire quelque chose de beau ET d’utilisable est très difficile.

Et si on doit choisir, il vaut mieux faire utilisable que beau.

Les états

Les états sont par exemple un vrai problème. En informatique, il n’y a pas vraiment de moyen de connaître l’état de quelque chose, et donc on crée artificiellement des repères visuels en espérant que l’utilisateur comprenne ce que l’on veut dire.

Seulement beau n’est pas forcément explicite. Est-ce que quelqu’un peut me dire ici quel bouton correspond à l’état “on” ?

On / Off, l'état le plus simple du monde

Le premier bouton, il est sur “off” parce qu’il affiche “off” ou il est sur “on”, offrant la possibilité de slider vers l’état “off” ? Les deux comportements existent dans le monde matériel.

Nous avons déjà des boutons qui reflètent très bien on / off: les checkboxes. Tout le monde sait comment ça marche, mais c’est moche, alors la plupart des designers essayent de les remplacer.

Si la designite vous démange, il faut alors sérieusement réfléchir, et ne pas proposer une solution moins efficace que ce qui existe déjà. Par exemple, une bonne implémentation du concept ci-dessus est:

Un tout petit détail...

L’auteur a ici ajouté un simple effet grisé sur le “off” (qui a la connotation de “désactivé”) et un effet de lumière sur le “on” (qui à la connotation de “en fonctionnement”). On sait clairement que le premier est l’état “off”, et que si on clique dessus, on va obtenir le second état: “on”.

Mais les états ne sont pas toujours aussi simples que on / off, et surtout, ils se cachent parfois dans des situations naturelles. 37signals ont largement défendu l’idée de parer à ce que l’utilisateur va vouloir faire, plutôt que d’attendre qu’il le fasse. Et cela passe par la prédictibilité, et la compréhension du contexte, donc par l’affichage d’états et d’intentions.

Un exemple simple: l’état vide. Vous n’imaginez pas combien il est courant de ne pas travailler l’état de départ, ou vide, d’une UI. Pourtant, c’est primordial car c’est le premier contact de l’utilisateur avec votre logiciel, et surtout, par principe, vide signifie qu’il n’y a aucun indice sur ce qu’il faut faire par défaut.

Prenez l’explorateur de fichiers par défaut d’Ubuntu, Nautilus. Il est globalement très bon. En revanche, sur les gros dossiers, ou sur les dossiers contenant beaucoup de thumbnails, il y a un instant plus ou moins long durant lequel on ne sait pas si il charge, ou si le dossier est vide.

Il n'y a rien dans ce dossier

Une fois qu’on a décidé que l’état “n’affiche rien” était bien non un temps de chargement, mais le fait qu’il n’y a rien à afficher, le cerveau fait la déduction, “le dossier est vide”.

Prenez par contre Marlin, l’explorateur d’Elementary OS, et donc bien moins intégré à Unity, dans lequel il ressort plus laid que Nautilus. Mais il vous montre instantanément de quoi il est question.

Marlin est un projet très prometteur

Ceci vous parait un détail. En fait, certains geeks trouvent même énervant tous ces trucs qui “ne servent à rien” pour “les gens qui ne veulent pas réfléchir” car “c’est quand même pas compliqué de voir que le dossier est vide”.

Oui, sauf que comme je vous en parlais précédemment, il existe une telle chose que la charge cérébrale, et que tout ce qui y participe se cumule.

Faire un beau design allège la charge cérébrale, mais faire un design utilisable la soulage sans commune mesure. Qui dit moins de charge, dit une utilisation fluide, sans peur (car oui, la peur de cliquer est un facteur étonnamment important dans le schéma de décision des utilisateurs lambdas), et donc des users qui aimeront votre app.

Le but est d’obtenir le même résultat que le crayon: quand vous écrivez, vous pensez à ce que vous écrivez, pas au crayon. Bien sûr que réfléchir un tout petit peu n’est pas la mer à boire, mais c’est autant de neurones que vous consacrez à votre outil plutôt qu’à votre travail.

Mais faire un design, plus que beau, utilisable, c’est aussi proposer à l’utilisateur ce qu’il peut faire. Mettre en avant les solutions les plus importantes. Les menus ajoutent à la charge cérébrale, ce sont des accès secondaires.

UsabilityFriction a posté une bonne illustration de la démarche. Ils sont partis d’un truc vide et pas top:

Vous n'avez pas de photo. Merci. Au revoir.

Et ils ont ajouté:

• Des raccourcis vers les actions de certains menus pour ajouter des photos.
• Un album photo d’exemple facilement supprimable pour que l’utilisateur puisse déjà se balader.
• Une vidéo de démo qui disparait dès qu’on ajoute un élément.
• Une courte et simple explication en forme d’invitation à l’action.

Vous n'avez pas de photos. Mais vous pouvez faire tout ça !

Ici il n’y a pas d’enjeu esthétique car c’est un mockup. Et c’est tout l’interêt du mockup pourri, fait avec balsamiq ou même au feutre Veleda sur brouillon: on se soucie de l’utilisabilité, pas du look. Le premier est la priorité car un bon designer rendra votre site qui est déjà facile à utiliser beau, alors que rendre un site déjà designé facile à utiliser demande beaucoup plus de travail additionnel.

Un bon dessin vaut mieux qu’un long discours, sauf si on dessine mal

Utiliser des icônes, c’est bien, non ?

En théorie, les formes et couleurs sont plus faciles et rapides à identifier que des mots. Et on évite les problèmes de traduction.

Mais, le hic, c’est que la signification d’une icône, contrairement à un mot, n’est pas garantie:

• Il existe des centaines de milliers de mots. On est loin d’avoir autant d’icônes.
• Les concepts abstraits sont très durs à icônifier. Essayez de trouver un symbole pour “niveau de difficulté” pour voir…
• Selon le contexte (culturel, expérience, environnement…), un symbole peut avoir des sens différents. Ainsi, le blanc est la couleur du mariage pour nous, mais du deuil dans certains pays musulmans. Le rouge est la couleur du mariage en Chine…
• Les icônes se périment plus vite que les mots. On a en encore beaucoup de logiciels qui symbolisent “sauvegarder” par une icône en forme de disquette. Combien d’utilisateurs actuels savent à quoi sert une disquette ? Ou même ce que c’est ?

Et si on choisit les icônes, on est obligé d’en mettre de manière cohérente, donc quand on rajoute un nouveau bouton, c’est une nouvelle icône à rajouter: il faut en trouver une correspondante, et au sens, et au design.

Un exemple: j’aime le nouveau design de Gmail. Mais le tout icône n’est pas forcément une réussite. Dans l’ancienne version, trouver comment marquer un mail en tant que spam était évident:

Le mot spam est très facile à reconnaître: court et à faible ambiguïté

Le nouveau design est plus beau, mais par contre, pour mettre son mail en spam…

Difficile de faire le lien entre un hexagone avec un point d'exclamation et "spam"

L’objectif n’est pas de pinailler sur les qualités de x ou z, mais d’illustrer. Stackoverflow est un modèle d’utilisabilité, mais le site comporte pourtant très peu d’icônes. Mnmlist prouve qu’on peut être jusqu’au boutiste pour aller à l’essentiel. Drudge report prouve que… heu… Je vous laisse lire.

Encore une fois, ne laissez pas la fièvre graphique prendre la priorité sur l’utilisabilité. Un beau design est important. Un design utilisable est primordial. Il n’existe pas de solution clé en main telle que “utilisons des icônes” qui pallie le travail de réflexion ergonomique dont votre projet à besoin.

Tous les types de designs ont leur place: avec et sans icônes, avec des images, sans, avec du texte, sans, avec des jeux de couleur, sans. La recette à elle seule ne peut pas rendre un plat délicieux, il faut de bons cuisiniers, de bons ingrédients et du travail.

(et la métaphore de la bouffe est particulièrement adaptée, car quel que soit l’acharnement que vous mettez à votre popotte, y aura toujours un connard pour trouver ça dégueulasse)

Un dernier exemple de “ça dépend”. Gedit (Gnome) VS Scratch (Elementary OS), deux éditeurs de texte, deux approches pour “l’état de départ”, aucune n’est meilleure que l’autre, et elles ne satisferont pas le même public.

Je préfère l'approche de Gedit: on commence cash à éditer, c'est plus efficace

Un non dev sera parfois plus à l'aise avec une indication claire de ce qui va se passer

Tout comme on oriente son design en fonction de son public (hacker news peut se permettre l’aspect WEB 1.0, pas Facebook), l’ergonomie doit viser aussi le type d’utilisateur auquel vous souhaitez plaire. Car il n’y a aucune chance que vous plaisiez à tout le monde.

Par défaut Django ajoute automatiquement un champ id à tous les modèles, et le configure pour être un entier qui s’auto incrémente puis le désigne comme la clé primaire. Il est néanmoins possible d’utiliser un autre champ comme clé primaire pour sa table: un slug ou un identifiant métier. Dans notre cas, on va voir comment utiliser un UUID.

Un UUID est un identifiant généré de manière pseudo aléatoire qui a une forte probabilité d’être unique dans le monde entier, il y a 4×10³⁷ combinaisons possibles pour les versions des algos récents. Selon le paradoxe des anniversaires, il faudrait créer un milliard de UUID par seconde pendant 100 ans pour que le prochain ait 50% de chance d’être un doublon. Normalement pour votre site de fans club des limules hermaphrodites, ça devrait être suffisant.

Utiliser des UUID possède de nombreux avantages car ils sont plus ou moins garantis d’être uniques, et ainsi:

• Vos serveurs peuvent les générer indépendemment les uns des autres.
• ./manage.py loadata ne va pas vous crasher à la gueule à cause d’une duplicate key.
• On peut faire du sharding sur la clé très facilement.
• Faire des réplications et des synchronisations est beaucoup plus simple qu’avec un AUTO INT.
• Votre modèle n’a pas besoin d’un champ significatif pour être unique.
• Vous pouvez générer l’ID côté client et l’envoyer au serveur.
• Faire communiquer des systèmes complètement séparés, différents ou par API interposée ne pose aucun problème de référence.

Pour toutes ces raisons, les bases de données NoSQL (CouchDB, MongoDB, etc) utilisent depuis longtemps les UUID comme clés primaires par défaut. Le moteur de base de données de Google, Big Table, utilise des UUID.

Pourtant les UUID ne sont pas exempts de défauts:

• Les JOINS sont beaucoup plus lents.
• Il prennent plus d’espace disque et en mémoire.
• On ne peut pas les mettre dans des URL sans que ce soit très très moche.
• Ils sont difficiles à retenir, dicter et rechercher manuellement.
• Ils sont non significatifs. Regardez un UUID ne vous donne aucune info sur les données sous-jacentes.
• Ils ne sont pas ordonnés. Cela a un impact sur la manipulation des données, et sur certains moteurs de BDD à l’insertion.

Les UUID ne sont donc pas la solution miracle à tous les soucis, mais ils sont tout de même mon choix par défaut en ce moment ne serait-ce que pour les fixtures. Je gagne les performances sur le caching et le parallélisme, et un peu de lenteur sur les JOINS est quelque chose que je peux supporter. Pour les gros sites, les JOINS sont de tout façon votre ennemi juré et on finit toujours par tweaker à grand coup de dé-normalisation.

On peut faire passer ses modèles Django aux UUID en faisant:

from uuid import uuid4
 
class MotDElle(object):
    ...
    id = models.CharField(max_length=36, primary_key=True,
                          default=lambda: str(uuid.uuid4()), editable=False)

Ou, si vous utilisez django_extensions (et vous devriez, ne serait-ce que pour shell_plus et runserver_plus):

from django_extensions.db.fields import UUIDField
 
class MotDElle(object):
    ...
    id = UUIDField(primary_key=True)

Ce qui a l’avantage de caster la valeur en un objet UUID, et non une bête string, à la lecture.

Malheureusement, pour le moment il n’y a aucune implémentation officielle de Django pour utiliser les UUID. Cela a des conséquences fort ennuyeuses:

• Les implémentations actuelles utilisent un VARCHAR pour stocker l’UUID au lieu d’un type natif quand c’est possible, et donc ce n’est pas du tout optimisé. L’exception étant django-pdfield, mais dans ce cas, adieu la compatibilité entre plusieurs SGBD.
• django.contrib.auth.models.User n’a aucun moyen d’utiliser proprement les UUID (il ne vous reste que le monkey patching). Cela pourrait changer avec Django 1.5 qui prévoit un modèle User extensible. \o/

Un ticket pendouille depuis 5 ans sur la question. Je vous invite d’ailleurs à le spammer jusqu’à ce que réouverture s’en suive. Et le premier qui me dit “t’as qu’à l’implémenter, toi”, je lui retourne un tampon dans la poire.