Parce qu’on ne peut pas tout faire à l’instinct, il faut prendre le temps d’effectuer des tests d’utilisabilité. Cela permet de perfectionner le produit/service (min+ ici), de le compléter et de prendre des décisions quant à son évolution.

Soyons honnêtes, l’expérience utilisateur est quelque chose de très complexe : il faut en offrir un maximum, dans les meilleures conditions pour le plus grand nombre… tout en essayant de faire en sorte que cela paraisse simple à utiliser.

La version 2 de min+ me semblait prendre un mauvais chemin : elle est devenue trop compliquée. D’ailleurs, sans y chercher la moindre causalité, le nombre de téléchargements des deux versions viendrait presque le confirmer.

Au départ, je souhaitais simplement créer un framework… min+ est devenu un outil ultra-modulaire permettant de créer des mises en pages en ajoutant des classes à body donc en gérant les styles de manière conditionnelle — ce qui n’est pas sans poser quelques problématiques assez importantes pour la MAJ au format EPUB 3 et le support de l’ancien format Kindle.

Aussi, il me paraissait naturel de faire une petite pause dans le développement histoire de prendre un recul nécessaire.

Après avoir collecté les retours d’expérience des utilisateurs de la v3 (bêta) et de la v2 (publique), nous pouvons établir un premier bilan. Je me propose donc de le partager avec vous aujourd’hui, en 10 observations.

1. Les gens sont curieux

Beaucoup téléchargent pour voir, ils « restent » s’ils trouvent une quelconque utilité. C’est précisément ce qui peut rendre l’évolution de min+ « casse-gueule » puisque certains trouvent son utilité dans les choses sur lesquelles nous souhaiterions revenir en arrière.

2. C’est utile

Parce que l’e-production n’a pas encore atteint sa maturité et que nous ne disposons pas forcément d’outils réellement dédiés et simples d’utilisation, un fichier EPUB voire même une feuille CSS toute bête peuvent avoir leur utilité.

De fait, min+ est un peu la matérialisation de tous les petits bouts de code et tutoriels qui ont été publiés sur le site. Cela permet de les placer en contexte et de voir directement les bénéfices qu’ils peuvent apporter.

Par extension, c’est un moyen de déployer plus facilement ces bouts de code — donc potentiellement des solutions à certains problèmes — dans l’écosystème EPUB (modification de la CSS, copier/coller de certains morceaux, etc.).

3. Les gens te font confiance

S’il y a beaucoup de curieux, il ne faudrait pas oublier ceux qui cherchent à se former et considèrent que ton boilerplate peut leur servir de référence, ceux qui rencontrent quelques problèmes et cherchent des solutions, et ceux qui souhaitent implémenter min+ comme framework dans leur processus de fabrication.

Tu as donc d’assez grandes responsabilités et ce même si tu cherches à t’en dédouaner.

C’est précisément la raison pour laquelle min+ m’a forcé à remettre quelques habitudes en question : à quel moment la bonne pratique est-elle suffisamment bonne ? C’est à mon sens la question que les développeurs de certaines solutions logicielles ont tendance à oublier.

4. Les utilisateurs ne sauront pas forcément modifier les styles

Il faut rester simple et cohérent ; il faut offrir un défaut qui fonctionne pour une majorité de livres.

L’absence de gabarits pour tout le paratexte ou de styles pour les notes peut devenir un frein à l’utilisation. C’est quelque chose qui me conforte dans l’idée de proposer certaines fonctionnalités sous d’autres formes. Par exemple, une (web-)app qui permettrait d’uploader son livre et d’en modifier la mise en pages à l’aide d’une interface graphique pour régler ce « problème » — je perçois de plus en plus ce genre d’outil comme nécessaire car il est extrêmement difficile de demander à l’utilisateur de changer de logiciel.

5. On ne peut pas satisfaire tout le monde

Il n’y a pas d’utilisateur moyen, il n’y a que des extrêmes. Raison de plus de faire simple et cohérent.

Ceux qui ne savent pas modifier la CSS conserveront la maquette d’origine, les autres la modifieront en profondeur : on ne peut pas en demander trop, il faut trouver le moyen d’obtenir le meilleur résultat possible en fonction des connaissances de chacun sans pour autant surcharger le boilerplate pour ceux qui en viendraient à le modifier.

Sans surprise, les utilisateurs préféreraient que la composition de droite soit celle par défaut.

6. Tu ne peux pas tout prévoir

Les utilisateurs font des choses que tu n’avais pas prévues, comme des titres h3 ou h4 dans des encadrés, ces mêmes encadrés utilisés pour une introduction ou des images de différentes largeurs d’écran par exemple.

Or, tout ce qui n’est pas prévu risque de bloquer l’utilisation de min+, a fortiori parce que les mises en pages sont gérées de manière conditionnelle.

Cela est d’autant plus important que…

7. Tu as besoin d’une documentation

Ce point est critique parce que les utilisateurs ne demandent pas forcément de l’aide quand ils en ont besoin.

En pratique, ils ne te feront que très rarement remonter leurs problèmes, il faut leur demander.

C’est là qu’une documentation peut être une solution intermédiaire, ne serait-ce que pour expliquer comment faire quelque chose et fournir des bouts de CSS à copier/coller.

8. Il faut que le format Kindle soit pris en compte

Il n’y a pas le choix puisque l’on peut très facilement convertir dans ce format depuis un fichier EPUB.

Cela implique qu’en plus des gabarits de paratexte, il faut une table des matières XHTML, ce qui n’est pas forcément pertinent en EPUB pour certains types de livres comme les romans par exemple.

9. Il commence à y avoir une demande pour EPUB3

Ça reste assez marginal mais ça commence à venir. C’est la prochaine étape de min+ et je ne cache pas que la problématique majeure de cette MAJ sera la gestion de la rétrocompatibilité EPUB 2 — on peut facilement casser pas mal de choses si l’on ne porte pas une attention particulière à cette problématique.

Il va donc falloir trouver un moyen de gérer tout ceci au mieux pour proposer la meilleure expérience utilisateur possible.

En outre, je ne cache pas que cette observation risque d’avoir quelques répercussions sur le pack « swiss ». Si j’envisageais une mise à jour des trois thèmes de ce pack pour y ajouter le support EPUB 3, elle ne sera pas forcément pour tout de suite. De fait, il n’y a jamais eu aucune demande d’amélioration ou report de bug pour le pack. Je préfère donc me concentrer sur min+ dans les prochaines semaines.

10. Il y a besoin d’un outil pour prototyper

Si cela peut être le rôle d’un boilerplate, il me semble qu’il faudrait plutôt un « logiciel » permettant de récupérer une CSS toute faite.

Les utilisateurs aiment la modularité mais souhaitent que l’utilisation reste simple. Autant donc articuler la modularité sous forme de petits « outils-atomes » que l’on peut combiner et ajouter au processus de fabrication déjà existant plutôt que de tout mettre dans un fichier EPUB.

Le prototypage n’est pas forcément la vocation première de min+, elle l’est devenue par accident. Dans la mesure où cette fonctionnalité a un impact non négligeable sur d’autres points (MAJ EPUB3 + support Mobi7), il est certainement plus raisonnable de la gérer à part, sous une autre forme.

Pour information, nous avons déjà commencé à réfléchir à cette autre forme avec @Nephou sur Twitter. A priori, cela impliquerait un travail très conséquent, ne serait-ce que pour prendre en charge les sorties EPUB d’InDesign. Le support de ces fichiers n’est pas vraiment discutable à l’heure actuelle puisque le logiciel est massivement utilisé — et cela sous-entendrait donc de nettoyer le balisage HTML et de le modifier au besoin.

Feuille de route de min+

Si nous devinions une majorité de ces points depuis un moment, ce petit test nous a permis de les confirmer. Il ne faudrait pour autant considérer que nous avons perdu du temps puisque nous disposons désormais d’une vision beaucoup plus précise des usages (assez) variés de min+.

J’aurais pu ajouter 2 points supplémentaires à cette liste :

1. tu ferais probablement mieux de publier ton outil en anglais ;
2. tu peux oublier l’idée de le rentabiliser, le volume de téléchargements et la valeur perçue étant relativement faibles.

Deux observations qui nous confortent dans le choix de GitHub pour la MAJ au format EPUB 3, donc dans notre volonté de nous appuyer sur la communauté pour faire avancer le projet au mieux. La prochaine version s’accompagnera donc d’un changement de licence.

Nous allons donc bientôt publier une version de transition (v2.5) pour remettre les choses à plat au niveau des feuilles de styles et renouer avec la philosophie d’origine : une nouvelle composition par défaut fera son apparition pour plus de simplicité, des options disparaîtront pour plus de légèreté — si vous utilisez min+ pour prototyper, sauvegardez la v2 à plusieurs endroits, donc.

La prochaine version majeure (v3) proposera le support d’EPUB 3 et sera distribuée via GitHub. Dans la mesure où je sais que cela peut poser quelques problèmes à certains utilisateurs, qui ne souhaitent pas manipuler de l’EPUB 3, la version 2.5 (qui est un équivalent EPUB 2 de la v3, ne vous inquiétez pas) restera disponible au téléchargement.

Pour être plus précis, voici ce qui va se passer dans les prochains mois :

1. création d’un framework CSS (« Blitz »), prenant en charge EPUB 2 et EPUB 3, auquel les abonnés newsletter auront accès dès finalisation ;
2. utilisation de ce framework pour la v3 de min+ ;
3. mise à jour de min+ et dépôt sur GitHub ;
4. re-création des thèmes swiss à partir de min+ ;
5. création d’une fonte-icône (« Fleuron ») dont le mappage sera « compatible text-to-speech », et auquel les abonnés newsletter auront accès dès finalisation ;
6. intégration de cette fonte à min+.

En attendant, n’hésitez pas à me faire signe si vous souhaitez contribuer à la documentation ou à un hypothétique outil de prototypage.

À noter également que les abonnés newsletter recevront très bientôt un nouvel outil exclusif : « markup.css ». N’hésitez donc pas à vous abonner (ci-dessous) si vous souhaitez en profiter.