Les nouveautés d'un produit, quand on passe ses journées à le construire
Pour qui livre un produit et doit dire quelque part ce qui a changé
Gratuit pour commencer, sans carte. Tout s'exporte, quand vous voulez.
Vous fabriquez quelque chose — une application, une API, un petit outil — et les utilisateurs qui s'y intéressent veulent savoir ce qui a changé. Une fiche de magasin est trop courte pour ça, un message sur un réseau disparaît en un jour, et un journal des versions à l'intérieur du produit n'est lu que par ceux qui sont déjà dedans.
Ce qui manque est un endroit sur le web ouvert : une adresse où chaque version est une page, retrouvable des mois plus tard par quelqu'un qui cherche la fonctionnalité que vous avez livrée, et un courriel qui part au moment de la publication.
Il n'y a pas d'outil dédié au journal des versions ici, et prétendre le contraire vous ferait perdre l'après-midi. Il y a des articles, des catégories, des mots-clés et une lettre d'information — ce dont un blog de notes de version est fait.
Ce dont vous avez besoin
Une page par version, à une adresse permanente
Chaque article a son adresse, gelée à la première publication. Six mois plus tard, un lien posé dans une réponse d'assistance tombe encore sur la bonne page.
Un courriel qui part avec
La Lettre part avec l'article. Ceux qui ont demandé à être prévenus des changements le sont, et vous n'avez pas ouvert un second outil pour ça.
Un éditeur qui sait montrer du code
Des blocs de code à onglets pour plusieurs fichiers, des fiches techniques pour ce qui a changé, des encadrés en quatre tons pour les ruptures. Écrits comme des blocs plutôt que comme des conventions Markdown.
Des catégories qui séparent le bruit
Les versions dans l'une, les articles de fond dans une autre, les incidents dans une troisième. Un lecteur qui ne veut que les notes de version s'abonne au flux de cette catégorie.
Un site qui n'est pas votre produit
Votre atelier vit sur son sous-domaine ou sur votre domaine. Il ne partage pas un déploiement avec votre application, il ne tombe pas avec elle, et écrire un article ne veut pas dire livrer une version.
Ce que Typoza ne fait pas
Mieux vaut le lire ici que le découvrir après trois articles écrits. Si l'un de ces points est bloquant pour vous, ne vous inscrivez pas.
- Pas de page d'état. S'il vous faut un historique d'incidents avec disponibilité et abonnés alertés, c'est un autre produit et il vaut mieux en acheter un.
- Rien ne lit votre dépôt. Les notes de version s'écrivent à la main — pas d'étiquette, pas de plage de commits et pas de pull request qui devienne un article.
- Pas de widget dans l'application. Typoza publie un site ; afficher ces notes dans votre produit est le travail de votre code, et les flux sont la façon de le faire.
- Pas de documentation versionnée. Un article est un instant ; une documentation qui a une v1 et une v2 demande un outil de documentation.
- Pas de commentaires publics, donc les rapports de bug continueront d'arriver là où ils arrivent aujourd'hui.
L'article que vous remettez à plus tard
Vous avez lu le tableau. Ouvrez un atelier et écrivez le premier — ça prend moins de temps que de choisir un thème WordPress.
Gratuit pour commencer, sans carte. Tout s'exporte, quand vous voulez.