17-12-2014, 11:11 PM
La phrase du slideshare est magique:
Servir contenu et fonctionnalités d'un site ou d'une application quelque soit le cadre d'utilisation de l'internaute
Elle définie parfaitement l'accessibilité (à mon sens), en soulignant le point clef du cadre d'utilisation (ou contexte), auquel le site web n'a pas accès.
D'où l'impossibilité de dicter à la machine client ce qu'il faut exactement afficher (la notion même d'affichage dépend du cadre d'utilisation!)
D'accord du coup avec Sephi: lâchons du lest (pour Chrome, TampterMonkey permet de gérer les userscripts, qui sont des javascripts définis par l'utilisateur et ajoutés aux pages web d'un domaine donné).
En plus des exemples de Sephi, j'ajouterai qu'on ratisse plus large en terme d'audience car les joueurs qui n'accrochent pas trop, mais qui savent développer, peuvent s'amuser à modifier le site pour le rendre plus pratique pour eux-mêmes. De là, ils peuvent diffuser leurs modifications (ben oui: si ces joueurs peuvent modifier le site, c'est parce qu'il est "ouvert d'esprit et de code", ce qui déteint sur ces joueurs qui diffusent alors leurs créas), et la communauté en profite.
Au fond, plus c'est ouvert, plus c'est souple: donner la possibilité à tout utilisateur d'améliorer son interface, c'est donner de la réactivité à son serveur. Cela permet même au développeur du jeu de se concentrer sur le serveur de jeu, et de laisser la partie interface aux fans. Cela facilite le dev, assure que les utilisateurs auront une interface qui leur plait, et en plus, on améliore la visibilité du jeu puisque d'autres personnes (ceux qui ont fait des codes changeant l'interface) le diffusent
Après, on a deux niveaux d'accessibilité:
• L'accessibilité "tout public", où on cherche un design qui plait à l'utilisateur
• L'accessibilité "tout custom", où on permet à chacun de vraiment s'approprier le site
Le premier revient à construire un design qui plairait à tous (boulot de designer);
le second revient à construire un système permettant à chacun de construire son design (boulot de développeur).
prendre en compte les différents cas, support de visualisation, personnes...
Pas forcément d'accord: il s'agit justement de faire abstraction de ces supports. Le seul composant informatique à même de faire le meilleur travail d'IHM (interface homme machine), c'est le navigateur du client. Ce n'est pas pour rien qu'HTML est déclaratif et non impératif: le navigateur connait le contexte de l'utilisateur, et il adapte le site à ce contexte (pour peu que l'on respecte les standards du W3C).
On n'est donc pas forcé de prendre chaque support en considération: il suffit de se baser sur le standard que tous ces supports utilisent. On n'aura effectivement aucune idée de comme le site sera rendu sur les supports que l'on n'a pas, mais c'est justement le principe.
Pour le design contrôlé par google, c'est une question de least surprise principle. Si l'utilisateur est "surpris" par l'interface, alors l'interface est mauvaise car non intuitive.
D'où ce coté "tous les sites se ressemblent".
Servir contenu et fonctionnalités d'un site ou d'une application quelque soit le cadre d'utilisation de l'internaute
Elle définie parfaitement l'accessibilité (à mon sens), en soulignant le point clef du cadre d'utilisation (ou contexte), auquel le site web n'a pas accès.
D'où l'impossibilité de dicter à la machine client ce qu'il faut exactement afficher (la notion même d'affichage dépend du cadre d'utilisation!)
D'accord du coup avec Sephi: lâchons du lest (pour Chrome, TampterMonkey permet de gérer les userscripts, qui sont des javascripts définis par l'utilisateur et ajoutés aux pages web d'un domaine donné).
En plus des exemples de Sephi, j'ajouterai qu'on ratisse plus large en terme d'audience car les joueurs qui n'accrochent pas trop, mais qui savent développer, peuvent s'amuser à modifier le site pour le rendre plus pratique pour eux-mêmes. De là, ils peuvent diffuser leurs modifications (ben oui: si ces joueurs peuvent modifier le site, c'est parce qu'il est "ouvert d'esprit et de code", ce qui déteint sur ces joueurs qui diffusent alors leurs créas), et la communauté en profite.
Au fond, plus c'est ouvert, plus c'est souple: donner la possibilité à tout utilisateur d'améliorer son interface, c'est donner de la réactivité à son serveur. Cela permet même au développeur du jeu de se concentrer sur le serveur de jeu, et de laisser la partie interface aux fans. Cela facilite le dev, assure que les utilisateurs auront une interface qui leur plait, et en plus, on améliore la visibilité du jeu puisque d'autres personnes (ceux qui ont fait des codes changeant l'interface) le diffusent
Après, on a deux niveaux d'accessibilité:
• L'accessibilité "tout public", où on cherche un design qui plait à l'utilisateur
• L'accessibilité "tout custom", où on permet à chacun de vraiment s'approprier le site
Le premier revient à construire un design qui plairait à tous (boulot de designer);
le second revient à construire un système permettant à chacun de construire son design (boulot de développeur).
prendre en compte les différents cas, support de visualisation, personnes...
Pas forcément d'accord: il s'agit justement de faire abstraction de ces supports. Le seul composant informatique à même de faire le meilleur travail d'IHM (interface homme machine), c'est le navigateur du client. Ce n'est pas pour rien qu'HTML est déclaratif et non impératif: le navigateur connait le contexte de l'utilisateur, et il adapte le site à ce contexte (pour peu que l'on respecte les standards du W3C).
On n'est donc pas forcé de prendre chaque support en considération: il suffit de se baser sur le standard que tous ces supports utilisent. On n'aura effectivement aucune idée de comme le site sera rendu sur les supports que l'on n'a pas, mais c'est justement le principe.
Pour le design contrôlé par google, c'est une question de least surprise principle. Si l'utilisateur est "surpris" par l'interface, alors l'interface est mauvaise car non intuitive.
D'où ce coté "tous les sites se ressemblent".