Dans une framework orientée Web comme Ruby on Rails ce principe s’applique de plusieurs manières. Prenons le cas des vues, sur Feedbooks, on affiche à plusieurs reprises un livre de la manière suivante:

Au lieu de recopier dans chaque page où j’affiche un livre de cette manière le même bout de code, j’appelle une vue partielle. Comme cela si le lien vers un livre change, il suffit de le changer dans un seul fichier pour que cela s’applique à toutes les pages. C’est un principe qui permet de rendre le code plus concis et lisible mais aussi plus évolutif en général. On l’aura remarqué, c’est un critère essentiellement visuel qui me permet de ne pas avoir à reproduire les lignes de code: visuellement l’information est présentée de la même manière.

Le RDFa (par ici pour ceux qui ont peur à la vue de ce terme) est toujours présenté comme suivant ce même principe DRY.

Dans un sens c’est vrai, si je veux par exemple marquer qu’une information est un titre il me suffit de faire: 

<h1 property="dc:title">Titre</h1>

Je me content de marquer la nature de l’information (dc:title, un titre) et je n’ai pas à ajouter de nouveau le titre dans l’information structurée: on suit bien un principe DRY.

Mais reprenons le cas de mon livre: si visuellement il est toujours présenté de la même manière, avec les mêmes liens, le contexte lui peut être très différent. Je pourrais par exemple l’afficher dans la page des favoris d’un utilisateur, dans une liste de lecture ou comme une recommandation.

Si la représentation visuelle de l’information ne change pas, son sens lui peut être complètement différent et il devient bien plus difficile d’appliquer un principe DRY de cette manière.

J’apprécie beaucoup ce petit schéma venant tout droit du RDFa Primer, et présentant de manière très simple le principe de ce standard: qu’une même information aient du sens pour un humain comme pour une machine. Mais on se heurte rapidement à pas mal de questions sur la manière de mettre tout cela en pratique encore. Maintenant que RDFa est officiellement une recommandation W3C il s’agit de se demander dans quels cas faut-il ou non marquer sémantiquement l’information, quels principes à appliquer lors du développement d’une application sémantique ou encore comment intégrer cette technologie à des frameworks comme RoR ou Django.

Un an de retard pour la France… Alors que l’an dernier Sony dévoilait son PRS-505, celui-ci se décide enfin à arriver en France cette semaine. Pendant ce temps aux USA, Sony présente non pas son remplaçant, mais un nouveau modèle plus alléchant venant complémenter l’offre du constructeur: le Sony PRS-700.

Tactile ou connecté ?

Tout d’abord avant de commencer à décortiquer les nouveautés et les modifications apportées par le PRS-700, je souhaite revenir sur un point: l’absence de connectivité.

Alors qu’on commençait à parler de l’arrivée d’un nouveau modèle, la blogosphère s’entêtait à croire que la principale modification apportée serait une liaison sans-fil assurant à la gamme Sony Reader un équivalent du Whispernet d’Amazon.

Pour un certain nombre de raisons, cela semble contradictoire avec les décisions récentes de Sony mais surtout très difficile à mettre en place:

• le WiFi tout d’abord n’est pas une alternative viable à l’EVDO d’Amazon. Configurer du WiFi sur un tel périphérique est loin d’être idéal et réserverait cette fonctionnalité aux geeks. Le WiFi est aussi particulièrement gourmand et réduirait en conséquence l’autonomie de l’appareil. Mais surtout, en WiFi il n’est pas question de se connecter n’importe où et n’importe quand: il faut forcément être dans un lieu où on a une couverture WiFI.
• Le sans-fil sans rien derrière n’a absolument aucun sens. La force du Kindle c’est de s’intégrer à une plateforme complète de vente en ligne et de gestion d’abonnements. Développer une telle plateforme prend un certain temps (le Kindle est le fruit de nombreuses années de développement, alors que Sony commence à peine à regrouper ses effectifs travaillant sur le Reader).
  L’ajout du DRM d’Adobe depuis la mise à jour du PRS-505 semble aussi aller à l’encontre de cette hypothèse: au lieu de lier l’appareil à un seul magasin en ligne comme c’était le cas avant, Sony ouvre son appareil à une multitude de fournisseurs de contenus. 
• Le WiFi n’étant pas une solution viable, il faut forcément passer par la carte EVDO/3G et dans ce cas de figure, trouver des accords avec des opérateurs. C’est quelque chose de long et fastidieux, surtout étant donné que le modèle du Kindle avec Sprint est à l’opposé du modèle traditionnel des opérateurs, ceux-ci préferant vendre un périphérique à prix réduit lié à un abonnement.
  Pour lancer un produit à l’international, c’est d’autant plus long: il faut négocier pays par pays des accords avec les opérateurs.
• Pourquoi vouloir faire comme Amazon en moins bien ? L’expertise de Sony est sur le matériel, pas les services. Le Kindle souffre d’une image execrable sur le plan design,  autant choisir un moyen facile de se différencier en proposant un produit tactile beaucoup plus sexy.

Moins de boutons

Le premier point qu’on remarque, c’est la disparition des boutons 0-9. Globalement, les boutons sur ce nouveau modèle se font très discrets, avec de gauche à droite: retour, page précédente, page suivante, menu principal, recherche, zoom et “option”.

Disparition donc du bouton que je trouvais le plus utile sur le 500/505, marque-page, au profit d’un bouton recherche. Je trouve ce choix on ne peut plus douteux: pour marquer une page on peut désormais appuyer deux fois dans le coin de la page, mais cela ne remplace en aucun cas une autre possibilité de l’ancien bouton marque-page. En gardant longtemps le bouton appuyé sur le 500/505 on pouvait immédiatement retrouver l’ensemble de ses marque-pages: pour les personnes qui comme moi aiment lire plusieurs ouvrages en parallèle, c’était donc le meilleur moyen de passer d’un ouvrage à l’autre. Pas besoin de passer pas le menu principal et de se ballader dans plusieurs pages, on pouvait en une pression de bouton naviguer d’un ouvrage à l’autre. Certes, effectuer une recherche dans un livre peut s’avérer utile, mais plus utile que de marquer une page et passer facilement d’un ouvrage à un autre ? J’ai quelques doutes là-dessus…

La position des boutons permettant de tourner les pages est encore plus étrange: Sony considère donc que la majorité des utilisateurs se serviront plutôt de l’écran tactile. Pour changer de page, il suffit de faire un mouvement du doigt dans un sens ou dans l’autre, ce qui rend l’appareil utilisable autant pour un gaucher que pour un droitier. Mais est-ce optimal pour une utilisation à une main, peut-on facilement tenir l’appareil et effectuer un mouvement du pouce pour changer de page ? Seule une utilisation prolongée répondra à cette réponse, mais il aurait semblé judicieux de laisser justement ces boutons pour changer de page de part et d’autre de l’écran au cas.

On appréciera pas contre particulièrement la possibilité de “feuilleter”, en gardant le doigt appuyé à la fin du mouvement pour tourner une page, le PRS-700 continue de tourner les pages sans le fameux “flash” noir d’un écran e-ink.

Navigation tactile

La navigation sur un appareil e-ink est toujours un casse-tête: si le taux de rafraichissement n’est pas problématique quand il s’agit de tourner des pages, naviguer dans un menu est une toute autre affaire. Sony utilisait jusqu’à présent les boutons 0-9 pour cette raison la, en présentant toujours 10 éléments à l’écran, alors que le Kindle dispose d’une petite barre LCD permettant d’éviter ces désagréments.

Un écran tactile change forcément la donne: plus besoin des boutons 0-9 pour naviguer et Sony prend donc de nombreuses libertés:

• des icônes faciles à cliquer sur le menu principal
• il n’y a plus qu’une seule option pour naviguer dans ses livres mais on peut changer l’ordre de présentation, ou aller directement à une lettre précise de l’alphabet (iRex avait totalement sous-exploité ce type de fonctionnalités sur l’iLiad alors que justement le tactile présente de gros avantages pour ce type d’interfaces)
• un zoom tactile
• un clavier tactile pour la recherche
• sélection du texte au stylet

Globalement pour tout l’aspect navigation, le PRS-700 semble s’en tirer la tête haute. Mais un écran tactile ce n’est pas simplement utile pour une meilleure navigation, on peut imaginer de nouveaux usages aussi…

Recherche, prise de notes et dictionnaire

Le Kindle brille par sa fonctionnalité de recherche qui va beaucoup plus loin que la recherche dans un ouvrage donné: il embarque en réalité un moteur d’indexation. On peut à tout moment effectuer une recherche pour trouver un ouvrage sur l’appareil (métadonnées), sur Amazon (via Whispernet) mais aussi trouver n’importe quelle occurence dans un texte.

Il n’a pas encore été clairement expliqué comment fonctionnera le PRS-700 sur ce point, j’imagine que la fonctionnalité recherche est probablement limitée à la recherche au sein d’un livre. Pouvoir chercher un livre en fonction de ses métadonnées serait encore mieux, et chercher des occurences dans l’ensemble des textes de l’appareil optimal, mais tout cela à un coût: il faut indexer le contenu, ce qui est gourmand en ressources et diminue l’autonomie de l’appareil.

Côté prise de notes, c’est clairement une déception, d’après les premières impressions, il est impossible d’utiliser le clavier tactile pour des notes. On doit se contenter d’un simple surlignage du texte au stylet. D’ailleurs dans quel format ? Digital Editions support la prise de notes, mais le PRS-700 doit aussi proposer ces fonctionnalités sur des formats comme le LRF et le RTF que DE ne supporte pas. La prise de notes reste techniquement parlant, un véritable casse-tête et l’ancêtre de l’EPUB, l’OEB, avait subit un cuisant échec lorsqu’après plusieurs semaines de travail sur le sujet, aucune solution n’avait été obtenue.

Autre déception: l’absence de dictionnaire. La aussi, pas de format adapté et pas de support pour le moment, ce qui est vraiment dommage: il est beaucoup plus facile de sélectionner un mot sur un écran tactile que sur le Cybook ou le Kindle.

Sony doit donc revoir rapidement sa copie pour véritablement exploiter les avantages d’un écran tactile en dehors de la navigation, mais c’est l’industrie toute entière qui doit avancer sur le support des notes ou des dictionnaires.

Conclusion

Je n’ai pas abordé la question de l’autonomie et c’est volontaire: on ne peut pas s’appuyer sur les chiffres des constructeurs sur ce point. Il est évident que le choix du tactile a des répercussions sur l’autonomie, mais avec 3 semaines d’autonomie, les PRS-505 était le meilleur élève de sa génération. On peut donc s’attendre à quelque chose de tout à fait correct sur le PRS-700 qui gardera le même mode veille.

Globalement, le PRS-700 est un bel objet, même s’il reste bien trop cher (399$) et qu’il sous-exploite ce qu’on peut faire avec un écran tactile.

Depuis maintenant quelques mois, je suis de près ou de loin, les péripéties du Web sémantique, et en particulier, de SearchMonkey, une initiative de Yahoo visant à améliorer la présentation des éléments lors d’une recherche.

Mis à part un redesign de leur élément de présentation, la grande nouvelle c’est l’arrivée du RDFa.

Après seulement quelques minutes de redesign, ça y est, Feedbooks est donc la première application RDFa de SearchMonkey. Un petit pas pour le Web sémantique, mais allant dans le bon sens avec enfin des applications concrètes à la clé.

Màj: http://developer.yahoo.net/blog/archives/2008/09/searchmonkey_su.html

J’ai aussi eu l’occasion de discuter directement avec des membres de l’équipe afin de leur faire quelques suggestions.

Un problème revient très souvent: si j’ai disons, plusieurs éléments marqués avec dc:subject en DublinCore sur ma page, il n’y a aucun moyen d’itérer sur l’ensemble de ceux-ci ou encore d’évaluer le nombre d’éléments disponibles. On ne manipule que des chaînes de caractères, ce qui est loin d’être idéal dans ce cas de figure.

Ma proposition: ajouter un support pour avoir un tableau en sortie (array), élément très facile à manipuler pour ces opérations.

Normalement, c’est ajouté à leur “to-do list”. On verra bien comment cela avance…

La vidéo est commentée en anglais pour le moment, mais c’est promis, j’en ferais une version française dès que possible.

Nous avons récemment modifié la gestion des avatars sur Feedbooks pour supporter les identicons en plus des gravatars. Au lieu d’utiliser deux champs (e-mail/gravatar), nous utilisons désormais l’e-mail associé au compte pour vous assigner votre avatar (gravatar si disponible, sinon identicon).

Qu’est ce qu’un gravatar ?

Gravatar signifie “globally recognizable avatar”. Au lieu de devoir mettre en ligne sur des dizaines de services votre avatar, le principe est d’envoyer une fois pour toute votre avatar sur gravatar.com afin de l’afficher sur l’ensemble des services supportant les gravatars.

De nombreux services emploient déjà cette solution, qui est de plus en plus souvent intégrée par défaut sur les blogs (Wordpress par exemple).

Qu’est ce qu’un identicon ?

A défaut d’un gravatar, nous utilisons un identicon pour vous identifier. Un identicon est un avatar généré en utilisant votre adresse e-mail.

Avec un million de fichiers ePub distribués sur Feedbooks et les grands groupes d’édition qui s’y mettent, il est plus que jamais indispensable d’avoir une vision critique sur le standard afin de le faire avancer.

Quelques éléments qui méritent d’approfondir cette question…

OPF et images

Pour reprendre les définitions de la spécification OPS, on distingue:

OPS CONTENT DOCUMENT

An XHTML, DTBook, or Out-Of-Line XML Island that conforms to this specification that may legally appear in an OPF Package Document spine element.

OPS CORE MEDIA TYPE

A MIME media type that all Reading Systems must support.

Dans un fichier ePub, on utilise en réalité une multitude de documents inclus dans un conteneur. Pour constituer le document ePub, on précise un ordre de lecture via l’élément spine du fichier OPF (Open Packaging Format, où on décrit les métadonnées et la composition du fichier).

Pour composer le document, on a uniquement le droit de se servir d’OPS Content Documents (à savoir du XHTML, DTBook, ou XML avec sa feuille de style). Alors que tout système de lecture conforme ePub est capable de lire l’ensemble des OPS Core Media Types (comprenant des formats d’images comme le PNG, JPEG, SVG ou GIF), on ne peut pas utiliser ces fichiers directement pour composer son document.

Qu’est ce que cela implique ?

Prenons le cas de la BD. A priori, le format ePub est parfaitement adapté à ce support: on peut mettre dans le conteneur toutes les images, définir leur ordre de lecture et une table des matières.
Mais étant donné qu’on a pas le droit d’utiliser directement des OPS Core Media (les images ici) pour composer son document, pour chaque image il est obligatoire de créer un fichier XHTML uniquement pour afficher une image. Autant dire que c’est particulièrement inutile d’utiliser du XHTML dans ce cas, sans parler des problèmes inhérents au CSS par défaut: si on n’applique pas aussi du CSS pour chacun de ces flux XHTML, on se retrouve avec des marges inutiles pour une image, ainsi qu’une image qui n’est pas centrée.

Le problème est encore plus délicat en ce qui concerne la couverture d’un livre. A l’heure actuelle, il n’y a aucun élément dans les métadonnées pour pointer vers la couverture (certes en DublinCore non qualifié ce n’est pas évident, mais le groupe de travail sur l’OPF ayant justement étendu le DublinCore pour qualifier certains éléments, pourquoi ne pas avoir abordé ce point ?).
Vu qu’il n’est pas possible non plus de directement composer son document avec une image, on se retrouve obligé de devoir définir un flux XHTML.
Mais les complications ne s’arrêtent pas la: cette fois ci la faute en revient à DE. Etant donné que celui-ci considère la page XHTML comme n’importe quelle page plutôt que comme une couverture, il n’étire pas l’image si on utilise pas un format vectoriel.
Ainsi, dans la majorité des fichiers que j’ai pu observer non seulement, la couverture est un document XHTML, mais le plus souvent, c’est un fichier image non vectoriel, qui est inclus dans un SVG (vectoriel) avec des propriétés particulières.

Quelle complexité pour quelque chose d’aussi essentiel qu’une couverture !

J’ai eu l’occasion d’en parler avec Jon Noring il y a déjà quelques mois et d’après ses souvenirs, certains membres de l’IDPF avaient de bonnes raisons de n’accepter que les OPS Content Document dans la composition du document. J’aimerais bien les connaître, car en l’état, cette limitation semble totalement absurde et pousse à une complexité artificielle.

Restitution Vs. Flexibilité

Un autre point qui me saute aux yeux: l’utilisation quasi systématique dans les fichiers commerciaux de polices embarquées. Ainsi chez Penguin, le corps du texte principal utilise une police qui se trouve dans le fichier principal. Je comprend tout à fait ce en quoi c’est une chose que l’éditeur apprécie: on peut reproduire la présentation du livre papier et différencier des ouvrages qui seraient rapidement génériques quand à leur présentation.

Il y a plusieurs problèmes néanmoins quand on utilise systématiquement des polices de caractères embarquées pour l’ensemble du texte. Un problème de vitesse tout d’abord: ces fichiers sont plus lents à s’afficher globalement. Chaque page qu’on tourne prend un peu plus de temps à s’afficher, ce qu’on discerne à peine sur un ordinateur de bureau mais nettement plus sur un périphérique mobile. Ensuite il y a un problème de taille des fichiers. Si j’ai sur mon lecteur 20 livres de chez Penguin utilisant tous la même police embarquée, je vais me retrouver avec 20 fois la même police. Les polices sont assez gourmandes en terme de taille et peuvent facilement doubler la taille d’un fichier. Certes, au lieu d’embarquer des milliers de livres, cela me limitera à quelques centaines d’ouvrages, mais c’est tout de même un gaspillage d’espace disque.

Mais l’essentiel du problème est d’un autre ordre: on se retrouve dans une position où la volonté de restitution de l’oeuvre de l’éditeur rentre en conflit avec la volonté de personnalisation du lecteur.
Un des principaux attraits du Cybook Gen 3 de Bookeen est lié à sa capacité à embarquer les polices que l’on souhaite. Ainsi si plutôt que du Times, je souhaite utiliser du New Century Schoolbook ou du Garamond, pas de problème, je peux changer de police pour l’ensemble du texte.
A partir du moment où l’éditeur définit l’utilisation d’une police embarquée pour l’ensemble du texte, au lieu d’une utilisation pour des passages particuliers demandant une mise en forme précise (une lettre par exemple), il devient très complexe pour le système de lecture de faire la part des choses. Quand doit-il utiliser la police demandée par le lecteur à la place de celle précisée par l’éditeur ?

Cette question d’ailleurs dépasse largement le cadre des polices embarquées, et touche aussi à la mise en forme CSS ou XPGT. Il faut introduire un élément qui est nouveau pour le monde de l’édition: contrairement au livre papier, l’éditeur ne doit pas imposer sa présentation, sa mise en forme. Il faut trouver un nouvel équilibre entre les éléments que l’éditeur considère comme devant absolument être mis en forme à sa manière, et ceux où il faut laisser un degrès de liberté pour le lecteur.
Plus que des considérations techniques, ce qu’on bouscule c’est la manière de penser la présentation du livre. C’est un passage qui risque d’être très difficile pour le monde de l’édition, mais il est indispensable de se poser les bonnes questions et de mettre en place un ensemble de bonnes pratiques pour ne pas frustrer le lecteur, et lui retirer toute une dimension de liberté supplémentaire, qui n’existait pas sur support papier.

Typographie

Restituer l’expérience papier peut tout de même se faire sans marcher sur les pieds de l’utilisateur dans certains cas, à condition d’adopter certaines pratiques. Plutôt que de vouloir imposer leurs préférences, le monde de l’édition doit pousser l’IDPF à aller de l’avant. Je note en particulier choses qui manquent au standard:

• césure des mots
• contrôle de l’affichage sur la page

C’est sans aucun doute la sortie de Stanza qui a vraiment permis au format de décoller, et la lecture sur iPhone se porte très bien à en croire le classement de l’AppStore français étant donné que Stanza ne décroche plus du top 50 des applications gratuites les plus populaires (il est même monté dans le top 20 lors de la dernière mise à jour).

Petit retour sur le lancement du magasin en ligne de Waterstone et sur ce qui fait défaut ou mérite encore réflexion concernant ce standard dans les prochains jours.

Nous avons récemment ajoutés des vidéos sur la page d’aide pour l’iPhone ainsi que pour le Kindle.

La démo iPhone présente Stanza, son utilisation pour la lecture et le téléchargement de contenu depuis Feedbooks.

Pour le Kinde c’est notre guide qui est à l’honneur avec un tutoriel complet pour apprendre à s’en servir. Utile pour les francophones vivant aux USA ?

Un grand merci à Marc de Lexcycle pour la réalisation de ces deux vidéos.