Archive | Technology RSS feed for this section

Goodbye, Facebook; Hello open Web

7 Apr

I grew weary of Facebook a long time ago. Yet I was drawn to it all the while. There’s one thing they got right: showing me snippets of the life of family and friends by suppressing frontiers, overcoming distance and time zones. That is what I’ll miss –its unique ability to show me, at my pace, inklings that are valuable, endearing, funny.

But I grew wary of it a few months ago, while after searching for alcohol ink techniques on my smartphone’s mobile browser the Facebook app immediately suggested I join a few groups on the subject. Whether this was relevant or useful is beyond the point. The Facebook app has hardly any business spying on the history of the browser app.

So I waved goodbye to Facebook’s intrusive practices a few days ago. So long, daily dose of comfort and social peep show.

It may take a bit of effort to write on one’s blog or maintain a Website, and probably takes a massive one for those unfamiliar with the open Web to open the garden wall door and explore the Web, use it.

Someone lamented that they would miss seeing my drawings. But Facebook was just an additional space that I shared those on —a space of crappy definition images— just because there’s a world of apps on smartphones and a population of app users who happen to find it convenient to be fed those.

My drawings go to my blog, in high-resolution definition. My blog has a syndication feed. It means that any update to my blog is signaled. And any feed aggregator can pick up that signal and relay it. This is the principle behind RSS (really simple syndication).

You can read more in a recent article at Wired.

Advertisements

Version annotée de l’article “Lutte fratricide dans les coulisses du web” par Guillaume Sire sur Ina Global

12 Dec

Je vous propose aujourd’hui une version annotée de l’article de Guillaume Sire pour Ina Global “Lutte fratricide dans les coulisses du web”. C’est mon boulot de communiquer sur ce que fait le W3C et dans le cas de cet article, on nous a refusé d’accéder au texte en avance pour proposer des corrections si nécessaire.

Vous trouverez mes réponses et commentaires sous forme de monologue avec mes initiales en préfixe, dans des éléments blockquote.

J’ai précédemment écrit sur le blog du W3C, de manière officielle, neutre et dépassionnée, quant à toutes les inquiétudes dont on nous a fait part à propos d’EME.


 

Lutte fratricide dans les coulisses du web
Qui connaît le W3C ? Cet organe, qui décide ce qui peut être fait ou non sur le web, comment, et dans quelle mesure, traverse une crise sans précédent.

CM : Ah bon ? on traverse une crise ? J’ai cru que la crise était passée suite à la publication d’EME en tant que recommendation.

La raison ? L’implémentation des DRM au sein des standards du web, bien loin de l’esprit des pionniers d’Internet.
CM : Par où commencer ? …
Le concept d’implémentation de DRM au sein des standards du web est faux.
Quant à invoquer l’esprit des pionniers d’Internet, j’ai juste envie de rappeler que Tim Berners-Lee, inventeur du Web, est le directeur du W3C (entre autres) et qu’il se bat pour le bien de sa création avec ferveur.

Sommaire

Et si, demain, vous ne pouviez plus cliquer sur tel ou tel lien hypertexte sans payer ? Le web ne ressemblerait plus alors à une toile, mais à une juxtaposition de jardins murés… Fiction ? Pas forcément. Cette question est l’une de celles qui se posent
CM : Hmm, et où se pose-t-elle donc ?
après la décision du W3C (World Wide Web Consortium), organe méconnu mais essentiel de la gouvernance du web, d’intégrer des DRM (Digital Right Management, ou système de gestion des droits numériques) dans les standards du web, malgré l’opposition de l’Electronic Frontier Foundation (EFF), l’une des institutions les plus représentatives de l’esprit des pionniers d’Internet. Décryptage d’une controverse, en apparence technique, dont l’issue concernera tous les utilisateurs du web sans exception.

Le W3C, une instance de standardisation peu connue des internautes

Le W3C a été créé en 1994 par le fondateur du web, Tim Berners-Lee, dans le but de standardiser les protocoles permettant de rendre compatibles les infrastructures et logiciels d’Internet, en instituant des modalités de production et de circulation du contenu qui fonctionnerait sur tous les ordinateurs quelle que soit leur configuration. Y furent notamment standardisés les protocoles HTTP pour transférer, URL pour localiser et HTML pour décrire les données. Ces trois protocoles sont à la base du world wide web, c’est-à-dire de l’usage de l’infrastructure Internet consistant à publier et à consulter des documents depuis un logiciel appelé « navigateur » (Firefox, Internet Explorer, Safari, Chrome, Opera).
CM : Vingt sur vingt. Zéro faute.
Pour la suite, je ne vais relever que ce qui est incorrect.
La vocation du W3C est de servir d’arène aux discussions concernant les modifications à apporter à ces protocoles,
CM : Oui.
et, une fois qu’une modification a été actée, de faire son possible pour que les acteurs concernés agissent en conséquence.
CM : Non, pas vraiment. Les acteurs concernés sont à la table de la standardisation parce qu’ils sont concernés. De ce fait, ils agissent en conséquence.
C’est donc un organe essentiel dans la gouvernance du web à l’échelle mondiale, pourtant peu connu des utilisateurs.
N’importe quelle personne morale peut devenir membre du W3C, pour un montant variant selon son statut et sa taille (jusqu’à 59 000 euros par an pour une grosse entreprise en France), et participer ainsi aux négociations en y faisant valoir ses intérêts.
Le processus de standardisation du W3C est décrit dans le « W3C Process document », qui est en quelque sorte, comme l’a écrit Andrew Russel, la « Constitution » du consortium. Toute discussion concernant un protocole commence par la formation d’un groupe auquel participent les représentants des organisations membres du W3C pourvu que celles-ci en aient formulé la demande, des employés du W3C ainsi que certains experts invités étant donné leurs compétences sur le sujet. Chaque groupe édicte sa propre charte, comportant la description du sujet, une durée envisagée (variant entre six mois et deux ans), les objectifs et les règles de la discussion.
CM : C’est un détail, mais “six mois” n’est pas réaliste, aussi, aucun groupe n’est lancé pour une telle durée. Par contre, on étend volontiers des groupes existants pour six mois afin leur permettre de finaliser leur travail.
Chaque modification significative des protocoles existants doit franchir cinq étapes : First Working Draft (FWD), Working Draft (WD), Candidate Recommendation (CR), Proposed Recommendation (PR) et Recommendation (REC). Chacune de ces étapes correspond à un degré de maturité spécifique dans le sens où, petit à petit, la modification doit faire l’objet d’un consensus de plus en plus fort et avoir prouvé son efficacité en subissant des tests techniques de plus en plus exigeants. À chaque étape, si le Comité consultatif — composé d’un représentant pour chacun des membres du W3C (ils étaient 463 en septembre 2017) — juge que les conditions ne sont pas réunies, le texte est renvoyé à l’étape en cours, ou bien à l’étape précédente. Seule la dernière étape, REC, a valeur de norme officiellement reconnue par le W3C. (C’est l’accession par l’EME à cette étape qui a provoqué le départ de l’EFF.)
 Certains auteurs n’hésitent pas à qualifier l’inventeur du web de « dictateur »  
CM : Je note que je n’ai aucune idée de qui sont ces auteurs, de quoi ils sont auteurs, ni même d’où ils qualifient l’inventeur du Web de dictateur.
Le processus du W3C confère un pouvoir considérable au directeur du W3C, qui n’est autre que Tim Berners-Lee, puisque celui-ci peut prendre en dernière instance des décisions qui ne vont pas dans le sens de l’avis exprimé par le Comité consultatif ou bien trancher alors qu’il reste des objections formelles n’ayant pas été résolues. Pour cette raison, certains auteurs comme Jeremy Malcolm n’hésitent pas à qualifier l’inventeur du web de « dictateur ».
CM : Qui est cet auteur qu’on nous présente en expert sans le présenter ? Quels sont ses références et qualifications ?
Il ne fait pas partie de groupes de travail au W3C (*), ni n’est un représentant du Comité consultatif.
(*) Il est cependant participant d’un des W3C Community Groups, groupes ouverts au public permettant entre autres d’incuber des technologies et spécifications pour les porter officiellement à l’attention de tous via un groupe de travail.
Si le Comité consultatif n’est pas d’accord avec la décision prise par le directeur, il existe tout de même une procédure d’appel. Si au moins 5 % des membres du Comité se prononcent en faveur de l’appel, cela déclenche un vote de toutes les organisations membres du W3C visant à accepter ou rejeter la décision du directeur. Avant 2017, cette procédure n’avait jamais été invoquée.

Revenir au sommaire

Les défis du W3C

 Les différentes parties prenantes du W3C n’ont pas toutes les mêmes intérêts et ne défendent pas toutes les mêmes valeurs  Une des difficultés majeures du W3C tient au fait que les différentes parties prenantes n’ont pas toutes les mêmes intérêts et ne défendent pas toutes les mêmes valeurs. Le fossé est en effet considérable entre des producteurs de contenus désirant générer du chiffre d’affaires en faisant payer les internautes, et donc en contrôlant les modalités d’accès à leurs contenus, et les partisans d’une liberté totale de circulation des contenus et d’une neutralité absolue des contenants. Le Comité consultatif du W3C, son directeur Tim Berners-Lee et son P-dg Jeff Jaffe doivent donc arbitrer entre les positions et les réclamations des uns et des autres.
Qui plus est, le web doit faire face à la concurrence des autres usages d’Internet, notamment les applications pour smartphones. Ces dernières (exception faite des applications « navigateur ») utilisent l’infrastructure Internet mais n’ont pas recours aux protocoles du W3C. La navigation hypertexte n’étant pas possible pour passer horizontalement de l’une à l’autre, elles fonctionnent comme des « jardins murés » et permettent aux éditeurs de mieux contrôler les modalités d’accès à leurs contenus. Il n’est pas rare d’entendre dire que le web, trop permissif, a vocation à être remplacé par ce type d’application et qu’il n’aura par conséquent été qu’une page de l’histoire d’Internet. Cette perspective, qui a son importance nous le verrons dans l’histoire de l’EME, a été nourrie par le magazine Wired dont le très écouté rédacteur en chef Chris Anderson n’a pas hésité à déclarer en 2010 : « Le web est mort, longue vie à Internet ! »

Revenir au sommaire

Encrypted Media Extensions : chronologie d’une controverse

En février 2012, Google, Microsoft et Netflix proposèrent d’intégrer au standard HTML, dont la version HTML5 était alors en train d’être discutée, une API (Application Programming Interface) nommée « Encrypted Media Extensions » (EME). Le but de celle-ci était de permettre aux développeurs d’ouvrir un canal de communication entre une page web et les logiciels de DRM. Concrètement, des lecteurs pourraient être intégrés aux pages web pour lire les vidéos sans module d’extension spécifique (contrairement à Flash) et grâce auxquels il serait possible d’obliger l’ordinateur de l’internaute à obtenir une clé depuis un serveur dédié avant chaque lecture du fichier, et ainsi d’autoriser le visionnage de la vidéo aux seuls individus ayant acquis ce droit. Sur un service comme Youtube, il deviendrait possible de protéger les vidéos sans module spécifique (grâce à la commande « Clear Key ») mais aussi de faire interagir différents modules de décryptage comme Widewine (supporté par le navigateur Chrome, de Google) et PlayReady (supporté par Internet Explorer 11, de Microsoft).
Les acteurs attachés à la libre circulation et à la transparence s’opposèrent immédiatement à l’EME, c’est-à-dire qu’ils ne voulaient même pas que la discussion soit ouverte au sein du W3C. L’Electronic Frontier Foundation (EFF) et la Free Software Foundation (FSF) lancèrent une pétition avec pour objectif d’atteindre les 50 000 signataires avant le 3 mai 2013. Une lettre ouverte fut également signée en avril 2013 par 27 organisations et adressée à Tim Berners‑Lee pour « implorer le comité du World Wide Web ainsi que ses organisations participantes de rejeter la proposition EME ». Tout en comparant la spécification à des « menottes numériques », la lettre prévenait le directeur du W3C que le fait de l’intégrer à l’agenda du HTML5 « constituerait une abdication de ses responsabilités face aux objectifs essentiels du W3C et des utilisateurs du web ».
Mais malgré cette lettre et les 27 500 signatures reçues par la pétition, le 9 mai 2013, Tim Berners-Lee accepta de publier l’EME sous forme de FPWD et de l’inscrire sur la charte du HTML5. Ce faisant, il rappela qu’un FPWD n’était pas une REC, et que le fait de discuter de l’EME ne signifiait en rien que le W3C permettrait qu’il accède au statut de norme officielle. Il expliqua dans une lettre datée du 9 octobre 2013 qu’il était lui-même opposé à certaines formes de DRM. Et il réitéra sa volonté de faire en sorte que le web soit « ouvert » et « universel ».
De nombreuses personnes, au premier rang desquelles Cory Doctorow, membre de l’EFF représentant l’organisation au W3C, accusèrent Tim Berners-Lee de faire le jeu des producteurs de contenus, et notamment des producteurs de cinéma d’Hollywood rassemblés au sein de la Motion Picture Association of America (MPAA) qui, aussitôt assurée que l’EME serait bien discuté au sein du W3C, décida de devenir membre de manière à pouvoir participer à la discussion.
CM : Ce que cet article ne dit pas c’est que l’EFF aussi a rejoint le W3C à ce moment-là et pour la même raison. Et c’est bien.
Selon Doctorow, Tim Berners-Lee « semblait avoir cru au mensonge selon lequel les producteurs d’Hollywood allaient abandonner le web et s’intéresser à d’autres médias (AOL ?) dans le cas où ils n’obtiendraient pas que l’Internet ouvert soit reprogrammé pour correspondre à leurs projets de maximisation profits ».
CM : Spéculation.
 
Les concepteurs de navigateurs ont tous accepté de re-paramétrer leurs logiciels. Certains comme Google (Chrome) et Microsoft (Internet Explorer) l’ont fait dès le stade FPWD. Pour Mozilla (Firefox), en revanche, ce fut moins immédiat, notamment parce que la fondation était plus proche de l’EFF que des partisans de l’EME. Et s’ils re-paramétrèrent malgré tout en mai 2014, ce fut à contrecœur et parce qu’ils ne voulaient pas empêcher leurs usagers d’avoir accès aux contenus protégés de Netflix, Amazon Video et Hulu.
En mars 2017, l’Unesco a rejoint officiellement les rangs des opposants à l’EME (passé au stade CR le 5 juillet 2016) lorsque le sous-directeur général pour la communication et l’information, Frank La Rue, a adressé une lettre publique à Tim Berners-Lee destinée à lui faire savoir qu’une des valeurs fondamentales de l’Unesco était « la libre circulation des idées et de l’information » et à le prévenir que l’EME « pourrait avoir un impact sur les navigateurs au point de rendre impossible l’exercice des utilisateurs de leur droit légal d’une utilisation équitable des vidéos sous copyright ».
CM : Lettre ouverte à laquelle non seulement le W3C a répondu, mais qu’il a clarifiée et corrigée.
À peine un an plus tard, en juillet 2017, on annonça que l’EME était sur le point de devenir une REC. C’est alors que l’EFF, par l’intermédiaire de son représentant au W3C Cory Doctorow, lança la procédure d’appel en réunissant 5 % des signatures des membres et en exhortant tous les autres à « sauver le web ». Cette procédure n’avait encore jamais été invoquée en vingt‑trois ans d’histoire du W3C. Seulement 185 des 463 membres du W3C s’exprimèrent lors du vote, et finalement, malgré la pression de l’EFF, l’EME obtint 58,4 % de voix « pour » (108 ont voté oui, 57 non et 20 blanc)  et passa au stade REC le 18 septembre 2017. Cela provoqua le départ de l’EFF du W3C, Cory Doctorow considérant que le W3C s’était trahi lui-même en publiant une norme « faite pour contrôler l’usager au lieu de lui donner du pouvoir ».
Concrètement, la normalisation de l’EME ne changera pas grand-chose
CM : Pas grand-chose, non.
Juste l’accessibilité aux personnes handicapées, l’intéropérabilité, la sécurité. Des broutilles, quoi.
Sans EME, c’est retour aux plug-ins inaccessibles, exposés à des failles de sécurité, et dont la plupart ne fonctionne que sur certaines plate-formes.
Je vous invite à lire la liste des avantages qu’apporte EME, ainsi que le document d’information accompagnant le communiqué de presse, relatant tous les éléments essentiels autour d’EME.
Par contre, vous n’y trouverez rien de dramatique ou de sensationnel.
puisque tous les principaux navigateurs étaient déjà re-paramétrés et que de nombreux services vidéo l’utilisent depuis 2014. Mais elle a quand même deux implications majeures pour le web et son avenir.

Revenir au sommaire

Demain, le contrôle des pages ?

La première de ces implications a trait au contrôle. Puisqu’il est désormais possible de contrôler par DRM la circulation des vidéos sur le web,
CM : Notez bien que “sur le web” est le mot-clé, ici et représente la nouveauté. Ce qui se faisait via plug-in se fait désormais sur le Web.
Je vais vous laisser relire cette phrase.
Ne tombez dans le piège tendu par l’auteur qui sous-entend que le contrôle passe aux mains des producteurs de films. Ils ont le même contrôle, ni plus ni moins.
Ce qui change est la plate-forme. En déplaçant toutes les interactions dans les navigateurs Web, elles sont protégées des failles de sécurité des plug-ins.
à la grande joie des producteurs de films, certains producteurs d’autres types de contenus ne voient pas pourquoi eux non plus ne disposeraient pas d’une telle technologie.
Les bruits de couloir sourdent dans les coulisses du W3C : à présent qu’on est débarrassé de l’EFF, pourquoi ne pas proposer de normaliser un module de gestion des DRM au sein du HTML5 permettant de protéger les livres numérisés ?
CM : Ah mais, ça commence à bien faire avec les sous-entendus, les exagérations et les demi-vérités !
Comme l’a souligné Silvère Mercier dans un excellent article sur la question, on trouve la trace d’un tel projet dès décembre 2013 dans les listes de discussion du W3C. Et le projet est d’autant plus actuel qu’en février 2017 le W3C et l’International Digital Publishing Forum (IDPF), au sein duquel a été développé la norme EPUB, ont fusionné
CM : Non, ce n’est pas un project actuel. Le groupe de travail a mis “DRM” dans la section “hors cadre” de sa charte de travail.
et qu’il sera possible à partir de 2018 pour les membres du W3C de participer à un groupe appelé « Publishing business ».
CM : À vrai dire, ce groupe existe depuis le printemps 2017.
De nombreux liens hypertextes ne seront plus des passages gratuits mais des passerelles payantes  C’est sans doute le sujet brûlant de ces prochaines années. Car s’il est possible demain de contrôler la circulation de formats texte, il sera également possible de verrouiller des pages web et nous pourrons dire adieu alors à la navigation fluide. Il sera extrêmement aisé de protéger des pages ou même des éléments d’une page web, de sorte que de nombreux liens hypertextes ne seront plus des passages gratuits mais des passerelles payantes.
CM : Je trouve le paragraphe ci-dessus bien sensationnel alors qu’aujourd’hui et depuis des années de telles passerelles payantes existent sur le Web. Le Web a vocation à contenir tout autant de contenus gratuits, que de contenus payants.
Le web sera truffé de palissades exigeant que soit montrée patte blanche pour être franchies, et sa topographie ressemblera moins dans ce cas à une « toile mondiale » qu’à une juxtaposition de « jardins murés ». Adieu plaines du Larzac, bonjour clos de Champagne !

Revenir au sommaire

La sécurité, autre problème majeur

Aux États-Unis, personne, dans aucun cas, n’a le droit de contourner un DRM. Il est en outre interdit d’essayer de regarder ce qui se passe à l’intérieur ou même d’évoquer avec quelqu’un la possibilité de contourner un DRM (un courriel dans lequel vous évoqueriez un tel contournement peut normalement être retenu contre vous en cas de procès). Ces interdictions proviennent de la section 1201 du Digital Millenium Copyright Act. Ainsi, l’EME crée un espace auquel on n’a pas le droit d’accéder et à propos de l’accès duquel il est interdit de discuter. Cela pose un problème en termes de sécurité, puisque même les chercheurs et les producteurs d’antivirus n’ont pas le droit d’accéder à cet espace.
C’est pourquoi l’EFF avait proposé en janvier 2016, au sein du W3C, que fût mis en place d’un accord formel impliquant que les ayants droit des vidéos protégées par l’EME s’engageraient à ne pas poursuivre en justice les personnes qui auraient procédé à des tests dans la mesure où ils auraient ensuite publié les anomalies identifiées. Malgré la signature de 198 chercheurs en informatique favorables à cette proposition et le soutien de l’Open Source Initiative (OSI), la proposition de l’EFF a été refusée par les parties prenantes de la discussion concernant l’EME au W3C. C’est également une des raisons qui a motivé le départ de l’EFF, Cory Doctorow pointant du doigt dans son communiqué le refus de la part des parties prenantes d’accepter un tel compromis et accusant la direction du W3C, en particulier Jeff Jaffe, de s’en être rendu complice.
CM : Tout ce que je peux dire publiquement à ce sujet c’est que plusieurs versions d’un accord formel ont été étudiées, que ça a pris de longs mois en toute bonne foi –et que Jeff Jaffe a œuvré en ce sens–, que toutes ne provenaient pas que de l’EFF et que cette dernière a tout autant rejeté les versions non satisfaisantes que les autres membres du W3C.

Revenir au sommaire

La standardisation du code HTML se fera-t-elle demain ailleurs qu’au W3C ?

Ce qui peut être fait ou non sur le web, et comment, dans quelles mesures, selon quelles modalités… tout cela est décidé depuis le début des années 1990 au W3C. Autrement dit, c’est là-bas que le répertoire d’action est négocié, et que sont discutées les valeurs qui président à ces actions. En théorie, tout le monde est invité autour de la table et la normalisation se fait par consensus.
CM : En pratique aussi, tout le monde est invité. La section “wide review” du processus du W3C prévoit de faire savoir publiquement les avancées et d’inviter tout retour.
Cependant, pour la première fois de son histoire, le W3C a été le théâtre d’un affrontement qui est allé jusqu’à une procédure d’appel qui n’avait encore jamais été nécessaire, et a débouché sur le départ d’une des institutions les plus représentatives sans doute de l’esprit des pionniers d’Internet : l’Electronic Frontier Foundation.
Que se passera-t-il à l’avenir, si les acteurs qui défendent la libre circulation des contenus et la neutralité des contenants ne participent plus aux discussions du W3C ? Le web sans doute deviendra moins permissif et peut-être aussi plus « légal » mais plus cher également, moins universel, plus inégalitaire peut-être, et moins fluide de toute façon, moins horizontal.

Il n’est pas impossible toutefois que d’autres protocoles voient le jour, dans d’autres arènes, écrits cette fois par les défenseurs de la libre circulation et de la neutralité du réseau. On peut très bien imaginer que des arènes de normalisation se mettent en place en marge du W3C, comme ce fut déjà le cas du Web Hypertext Application Technology Working Group (Whatwg) créé en 2005 à l’époque où Tim Berners-Lee ne jurait que par le XHTML et le web sémantique alors que certains développeurs voulaient détrôner l’hégémonie de Flash en matière d’interactivité et créer pour cela le HTML5. D’ailleurs, le fondateur du Whatwg, Ian Hickson, dès le premier jour où il en a été question, s’est opposé de manière virulente à l’EME. Il ne serait pas étonnant par conséquent qu’il accueille l’EFF à bras ouverts au Whatwg.

CM : Le WHATWG travaille sur une toute petite partie des technologies Web.

Le W3C c’est 235 spécifications en développement actif, dont 200 visent le statut de Recommandation. C’est 36 groupes de travail en parallèle et 13 groupes d’intérêt qui s’occupent de tous les aspects du Web. Tous ces groupes suivent un modèle de revue et vérification transverse afin d’assurer une prise en charge en matière d’accessibilité pour les handicapés, de sécurité et d’internationalisation.

 

Crédit :

Illustration : Ina – Yann Bastard

Revenir au sommaire

In honour of World Usability (#WUD)

17 Nov
wud-logo-color
World Usability Day (#WUD), generally the second Thursday of November, aims at ensuring that services and products important to life are easier to access and simpler to use, and at celebrating and educating – celebrating the strides we have made in creating usable products and educating the masses about how usability impacts our daily lives. It is about making our world work better.

This year I attended with 40 or so others, FLUPA Nice The World Usability Day local meetup where Google’s Material Design was introduced, and a small workshop was held on visually designing wireframes.

I learned that 21% of the French population is in a situation of handicap (that is 23M people) and that 80% of handicaps are invisible. W3C was mentioned for its work on WCAG, but unfortunately not for its WAI tutorials or Developer tools.

Other useful snippets:

  • Digital accessibility is a vector of social integration.
  • My priority design principles include:
    • Visible elements
    • … including visible buttons using or or two words
    • Most important elements at the top
    • Similar types of information are grouped
    • Clear hierarchy of information
    • Consistency of UX throughout
    • Sufficient font size and colour contrast
    • 2 to 3 colours (that match, preferably although it’s a matter of taste)
    • 2 font types at most, maybe a third if used in a logotype
    • Short sentences
    • A little jargon as possible
    • Consistent usage of personal pronouns
  • Given that only a handful of frameworks appear to be used to create websites nowadays, people really need to be creative in order to stand out and be identifiable.

#ParisWeb 2016: notes and thoughts (day 2)

4 Oct

[Read my notes and thoughts about Day 1.]

I attended Paris Web 2016 on 29-30 September, a two-track conference followed by a day of workshops. I heard about the French Web conference in 2006 for its first edition, but I’ve attended only the last 3 editions. It’s such a great conference. The people are passionate and respectful –no, they are caring and it makes the conference extra special. The staff is dedicated and wonderful. The speakers are excellent. It’s probably the most inclusive conference; as far as I can tell, it’s the only conference that has:

  1. live French sign language,
  2. live translation into French of English presentations, and
  3. transcriptions projected on screen.

In addition, the conferences are filmed for streaming and posterity.

I am not a Web {developer,designer}, but I’m interested for my work in taking the pulse of the Web Community as far as Web Standards are concerned. Each of the two parallel tracks of the conference were appealing and I am looking forward to watching the videos of the talks I could not attend.

Here are my notes and thoughts from the second day:

Web Accessibility

09:00: L’accessibilité décomplexée – ce qu’elle peut faire pour vous. Adoptons un point de vue iconoclaste, voire… totalement décomplexé, sur l’accessibilité !

Par Nicolas Hoffmann

Thoughts:
Nicolas packages accessible plug-ins, shares them on Github, and encourages everyone to do the same. Accessibility brought Nicolas technical knowledge (that should put to rest all the lame excuses from whiners who wait to accrue technical knowledge *before* they think they can tackle accessibility.)
Any contribution is worthwhile and an investment, bound to reap benefits. Nicolas concluded with a question: “What can accessibility do… for you?”
Notes:
from Nicolas’ slides:

  • Evangelise accessibility
    • Avoid negative impressions (e.g. showing demos that fail)
    • Show positive stuff instead
  • Center your vision on “others” rather than “self”
  • Start small (but start)

Static Websites

10:00: Ne passons pas à côté des choses simples. Quels sont les secrets de la vogue pour les gestionnaires de sites statiques.
Par Frank Taillandier et
Bertrand Keller

Thoughts:
Frank and Bertrand held a conversation on stage where one convinced the other that not all data requires a base, and that HTML, CSS and Javascript in some cases can generate simple and light sites that perform well. It’s high time to “Keep It Static Simple”
I used to keep a local diary powered by Blosxom a decade ago and like how simple it was to use from the command line. I then tried Nikola and Pelican several years ago between Christmas and the New Year, determined to change the way I updated my website, but after several days wrestling, I gave up, sad and frustrated. As soon as I can realistically make time, I’ll look again at what generator(s) might be suitable for me.
Notes:
from slides linked off Frank’s article:

  • “serverless” movement
  • some say 80% of the Web does not require any database
  • Static website
  • Contribution, update via a headless CMS (or use an online service)
  • Role of APIs
  • Yet, ‘simple’ does not mean ‘easy’
  • A plethora of generators: Jekyll, hexo, hugo, pelican, brunch, middleman, metalsmith, gatsby, harp, grav, assemble, lekto, roots, nanoc, phenomic, etc.

wysiwyg CSS? holy cow!

11:00: CSS et édition WYSIWYG, l’amour vache. CSS et édition Wysiwyg, c’est l’amour vache. Difficile à implémenter et compliqué à matérialiser en UI. Pourquoi et comment ?
Par Daniel Glazman

Thoughts:
Daniel demonstrated the subtleties around the particular points that make it hard to do wysiwyg CSS.
I believe there are 10 sorts of people. Those who grok CSS and those like me who weep and swear when they have to do some CSS. (Usually the former are quite snotty about that achievement, as they have all the rights to be. R.E.S.P.E.C.T.)
When it comes to CSS, I have no idea what I’m doing. Really. Often do I find myself thinking “hmmm, I have no idea what I’m doing…” but that statement is completely true only as far as CSS in concerned. It’s like I lack the gene to even grasp it. There isn’t one way to do something in CSS, there is *choice*. I would hate it less if I understood why one choice makes sense because $type-here-the-enlightened-wisdom.
The first time I worked in earnest on a style sheet was a fine but cold Sunday in January 2005. It was also the last time. THE DAMN THING TOOK ME 8 HOURS! Behold the comment I left in that style sheet:

/*Here is downtown2.css, a variation of downtown.css
that I made 2 days ago for my W3C People page. As a beginner 
in CSS  I was exposing to a colleague how I wanted images  
to spring out on mouse hover without knowing if that was 
at all feasible ; I was  pointed to http://diveintomark.org/ 
and was told "I think it does  what you want." I was told it 
was a bit tricky. The style at  diveintomark.org is exactly 
the one I was looking for! --05jan2005
"Based on stylesheets from diveintomark.org, copyright (c) 
2004 Mark Pilgrim.  
Used here with permission" 
--memento background-color:
purple: a880bd
rosy: ecdeff--
Opera 7.54u1:mac displays a scaled flower in the top square 
on the left.--09jan2005*/
Then, I discovered Westciv’s *StyleMaster*, a style sheet editor that let me apply sheets to web pages, experiment and debug. Yet, not without great effort –remember the missing CSS gene. I haven’t used it in years, mostly because I no longer have to create style sheets from scratch, but I was thoroughly enthused by it.
My question to Daniel, had I had the time to ask it, “Isn’t Style Master a wysiwyg CSS editor and if so, how does it work around the challenges you exposed?”
Notes:
from Daniel’s slides:

  • [history of wysiwyg]
  • Question about copy/paste: should the style be copied and pasted?
  • What about CSS files that are not local and thus can’t be edited?
  • No FileAPI (File System API is defunct and Web Platform WG might take up work on File API)
  • Conclusion:
    • There is a half wysiwyg CSS editor on the market (BlueGriffon, Daniel’s editor).
    • CSS has been thought for rendering engines but not for editors; and it is not getting any better.
    • There are cases when what to do via a client can’t be done: the user will have to make a choice.

Progressive WebApps

11:45: Progressive Web Apps : le futur du web arrive. Venez découvrir comment le Web peut proposer une expérience proche du natif sur mobile sans les inconvénients des magasins d’applications.
Par Hubert Sablonnière

Thoughts:
Hubert is a great story teller; I loved Hubert’s slides and talk!
Notes:
(slides not found)

  • Desktop vs Mobile vs hybrid apps
  • … Choice depends on context of the user
  • Hubert Sablonnière: “Les URLs, c’est la vie !”
  • New buzzword: Progressive Web Apps (not a new technology but a marketing term)
  • Service Workers – works only in HTTPS
  • See https://pwa.rocks/ (by Opera DevRel)

A11Y beyond reference frames

13:30: Vers l’infini et au delà des référentiels. Les trucs et astuces pour améliorer l’accessibilité de vos sites au delà de la simple conformité RGAA
Par Eric Gateau et
Aurélien Lévy

Notes:
(slides not found)

  • RGAA is not a panacea: test for SVG, Canvas, ARIA only
  • Furthermore, accessibility isn’t just voice over, so RGAA doesn’t cover all aspects of a11y
  • Tests with users
  • Ergonomy
  • Fitts’s law: the biggest and closest the target, the easiest it is to hit.
  • Hick’s law: the time it takes for a person to make a decision as a result of the possible choices he or she has: increasing the number of choices will increase the decision time logarithmically.
  • Gestalt laws: near elements are associated, elements that are alike are associated
  • “When UX doesn’t consider ALL users: “some user experience” = SUX” –Billy Gregory

WCAG.next

13:30: WCAG.next – where do we go from here? Deque System’s Principal Accessibility Strategist John Foliot provides some insights and future milestones towards WCAG.next
By John Foliot

Thoughts:
John gave a well laid-out presentation of W3C Web Accessibility groups current thinking (where ‘current’ dates back a week prior to John’s talk, when the groups met during the W3C TPAC 2016).
One of my take-aways from John’s talk is that Web Accessibility *requirements need to be testable*.
Notes:
(slides not found)

  • Assessment: we need to blend the guidelines from WCAG, UAAG and ATAG
  • Project Silver: AG = Accessibility Guidelines – Decision by the end of 2016
    • https://www.w3.org/WAI/GL/wiki/Designing_Silver
    • Engage broadly, easily and openly
    • Communicate on that effort
    • Define and engage stakeholders
    • Make decisions based on evidence and data
    • Lifecycle (keep the standards Up-to-date)
    • Broaden the scope of applicability
    • Establish clear milestones
    • Likely to take 5-7 years
  • … in the meantime: WCAG 2.x
  • Task forces:
    • Mobile
    • Low Vision
    • Cognitive
  • New Guideline?: Device Manipulation
  • New Success Criteria Requirements:
    1. clear, measurable
    2. Documentation for developers to understand why the requirement exists
    3. At least 1 technique for success