Compte rendu du hackathon Music Hack Paris 2012

Posted on by
1

Google devrel Manager presenting the demos

Ce dimanche avait lieu le Music Hack Paris à la Cartonnerie. J’ai pu assister aux démonstrations des projets.

Quand on arrive à la Cartonnerie, on tombe d’abord sur une simple vitrine dépolie avec une petit écriteau “Music Hack Paris”. L’entrée où je retire mon badge est une pièce étroite. Mais dès qu’on passe cette étape, on arrive au milieu d’un lieu à la décoration faite de poutres et vieilles machines. Tout le monde s’active. Il ne reste plus qu’une heure aux participants pour finir leur projet.

Photo of La Cartonnerie

L’objectif des hackers et des musiciens était d’innover autour de la création, de la consommation et de la découverte musicale. L’ambiance est décontractée et bruyante. Les percussions, la guitare et les sons synthétiques se mélangent avec le bruit des claviers d’ordinateurs.

Hackers tinkering with physical objects and Arduinos

Ce hackathon organisé par l’UNECO, le Google Cultural Institute et Joshfire avait pour cadre la Journée Internationale du Jazz. Et au final, une quinzaine d’équipes ont sacrifié leurs heures de sommeil pour présenter leur “hack” dimanche après-midi.

Un des projets qui a attiré mon attention est InstaTube. L’équipe est partie du constat suivant : beaucoup de gens écoutent la musique grâce aux diaporamas accompagnés de musique dont regorge YouTube. Ils ont donc créé un outil simple qui permet de générer un diaporama à partir d’un fichier MP3 et de quelques mots clés. L’application se charge de trouver des images et des vidéoclips, de remixer le tout en rythme et d’envoyer le tout sur YouTube. La démo a parfaitement fonctionné et le résultat est peut être plus convaincant que ce qu’on trouve d’habitude sur le site de partage de vidéos.

Les autres projets étaient aussi intéressants mais peut être moins aboutis. On a pu voir des instruments de musique à base Kinect, de la musique générée par capteurs de téléphones, des sculptures métalliques musicales, des pendules pilotant un arduino, un arduino faisant des percussions et des séquenceurs web collaboratifs en temps réel. Les élections du dimanche faisaient même partie de l’événement avec le hack de @sylvinus qui faisait chanter des tweets sur la Marseillaise, en Javascript. Bref, beaucoup d’imagination de la part des participants.

Pour mieux vous rendre de compte de ce qu’il s’est passé, j’ai monté rapidement une vidéo qui montre quelques-unes des démos qui ont été présentées.

Hacking RFID with NodeJS

Posted on by
5

tl;dr: you can write JS code (see below) to read RFID tags with NodeJS.

Last week-end, I found my old RFID reader in a drawer. It’s a mir:ror, made by Violet, you know, the company that invented Wi-Fi rabbits. The device is a USB HID device and used to ship with a lousy app that could trigger a few predefined actions. But the company is kind of dead now and the driver is no longer available.

So, how hard would it be to write a driver that could do whatever I want? The thing is that I need it to work on OSX. And it would be great if programs could be written in JS, because it’s a language I’m comfortable with.

Being a lazy programmer, I first searched the Web for existing drivers. I found some software written in ruby and .Net. The first one expects the mir:ror to be available in /dev, which is not the case on my Mac (no idea why). The second one is for Windows obviously. Moreover, I don’t know any of these languages.

Out of luck, I wondered: is it possible to communicate with USB HID devices in NodeJS? Thirty seconds of googling later, I stumbled on this cool node extension: Node HID that does exactly what I’m looking for (you could also program keyboards, keypads, mice, etc.).

The next step was to code the driver. Hopefully, the protocol is simple and documented on this blog: http://blog.nomzit.com/2010/01/30/decoding-the-mirror-comms-protocol/.

Below is the code of the driver. It can read RFID tags, detect when the device is upside down, and disable the annoying lights and sound.

var HID = require('HID');

var devices = new HID.devices(7592, 4865);
var hid;
if (!devices.length) {
  console.log("No mir:ror found");
} else {
  hid = new HID.HID(devices[0].path);
  hid.write([03, 01]); //Disable sounds and lights
  hid.read(onRead);
}

function onRead(error, data) {
  var size;
  var id;

  //get 64 bytes
  if (data[0] != 0) {

    console.log("\n" + data.map(function (v) {return ('00' + v.toString(16)).slice(-2)}).join(','));

    switch (data[0]) {
    case 1:
      //Orientation change
      switch (data[1]) {
      case 4:
        console.log("-> mir:ror up");
        break;
      case 5:
        console.log("-> mir:ror down");
        break;
      }
      break;
    case 2:
      //RFID
      switch (data[1]) {
      case 1:
        console.log("-> RFID in");
        break;
      case 2:
        console.log("-> RFID out");
        break;
      }

      size = data[4];
      id = (data.splice(0)).splice(5, size);
      console.log(id.map(function (v) {return ('00' + v.toString(16)).slice(-2)}).join(','));
      break;
    }
  }
  hid.read(onRead);
}

Now that NodeJS can react to RFID tags, we can do all sorts of things, like switching between spaces on a Mac. Check out the video to see a demo.

CSS Color Palette Extractor

Posted on by
2

There are already many web apps that extract colors from CSS. But none of them seemed to do what I need them to do. So I built my own.

Twitter Bootstrap extracted palette

Twitter Bootstrap extracted palette

Facebook extracted palette

Facebook extracted palette

My goal was to create a tool that would help me consolidate the palette of an ever growing CSS. To achieve this goal, I needed a tool that can:

  • extract all colors from the CSS code. Most extractors rely on regular expression to perform this task. It may work for most cases, but they tend to fail with rgba or named values.
  • order colors in a sensible way. I want colors on one side and greyscale on another. I also want colors ordered by hue. Ordering hex values by alphabetical order doesn’t make sense.
  • roughly show how much a color is used. This way, I know that lesser used colors might be merged with dominant colors. Obviously, more occurrences in CSS doesn’t mean that the color will be more present on the website. But that’s better than nothing.

The result is CSS Color Palette Extractor, a pure JS app that does what I need. You can try the demo and fork it on github.

On the technical side, the app uses the great CSS parser written by Daniel Glazman to extract color values. It also includes code from Andrew Brehaut for color management/conversion. My own code is a bit rough but does the job. There are a few known issues. I haven’t found how to make the parser work with media queries. If you’re doing responsive design, simply extract medium per medium. Also, my app cannot extract colors from gradient backgrounds.

It’s sometimes nice to step back from code and analyze what’s going on. I hope that CSS Color Palette Extractor will help you to do just that. If you want to use the code, feel free to fork it on github.

My JS1K 2012 demo: Heart Petals

Posted on by
Reply

JS1K is a competition where you have to create a cool demo with less than 1 kilobyte of code.

This year, I entered the competition for the first time with a demo named: “Heart Petals”. The theme is “Love”, hence the cheesy title.

Here’s what it looks like:

And here are some tricks I’ve used to reduce the code size:

  • Use unicode chars to draw shapes. The hearts are not images. They are drawn with the unicode char 0×2764. That’s only one char (2 bytes in UTF8?). Certainly less than a lengthy SVG path or a crazy equation.
  • Use byte saving techniques. Did you know that 0| is equivalent to Math.floor() ? I didn’t. Also, assign long function names to one letter vars.
  • Optimize your algorithm. Don’t write unnecessary steps.
  • Use magic. If a shorter but approximate version does the trick: it’s probably good enough.
  • Use a minifier. Just before submitting the code, I simply compressed the code further with uglify.js.

At the end, my code is far less than 1K. I could have added more features. I probably have no chances to win, but the experience was funny. You should check the other demos out: http://js1k.com/2012-love/demos. And why not submit yours?

Retour sur TEDxConcorde

Posted on by
Reply

Ce samedi (28 janvier 2012), j’ai eu la chance d’assister à la conférence TEDxConcorde. Non seulement j’ai pu voir des présentations inspirantes et captivantes, mais j’ai également pu modestement photographier l’événement. Les caméras de Canal+ (partenaire de l’événement) étaient également là pour filmer en vue d’une diffusion programmée le 7 février. En attendant, j’ai publié mes photos de TEDxConcorde sur flickr.

Comment tester l’ergonomie de son site, même sans budget : les tests Guérilla

Posted on by
1

Cet article est la suite d’une série qui reprend ma présentation à la conférence Paris Web 2011.

Dans un précédent article, nous avons vu comment il est possible de réaliser des tests utilisateurs soi-même, avec peu de moyens. Pour ceux qui considèrent que le coût reste trop élevé, il existe une deuxième méthode encore moins onéreuse.

La méthode “Guérilla”

Monter au front : Guerilla Testing

Aussi connue sous le nom de “méthode Commando”, cette méthode reprend les éléments de la méthode Do-It-Yourself (DIY) mais dans un environnement différent. L’idée principale est de réaliser les tests dans la nature avec n’importe qui. On réduit les exigences et donc les coûts pour faire plus facilement des tests.

Le lieu

La première différence avec le test DIY, c’est le lieu. À la place d’une salle de réunion, nous allons réaliser nos tests utilisateurs dans un lieu public. Il faudra bien le choisir. Évitez les endroits trop bruyants, vos enregistrements seront inexploitables sinon. Favorisez les lieux plutôt calmes, vos utilisateurs en auront également besoin pour se concentrer sur votre scénario.

L'intérieur d'un café Starbucks

Pour plusieurs raisons que je vais détailler plus loin, les cafés de type Starbucks permettent de réaliser des tests guérilla dans d’assez bonnes conditions. Ils possèdent souvent une salle calme éloignée du comptoir, des sièges confortables et on peut y rester aussi longtemps que nécessaire.

S’il n’y a pas de Starbucks dans votre ville, vous pouvez essayer dans une bibliothèque ou un espace de co-working. Évitez les restaurants : manger n’est généralement pas compatible avec l’utilisation d’un ordinateur.

Ces lieux publics ne vous coûteront rien, sauf si vous consommez. Même dans ce cas, cela reste négligeable.

Les utilisateurs

L’autre différence importante avec un test D.I.Y., est la manière de recruter les utilisateurs. On est clairement dans l’optique «n’importe quel testeur vaut mieux qu’aucun test». Donc, au lieu de prendre rendez-vous avec des utilisateurs, vous allez simplement les choisir sur place.
Même si cela peut sembler intimidant au premier abord, il suffit d’un peu d’audace pour réussir à trouver des volontaires.

Voici quelques astuces qui vous aideront à les trouver :

  • choisissez une personne qui ne fait rien de spécial. Quelqu’un qui boit simplement son café, qui joue avec son téléphone portable ou qui lit un magazine par exemple.
  • ne lui faites pas peur. Présentez vous poliment. Si vous souriez c’est encore mieux.
  • jouez sur les sentiments. Il ne s’agit pas de susciter la pitié, mais dites simplement que vous avez besoin d’un peu d’aide sur votre projet. Expliquez brièvement votre démarche.
  • offrez un café, une pâtisserie ou une connexion au WiFi à ceux qui ont un ordinateur.

Avec un peu d’entraînement, il sera assez simple de convaincre quelques personnes. Et étonnamment, elles acceptent souvent de vous aider sans contre-partie.

Le déroulement d’une session

Avant tout, vérifiez que votre site est prêt à être testé et votre logiciel prêt à enregistrer.
Vous pouvez ensuite aller à la recherche d’un testeur.
Lorsque vous l’avez trouvé, il sera assez difficile de le convaincre d’être filmé. Ne gardez que l’écran et le son si c’est possible.
Expliquez-lui le déroulement d’un test et plongez rapidement dans votre scénario.
Essayez de limiter la durée d’une session. Avec 5 à 10 minutes, vous devriez avoir assez de temps pour réaliser une ou deux tâches simples.
Lorsque vous avez terminé, remerciez votre utilisateur et prenez des notes.

Ce type de session est généralement moins formel, ce qui peut affecter la qualité des résultats. Il faudra donc développer vos qualités d’observateur pour que le test ne se transforme pas en simple discussion de café.

Passage en caisse

Si on fait le compte, le prix d’un test guérilla coûte:

  • entre 0 et 5€ (si vous consommez) pour lieu;
  • environ 10€ par utilisateur;
  • rien pour l’observateur;
  • rien pour l’enregistrement si vous optez pour des logiciels gratuits.

On obtient donc un test qui revient à 10€ par utilisateur, soit 4 fois moins cher qu’un test DIY. Son coût réduit est alléchant, mais il est beaucoup difficile à réaliser et la qualité des résultats est plus aléatoire. Vous pouvez opter pour ce type de test :

  • lorsque vous êtes un observateur suffisamment expérimenté;
  • lorsqu’il vous faut des itérations rapides, en début de projet par exemple;
  • lorsque le test ne nécessite pas de connexion internet (prototype ou wireframe);
  • lorsque votre site est utilisé en situation de mobilité.

Dans le prochain article sur les tests utilisateurs, nous verrons comment tester sans bouger de votre bureau avec les tests à distance.

Comment tester l’ergonomie de son site, même sans budget : les tests Do-It-Yourself

Posted on by
13

Cet article est le premier d’une suite d’articles à paraître.

Cette année, pour la première fois, j’ai participé à la conférence Paris Web en tant qu’orateur.

Alors que je faisais partie de l’équipe organisatrice les années précédentes, j’ai voulu cette fois-ci partager mon expérience en proposant une présentation. Après avoir testé quelques idées, le sujet qui semblait le plus intéressant concernait les tests utilisateurs. Les éditions précédentes en avait déjà parlé, mais jamais comme sujet principal. J’ai donc envoyé une proposition à l’équipe sur le sujet pour en parler. Stress, angoisse et excitation : le sujet a été retenu.

Le 13 octobre 2011, j’ai donc présenté «Comment tester l’ergonomie de son site, même sans budget».

Après une introduction rapide et un rappel de ce qu’est un test utilisateur, j’ai décidé de me concentrer sur le coût de ces tests.

Pourquoi réaliser des tests moins chers ?

Dans mon expérience, le budget nécessaire est un des gros obstacles qui font que de nombreux projets sortent sans qu’il y ait eu de tests utilisateurs préalables.

Réduire le coût a plusieurs effets :

  • tester devient une option envisageable : même avec un budget réduit, il est possible de tester l’ergonomie de son site avant sa sortie.
  • convaincre son boss : une facture réduite permet d’obtenir l’accord de son boss plus facilement, voire de s’en passer («Undercover UX»).
  • des tests plus fréquents : il est possible de tester tout au long du projet. L’erreur serait de penser qu’on économise en ne testant qu’à la fin. Les gros problèmes qui seraient détectés pourraient alors remettre en cause des mois de développement. Mieux vaut tester tôt et souvent.
  • réduction des risques : au pire, si le résultat n’est pas concluant, on n’aura perdu qu’un peu d’argent. Tester ne fait plus peur.

Pour y arriver, j’ai proposé trois méthodes, toutes réalisables avec peu de moyens. La première méthode consiste à faire les tests soi-même.

D.I.Y. (Do it yourself), faire les tests soi-même.

Cette méthode est parfois connue sous le nom de «Hallway usability testing» (tests d’utilisabilité de couloir).

Pour ce tests, il faut plusieurs ingrédients: des utilisateurs, un site, un observateur, de quoi enregistrer et un scénario. L’idée principale est de réduire les exigences pour certains paramètres.

Les utilisateurs

Trouver des utilisateurs est une des étapes qui semble la plus difficile lorsqu’on n’a jamais organisé de tests. Une ergonome connue à qui j’avais posé la question m’avait répondu : «Tu te sors les doigts du !$@». Et elle avait raison. Il suffit d’aller chercher des participants là où c’est le plus simple:

  • les proches : demandez à votre femme, votre cousin ou vos amis. Ils vous aideront facilement. Cependant, il faudra bien filtrer les commentaires dont le but est de vous faire plaisir ou de vous encourager («j’aime bien ce que tu as fait là»).
  • les collègues : ils ont tout intérêt à ce que le projet marche et donc à vous aider à améliorer l’ergonomie. Ils ne sont pas très loin (le bureau d’à côté) et il suffit souvent de leur payer un café. Il faut faire attention à ceux qui travaillent directement sur le projet car ils ont souvent des motivations pour influencer le projet dans un sens ou un autre.
  • les étudiants : ils sont souvent fauchés et ne sont généralement pas contre se faire un peu d’argent en participant à des tests. Si vous connaissez des profs, ils sont généralement partant pour envoyer des étudiants se confronter à des cas réels en entreprise.
  • les vrais utilisateurs : si votre site existe déjà, certains utilisateurs ont souvent envie de faire part de leur remarques et testeront volontier une nouvelle fonctionnalité ou une nouvelle version.

Pour ces testeurs, il faudra prévoir un budget moyen de 40€ par utilisateur. C’est un budget raisonnable mais le montant est suffisamment attractif pour trouver des participants. Pour le mode de paiement, tout dépendra de ce que permet votre comptabilité. Il est courant d’utiliser des chèques cadeaux ou des bons d’achat.

L’observateur

L’observateur a un rôle important: c’est lui qui va garantir le bon déroulement des sessions. Pour cela, il va:

  • assister techniquement l’utilisateur lorsqu’il rencontre des difficultés techniques qui ne sont pas liées au test: déverrouiller un ordinateur qui se serait mis en veille, par exemple;
  • expliquer le déroulement du test;
  • indiquer les tâches à réaliser, sans donner d’indices;
  • inciter l’utilisateur à progresser dans le scénario s’il s’attarde trop sur une tâche;
  • rappeler à l’utilisateur de parler à haute voix;
  • répondre aux questions qui empêchent vraiment l’utilisateur d’avancer.

Ces missions sont plutôt simples et ne nécessitent pas de connaissances particulières. Cependant, il faut faire très attention à ne pas donner d’indices à l’utilisateur qui pourraient fausser le résultat du test. Par exemple, sur un site de e-commerce, si l’observateur énonce: «Recherchez un produit», cela risque d’aiguiller l’utilisateur vers le moteur de recherche alors qu’il aurait pu parcourir les catégories de produits plutôt.

L’observateur doit rester neutre. Et pour y arriver, le plus simple est d’avoir un discours écrit à l’avance et de s’y tenir.

N’importe qui peut jouer le rôle d’observateur, y compris vous-même. Il n’est donc pas nécessaire d’engager quelqu’un.

Le lieu

Habituellement, les tests d’utilisabilité sont réalisés dans un laboratoire. On y trouve généralement deux pièces, séparées par un vitre sans teint. D’un côté, l’utilisateur réalise la tâche avec un observateur à ses côtés. De l’autre, l’équipe du site observe en direct et peut éventuellement poser des questions via l’observateur. Le laboratoire est généralement équipé de caméras et de microphones pour tout enregistrer.

Dans une méthode D.I.Y., tout ce dispositif n’est pas nécessaire. Une salle de réunion suffira.

L’enregistrement

Pour garder une trace du test et pouvoir l’analyser plus tard, il va falloir de quoi enregistrer les sessions. Si on considère que vous utilisez un ordinateur portable récent, vous avez déjà une caméra (la webcam) et un microphone intégré. Il ne vous manque plus qu’un logiciel pour enregistrer. Voilà une liste non exhaustive d’outils:

  • Camstudio, pour Windows. Ce logiciel est gratuit et permet d’enregistrer l’écran et le microphone
  • Windows Media Encoder, pour Windows. Offert par Microsoft, ce logiciel permet d’enregistrer l’écran et le microphone
  • Silverback, pour Mac. Développé par Clearleft, ce logiciel coûte $70 et permet d’enregistrer l’écran, le micro et la webcam. Il dispose de fonctionnalités spécialement pensées pour les tests utilisateurs comme la possibilité d’enregistrer plusieurs sessions ou d’indiquer des moments intéressants pendant une session à l’aide d’une télécommande.
  • Quicktime, pour Mac. Installé sur tous les macs récents, Quicktime permet d’enregistrer gratuitement l’écran et le microphone.

À ce stade, vous avez quasiment tous les éléments pour effectuer un test utilisateur. Il ne manque plus que le scénario. Pour cela, voyons comment se déroule un test.

Les sessions

Avant la session, et avant l’arrivée des participants, il y a une phase préparatoire:

  1. préparez l’ordinateur qui va servir aux tests en installant les logiciels
  2. vérifiez que le site est testable
  3. désactivez ce qui pourrait gêner le test: les alertes e-mail, les antivirus, les notifications de mises-à-jour, etc.
  4. imprimez les documents: accords de participation, NDA (accords de confidentialité) et le scénario

Lorsque vous êtes prêt, vous pouvez accueillir le premier utilisateur. Présentez-vous en tant qu’observateur et non pas comme concepteur du site. Ainsi, il n’aura pas peur de vous blesser en exprimant des critiques. C’est aussi à ce moment là que vous allez donner sa compensation au participant. Il pourra ainsi réaliser le test sans avoir à «réussir» le test pour gagner de l’argent.

Ces formalités réglées, vous pouvez vous installer pour débuter la session.

Pour commencer, expliquez au participant le déroulement de la session. C’est peut être la première fois qu’il participe à ce genre de test. Rassurez-le sur l’objectif de cet exercice: il s’agit de tester l’interface du site et non pas de juger ses capacités à réaliser des tâches. Votre participant doit être à l’aise et rassuré pour faire ce test dans de bonnes conditions.

Faites-lui signer l’accord de participation et un NDA si nécessaire. Cela vous permet d’avoir un peu de temps pour (ré)initialiser le test. Pensez à effacer l’historique et les cookies du navigateur. Ce serait dommage de gâcher une session parce que la saisie d’un précédent participant apparait dans l’autocomplétion du navigateur.

Ensuite, discutez un peu avec le participant pour le connaitre un peu. Quels sont ses sites préférés ? Combien de temps passe-t-il sur Internet ? Cela va permettre de connaitre ses habitudes et son niveau de maîtrise de l’outil informatique. Profitez-en pour obtenir quelques détails qui pourraient permettre de personnaliser le scénario. Ce sera plus simple pour lui de s’imaginer dans une situation taillée sur mesure qu’avec un scénario standard totalement hypothétique.

À présent, le participant va devoir réaliser les tâches du scénario qui vous aurez défini. Vous pouvez lancer l’enregistrement.

Habituellement, je commence avec une tâche simple de repérage. Cela va permettre au participant de s’exercer à la pensée à haute voix. Pour cela, j’ouvre généralement la page d’accueil du site et je lui dis la chose suivante:

«Voici un site Web. Est-ce que vous pourriez me dire si vous comprenez à quoi sert ce site et quelles sont les possibilités qui vous sont offertes. Pour le moment, je vous demande juste d’observer. Vous pouvez faire défiler la page, mais pas cliquer pour le moment». Votre participant devrait commencer à observer et dire à haute voix ce qu’il voit. Si ce n’est pas le cas, inciter le à parler. Un simple «à quoi cela vous fait penser ?» ou «qu’est-ce que vous voyez ?» devrait l’aider.

Les autres tâches dépendront de ce que vous souhaitez tester. Pour cela imaginez un contexte et un objectif. Donnez ce contexte à votre participant et demandez lui d’atteindre l’objectif. Vérifiez si cela se passe comme vous l’aviez supposé. S’il vous pose des questions, n’y répondez pas, sauf si ça l’empêche de progresser.

L’ensemble des tâches devra tenir dans une session de 20 minutes environ. Pendant ce laps de temps, vous devriez pouvoir réaliser 3 ou 4 tâches sans que cela soit pénible pour l’utilisateur.

À la fin de la session, vous pourrez répondre à ses questions avant de le remercier. Prenez ensuite quelques minutes pour prendre des notes sur la session.

Vous pouvez alors passer à un autre utilisateur.

Lorsque toutes les sessions sont terminées, collectez tous les enregistrements pour les analyser.

Passage en caisse

Si on fait le compte, on arrive à la facture suivante:

  • rémunération d’un participant : 40€
  • lieu : 0€
  • observateur : 0€
  • logiciel : entre 0 et 70€

En choisissant bien vos options, un test revient donc à environ 40€ par utilisateur.

Dans un prochain article, nous verrons une variante encore moins coûteuse: le test guérilla, ou comment faire des tests sur le terrain.

Crédits photo (Creative Commons):

 

Why your Dropbox alternative is not enough

Posted on by
6

Projects such as lipsync or SparkleShare are often considered as Dropbox alternative, especially by people who do not actually use Dropbox.

Unfortunately, we’re still not there yet.

Here’s why: most people usually always think of Dropbox as a syncing solution. But it’s more than that. Dropbox can:

I really hope that those project catch up, but until then, I won’t consider them as alternatives.