wdfriday

Copie, plagiat, style graphique, jusqu’où peut aller la créativité en Flat Design ?

Geoffrey Dorne — Fri, 15 Mar 2013 09:00:37 +0000

Il y a quelques jours, le site Designmodo publiait le lien vers un fichier Photoshop gratuit contenant des éléments d'interface en Flat Design. Ce fichier a été remarquablement bien reçu de par sa qualité et beaucoup de webdesigners l'ont téléchargé afin de l'utiliser pour leurs maquettes. Mais voilà, le site Layervault a émis un avis de retrait DMCA sur ce fichier. Le Digital Millennium Copyright Act (DMCA) est une loi américaine adoptée en 1998 dont le but est de fournir un moyen de lutte contre les violations du droit d'auteur et d'établir une législation de la propriété intellectuelle adaptée à l'ère numérique. Après une rapide comparaison entre ce fichier Photoshop gratuit et le design du site Layervault, on remarque la flagrante ressemblance des couleurs, des icônes, des éléments d'interface utilisateur en Flat Design. Une copie donc ? D'un autre côté, le caractère minimaliste du Flat Design fait qu'il est parfois facile d'arriver à un même traitement graphique pour certaines choses, en particulier les petits éléments tels que les boutons, les champs de formulaire, etc. Voici des liens sur le fameux sujet et quelques réactions :

Alors, où sont les limites de l'inspiration, en Flat Design mais également dans un aspect plus général ? Dans quelles mesures peut-on considérer une maquette comme étant une copie ?

Aller sur Branch pour débattre de ce sujet

(N'hésitez pas à demander à rejoindre la conversation.)

UX design : indispensable ou négligeable ?

Enza Chaffron — Fri, 08 Mar 2013 00:43:25 +0000

Le Web devient progressivement de plus en plus complexe, au rythme battant des technologies. Ce qui était autrefois un support statique a aujourd’hui évolué pour devenir une expérience très riche et interactive. Cependant, une chose ne change pas : le succès d'un site Web dépend toujours de ce qu'en perçoivent ses utilisateurs. Nous sommes amenés dans notre travail de web designer à prendre en compte cette problématique de l’expérience utilisateur et nous tentons d’y répondre en concevant des wireframes, en créant des personas, users journey ou d’autres méthodes d’UX design. L’article de Rian Van sur le site Elezea reprend un passage de l’interview de Ryan Singer, product manager chez 37signals :

“The things that get called User Experience come from the agency world. It really seems to be like that. Every time you meet people who are doing all of these UX methodologies they come from the consulting world. My background isn’t in the agency world; it’s in the product world. The whole game changes when you don’t have the pressure of delivering to a client on time, or trying to convince a client that you’re worth hiring or worth sticking with. For example, if you’re working on products, and you’ve got a really capable team that can prototype things in real code, of course you don’t need wireframes, because you don’t need to get sign-off on something from a client.”

Selon lui, l’UX design ne serait pas nécessaire car simplement lié à une problématique client et pourrait très bien être remplacé, par exemple, par du prototypage directement dans le code. Rian Van réfute cette affirmation et explique son point de vue sur la question, à savoir que ce n’est pas juste une pratique de Web Agency souhaitant sensibiliser le client, mais que cela apporte bien une réelle utilité dans notre travail au quotidien. Et vous, que pensez-vous de cet article ? Selon vous, l’UX design est-il un travail indispensable dans tout projet web, ou négligeable ? Est-ce un métier à part entière ?

Aller sur Branch pour débattre de ce sujet

(N'hésitez pas à demander à rejoindre la conversation.)

Redesign non sollicité : bonne idée ou poudre aux yeux ?

Stéphanie Walter — Fri, 22 Feb 2013 10:10:55 +0000

Depuis quelques semaines, voire des mois, on voit de plus en plus sur Twitter et Facebook, dans la communauté webdesign, passer des “Redesigns non sollicités”. Le principe : un designer s’approprie une interface, un logo ou un site web et le redesign sans accord initial du service/produit. Quelques exemples en actions :

L’exercice semble être devenu tellement populaire qu’un site rassemble certains de ces redesigns. Pourtant l’idée est loin de faire l’unanimité dans la communauté. Certains les critiquent car ils ne les trouvent pas ergonomiques, arguant le fait que ce ne sont que de jolies interfaces “eyecandy” sans réelle réflexion derrière. D’autres mettent en avant l’argument des contraintes du projet : ce genre de redesign n’est en effet soumis à aucune contraintes de temps, technologie ou client. D’autres encore pensent que le côté “gratuit” donne une mauvaise image du métier de designers aux clients, une image de designers prêts à travailler gratuitement puisqu’après tout c’est leur passion : “si certaines personnes sont prêtes à faire des redesigns gratuit, pourquoi irais-je payer un designer ?” ou “s’il a réussi à faire cela si rapidement je ne comprend pas pourquoi faire celui de mon site prendrait tellement de temps.” Pourtant, ce genre de pratiques peut également porter ses fruits, puisque le jeune designer qui avait proposé un redesign de Microsoft a été embauché pour travailler sur l’UI de la prochaine xBox. Alors "eyecandy", poudre aux yeux pour tenter de se faire remarquer, ou réelles bonnes idées, que pensez vous de ces redesigns non sollicité ? Y avez-vous déjà fait face dans votre carrière ? En avez vous déjà proposé un ? Et comment réagiriez vous si quelqu’un venait refaire une interface que vous avez créé sans votre accord ? Cette semaine, nous avons décidé de vous donner la parole pour ce petit sujet “débat”. La conversation se passera sur Branch et sera retranscrite ici. À vous la parole !

Aller sur Branch pour débattre de ce sujet

(N'hésitez pas à demander à rejoindre la conversation.)

Design et créativité : Apprendre à avoir des idées.

Jean-Philippe Cabaroc — Fri, 08 Feb 2013 09:30:09 +0000

La créativité est au cœur du métier de designer. Il doit sans cesse trouver des idées neuves pour répondre aux besoins de ses clients. Et la difficulté de cette tâche réside dans le fait qu'à un problème donné correspond une multitudes de solutions. On peut donc vite se sentir perdu si on ne sait pas comment chercher et comment choisir (Car encore faut-il savoir choisir la bonne idée). Heureusement, avoir des idées ça se travaille et avec de la méthode, on peut organiser sa réflexion de manière à être efficace. C'est ce que nous allons voir.

L’idée, c’est quoi ?

Qu'entend-on par “avoir une idée” ? En design, une idée est une réponse à un problème. Ça se formule en une phrase la plupart du temps. Quand un enfant pense à monter sur une chaise pour attraper un jouet inaccessible sur une table, il a une idée (s’il utilise une planche à roulette, c’est une mauvaise idée mais il ne le saura pas avant de s’être cassé la figure). Le métier de designer, c’est trouver des solutions aux besoins des clients : “Je veux vendre plus cher”, “je veux être entendu”, “je veux avoir plus de temps”, etc. Et pour cela, on va vous demander d’avoir pleins de chaises à disposition.

D’où viennent les idées ?

La croyance populaire laisse penser qu’une idée surgit de nulle part, un peu comme par magie (Voyez le symbole de l’ampoule qui représente l’idée dans la bande dessinée). Mais l’idée, bien sûr, est le résultat d’une réflexion, consciente ou non, et plus ou moins longue. Cette réflexion est influencée par son apprentissage du métier mais aussi par ses expériences personnelles. C’est une des raisons pour laquelle un design est très lié à la sensibilité d’un designer. Cette sensibilité, c’est d’ailleurs ce qui fait le succès de beaucoup d’entre eux. Un designer peut créer des designs très différents selon les projets auxquelles il participe, pour autant il y a toujours une part de lui même en chacun d’entre eux. Mais si les idées sont en nous, elles ne vont pas sortir toute seules non plus. Il faut un peu les aider et nous allons voir comment.

La culture personnelle

La première qualité d’un designer, c’est sa curiosité. Car c’est la base de ce qui forme sa culture. Beaucoup d’entreprises reprochent aux écoles qui forment les étudiants aux métiers du design de ne pas «livrer» des individus totalement opérationnels techniquement. Il y a sûrement des choses à redire sur la formation des étudiants, là n’est pas le sujet, mais ils ne se rendent pas toujours compte que ces écoles passent beaucoup de temps à former les esprits. On apprend aux étudiants à se nourrir intellectuellement, à enrichir leur pensée, à développer leur sens critique. Une fois dans la vie active, on a bien moins le temps pour cet entraînement intellectuel qui prend des années (et même toute une vie). La culture personnelle, c’est quelque chose d’intangible et donc de difficilement quantifiable, mais il ne faut pas oublier qu’avant d’être réel, un design se conçoit dans la tête. L’apprentissage d’un logiciel est important bien évidemment, mais ce n’est pas ça qui fera de vous un designer. Ne loupez donc pas une occasion d’enrichir votre connaissance, lisez des livres, participez à des conférences, allez voir des expos, rencontrez d’autres designers, bref : soyez curieux.

Définir des objectifs

Avoir un bon bagage culturel, c’est bien mais pour trouver des idées, il faut d’abord savoir ce que l’on cherche. La première chose à faire, c’est analyser la demande du client : “Qui est-il ?”, “Quel est son besoin ?”, “Quels sont les objectifs de communication ?”, “Quelle est la cible”, etc., c’est le genre de question qui vous aidera à cadrer vos recherches vers un point précis. Si vous avez la chance d’avoir un cahier des charges, vous aurez déjà des réponses à ces questions, sinon il faudra les poser. Le principe est d’avoir une liste de critères objectifs qui donnent un chemin à suivre. Maintenant que vous avez défini vos objectifs, passons à l’étape des recherches.

Cibler ses recherches

Une fois les objectifs fixés, il faut approfondir sa connaissance du sujet. C’est l’étape de recherche. Renseignez vous sur le client et son domaine d’activité : cherchez des images, des informations, regardez ce que fait la concurrence, imprégnez vous des codes de communications existants. Il faut nourrir son savoir, s’enrichir de références multiples. Si vous travaillez pour une société qui vend des avions radiocommandés, vous devez vous renseigner sur l’aéromodélisme, les différentes catégories d’avions, le prix que ça coûte, le profil type des personnes qui achètent ces produits, l’histoire lié à ce loisir, l’univers visuel qui lui est associé, etc. Vous ne savez pas encore comment vous allez vous servir de tout cela, mais plus vous avez d’informations et plus vous aurez de la matière sur laquelle bâtir vos idées. Car maintenant que vous avez vos références, il faut les digérer.

S’approprier un univers

Vous avez un problème à résoudre et vous connaissez votre sujet, reste à se concentrer sur l’objectif pour trouver un moyen de l’atteindre. Les interactions, les images, les couleurs, les éléments graphiques, la mise en page : tout doit avoir du sens par rapport à cet objectif. Vous ne ferez pas les mêmes choix si votre site s’adresse à des seniors amateurs d’opéra ou à des adolescentes fans d’équitation. De plus, il n’y a pas qu’un seul design possible pour répondre aux besoins d’un client, vous pouvez définir des axes de travail différents, mais alors il faudra choisir la réponse qui vous semble la plus pertinente.

Avoir un parti pris

Choisir le bon design parmi différentes pistes dépend de l'aspect que vous (ou votre client) décidez de valoriser et des choix esthétiques qui l’illustreront. Imaginons que vous deviez réaliser l’identité graphique d’une marque de chocolats diététiques artisanaux. L’objectif étant de mettre en avant les atouts du produit. Vous allez peut être choisir de travailler sur l’axe « diététique », créer un univers autour de l’alimentation équilibrée qui reste un plaisir. Ou bien vous allez peut être parler du savoir-faire ancien de la marque qui garantie la qualité du produit. D’un point de vue esthétique, vous avez la possibilité de montrer le produit brut sans artifice ou bien dans son packaging. Vous irez peut-être montrer des photos de l’artisan passionné dans sa chocolaterie ou bien peut être que ce sont au contraire les clients heureux que vous montrerez. Bien sûr ça peut être un peu de tout ça à la fois avec le juste dosage mais si vous voulez un design marquant, il faut un parti pris précis. Un design ne doit pas chercher à vouloir tout dire, mais se focaliser sur une idée forte.

L’inspiration perpétuelle

Comme on l’a vue précédemment, la culture personnelle tient une place importante dans sa capacité à trouver des idées. Se tenir au courant des tendances est indispensable mais une idée peut venir de n’importe où : un voyage, un livre, une rencontre ou de la simple observation du monde… László Bíró, l’inventeur du stylo à bille a eu l’idée de son invention en regardant des enfants jouer aux billes. Il avait remarqué que celles-ci laissaient un mince filet d’eau en roulant dans les flaques. Les idées peuvent surgir à des moments où on ne les attend pas, alors même qu’on était pas en train de chercher quoi que ce soit. C’est ce qu’on appelle la sérendipité. La capacité à découvrir quelque chose par le fait du hasard. La vie de tous les jours est une inspiration pour tout designer, le tout est d’être attentif à ce qui vous entoure.

Conclusion

Les idées de design viennent à la convergence de son expérience du métier, de sa sensibilité et de contraintes extérieures. Et bien qu’il y ait quelque chose de magique dans l’apparition d’une idée, elle est surtout le fruit d’un travail issu d’un exercice de la pensée. Une bonne idée c’est avant tout une idée qui répond à un besoin. Pas la peine de chercher systématiquement une idée de génie, car ça serait comme vouloir arriver au bout d’un voyage sans en faire le chemin. Comme disait Linus Pauling : « Le meilleur moyen d’avoir une bonne idée est d’en avoir beaucoup. »

Web needs You!

Matthieu Bué — Fri, 25 Jan 2013 10:00:31 +0000

Le Web évolue. Il évolue même très vite. Au point même que les usagers en cernent les avancées plusieurs mois après leur mise en place. Et encore. Ok, ce n’est pas un scoop, mais il fallait bien une introduction.

Constatons

Si on y réfléchit un peu, qui au juste pousse à cette évolution constante ? Ce sont les constructeurs de supports de consultation ! Des grands groupes comme Samsung, Apple, Asus, HTC, LG, Sony, Philips, Nokia, etc. pour ne citer qu’eux. Des groupes aux moyens marketing très importants leur permettant de vanter les mérites de leurs devices de plus en plus performants, de plus en plus novateurs. Des devices qui demandent, du même coup, de plus en plus de connaissances techniques à ceux qui les exploitent, c’est-à-dire nous, les Web designers. Je rappelle que je ne parle ici que de Web. Le reste couvrirait un sujet beaucoup trop vaste.

La multiplication des devices

On assiste effectivement à une multiplication impressionnante des devices depuis ces dernières années. Et c’est justement là qu’est le problème : on ne fait qu’y assister ! Ne serait-il pas temps de participer, voire même d’anticiper ? C’est le sujet qu’a voulu traiter Francis Chouquet lors d’une conférence informelle du Paris Web : « Comment gérer la multiplication des devices ? ». À cette conférence, il y avait pourtant du beau monde. Le débat avait bien démarré, on discutait responsive, bien sûr, et des moyens actuellement possibles pour tester. Kaelig Deloumeau-Prigent, nous a notamment fait part de son expérience particulière et souvent utopique pour la plupart d’entre nous : si des devices en particuliers nécessitent d’être testés, on les achète, tout simplement. Rien de mieux que le support réel. Malheureusement, la durée imposée du débat ne nous a pas permis d’aller assez loin. Nous avons tout de même eu la possibilité d’animer un atelier d’une durée plus conséquente sur ce même sujet le samedi. Avec entre autres Stéphanie Walter, Enza Chaffron, Raphaël Goetter, Nicolas Torres, Nicolas Hoffmann, Maurice Svay, Erwann Mest, nous sommes arrivés à un relatif consensus au bout d’une heure et demie… Gérer la multiplication des devices est une problématique actuelle et récente. On connaît tous des moyens plus ou moins onéreux, plus ou moins compliqués à mettre en place, et on sait pertinemment que ça va devenir de plus en plus difficile. La question a donc évolué en « Comment anticiper sur la multiplication des devices ? ». Pour illustrer mon propos, connaissez-vous la résolution du dernier MacBook Pro 15 pouces ? 2880 x 1800 ! Également, plus d’un an avant sa sortie, Sony a annoncé que sa prochaine PlayStation 4 supportera une résolution de 4096 x 3072 ! Pas besoin de vous faire un dessin : le Web, ce n’est définitivement plus du 72dpi (coco) ! En y réfléchissant, on se rend compte qu’il est en fait impossible d’anticiper, car qui peut réellement parier sur des évolutions ? En confrontant les expériences et avis de chacun, nous avons conclu que la solution, si tant est qu’elle existe, serait une plate-forme communautaire qui permettrait la proposition de nouvelles fonctionnalités afin de les transmettre à « ceux qui développent les navigateurs ». La communauté d’acteurs du Web est une ressource de matière grise non négligeable pour eux !

La solution

À cette édition du Paris Web, j’ai également eu l’occasion de rencontrer Karl Dubost. Pour ceux qui ne le connaissent pas encore, de 2000 à 2008, il a été Web Community Liaison, HTML WG staff contact, QA Activity Lead et Conformance Manager pour le W3C. Il a également travaillé comme Web Opener pour Opera Software de 2010 à 2012. Après d’enrichissants échanges lors de l’atelier « La clinique des navigateurs » puis par mail, j’ai appris que cette plate-forme existait déjà : Les W3C Community and Business Groups. Pour être honnête, je me suis pris une grosse claque dans l’ego. « Bien joué, Karl ! C’est réussi ! ». Sérieusement, comment se fait-il que moi qui me tiens au courant en permanence de ce qu’il se passe sur le Web, de ses avancées, qui cherche à apporter mon petit caillou à cet édifice mondial, je n’étais pas au fait de l’existence de cette communauté ?! C’est pour tenter de combler ce manque de communication et diffuser la bonne parole que je laisse la place à Karl afin qu’il présente cette plate-forme, son contexte, sa création, son but, ses ambitions.

Les W3C Community and Business Groups

(par Karl Dubost) Le Web est un lieu technologique ouvert en évolution. Le débat d’idées y est fréquent et nécessaire, ce qui génère du conflit. Le W3C est un organisme qui permet de gérer ce conflit, de l’organiser et de le canaliser dans une discussion positive. L’organisme est financé à travers différentes sources de revenus : les membres (entreprises, organisations, gouvernements, etc.) et les donations sur des projets précis. Une grande partie de son activité est rendue possible grâce au temps bénévole ou salarié des individus qui y participent. Le W3C a été créé en octobre 1994. Son mode de fonctionnement évolue en fonction des circonstances et des besoins de la communauté (industrie et participants du Web). Certaines de ces évolutions ont été radicales. En 2002, la communauté open source était insatisfaite par les termes des licences des normes du W3C. Les normes étaient publiées avec une licence permettant aux participants des groupes d’implémenter la technologie mais sans pour autant lever le risque des brevets pour les groupes externes au W3C. Une discussion passionnée s’est soldée finalement en mai 2003 par l’annonce de Tim Berners-Lee (inventeur du Web et directeur du W3C) de la Royalty Free Patent Policy. Toutes normes du W3C sont maintenant publiées de façon à ce que chaque développeur n’ait pas à craindre un brevet. Le W3C est un organisme en mouvement dont le mode de fonctionnement dépend des communautés qui y participent. Il est important de s’impliquer et de faire entendre sa voix pour y créer du changement. Le Web s’est étendu à de nombreux domaines de la société touchant un public de plus en plus large avec des ressources (temps et argent) très différentes. Le W3C initialement permettait uniquement aux membres payants (ainsi que quelques invités experts) de participer aux groupes de travail : la participation bénévole sous forme de commentaires et d’implémentations externes au W3C. Un sentiment de participation à double vitesse des communautés externes s’est formalisée. Après de nombreuses discussions et de commentaires de la communauté, les community groups ont été créés. Les community groups sont une plate-forme pour permettre à tous de travailler ensemble sur un sujet donné du Web. Il suffit de posséder un compte public au W3C afin de pouvoir commencer à proposer un groupe. Une fois que le groupe a été appuyé par cinq personnes, le travail peut débuter. L’ouverture d’un groupe fournit une ou plusieurs listes de discussions, un blog du groupe, un wiki, un canal IRC. Sur demande, il est également possible d’obtenir un issue tracker ainsi qu’un espace Mercurial. Les participants sont finalement libres de contribuer à leur manière et de s’auto-organiser autour d’un sujet spécifique. Ils peuvent même bénéficier sans obligations du mode de contributions sous la politique de licence Royalty Free. L’enjeu donc n’est plus le frein à la participation mais la motivation même des participants à concrètement s’impliquer. Les community groups déplacent la zone de friction précédente du « nous n’avons pas le droit de participer » vers « nous devons nous impliquer ». En cela, c’est intéressant, il ne tient qu’à vous de rendre le groupe actif et productif. C’est peut-être là la plus grande difficulté. Les résultats d’un community group peuvent permettre d’aider le travail d’un groupe de travail du W3C, mais ce n’est pas la seule possibilité. Il est tout à fait possible pour les participants de produire un ou des documents autonomes pour les besoins d’une communauté spécifique. Le champ des possibles est vaste. Il ne tient qu’à vous de créer et contribuer à la communauté. Cependant il est essentiel de se souvenir que votre enjeu n’est pas toujours le problème des autres communautés. La création d’un community group ne se traduit pas nécessairement par le succès de votre idée, mais peut vous aider à déterminer si l’idée était mature ou avait les bons participants pour qu’elle se réalise. La création du groupe n’est que le premier 1% du travail. Le 99% restant est votre implication dans la vie du groupe. Bon courage !

Le Web a besoin de nous

Désormais, vous connaissez cette plate-forme. Jetez-y un coup d’oeil, regardez ce qu’il s’y passe, lisez… Ce sont ces premiers pas qui vous amèneront peut-être à participer, et contribuer à l’élaboration de solutions pour « gérer la multiplication des devices ». Qu’en dites-vous ?

Pour aller plus loin

Mode de fonctionnement du W3C
La liste des membres payants du W3C
Créer un compte public au W3C
L’ouverture d’un groupe, par exemple Responsive Images Community Group
Le W3C vu de l'intérieur par Dominique Hazaël-Massieux sur le Train de 13h37

jQuery Mobile : une introduction au framework et principes de base

Stéphanie Walter — Fri, 11 Jan 2013 11:31:37 +0000

Avec l’expansion du marché du mobile de ces dernières années, les entreprises comprennent de plus en plus le besoin de mettre leur contenu à disposition d’utilisateurs en situation de mobilité (sur smartphone ou tablette). Pour cela, il existe deux techniques : mettre son contenu à disposition dans une application native, ou le rendre accessible depuis une page Web (ou une webapp). Pour connaître la différence entre les deux, je vous renvoie à l’excellent article de Geoffrey sur le sujet. Dans cet article, c’est à la seconde solution que nous allons nous intéresser : le contenu accessible depuis une page Web. Le but est de vous présenter un Framework avec lequel je travaille beaucoup : jQuery Mobile. Je n’entrerai pas dans les détails techniques très poussés du code pour cette fois, la documentation officielle très détaillée et simple d’utilisation, ainsi que les tutoriels que vous trouverez sur le net seront là pour ça. Mon but est plus de vous permettre de cerner les possibilités du Framework, ses avantages et ses limites, pour que vous puissiez décider, en toute connaissance de cause, de l’utiliser dans vos projets futurs ou non.

jQuery Mobile, qu’est ce que c’est ?

Créer une “application Web” ne requiert d’autres connaissances que celles qu’ont déjà la plupart des webdesigners : HTML, CSS, JavaScript (et le langage de votre choix côté serveur pour générer tout ça). JQuery Mobile est un Framework complémentaire à la librairie jQuery, qui permet de créer facilement des applications Web cross-plateforme qui auront un look and feel mobile. Pour ceux qui utilisent jQuery UI, jQuery Mobile est donc la version cousine, pour les applications mobiles. Attention, qui dit Framework, dit fichiers supplémentaires à charger. Dans le cas de jQuery Mobile, vous devrez intégrer à vos pages les librairies jQuery et jQuery Mobile.

Un Framework orienté mobile, concrètement, ça fait quoi ?

Les plus équipés d’entre vous qui auront la curiosité d’aller visiter la documentation, qui sert également de démo, depuis différents terminaux pourront noter la différence de mise en page du site sur desktop, tablette ou smartphone. Vous pouvez également redimensionner votre navigateur pour vous en rendre compte. JQuery Mobile utilise des techniques de responsive webdesign pour faire en sorte que votre application mobile s’adapte toute seule à la taille du navigateur. Cela permet donc de développer une application pour smartphones et tablettes, sans avoir à changer le code et à refaire le travail deux fois. [caption id="attachment_1283" align="aligncenter" width="510"] jQuery Mobile[/caption] Orienté mobile, ça veut également dire dans le cas de jQuery Mobile que l’interface utilisateur est pensée pour un utilisateur en situation de mobilité : Les zones cliquables sont très grandes, le contenu est présenté en une colonne pour les utilisateurs de smartphones, etc. Le look and feel général de jQuery Mobile a été fait de telle sorte que l’application Web ressemble et mime certains des comportements natifs. Orienté mobile, ça veut enfin dire que les évènements « mobiles » tels que le touch, le swipe, taphold, et le changement d’orientation sont pris en compte dans le Framework. Là où jQuery permettait de lier des évènements de souris à des fonctions, jQuery Mobile permet de faire la même chose, mais pour des évènements mobiles. Le Framework se charge également de faire la conversion entre ces évènements, ce qui permet de créer un site qui fonctionne aussi bien sur écran classique que sur écran touch, avec la même ligne de jQuery.

Un Framework pour développer sur différentes plates-formes

JQuery Mobile est compatible multiplateforme : iOs, Android, Windows Mobile, BlackBerry, mais également navigateurs desktop et Phonegap. Puisqu’une application jQuery Mobile est en fait une application HTML5, il est possible de la lancer dans n’importe quel navigateur de n’importe quel appareil qui supporte le balisage HTML5. Notons que le HTML5 est obligatoire, beaucoup d’éléments du framework passant par l’attribut data-* . Plus besoin de développer une application native par plate-forme. Vous pouvez jeter un coup d’œil à la liste de compatibilité pour voir tous les appareils pouvant supporter. Certains pourraient cependant voir ici une des limites du Framework. Chaque plate-forme ayant son propre look and feel, une application iOS native sera, en théorie, différente d’une application Android ou Windows Mobile. Utiliser jQuery Mobile uniformise les apparences sur toutes les platesformes (vers une tendance assez iOS d’ailleurs), et l’éloigne du natif auquel les utilisateurs sont habitués. Un exemple concret est l’utilisation du bouton de retour en arrière dans les toolbars : Si ce bouton a une utilité sur les smartphones iOS, un bouton physique (ou implémenté dans l’OS pour les téléphones récents) est toujours présent, rendant ce bouton inutile. A noter qu’il peut néanmoins s’avérer indispensable pour une application iPhone embarquée dans Phonegap par exemple, puisqu’en embarquant l’application, on prive l’utilisateur du bouton de retour intégré dans le navigateur iOS. [caption id="attachment_1284" align="aligncenter" width="440"] Le bouton retour de la toolbar[/caption]

jQuery Mobile, c’est facile !

Je devrais dire très simple d’utilisation, puisque de base, jQuery Mobile ne requiert que des connaissances en HTML et CSS. Oui, même pas besoin de JavaScript. Le Framework utilise un système basé sur l’attribut HTML5 data- qui sera automatiquement récupéré et transformé par jQuery Mobile. Une div ayant l’attribut data-role=“page“ sera reconnu comme une page, un lien avec data-role=“button“ sera reconnu comme un bouton et aura automatiquement le look and feel d’un bouton, data-role=title pour les titres, etc. Il suffit de se référer à la documentation pour créer des mises en page plus ou moins complexes, à partir d’un HTML très simple. Voilà à quoi ressemble typiquement un morceau de page jQuery Mobile : [caption id="attachment_1285" align="aligncenter" width="510"] Exemple de code[/caption]

Un design personnalisable

Le design de jQuery Mobile est personnalisable via une simple feuille de style. De base, 5 styles sont proposés, et il est possible d’en créer d’autres. Depuis quelques versions le Framework a introduit une feuille de style « structure » et une feuille de style « theme », ce qui permet de faire des modifications de CSS sans devoir créer une surcharge de la feuille de style de base. Comme pour jQuery UI, un thème roller permet de créer son propre thème très facilement. Pour voir les possibilités en matière de graphisme, vous pouvez faire une tour sur le site JQM Gallery qui répertorie quelques sites / apps créées avec jQuery Mobile où jeter un coup d’oeil à ce tutoriel (en anglais). [caption id="attachment_1286" align="aligncenter" width="510"] jQuery Mobile Gallery[/caption] Attention cependant : comme tout Framework comportant son propre CSS, il peut devenir très vite lourd en termes de poids de “sur-coucher” les thèmes jQuery. Pour créer un thème très spécifique, il vaut mieux soit partir d’une feuille de style vierge et ne styler que les éléments dont vous avez vraiment besoin, soit faire le ménage et supprimer ce qui ne sert à rien. La feuille de style de base propose par exemple plusieurs transitions CSS3 entre les pages. En général on ne se sert que d’une seule. On peut donc imaginer supprimer les transitions inutiles, etc.

Des modules personnalisables

jQuery Mobile est, depuis quelques temps déjà, proposé dans sa version “decoupled” qui permettait encore une fois de gagner en performance en n’utilisant que les modules dont on a besoin. Depuis sa dernière version, un builder est proposé en version beta. Il permet de choisir les éléments et modules que l’on souhaite, et faire son “custom build” (comme Modernizr par exemple). Plutôt pratique sur du petit projet si on veut vraiment optimiser les performances.

Les limites de jQuery Mobile

C’est là que ça devient moins drôle. Je vous ai montré combien jQuery Mobile était sympa, je vais maintenant quelque peu noircir le tableau. Dans le web, la seule vraie réponse est “ça dépend” ! Il en va de même pour la question “Vais-je utiliser jQuery Mobile sur mon projet ?”. JQuery Mobile est tout sauf une solution miracle : il ne s’agit pas d’un script plug and play qui va magiquement transformer votre site en un site optimisé mobile. Il n’est donc PAS conseillé de l’utiliser si vous avez juste besoin d’optimiser l’affichage mobile de votre site. Pour ça, une optimisation responsive à base de media queries bien choisis (entre autres) suffit largement. Son look and feel de base laisse peu de place au branding de la marque de votre client, et tous les sites se ressemblent, à moins de faire un très gros travail sur le CSS qui vous prendra beaucoup de temps. Il n’est donc pas forcément conseillé de l’utiliser pour des sites vitrine que vous voulez optimiser “rapidement”, mais plus pour des sites “applicatif”. Le poids de la librairie est également un paramètre non négligeable : 24KB pour le script minifié, 7KB pour la feuille de style de base minifiée elle aussi. Sans oublier qu’il faut inclure la librairie jQuery ! Autant de ressources à télécharger pour un utilisateur en situation de mobilité dont la bande passante peut être assez limitée. Encore une fois ici, la version decoupled et les feuilles de styles personnalisées peuvent vous aider, mais ça demande du temps. Enfin, notons également que pour le moment, malgré les progrès des APIs HTML5 et JavaScript, tout ce qui est faisable sur une application native ne l’est pas forcément dans un navigateur. Par exemple, si l’application a besoin d’un scanner de Barcode, du gyroscope ou de l’appareil photo, ce n’est pour le moment pas possible (certaines librairies et API commencent tout de même à s’y intéresser). Une solution alternative sera d’utiliser Phonegap, qui permet des passerelles entre fonctionnalités natives et jQuery.

Quelques questions

Je vais finir cet article par des questions, certaines que j’ai pu me poser moi-même, et d’autres qui m’ont été posées par des confrères Webdesigners et développeurs. Quel environnement de développement faut-il pour créer une application jQuery Mobile ? La navigation jQuery Mobile utilisant l’Ajax, il faudra un serveur capable de le supporter. En environnement de développement, même si l’on crée des pages HTML, il faut donc les lancer depuis un serveur local ou distant (Wampp, Xampp, EasyPHP, etc.) pour que la navigation fonctionne. Pour les outils, un éditeur de codes HTML, CSS et JavaScript classique suffit. Est-ce que les applications web créées avec jQuery Mobile ne fonctionnent que sur smartphones ? Non, comme on peut le voir sur le site de démonstration, les applications Web fonctionnent également sur PC, mais gardent un look and feel prévu pour smartphone. Cependant, certains évènements comme le changement d’orientation ou le swipe ne seront pas disponibles. Mon client veut une application « sur le store ». Peut-on utiliser jQuery Mobile dans une application native ? Il est tout à fait possible d’utiliser jQuery Mobile dans une application native. Une des solutions possibles est de construire l’application avec le Framework jQuery Mobile, puis de l’encapsuler dans une application native en utilisant Phonegap. Attention cependant à Apple qui a tendance à parfois refuser les application “natives” qui ne sont que des coquilles d’un site embarqué. Une autre solution consiste à utiliser les « Webviews » natives d’Android et iOS, et d’y « afficher » l’application comme s’il s’agissait d’un navigateur. Dans ce cas les fichiers HTML, CSS, JavaScript, images, etc. peuvent soit être stockés sur l’appareil (et donc téléchargés au moment de l’installation de l’application), soit être en ligne (nécessite une connexion). Est-il possible d’adapter le design en fonction du système de l’appareil pour donner une apparence plus « native » ? Le seul moyen est une détection du User agent, avec tous les risques d’erreurs que l’on connaît. Dans le cas d’une application native utilisant une Webview, c’est un peu plus simple puisque le développeur peut définir un User Agent que l’application va envoyer au serveur (oui, on peut tricher ^^). On pourra alors changer le HTML, ajouter une classe .iOS au body pour pouvoir changer de style en fonction, etc. Où placer les scripts qui ne vont servir que sur une page ? Les pages d’un site jQueryMobile sont chargées en ajax. Uniquement les scripts et ressources contenues dans le header de la première page seront donc chargés. Cela implique que tout script placé dans le header d’une page non première ne sera pas chargé. Pour ne charger un script que sur une seule page, il ne faut pas le placer dans le header, mais après la balise data-role=page_de_celle-ci.

Conclusion

J’espère que cet article vous a permis de découvrir ce Framework et vous a donné une vision plus claire de ce qui est faisable ou non. Gardez bien à l’esprit que pour son utilisation, chaque projet étant différent, cela va dépendre du contexte, du projet, du client, etc. The right tool, for the right job. Et vous, avez-vous déjà testé jQuery Mobile ? N’hésitez pas à faire vos retour d’expériences.

Pour aller plus loin

La documentation officielle de jQuery Mobile
JQuery Mobile best practises
Mon tutoriel pour créer une application de choix de restaurant
Codiqa, pour créer des prototypes rapides avec jQuery Mobile
50 jQuery Mobile Development Tips

Des modèles pour vos articles

Matthieu Bué — Fri, 07 Dec 2012 09:30:42 +0000

Lorsqu’on entame un projet éditorial sur le Web, collaboratif qui plus est, on passe bien souvent par plusieurs phases : les balbutiements à la syntaxe bancale, puis quelques articles prometteurs, après vient la lassitude de la charge, puis la restructuration. Ces deux derniers points sont malheureusement souvent récurrents. Pour que le projet perdure, il faudra réussir à sortir de ce cycle “infernal” pour en arriver à pousser le projet vers le haut et le faire évoluer perpétuellement avec de nouvelles idées. Autant vous le dire de suite, ça a tout du parcours du combattant. Lors d’une restructuration précédente du projet WDfriday, il devenait impératif d’établir un processus stable pour la rédaction des articles. Quant bien même ils venaient de rédacteurs extérieurs à l’équipe, ils devaient passer plusieurs validations : pertinence, consistance, orthographe, grammaire, storytelling, etc. Nous ne sommes pas des rédacteurs dans l’âme, même si certains ont plus de facilités que d’autres, ce qui nous a amené à lire le livre Stratégie de Contenu Web de Erin Kissane, paru chez A Book Apart et édité chez Eyrolles en France. Il nous a été d'une aide précieuse, et je ne saurai trop vous le conseiller, même si l’éditorial n’est pas votre métier. Une structure. C’était la clé. Nous avons donc réparti les postes de chacun tel que nous le pensions le plus adéquat, puis nous avons défini des modèles d’articles : Analyses, Études de cas et Tutoriels. Ils ne sont jamais figés, et d’autres pourront bien sûr être créés par la suite. À posteriori, je peux vous dire que ce sont ces modèles qui nous ont été le plus profitable. Lorsque nous avons proposé à Stéphane Deschamps de venir rédiger son article Un Design Collaboratif d’Interface, nous lui avons mis à disposition le modèle d’article correspondant. Sa réaction fut sans équivoque :

« C'est vraiment bien, ce que vous avez fait. Vous devriez le documenter publiquement, tous les sites collaboratifs gagneraient à lire ça ! (…) »

Le WDfriday est en effet un projet collaboratif — et ne serait d’ailleurs rien sans ses contributeurs —, et aujourd’hui nous l’écoutons : voici les modèles d’articles du WDfriday, livrés sous licence CC (by-nc-sa).

Analyse Tutoriel Étude de cas

Notez que nous modifions régulièrement ces modèles suivant les besoins et notre expérience tout au long de ce projet. Inspirez-vous en, dépassez-les, faites-mieux et lancez-vous dans la rédaction. Et même, que diriez-vous de venir rédiger les articles qui vous tiennent à coeur et de contribuer au projet WDfriday ?

Prendre en compte l’accessibilité dans vos projets

Elie Sloïm — Fri, 16 Nov 2012 09:30:16 +0000

Vous êtes designer, intégrateur, concepteur d'interfaces ou chef de projet. De votre compétence dépend l'accessibilité des services et applications que vous développez. Faisons un point sur cette notion et voyons comment vous allez pouvoir la prendre en compte. L'objectif de cet article n'est pas de faire de vous un expert : il s’agit simplement de vous donner une vision simple et claire du sujet. Je vais vous indiquer quelques fondamentaux à connaître, puis vous proposer un bref parcours de quelques ressources utiles.

Ce qu'il faut absolument savoir

Pour commencer, nous allons essayer de déterminer quelques éléments à comprendre absolument :

L'accessibilité est l'une des exigences fondamentales qui s'appliquent aux projets web. C'est une obligation légale pour la plupart des sites publics à travers le monde. Pour des sites privés, la non accessibilité d'un contenu web est un risque juridique important, en raison des possibles mises en cause pour discrimination — par exemple, une rubrique ressources humaines, jobs ou recrutements présentant de graves défauts d’accessibilité fait courir de réels risques juridiques à ses auteurs.
L'accessibilité a pour objectif l'« ouverture » des contenus et services en ligne aux personnes handicapées, c’est à dire plus largement à toutes les machines logicielles ou matérielles qu’elles utilisent.
L'accessibilité a un intérêt particulièrement immédiat pour toutes les personnes qui ont des difficultés à se déplacer pour effectuer une démarche hors de leur cadre familier. Cela concerne au premier chef toutes les personnes ayant des déficiences cognitives, motrices ou sensorielles, de manière permanente ou temporaire, qu'elles soient reconnues comme handicapées ou non. Par extension, toutes les personnes âgées sont également concernées.
Des standards techniques internationaux ont été définis pour atteindre cet objectif d’accessibilité, sous l’égide du W3C. Il s’agit en particulier des Web Content Accessibility Guidelines (recommandations pour l'accessibilité des contenus Web, WCAG).
Ces standards internationaux définissent un certain nombre de choses à faire et à ne pas faire sur un site. Ces pratiques sont d'ordre ergonomiques, techniques ou éditoriales.

Des critères bloquants, ou au contraire facilitants

Les pratiques ergonomiques, techniques et éditoriales dont je parle ci-dessus vont conduire selon les cas à :

Lever un blocage total à l’accès aux contenus :
Exemple : le déclenchement automatique d'un son au chargement d'une page va venir empêcher la vocalisation d'une page par un lecteur d'écran. Il ne faut pas déclencher automatiquement de son au chargement d'une page.
Supprimer des difficultés majeures d'accès aux contenus :
Exemple : le rafraîchissement automatique des pages va vous renvoyer constamment en début d'article alors que vous êtes en pleine lecture. Pour des personnes qui vocalisent les pages via un lecteur d'écran, cela rendra très pénible la consultation de l'article. Il ne faut donc pas rafraîchir automatiquement vos pages.
Faciliter l'accès aux contenus :
Exemple : la présence d'un moteur de recherche va aider à trouver les contenus sans avoir à passer par des menus dynamiques éventuellement difficiles à consulter, ni avoir à explorer le site page après page.

Si vous décidez de faire en sorte que vos maquettes graphiques et intégrations ne contiennent pas de défauts susceptibles de dégrader l’accessibilité du site dans lequel ils seront utilisés, vous allez devoir respecter un certain nombre de critères. Le respect de ces critères ne garantira pas que le site en question sera visible partout et par tout le monde, mais au moins, vous aurez fait le maximum pour que ce soit le cas, et vous n’aurez pas introduit de défaut par le manque de qualité de votre travail. Voyons un peu comment il faut procéder.

Utiliser les standards internationaux ou une méthode d'application ?

Votre objectif final va être la mise en conformité de vos développements aux standards internationaux WCAG. A cet effet, vous pouvez évidemment décider d'utiliser les standards internationaux eux-mêmes. Voici la traduction française de ces standards. Regardez le sommaire. Les standards sont structurés en 4 principes génériques (des contenus perceptibles, compréhensibles, utilisables et robustes), puis déclinés sous forme de règles. À la lecture de ces règles, vous devez comprendre à peu près de quoi ces standards parlent. Mais cela semble immédiatement assez abstrait s’il s’agit à présent d’améliorer directement des maquettes graphiques ou des intégrations HTML/CSS, n'est-ce pas ? C'est pour cette raison qu'il existe des méthodes d'application, qui rendent la mise en conformité plus simple grâce à la mise à disposition de tests unitaires. En France, ces méthodes d’applications sont le RGAA et AccessiWeb ; au Québec, c'est la norme SGQRI-008. Voici quelques liens à visiter :

Le RGAA V2.2.1 (obligatoire pour les sites publics) : 187 tests, classés sous 12 thématiques.
AccessiWeb (proposé par l'association braillenet, associé à un groupe de travail et à un système de labellisation) : 300 tests.

Ces deux méthodes d'application reposent sur des listes de tests (ou de critères). Si le nombre de critères RGAA et Accessiweb est différent, ce sont bien les mêmes objectifs qui sont visés, à savoir le respect des standards internationaux (WCAG). Certains de ces critères sont techniques, d'autres ergonomiques et d'autres éditoriaux. Certains sont simples, d'autres sont complexes. Quand vous serez un ninja de l'accessibilité, vous maîtriserez le pourquoi de chaque règle. Mais pour l'instant, contentons-nous de les examiner.

Prendre en compte tout au long du processus

Les méthodes d'applications nous invitent à évaluer le résultat obtenu, mais ce n’est pas forcément le meilleur moyen d'y arriver. En effet, vous risquez de commencer en effectuant le contrôle de votre site en fin de fabrication pour vous assurer de votre conformité à votre objectif d’accessibilité, pour voir ce qui ne conviendrait pas. Au vu des résultats de cette évaluation, vous allez rapidement vous rendre compte qu'il est très coûteux de corriger les erreurs liées à certains critères. En pratique, cela conduit généralement à dire : « c'est trop cher, je prendrai cela en compte lors de ma prochaine refonte ». Par exemple, si vous vous rendez compte lors de l'analyse finale d'un site déjà en ligne que les contrastes sont insuffisants, cela risque de vous conduire à revenir sur le design, les images,... bref, des éléments qui sont censés être validés depuis bien longtemps. Voilà pourquoi il est fort conseillé de prendre en compte l'accessibilité bien avant, c’est à dire tout au long du processus de production. Dès l’étape du cahier des charges et des spécifications, de grosses erreurs peuvent en effet être commises :

Le choix d'une technologie fondamentalement inaccessible ou très chère à rendre accessible.
le choix d'une architecture de l'information ou de principes ergonomiques en dépit du bon sens qui rendront de toute façon l'accès aux contenus très compliqués.
Le choix d'un système de gestion de contenu (CMS) qui ne permettra pas aux rédacteurs quotidiens du site de produire des contenus accessibles.

Par la suite, les phases de prototypage et de design nécessitent également de prendre en compte certains critères. Ce sera le cas des contrastes, par exemple, mais aussi de nombreux éléments ergonomiques (signalement des liens, des menus, liens d'évitement, zonage des formulaires). La phase d'intégration HTML/CSS est absolument fondamentale, car c'est de ce niveau que va dépendre une très grande partie de l’accessibilité technique. Pour finir, la phase d'ajout des contenus n’est pas moins fondamentale, au contraire : en fonction du CMS choisi et de la façon dont il sera configuré (via ses extensions, notamment), il sera plus ou moins possible pour les rédacteurs de rendre les contenus accessibles. Mais encore faudra-t-il qu’ils aient été au moins sensibilisé à cet aspect souvent méconnu de leur travail. Il est maintenant temps de regarder vos maquettes graphiques, vos intégrations HTML/CSS, puis de les corriger, de les améliorer, de comprendre. Et cela tombe bien en France, d'excellentes ressources documentaires sont apparues depuis peu. Nous allons notamment citer les notices AcceDeWeb, produites sous licence ouverte par la société Atalan ; elles vont particulièrement vous intéresser pour les phases de design et d'intégration.

Détecter les erreurs et les risques d'erreur

Je m'occupe depuis plusieurs années d'un projet appelé Opquast (Open Quality Standards). Dans le cadre de ce projet, Aurélien Levy a lancé la conception de deux listes de critères appelées « Steps ». Ces checklists ne rendront pas votre site totalement accessible ni conforme aux normes WCAG. Elles permettront en revanche de traiter un socle vital d’erreurs et risques d'erreurs techniques (mais pas éditoriales ou ergonomiques) :

« First step » permet de détecter une série d'erreurs sur une intégration ou un site. Exemple : il ne faut pas utiliser l'attribut bgsound ;
« Second step » permet de détecter des risques d'erreurs d'accessibilité. Exemple : si vous ne faites pas un target blank, votre contenu ne sera pas forcément inaccessible, mais si vous ne mentionnez pas l'ouverture en nouvelle fenêtre, ce sera le cas.

Ces deux checklists sont disponibles en téléchargement et sous licence libre. Et j'ai encore une meilleure nouvelle : vous pouvez télécharger l’extension Opquast desktop pour firefox qui va vous permettre de tester directement vos pages selon les critères des checklists Steps.

Pour aller plus loin

Pour bien comprendre l'accessibilité, vous pouvez acheter le récent livre d'Armony Altinier sur l'accessibilité Web. Vous pouvez également consulter le site OpenWeb.eu.org, qui parle d'accessibilité dans de nombreux articles. Enfin, dans votre apprentissage de l'accessibilité, vous voudrez peut-être à un moment vous intéresser à d’autres aspects de la qualité Web. Dans ce cas, vous pouvez également consulter les différentes briques du projet Opquast. Vous y trouverez différentes checklists en licence libre, un outil de management de la qualité et de l’accessibilité Web en SaaS (Opquast reporting) et Opquast desktop, l’extension open source pour firefox déjà signalée plus haut. Maintenant, c'est à vous ! Avez-vous déjà pris en compte l'accessibilité dans vos projets, Web ou non d'ailleurs ? Connaissez-vous d'autres ressources utiles ? Partagez votre expérience !

Un design collaboratif d’interface

Stéphane Deschamps — Fri, 02 Nov 2012 09:00:57 +0000

De plus en plus de designers Web prônent une pratique du design décloisonnée : à l’heure où on parle d’agile, comment concevoir une page sans être coincé par Photoshop, en tirant parti du fait que les navigateurs permettent de faire des interfaces « qui bougent » ? C’est ce que nous avons tenté de faire lors de la conception d’un didacticiel expliquant le portail Orange.fr.

Le besoin

À l’occasion de la refonte du portail Orange.fr en juillet 2012, il nous a semblé opportun de concevoir une page didacticielle, et ce pour plusieurs raisons :

La conduite du changement : souvent le changement se heurte à une certaine résistance liée à l’habitude. Il faut réduire la friction, en simplifiant la transition.
L’accompagnement de l’utilisateur : tout le monde préfère s’entendre expliquer à quoi servent les choses plutôt que de devoir tâtonner (et puis tout le monde n’est pas un digital native ou ne travaille pas dans le web).
Enfin, c’était l’occasion de proposer un point d’atterrissage plus intéressant/utilisable/profitable que de simples blocs de texte expliquant les fonctionnalités de cette page d’accueil : comme on dit, un bon dessin vaut mieux qu’un long discours. Nous voulions expérimenter une présentation simple et la plus intuitive possible, sans recourir à des vidéos ou aux blocs de texte habituels.

Nous avons donc décidé de travailler en parallèle :

Pour le design : des soumissions aux parties prenantes de maquettes basées sur Photoshop pour les couleurs, la typographie, l’équilibre des masses, le facteur de zoom le plus adapté à la prévisualisation complète du portail, etc.
Pour le développement : des petites itérations permettant de tester le comportement de la page et de voir si elle est en accord avec ce que nous espérons (prendre l’utilisateur par la main et rendre l’expérience la plus confortable possible).

Je vais détailler ci-dessous la partie développement en accompagnement du design. Imaginez qu’en parallèle, des maquettes Photoshop ont été réalisées, là aussi en accord avec le cahier des charges. Tâchons de détailler, au fil de l’eau, l’intégration du design graphique dans la page.

Les étapes

En parallèle des tests d’ergonomie de la page, vous verrez le design se raffiner. Lors de cette première étape rien n’était finalisé : ni les couleurs, ni les équilibres de typos, ni les contenus. Le design graphique était encore en phase de validation.

Étape 1 : comportements de base

Dans un premier temps il fallait arriver à maquetter le comportement des éléments que nous voulions montrer. Ce qui fonctionne bien dans un design statique peut ainsi être mis à l’épreuve en survolant plusieurs items et en regardant l’effet produit. Nous avons donc tenté de faire un zoom incarné par un effet de loupe décentrée : [caption id="attachment_1114" align="aligncenter" width="510"] Effet de loupe décentrée[/caption] Une fois mis en musique dans le navigateur, nous découvrons en montrant cette page autour de nous que ça ne fonctionne pas : la partie zoomée est trop éloignée de l’emplacement réel de l’élément mis en évidence. La maquette graphique était prometteuse, le rendu dans le navigateur ne donne pas le résultat escompté. Nous tentons alors un zoom positionné sur l’élément lui-même : [caption id="attachment_1117" align="aligncenter" width="510"] Zoom positionné sur l’élément[/caption] C’est mieux, et ça nous permet de comprendre que le zoom ne pourra pas se faire sur tous les éléments que nous mettrons en évidence en fin de course : les plus gros blocs cacheraient toute la page — et ce n’est d’ailleurs pas forcément pertinent de les zoomer. Nous décidons alors de ne zoomer que deux fonctionnalités : mail et espace client. C’est par ailleurs cohérent avec notre cahier des charges, qui indique que nous devons insister sur le changement important dans la zone supérieure du portail : ces deux fonctionnalités sont très utilisées, il convient de ne pas perdre l’utilisateur. Par acquit de conscience nous tentons une mise en surbrillance sans zoom sur ces deux items, ce qui ne fonctionne pas, comme vous pouvez le constater : [caption id="attachment_1119" align="aligncenter" width="510"] Surbrillance sans zoom[/caption] Également, l’idée de désaturer les éléments flottants autour de la capture d’écran quand un élément est sélectionné commence à se profiler : elle est reprise dans une maquette graphique du « mode survol » et soumise à validation en parallèle. On valide ensuite que ce principe de ne pas zoomer les plus gros blocs n’est pas perturbant : [caption id="attachment_1121" align="aligncenter" width="510"] Un gros bloc n’a pas besoin d’être zoomé[/caption] Effectivement, ça fonctionne bien : comme c’est un gros bloc il n’a pas besoin d’être zoomé pour qu’on le repère facilement. Ici, le fond devient gris, ce qui permet de mieux mettre en évidence l’image et les pavés flottants. C’est ce qu’il y a dans les maquettes Photoshop, que j’intègre au fur et à mesure, en même temps que les tests fonctionnels. De même, sur cette itération, il n’y a pas de coins arrondis alors que la maquette graphique en comportait : on en déduit que c’est plus confortable, qu’il faut les garder, mais ce n’est pas stratégique au point de devoir intégrer des bidouilles laborieuses pour les vieux navigateurs. Ils auront des coins carrés, nous l’actons à cette étape.

Étape 2 : intégration graphique

Dans les maquettes Photoshop, les points spécifiquement graphiques ont pu être validés entre temps. On peut alors intégrer définitivement la charte retenue. D’abord, donner des formes de boutons aux liens « voir en détail », arrondir les angles, associer les bulles aux éléments qu’elles montrent par des petites flèches discrètes, aligner les titres, affiner la typographie, etc. [caption id="attachment_1122" align="aligncenter" width="500"] Intégration de la charte[/caption] Enfin, intégrer les textes définitifs et les éléments de navigation, communs à tout le portail : [caption id="attachment_1124" align="aligncenter" width="500"] Intégration des textes définitifs et éléments de navigation[/caption]

En résumé

Je ne vous ai parlé ici que du haut de la page pour faire simple, mais dans ce processus nous avons également validé d’autres aspects qui n’étaient pas modélisables dans un design statique, comme l’ouverture douce des blocs (slideUp/slideDown en jQuery), le défilement lent (soft scroll, cf. HTML Zen Garden), etc. Nous avons pu faire avancer le projet sur trois fronts en même temps : le design graphique via des maquettes traditionnelles sous Photoshop, le design comportemental via des prototypes intégrés dans le navigateur, et les contenus textuels. Ne pas avoir eu une organisation traditionnelle en « waterfall » — organisation séquentielle traditionnelle où le développement vient après le design — nous a permis d’obtenir un résultat qui nous semble plus riche à moindre effort. On connaît tous ces situations où un design validé ne sera pas intégrable tel quel, ce qui peut frustrer autant le donneur d’ordre que le designer, sans compter le développeur qui fera ce qu’il peut, mais aurait aimé un meilleur karma. En conclusion, faire des itérations plus simples en croisant les idées issues du design graphique et celles de la conception dans le navigateur par des allers-retours continus, nous a permis de prouver — s’il en était besoin — que c’est une façon très positive et productive de travailler. En tout cas, cette méthode nous semble un bon moyen de conjuguer design traditionnel et la conception dans le navigateur (voir l’article de Francis Chouquet sur le sujet). Vous pourrez voir le résultat final sur didacticiel.orange.fr. Qu’en pensez-vous ? Concevez-vous le design seul ou en équipe ? Quels sont selon vous les points qui pourraient bloquer cette démarche, ou au contraire y contribuer ? À quel moment basculez-vous vers le navigateur ?

Démystifions le Pixel Art : interview d’Olivier Huard

Huard Olivier — Fri, 12 Oct 2012 12:00:05 +0000

Aujourd'hui nous vous proposons de changer nos habitudes en présentant un nouveau type d’article sur le blog du WDfriday : l’interview, et nous commençons par celle d’Olivier Huard, avec une tendance récurrente du Web design : le pixel art.

Bonjour Olivier, peux-tu te présenter brièvement ?

Hello, je m’appelle Olivier Huard, j’ai bientôt 39 ans et je suis graphiste. J’ai pour spécialité le pixel art⁽¹⁾ mais j’adore m’essayer à tout plein de domaines comme la photo, la vidéo, etc. J’ai également pratiqué la 3D mais bien sûr en low poly (avec le moins de polygones possible). J’aime aussi bidouiller un peu de code. ⁽¹⁾J’ai pratiqué cette technique il y a quelques années pour le jeu Rayman sur Palm et Pocket PC, ainsi que pour divers autres jeux vidéos. Plus récemment, j’ai eu la chance de réaliser l’affiche de l’exposition Game Story au Grand Palais.

Tu as commencé sur Palm Pilot, donc une expertise pixel art sur écran. Tu nous racontes ?

J’ai même commencé bien avant, sur mon MO5 avec un logiciel qui se nommait Pictor et qui fonctionnait avec un crayon optique. Puis je suis passé par le papier millimétré colorié à la main, Deluxe Paint sur Amiga, Paint sur mon premier PC et ainsi de suite, en utilisant divers logiciels qui me permettaient de pratiquer de manière confortable. J’ai très vite vu le potentiel des petits écrans pour s’amuser avec le pixel art, au moment ou l’on commençait à faire de la 3D à tout-va sur ordinateur.

Tu as également fait du print en pixel art, la transition a-t-elle été délicate ?

En fait le passage n’est pas si difficile si on tient compte de quelques réglages préalables. Il faut savoir que lorsqu’on veut imprimer une image en pixel art, il faut l’agrandir par un multiple de 2. Par exemple, je fais une image en 300*120px, si je veux l’agrandir pour du print, je devrais multiplier ses dimensions par 2, 4, 6, 8 ou plus au besoin, tout en faisant attention à la définition (dpi). Une fois les réglages effectués, on peut attaquer la réalisation.

Le pixel art est décrit comme une tendance, qui pourtant perdure. Comment l’expliques-tu ?

En effet c’est une tendance, mais c’est surtout un mouvement qui, par moments, retrouve ses lettres de noblesse. Je pense que s’il revient depuis quelques temps c’est parce qu’il joue beaucoup sur l’affect. Les personnes qui ont grandi avec le pixel art arrivent aujourd’hui à un âge où leurs pouvoirs d’expression et d’achat le font revenir sur le devant des écrans. Le côté sentimental joue un rôle déterminant sur ce retour du pixel art. Les trentenaires ont la nostalgie de sessions de jeux avec leurs vieilles consoles et jeux fétiches de l’époque. Cela s’inscrit dans une mouvance “revival” qui s’observe dans de nombreux domaines : séries TV, jouets, mobilier, etc.

Tu retournes aujourd'hui vers le Web, avec notamment cette bannière pour Fred Cavazza : retour aux sources, ou évolution ?

Je pense que, comme quasiment toutes les formes d’expression artistique, elle a sa place sur un site Web. Le pixel art lui confère ce petit côté rétro qui fait appel une fois de plus à l’affect. C’est tout de même plus une évolution, car le pixel art ne s’illustrait que peu sur les sites Web ou portfolios, et encore, rarement en tant qu’élément visuel principal. [caption id="attachment_1072" align="aligncenter" width="400"] Bannière pour Fred Cavazza #1[/caption] [caption id="attachment_1073" align="aligncenter" width="400"] Bannière pour Fred Cavazza #2[/caption]

De nombreux Web designers se demandent ce qu'ils feront dans 3 ans ; et toi, comment imagines-tu le pixel art sur le Web à l'avenir ? Réservé à une niche ou tendance de fond ?

Pas simple comme question :) ! Je pense que cette technique va perdurer au travers de diverses formes, telles que les jeux “casual”, qui adorent jouer sur le côté “revival”. Cette technique sera plutôt une niche, car elle dépend, comme toutes les tendances, de la médiatisation que l’on en fait ; si la “mode” passe à autre chose, on en verra moins. Mais c’est un avantage car cela lui conférera un côté unique, qui le rendra d’autant plus apprécié. Du fait de sa longévité, on peut également lui attribuer le titre de tendance de fond, car c’est tout de même un des premiers moyens d’expression artistique informatique que nous ayons eus. J’apparente cette technique à un savoir-faire qui tend à se perdre avec les nouvelles générations — et qu’il faut faire perdurer — car les futurs trentenaires n’auront pas connu de jeux en pixel art. Ils n’auront donc pas forcément l’envie de faire revivre un truc qu’il n’ont pas connu.

Tes conseils pour un designer Web qui voudrait justement s'intéresser au pixel art pour créer un site ?

Comme pour toute discipline artistique il faut pratiquer, s'entraîner avec des tutoriels et ne pas hésiter à recopier des choses déjà faites pour les disséquer. Ensuite, il faut beaucoup de patience et de minutie, car c’est une pratique qui ne supporte pas vraiment l’approximation. Maintenant pour une création de site, je conseille d’essayer de travailler sur de petits formats, comme des sites mobiles pour commencer, ou juste des éléments d’UI afin de se faire une base d’éléments réutilisables. Il faudra également faire attention à sa mise en page, car c’est du travail au pixel près et la moindre erreur impliquerait de refaire l’élément. Et encore un truc : si vous utilisez Photoshop, n'hésitez pas à travailler avec les objets dynamiques et de la bonne musique :). Merci pour tout. Et vous, que pensez-vous du pixel art en tant qu’élément de Web design ? Vous y êtes-vous déjà essayé ?

Avec ceci ?

Un aperçu du travail de pixel art par Olivier Huard, dans lequel il présente, via un tutoriel, l'un de ses derniers projets. http://youtu.be/WP6_f1BM-yc