Profile

Cover photo
Hadrien Gardeur
Lives in Paris
665 followers|59,137 views
AboutPosts

Stream

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: http://www.aldiko.com/blog/aldiko-3-0-is-here
3
2
Kang Lu's profile photoOlivier Guéry's profile photoNicolas Robaux's profile photo
 
Hé, hé, on va tester ça :)
 ·  Translate
Add a comment...

Hadrien Gardeur

General Discussion  - 
 
New design pattern for slide menu/navigation drawer on Android.

I'm not a fan at all. I like the fact that Google is standardizing this pattern, but I don't like the results.

Of all the Google apps I know, Youtube has the best navigation drawer.

In Play Music or Play Books, you can't make the menu appear by swiping from the middle of the screen.
You need to be close from the edge of the screen or tap the new icon.

The icon itself looks weird. I don't like the fact that it lacks a margin with the left border of the screen. It's also hard to figure out that this is a menu icon.

In Play Books and Play Music, one of the recommendations is not followed:
"Remove actions from the action bar that are contextual to the underlying view (such as Create new, Refresh). You may retain actions with global scope, such as “Search”."
If I open the menu, it doesn't always show the icon, doesn't show the app name, and none of the actions are hidden.

I also don't like the fact that it overlays the current screen, instead of making everything slide to the right. This looks particularly bad in Play Music, where some of the screens have translucid action bars.
When everything slides (like the current G+ or Youtube apps), it "feels" like I'm directly interacting with the screen. I can literally move the content of the screen, like I would with an object in the real world.
That's not the case when you overlay the menu, which is made even worse by the fact that I have to swipe from the edge of the screen.
Overlays work for OS-wide actions (such as notifications) where you want to draw something on top of the current application. It doesn't work nearly as well within the context of an application.
 
Very happy to announce a new design pattern for the Android Design Guide: The Navigation Drawer.

Navigation drawers have been a community-driven pattern for a while. We have now formalized its use on the Android platform with a new chapter in the official Android Design Guide. If you're interested in using this pattern in your app, or want to update your existing drawer to match best practices and recommendations, head on over and take a look.
10
1
guillaume palayer's profile photoKyle Smaagard's profile photoHadrien Gardeur's profile photoAdam Powell's profile photo
13 comments
 
On the other hand, Play Music just fixed most of what felt wrong about its implementation of this new pattern. 
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" (https://plus.google.com/u/0/107252663012827113536/posts/VGruSpVbd5n) 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.
9
5
J-P Losier's profile photoHadrien Gardeur's profile photo
6 comments
 
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.
1
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 (http://developer.android.com/design/index.html) 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.

Bookshelf

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 (http://developer.android.com/design/patterns/actionbar.html).
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 (http://developer.android.com/design/patterns/navigation.html).

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 (http://developer.android.com/design/building-blocks/spinners.html).
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.
4
1
Hadrien Gardeur's profile photoKevin Wu's profile photoAlex Kuiper's profile photo
4 comments
 
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...
Have him in circles
665 people

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  
2
1
Olivier Nyssen's profile photoHadrien Gardeur's profile photoSameer Verma's profile photoJulieta Lionetti's profile photo
6 comments
 
J'ai ajouté un lien dans le wiki Tizen https://wiki.tizen.org/wiki/Application_Development
 ·  Translate
Add a comment...

Hadrien Gardeur

Shared publicly  - 
 
Just posted my comment to Dave Cramer's post about a lightweight version of EPUB.
1
1
Add a comment...

Hadrien Gardeur

Shared publicly  - 
3
Olivier Guéry's profile photoHadrien Gardeur's profile photo
5 comments
 
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" : http://idpf.org/epub-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.
6
4
Hervé Bienvault's profile photoNicolas Robaux's profile photo
2 comments
 
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  - 
 
Translated a recent presentation about OPDS
6
2
Créatnum's profile photo
 
toujours aussi clair !
 ·  Translate
Add a comment...
People
Have him in circles
665 people
Work
Occupation
Entrepreneur
Basic Information
Gender
Male
Birthday
February 1
Story
Tagline
Entrepreneur, Tea Addict & Music Geek
Introduction
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
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Paris
Links
Contributor to