Skip to main content

La publicité digitale est une révolution qui est née avec l’arrivée des tablettes en tant que support de lecture. Lorque l’on parle de la publication digitale , il s’agit d’une synergie entre le support de lecture, la tablette tactile, qui offre une expérience proche du papier et de l’ardoise (le papier pour la mise en forme du contenu, l’ardoise pour le format et voire même le poids) et le contenu, qui se rapproche fortement du papier, avec la notion d’interactivité se rajoutant à l’élaboration du contenu, et de médias, son et vidéo, qui peuvent être mixé dans un même support.

Cette capacité de mix complexe de l’information via le support, la tablette, auquel on peut rajouter la phablette, donne un contenu hydrique, complexe, qui offre une expérience complètement différente des même contenu consulté sur un ordinateur de bureau ou bien un portable. Le tactile et l’absence de périphériques de saisie (souris, clavier) modifie complètement l’expérience utilisateur qui est une des donnée les plus importantes lors de l’élaboration d’un projet de publication. La production de ce type de contenu pose par contre plusieurs questions qui sont liées aux choix technologiques choisis, à la destination des contenus et à la qualité des interactions que vous voulez proposer.

Lors de mon article précédent sur Adobe et le syndrome quark, je précise dans l’article l’abandon de la solution Abobe DPS dans les choix de solutions de publication. Je réitère ce choix et cet article précisera les raison qui m’ont poussé à cette décision et pourquoi je vous recommande de la suivre. J’ai réagi précédemment dans l’article à l’abandon de FormCentral, précédée de l’abandon de la part d’Adobe de nombreuse autres solutions proposées, ce qui fragilise la décision d’utiliser dans un objectif de longue durée certaines des solutions Adobe. Je tiens à préciser quelques point à la suites des réactions liées à mon article précédent : j’ai été un Adobe addict, car à un moment donné, Adobe nous a amené une révolution dans nos méthodologie de production, en nous simplifiant notre travail et en améliorant la qualité potentielle des documents produits. C’est cette révolution que j’espérais trouver dans l’apport de la publication digitale, mais les choix stratégiques d’Adobe m’ont déçu, et mon parcours de chef de studio, de créatif ou de formateur certifié Adobe petite à petit m’ont confirmé dans cette déception. Là ou un nouveau média aurai pu révolutionner nos méthodes de travail, ainsi que la mise en forme de l’information que nous transmettons au niveau des canaux de distribution que nous utilisons, quitte à en créer d’autres, je n’ai vu que la mise en place de méthodes mercantiles ne cherchant qu’a capter une source de revenu supplémentaire, sans apporter d’évolution technologiques. Et malheureusement Adobe n’est pas la seule société ayant des visées semblables, la plupart des éditeurs de solution de publication ont pris la même orientation, c’est à dire, pour parler cru, capter le maximum de pognon de la mutation de force d’un secteur en crise, l’édition et la presse, obligé de s’adapter à la révolution de médias digitaux, sous peine de mourir ou de disparaître.

Pourtant des solutions existent pour que cette transition se fassent de manière plus douce. Il n’y a pas que Adobe DPS, ni même aquafadas ! Plus de 50 solutions existent, à des tarifs très divers et avec des fonctionnalités complètement différentes. Mais l’idée même de notion de solution de publication digitale n’est valable à notre niveau que pour une seule chose : nous ne sommes pas tous des développeur ! Pour les éditeurs, c’est juste un moyen de capter un flux monétaire. C’est un peu comme si Sony vous vendait une caméra vidéo, et vous faisait payer chaque vidéo que vous voudriez monter, arranger, diffuser… Adobe, et d’autres vous font payer InDesign tout les mois, et chaque n° de votre magazine ainsi que le kiosque qui l’accueille !

Dans les ténèbres les lier…

Avec l’arrivée des supports mobiles (tablettes, phablettes, smartphone…), la base du web s’est vu obligée d’évoluer : HTML 5, CSS 3, Javascript, ainsi que beaucoup d’autre langages liés : PHP, SQL , Python. La surprise est de voir que très peu de solutions de publication utilisent réellement le HTML 5 comme structure technique pour élaborer les publication, mais plutôt un surcouche interactive (en DPS, on appelle ça un Overlay) posée sur un aspect graphique qui est soit un PDF, soit un JPG. Cette construction, qui est commune à la plupart des éditeur oblige d’avoir un lecteur spécifique des contenus pour utiliser les interactions. Ce pour plusieurs raisons :

  • Ce lecteur permet de verrouiller l’utilisation des contenus qui ne sont utilisables qu’au travers de la solution de l’éditeur. Avec Adobe DPS, vous ne pouvez faire que du DPS. Même si les choix de publication vous permettent de choisir PDF ou Image lors de la publication de votre contenu, ce n’est que sur l’aspect graphique, par sur le format final. Le format .folio, rendu libre par Adobe, n’est utilisable à ce jour que par Adobe Viewer. Pareil pour le .zave d’aquafadas, qui n’est qu’une archive .zip, mais qui n’est lisible que par le viewer Aquafadas.
  • Le lecteur permet aussi de gérer l’abonnement et la monétisation des contenus, en excluant le diffuseur de l’application (le lecteur) tel qu’Apple ou Google via leur store respectif. Donc il permet aussi à l’éditeur de la solution de capter une partie de tout les revenus que sont susceptibles de générer vos publications.
  • Le lecteur améliore la navigation en rajoutant des éléments tels que sommaire, index, recherche, navigation horizontale, etc. C’est cette ergonomie de navigation qui différencie grandement une webapp d’une publication
  • Le lecteur permet aussi à une ou plusieurs publications d’être présentes sous forme d’une application téléchargeable sur un store
  • Le lecteur permet un gestion des droit de diffusion, en empêchant toute copie de votre publication

La typologie même du lecteur a certain avantage, qui vous sont facturé à des tarifs très divers selon les éditeurs, mais ces avantages sont à mettre en regard de solutions techniques gratuites, utilisable par tous !

Il y a d’autres raisons pour lesquelles vos publications ne sont pas en html 5, alors que vous pouvez sans aucun problème intégrer des animations html5 de type Edge Animate ou bien Motion Composer, et par extension pourquoi InDesign ne produit pas du html en dehors du .epub, format qui n’est juste qu’un site web encapsulé ! Le html5 est un format open source, c’est à dire que tous peuvent l’utiliser gratuitement, et le diffuser de même. Le format .epub est lui aussi un format libre. Mais l’utilisation de ce type de format et que vous pouvez manipuler le contenu de manière totalement libre, ce qui bloque toute possibilité pour un éditeur de monétiser la possibilité de créer un contenu. En gros, vous pouvez payer le logiciel qui va produire votre contenu, mais l’éditeur ne peut pas vous facturer la production dudit contenu, ainsi que sa distribution. Vous payez word pour pouvoir produire votre texte, vous ne payez pas chaque édition de votre texte ! Et c’est pourtant ce tour de passe-passe que les éditeurs on réussi à vous vendre : vous payez la solution d’édition, mais aussi l’édition et même la diffusion. La plupart des éditeurs vous permettent donc de manipuler du contenu html, avec l’avantage d’avoir une technologie gratuite et puissante, mais vous empêche de publier sous ce format…

L’autre question posée est sur l’évolution des outils. En reprenant Adobe comme exemple, une question se pose : Flash à évolué depuis la CS6 pour produire du contenu normé HTML 5, en plus du format .swf classique, et pas InDesign, qui contient encore des modules qui produisent du .swf, non compatible avec les plateforme mobiles.

Petit apparté : soulignons quand même la responsabilité d’Adobe dans l’abandon généralisé du plugin flash sur les navigateurs mobiles. Leur incapacité à investir pour améliorer leur lecteur de contenu à généré d’énormes coûts de transformation pour les éditeurs de site internet (YouTube par ex, obligé de passer du .flv au .mp4/H264 pour pouvoir rendre lisible les vidéo sur mobile). Même google a abandonné flash sur Android. Relire aussi la lettre ouverte de Steve Jobs au patron de l’époque d’Adobe : sur le site Apple (en anglais) ou ici en français (source ZDNet). Petits extraits :  « Les produits Flash d’Adobe sont 100% propriétaires. Ils sont seulement disponibles chez Adobe qui a toute autorité sur leur développement futur, leur tarification…». Le patron d’Apple aurait traité Flash de « porc bouffeur de CPU » causant « des failles de sécurité » et « faisant planter les Mac ».« (…) Flash n’est plus nécessaire pour regarder un vidéo ou consommer n’importe quel contenu Internet. Et les 200 000 applications de l’App Store prouvent que Flash n’est pas nécessaire à des milliers de développeurs pour créer des applications graphiquement riches, y compris des jeux ». CQFD

Ce constat accablant, réalisé en 2010 (5 ans, une génération dans le domaine du web !) perdure encore et toujours dans InDesign. Les animations disponibles sont toujours au format .swf, et ne sont pas exportables au format html dans un .epub ou un .folio. Pourquoi, en 2015, InDesign n’est pas capable produire intégralement du contenu au format html5 ? La réponse est simple : parce que Adobe ne serait plus capable d’aller chercher les sous dans vos poches. En effet, une mise en page en html5, avec des animation, peut être gratuitement mise en ligne sous forme d’application avec un framework de type PhoneGap , qui au passage est devenu la propriété d’Adobe (tiens, tiens, risquerait-on un jour de voir ce produit open source et libre diparaître car gênant pour Adobe ?). Il est préférable donc pour Adobe de limiter les capacités de son logiciel phare InDesign, le seul qui s’intègre dans un chaîne de production graphique, utilisé par toute les structure de production graphique, mais propose des éléments complémentaires (Edge Animate) pour créer de l’interactivité. La question directement posée à Adobe : verra-t-on un jour InDesign produire du full html5 ? Je pense que l’attitude d’Adobe nous indique grandement une réponse : s’il peuvent vous le faire payer, oui, sinon, c’est non. La non implémentation du plugin DPS dans InDesign indique de manière évidente que le DPS version html n’est pas la priorité d’Adobe. L’export html d’InDesign est indigne d’une solution professionnelle et d’un éditeur comme Adobe, le code généré est ‘merdique’, sans aucun respect des CSS declaré dans le document. L’export ePub n’est pas mieux loti, aucun des export réalisé avec InDesign ne passe les tests de certification epub de l’IDPF. Et pourquoi un plugin InDesign comme In5, parti d’un projet Kickstarter, est capable d’exporter le contenu d’un document InDesign au format html5, y compris les animations, les formulaires, les boutons ? Pourquoi un seul développeur a pu créer cet outils, alors que les équipes de chez Adobe sont à ce jour toujours incapable de créer la capacité dans ID de générer un export correct en html ? Pourquoi Aquafadas est capable d’implémenter des interactions poussée dans un document InDesign, et de les transformer dans un document, alors qu’en DPS on se contente toujours d’objet à état multiple ?

Le html comme solution unique ! Le epub comme sauveur !

Et pourtant, pour vos publications, il existe une solution, majeure, puissante, efficace, gratuite, libre. Le HTML. La version 5 de ce langage est une évolution majeure car elle intègre la quasi totalité des évolutions nécessaires pour les prochaine années. Mais qu’est le html5 ? La HTML5 est un langage de description de page web, qui se compose en réalité de trois ‘langage’ différents : le HTML en version 5, les CSS (Cascading Style Sheet) en version 3, et Javascript.

  • Le HTML ne décrit que la structure sémantique des pages web. Ce langage indique ce qu’est votre page : un paragraphe, un titre, un gras, une image. La mise en forme de cette structure est fixée pa le navigateur web, qui utilise des polices par défaut pour afficher le contenu. L’ensemble de cette structure est chargée à partir d’un serveur, c’est à dire une archive à laquelle vous vous connectez (l’adresse http://www.votrepage.com) et qui vous met à disposition l’ensemble des éléments. Un site internet est page par page, c’est à dire que vous ne pouvez (de manière générale) consulter qu’une page par une page. Les informations qui doivent être conservée d’une page à l’autre (identifiant, caddie, etc) sont conservée par le logiciel vous permettant de lige les pages web, le navigateur, sous forme de cookies (les fameux cookies indiscrets)
  • Le CSS lui décrit la façon dont les pages doivent être affichées : couleur, polices, positionnement des images, mais aussi le comportement des éléments html de manière conditionnelle. C’est en parti la vraie puissance du html, car avec les CSS vous pouvez adapter la même structure (le HTML) de manière totalement différentes selon le support le lecture (tablette ou desktop), ou bien modifier la mise en page complète, sans changer la structure. Par analogie, c’est l’équivalent dans InDesign des styles, de tous les styles. Je vous invite à aller voir ce site qui montre, à partir d’un même contenu html, les possibilités d’usage du CSS.
  • javascript est un langage de programmation qui donne une autre dimension à l’ensemble; Il permet d’animer des éléments des page, de créer des actions et des interaction avec votre système, de rendre votre page utilisable avec des interactions digitales du type tablette, de créer des jeux, des utilitaires, de applications… Javascript, ses évolutions, ses bibliothèques sont la puissance cachée de l’évolution du html5. Il n’y a quasiment aucune limite à ce que l’on peut faire avec. Pour preuve, l’interface d’InDesign utilise en façade Javascript pour faire fonctionner les palettes et les modules.

Ces trois langages sont accompagnés d’autre langages lié au fonctionnement global

  • PHP est un langage situé au niveau du serveur qui permet de générer du code html adapté à l’utilisateur. Si vous voulez par exemple une page html « bonjour toto », c’est le serveur qui en utilisant le PHP appelant une variable contenant le nom toto va générer cette page. Il suffit de changer le contenu de la variable pour générer une page « bonjour Monsieur »
  • Le SQL est le langage de description de la structure de votre page. Il identifie les différente page et permet d’utiliser un base de données, votre archive, votre stock d’information.
  • Le HTTP est le protocole qui va permettre à votre navigateur de trouver votre page dans le net. Il s’agit d’une normalisation d’information.

Pour avoir l’équivalent d’une publication digitale, toutes ces technologies ne sont pas nécéssaire. Tout a été en fait intégré dans un format peu encore développé, le format ePub. Ce format est un dérivé du html qui contient, sous forme d’une archive compressée, un ensemble de fichier structurant le document :

  • le fichier mimetype qui doit nécessairement être placé la racine du projet ;
  • le dossier obligatoire META-INF qui contient le fichier container.xml (éventuellement signatures.xml ou encryption.xml) ;
  • le dossier OEBPS, ou OPS dans les epub de version 3 pour simplifier, qui regroupe :
    – le dossier optionnel Texte (Text) qui contient les fragments html ou xhtml (ce sont vos chapitres),
    – le dossier optionnel Style qui contient la ou les feuilles CSS (par exemple style.css),
    – le dossier optionnel Images s’il y en a,
    – le dossier optionnel Polices (Fonts) si des typographies spécifiques ont été intégrées,
    – le dossier optionnel Divers (Misc) qui contient par exemple des fichiers audio, vidéo ou des fichiers xml spécifiques,
    – le content.opf (où sont entre autres indiqués l’emplacement des fichiers et les métadonnées),
    – le toc.ncx (qui régit la table des matières, la navigation dans le livre).

Il peut arriver que vous ayez d’autres fichiers lorsque vous extrayez votre epub, si par exemple vous l’avez créé avec certains logiciels de PAO offrant des fonctions d’exportation (ces fichiers supplémentaires étant spécifiques à ces logiciels). Ce qui pose un soucis de compatibilité avec les lecteurs, certains pub ne répondant pas à la norme ePub de l’IDPF, http://idpf.org/ tel que le format .ebooks d’Apple ou le format .kindle d’Amazon.

Vers l’infini, et au delà !

Le format ePub est un format d’avenir, en cours de développement, et surtout libre et gratuit, et normé par le W3C et l’IDPF. C’est le format par excellence de publication digitale, et qui est amené à remplacer toutes les solutions propriétaires des éditeurs. Il offre toutes les capacités voulues en termes d’interactions, de navigations, et il est lisible de manière native par la plupart des OS récents. Or la quasi totalité des éditeurs n’ont pas d’export ePub 3 (la dernière norme du format) digne de ce nom, et ne parlons pas du code html et javascript généré. Mais cette situation est amené à évoluer rapidement, une concurrence féroce se mettant en place sur la capacité de produire un format ePub. Adobe n’a pas à ce jour un export propre, surtout en fixed layout (mise en page fixe) mais espérons que les prochaines mise à jours résoudront ce problème.

Mais produire un projet global, que vous managiez une équipe, ou si vous êtes seul, de la création jusqu’à la publication, soulève un certain nombre de contraintes qui sont nécessaire de prendre en compte. D’autre articles seront rédigés pour aborder ces points dans le détails, mais je vais soulever un débat sur lequel d’autre contributeurs d’ElectricNews vont rebondir (les commentaires sont à votre disposition pour faire avancer le débat).

Vous ne pourrez pas, dans le cas d’un projet mené de A à Z, vous passer de ressources incluant la connaissance du HTML, du CSS, de javascript, et pour des projet plus poussés, du PHP, de la gestion des base de données SQL , et de préparer l’avenir avec des évolutions tel que NODE.js.

  • Vous êtes graphiste, D.A., éditeur ? Vous allez avoir besoin de mettre les mains dans le cambouis et de connaître un minimum la structure de ces langages, et de comprendre le fonctionnement global technique des solutions. Aucun logiciel ne peut structurer le code de manière optimisée comme peut le faire un être humain. Vous gagnez du temps en utilisant une interface graphique, mais derrière la structure est mal gérée. A titre d’exemple, le moindre site générée par Muse d’Adobe contient environ 40% de code inutile, notamment dans le gestion des classes et des CSS, et en optimisant le code on peut réduire d’un facteur 3 le code d’un site, et donc diviser aussi par 3 le temps de chargement et augmenter la réactivité d’un site. Et la réactivité est la base même de l’expérience utilisateur.
  • Le debugging fait partie de tout process de création en programmation. Cette partie là est plus ou moins incluse dans la conception des outils intégrés de création web, mais vous serez toujours confronté au cas particulier que le développeur de la solution que vous utilisez n’a pas prévu. Et c’est là que sans connaissance technique, votre projet prendra du retard ou pourra même devenir un échec. Un exemple vécu, un site développé avec un outil Adobe s’est révélé parfaitement illisible sur Internet Explorer 8 (oui, bon…). Une bonne gestion du code aurai permis de prendre en compte dès le début de cette problématique, qui s’est révélé ingérable avec l’outil Adobe.
  • Les bibliothèque de code (jQuery, mode.js, etc…) disponible vous offrent des ressources fantastiques que vous pouvez utiliser comme vous voulez dans vos publications.
  • Coder, c’est gratuit, c’est juste votre travail. Vous ne dépendez que de vous, pas d’un éditeur tiers qui vous impose ses choix ou ses outils. Et l’expérience vous apportera rapidement la capacité de réaliser ce que vous pensiez impossible.
  • Vous n’aurez pas de mauvaise surprise avec des éléments de tracabilité que l’éditeur aura placé subrepticement dans votre site. En effet, Adobe connait tout les chiffres des sites qui sont créé avec leurs outils. Comme Aquafadas. Comme tout les autres
  • Pour finir, vous ne dépendrez plus d’éditeur de solutions qui imposent des choix qui ne sont pas les vôtres.

Il existe en ligne de nombreux cursus de qualité d’aprentissage, et si vous ne vous sentez pas d’être seul face au code, de nombreux centres de formation propose des contenus complet vous permettant de devenir intégrateur ou développeur web.

L’apprentissage du code devient une nécessité avec l’évolution des outils, et nous avons la chance de vivre une période ou les outils du web se sont standardisé et deviennent beaucoup plus simple à utiliser.

Lancez-vous, codez !

Richard Couet

Consultant en solutions de publication digitale - Formateur Expert PAO et DPS

Pin It on Pinterest