Vu sur le web : quelques liens que j’ai parta­gés avec mes collègues

Diapo­ra­mas, carrou­sels et accor­déons : Le point de vue de Niel­sen
Formu­laires : Pourquoi les utili­sa­teurs ne remplissent pas les formu­laires d’ins­crip­tion
Carto­gra­phie de l’UX : Méthodes, livrables & savoirs   [SVG]  [PDF]

Mieux traduire les besoins utili­sa­teurs à l’équipe de déve­lop­pe­ment

En quelques mots :

  • Faites du maquet­tage fonc­tion­nel
  • Propo­sez une ciné­ma­tique d’écrans
  • Story­tel­ling
  • Docu­men­tez les fonc­tion­na­li­tés

Article origi­nal extrait de (Hélas ces deux liens sont morts) :

  • http://www.garga­rismes-ergo­no­miques.com/post/traduc­tion-besoin-utili­sa­teur
  • Démarche ergo­no­mique dans le cadre d’un projet : http://www.garga­rismes-ergo­no­miques.com/post/demarche-ergo­no­mique-projet-web

Messages d’er­reur : Article origi­nal (en)
Drag and drop sur le web : exemples et bonnes pratiques
Utili­sa­bi­lité des CMS : 5 (autres) points à réflé­chir
Rapport usabi­lity : Un (ancien) projet de norme
Sites gouver­ne­men­taux : Guide de concep­tion de formu­laire du Québec [PDF]
Un article sur les apps hybrides : Navi­ga­ting the Mobile App Deve­lop­ment Land­scape
Créa­tion de formu­laire : Smashing maga­zin fait le point sur les dernières évolu­tions
Fiche de lecture : Mobile first de Luke Wroblewski
Utili­sa­bi­lité des sites e-commerce : Niel­sen revient sur le sujet 11 ans après sa dernière étude
Écrire de la docu­men­ta­tion : Retour d’ex­pe­rience
Outil de mesure du contrast : Contrast Analy­ser
Rédac­tion de scéna­rios : Les 3 grandes étapes
Paru­tion d’une norme sur l’er­go­no­mie : La norme ISO 26800:2011
Inté­grer l’er­go­no­mie web en entre­prise : Quelques recom­man­da­tions
Bench­mark édito­rial : Quelques grilles à télé­char­ger
Boos­ter votre page d’ac­cueil : Quelques conseils de Laure Sauvage
Eye Tracking : Le diamètre pupil­laire
Concep­tion d’IHM : Métho­do­lo­gie
Persua­sive design : Vos premiers pas en persua­sive design
Une vision globale de l’ex­pé­rience utili­sa­teur : 3<sup>ème</sup> partie
Archi­tec­ture de l’in­for­ma­tion : Penser l’or­ga­ni­sa­tion d’un site web
Que faire avec le feed­back des utili­sa­teurs ? : Amélio­rez l’ex­pé­rience utili­sa­teur de votre site grâce à vos utili­sa­teurs
Nouvelles façon de déter­mi­ner la perti­nence d’une page web : Twikio : la fin du ranking à la Google ?
Article très commer­cial mais inté­res­sant : Eye Tracking en E-Marke­ting
Un article qui met les points sur les I : Humeur : tout le monde il est beau, tout le monde il est ergo­nome
Les bonnes pratiques de concep­tion : Zoning, wire­frame et proto­type
Menus affi­chés au survol : Pourquoi font plus de mal que de bien
Exemples de plan de test : Hand­book of Usabi­lity Testing 2<sup>nd</sup> Edition
Une liste de design patterns actua­li­sée : Design patterns, des librai­ries pour la concep­tion d’in­ter­face
Un utili­sa­teur découvre l’or­di­na­teur et le web : User Testing in the Wild: Joe’s First Compu­ter Encoun­ter
It’s the little things : How small frus­tra­tions can ruin a nice expe­rience
Life below 600px : There’s life below the fold
Writing micro­copy : The fastest way to improve your inter­face is to improve your copy-writing.
[Lien mort] RIA : Appli­ca­tion Web Ajax – Edition de cellules dans un tableau
Moteur de recherche en ergo­no­mie : Ergo­no­search

Moteur de recherche

Après excel­lente décou­verte de Geert (un livre à paraitre) : Search User Inter­faces

Et alors qu’a­vec Nico­las nous plan­chions sur les moteurs de recherche pour les nouvelles instruc­tions admi­nis­tra­tive et l’aide en ligne, j’ai donc lancé une petite recherche sur inter­net et voila ce que j’ai trouvé :

  • Offrir un bon moteur de recherche interne sur son site : Essen­tiel et diffi­cile !
    • Beau­coup d’in­ter­nautes utili­sant les moteurs de recherche y serait contrait par de mauvais sites (des sites dans lesquels il est diffi­cile de trou­ver l’in­for­ma­tion que l’on cherche) ;
    • Plus les inter­nautes utilisent les moteurs de recherche et moins ils ont de chance de trou­ver ce qu’ils cherchent ;
    •  » Dès lors on peut en conclure que pas de moteur de recherche vaut mieux qu’un mauvais moteur de recherche ;
    • Les utili­sa­teurs ne savent pas utili­ser correc­te­ment ni les opéra­teurs booléens ni les jockers ;
    •  » Dans un champs de recherche simple, l’opé­ra­teur doit impli­ci­te­ment être ET ;
  • À voir aussi un article très complet en 3 parties :

Webcre­di­bi­lity  : Tout savoir la webcre­di­bi­lity
Termi­no­lo­gie : Les inter­faces vocales

Les ancres

En lisant le blog de la société Belge AG consult, j’ai trouvé un article qui pour­rait nous donner un peu de matière pour le webguide :

  • Présen­tez les liens rapides en haut de page, sous le titre de la page, sous la forme d’un index.
  • Respec­tez les règles de cliqua­bi­lité.
  • Les ancres (liens sources) doivent être iden­tiques aux inter­titres (liens cibles). En d’autres mots, les titres dans l’in­dex doivent être libel­lés de la même manière que les titres qui appa­raissent dans la page.
  • Les inter­titres vers lesquels renvoient les ancres doivent graphique­ment ressor­tir et clai­re­ment faire appa­raître la hiérar­chie dans la titraille.
  • La première ancre doit renvoyer vers une zone encore visible dans le premier écran de sorte que l’uti­li­sa­teur comprenne qu’il a affaire à des ancres.
  • A droite des inter­titres, dans la page, propo­sez un lien souli­gné libellé « Haut » (ou l’icône d’une flèche vers le haut) pour permettre à l’uti­li­sa­teur de remon­ter à l’in­dex à partir de chaque inter­titre qui en fait partie.
  • Assu­rez-vous que les ancres renvoient l’uti­li­sa­teur au bon endroit de la page.

Une manière origi­nale de présen­ter des heuris­tiques : Charte des droits des utili­sa­teurs

Voici une charte qui provient du site d’Alain Robillard – Bastien, traduite d’après un article inti­tulé “A Compu­ter User’s Mani­festo” de Stephen W. Wild­strom.

  • L’uti­li­sa­teur a toujours raison. S’il existe un problème avec l’uti­li­sa­tion du système, il provient du système, pas de l’uti­li­sa­teur.
  • L’uti­li­sa­teur a droit à la faci­lité lors de l’ins­tal­la­tion de logi­ciels et d’équi­pe­ment infor­ma­tique.
  • L’uti­li­sa­teur a droit à des systèmes faisant exac­te­ment ce qu’ils sont censés faire.
  • L’uti­li­sa­teur a droit à des instruc­tions claires, simples et précises lui permet­tant de comprendre et d’uti­li­ser un système assu­rant l’at­teinte de ses objec­tifs.
  • L’uti­li­sa­teur a droit au contrôle absolu du système, de même qu’à être capable d’ob­te­nir l’at­ten­tion du système sur demande.
  • L’uti­li­sa­teur a le droit d’être informé par le système sur son état par rapport à la tâche qu’il effec­tue et par rapport au progrès accom­pli vers la complé­tion de la tâche, de façon claire, compré­hen­sible et précise.
  • L’uti­li­sa­teur a le droit d’être informé clai­re­ment quant aux spéci­fi­ca­tions requises pour utili­ser plei­ne­ment tout système infor­ma­tique.
  • L’uti­li­sa­teur a le droit de connaître les limites des capa­ci­tés du système.
  • L’uti­li­sa­teur a le droit de commu­niquer avec les four­nis­seurs de tech­no­lo­gies et de rece­voir des réponses utiles et intel­li­gentes à toutes ses ques­tions.
  • L’uti­li­sa­teur doit être le maître de la tech­no­lo­gie, non l’in­verse. Tout système doit être intui­tif et natu­rel lors de son utili­sa­tion.

Ergo / UX Mobile

Choi­sir entre une appli­ca­tion, native, web ou hybride : l’ana­lyse de Norman Niel­sen

Native, Web App, or Hybrid: Which Should You Choose?

Each of these types of apps has their advan­tages and disad­van­tages, as I’ve tried to point out. Let’s summa­rize them here.

Device features. Although web apps can take advan­tage of some features, native apps (and the native compo­nents of the hybrid apps) have access to the full para­pher­na­lia of device-speci­fic features, inclu­ding GPS, camera, gestures, and noti­fi­ca­tions.

Offline func­tio­ning. A native app is best if your app must work when there is no connec­ti­vity. In-brow­ser caching is avai­lable in HTML5, but it’s still more limi­ted than what you can get when you go native.

Disco­ve­ra­bi­lity. Web apps win the prize on disco­ve­ra­bi­lity. Content is a lot more disco­ve­rable on the web than in an app: When people have a ques­tion or an infor­ma­tion need, they go to a search engine, type in their query, and choose a page from the search results. They do not go to the app store, search for an app, down­load it, and then try to find their answer within the app. Although there are app aficio­na­dos who may fish for apps in app stores, most users don’t like instal­ling and main­tai­ning apps (and also wasting space on their device), and will install an app only if they expect to use it often.

Speed. Native apps win the speed compe­ti­tion. In 2012 Mark Zucker­berg decla­red that Face­book’s biggest mistake had been betting on the mobile web and not going native. Up to that point, the Face­book app had been a hybrid app with an HTML core; in 2012 it was repla­ced with a truly native app.

Instal­la­tion. Instal­ling a native or hybrid app is a hassle for users: They need to be really moti­va­ted to justify the effort. “Instal­ling” a web app involves crea­ting a book­mark on the home screen; this process, while argua­bly simpler than down­loa­ding a new app from an app store, is less fami­liar to users, as people don’t use book­marks that much on mobile.

Main­te­nance. Main­tai­ning a native app can be compli­ca­ted not only for users, but also for deve­lo­pers (espe­cially if they have to deal with multiple versions of the same infor­ma­tion on different plat­forms): Changes have to be packa­ged in a new version and placed in the app store. On the other hand, main­tai­ning a web app or a hybrid app is as simple as main­tai­ning a web page, and it can be done as often or as frequently as needed.

Plat­form inde­pen­dence. While different brow­sers may support different versions of HTML5, if plat­form inde­pen­dence is impor­tant, you defi­ni­tely have a better chance of achie­ving it with web apps and hybrid apps than with native apps. As discus­sed before, at least parts of the code can be reused when crea­ting hybrid or web apps.

Content restric­tions, appro­val process, and fees. Dealing with a third party that imposes rules on your content and design can be taxing both in terms of time and money. Native and hybrid apps must pass appro­val processes and content restric­tions impo­sed by app stores, whereas the web is free for all. Not surpri­sin­gly, the first web apps came from publi­ca­tions such as Play­boy, who wanted to escape Apple’s prudish content censure. And buying a subscrip­tion within an iOS app means that 30% of that subscrip­tion cost goes to Apple, a big dent in the publi­shers’ budget.

Deve­lop­ment cost. It’s argua­bly chea­per to deve­lop hybrid and web apps, as these require skills that build up on previous expe­rience with the web. NN/g clients often find that going fully native is a lot more expen­sive, as it requires more specia­li­zed talent. But, on the other hand, HTML5 is fairly new, and good know­ledge of it, as well as a good unders­tan­ding of deve­lo­ping for the mobile web and hybrid apps are also fairly advan­ced skills.

User Inter­face. Last but not least, if one of your prio­ri­ties is provi­ding a user expe­rience that is consistent with the opera­ting system and with the majo­rity of the other apps avai­lable on that plat­form, then native apps are the way to go. That doesn’t mean that you cannot provide a good user expe­rience with a web app or a hybrid app–it just means that the graphics and the visuals will not be exactly the same as those with which users may be already accus­to­med.

To summa­rize, native apps, hybrid apps, or web apps are all ways to cater to the needs of the mobile user. There is no unique best solu­tion: each of these has their strengths and weak­nesses. The choice of one versus the other depends on each compa­ny’s unique needs.

Écrans tactile : Luke W propose une réfé­rence des mouve­ments possibles [EN]
Contexte d’usage : l’art d’ima­gi­ner des scéna­rios
Ergo­no­mie mobile : Android : retour d’ex­pé­rience
Ergo­no­mie mobile : Respon­sive webde­sign : adap­ter un site à toutes les réso­lu­tions
Web mobile : Comment réagissent les utili­sa­teurs face à un site long à char­ger
Ipad & ergo­no­mie : Futurs usages du web et tablettes tactiles


Tests utili­sa­teurs

Séances utili­sa­teurs : indi­vi­duelle ou en groupe ?
Tests utili­sa­teurs ? : 5 argu­ments pour clouer le bec à votre client
Comment réali­ser un test utili­sa­teur en toute simpli­cité : Désa­cra­li­ser les tests d’uti­li­sa­bi­lité
Tests utili­sa­teurs : Docu­ment Word en anglais


Outils statis­tiques

  1. Une liste d’ou­tils statis­tiques gratuits Free Statis­ti­cal Soft­ware
  2. Une seconde liste Logi­ciels gratuits de statis­tique
  3. Un site dédié aux outils statis­tiques Bill Miller’s Free Statis­tics Site
  4. Une troi­sième liste Logi­ciels pour les statis­tiques
  5. Un outil statis­tique libre en ligne de commande (une réfé­rence) The R Project

Bonnes pratiques

Bonnes pratiques : Atten­tion danger !

Guides de style : Quel inté­rêt

Quelques guides de style

Orga­ni­sa­tion clas­sique d’un guide de style

  1. Contexte d’usage, connais­sance sur les utili­sa­teurs : Rappel des études concer­nant les utili­sa­teurs qui sont à l’ori­gine des choix faits par la suite.
  2. Prin­cipes de concep­tions, modèle d’in­te­rac­tions : L’in­ter­face va proba­ble­ment se baser sur un type d’in­ter­face exis­tant (WIMP, texte, hiérar­chique,…) ou s’ap­puyer sur du maté­riel spéci­fique comme un écran tactile, une télé­com­mande, etc… Cela crée un cadre spéci­fique et des contraintes pour la concep­tion.
  3. Règles de concep­tions : On peut rappe­ler là un certain nombre de règles trans­verses par exemple en ce qui concerne l’ac­ces­si­bi­lité, la protec­tion des mineurs, l’or­ga­ni­sa­tion de l’in­for­ma­tion, les raccour­cis claviers…
  4. Archi­tec­ture de l’in­for­ma­tion, Struc­ture des services : Des struc­tures types peuvent être propo­sées en fonc­tion de la complexité des services et de la struc­ture des données.
  5. Modèles d’écrans : Chaque type d’écrans est défini, ainsi que son bon usage, de la fenêtre prin­ci­pale, au dialogue en passant par la pop-up d’alerte à la pruden­ce…
  6. Éléments d’in­ter­faces : On arrive dans les détails, le plus impor­tant, qui permet de déter­mi­ner quel contrôle, quel élément il faut utili­ser dans quel cas. Ainsi que les éléments spéci­fiques à certains usages : calen­drier pour saisir les dates, contenu audio-visuel, etc…
  7. Graphisme, anima­tions, typo­gra­phies,… : Les éléments liés aux aspects visuels sont souvent regrou­pés, soit parce que l’in­ter­face est person­na­li­sable, soit parce qu’ils peuvent évoluer en paral­lèle des inter­faces.
  8. Annexes, index, etc…

Article origi­nal

Divers

Acces­si­bi­lité

Quelques extraits des WCAG 2 :

Réfé­ren­ce­ment

 


Dev web

Layout respon­sive : Une liste de paterns avec code à reprendre
Respon­sive, nouvelles tech­niques : et sa traduc­tion chez Open­web
Template HTML/CSS respon­sive Simple Stacks and Panels [en]
Mise à jours des codes twit­ters pour Word­press : Expli­ca­tion en Français
Prio­rité des opéra­teurs CSS : Expli­ca­tion chez Alsa­créa­tion
News­let­ter : Un e-mail en HTML respon­sive multi-clients
Favi­con : L’équi­valent pour Windows 8
Mise en page : Le modèle tabu­laire en CSS
Web séman­tique : Micro­data et Schema.org
Confi­gu­ra­tion serveur : Le fichier htac­cess
visua­li­sa­tion de données : 13 exemples
Métiers du déve­lop­pe­ment web : De l’in­té­gra­teur au déve­lop­peur front-end
Tous les navi­ga­teurs acceptent HTML5 et CSS3
Mise en page CSS avan­cée : La propriété display
HTML : centrer verti­ca­le­ment sur tous les navi­ga­teurs
HTML5 & CSS3 : Accep­tés par tous les navi­ga­teurs
Boutons exten­sibles : un exemple en CSS compa­tible tous navi­ga­teur
Outils pour webmas­ter : Les guide­lines de Google
CSS : Mise en page avan­cée grâce à la propriété display
Exemples d’in­fo­bulles en CSS : Examples of CSS ToolTips
HTML5 : HTML5 par l’exemple

CSS 2.1 : Ce que permet­tra l’aban­don d’IE6

L’aban­don prochain d’IE6 permet­tra enfin d’ex­ploi­ter plei­ne­ment les CSS2 et 2.1 qui, bien que CSS3 pointe le bout du nez, ne peuvent pas encore être plei­ne­ment utili­ser aujourd’­hui.

Cet article en français sur le site Brito­web et sa source en anglais sur le site 456 Berea Street mettent en avant quelques points inté­res­sants des CSS 2 que nous pour­ront bien­tôt utili­ser :

  • Le sélec­teur d’élé­ment enfant (E > F) ;
  • Le sélec­teur d’élé­ment frère adja­cent (E + F) ;
  • Le sélec­teur d’at­tri­but (E[attri­but] et E[attri­but=valeur], notam­ment) ;
  • La pseudo-classe :first-child ;
  • La pseudo-classe :hover appli­cable à n’im­porte quel élément et non seule­ment à l’élé­ment a ;
  • La pseudo-classe :focus ;
  • Le sélec­teur de classes multiples (E.clas­se1.clas­se2).

Typo­gra­phie

Dyslexie : Une police de carac­tères dédiée
Taille du texte : 16 Pixel [en]

Guide­lines : 12 Conseils pour gérer l’Er­go­no­mie au travers de la Police

Voici une liste de 12 direc­tives pratiques rela­tives à la police qui vous aide­ront à amélio­rer la faci­lité d’uti­li­sa­tion de votre site web :

  1. Main­te­nir le nombre de polices utili­sées au mini­mum : utili­ser un grand nombre de polices (plus de 3 polices diffé­rentes) rend un site Web diffi­cile à regar­der, non struc­turé et non profes­sion­nel.
  2. Utili­ser des polices sans empat­te­ment plutôt qu’a­vec pour le contenu : Les polices sans empat­te­ment sont plus adap­tés pour l’écran que les polices à empat­te­ment qui sont mieux adap­tés pour les titres et l’im­pres­sion.
  3. S’as­su­rer que le texte et sa taille sont appro­priés : Il est recom­mandé que l’Arial Trébu­chet et Geor­gia soient en plus de 10 pts, le Times New Roman à 12pts et d’évi­ter le Comic Sans et l’Im­pact.
  4. Utili­ser un contenu avec une capi­ta­li­sa­tion mixte : Affi­cher tout le texte en majus­cules ou petites majus­cules le rend diffi­cile à lire et à analy­ser pour l’uti­li­sa­teur. Cela donne au site Web un aspect peu profes­sion­nel et non digne de confiance.
  5. Utili­ser des polices stan­dards pour le Web : Les utili­sa­teurs sont plus fami­liers avec les polices stan­dards et les lisent donc plus rapi­de­ment.
  6. Ne pas mini­mi­ser l’es­pa­ce­ment des carac­tères : La modi­fi­ca­tion de l’es­pa­ce­ment des carac­tères pour inté­grer plus de texte le rend plus dense et diffi­cile à analy­ser.
  7. Limi­ter l’uti­li­sa­tion de diffé­rentes couleurs pour les polices : Lorsque le texte est trop coloré, cela réduit son impact et sa compré­hen­sion. En outre, les utili­sa­teurs peuvent confondre avec une publi­cité. Ainsi, il est recom­mandé d’uti­li­ser au maxi­mum 4 couleurs diffé­rentes pour le contenu du texte.
  8. Ne pas utili­ser le bleu pour le contenu : Les utili­sa­teurs asso­cient le texte en bleu avec des liens et essayent donc de cliquer dessus.
  9. Éviter de colo­rer un texte en rouge ou en vert : Le dalto­nisme est une affec­tion fréquente surtout chez les hommes (8% des hommes sont dalto­niens). Il est conseillé de toujours utili­ser d’autres couleurs, surtout pour distin­guer le texte impor­tant.
  10. Ne pas utili­ser les couleurs iden­tiques ou simi­laires pour le texte et l’ar­rière-plan : Plus le texte est visible, plus les utili­sa­teurs seront en mesure de lire rapi­de­ment et faci­le­ment.
  11. Ajou­ter un sépa­ra­teur des milliers pour les nombres de 5 chiffres ou plus : Avec le sépa­ra­teur des milliers, il est plus facile pour les utili­sa­teurs d’in­ter­pré­ter rapi­de­ment les chiffres.
  12. Ne pas utili­ser le dépla­ce­ment ou le cligno­te­ment de texte : Bien que les tech­no­lo­gies avec lesquelles ils sont mis en œuvre ont changé, ces tech­niques qui existent depuis les premiers jours du Web se retrouvent toujours dans certains sites Web. Leur objec­tif est toujours le même : atti­rer l’at­ten­tion des utili­sa­teurs. Cepen­dant, ils véhi­culent une image de manque de profes­sion­na­lisme et peuvent conduire les utili­sa­teurs à quit­ter le site Web.

12 guide­lines for good website usabi­lity

  1. Keep the number of fonts used at a mini­mum: Using a lot of fonts (more than 3 different fonts) makes a web site look unstruc­tu­red and unpro­fes­sio­nal
  2. Use sans serif fonts instead of serif for content: Sans serif fonts are more suited for the screen than serif fonts which are better suited for headings and print
  3. Ensure that proper text and text size is used: It is recom­men­ded that Arial Trebu­chet and Geor­gia are at 10pts+, Times New Roman at 12pts+ whilst Comic Sans and Impact fonts are not used
  4. Content must make use of mixed capi­ta­li­sa­tion: Having all text in caps or small caps makes it diffi­cult for the user to read and scan it. All caps text makes a web site look unpro­fes­sio­nal and untrust­wor­thy
  5. Use stan­dard fonts for web site fonts: Users are more fami­liar with stan­dard fonts and can thus read them faster
  6. Charac­ter spacing should not be mini­mi­sed: Alte­ring the charac­ter spacing to fit in more text, makes it more dense and diffi­cult to scan
  7. Limit the use of different colours for fonts: When text is over-desi­gned, it affects its meaning. Addi­tio­nally, users may mistake over-desi­gned text for adverts. Thus it is recom­men­ded that 4 different colours or less are used to colour text
  8. Do not use blue for content: Users asso­ciate blue text with links and can thus try and click on it
  9. Avoid colou­ring text in red or green: Since colour blind­ness is a common condi­tion, espe­cially amongst men (8% of men are colour blind), it is advi­sable to always use other cues in addi­tion to colour to distin­guish impor­tant text. It is also advi­sable to avoid the use of red and green since red and green colour blind­ness is the most common form of colour blind­ness
  10. Do not use the same or simi­lar colours for text and back­ground: The more visible the text, the faster users are able to scan and read it
  11. Numbers having 5 digits or more should have a thou­sand sepa­ra­tor: The thou­sands sepa­ra­tor makes it easier for users to quickly scan and inter­pret numbers
  12. Do not use moving or blin­king text: Although the tech­no­lo­gies with which they are imple­men­ted has chan­ged, these tech­niques that have been with us since the early days of the web are still found in some web sites. Their objec­tive is still the same – to draw the users’ atten­tion. Howe­ver, they convey an unpro­fes­sio­nal image and may lead to users leaving the web site

Réfé­ren­ce­ment

AuthorRank & AuthorS­hip : expli­ca­tions par WaW
Algo­rythmes Google : L’im­pact de Panda et Pinguin
Réfé­ren­ce­ment Word­press : URL Cano­nique
Réfé­ren­ce­ment : Pourquoi conduire des tests utili­sa­teurs
Présen­ta­tion d’Ad-word : presen­ta­tion à laquelle j’ai assisté


Média sociaux

Bouton de partage : Le point après 2 mois sans
Ergo­no­mie des réseaux sociaux par Niel­sen : Streams, Walls, and Feeds[en]

Tagués avec :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.