samedi 6 septembre 2014

Comprendre le digital publishing



C'est la rentrée. Un point sur les technologies s'impose, surtout à l'annonce de grandes évolutions à paraître dans les tous prochains jours en terme de workflow dans la création numérique.

Qu'est-ce que le digital publishing ? C'est tout ce qui est publié au format numérique et à destination des écrans numériques, qu'ils soient tactiles ou non. Ainsi, on inclut les tablettes, les smartphones, les phabelettes (agendas tactiles de taille intermédiaire, parfois avec stylets, entre smartphones et tablettes), les ordinateurs fixes et mobiles, les bornes interactives, les consoles de jeu, les télés connectées. La plupart du temps, nous simplifions l'approche en nous concentrant sur les tablettes tactiles, identifiées comme le hub en devenir de tout contenu publié avec un angle éditorial qualitatif.

Mais, dans cette jungle technologique, on distingue plusieurs formats. Et tous peuvent quasiment être générés depuis votre logiciel favoris de composition : Indesign. Alors, quel format est utilisé et pour quoi faire ? Là est la vraie question. Voici un schéma pour vous aider à comprendre.
Dans ce schéma, on remarque tout d'abord que InDesign permet en effet d'exporter dans les principaux formats numériques : PDF, package Zip et SWF. On oubliera le SWF qui se marginalise du fait de l'absence du player sur les nouveaux périphériques. Le PDF reste le must pour l'impression (avec une calibration CMJN) et le transfert de fichiers entre postes numériques (avec une calibration RVB) mais souffre d'un aspect peu immersif, peu interactif et facilement piratable. Il nous reste donc l'export packagé (entendre un zip) qui permet de déployer votre mise en forme vers tous les autres systèmes de publication, les stores, les sites Web, les liseuses, en mode plus immersif et sécurisé.

Chez Adobe, l'export d'un package compressé prend le nom de folio. C'est un zip, ni plus ni moins. Chez Aquafadas, plugin pour InDesign, ce fichier porte le nom de zave. C'est également un zip, ni plus ni moins. Le principe étant, non pas de pouvoir générer ce zip, que vous pourriez avec beaucoup d'assiduité générer manuellement au fond. Mais bien de savoir comment le lire, le protéger, le distribuer et le monétiser. C'est le rôle des solutions propriétaires, DPS et Aquafadas, entre autres, à destination des stores natifs ou pour les liseuses. Ainsi, votre solution prendra à sa charge la compilation d'une application embarquant les librairies de codes natifs ou HTML5, capables d'interpréter ce zip qui ne rassemble finalement que les données à l'état brut. Et vous payerez pour disposer de ces moteurs codés en C ou en HTML via Webkit au lieu de les coder par vous-même. Vous noterez que l'export HTML induit le recours (transparent) à un moteur de navigateur pour convertir les données HTML en C, ce qui se révèle très gourmand en terme de ressources et limite par conséquent les effets et les animations dans vos parutions, bien que cela rende le workflow plus simple puisque tout le Web est déjà en HTML. Donc, soit vous publiez en natif (en C) pour de meilleurs résultats mais à travers une gestion plus complexe de la distribution, soit en HTML5, c'est plus simple, mais au prix de moindres performances.

Les stores natifs rassemblent donc les applications codées en langages dérivés de C, ce qui leur confèrent une grande robustesse, de grandes performances, un bon niveau de sécurisation, et l'accès à tous les services embarqués dans les stores et sur vos périphériques (achats intégrés et sécurisés, par abonnement ou à l'acte, accès matériel aux périphériques, non limite de la mémoire...).

Les liseuses ne sont ni plus ni moins que des applications natives qui délèguent l'interprétation des contenus à un moteur externe, généralement un Webkit, comprendre le navigateur embarqué par défaut sur votre périphérique. Une liseuse fonctionne donc comme un navigateur Web. Ainsi, un contenu composé pour le Web risque fort d'être compatible avec une liseuse, à quelques ajustements près. Cela permet de monter plus facilement des contenus à l'aide de langages simples, comme le HTML, ou à partir de routines déjà en place sur le Web, en PHP. Mais au prix de moindres performances à l'affichage et d'animations moins fluides. Les capacités intrinsèques des périphériques tendent cela dit à augmenter avec le temps (loi de Moore) et nous invitent donc à apprécier de plus en plus ces possibilités. Dans les langages simplifiés lus par les liseuses, il y a le XHTML (mise en page Web plate, sans animation) et le HTML5 (mise en page avec des animations et de l'interactivité). Le XHTML donne naissance au standard ePub2. Le HTML5 donne naissance au standard ePub3. Des librairies supplémentaires de comportements Javascript associées aux possibilités graphiques du HTML5 donnent naissance au nouveau standard EDUePub amélioré pour l'éducation (anotations, quizz, zooms, partage, stockage, archivage). Le succès du standard ePub reste assez mitigé pour le moment du fait des limites de ce format et des premières liseuses pas très véloces. Mais l'avènement de ces tout nouveaux standards, de performances accrues,  et de nouveaux modèles économiques de publication numérique à venir, devraient changer la donne.

Ainsi, on distingue globalement trois grands axes de publication numérique.
  • Un axe gratuit pour obtenir des fichiers utilisables par tous, sur ordinateurs (PDF, SWF).
  • Un axe simplifié qui valorise surtout l'expérience textuelle (ePub/HTML) plus favorable à l'édition traditionnelle de livres, de quotidiens, d'hebdomadaires.
  • Et enfin un axe avancé, natif, plus complexe mais offrant plus de possibilités techniques et immersives, pour des projets de communication et des applications de service codés en C.
Vous choisirez la solution technique en fonction de la nature de votre projet. Chaque format, ePub, natif en C ou autre, ne se révèle pas toujours le plus en phase avec les besoins du projet, même si ce dernier apparaît initialement comme un projet éditorial ou une présentation interactive avancée. Ainsi, il est courant de voir des périodiques (magazines de presse) adopter le format natif afin de permettre le déploiement d'animations et d'enrichissements avancés et de voir transposés ces mêmes parutions au format HTML, PDF ou Flash pour les rendre disponibles facilement aux lecteurs qui ne disposent pas de périphériques tactiles.

A suivre.

Aucun commentaire:

Enregistrer un commentaire