Projet communautaire pour enseigner le front (et le reste) – Bilan personnel de l’atelier de lancement

Le mois dernier, j’ai co-animé avec Rémi un atelier à Paris Web au nom bien bien long : « Construire ensemble un enseignement du front-end pertinent, pédagogique et pérenne ».

Comme cette session faisait suite à un débat ayant eu lieu à Sud Web (2), nous avions déjà des convictions sur lesquelles nous baser :

  • Cet enseignement ne peut se faire qu’en transmettant la culture générale du web et ses grands principes.
  • Il faut rapidement être concret et faire des exercices pratiques pour ne pas perdre l’intérêt des étudiants.
  • Il s’agit plus d’apprendre à apprendre que de donner un enseignement dogmatique qui sera vite obsolète.

L’atelier à Paris Web nous a donc essentiellement servi à proposer et mettre la l’épreuve la méthodologie que nous avions imaginée pour servir cette direction : des fiches suivant un gabarit où une problématique « terrain » organisées en trois temps :

  1. une demande comme extraite d’un brief ou d’une spécification,
  2. un temps de recherche et de propositions,
  3. une modification dans la demande (on a dit que c’était « terrain » 😉 ).

C’est avec plaisir que nous avons constaté que « ça a pris ». La quarantaine de participants – parmi lesquels des enseignants à temps-plein ou partiel et trois étudiants – a joué le jeu et a eu l’air d’adhérer. Nous avons eu des retours enthousiastes à la fin de l’heure et demie et ça fait vraiment plaisir.

Matthieu est « chaud bouillant », Boris a très envie de s’impliquer dans la suite et ils ne sont pas les seuls à nous avoir fait part de leur adhésion. (2)

Et tant mieux ! Car un atelier comme celui-ci n’est que le lancement d’un projet. S’il ne se passe rien derrière, c’est « raté » (comprendre, c’est une expérience pour une tentative future).

La suite se passe sur GitHub : http://traindrop.github.io/
(lien mis à jour le 26/04/15)

Tout est à faire :

  • Assoir la méthode de contribution ;
  • Bien se positionner par rapport à d’autres projets similaires ;
  • Trouver un nom plus sexy 😉 et faire une jolie page de présentation (Y a-t-il un graphiste dans la salle ?) ;
  • Et bien sûr : décliner les fiches (c’est-à-dire que la communauté s’empare du projet et décline des fiches) !

Mais mon premier bilan est positif car la réception que notre audience m’a fait bien plaisir. Merci.

Vivement la suite donc !

(1) « Élaboratoire » improvisé en mai 2014 avec Romy et Rémi. Je vous invite à voir les différents comptes-rendus listés sur la page Lanyrd.
(2) Vous êtes plusieurs à vous être manifestés pour être tenus au courant de la suite ; je ne vous oublie pas 😉
Crédit photo : Fred Mayor

Construire ensemble un enseignement du front-end pertinent, pédagogique et pérenne – Paris Web 2014

Avec Rémi Parmentier
Atelier, 1 h 30
Paris Web, octobre 2014

Un atelier-débat improvisé à Sud web en mai 2014 a permis de lister quelques pistes sur l’enseignement du développement front-end. Parmi ces pistes, la difficulté de la pédagogie et le manque d’outils sont ressortis. Il s’agit en effet de bien transmettre les principes et les spécificités du média (plus que la technique, peu complexe en définitive) sans lasser, sans assomer, sans braquer ou encore donner l’impression de couper les cheveux en quatre.

Nous vous proposons de concevoir ensemble des fiches pédagogiques qui permettraient :

  • aux étudiants d’avoir un projet ou un cas concret avec un problème clair à résoudre.
  • à l’enseignant de distiller les grands principes du web petit à petit à travers ces cas concrets, et pas présentés de manière théorique.

Le tout sera mis à la disposition de tous sur GitHub.

Aux experts de l’accessibilité fatigués

Vous n’êtes pas en charge de la prise en compte de l’accessibilité en France ; vous y avez contribué. C’est différent.
Vous avez œuvré pour en faire comprendre les enjeux, fourni des outils pour faciliter son intégration, transmis vos connaissances – et souvent votre enthousiasme.
Personne n’aurait de légitimité à vous reprocher d’arrêter. Pas même vous ; ce n’est pas un abandon, c’est un passage de relais.

Donc, si vous êtes usés, déçus ou que vous avez juste envie de passer à autre chose, recevez, via ce billet, mes humbles remerciements pour ce que vous avez fait pour l’accessibilité et tous mes vœux d’épanouissement dans votre nouvelle voie.

Ne vous inquiétez pas de la suite : certains ont déjà commencé à marcher dans vos pas ; je les vois. Et c’est ça aussi votre succès.

(Ce blog n’a pas une grosse audience mais si parmi les lecteurs certains se reconnaissent dans la relève (en gros, le sujet de l’accessibilité vous intéresse de plus en plus), je vous invite à vous manifester dans les commentaires. Ça nous fera plaisir de vous voir.)

Illustrations autour de l’accessibilité numérique

Ce n’est pas grand chose, mais ça m’a été utile et ça peut en aider d’autres. Voici quelques dessins qui servent à illustrer des idées autour de l’accessibilité numérique.

J’en ai eu besoin lors d’une conférence introductive (1) à la première session de Accessiday, journée consacrée à l’accessibilité numérique.

Les dessins que j’ai fais pour illustrer mes propos ont beaucoup plus et certains m’ont dit qu’ils pourraient en avoir besoin. Les voici donc à disposition ; ils sont en effet distribués sous licence CC BY-SA 3.0 FR.

Handicap vs. déficience

Un personnage en fauteuil roulant. Il souffre d'une déficience physique (permanente ou temporaire) à laquelle il pallie par le truchement d'un fauteuil roulant.
Un personnage en fauteuil roulant. Il souffre d’une déficience physique (permanente ou temporaire) à laquelle il pallie par le truchement d’un fauteuil roulant.
Un personnage en fauteuil roulant en haut d'un escalier. Il est en situation de handicap.
Un personnage en fauteuil roulant en haut d’un escalier. Il est en situation de handicap.
Un personnage en fauteuil roulant face à sa table de travail. Il n'est pas en situation de handicap.
Un personnage en fauteuil roulant face à sa table de travail. Il n’est pas en situation de handicap.

Aide technique – Le lecteur vocal

Un personnage aveugle face à un écran d'ordinateur. Il ne peut pas consulter le contenu.
Un personnage aveugle face à un écran d’ordinateur. Il ne peut pas consulter le contenu.
Un personnage aveugle face à un écran d'ordinateur. Par le truchement d'une aide technique -ici un lecteur vocal- il peut consulter le contenu.
Un personnage aveugle face à un écran d’ordinateur. Par le truchement d’une aide technique -ici un lecteur vocal- il peut consulter le contenu.

Aide technique – Les lunettes

Un personnage avec une mauvaise vue face à un écran d'ordinateur. Il n'arrive pas à lire le contenu.
Un personnage avec une mauvaise vue face à un écran d’ordinateur. Il n’arrive pas à lire le contenu.
Un personnage avec une mauvaise vue face à un écran d'ordinateur. Par le truchement d'une aide technique -ici une paire de lunettes- il peut consulter le contenu.
Un personnage avec une mauvaise vue face à un écran d’ordinateur. Par le truchement d’une aide technique -ici une paire de lunettes- il peut consulter le contenu.

Contexte – L’ensoleillement

Un personnage consulte son mobile. Bien que le texte soit peu contrasté, le personnage n'est pas gêné.
Un personnage consulte son mobile. Bien que le texte soit peu contrasté, le personnage n’est pas gêné.
Un personnage consulte son mobile en plein soleil. Le manque de contraste des textes sur l'écran ne lui permet pas de lire.
Un personnage consulte son mobile en plein soleil. Le manque de contraste des textes sur l’écran ne lui permet pas de lire.
Un personnage consulte son mobile en plein soleil. Le fort contraste des textes sur l'écran lui permet de lire facilement.
Un personnage consulte son mobile en plein soleil. Le fort contraste des textes sur l’écran lui permet de lire facilement.

Le daltonien

Un daltonien ne perçoit pas les couleurs correctement.
Un daltonien ne perçoit pas les couleurs correctement.

Si vous utilisez ces dessins, j’en serais ravie ! Signalez-le moi via les commentaires 😉

Notes :

(1) Conférence  » Accessibilité numérique, mais au fait de quoi on parle ? » Retour

À propos : Si vous aussi vous voulez faire des croquis, je vous conseille d’aller faire un tour chez Eva-Lotta Lamm

Comment enseigner l’intégration HTML ? – Sud Web 2014

Élaboratoire improvisé suite à la conférence de Rémi Parmentier « Faire comprendre son métier » et suite à une question de Delphine Malassingne à la fin de la conférence.

Débat ouvert pour trouver quel devraient-être le contenu et la pédagogie d’un enseignement de l’intégration front.

Voir aussi l’atelier qui y a fait suite : Construire ensemble un enseignement du front-end pertinent, pédagogique et pérenne – Paris Web 2014

Crédit photo : romytetue

Bonnes pratiques des API – Compte-rendu

Pour les besoin de mon projet Spoiled People (voir Projet de liste cadeaux sur GitHub), je dois monter en compétence côté API. Je suis allé voir du côté de la conférence « Bonnes pratiques des API ».

Cette conférence de 15 petites minutes est un retour d’expérience, y compris sur les ratés.

La première leçon qu’Éric Daspet a appris et nous transmet concerne la littérature et la pratique. Sans critiquer la littérature, son constat a été que d’un point de vue pragmatique, il vaut mieux s’adapter aux envies des utilisateurs (les développeurs).

Eric Daspet - Paris Web 2013 - Photo Brice Favre

Les recettes à suivre

Voici une première liste de conseils issus de cette conférence.

Internationalisation

  • Toujours mettre des heures et non juste une date
    Pas GMT mais en mettant un fuseau horaire que vous allez interpréter dans chaque paramètre)
    Voir le commentaire d’Éric ci-dessous.
  • Attention aux langues : anticiper la possibilité d’avoir plusieurs langues, utiliser UTF-8 (et non de l’ISO).

Pagination

  • L’offset sont de fausses bonnes idées.
  • Trier les données par ordre (alphabétique, de date, d’arrivée,…) et utiliser « after | before » (plus ancien ou plus récent que tel item)
  • Rendre la pagination obligatoire.
  • Mettre des limites de taille avec une profondeur maximum

Un bon exemple : Twitter

Versionnement

Même si dans la littérature, le versionnement peut être vu comme une mauvaise pratique, en l’état, nous ne sommes pas forcément prêt à nous en passer. Partir du principe qu’on va se planter et, alors, qu’on fera une V2 plutôt que mettre des bouts de sparadrap.

  • Prévoir un /v1 en bout d’URL dès le début

(NB : Le versionning dans les en-têtes n’est pas assez simple et ne sera pas pratique pour vos utilisateurs et donc ne servira pas)

Sécurité

  • HTTP Basic Oauth
  • + SSL
  • imposer HTTPS
  • Ne pas permettre le SSL désactivé dans le SDK (qui est recommandé)
  • Clé d’API : savoir à tout moment qui fait la requête. Prévoyez-la.

Structure

  • Faites de l’hypermédia mais ça ne suffit pas.
  • Vos adresses doivent être « bidouillables » de façon qu’elles soient prédictives.
  • Une adresse doit ressembler à un nom de fichier : pas de caractères spéciaux encodés, que des minuscules, pas de caractères accentués.
  • Réduire la hiérarchie aux maximum (3 semble être la bonne pratique).

La conclusion

La clé :

  • En faire peu.
  • Ouvrir un maximum de champs pour plus tard.
  • Faire simple.
  • Utiliser les standard existants.
  • Penser pragmatique.
Diaporama de la conférence
NB : Le diaporama contient 10 bonnes pratiques supplémentaires en page 11.

Projet de liste cadeaux sur GitHub

Mise à jour du 17/11/2013 : Le projet est maintenant géré en organisation GitHub (les liens ci-dessous ont été mis à jour)

Alors voilà. Figurez-vous que j’ai eu envie d’une application de liste cadeaux sur mon mobile (Android). Il y en a pas mal et j’avais l’embarras du choix. Pourtant, après les avoir regardées, testées, repoussées et re-testées, je n’en ai trouvé aucune qui correspondent à mon besoin.

Et là, vous vous dites que soit je cherche la petite bête, soit je suis passée à côté de l’évidence. Une conversation Twitter a fini de me convaincre que non, il n’y a pas ce que je veux (non, non, pas même Amazon ou Pinterest).

Et donc, je veux :

  • pouvoir ajouter un item via ma caméra – donc une application mobile ;
  • pouvoir ajouter un item via ma galerie (je vous jure qu’il y a des appli qui permettent l’un sans l’autre) ;
  • pouvoir ajouter un item depuis n’importe qu’elle page en ligne – donc via un bookmaklet associé ;
  • pouvoir éditer tout ça aussi depuis un site en ligne ;
  • et que ce soit joli.

Voilà mes 5 critères incontournables.

J’ai trouvé une application/site web (Ookoodoo) qui a tout ça …sauf le dernier point : elle fait bien vieillotte, a une ergonomie compliquée et cela gâche beaucoup mon plaisir.

Seule solution (puisque Ookoodoo n’est pas open source) : lancer mon propre projet. Oui mais voilà, je n’ai pas les compétences de développement qu’il faut ! Et là, Laurent Demontiers m’a donné LA bonne idée : lancer un projet GitHub pour un projet en open source. Non seulement l’état d’esprit me plaît mais en plus ça me fait un prétexte pour mettre vraiment les mains dans GitHub.

logo001-480px

Et donc voilà : ça s’appelle « Spoiled People » et ça a besoin de vous.

De l’aide est la bienvenue pour tout :

  • développement,
  • graphisme,
  • ergonomie,
  • conception fonctionnelle,
  • aspects légaux,
  • etc.,
  • et même pour tout ce qui est prise en main de GitHub

Alors ? Ça vous dit de jouer aussi ? Tout est dans le  « README »