Rétrospectivement, les questions que nous nous posions il y a 5 ans quand il était question de concevoir une interface étaient plutôt triviales : « Quelle largeur d’écran ?« , « Faut-il souligner les liens ou non ?« … Il faut dire qu’à l’époque, le web se consommait quasiment exclusivement au travers d’un ordinateur. Nous sommes maintenant en 2011 et la situation s’est nettement complexifiée avec la montée en puissance des smartphones et des touchbooks. Et comme si ça n’était pas assez, certains commencent déjà à anticiper l’arrivée des TV connectées.

La conception multi-écran est donc de nouveau sur le devant de la scène avec la dernière Alertbox : Transmedia Design for the 3 Screens. Le Dr Nielsen nous y explique que si les smartphones sont en train de dominer les usages, les tâches à valeur ajoutée seront toujours réalisées sur un ordinateur (achat en ligne, déclaration d’impôts, choix d’une voiture…). Il convient donc de ne négliger aucun de ces deux formats (ordinateur et smartphone), voir de commencer à réfléchir aux prochains formats (touchbooks, TV connectées…). La recommandation du Dr est comme toujours très consensuelle : Développer des interfaces distinctes, mais conserver la même expérience utilisateur (mêmes codes visuels, fonctionnalités et contenus similaires…). Précisions que cette Alertbox fait écho à un précédent article publié dans UX Magazine : UX Concerns Across Mobile Platforms.

Dans la pratique, vous vous doutez bien que la mise en oeuvre est plus complexe. Je vous propose pour celà d’étudier deux approches. Il y a tout d’abord celle d’Amazon qui fait le pari d’une nouvelle version de son site web qui soit adaptée au format touchbooks : Amazon is testing a slick new site design, built with tablets in mind.

Un choix de conception plutôt audacieux, même si le risque est minimisé par l’ancienneté des clients qui de toute façon retrouveront leurs marques. Il n’empêche que c’est à ma connaissance la première initiative de ce genre pour un site à très large audience. Précisons qu’Amazon édite également d’autres interfaces comme Windowshop, une version mobile ainsi que des applications mobiles.

Deuxième exemple avec Google qui propose des versions mobiles « universelles » de ses sites, mais également une toute nouvelle application iPad marchande : Google Catalogs.

De même, ils avaient lancé l’année dernière une version minimaliste de YouTube (Leanback) pour rendre la consultation plus agréable sur touchbook (ou sur TV) : YouTube Leanback offers effortless viewing.

En étudiant ces différents exemples, il apparait donc comme évident que l’interface universelle est une arlésienne, surtout avec la multiplication des formats (cf. Panorama des terminaux alternatifs). Ceci étant dit, il faut tout de même trouver une solution. Je préconise donc un compromis avec une interface web adaptable (cf. 4 feuilles de styles pour 4 expériences de lecture) et des interfaces spécifiques à chaque format / terminal pour une meilleure expérience (des applications payantes ou avec un accès par abonnement).

Dans tous les cas de figure, le plus important n’est pas de se focaliser sur les interfaces (car les formats vont se multiplier et évoluer), mais sur ce qu’il y a derrière : Le middle-office permettant de délivrer le contenu et les fonctionnalités. À partir du moment où vous avez une architecture « propre » qui dissocie le fond de la forme, vous pouvez petit à petit déployer des interfaces en fonction de l’évolution du marché.

J’ai déjà plusieurs occasions de vous parler des design pattern library (Vive les librairies de modèles de conception d’interfaces et Et on reparle des bibliothèques de modèles de conception), par contre je n’avais jamais abordé les librairies qui concernent les interfaces mobiles. Un manquement impardonnable tant le sujet est chaud (Pourquoi iOS est plus disruptif que vous ne le pensez) et le besoin est pressant (2011, l’année du point de bascule).

Je vous propose donc ce matin de découvrir plusieurs sources d’inspiration pour concevoir vos interfaces mobiles, principalement des interfaces d’applications pour smartphones. Commençons avec Mobile Patterns, une collection d’interfaces mobiles réparties dans une quinzaine de catégories :

Il y a ensuite Pttrns qui propose un équivalent, mais avec une trentaine de catégories :

Il y a enfin LovelyUI qui propose moins de catégories, mais un système de tags bien pratique :

Il existe d’autres sources, mais ces trois bibliothèques devraient vous fournir tout ce dont vous avez besoin pour avoir une vue synthétique des meilleurs pratiques de conception d’interfaces mobiles. Ces bibliothèques présentent l’avantage de classer les interfaces dans des catégories, par contre elles sont très loin d’être exhaustives. C’est pourquoi je vous recommande également Cocoa Controls, une base de référence de l’ensemble des éléments d’interfaces des interfaces Mac (avec une section pour les contrôles iOS). Dans le même style, je peux également vous recommander Android Patterns qui propose une sélection d’éléments d’interface propres au système d’exploitation mobile de Google.

Si vous ne cherchez pas particulièrement des exemples de composants d’interface, simplement l’inspiration, je peux enfin vous proposer quelques collections d’interfaces : CSS iPhone, Make Better Apps, Tap Fency, Refined Mobile Design, Dribbble ou Ember.

Pour finir, si vous avez encore un peu de temps, faites donc un détour par Landing Pad (collection d’interfaces d’applications iPad) et AppSites (collection de sites web d’applications mobiles).

(via UX Movement et Mobile GUI)

Ces derniers temps je parle de plus en plus des terminaux mobiles, et pour cause : ils prennent une place de plus en plus importante dans notre quotidien et surtout dans notre consommation de l’internet (services et contenus). Avec la multiplication des plateformes mobiles et même des formats de terminaux alternatifs, les concepteurs de sites et services en ligne s’arrachent les cheveux pour trouver des solutions à cette fragmentation.

Présentée à la communauté l’année dernière, la technique du Responsive Web Design semble apporter une réponse concrète à la prolifération des formats d’écran. Jusqu’à présent, lorsqu’un internaute visitait un site ayant plusieurs interfaces, il était redirigé vers la version du site qui correspondait le mieux à son mode d’affichage (ex : IMDB.com qui renvoie vers m.IMDB.com si vous le consultez avec un smartphone). Le principe du Responsive Web Design est de ne proposer qu’une seule URL avec une interface qui s’adapte en fonction de votre écran en exploitant différentes feuilles de styles CSS (et les media queries qui peuvent maintenant s’exprimer en largeur de page).

L’exemple ci-dessus vous permet de tester ce principe en redimensionnant la fenêtre de votre navigateur. Ce n’est donc pas qu’une question de largeur de page, mais une nouvelle façon de penser les interfaces web. L’approche de l’auteur (traduction française disponible ici : Le Web Design Réactif) est donc de prévoir à la fois une mise en page qui s’adapte (nombre et largeur des colonnes), mais également des images qui se redimensionnent et même des éléments qui sont repositionnés voir supprimés.

Ce type d’interface demande un minimum d’expertise et surtout un gros travail de préparation en amont pour « penser » une interface en plusieurs largeurs. Il existe heureusement un certain ombre d’article traitant de ce sujet :

• Responsive Web Design: What It Is and How To Use It
• Understanding the Elements of Responsive Web Design
• Les Media Queries CSS3
• The best responsive web design examples and resources

Avec la récente sortie de nouvelles versions de navigateurs (IE9, Firefox 4, Chrome 11, Opera 11…), l’utilisation de ce type de technique va devenir une réalité et évitera de devoir passer par du code javascript et des acrobaties pour assurer une t-rétro-compatibilité.

Encore une fois, c’est un sujet assez technique, mais qui concerne une approche radicalement novatrice dans la distribution de contenus et services en ligne. La plupart des réalisations déjà disponibles concernent des sites de designeurs (visibles sur MediaQueri.es), mais nous commençons à voir des sites de beaucoup plus grosse importance adopter cette technique comme la rubrique Election du Chicago Tribune :

Les exemples listés sur MediaQueri.es sont illustrés en 3 largeurs (smartphones, netbooks/tablettes et ordinateurs) mais peuvent potentiellement s’adapter à n’importe quelle interface (téléphones mobiles, TV connectées, consoles portables…). Je suis particulièrement enthousiaste quant à cette approche de la mise en page d’un site ou service en ligne. D’ailleurs une réécriture du gabarit de ce blog est en cours pour justement exploiter les medias queries. Des explications détaillées seront publiées quand ce nouveau thème sera en ligne.

Voilà maintenant près de 4 ans que l’iPhone a été présenté au grand public, et 4 ans que les concepteurs d’interfaces mobiles se creusent la tête pour pouvoir exploiter au mieux la taille réduite de l’écran. Outre cette contrainte au niveau de la surface utile d’affichage, les applications mobiles ne sont utilisées que de façon intermittente, la prise en main doit donc se faire très rapidement pour ne pas frustrer les utilisateurs (cf. iPhone Apps Need Low Starting Hurdles).

Autant sur un ordinateur et dans le cadre d’une application traditionnelle, les utilisateurs tolèrent de passer un peu de temps à apprendre les fondamentaux de l’interface et la logique de l’application (après tout vous n’installez pas si souvent de nouveaux logiciels sur votre ordinateur). Sur les smartphones, et plus particulièrement l’iPhone, le contexte est différent, car l’utilisation quotidienne est répartie sur une multitude de petites applications. Les utilisateurs d’iPhone sont également amenés à télécharger et installer plusieurs nouvelles applications par semaine (du moins pour les plus assidus). Il est donc inconcevable de leur faire lire un manuel ou de leur imposer une longue séquence d’apprentissage. Les iOS Human Interface Guidelines publiées par Apple sont d’ailleurs très explicites sur la nécessité de se concentrer sur la tâche principale et d’apporter une satisfaction immédiate.

Le blog InspireUX nous propose à ce sujet un très bon article sur les différentes façons de faciliter la compréhension d’une interface et son fonctionnement : Top 6 Help Design Patterns for iPhone Apps. L’auteur a ainsi identifié 6 design patterns :

• Les vidéos de démonstration qui présentent les fonctionnalités principales de l’application. Une solution intéressante, mais coûteuse à produire et frustrante pour les utilisateurs les plus impatients (et ils sont nombreux). Exemple avec l’application Convertbot :

  

• Les tutoriels, généralement présentés écran par écran. Une solution simple et legère, mais qui n’est pas forcément évidente à trouver une fois proposée à l’initialisation de l’application. Exemple avec l’application FLUD :

  

• L’écran aide en sur-impression qui s’affiche sur sollicitation de l’utilisateur. Une solution simple et efficace, mais qui ne convient pas aux interfaces complexes qui nécessitent de longues explications. Exemple avec l’application Pulse News :

  

• Les visites guidées qui proposent une cinématique complète des différents écrans. Une très bonne entrée en matière mais, qui condense l’apprentissage en une seule session. Exemple avec l’application Shopkick :

  

• Les écrans d’aide qui sont associés aux fonctionnalités (« Tips« ). Cette solution permet de fragmenter l’aide et de proposer des explications beaucoup plus courtes et surtout directement en rapport avec l’écran en cours de consultation. Exemple avec l’application Evernote :

  

• Les aides contextuelles qui sont affichées en sur-impression lors de la première visite et disparaissent au bout de quelques secondes. C’est la solution que je préfère car elle fait un très bon usage de la contextualisation, mais ne peut pas délivrer de trop longues explications. Exemple avec l’application Instagram :

  

Voici donc une très belle collection de solutions d’aide et de prise en main pour les smartphones. Je suis intimement convaincu qu’une solution n’est pas forcément meilleure que les autres, car tout dépend de l’application en question (de la richesse de son interface et du nombre de fonctionnalités proposées). Il n’empêche que, comme toujours, le mieux est de combiner les solutions présentées plus haut :

• Une démo avec captures d’écran qui présente l’application dans les grandes lignes. Ce tutoriel est imposé lors de la première ouverture de l’application (avec la possibilité de le sauter) et est facilement accessible sur l’écran d’accueil.
• Des tutoriels qui résument en quelques étapes les fonctionnalités-clés.
• Une aide contextuelle en plein écran qui vient s’afficher en surimpression lorsque l’in clic sur l’icône d’aide (qui est présent sur chacun des écrans).

La démo ainsi que les tutoriels peuvent également servir sur le site web de l’application pour en assurer la promotion et pour nourrir la partie « Support ». Si vous avez de bons exemples d’applications qui combinent ces différentes méthodes, n’hésitez pas à les mentionner dans les commentaires.

La lecture à l’écran est un débat récurent dans le monde de l’utilisabilité. Je n’ai pas l’intention de relancer ce débat ni d’y apporter une contribution significative. Par contre, je rapprocherais les problématiques liées à la lisibilité des contenus web à la montée en puissance des terminaux alternatifs : Vers des sites adaptés aux netbooks ? et De la difficulté de concevoir une interface multi-terminaux.

Le problème que nous essayons de résoudre ici est celui de la lisibilité, ou plutôt de l’adaptation de l’interface au différents contextes de lecture. Il est ainsi difficilement envisageable de concevoir une interface qui convienne à la fois aux utilisateurs d’ordinateurs traditionnels (avec des écrans toujours plus grands), de smartphones, de touchbooks… Il existe pourtant une solution toute simple pour pallier à ces situations : les feuilles de style.

Les CSS sont ainsi parfaitement adaptées à gérer cette problématique. Il serait ainsi tout à fait pertinent de fournir 4 feuilles de styles différentes :

• pour la mise en page du site en mode « web » (donc avec un affichage standard) ;
• pour pouvoir imprimer la page sans tous les éléments parasites (en supprimant les menus et colonnes) ;
• pour pouvoir lire le contenu à l’écran (en proposant uniquement le texte avec une plus grosse police de caractères) ;
• pour pouvoir consulter la page sur un smartphone.

Concernant la version imprimable, il existe quantité d’écrits sur le sujet donc je ne m’attarde pas (CSS Design: Going to Print et How To Create A Simple Print CSS For Your Site). De même pour ce qui concerne la version pour smartphones, il existe des plug-ins et des outils pour faire basculer l’affichage en mode « mobile » (j’utilise par exemple l’extension WPtouch pour WordPress).

Le mode « lecture à l’écran » me semble par contre tout à fiat intéressant à étudier. Il existe déjà des initiatives intéressantes en ce sens (comme le Skimmer du NY Times) mais elles restent marginales. Au mieux, ce que nous proposent les éditeurs pour améliorer le confort de lecture à l’écran est d’augmenter la taille de la police de caractère. Personnellement, je préfère de loin cliquer sur le bouton « Imprimer » et de lire la page d’aperçu avant impression.

Il ne serait pourtant pas très compliqué de proposer un bouton pour basculer en mode « Lecture« . Cette fonction existe ainsi sur le navigateur Safari :

L’avantage des feuilles de styles est de pouvoir exploiter un code HTML unique tout en proposant des expériences de lecture adaptées au contexte. Je suis en train de travailler sur une refonte de ce blog et je vous fournirais des explications détaillées sur les multiples feuilles de styles mises en place dès que ça sera prêt.

Souvenez-vous il y a quelques temps je vous avait parlé de Moblin, un système d’exploitation pour Netbooks sur lequel intel travaillait (Quelle interface pour le système d’exploitation de demain ?). Aujourd’hui ce projet n’existe plus car il a été fusionné avec le projet de système d’exploitation Maemo de Nokia pour être renommé en MeeGo. Vou suivez ? Bon bref, ce que vous devez retenir est que MeeGo ambitionne d’être une plateforme de développement multi-terminaux mobiles, donc qui va pouvoir équiper aussi bien les netbooks, que les smartphones, que les téléphones standards, que les TV, que les ordinateurs de bord de véhicules…

Se pose donc le problème de l’uniformisation de l’interface mais également de l’expérience utilisateur. Une première version pour netbooks a été publiée le mois dernier auprès de la communauté : MeeGo v1.0 Core Software Platform & Netbook User Experience project release. Cette première version reprend les fondamentaux de l’interface de Moblin avec sa barre de tâches en position haute (ils ont rajouté un peu de couleurs) :

Nous avons également vu dernièrement la version pour smartphones faire son apparition : MeeGo for netbooks and smartphones gets Chrome and Fennec. Même si certaines règles semblent communes (le fond sombre pour les icônes du haut d’écran, le flux d’activité…) nous commençons à voir de sérieuses divergences dans l’interface :

Ces divergences sont tout à fait normales car elles sont la conséquence de la prise en compte des contraintes de ces deux types de terminaux. Et ce n’est qu’un début car il va très certainement falloir également tenir compte des spécificités des smartphones eux-mêmes (d’un modèle à l’autre) :

Et finalement cette semaine ont été publiée les premières images de la version touchbook : Pre-alpha MeeGo for tablets demo.

Comme vous pouvez le constater sur la vidéo précédente, l’expérience utilisateur a été complètement repensée pour une manipulation au doigt (donc moins de précision et de clics) où l’on fait défiler les contenus par types de droite à gauche :

Cette page d’accueil me semble tout à fait intéressante mais tranche complètement avec les principes posés pour les autres versions. Il y a également une vue plus traditionnelle avec des icônes sur un bureau et une barre d’applications pour basculer de l’une à l’autre :

Nous sommes ici bien plus proche de l’iOS que du MeeGo pour netbooks. En soit ce n’est pas un drame mais cela illustre bien la difficulté de concevoir une interface suffisamment malléable pour convenir à différents types de terminaux.

Si je ne me trompe pas, l’objectif de MeeGo est avant tout de fournir une plateforme technique stable, mais pas nécessairement une interface unifiée pour l’ensemble des terminaux visés. Certains éléments communs pourraient être conservés (jeux de couleurs, picto et typo, barre d’état…) mais le pari de proposer une interface unique me semble intenable (Microsoft s’y est cassé les dents avec Windows). Attendons de voir s’ils se lancent dans la publication de design guidelines (qui pourraient être très intéressantes)…

MàJ (01/07/2010) : De nouvelles captures d’écrans viennent d’être publiées pour illustrer l’interface de la version smartphones de Meego  : MeeGo Handset Project Day 1 is Here.

Pas de gros changement par rapport à la précédente version mais un réel effort d’épuration de l’interface et une identité visuelle bien marquée (qui diverge toujours des autres versions). (via The Next Web Mobile)

Je termine une série d’articles sur la conception de formulaires avec deux sujets encore non-traités : Les formulaires pour terminaux mobiles et les formulaires narratifs.

Tout ce que vous avez besoin de savoir sur les formulaires mobiles est ici : Forms On Mobile Devices: Modern Solutions. Cet article est en fait un résumé d’une série de billets publiés par Luke Wroblewski sur son blog (Web Form Innovations on Mobile Devices et Better Mobile Form Design). J’ai eu la chance d’entendre ce fameux Luke en conférence lors du MIX et je peux vous assurer que son discours est parfaitement au point.

Dans son article il recommande ainsi d’exploiter au maximum les spécificités des interfaces des terminaux mobiles pour faciliter le travail de saisi dans les formulaires avec :

• La fonction de zoom
  
• L’adaptation du clavier virtuel en fonction du format du champ
  
• L’affichage temporaire du dernier caractère saisi dans un champ de mot de passe
• Les menus contextuels pour la saisie de valeurs numériques
• Les menus spéciaux pour la saisie de données complexes (comme la date ou la taille en pieds / pouces)
  
• L’adaptation de la mise en page en fonction de l’orientation de l’écran
• L’utilisation d’éléments d’interfaces natifs qui sont livrés avec le système d’exploitation
  
• L’utilisation des composants hardware comme le micro, le GPS ou le compas.

Cet article est une véritable perle pour qui veut se lancer dans le développement de sites web adaptés au smartphones. Vous remarquerez que je ne fais pas référence aux applications mobiles ni aux sites web mobiles mais au cas bien particulier des sites web destinés aux smartphones (iPhone, Android, Blackberry, Palm, Windows Phone…). Il y a beaucoup de paramètres à prendre en compte dans ce contexte particulier car les différences de rendus peuvent être spectaculaires (comme en témoigne la dernière capture d’écran).

Si vous connaissez un article sur les meilleures pratiques de conception de formulaires pour sites web mobiles (à destination des feature phones) je suis preneur…

Changeons de sujet maintenant pour rebondir sur un autre article de Luke W qui traite des formulaires narratifs : Mad Libs Style Form Increases Conversion 25-40%. Pour faire court, les formulaires narratifs utilisent une mise en page complètement différente des formulaires traditionnels et privilégie une approche plus narrative : « Je suis … et je recherche … pour faire … à partir de …« . À découvrir par exemple chez Effduffer.

Dans les faits, ce type de formulaires transformerait mieux que les formulaires traditionnels, les équipes de Vast ont ainsi constaté une amélioration de 25% à 40% de leur taux de transformation sur le formulaire de contact :

Des résultats surprenant pour une approche très originale. Assurément une piste à creuser…