Cependant, ce n’est pas un mystère, le CSS3 a un sacré appétit et son repas préféré est le CPU (Central Processing Unit), le processeur en version française. Qu’en est-il réellement ?

Je me suis donc intéressé de plus prêt à cette consommation sur des animations simples, puis plus complexes et sur différents navigateurs, principalement Google Chrome et Firefox. J’utilise également un Mac Intel Core 2 Duo pour les tests.

1er test – transition et rotation

J’ai donc testé une translation d’un bloc combinée à une rotation et un changement de couleur. Le test est réalisé sur Google Chrome. Voici les résultats sur le CPU en position initiale, puis pendant l’animation :


Interprétations : le test révèle donc une augmentation de la consommation du CPU. On s’en doutait, mais 18% en système et 17% en utilisateur pour une si petite animation, ce n’est pas négligeable. Le résultat laisse assez perplexe d’autant que j’ai réalisé le test avec seulement Chrome d’ouvert. Si on ouvre Photoshop et autres fioritures de créatif ou développeur, on se retrouve très vite avec un PC qui chauffe, encore plus sur un PC portable.

2ème test – animation complexe sur beta.theexpressiveweb.com :

Google chrome :

Firefox :

Interprétation : ici sur une animation plus complexe, une bonne partie de la puissance du CPU est mobilisée pour l’animation. Sur Google Chrome nous avons 47% du CPU utilisé par l’utilisateur et 20,55% pour le système. Sur Firefox les résultats sont meilleurs. Nous avons 45,75% pour l’utilisateur et 11,75% pour le système. Chaque navigateur interprète le CSS3 à sa manière. Firefox est plus orienté vers le développement du navigateur en tant que plateforme, il va ainsi privilégier les outils comme les modules sélecteurs avancés.

En réalité, les animations qui consomment le plus sont en toute logique les plus longues, normal. Par exemple sur hakim.se/…/slideshow, des animations courtes montrent que le CPU ne s’emballe pas, bien qu’elles fassent appelle à de grosses transformations. Un conseil donc, visez juste dans la durée de vos animations pour ne pas affoler les compteurs.

Conclusions :

Alors il faut prendre en compte que mon matériel n’est pas le plus performant. Maintenant il faut aussi se mettre à la place du visiteur qui n’a peut-être pas non plus un foudre de guerre comme machine.

Le CSS3 propose de belles animations et s’améliore chaque jour. Chaque version de navigateur améliore le rendu et sa consommation. Ce petit test tout simple permet de mettre en avant un point technique : dans un projet, il faut pouvoir tester toutes les possibilités pour trouver celle qui sera la plus adaptée et pertinente pour répondre aux problématiques. Le choix d’une animation pourra se porter soit sur le Javascript avec notemment JQuery, ou sur le CSS3. Il faut pouvoir réaliser les tests sur un matériel récent, un plus ancien et également le plus de versions de navigateur possible. Il ne faut pas oublier que les animations doivent bien tourner en mode « production ».

Alors dans vos animations, attention aux bouffées de chaleur.

Bien que le web ne soit pas une branche scientifique à proprement parler, certaines notions pourraient être très utiles, comme la basique « démarche scientifique », qui se compose d’observations, d’expériences et de raisonnements.

Lorsque je vais parler des personnes travaillant sur le web, je ferai une généralité afin de rendre plus fluide la lecture, mais ce dont je parle n’est pas commun à tout le monde ! Il existe, et heureusement, des personnes ne s’arrêtant pas aux points abordés ci-après.

Beaucoup de tests, peu de compréhension

Quelque soit le domaine (développement web, tests utilisateurs, référencement…) nous sommes amenés à faire des tests, qui prennent plus ou moins de temps et sur lesquels on a plus ou moins de résultats. On étudie ces derniers afin de définir le test nous avantageant le plus, et on le garde. Or, il manque deux étapes dans ce processus, en prenant en compte la démarche scientifique : la création d’hypothèses après la compréhension même du problème, et la compréhension des résultats.

Un cas de départ assez global

Dans nos métiers, nous sommes souvent confrontés à des problèmes. « Pourquoi les utilisateurs n’achètent pas plus ? ». « Pourquoi j’ai une erreur PHP ? ». « Pourquoi je n’arrive pas à mieux me positionner sur Google ? ».

Toutes ces questions, pourtant basiques, reviennent tous les jours. Et lorsqu’il s’agit d’y répondre, la facilité consiste à trouver un plugin, trouver quelqu’un qui a déjà rencontré ce problème, ou tester dans tous les sens, sans réelle orientation.

Emettre des hypothèses

Dans la démarche scientifique, la première étape consiste à émettre des hypothèses. Selon les situations, il faut analyser l’environnement du problème, analyser des situations similaires qui n’ont pourtant pas ce problème. Ainsi, on peut avoir une idée de la source du problème et émettre des hypothèses.

Cela peut se faire en notant chaque hypothèse, ou bien en le faisant de tête pour des problèmes beaucoup plus simples, comme l’oubli d’un point virgule en développement par exemple.

Dans ces hypothèses, il ne faut pas oublier les situations liées à une cause indirecte. En effet, un problème n’est peut être le résultat d’une cause, qui est elle même le résultat d’une autre cause.

Tester ses hypothèses

Lorsque ces hypothèses sont établies, il faut ensuite les tester. Certaines peuvent déjà être supprimées grâce au rasoir d’Ockham, un principe énonçant que les hypothèses les plus simples sont les plus probables. Il faut aussi établir un périmètre de fonctionnement afin d’écarter certaines variables qui pourraient interagir avec le test, des valeurs de satisfaction qui vont permettre de comparer les résultats afin de déterminer si les différences sont significatives.  Ainsi, lors d’un test utilisateur sur un tunnel d’achat par exemple, si l’écart entre deux tests n’est que de quelques pourcents, un choix entre l’une ou l’autre des hypothèses n’est pas vraiment justifié.

Etablir un raisonnement

Lorsque les tests sont effectués, on aura alors une ou des situations répondant au mieux à nos problèmes. Pour des tests utilisateurs par exemple, cela aura permis au client d’améliorer son ROI (Return On Investisment) et au prestataire de répondre à la demande.

Sauf que, le plus souvent, la démarche s’arrête là, et aucun enseignement n’est retenu. Ainsi, lorsqu’une situation à priori différente se présentera, cette compréhension des problèmes précédents pourrait aider à résoudre les futures situations plus rapidement.

Ce raisonnement peut prendre du temps lorsqu’on n’y est pas habitué, mais on n’en ressort beaucoup plus riche lors de chaque expérience. Car il faut considérer une expérience comme quelque chose qu’on aura réussi, mais qui nous aura aussi permis d’en apprendre d’avantage.

Un cas concret

J’hésitais à prendre un exemple en développement mais je préfre que ce soit compréhensible pour tout le monde. Je vais donc vous donner un exemple d’un test utilisateur.

Le propriétaire d’un site marchand décide  de contacter une agence afin de tester différentes mises en page de son site car il aimerait que les clients achètent plus de produits. Sur les pages articles, une barre de filtres est disponible pour sélectionner la couleur, la taille et d’autres options. L’agence décide alors de tester deux mises en page : la première avec les filtres à gauche, la seconde avec les filtres à droite. Après un mois de test, on remarque que les clients achètent plus d’articles lorsque les filtres sont à gauche. L’agence conclut donc que cette disposition est plus efficace, ce qui ravit le client car cela lui permettra de gagner plus d’argent. Le problème est que cela ne nous dit pas pourquoi cette configuration a mieux fonctionné. Et c’est à partir de ce moment là que le raisonnement doit vraiment être fait.

La démarche, qui se rapproche alors de la démarche scientifique, peut sembler laborieuse, mais cela permettra d’en apprendre pour soi-même, mais cela servira surtout à plus long terme car les mêmes problèmes se présenteront plusieurs fois !

Cette année, HETIC et CIFACOM ont eu le plaisir de pouvoir accueillir le Google DevFest dans leurs locaux. La journée, s’étalant de 10h à 18h, nous proposait des conférences au sein de 3 salles différentes : la salle Android, la salle Chrome et la salle Cloud. Deux sessions pratiques étaient aussi dispensées dans une salle Codelab. Je vais vous résumer la journée dans la salle Chrome, celle qui m’intéressait le plus. Vous trouverez sûrement des retours des deux autres salles ailleurs sur le web.

Les nouvelles applications web

Intitulée « These Aren’t the Sites You’re Looking For: Modern HTML5 Web Apps » , présentée par Sam Dutton (samdutton.wordpress.com), Developer Advocate pour Chrome, cette présentation avait pour but principal de nous montrer les nouveautés liées au HTML5 en général (donc CSS3, JS et HTML) afin de nous permettre de faire des applications riches, offline…

Il a commencé par nous expliquer comment penser une application web. Il faut qu’elle soit très simple d’utilisation, l’internaute devant rapidement se familiariser avec l’application. Il doit savoir dès le début où cliquer et ce qu’on peut faire ou non avec cette application. Il doit aussi pouvoir utiliser l’application sans s’enregistrer, ce processus ne devant être demandé que lorsqu’il souhaite enregistrer ce qu’il a fait par exemple (mise en forme en bullet point).

D’un point de vue un peu plus technique, il nous a conseillé de bien séparer chaque élément de notre code, en prenant l’exemple du modèle MVC (Modèle / Vue / Contrôleur). Il nous a ainsi conseillé des frameworks Javascript tels que Sproutcore, Backbone.js ou encore extJS et des frameworks CSS tels que LessCss ou Sass. Le « responsive design » nous a aussi été conseillée grâce à l’utilisation des media queries, de Google web toolkits ou de la fonction window.matchMedia en Javascript. Il existe un autre Framework Javascript, formfactor.js, qui permet de travailler plus simplement sur plusieurs tailles d’écrans.

La suite de la présentation était composée d’une liste des nouvelles fonctionnalités qu’on peut avoir avec HTML5 :

• les fonctions Javascript pushState et popState, qui permet de se passer de hashtags et de modifier directement l’URL du navigateur. Cela permet à l’utilisateur de toujours savoir où il se trouve (leviroutes.com).
• la balise input « webkitdirectory » qui permet d’uploader un dossier entier de fichiers.
• l’attribut « draggable » associé à « dragstart » ou event.transfertData en Javascript qui permet de télécharger les fichiers  directement en drag’n drop vers un dossier.
• la fonction Javascript appCache qui permet de stocker des fichiers entiers chez l’utilisateur grâce à la déclaration d’un « manifest ».
• l’utilisation de bases de données locales comme indexedDB, webSQL permettant d’enregistrer les données offline puis de les envoyer à la reconnexion.
• la balise input « x-webkit-speech » qui enregistre la voix de l’utilisateur, propose des correspondances avec leur taux de fiabilité.
• des notifications au sein du navigateur grâce à la notification Window.
• l’utilisation des web-workers afin de ne pas bloquer le Javascript.
• le recours à des librairies Javascript permettant un travail plus efficace (selon les besoins…) comme HTML5 BoilerPlate, jQuery, Modernizr…

Sam Dutton nous a présenté Dart (pour ceux qui ne connaissaient pas) en vantant ses avantages. Il a notamment donné un argument qui a assez convaincu. Il est vrai que Google a permis d’accroître l’utilisation de Javascript et son rendu grâce à Chrome.
Pour finir, il nous a expliqué l’intérêt de faire des applications pour le Chrome Web Store. Il y a 200 millions d’utilisateurs de Chrome, ce qui représente le même nombre d’utilisateurs potentiels de votre application.

La console Javascript

Intitulée « DevTools Tips and Tricks » et présentée une nouvelle fois par Sam Dutton, la conférence concernait tous les outils présents dans la console de Chrome. C’était ainsi vraiment utile pour les développeurs qui l’utilisent souvent. On a ainsi été plusieurs à découvrir qu’il était possible de cleaner un Javascript compressé par exemple, ou de faire des requêtes à la console.

Le HTML5 offline (http://devfest-html5-offline.appspot.com/)

Intitulée « Working of the Grid : HTML5 Offline » et animée par Paul Kinlan, cette présentation revenait sur certaines nouveautés abordées lors de la première conférence, mais plus en détails, notamment sur les fonctions Javascript permettant à l’utilisateur de toujours pouvoir utiliser un site ou une application en étant offline.

Cela est très utile pour les personnes en déplacement, en avion, en train, ou lorsqu’une personne est dans le métro ou une zone peu couverte où il y a souvent des déconnexions. Cela apporte aussi une augmentation des performances car le travail se fait en local, directement chez l’utilisateur. Il n’y a alors plus de problèmes de DNS, il n’y a pas de données à télécharger…

Paul Kinlan est donc revenu plus précisément sur le stockage des données en local grâce à localStorage, sessionStorage, appCache, et sur l’utilisation de bases de données en local avec IndexedDB, WebSQL. L’utilisation de ce nouveau type de bases de données permet à l’utilisateur d’enregister ce qu’il a fait lorsqu’il était déconnecté pour pouvoir envoyé ces données à la reconnexion. Gmail utilise ce système pour que, lorsque vous écrivez un mail, il s’envoie soit directement, soit lorsque vous avez récupéré votre connexion.

On a enfin eu le droit à la présentation d’un « très » jeune développeur, Yvan Sraka, (18 ans… ), en double cursus BTS informatique / DUT biologie, qui a gagné un concours Google. Il a réalisé une application, QMCE, qui permettrait de convertir des applications en C, C++,  Python, Ruby et j’en passe, pour les rendre compatibles avec de nombreuses plateformes (navigateurs webs, mobile …). On était plusieurs à ne pas trop avoir compris réellement ce que ça faisait et surtout comment ça fonctionnait, mais il était assez impressionnant.

Les applications Google +

Pour finir la journée, Chris Chat et Jonathan Beri nous ont expliqué comment créer simplement des applications pour Google+ et ce qu’on peut y faire. Si Google a créé Google+, c’est d’abord grâce à une constatation. En effet, ils ont remarqué qu’ils étaient bons pour comprendre le web, ce qu’il contient, comprendre les langages… mais ils ne savent pas comprendre les gens, leurs relations, leurs envies. Ils sont revenus sur le principe des Hangout.

Merci à Google tout d’abord d’avoir choisi de faire ce DevFest au sein d’HETIC et de CIFACOM. Merci aux intervenants et toutes les personnes qui ont participé à l’organisation qui étaient très accueillantes, toujours souriantes. C’était aussi l’occasion de présenter le concours Dataviz 2012, sur lequel vous trouverez de plus amples informations sur le site officiel.

On a hâte de pouvoir assister aux prochains événements Google, peut-être encore à HETIC et CIFACOM ?

Liste de liens utiles :

Polyfills : http://bit.ly/HTML5PolyFills
Dart : www.dartlang.org
Appmator : http://appmator.appspot.com/
Chrome Status : chromestatus.com
HTML5Rocks : html5rocks.com

Chrome Web Store Developer Guides http://bit.ly/r3K8bm
Chrome Web Store Tutorial http://bit.ly/pYwzkY

Background – Extending your app’s life http://bit.ly/pc5HiT
Using the Notifications API http://bit.ly/qNfeeN
OpenID & Identifying Your User http://bit.ly/oqsAfI
What makes for a great web app? http://bit.ly/nJWZQA
Anatomy of a Great Chrome Web Store Listing http://bit.ly/iUdFLb

Au sommaire :

• Les goûts et les couleurs : la formation sur la symbolique des couleurs
• Tester l’ergonomie de son site même sans budget : les best practices
• Petite arithmétique de l’UX design : choisir, renoncer, construire étapes par étapes
• API et formulaires en HTML5
• Un bug à la fois : les problématiques d’un navigateur, Opera
• Les lighting Talks : 40 min, 10 intervenants, 10 speechs à mourir de rire !

Bonne lecture !

Les goûts et les couleurs

Une formation intéressante sur la symbolique des couleurs appliquée au web. La palette de couleurs est extrêmement importante pour l’expérience utilisateur, notamment sur les sites e-commerce où elle peut fortement favoriser l’acte d’achat. En fonction de leur spectre, les couleurs entrainent des réactions acquises et physiques différentes. Dans le premier cas, ces réactions dépendent de notre éducation et de notre culture. La réaction physique quant à elle entraine une accélération ou une réduction de notre métabolisme. C’est pour cela qu’il est communément admis que le rouge excite alors que le bleu apaise. La symbolique de chaque couleur en occident s’en est suivie, ainsi que des exemples de sites internet correspondants.

Quelques conseils en matière de sélection de couleurs ont été proposés : une couleur de base + une nuance correspondante + la couleur complémentaire correspondante. Et des outils pour faciliter cette tâche ont également été proposés tel que Kuler et Mypant.

Une question se pose ici finalement : peut-on stigmatiser chaque couleur à des sensations physiques même en ne restant que dans la symbolique des codes occidentaux ? Ne serait-ce pas comme l’a précisé un membre de l’assistance durant la session de questions/réponses : « un peu bullshit » ?

Tester l’ergonomie de son site même sans budget

Formation sur les best practices pour faire tester son site par des utilisateurs lambda sans avoir à passer par une agence spécialisée, car cela peut rapidement coûter très cher. « Do it yourself » ! Aussi bien durant la phase de maquettage ou de développement, car comme vous allez le voir, cela peut être « facile » avec de la méthode !

Tout d’abord, sélectionnez un panel d’utilisateurs pioché dans vos proches :

• La famille / des amis : pas vraiment optimal, car ces membres risquent d’être trop positifs dans leurs réponses pour vous faire plaisir.
• Des collègues : attention ici à ceux qui risqueraient de répondre sans vis-à-vis de leur propre intérêt. Un collègue intégrateur ayant tout intérêt à ne pas être négatif pour éviter toute modification de travail !
• Des étudiants : pratique, car toujours à la recherche d’argent !

Un lieu clos doit être choisi, ainsi qu’un logiciel d’enregistrement de la session tel que Camstudio. Sélectionnez ensuite un observateur : il aidera les utilisateurs si des problèmes techniques arrivent, pour répondre à ses questions, incitez celui-ci à parler à voix haute tout en lui proposant étapes par étapes le scénario. Il doit être présenté comme détaché du projet pour éviter de biaiser les réponses de l’utilisateur. Attention également à ne pas donner d’indices sur une fonctionnalité à l’utilisateur, exemple : « recherchez des billets de train »

Un scénario d’accompagnement de l’utilisateur doit être préparé en amont pour l’aider dans les tâches qu’il devra réaliser. Une tâche c’est un contexte et un objectif. Un scénario pour contextualiser un achat, une inscription par exemple. Et un objectif correspondant que l’utilisateur peut lui-même valider : « j’ai réussi à commander cette paire de chaussures » quitte à ce que cela soit faux ! Un bon démarrage peut être tout simplement la description de ce que voit l’utilisateur : type de site, fonctionnalité présente sur la page, etc. Prenez des notes après chaque session pour optimiser le debrief avec le chef de projet effectué en fin de la journée de test.

Finalement, le seul coût de l’opération est la rémunération de l’utilisateur, 40 euros semblent être une bonne moyenne, que cela soit en bon d’achat ou en cash suite avec une note de frais (tout dépend de votre comptabilité !). Pensez aussi que les lieux publics tels que le bon vieux Starbucks coffee et les tests utilisateurs à distance sont des options tout à fait envisageables ! On notera sur ce point des sites utiles tels que Appili en français (25^e par utilisateur) ou Youeye en anglais qui possédera bientôt une fonction de EyeTracking pour utiliser à distance la webcam de l’utilisateur.

Bref, faîtes des tests, que cela soit fait par vos soins, ou ceux d’une agence, cela vous évitera de toute façon des coûts bien plus importants par la suite et les éternels V3,V4,V5 !

Petite arithmétique de l’UX : choisir, renoncer, construire

Restons « User Centric » avec cette formation très intéressante pour « épurer » efficacement et avec pertinence votre site internet durant sa création ou sa refonte. On démontrera ici l’utilité de la méthode S.H.E pour « Shrink » (réduire) Hide (cacher) et Embody (personnifier).

Tout d’abord, il va falloir choisir le nombre de fonctionnalités pour éviter d’avoir des multi-tools « qui en jettent » et peu utiles au final pour l’utilisateur. Plus facile à dire qu’à faire, car dans cette étape de réduction on se confronte :

• À nous-mêmes, créateurs de site internet.
• À l’utilisateur, attaché par habitude à des fonctionnalités.
• À la concurrence : si elle fait beaucoup de choses, je ne peux pas en faire moins !

Comment faire alors ? Lister une fonctionnalité et comparer sa valeur à son coût en « Journée Homme ». Vous verrez dans le mapping ci-dessous le résultat du comparatif de chaque fonctionnalité : certaines auront beaucoup de valeur, mais seront très compliquées à mettre en œuvre (coût élevé), d’autres auront une valeur limitée et un cout élevé (poubelle), d’autres encore auront beaucoup de valeurs et seront très simples à mettre en place (the best ones !).

Pour réduire sa sélection on peut : prioriser, raconter une histoire, penser « mobile first » tout en gardant dans l’esprit que l’instinct ne doit pas être brimé dans cette démarche !

• Cacher permet de faciliter le travail d’attention sélective, certaines fonctionnalités sont évidentes dans cette démarche : menus déroulants, apparition d’éléments uniquement au survol.
• Personnalisez, simplifiez avec des icônes et en pensant à l’opposition entre l’agencement dans l’espace (un écran, x rubriques) VS l’empilage dans le temps (x écrans, 1 rubrique) dans le but d’optimiser l’expérience utilisateur.

Petite note de fin, « l’usabilité » d’un site est une affaire d’ergonomie alors que la simplification est une affaire d’UX design (User eXperience design).

HTML5

Deux formations distinctes ont été proposées : une sur les API HTML5 et une autre sur les nouvelles possibilités des formulaires.

Du coté des formulaires, l’intervenant a démarré sa session avec un parti-pris très clair sur les webkits qui sont des bibliothèques logicielles permettant aux développeurs d’intégrer facilement un moteur de rendu de pages Web dans leurs logiciels. En trois mots : « C’est à prohiber ! ». S’en est suivi un listing d’attributs pour améliorer l’expérience utilisateur dans un formulaire tel que :

• @autofocus : pour donner le focus d’un élément
• @placeholdfer : pour afficher un texte donnant un indice sur le contenu à rentrer (input et texte area)

Du coté des APIs on listera :

• Les Websockets : pour avoir une communication bidirectionnelle entre le serveur et le client.
• File API : possibilité de lire directement côté client le contenu des fichiers sans avoir à passer par le serveur
• vidéos API : avec les formats H264 (bourrés de brevets) et WebM (open source). La vidéo se comporte comme un élément HTML, libre à vous de lui donner toutes les compétences CSS ou SVG que vous souhaitez ! À noter un media framework pour synchroniser à une vidéo avec tout type de marqueurs : http://popcornjs.org/
• History API : pour gérer l’historique plus efficacement qu’en Ajax avec la méthode pushState.
• Le format JSON : pour transférer à peu près n’importe quel objet JavaScript valide en chaîne de caractère et de faire la transformation inverse.
• La technologie Apcash pour permettre l’utilisation du site lorsque l’on est hors ligne.
• Les incontournables Canvas : tueront-ils la technologie Flash dans le futur ?
• pdf.js : pour garantir l’intégration de format PDF sans l’utilisation de plug-in.
• La technologie WebGL : pour des rendus 3D plus que bluffants (ex : http://bodybrowser.googlelabs.com/ pour regarder le corps humain sous tous les niveaux. Toujours, en bêta test malheureusement…)

Le vrai défi du HTML5 a clairement été soulevé en fin de formation : une utilisation globale, répandue et stable. Bref, il faut le démocratiser !

Un bug à la fois

Un intervenant a sensibilisé l’assistance sur le problème de l’XML parsing du point de vue du navigateur Opera. Avec un message fort pour les intégrateurs : créer des hacks est une mauvaise politique et l’utilisation de librairy « funky » présente plus de risques que d’avantages ! Opera comme tout navigateur est confronté à un insight récurrent de la part des internautes : « si cela ne marche pas c’est la faute de mon navigateur, pas celle du site internet ! »

Les lighting Talks

Une très bonne surprise pour ma part, 10 intervenants présentent durant 4 min top chrono un point de vue, un fait en rapport au web.
@Karlpro remporte la compétition à l’applaudimètre avec son étonnante démonstration : comment faire un sac de laptop avec un jean !

Suivi par deux ex-aequo proposant pour l’un un fait absurde : Pas De Liens Sans Autorisation, ou comment informer que de nombreux sites obligent, selon leurs mentions légales, les internautes à les informer avant de poster un lien hypertexte ! Tel que Facebook, Google, Twitter… Le second ex-aequo nous propose le concept hilarant du G.A.O : les best practices de la Glande Assisté par Ordinateur. 25 min de travail, 5 min de pause !

Voilà pour le long debrief de cette première journée de formations à ParisWeb, deuxième session ce matin que vous pouvez suivre en live ici !

Mais qu’en est-il réellement et quelles sont les limites de cette utilisation ?

Cette technologie utilise les fonctions Javascript pushState() et replaceState(), utilisables uniquement sur le moteur web Gecko 2. Et oui ! C’est uniquement compatible Chrome (min v5), Firefox (min v4), Opéra (min v11.5) et Safari (min v5). Internet Explorer n’est pas dans la liste, ni-même sa version 10 et encore moins la 9 !

Après cette petite introduction, donnons tout de suite un exemple simple d’utilisation. Suivez bien :

Je suis sur une page A.html. J’ai un lien dans cette page qui me mène vers la page B.html, comme cela pourrait être le cas dans un menu de navigation. Je désire charger en Ajax le contenu de B.html afin de fluidifier un peu tout ça. Je vais donc récupérer en Ajax la page B.html, avec la méthode .load() de JQuery par exemple.

Jusque-là, rien d’innovant. L’un des problèmes de ce type de navigation est que si je fais « précédent » avec mon navigateur, je ne retomberai pas sur le contenu précédent, c’est à dire A.html. Pourquoi ? Etant donné qu’en appelant en Ajax le contenu de B.html, je n’ai pas bougé de ma page A.html. Donc le bouton précédent ne fera que me ramener sur la page où je me trouvais avant A.html. Vous comprenez facilement la limite de cette exemple au niveau ergonomique.

C’est là qu’intervient la fonction de manipulation de l’historique du navigateur. Quand je charge ma page A.html, j’exécute la fonction history.replaceState() en lui donnant en paramètre l’URL de la page, c’est-à-dire A.html. Au moment d’appeler B.html en Ajax, je fais un history.pushState() en lui plaçant en paramètre l’URL que je demande, B.html. Je crée ainsi une nouvelle entrée dans l’historique de navigation de mon navigateur. Tout le monde a suivi ?

Pour activer la navigation par le navigateur avec le bouton « précédent » et « suivant », je fais la fonction suivante :

$(window).bind(‘popstate’, function(event) {

var state = event.originalEvent.state;

if (state) {
$(« #ma_div_ou_je_charge_mon_ajax »).load(state.path);
}
});

J’ai donc placé un écouteur sur les évènements du navigateur afin d’afficher ce qui est demandé.

Niveau SEO :

Au niveau du SEO, c’est parfait ! J’ai uniquement appelé le contenu qui m’intéresse de B.html. J’ai bien deux pages distinctes A.html et B.html dans mon arborescence et les robots indexeront bien les deux pages. Si je désactive le Javascript, j’ai un lien classique de A vers B qui affichera la page demandée avec un rechargement du navigateur comme dans une navigation classique.

Inconvénients :

C’est assez difficile à mettre en place. Les navigateurs ne réagissent pas tous pareils à cette manipulation. En effet, il existe un problème sur Chrome. Je suis sur A.html, j’appelle la page B.html, puis ensuite tape une URL à la main vers un site externe. Si arrivé sur cette nouvelle page je fais précédent avec le navigateur, je retombe sur la page B.html en entière et non plus A.html avec l’importation du contenu de B. Il existe donc une méthode pour remédier à ce problème, mais on n’entrera pas dans les détails ici et elle est assez lourde.

Conclusion :

Grâce à cette technique, on peut créer une navigation très fluide en Ajax, tout en conservant la navigation par les actions du navigateur. Cette technologie se rapproche de ce qu’offre Flash au niveau de la fluidité. Comme toutes les bonnes choses, c’est à consommer avec modération. Nous avons bien vu dans les inconvénients, que cette méthode est encore au stade expérimental. Voici une application concrète de cette méthode sur le site Github. Regardez le chargement du contenu lorsque l’on clique sur un fichier dans le tableau. Testez la navigation par vous-même. Ceci dit, nous repoussons sans cesse les limites de nos navigateurs afin d’en tirer le meilleur. C’est ce genre de pratique qui pousse les concepteurs de navigateurs à améliorer leurs applications et repousse un peu plus la technologie web.

Cela vous est sans doute déjà arrivé : un beau matin, en vous connectant à l’un de vos sites favoris, vous vous apercevez que ce n’est plus comme avant et vous vous sentez troublé. Vous tâtonnez pour retrouver ce pour quoi vous êtes venus, et même pire, au-delà des problèmes liés à l’ergonomie, vous trouvez le tout vraiment très laid. Et oui… enterrer vos utilisateurs les plus fidèles est un des plus gros risques d’un redesign de votre site internet.

Bien entendu, plus un site comporte de fonctionnalités et de pages plus les risques sont importants. Mais même un site de plus petite envergure, peut se faire descendre par la critique s’il ne tient pas compte des attentes de ses visiteurs. C’est pourquoi nous vous proposons un billet inspiré de ce très bon article du site webdesignerdepot.

La question mérite d’être posée : pourquoi, quand et comment bien redesigner ?

Le guide suivant devrait vous aiguiller sur le droit chemin pour recréer et repenser votre site tout en satisfaisant vos utilisateurs. Et si jamais vous êtes actuellement dans le cas d’une refonte échouée, il n’est pas trop tard ! On pourra tout de même vous donner un coup de pouce.

Faire du neuf avec du vieux, le problème de la refonte

Quand vous décidez qu’une refonte est nécessaire pour votre site internet, il y a énormément de paramètres à prendre en compte, au-delà des simples aspects techniques.

Souvenez-vous que votre site est déjà régulièrement visité, et a sans doute des utilisateurs réguliers. Ces derniers ont des attentes particulières lorsqu’ils visitent votre site. Vous avez besoin d’avoir de bonnes raisons pour changer tel ou tel process/fonction/élément graphique. Vous devez en tenir compte aussi bien au début que tout le long du processus.

Communiquez avec vos utilisateurs actuels
Contrairement à une création ex-nihilo, un redesign de site possède déjà une base utilisateurs.  Faire participer ces derniers dès le début de votre remaniement ne pourra jouer qu’en votre faveur. Après tout, ce sont ces personnes qui utilisent votre site, et qui y sont déjà familières. Bien entendu, vous tomberez toujours sur d’irréductibles internautes, complètement fermé à toutes formes de changements, mais d’autres pourront vous donner un aperçu intéressant de comment ceci pourrait être amélioré, ou bien comment cela aurait besoin d’être modifié.

Il est important de tenir compte de la manière dont les internautes utilisent votre site avant la refonte. La façon dont vous voudriez qu’ils utilisent vos outils n’est pas forcément en accord avec la vraie utilisation qu’ils en font. Prenez cela en compte quand vous redesignez et prenez garde de ne pas briser les habitudes de navigation de vos utilisateurs sans une excellente raison.

Testez à la fois pour les futurs et les anciens utilisateurs
On pourrait croire qu’il faut tester votre nouveau design uniquement sur les futurs utilisateurs pour obtenir les meilleurs résultats. Ne connaissant pas le design, ils ne sont justement pas influencés par l’existant. C’est une bonne stratégie si vous redesignez quelque chose comme une fiche produit sur un site e-commerce (le but ici est d’attirer de nouveaux clients). Mais si vous réaménagez un site entier, vous avez besoin du feedback des gens qui utilisent actuellement votre site. La dernière chose dont vous avez besoin, c’est de faire fuir tous vos utilisateurs.

Vous pouvez par exemple laisser entendre que vous testez un nouveau site. Offrez leur le choix de le tester et soumettez-leur un questionnaire non-intrusif, ou un mécanisme similaire pour recueillir ce qu’ils en ont pensé.

Laissez les utilisateurs changer l’interface selon leurs propres envies
Ce point est particulièrement important pour les sites “outils”. Laisser les utilisateurs switcher entre la nouvelle et l’ancienne interface selon leur convenance est la meilleure façon de se prévenir des plaintes. Les sites de médias sociaux sont surement les meilleurs exemples pour illustrer cette facette (comme le fait Twitter avec la possibilité de retourner sur l’ancienne interface). Laisser-les changer à leur rythme, cela évitera les mauvaises surprises et la frustration.

Il est par contre important d’imposer une deadline pour effectuer ce switch. Faites-vous bien comprendre des utilisateurs : ils doivent assimiler qu’ils peuvent changer autant de fois qu’ils le veulent tant que la deadline n’est pas atteinte, mais qu’après, la nouvelle version s’appliquera à tout le monde. Cela évitera à quelques trainards de rester indéfiniment sur l’ancien site.

Facilitez l’envoi de feedback après la refonte
Il existe pléthore d’outils pour collecter les impressions des utilisateurs. Utilisez-les et trouvez ce que vos visiteurs aiment ou n’aiment pas. Ensuite, assurez-vous de relever tout ce qui est soulevé par plus d’une poignée de visiteurs. Rappelez-vous : pour chaque visiteur qui exprime un besoin ou un souci, il pourrait y en avoir des dizaines qui ressentent la même chose sans rien dire.

Exprimez clairement vos raisons
Il est important d’énoncer à vos utilisateurs quelles raisons vous ont poussé à la refonte. Beaucoup d’internautes qui ne sont pas familiarisés avec les aspects techniques liés au fonctionnement, pensent que la refonte existe pour des raisons purement esthétiques. Faites-leur savoir quelles fonctionnalités vous comptez ajouter ou bien ce que les améliorations d’interface utilisateur vont apporter. Un billet de blog, expliquant votre plan de redesign peut être un bon moyen d’ouvrir le dialogue.

Proposez un tutoriel expliquant les changements majeurs
Si vous changez le fonctionnement de votre site ou si vous procédez à des modifications drastiques des éléments des pages, cela serait une bonne idée d’offrir une vidéo, un schéma, ou n’importe quel autre support faisant le tour des nouvelles caractéristiques du site. Cela aidera les utilisateurs à s’adapter plus rapidement aux nouveautés et de ne pas se sentir perdus. De plus, cela donnera l’impression que vous vous souciez d’eux, et que vous voulez que leur expérience soit aussi bonne que possible.

Que faire si votre refonte a déjà échoué ?

Donc, vous venez de mettre en ligne votre design retravaillé, malheureusement à part des plaintes, rien de bon ne ressort, aussi bien de la part des anciens utilisateurs que des nouveaux venus.
Que devez-vous faire ? Devez-vous retourner sur l’ancienne version ?
Que faire si ce n’est pas une option, ou que vous avez investi des milliers d’euros et des mois dans le nouveau site ?

Tout est question de contrôle
La première chose que vous devez faire est de reconnaître que votre refonte n’a pas répondu aux attentes des internautes. Faites savoir aux gens que vous entendez leurs revendications et que vous vous souciez de leurs préoccupations. Que vous le fassiez grâce à Twitter, votre blog, ou tout autre support, dépend essentiellement de l’endroit depuis lequel vous pouvez atteindre le plus grand nombre de vos utilisateurs.

Identifier et traiter les plaintes
Cibler les plaintes spécifiques si vous le pouvez. Si tout le monde se plaint de combien telle ou telle fonction est difficile à trouver, répondez-y immédiatement. Il existe plusieurs façons de le faire : vous pouvez simplement poster sur votre blog ou envoyer un courriel contenant toutes les informations utiles. Vous pouvez également re-procéder à un changement dans l’ergonomie, l’arborescence ou le design pour rendre cette fonction plus facile d’accès. Si c’est vraiment un gros problème, faire un changement est probablement la meilleure solution.

N’ayez pas peur de revenir en arrière
S’il y a des plaintes énormes, ou si vous constatez une baisse de trafic fulgurante, n’ayez pas peur de downgrader tout ou partie de votre site. Du moins jusqu’à ce que des correctifs puissent être appliqués. Si le succès de votre site souffre à cause de la refonte, il n’y a aucun sens à continuer sur cette voie. Il est préférable de faire marche arrière en reconnaissant l’insatisfaction de vos visiteurs  (et donc montrer que vous placez l’expérience utilisateur avant tout) plutôt que d’insister aveuglément.

Surveillez attentivement

Chaque fois que vous lancez un nouveau design, il est important de suivre attentivement tout ce qui « entre » et « émane » de votre site.

Voici les points principaux à ne pas laisser de côté :

• Définissez des objectifs pour les différentes fonctions/pages de votre site (cette page doit avoir X taux de conversion, ne doit pas avoir un taux de rebond supérieur à X %, etc.) et assurez-vous régulièrement que le flux de visiteurs ne chute pas brutalement.
• Les différents outils d’analyse (Google Analytics pour n’en citer qu’un) peuvent vous aider dans ces tâches. Suite à l’analyse, ils permettent d’effectuer des changements proactifs sur votre site, anticipant ce que les visiteurs pourront éventuellement vous reprocher.
• Assurez-vous en permanence de recueillir les informations d’analyse de base pour vous donnez des repères sur l’évolution de ces données.
• Également surveillez le ton des messages postés sur les médias sociaux au sujet de votre restructuration. Si vous voyez beaucoup de plaintes, ou même beaucoup de confusion, il faut être proactif et ne pas hésiter à engager la conversation.
• Laisser couler est le meilleur moyen de provoquer un « bad buzz ». Il est important d’informer au mieux vos utilisateurs pour qu’ils sachent que les changements effectués sont fait en leur faveur et pas dans un but indéfini.

Co-écrit avec Nicolas Bayard.

Au cours de la chaîne de création d’un site internet (ou d’un projet web plus généralement) le webdesigner est amené à interagir avec d’autres métiers. Pour une fluidité dans les échanges, il est important de tenir compte des contraintes des autres intervenants qui vont utiliser votre travail.

Ceci nous amène à notre problématique : comment faciliter le workflow en tant que webdesigner ? À quels niveaux chacune de mes décisions va impacter la chaîne de création d’un site internet ?

Nous nous attarderons principalement sur les interactions avec le référenceur et l’intégrateur (celles avec les autres métiers étant plus réduites, voire inexistantes).

Prise en compte des collaborateurs

Vous remarquerez que souvent nous débordons du cadre du design pur et dur, cela reste pertinent avec le fait que le workflow d’un projet web constitue un ensemble, divisé en multiples interactions. Si le designer interagit avec d’autres personnes, la réciproque est aussi vraie. Certains des points abordés serviront donc également à d’autres rôles.

Interactions avec le référencement

Bien que le design n’impacte pas beaucoup le référencement, il est souvent amené à structurer l’information et à créer une navigation ergonomique. Dans ces cas précis, le designer doit faire attention à ne pas créer de points bloquants pour l’accessibilité et la navigation des internautes ainsi que des moteurs de recherche sur le site.

Cela peut passer par plusieurs aspects :

• L’utilisation de Splash Page (page d’accueil d’un site ne présentant qu’une image ou une animation Flash et un lien d’entrée sur un site Web).  La Splash Page possède un certain nombre d’inconvénients :
  • elle retarde d’une page l’accès à l’information pour les visiteurs, leur proposant une page parfois pauvre en contenu.
  • elle offre également une page d’accueil difficile à référencer pour les moteurs de recherche, car elle ne contient pas ou peu de contenu référençable. Dans le pire des cas, le lien d’entrée est incrusté dans le Flash et il est donc impossible pour les robots de suivre le lien.
  • enfin, si l’image est de grand format ou si l’introduction en Flash est complexe, la page risque d’être longue à charger.

• L’utilisation abusive d’Ajax dans l’interface. Beaucoup d’ergonomes et de développeurs essayent d’impressionner les internautes en utilisant massivement cette technologie pour fluidifier la navigation, mais c’est souvent une erreur, car le contenu Ajax (chargé dynamiquement donc) ne peut pas être lu, donc indexé par les moteurs de recherche. Pour pallier à ce problème il faudrait idéalement créer une alternative à ce contenu, doublant le travail de l’intégrateur.

• L’utilisation de Flash : de la même manière, par souci d’esthétisme ou de navigation, du Flash est parfois implémenté dans la page. Les moteurs de recherche ne pouvant pas lire cette technologie, il est déconseillé d’en abuser, et le cas échéant, créer une alternative (encore une fois, double travail à effectuer).

Interactions avec l’intégrateur

Sans nul doute, c’est envers l’intégrateur que le designer a le plus de responsabilités. En effet, c’est en grande partie du graphisme que va dépendre la charge d’intégration. Bien entendu, le but n’est pas de restreindre son imagination sous prétexte que l’intégrateur aura plus de travail, le principal étant de répondre aux objectifs du site. Cependant, amis designers, gardez en tête que :

• Vous vous devez d’être le plus minutieux possible ! Pas question de maquetter seulement deux pages et de se dire que le reste se déclinera aisément tout seul. Les meilleurs sites sont pensés et dessinés du header de la page d’accueil jusqu’au footer de la plus profonde des pages. Ce souci du détail vous vaudra les louanges des intégrateurs. En effet, le designer fournit souvent la maquette de la page d’accueil et des grandes entrées, mais rarement des pages plus profondes. Il ne faudra pas s’étonner si l’intégrateur comble par lui-même ces « blancs ». Il est donc important d’avoir un design poussé et validé avant de commencer l’intégration. Il est plus facile de retoucher un détail sur Photoshop plutôt que bidouiller « on the fly » pendant la phase de développement.

• Vous devez prendre en compte la charge de temps qui vous est attribuée ! Si vous êtes face à des deadlines assez courtes, ne vous lancez pas dans un webdesign et/ou une navigation trop sophistiqués. La création peut s’avérer très chronophage, et ainsi retarder un planning (pensez au chef de projet, avez-vous déjà essayé de tout décaler sur un Gantt ?). Au bout de la chaîne, ce sont souvent les intégrateurs/développeurs qui trinquent, en devant intégrer et/ou développer vos chefs-d’œuvre en un temps record afin de ne pas cumuler toujours plus de retard. La créativité à outrance joue souvent contre un planning serré. De plus, la simplicité et la sobriété peuvent être tout aussi importantes (pour ne prendre qu’Apple en exemple).

• Soulevons également le problème des typographies. Il est en effet souvent plus sympathique pour un designer d’utiliser des typographies exotiques afin de donner du relief à sa page et de titiller notre rétine en changeant de l’habituel Arial. Seulement voilà, même s’il existe actuellement beaucoup de techniques pour utiliser d’autres polices (font-face, cufont.js, etc.) que les typos web, aucune n’est parfaite, et cela causera toujours des soucis d’intégration selon la configuration et le navigateur de l’internaute. Et là encore on ne parle pas du temps supplémentaire que prendra l’intégrateur : pensez donc à voir avec lui si la police de votre choix est intégrable.

Enfin, voilà quelques détails souvent mis à la trappe mais primordiaux pour que le travail soit fait proprement et pour éviter toutes confusions et aller/retours inutiles :

• évitez d’être trop farfelu ou extravagant pour le design d’un site hyper dynamique qui contiendra de nombreuses pages différentes (site de e-commerce, site immobilier…). Le but de ces sites étant avant tout de convertir, le design ne doit pas prendre le dessus sur le produit. D’autant que le temps de chargement de ce genre de site est un critère déterminant.

• faites attention aux effets difficiles à intégrer et  à rendre cross browser (ombres portées, dégradés, coins arrondis, etc.)

• lorsque vous dessinez des boutons, faites bien attention à fournir à chaque fois les trois états possibles (normal, hover et active). En effet, cela n’incombe pas à l’intégrateur de deviner comment vous auriez dessiné les états manquants.

• triez et nommez vos calques ! Cela fait perdre du temps à l’intégrateur de se plonger dans le découpage d’une maquette où rien n’est nommé et où aucun calque n’est rangé.

Ces listes de conseils sont bien entendu non exhaustives et visent seulement à vous faire comprendre la synergie qu’il existe entre chaque membre d’un projet web.

Conseil ultime : apprenez le CSS !

Voila le point essentiel qui adoucira le passage de votre travail à celui de l’intégrateur. En effet, si vous n’êtes pas familiarisé à coder vos propres design, vous ne pouvez pas comprendre toutes les contraintes s’attachant à ce langage. Apprendre à intégrer changera votre façon d’aborder un design car vous aurez une meilleure compréhension de ce qui est possible ou complexe à réaliser pour l’intégrateur. De cette manière, la transition entre le design et le code se fera plus aisément. De plus, vous serez plus proches et pourrez mieux répondre aux attentes de l’intégrateur, maintenant que vous parlez tous deux le même langage. C’est un point crucial, vous donnant plus de valeur ajoutée et qui fera facilement la différence entre deux designers lors d’un projet web.

Nous finirons cette partie en insistant sur l’importance d’avoir une vision globale d’un projet et de son équipe. C’est en pensant un site internet comme une chaîne où chaque ressource est complémentaire qu’on en fait un lieu plus accessible, attractif et mieux conçu.

Co-écrit avec Nicolas Bayard

Facilité par l’émergence de nouvelles technologies favorisant la création de sites possédant une réelle identité graphique recherchée (HTML5/CSS3, Flash, Jquery…), le webdesign est devenu un outil de marketing efficace et  financièrement accessible.

A la base un outil de mise en forme simple visant à rendre un site « beau » et « agréable », le webdesign est désormais un outil puissant stimulant encore plus la concurrence : il faut avoir un design attirant et original à la « mode », tout en affichant une image de marque forte. Ainsi la majorité des entreprises ont changé leurs stratégies et adoptent une identité graphique recherchée en phase avec leur cible, ainsi que le message à véhiculer pour transformer le visiteur en acheteur.

Ce dossier n’est pas destiné à justifier l’utilisation d’un bon design (inévitable de nos jours), il s’agit plutôt de mettre en exergue les démarches à faire tant vis à vis du client que de l’internaute pour (re)proposer un webdesign adapté à un domaine d’activité.

Nous garderons aussi à l’esprit que le webdesign n’est pas qu’une façade colorée : c’est une activité en synergie avec d’autres métiers liés au web, et il y a donc des habitudes à prendre pour faciliter le workflow.

Gestion du client et prise en compte de l’internaute

Lorsque nous sommes face à une demande de webdesign, il s’agit souvent de proposer une orientation graphique qui plaît au client sans réellement prendre en compte l’internaute. Et si celui-ci est considéré, c’est bien souvent les goûts du client et du designer qui ont plus de poids que l’opinion de l’internaute.

Sensibiliser  et bien comprendre le client

Le client n’a pas forcément les mêmes connaissances que nous, son expérience est différente de la nôtre et il ne sait pas toujours vraiment ce qu’il veut. Il est de notre ressort de définir quel serait la meilleure façon de designer le site sans pour autant ignorer son opinion : si vous voulez faire mouche plus facilement avec vos premières propositions, il peut être très utile de rédiger un brief créatif à l’intention de votre client pour mieux cerner ses propres goûts et faire parfois apparaître de nouvelles problématiques qui ne s’étaient pas posées auparavant.

Ce brief permet de sonder l’esprit du client en posant des questions très simples :

• Quelles philosophie ou valeurs associez-vous à votre concept ?
• Quel est l’objectif (autre que faire des bénéfices) affiché par votre site ?
• Comment décririez-vous votre site en 3 idées ? En 3 adjectifs ? en 3 verbes ?
• A qui parle-t-on ?
• Quel est selon vous votre cœur de cible ?
• Quel serait l’objectif principal, en une phrase, d’un internaute qui utiliserait votre site ?
• Qu’attend en premier un individu, en une phrase, qui utilisera votre site ?
• Quels sont les points faibles, et les points forts de votre site?
• En quelques mots, en quoi votre site se distingue-t-il de ses concurrents ?

Bien entendu le client est toujours roi, mais même si une proposition de webdesign remplit les objectifs donnés et correspond au besoin, il faut garder à l’esprit que c’est le point de vue de l’utilisateur final qui déterminera si un projet web est un échec ou une réussite. C’est pour cela qu’il faut anticiper la réaction de l’internaute dès le moment où il arrive sur le site et sensibiliser le client sur l’importance de la prise en compte du futur utilisateur.

Il faut donc, dans un premier temps, faire comprendre au client que ce sont les goûts de l’internaute qui priment sur ses propres caprices : comment générer du trafic et augmenter les ventes si le visiteur ne s’identifie pas au site, ou pire, le trouve tout simplement laid ?

La rédaction d’un dossier d’étude vous aidera beaucoup dans cette démarche, outre prouver au client par a + b que votre choix est meilleur qu’un autre, il lui permettra aussi de prendre du recul sur son projet et favorisera l’émergence de nouvelles idées (tant au sein de l’équipe de création que du client).

Un dossier d’étude de webdesign classique se construit généralement par des analyses  graphiques et ergonomiques, suivies de recommandations. Pour avoir des bases plus solides, vous pouvez également aller au delà du simple benchmark graphique et analyser la direction artistique prise par vos concurrents pour satisfaire la cible, c’est à dire comment répondre graphiquement à une problématique donnée.

Analyser les gouts de l’internaute

Dans ce dossier, il est d’usage de faire quelques recherches sur la cible, mais celles-ci sont trop souvent centrées sur la tranche d’âge concernée et le type d’internautes (homme, femme, étudiant, cadre…).

Avant toute proposition de webdesign, il est donc préférable d’accompagner votre dossier d’un « profil idéal d’utilisateur » pour justifier vos choix d’orientation graphique.

L’objectif est de dresser un profil psychologique de l’internaute en utilisant des questions simples permettant de mieux cadrer sa personnalité et ses goûts. Soyez inventifs, communiquez sur votre image de marque, posez des questions inattendues et montrez que vous vous intéressez à leurs opinions ! Vous pouvez par exemple leur demander de décrire votre nouveau site en trois adjectifs, de lui associer une ou plusieurs couleurs, qu’est-ce que l’internaute attend du service qui va lui être proposé, qu’est ce qu’il aime (ou n’aime pas) voir et lire sur le site, et quels types de fonctionnalités il préfère voir mis en avant sur le site ? C’est en quelque sorte un brief créatif à l’intention de vos futurs visiteurs.

Le designer doit bien comprendre qui est la cible que désire viser le client et quels sont les besoins réels de l’internaute. Cela permettra au designer de savoir sur quels éléments il devra le plus se concentrer et ceux qu’il devra éviter. On évitera par exemple une identité graphique trop chargée et trop poussée quand c’est le profil même de l’utilisateur qui construit le contenu d’une page (c’est le cas de Facebook ainsi que LinkedIn).

Comme outil d’analyse, n’hésitez pas à proposer au client le lancement de sondages sur les réseaux sociaux afin de déterminer ce qu’attend l’internaute ou bien le lancement d’une version béta pour avoir des retours avant le lancement de la version finale.

Une fois les goûts de l’utilisateur cernés, le designer doit prendre en compte le contenu du site par rapport au message à faire passer à l’internaute : quel est l’intérêt de réaliser un webdesign hyper créatif et très à la mode si l’utilisateur ne trouve même pas ce qu’il est venu chercher ?

Il est ainsi très important de bien hiérarchiser l’information et mettre en exergue les éléments les plus importants aux yeux du visiteur pour l’encourager à explorer le reste du site. Même si ce point est plus apparenté à de l’ergonomie que du design pur, prendre en compte l’accessibilité et la navigation du site lorsque l’on réalise un webdesign évitera plus tard de perdre bêtement un visiteur ayant éprouvé des difficultés à naviguer. Essayez donc d’enrichir le site d’éléments de navigation intuitifs et évitez de surcharger la page d’une pléthore d’éléments graphiques qui ne feront qu’agacer l’internaute.

Au final, en analysant simplement ce qu’aiment voir et lire les internautes et en sensibilisant le client sur l’importance de diriger ses efforts vers l’expérience l’utilisateur, on peut plus facilement proposer des orientations graphiques originales qui rempliront les objectifs initiaux.

Rendez-vous la semaine prochaine pour la deuxième partie du dossier !

Ce dossier s’articulera sur trois parties  :

Partie I : Gestion du client et prise en compte de l’internaute
Partie II : Le webdesign : un travail d’équipe
Partie III : Faire du neuf avec du vieux, le problème de la refonte

Co-écrit avec Geoffrey Mathern

Le design du site s’adapte à l’écran du périphérique utilisé. Tout cela à partir d’une url unique.

Donc fini les sous-domaine inutile m.exemple.com ou bien encore http://www.synerghetic.net/mobile/

Une url unique permet de résoudre les problèmes de référencements liés à la duplication du contenu sur des sous-domaine.

Je vais à présent revenir sur des points plus techniques abordés lors de ma conférence au pôle mobile de Synerg’heTIC.

Media queries

Les medias queries sont des techniques utilisées en CSS3. Elles permettent de définir une feuille de style en fonction de certaines propriétés du navigateur. Pour faire du responsive design nous allons utiliser la propriété max-width, qui permet d’appliquer une taille maximale d’écran, jusqu’où les feuilles de style seront appliquées.

@media screen and (max-width:480px){
    /*code */
}

Ici, on pourra par exemple modifier les différents blocs de note site pour leur appliquer une largeur relative à taille de notre écran.

@media screen and (max-width:480px){
    div{ width:90%;}
}

jQuery mobile

Certains associent directement responsive design avec les media queries. Mais je rappelle que le principe est d’adapter le site en fonction de l’appareil utilisé.

On peut donc utiliser un framework tel que jquery mobile pour réaliser note site. On peut l’utiliser exclusivement pour l’affichage sur iPhone et Android comme dans l’exemple suivant en PHP :

if ( strstr($_SERVER['HTTP_USER_AGENT'],'iPhone') || strstr($_SERVER['HTTP_USER_AGENT'],'Android') )
{
      //On charge jQuery mobile
}

Voici deux exemples de site en responsive design :

• Avec les media queries : Cuisine kawaii le livre
• Avec jQuery Mobile (sur iPhone et Android) : Développeur web mobile

Pour la troisième fois consécutive, Synerg’heTiC proposait aux Junior-Entrepreneurs une formation intitulée « Concevoir et promouvoir son site Internet », animée par Audrey Wermeister, Julien Gouvernet et Adrien Pepin. L’objectif étant de transmettre notre expertise dans la conception et la promotion de site Internet.

Lors de chaque congrès, nous nous efforçons d’adapter le contenu de cette formation de manière à être en phase avec les attentes des Junior-Entrepreneurs. La difficulté qui s’impose à nous est de satisfaire à la fois les personnes issues d’une JE « ingénieur », au profil plus technique, ainsi que les personnes provenant d’une JE « commerciale ».

Au programme :

Concevoir et réaliser son site Internet

• Adopter une démarche réfléchie
• Concevoir : la phase de réflexion
• Réaliser : la phase concrète
• Recetter : la phase finale
• Etendre son offre : pensez mobilité

Promouvoir son site Internet

• Adopter une démarche structurée et cohérente
• Actionner les leviers
• Etudier les résultats et s’adapter

Do it yourself !

• Analyse et conseil en matière de communication online pour chaque Junior-Entreprise

C’est toujours avec grand plaisir que nous faisons cette formation et nous sommes impatients de remettre ça lors du prochain congrès national d’hiver ! D’ici là, n’hésitez pas à nous faire part de vos remarques dans les commentaires, sur Facebook ou Twitter.