Oubliez le non obstrusif!

Derrière ce titre racoleur se cache pourtant une réalité bien fondée: il est aujourd'hui impensable de faire de l'applicatif pur et dur de manière non obstrusive.

Si je persiste à croire qu'il est important qu'un site web basée sur la succession de champs de formulaires soit accessible sans JavaScript, je pense à l'inverse qu'une fois sorti de ce genre de schéma séquentiel, il est impossible de conserver cette démarche non obstrusive. J'irais jusqu'à dire que ça freine totalement l'évolution et la qualité des applis web.

Prenons par exemple 280 Slides. Superbe application de création de présentations en ligne. Un honnête remplaçant de PowerPoint, gratuit et accessible de partout. Cet outil est, en toute bonne foi, irréalisable sans JavaScript. Or ce type d'applications web qui vient supplanter chaque jour un peu plus nos programmes desktop classiques (et c'est tant mieux!) ne peut être vu comme une interaction séquentielle d'actions successives. Les cas sont nombreux: retouche d'images, mise en page, outils de wireframe, cartes et itinéraires, …
Que faut-il faire? Ne pas développer ces applications sous prétexte qu'on ne peut les réaliser de manière non obstrusive? Hors de question. Accepter qu'un site web et une application n'ont pas la même vocation? Très certainement.

Nous développons actuellement en interne une application pour laquelle le choix de faire du non obstrusif s'est clairement posée et nous avons décidé d'y renoncer. Je ne regrette en aucun cas cette décision, que du contraire.

'lut Benjamin,

j'ai envie de dire "ben oui quoi !", ce qui est une manière comme une autre de te plussoyer...

Je pense qu'à partir d'un moment faut se libérer de ça, et surtout pour les services avancés et très pratiques. Je n'imagine pas une seconde Google Wave sans Javascript etc.. Ca deviendrait une galère totale pour le développer...

A partir du moment où les personnes veulent utiliser un service innovant/spécial ils faut qu'ils se rendent compte qu'il faut mettre certaines technologies à contribution...

Les internautes et les entreprises vont de toute façon se retrouver à un moment ou un autre obligés d'accepter les navigateurs récents et javascript. L'obstrusif est aussi plus fun que l'applicatif mais il est clair que ce n'est pas aussi (voir pas du tout) accessible.
C'est le seul problème qui reste selon moi, va rendre Google Maps accessible. :o

Skoua a écrit :
il est clair que ce n'est pas aussi (voir pas du tout) accessible.

Ce n'est pas tout à fait exact, il y a tout de même pas mal de choses qui bougent à ce sujet…

En même temps c'est logique. rendre accessible aux aveugles (je parle que d'un seul handicap juste pour l'exemple), une application servant à la mise en forme n'est que du brain f@#ing de toute façon...

Malgré que je suis impressionné par ce que certain arrive à faire.

JavaScript est de toute façon indispensable pour toute personne utilisant actuellement le web. La majorité des sites y font appel pour des fonctions de base, il n'est plus imaginable de le désactiver.

La question n'est donc plus de savoir s'il est activé ou non, mais si son utilisation est faite à bon escient et si cela reste accessible (ce qui est plutôt rare dans la majorité des cas).

On parle bien "d'applicatif pur et dur" et non de Javascript en général pour des sites web généraux mmh ?
Comme de toute façon "l'applicatif pur et dur" n'a pas réellement de rapport avec les sites web mis à part les technologies employées (HTTP, JS, HTML, CSS) et l'utilisation commune du navigateur web, ouais pourquoi pas ...

Pour les sites web par contre, le non-obstrusif reste une bonne pratique.

dew a écrit :
La majorité des sites y font appel pour des fonctions de base, il n'est plus imaginable de le désactiver.

Sisi.
Y a même des effets secondaires désirables à utiliser NoScript : détecter les iframes indésirables avant Google

Felipe a écrit :
On parle bien "d'applicatif pur et dur" et non de Javascript en général pour des sites web généraux mmh ?

C'est comme ça que je l'avais compris...

Felipe a écrit :
Pour les sites web par contre, le non-obstrusif reste une bonne pratique.

Yep.

Felipe a écrit :
Sisi.
Y a même des effets secondaires désirables à utiliser NoScript : détecter les iframes indésirables avant Google

re-Yep !

Heyoan a écrit :
C'est comme ça que je l'avais compris...

Et tu l'as bien compris.

Petite parenthèse niveau code, si l'on part sur un client full js, on pourrait même aller jusqu'à opter pour un gabarit tel que celui-ci:

<!doctype html>
<html lang="fr">
  <head>
    <meta charset="utf-8">
    <title>Mon application web</title>
    <style>@import "styles.css" screen;</style>
    <script src="appli.js"></script>
  </head>
  <body>
    <em>Vous devez activer JavaScript pour utiliser cette application.</em>
  </body>
</html>

L'ensemble du DOM serait allait construit via appli.js, ce qui n'est pas totalement absurde puisqu'il ne sera utilisable que lorsque JavaScript est activé.

Pas évident de définir le quand, pourquoi, comment du non obstrusif. De nombreux critères entrent en jeux tels que l'utilisateur cible, la définition de ce qui relève de l'ergonomie ou de la fonctionnalité, les besoins en terme de visibilité/référencement.

Personnellement je crois que ce n'est jamais tout l'un ou tout l'autre.

J'essaie toujours de commencer à développer une appli oldschool linéaire et ensuite de greffer dessus ma couche de javascript. Mais cela revient souvent à faire deux fois une appli en ajoutant une couche d'abstraction supplémentaire et donc une perte de maintenabilité.

Quand en plus viennent se greffer des temps/homme et des budgets limités, il est clair que l'on finit par se dire que le "tout non obstrusif" est un concept excellent en soi, mais difficilement viable en application.

Pour ce qui concerne les normes d'accessibilité, et notamment WCAG 2, rien n'oblige à faire du HTML qui-marche-tout-seul. WCAG 2, même si c'est un peu artificiel par moment, est conçu comme technology-agnostic. Pour la création d'un site web accessible, on peut tout à fait, en respectant WCAG 2, choisir une technologie que l'on considère comme accessible, même si cette technologie n'est pas utilisée par tous.

Exemples de technologies accessibles mais pas forcément compatibles:
- Flash (même si c'est parfois bancal).
- JavaScript + ARIA (même si c'est pas encore super implémenté).

Mon petit doigt me dit qu'un site public français qui respecterait le RGAA 2.0 pourrait fonctionner uniquement avec JavaScript activé, et être conforme grâce à une utilisation correcte d'ARIA. Je me demande ce qu'il en est du plugin Java, en passant (impots.gouv.fr, hum?).

Pour revenir au coeur du sujet: +1. Le choix d'un développement «JS non-intrusif» va surtout dépendre du type de site créé. Si le site fonctionne à 90% en HTTP et utilise une petite ou moyenne dose d'Ajax, autant développer à 100% en HTTP (ça facilite une partie des tests automatisés, en passant), et rajouter les 10% de JS nécessaire. Si on est essentiellement sur une application web, qui gère des objets et des workflows très éloignés du Web des contenus, le full-JS peut être tout à fait pertinent.

Bof.

Je crois que sur le fond le prob ne vient pas de JS mais de Html. Tant qu'il s'agit de produire un "rendu" structuré et séquencé (site, blog...) Html va très bien dans la mesure où il tire sa sémantique et ses fonctionnalités de son ancêtre l'imprimé. Disons en gros que plus de 90% de ses balises concernent le "rendu", et donc moins de 10% concernent l'applicatif/interactif.
Donc dès qu'il s'agit de produire du "massivement applicatif", s'appuyer sur Html est de moins en moins tenable. Pour le moment on fait avec mais c'est souvent par méconnaissance ou manque d'énergie ou manque de temps.

Comme ça fait longtemps que j'ai pas trollé un vendredy avec mes expérimentations dans l'hyperweb de la mort qui tue, suite à des questionnements et probs de méthode avec mon robot conversationnel (le webmaster virtuel en AIML) j'ai été amené à m'intéresser à diverses choses ces derniers mois qui m'éloignent de plus en plus de Html pour entrer dans d'autres dimensions du web, notamment du côté du web des objets.

En couplant/mélangeant/mixant langages et API (Pachube, Bots, Touachatag, etc.) on arrive à des résultats assez drôles. Par exemple en associant une puce RFID à une tasse à café (qui se retrouve du coup taguée en quelque sorte) et en paramétrant un script Touchatag on peut envoyer un Twitt chaque fois qu'on prend un café. Dit comme ça ça fait gadget, mais les apllications/interactions entre utilisateurs/contenus/objets avancent très vite. Par ex je peux aujourd'hui produire en quelques secondes une image QRcode (code barre 2D) que j'affiche sur le web ou dans un univers virtuel, image qu'un mobile, un PDA, un iPhone peut scanner et à laquelle réagir illico : si j'encapsule une URL dans le QRCode, iPhone ouvre la page, si c'est un n° de tél il l'appelle direct, etc. Ex d'application ? des affiches de concert avec un code barre en 2D qu'il suffit de le scanner avec un iPhone pour afficher le site du groupe. Là on n'est plus du tout dans des usages Html classiques (a href) mais dans des dialogues entre objets = ici une affiche imprimée passe une URL à un phone. Elle pourrait aussi lui passer une video par ex.

Vous pouvez aussi jeter un coup d'oeil du côté de ARTisan (web en réalité augmentée) ou encore de Processing (langage d'événements interactifs) ou même Pachube, une API qui couple objets réels et objets virtuels et permet l'échange de datas via des sensors numériques ou physiques. A partir du moment où les contenus sont constitués de valeurs d'échange informationnelle entre objets et utilisateurs (réalité virtuelle, réalité augmentée, immersivité dans du contenu 3D, etc) on n'a plus du tout besoin des langages du "web d'autrefois".

Et j'ai même pas osé parler des univers virtuels 3D parce que de ce côté là ça va vite aussi. Des gars ont reconstitué un lieu virtuel en partant d'un lieu réel bardé des capteurs : si on est dans le lieu virtuel les êtres réels apparaissent en proj vidéo au milieu des avatars, comme apparaissent en holo 3D les avatars présents dans le lieu virtuel au milieu des gens du lieu réel (vous suivez ?). Du coup les échanges sociaux ne passent plus par un support Html (comme dans Twitter ou Facebook) mais via des canaux de voice et des recognizers qui stockent tout ça. Concrètement, pour le web au quotidien, ça préfigure des usages- pas si éloignés que ça - où Html/Js n'ont plus cours. Restera probablement toujours des datas à présenter "à l'ancienne" (Html5-Css-Js-Ajax) mais ce n'est certainement pas l'avenir du web. Et c'est pas Chan "XMPP" Gaco qui va me contredire

Donc pour conclure - et revenir au débat - il me paraît plus intéressant de chercher dans ces directions-là plutôt que chercher à tordre Html/JS dans tous les sens pour leur faire faire ce pourquoi ils ne sont pas fait, et en plus se coller des maux de crâne avec des questions existentielles (puis-je obstruer ou pas) qui n'ont à mon avis pas franchement lieu d'être.

Arsene a écrit :
il me paraît plus intéressant de chercher dans ces directions-là plutôt que chercher à tordre Html/JS dans tous les sens pour leur faire faire ce pourquoi ils ne sont pas fait

Sauf que pour créer aujourd'hui une application web sans entrer dans la R&D, on n'a pas des centaines de possibilités. Soit c'est du standard html/css/js, soit c'est du plugin Flash et autres Silverlight. Dans un cas on perversifie un peu la technologie (quoi qu'avec HTML5 c'est déjà un peu moins le cas), dans l'autre on passe dans le propriétaire avec tout ce que ça engendre comme problèmes et dépendances.

À choisir, je perversifie.
Modifié par Benjamin D.C. (04 Sep 2009 - 18:07)

Tiens, just for fun : utilisation de RFID pour interactions entre monde réel, monde virtuel et document web. Les applis potentielles sont nombreuses : éducation (apprentissage gestuel), e-commerce (gestion boutique web + boutique 3D), jeux en ligne+réel simultanés, etc. C'est tourné à la va-vite sur un tél et j'ai commenté ça en anglais, mondialisation oblige. Un de ces 4 je ferai une version clean un peu moins bricolée.
Un capteur RFID envoie un signal à mon serveur qui le traduit en information Html d'un côté (petite fenêtre FF à droite) et en langage LSL de l'autre (navigateur SecondLife à gauche). Pas un poil de flash ni de javascript, sauf pour recharger chaque seconde un fichier xml qui contient les datas passées par RFID. L'idée c'est d'interéchanger des contenus entre différents supports (des objets, ou comme ici des positions d'objets).
Et dans cet essai assez "space" je transfère un objet de réalité augmentée (une petite video de chat qui joue du piano) de la réalité physique à la réalité virtuelle en utilisant l'iPhone comme "outil de transport" pour drag-droper la video en question d'un endroità un autre. Vu comme ça ça fait gadget mais on imagine ce qu'on peut produire par exemple en capturant un élément de texte (ou une video comme ici) en réalité augmentée et en allant le coller dans un template de site... dans le genre CMS de demain, ça le fait assez.

Sinon en plus grave (mais là c'est pas de moi, faut pas rêver) :le MIT s'essaie au web futur... Alors là les gars, même Cruise dans Minority Report est écrasé

Benjamin D.C. a écrit :
Il est aujourd'hui impensable de faire de l'applicatif pur et dur de manière non obstrusive.

Tu as bien dit aujourd'hui qui s'est dans le futur, surtout avec des specs comme WAI ARIA et aussi si les JS frameworks se mettent a supporter ca (par exemple YUI bon c'est en anglais http://yuiblog.com/blog/2007/12/21/menu-waiaria/)

Pour moi, le non intrusif ce n'est pas arreter d'utiliser JS, le non intrusif c'est d'avoir une behavior layer (comme ils disent en anglais). C'est a dire ne pas polluer le HTML avec des onclick, onsubmit et autres m*rd*s, et tout faire par event listener.