Si tu ne veux pas faire un livre cours, de manière à focaliser les lecteurs sur les problématiques importantes, alors ce qui est bien aussi peut être de segmenter le livre en une partie principale aussi courte que possible (200 pages maximum me semblent bien) et des annexes pour pousser les sujet à fond.

Est-ce que tu comptes mettre des études de cas et des chiffres sur les résultats actuels des principaux sites selon les usages ?

Pour la taille totale, je serai très certainement largement au dessus des 200 pages, justement parce que je considère que tout ce que je dis doit être jusqu’au moindre détail. Par contre oui, l’index et la navigation dans le livre sont étudiées pour une référence et pas une lecture séquentielle. Je n’ai jamais utilisé un livre technique séquentiellement, du moins pas après les premiers chapitres.

Les points sont bien prioritisées et argumentés, il ne se perd pas en vains discours creux, et une fois le livre fermé, il est très facile de retrouver les informations que l’on veut à partir de la table des matières et de l’index. Ce dernier point est souvent très mal supporté dans de nombreux ouvrages qui se focalisent sur une utilisation « lecture unique et totale » du livre, ce qui est rarement le cas, surtout pour les pavés que l’on a en développement informatique.

Ce serait pas mal de se fixer ce double objectif : le bouquin ne doit pas avoir plus de 200 pages et on doit pouvoir retrouver une information dedans en moins d’une minute (ça c’est un bel objectif de performance).

Ça pourrait éventuellement m’intéresser. Techniquement, je ne suis pas spécialiste des performances côté client (ni serveur, encore moins d’ailleurs), «juste» intégrateur web.

Il faut encore que je décide si je me lance, parce que j’ai d’autres projets (pro et «communautaires» en cours ou sur le point de se décider, et donc risque d’être très occupé). Ça se ferait sur quelle période?