Du html au livre [
www related ] @
22:20:05
Attention Geek talk ! Cet article aurait plus sa place sur mon futur site professionnel mais celui-ci n’ayant pas encore été créé par manque de temps, je poste une première version ici, il sera probablement remanié et complété avant d’être republié sur mon prochain blog « pro ».
Bert Bos et Håkon Wium Lie ont généré leur dernier livre « Cascading Style Sheets: Designing for the Web, 3rd Edition » entièrement en XHTML et CSS ! Le « site » a ensuite simplement été converti en PDF (grâce à Prince) puis transmis en sans retouche à leur imprimeur. C’est la un pas énorme en matière de technologie web, la puissance et l’intérêt des standards n’est décidément plus à prouver.
Pour ceux qui n’y verraient qu’un exploit technique sans lendemain voici un exemple concret parmi tant d’autre de l’avantage de cette solution : Imaginons une grande société qui du fait de sont activité pointue dans un domaine est amenée à rédiger régulièrement des documentations techniques en faisant appel aux compétences des différents services internes et externes. La rédaction d’une documentation passerait (dans le cas le plus simple) par de simples échanges de fichiers texte (word ou pdf), qui seront successivement annotés, corrigés, renvoyés à l’auteur d’origine, validés par les décideurs de chaque services, puis finalement regroupés pour être mis en page de façon homogène. Dans le meilleur des cas la société se sera préalablement équipé d’un outil de génération de documentation, ces outils sont souvent très coûteux, pas toujours adaptés à la culture métier de chaque entreprise et nécessite un temps d’apprentissage qui ampute encore l’entreprise d’une partie de son budget annuel.
On a donc aujourd’hui le choix entre deux solutions, la première qui nécessite une organisation draconienne du flux des documents ainsi échangés (et par expérience, même avec la meilleur volonté de tous les intervenants, on devra compter sur un pourcentage d’erreur), un coût important pour la vérification, la validation des contenus, l’intervention d’un maquettiste expérimenté pour la mise en page de chaque documentation, sans parler du fait que les parties du document final rédigées par un services ne seront accessibles à l’intégralité de l’entreprise qu’après publication de la version papier. Et la seconde qui implique l’acquisition de logiciels coûteux (sans même parler des coûts de mise à jour) pas toujours adaptés aux besoins spécifiques d’une entreprise et un temps d’apprentissage important (plus la formation des nouveaux arrivants et de prestataires extérieurs), je ne parle même pas de l’accessibilité aux personnes handicapés encore trop peu pris en compte sur la majorité des outils existant à ce jour.
Imaginons maintenant que la société utilise un simple Wiki, cet outil pourra être rapidement déployé et rendu accessible à toutes personnes devant intervenir sur la rédaction de la documentation. La simplicité d’utilisation d’un wiki n’est plus à prouvé, Wikipédia en est probablement un des meilleurs exemples. En fonction de ses besoins la société pourra faire développer un Wiki spécifique en quelques jours, elle pourra même faire évoluer les fonctionnalités proposées au fur et à mesure des retour des utilisateurs, ceci sans altérer les contributions précédentes. Les différentes sections de la documentation ainsi rédigée pourront être corrigées et validées en temps réel, elle pourront être accessibles à tous à tout moment (bien avant la diffusion de la version papier) et enfin toutes personnes soufrant d’un handicape physique rendant la consultation ou la contribution difficile voir impossible sur un outil propriétaire pourront sans problème intervenir au même titre que leurs collègues sur un wiki développer en prenant compte des règles d’accessibilité en vigueurs sur internet.
Grâce à l’expérience des deux auteurs citées plus haut et la puissance de xHTML et CSS, ce Wiki pourra être converti (aussi souvent que l’on le souhaitera) en une édition papier dont la clareté de la mise en page donnera l’impression d’avoir été réalisé avec les logiciels leader dans le domaine de la PAO (Xpress et InDesign pour ne pas les citer) l’intégralité de la mise en page pourra être modifiée en fonction de la cible par une simple correction de la feuille de style css utilisée pour générer la version pdf et des extraits pourront être générés sans avoir recours à l’intervention d’un technicien en PAO.
Bien entendu les grands maquettistes (dont je suis le premier fan) n’ont pas encore de soucis à se faire, il s’agit là de documentation technique dont la mise en page est soumise à une certaine rigueur, on est très loin de pouvoir envisager de générer automatiquement des maquettes originales qui font la force des plus beaux magazines tendances.
Mais encore une fois, on démontre qu’on le peut considérablement réduire les coûts de production d’un document par une utilisation réfléchie des standards du web.
Plus d’info sur l’expérience en question sur le blog A List Apart fondé par le génial Jeffrey Zeldman
Bert Bos et Håkon Wium Lie ont généré leur dernier livre « Cascading Style Sheets: Designing for the Web, 3rd Edition » entièrement en XHTML et CSS ! Le « site » a ensuite simplement été converti en PDF (grâce à Prince) puis transmis en sans retouche à leur imprimeur. C’est la un pas énorme en matière de technologie web, la puissance et l’intérêt des standards n’est décidément plus à prouver.
Pour ceux qui n’y verraient qu’un exploit technique sans lendemain voici un exemple concret parmi tant d’autre de l’avantage de cette solution : Imaginons une grande société qui du fait de sont activité pointue dans un domaine est amenée à rédiger régulièrement des documentations techniques en faisant appel aux compétences des différents services internes et externes. La rédaction d’une documentation passerait (dans le cas le plus simple) par de simples échanges de fichiers texte (word ou pdf), qui seront successivement annotés, corrigés, renvoyés à l’auteur d’origine, validés par les décideurs de chaque services, puis finalement regroupés pour être mis en page de façon homogène. Dans le meilleur des cas la société se sera préalablement équipé d’un outil de génération de documentation, ces outils sont souvent très coûteux, pas toujours adaptés à la culture métier de chaque entreprise et nécessite un temps d’apprentissage qui ampute encore l’entreprise d’une partie de son budget annuel.
On a donc aujourd’hui le choix entre deux solutions, la première qui nécessite une organisation draconienne du flux des documents ainsi échangés (et par expérience, même avec la meilleur volonté de tous les intervenants, on devra compter sur un pourcentage d’erreur), un coût important pour la vérification, la validation des contenus, l’intervention d’un maquettiste expérimenté pour la mise en page de chaque documentation, sans parler du fait que les parties du document final rédigées par un services ne seront accessibles à l’intégralité de l’entreprise qu’après publication de la version papier. Et la seconde qui implique l’acquisition de logiciels coûteux (sans même parler des coûts de mise à jour) pas toujours adaptés aux besoins spécifiques d’une entreprise et un temps d’apprentissage important (plus la formation des nouveaux arrivants et de prestataires extérieurs), je ne parle même pas de l’accessibilité aux personnes handicapés encore trop peu pris en compte sur la majorité des outils existant à ce jour.
Imaginons maintenant que la société utilise un simple Wiki, cet outil pourra être rapidement déployé et rendu accessible à toutes personnes devant intervenir sur la rédaction de la documentation. La simplicité d’utilisation d’un wiki n’est plus à prouvé, Wikipédia en est probablement un des meilleurs exemples. En fonction de ses besoins la société pourra faire développer un Wiki spécifique en quelques jours, elle pourra même faire évoluer les fonctionnalités proposées au fur et à mesure des retour des utilisateurs, ceci sans altérer les contributions précédentes. Les différentes sections de la documentation ainsi rédigée pourront être corrigées et validées en temps réel, elle pourront être accessibles à tous à tout moment (bien avant la diffusion de la version papier) et enfin toutes personnes soufrant d’un handicape physique rendant la consultation ou la contribution difficile voir impossible sur un outil propriétaire pourront sans problème intervenir au même titre que leurs collègues sur un wiki développer en prenant compte des règles d’accessibilité en vigueurs sur internet.
Grâce à l’expérience des deux auteurs citées plus haut et la puissance de xHTML et CSS, ce Wiki pourra être converti (aussi souvent que l’on le souhaitera) en une édition papier dont la clareté de la mise en page donnera l’impression d’avoir été réalisé avec les logiciels leader dans le domaine de la PAO (Xpress et InDesign pour ne pas les citer) l’intégralité de la mise en page pourra être modifiée en fonction de la cible par une simple correction de la feuille de style css utilisée pour générer la version pdf et des extraits pourront être générés sans avoir recours à l’intervention d’un technicien en PAO.
Bien entendu les grands maquettistes (dont je suis le premier fan) n’ont pas encore de soucis à se faire, il s’agit là de documentation technique dont la mise en page est soumise à une certaine rigueur, on est très loin de pouvoir envisager de générer automatiquement des maquettes originales qui font la force des plus beaux magazines tendances.
Mais encore une fois, on démontre qu’on le peut considérablement réduire les coûts de production d’un document par une utilisation réfléchie des standards du web.
Plus d’info sur l’expérience en question sur le blog A List Apart fondé par le génial Jeffrey Zeldman
Commentaires (0)