Cover photo
Hadrien Gardeur
Lives in Paris
715 followers|94,682 views


Hadrien Gardeur

Shared publicly  - 
Aldiko 3.0 has a great new Holo design and truly feels like the first next generation OPDS client.
I'll do a full post here about why this is a major step forward for OPDS.
Aldiko 3.0 is here! The Adiko 3.0 is a re-imagined version of the Aldiko Book Reader. It's built on a modern design, following closely the design guidelines of Holo. It features a whole new user interface, great catalog integration and easy and powerful library organization for users with lots of books. More details:
Olivier Guéry's profile photoKang Lu's profile photoNicolas Robaux's profile photo
Hé, hé, on va tester ça :)
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Just posted my comment to Dave Cramer's post about a lightweight version of EPUB.
J-P Losier's profile photo
Add a comment...

Hadrien Gardeur

Shared publicly  - 

Update 1: I've added a new screenshot, this time on a large (> 7") tablet. It's an example of how faceted browsing might work.

A modern OPDS client

OPDS 1.2 is almost ready and could be easily released in a matter of days. But as I looked back at the state of the current OPDS clients, something hit me : none of them even support OPDS 1.1 properly, and they're all stuck in the days of Stanza on the iPhone 3G in terms of user experience.

I decided to start a list of features and popular clients in order to test them one by one. This work is still on-going, but it's not enough on its own to push the ecosystem forward. A compatibility list and a full way to test a client are both useful things to have, but to build truly modern OPDS clients we need the big picture, an idea of what we should expect from such software in 2012 and beyond.

UX on smartphones/tablets has considerably improved over the last few years, and an OPDS client could leverage a lot of that to craft a truly wonderful experience.

A modern OPDS client should be fun to explore

Recently both Android with its Holo theme in Android 4.0 and Windows 8 with its Metro UI introduced brand new user interfaces, with a focus on simplicity and UI elements that invite the user to swipe everywhere and explore.

Unfortunately, most of the current OPDS clients are stuck with non-standard UI elements and display OPDS catalogs as a boring list of links to click, instead of a graphic heavy, touch friendly place to discover brand new content.

While it is technically true, that there's a clear distinction between navigation and content in OPDS, it doesn't mean that the user should be stuck with 5 screens in a row displaying just a bunch of text links before they finally see the goods.
OPDS is designed around links and semantics associated to those links. The main menu of an OPDS catalog (its first navigation feed, at the root of the catalog) doesn't have to be boring: it can include links to featured books, lists of all kinds and new releases. Such links can easily be identified by an OPDS client, and their content displayed directly next to the core navigation of the catalog.

Content should always be a swipe away from navigation, and using such techniques, content providers can craft great experiences where they curate the content and group them in a way that makes sense and is easy enough to explore.

A modern OPDS client should go beyond OPDS as a catalog format

About a year ago, I wrote a post called "A new modular approach to ebook distribution" ( which introduced the idea of using callbacks and shelves/subscriptions separately from a catalog.

While OPDS was initially created as a format to browse, search and acquire content, it has outgrown its definition as a "catalog format" almost two years ago when we included the concept of a "shelf" in the 1.0 version of the specification.

A modern OPDS client should support both callbacks and shelves: they would both dramatically increase its usefulness, and would help to connect OPDS to the real world.

Imagine walking into a museum, that offers a free ebook guide for its current exhibit. 
The visitor would walk into the museum and through several means (could be a NFC tag, a QR code, a webpage on the museum's wifi, in an app that geolocalized the device) could obtain an OPDS callback. 
Callback is a complicated words to describe a message that contains a bunch of links and metadata. Instantly, the OPDS client would download the free ebook and would offer the user to add a full catalog where several other resources are available: videos, an audio tour of the exhibit or other ebooks from the museum store. That's the power of an OPDS callback: it's meant to open doors for you, a simple click and you get both your download and cool new resources to explore.

In a similar fashion, shelves are meant to simplify your experience. The first time that you buy an ebook from a retailer, you could get an OPDS callback that contains both your title and a link to your brand new shelf. From that moment on, any new purchase would show up instantly on your device and since OPDS is all about openness, this would extend to several sources at the same time: your favorite bookstore, your university's library or a book club for example.

A modern OPDS client should help you find what you want

Most of the so-called application store do a terrible job at discovery. It was recently announced than on Apple's AppStore for example, close to half a million apps have almost next to zero downloads.
Browsing through a catalog with hundreds of thousands of items is next to impossible, even on a large screen, if you don't offer the right tools.
Facets are designed exactly for that goal, to drill down into a catalog and apply criterias that will help you find what you want.

Let's say that you'd like to visit Paris. A search for the keyword "Paris" or even "Paris guide" might return a lot of unwanted results. Good faceted search, can easily help in such cases and offer the user to limit the search to certain categories (Travel guides), price range (under 5$) and formats (EPUB).

Without facets, we're stuck with browsing though pages and pages of content, unable to drill down into a catalog.

A modern OPDS client should be an open door to explore new things

Some of the current crop of OPDS clients makes it fairly easy to add new catalogs to explore: just click on a link that starts with opds:// and you can start exploring.
But most of them still limit the ease of adding new catalogs, and most of the time you end up having to enter a URL manually or limit yourself to the preloaded choices.

I believe that we can do better than that and make it completely seamless to discover and add new catalogs to explore.
Callbacks that would add a new catalog would be a good start, but the current OPDS specification allows a lot more than that. New catalogs could be discovered as you browse the Web (included in HTTP headers or in a webpage), specialized guides could list interesting catalogs and geo-aware OPDS clients could offer new suggestions as you visite a new place.

User added catalogs should be treated exactly like the preloaded ones, with the ability for the user to organize their selection however they want.

A modern OPDS client: Android edition

We've worked on a few mockups of what such a client could look like on the Android platform.

These screenshots are just a suggestion of how some of the things detailed in this post might work, and we'll probably try to do something similar for other platforms in the near future.

Each screenshot has a comment that explains how things work, and what makes them different from the current crop of OPDS clients.
Sameer Verma's profile photoBastien Quelen's profile photoNicolas Robaux's profile photoClaudia Doppioslash's profile photo
Just wanted to be sure. I understand the reuse.
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Not sure how I feel yet about this new layout. It feels designed for shorter posts and content/link sharing.
This is probably due to how posts are now displayed (like a chat).

I previously used Google+ strictly for longer posts (almost as a replacement for a blog) and presentations (the image viewer worked great for that). We'll see if there's a good fit or not for this redesign.
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Translated a recent presentation about OPDS
Créatnum's profile photoMilad Khajavi's profile photo
toujours aussi clair !
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Kobo et la FNAC ne vendent pas de l'EPUB

Depuis quelques jours, les bruits circulent sur la toile vis à vis de nombreux problèmes de compatibilité sur les fichiers EPUB vendus par Kobo et donc par la FNAC.

En vrac, pour ne donner que deux exemples:

Les problèmes notés sont graves, et concernent potentiellement quasi l'ensemble des lecteurs EPUB (en dehors de ceux de Kobo).
Pour l'utilisateur les effets sont:
- une police beaucoup trop grandes et dont on ne peut pas changer la taille
- des interlignages trop importants
- absence de marge

Bref une expérience de lecture dégradée qui rend le fichier quasi inutilisable sur un lecteur concurrent.

Côté code

Il suffit d'ouvrir un des titres pour comprendre l'étendue du problème:
- ajout d'un kobo.css qui écrase des propriétés du CSS éditeur et insiste en plus via l'utilisation de "!important"
- ajout de "kobostylehacks" dans les headers HTML
- ajout de Javascript
- pas de déclaration des ajouts CSS et JS dans l'OPF

Bref, ces fichiers ne sont pas des fichiers EPUB valides (entre autre à cause des ressources non déclarées dans l'OPF) et semblent "bidouillés" par Kobo pour leurs propres lecteurs, excluant au passage tout le reste du marché.

On remarquera qu'à aucun moment, ni la FNAC ni Kobo n'indique que leurs fichiers sont en fait modifiés, leurs sites respectifs ne parlant que d'EPUB (et non de KEPUB, voir plus bas).

KEPUB et non EPUB ? EPUB3 ?

Mobileread dispose d'une page intéressante présentant le "KEPUB":

A première vue, il ne s'agit pas du problème rencontré ici, mais plutôt de leur propre DRM ainsi que d'une base SQLite.

La page indique quand même au passage que:
"Kobobookstores can also sell standard ePub books which can be read on any device that supports ePub. The user will need to ensure which formats are available for a particular book."

Il appartient donc à l'utilisateur de vérifier si chaque livre est disponible en EPUB ?

En France, la réaction de la FNAC est un peu différente:
- ils répondent à leurs clients que la FNAC vend bien de l'EPUB, mais de l'EPUB3 et que c'est du coup la faute des autres lecteurs
- ils indiquent que le problème est connu et remboursent systématiquement l'utilisateur
- ils demandent à l'utilisateur de ne plus acheter de titres

Désinformation donc de leur part: EPUB3 n'a rien à voir la dedans, le problème vient du fait des modifications faites par Kobo au niveau du CSS. Simple incompétence ou tentative de désinformation à l'égard des autres lecteurs sur la marché ?

En conclusion

On savait déjà que Amazon ajoutait des DRMs sur les titres sans DRM (, et que leurs titres étaient de moindre qualité étant donné qu'ils s'appuient sur des conversions EPUB vers Mobipocket (

Pour Kobo, on savait qu'ils forcent aussi des DRMs sur les titres sans DRM (!/sebbago/status/147681485221150722). On sait maintenant qu'en plus d'imposer des DRMs, ils rendent les titres inutilisables sur d'autres lecteurs que le leur.

A titre de comparaison, sur Feedbooks:
- on ne force pas de DRM
- on indique clairement si un titre comprend un DRM ou un watermark
- on permet aux utilisateurs de filtrer les titres selon la nature du DRM
- on vend exclusivement de l'EPUB (et non un format propriétaire comme Amazon), sans ajouts de CSS ou autres modifications empêchant l'utilisation sur un autre appareil (contrairement à Kobo/FNAC)

A chacun de choisir sa librairie, mais il est clair que tout le monde ne traite pas le client de la même manière...

Mise à jour

Immatériel vient de publier un billet assez accablant sur les pratiques de Apple/Amazon/Kobo/FNAC vis à vis des DRMs, je vous laisse lire:

01net reprend le sujet sur sa une et confirme le problème:

Les anglo-saxons constatent aussi le même problème:
Olivier Jeulin's profile photoVincy Thomas's profile photoGuillaume RENAUDIE's profile photoPierre Debar's profile photo
Have him in circles
715 people
Julio Cesar Sanchez Narvaez's profile photo
shane parkhill's profile photo
Ankit Goyal's profile photo
Romain Verdier's profile photo
Nicolas Morin (nicomo)'s profile photo
Cart Reed's profile photo
Clémentine Gallot's profile photo
henrique gothic's profile photo
Profulla Sadangi's profile photo

Hadrien Gardeur

Shared publicly  - 
Brand new page for OPDS on Wikipedia with less duplicated information, an example, compatibility for multiple clients and new resources. #opds  
urn:uuid:433a5d6a-0b8c-4933-af65-4ca4f02763eb ...
Hadrien Gardeur's profile photoSameer Verma's profile photoOlivier Nyssen's profile photoJulieta Lionetti's profile photo
J'ai ajouté un lien dans le wiki Tizen
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Olivier Guéry's profile photoHadrien Gardeur's profile photo
Merci ! L'objectif c'est de pousser les clients OPDS à adopter des fonctionnalités plus avancées, et aussi à moderniser leur design.
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Un DRM standard pour le format EPUB ?

+Bill McCoy annonçait clairement depuis quelques mois que l'IDPF souhaitait s'emparer de la question difficile des DRMs, afin de favoriser une solution standard qui permettrait de diminuer la fragmentation actuelle du support EPUB (avec d'une part des titres sans DRM, et de l'autres des fichiers EPUB protégés par ACS4 de Adobe ou Fairplay d'Apple).

En publiant un premier document expliquant les choix retenus pour le moment, on obtient une idée un peu plus clair de ce que pourrait être ce "Lightweight Content Protection" :

Un DRM poids plume ?

Une grosse partie de ce document consiste à décrire ce que l'IDPF propose comme étant une solution DRM souple/légère, en opposition à une solution plus lourde comme celle d'Adobe.

Le raisonnement retenu est le suivant :
- même les solutions les plus complexes et avancées ne garantissent jamais que le contenu ne soit pas piraté, et tout DRM finit pas être cracké
- l'objectif d'un DRM n'est donc pas d'empêcher le piratage, mais plutôt de décourager le partage excessif et systématique des fichiers, en rendant ces opérations un minimum plus contraignantes pour l'usager moyen
- dans de nombreux pays il est de toute façon illégal de supprimer un DRM d'un fichier
- ... ce qui n'est pas le cas de la suppression d'un watermarking (tatouage/filigrane), argument utilisé par l'IDPF pour défendre l'interêt d'un DRM standard vis à vis de ces solutions
- en dehors des usages grand public des DRMs, de nombreuses entreprises auront de toute façon besoin de protéger leurs documents EPUB de la même manière qu'ils le font aujourd'hui avec des fichiers PDF

Une vague impression de déjà vu

La solution retenue par l'IDPF est donc d'utiliser une protection par mot de passe : le document est chiffré en utilisant ce mot de passe en guise de clé de chiffrement symétrique.

Cette solution a comme avantage d'être beaucoup plus simple à implémenter qu'une solution asymétrique comme celle d'Adobe, et surtout de ne pas nécessiter de connexion ou d'un tiers de confiance pouvant à tout moment disparaître, pour que le fichier soit ouvert.

Par contre, on est en droit de se poser de vraies questions sur la facilité à l'usage d'un tel DRM. Que se passe-t-il si j'oublie un mot de passe ? Est-ce vraiment plus facile de devoir retenir un nombre important d'identifiants (chaque libraire ou bibliothèque pouvant demander des identifiants différents) ? Un mot de passe est-il vraiment un plus grand frein qu'un watermark à la diffusion d'un fichier ?

Un autre exemple de DRM nous vient directement en tête: la solution employée par Barnes & Noble, qui se base sur un nom d'utilisateur et un mot de passe (le numéro de carte de crédit du client), qui a d'abord été utilisée pour le format eReader, puis par la suite sur les fichiers EPUB vendus par ce libraire.
Si les détails d'implémentation diffèrent, dans l'idée on est tout de même très proche de l'objectif de l'IDPF.

Ce que beaucoup de monde ignore, c'est que la solution d'Abobe (ACS4+RMSDK) est capable de supporter le DRM de Barnes & Noble depuis plusieurs versions maintenant, même si mis à part Barnes & Noble, aucun libraire ou distributeur n'utilise cette option. Etant donné qu'il faut absolument une version relativement récente de RMSDK sur son système de lecture, personne n'a fait le pas pour le moment en dehors de B&N: ce serait fermer la porte aux utilisateurs de périphériques plus anciens (les précédentes générations des liseuses de Sony ou de Bookeen par exemple).

Trop tard ? Pourquoi préférer une solution DRM au watermarking ?

Le cas du DRM de Barnes & Noble illustre bien les obstacles auxquels cette solution DRM devra se confronter : il est très difficile de faire évoluer un parc de machines vers une nouvelle solution DRM. Même si l'IDPF accouche en 2012 d'une spécification en plus d'un document d'intention, il faudra attendre un certain temps avant de voir arriver les premières implémentations. Idéalement, cette question aurait du être abordée en 2007 lors de la publication d'EPUB 2.0, ce qui aurait permis à Adobe et B&N de potentiellement adopter celle-ci, et non leur solution propriétaire.

Etant donné que d'une part, les utilisateurs possèdent des périphériques qui ne supporteront probablement jamais ce DRM, et de l'autre que leur bibliothèque est constituée de fichiers protégés par une des solutions propriétaires actuelles (Adobe, Apple ou B&N), il faudra certainement plusieurs années avant que cette solution DRM devienne véritablement utile. En attendant, les acteurs de la chaîne du livre (éditeurs, distributeurs, libraires et systèmes de lecture) resteront dépendants des solutions d'Adobe (70k$ par an pour une licence RMSDK, 10k$ pour ACS4 ainsi qu'un coût par transaction) pendant de nombreuses années, le temps que la transition s'opère.

Cette initiative de l'IDPF représente certes un vrai pas en avant, mais il est déjà trop tard pour que celle-ci vienne vraiment résoudre le sac de noeud actuel, et si on veut favoriser un vrai marché ouvert, le watermarking reste une solutions bien plus efficace.
Ce qui n'empêche en aucun cas de soutenir l'IDPF dans leurs efforts en la matière : à défaut d'une vraie alternative pour le consommateur, nous avons besoin d'une moyen simple de protéger un fichier EPUB par mot de passe pour certains des usages décrits par ce document (échange de fichier EPUB entre deux entreprises par exemple).

En dehors des arguments habituels qui viennent sur la table quand on débat de la question des DRMs (complexité d'utilisation pour les utilisateurs, inefficacité face au piratage, coûts importants, favorise l'émergence de plateformes qui limitent la portabilité et les usages), le coût le plus important reste celui de l'innovation. Si au lieu d'être limité par un plus petit dénominateur technologique commun (la solution RMSDK d'Adobe), nos périphériques et nos logiciels s'appuyaient sur des moteurs de rendus Web modernes (que ce soit Webkit, Gecko, Presto ou Trident), on pourrait continuer de tirer par le haut l'innovation: que ce soit par un meilleur support du format EPUB 3.0 ou en réinventant nos modes de lecture. Faire le choix d'abandonner les DRMs, c'est aussi faire ce pari d'un véritable écosystème, où l'innovation serait moins bridée par une main mise d'un ou deux acteurs sur le domaine.
Prepared for IDPF by Bill Rosenblatt, GiantSteps Media Technology Strategies (edited by IDPF mgmt.) Publication Date: May 18, 2012. Introduction. This document is an initial statement of requirements ...
Annabelle PELNIER's profile photoAdrien Sebbane's profile photoNicolas Robaux's profile photoyann Trocheris's profile photo
Merci, une fois de plus, pour cette très instructive analyse. Tu devrais en écrire plus souvent !
Sinon, la question du chiffrement entre entreprises peut tout à fait se résoudre sans faire appel à un mécanisme de DRM : il existe déjà des tonnes de façon de chiffrer un fichier, de façon fiable, ouverte et contrôlée par la communauté (les premières idées qui me viennent : les archives .7z chiffrées, truecrypt, le chiffrement de fichiers avec GnuPG, etc…). En matière de sécurité, je préfère d’ailleurs mille fois chiffrer un PDF avec GnuPG qu’avec la solution boîte-noire d’Adobe…
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Designing for Android 4.0

For the last three months, I've been running ICS on my phone. While it really represents a huge step forward in terms of design and user experience for Android, very few apps have been updated yet to fully embrace these new best practices.

Based on the Android Design Guidelines ( and my own experience with ICS, I've decided to start a little project of my own: taking a popular Android 2.x app, and creating mockups of its Android 4.x equivalent.
With over 5 million users, +Aldiko is one of the most popular reading application on Android, and the perfect target for this exercise.

Keep in mind that my Photoshop skills are incredibly bad, and these screenshots don't represent anything final at all.
This whole project is about thinking out loud how an Android 4.0 application should behave, and how Android devs might redesign their own apps in the future.

I'll update this post after each new screen is posted.


Aldiko's bookshelf is what people would associate the most with this app. It was adopted before Apple released their own iBooks app.

For this first screen, I mostly spent time redesigning the top of the screen.

Android 3.x introduced an UI element called the action bar (
I adopted the dark holo theme for this action bar (it's also available in white).
Unlike the 2.x app with its brown gradient, in ICS the action bar is never displayed using a gradient and no separators are displayed between the actions.

In the upper left corner of the action bar, the icon of the application is displayed instead of a home button.
The "Up" caret displayed next to the icon means that this is not the top-level element of the application.
"Up" is an important navigation element in ICS (

For the text ("Bibliothèque" means "Bookshelf" in France), I adopted the new convention: left alignment and Roboto for the typeface.

Instead of a basic text element, I decided to turn the text into a spinner (
The 2.x version displayed a non-standard button on the shelf itself to re-order books.
Using a spinner to re-order books make much more sense here. The user would instantly recognize the element as a spinner due to the triangle, and this use case fits the guidelines for spinners in the action bar ("Spinners are useful when changing the view is important to your app, but not necessarily a frequent occurrence").

The "action overflow" element (three dots in the upper right corner), where we display all the actions that used to be displayed using the menu hardware button is now displayed in the action bar. On a device with hardware buttons, this action could be hidden.

Finally, while the bookshelf with its faux-wood looks is really popular with users, it feels too skeuomorphic for ICS. This is more in line with what Apple does on iOS. An alternate option, with more minimalistic looks might fit better with the Android guidelines.
Kevin Wu's profile photoHadrien Gardeur's profile photoAlex Kuiper's profile photoKang Lu's profile photo
I'm interestied to see where this goes... I develop PageTurer, an open source e-reader, and I haven't used the action bar so far. I think it's time to enter the ICS era though, so I hope you don't mind if I steal some of your ideas :)
Add a comment...

Hadrien Gardeur

Shared publicly  - 
Nouvelle présentation en français pour expliquer les fondamentaux d'OPDS. Volontairement non technique mais assez abstrait afin de pouvoir pleinement saisir les concepts clés.
 ·  Translate
Patrick M. Lozeau (pmlozeau)'s profile photoMarin Dacos's profile photo
Add a comment...
Have him in circles
715 people
Julio Cesar Sanchez Narvaez's profile photo
shane parkhill's profile photo
Ankit Goyal's profile photo
Romain Verdier's profile photo
Nicolas Morin (nicomo)'s profile photo
Cart Reed's profile photo
Clémentine Gallot's profile photo
henrique gothic's profile photo
Profulla Sadangi's profile photo
Basic Information
February 1
Entrepreneur, Tea Addict & Music Geek
I'm the co-founder of Feedbooks, and as an engineer and entrepreneur, my goal is to contibute to the Open Web through standards for digital reading.
Bragging rights
Created the first EPUB files (widely adopted standard for ebooks) on the Web
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Contributor to