Les applications web (interface utilisateur universelle ?)

Bonsoir,

En deux points



Une place pour discuter des questions spécifiques aux applications web ?

Je ne sais pas si c’est mal venu ou pas, mais je trouve que sur Alsacréations il est difficile d’avoir des commentaires sur des questions relatives aux applications web. C’est, et je le comprend, que le propos y est plus souvent le web orienté contenu.

Mais je ne connais pas de lieux aussi intéressant que Alsacréations où la question des applications web serait mieux venue. En connaissez-vous ? Un endroit où on puisse discuter des questions d’interface utilisateurs, des questions de difficultés techniques, spécifiques aux applications web ?

Just for sharing, une page basique mais pertinente qui parle de la différence entre le design pour les sites de contenu et le design pour les site applications : User Interface Design for Web Applications [Jean Tillman]

Elle raconte, alors qu’elle avait surtout une expérience de la conception de site orienté contenu, ses pensées alors qu’elle a dut se plonger dans la conception d’une application web. Rudimentaire (j’y ai reconnu beaucoup de choses), mais pertinent et surtout utiles à lire pour les gens qui n’en ont pas vraiment une idée.



HTML+CSS+JavaSript vers HTML+CSS+Application

La portabilité est une question ou un problème courant dans le logiciel. Le point qui à mon avis pose le plus de problème de portabilité, c’est l’interface utilisateur (ce qui est système, en poses aussi, mais a plus de solutions légères).

Ça fait un bout de temps (quelques années) que je me dis que la page web, c’est l’interface utilisateur idéale. De plus, la plupart des environnements disposent d’au moins un navigateur, qui est souvent un navigateur par défaut bien intégré au reste du système.

Première question : sous Windows on peut intégrer une page web à une application, et ce sont les services d’Internet Explorer qui sont alors invoqués (il existe même les HTA, HTML Application). Mais en est-il de même par exemple sous Mac avec Safari ? Je suppose que oui, en tous cas j’imagine. Mais sous les UNIX-like, genre BSD et d’autres (avec Konqueror), j’ai un doute.

En même temps, il existe WebKit, qui permet d’embarquer une page web dans une application, mais je crains pour la lourdeur et la difficulté à compiler.

En fait, ce que j’aimerais, c’est avoir la ou les pages HTML+CSS pour l’interface, mais sans le JavaScript, et d’utiliser une application ordinaire à la place du JavaScript.

Je me demandais si des gens ici ont déjà d’expériences dans ce domaine. Des retours des expériences ? Des savoir à partager ?
Modifié par hibou57 (15 Jan 2011 - 20:16)

Sujet interessant, ne serait deja pour relever quelques bonnes pratiques pour les interfaces d'administration de gestionnaire de contenu (CMS) , je bookmark d'avance ce sujet.

GC

gc-nomade a écrit :
Sujet interessant, ne serait deja pour relever quelques bonnes pratiques pour les interfaces d'administration de gestionnaire de contenu (CMS) , je bookmark d'avance ce sujet.

GC

Merci, ça fait plaisir de voir cet intérêt pour la question

Tant que tu es là, et que la question t’intéresse, je vais faire l’égoïste, et t’inviter, si ça t’inspire, à répondre à ce fil : Gestionnaire de fichier rudimentaire (aspect et comportement de l’UI). C’est une application en ligne que je retravaille régulièrement (44.000 lignes de JavaScript et presqu’autant en Pascal pour les CGI, oops), mais je n’arrive jamais à être totalement satisfait. Je crois que le design des boites de dialogues va encore être à refaire pour la nième fois, parce que justement, ça n’est pas assez applicatif et trop inspiré d’une page de contenu. Trop de défilement nécessaire par exemple pour le dialogue «Options du document» et «Nouveau document», espace mal employé, etc. Comme très bien dit dans le lien que je donne dans le premier message, le graphisme d’une application en ligne n’est pas le même que celui d’un site de contenu, il faut être modéré dans le cas d’une application web… mais un minimum de style est nécessaire malgré tout.

Parlant technique spécifique justement, j’ai pas mal de question à résoudre avec la manipulation du focus et la navigation dans les contrôles avec la tabulation (j’espère faire une mise à jours bientôt avec ces problèmes corrigés).

And you, tu veux partager un lien sur une application en ligne que tu as créé pour qu’on en discute ?

Il y a aussi la question de l’accessibilité, je suis convaincu qu’elle devrait s’appliquer également aux applications web, mais quand il en est question, ça ne concerne que les sites de contenu, avec des recommandations qui n’ont de sens que pour ce type de site. Pire encore, certaines choses nécessaires pour une application en ligne, comme la re-définition de certains comportement par défaut, est considéré comme une chose à éviter pour ces mêmes règles d’accessibilité qui ne s’appliquent qu’aux sites de contenu. Manière de dire qu’il faudrait pouvoir traiter de cette question de manière spécifique.
Modifié par hibou57 (15 Jan 2011 - 23:09)

a écrit :
Il y a aussi la question de l’accessibilité, je suis convaincu qu’elle devrait s’appliquer également aux applications web, mais quand il en est question,
ça ne concerne que les sites de contenu, avec des recommandations qui n’ont de sens que pour ce type de site. Pire encore, certaines choses nécessaires
pour une application en ligne, comme la re-définition de certains comportement par défaut, est considéré comme une chose à éviter pour ces mêmes règles
d’accessibilité qui ne s’appliquent qu’aux sites de contenu. Manière de dire qu’il faudrait pouvoir traiter de cette question de manière spécifique.

C'est vrai qu'on parle souvent de l'accessibilité des contenus web, mais relativement peu d'autres cadres où l'accessibilité devrait être aussi importante :
1 - Accessibilité des contenus dans d'autres formats de document courants, PDF, word et open office notamment
2 - -Accessibilité des applications web, effectivement
3 - Accessibilité des applications de bureau, avec ou sans framework type WXWidget, QT, etc.

1a. accessibilité des documents word et open office
J'ai déjà réussi à trouver des informations sur l'accessibilité des documents dans ces formats, mais la documentation est relativement rare comparativement à la'ccessibilité du web. Or, tous deux donnent la possibilité, comme en HTML, d'ajouter des métadonnées utiles à l'accessibilité: hiérarchies de titres, textes alternatifs pour les images et contenus embarqués, citations, mise en évidence, changements de langue... le seul endroit où ça paraît à priori moins riche, c'est pour les tableaux où il n'y a apparament rien pour les cellules d'en-têtes et les relations entres les cellules.

Étant donné le taux de pénétration des fonctionnalités relatives aux styles et les pratiques très douteuses de certains utilisateurs, c'est vraiment pas gagné, ne serait-ce déjà rien que pour les titrs.

Jaws et NVDA, pour ne citer qu'eux, ont déjà tout prévu pourtant, la navigation dans un word accessible est normalement aussi simple que sur une page web accessible.

1b. accessibilité des PDF
Là aussi on trouve un peu quelque chose mais seulement si on a de la chance. Basiquement, même observation que pour word et open office, les possibilités sont théoriquement là.

Gros problème: pratiquement aucun outil n'est capable d'enregistrer du PDF réellement accessible. Il n'y a guère que word et open office et encore, il faut concevoir correctement le document dans l'éditeur ce qui n'est déjà pas gagné, en plus de devoir modifier des options particulièrement bien cachées, et dans tous les cas ça ne sera même pas encore parfait. Sinon, retouche à la mano dans adobe PDF pro, mais vu que le logiciel est cher et que c'est compliqué d'aller bidouiller les balises d'accessibilité, personne n'est assez fou pour perdre du temps là-dessus.
Je n'ai vu jusqu'à ce jour qu'un seul document PDF accessible: le document d'accessiweb qui décrit justement les étapes à suivre pour rendre son PDF accessible (Encore heureux). Pour les autres, le potentiel est totalement sous-exploité.

A part ça, rien, rien, rien. aussi étrange que cela puisse paraître LaTeX vous oubliez, PDF creator et autres imprimantes PDF vous oubliez, et vous pouvez aussi oublier tous les générateurs/convertisseurs en ligne en php, java, C# ou n'importe quoi d'autre. Aucun n'est capable de produire du PDF réellement accessible jusqu'au bout en utilisant toutes les possibilités offertes. Certains sont capables de produire un PDF qui est quand même plus ou moins lisible avec une synthèse, alors que d'autres produisent des choses vraiment inintelligibles (LaTeX ou adobe indesign par exemple, le pire c'est encore LaTeX bizarrement, un format qui a pourtant une sémantique très riche, dix fois plus encore que le HTML, et adobe indesign c'est un comble, si adobe ne peut même pas s'entendre avec lui-même où va-t-on).
ET par dessus le marché, aucune documentation gratuite et claire sur le format PDF et ses balises d'accessibilité. J'avais pourtant cru entendre que le format PDF était censé être ouvert ?

Bref, ma conclusion sur le PDF c'est qu'il va encore se passer quelques millions d'années avant qu'on commence à se rendre compte que les possibilités existent mais que personne ne peut les utiliser.

2. accessibilité des applications web

Alors là, on peut espérer que ça s'améliore gentiment avec l'arrivée progressive d'aria. Mais bon, ce n'est encore pas complètement au point, particulièrement les zones rich text.
En 2011, les grandes applications font encore et toujours n'importe quoi: le nouveau twitter c'est une catastrophe, facebook ne s'améliore pas vraiment... et google descend gentiment dans mon estime (j'ai pu m'apercevoir récemment que google docs n'était plus du tout accessible, il ne l'a jamais vraiment été mais à une époque on pouvait au moins lire les documents et taper du texte au kilomètre).
Pour ne rien arranger, freedom scientific aussi font quelques bêtises, comme leur façon de traiter role="application" et role="document" qui est à mon goût un peu bizarre...

Sans oublier que certaines mauvaises pratiques sont bien ancrées, petit classement rapide :
* On n'ajoute pas des div dynamiques tout à la fin du document mais au bon endroit dans le DOM, ou alors on trouve un moyen de diriger le focus sans être trop gênant
* ON ne déplace pas le focus ni change de page ni soumet de formulaire quand l'utilisateur ne peut pas raisonnablement s'y attendre (en particulier, surtout pas sur un onchange de select)
* ON n'oublie pas de mettre à jour les attributs qui ont une influence sur l'accessibilité quand on ajoute/modifie/déplace des éléments dans le DOM (en particulier les alt des images et boutons, le texte des liens, leur focusabilité/cliquabilité, parfois les labels aussi)
* Tous les éléments interactifs doivent être focusables (je pense en particulier aux boutons à base de span ou div qui ne le sont souvent pas)
* Tous les éléments interactifs doivent avoir un texte qui fait office d'intitulé (ici je pense à la construction span ou div + background-image CSS, largement répandue mais pas du tout accessible)
* L'ordre de tabulation est logique (et on n'utilise surtout pas tabindex avec des valeurs différentes de 0 et -1, parce que tabindex c'est pourri)
* ON utilise des composants standard le plus possible (parce que les arrangements maison sont forcément moins bons, même avec aria)

ON pourrait encore dire beaucoup de choses, sur l'intégration du multimédia par exemple. JE me contenterai de dire à ce sujet que HTML5 est une très bonne chose, puisqu'il tend à établir un standard pour ces éléments, à l'heureux détriment du flash qui n'est pas adapté à cette utilisation. Flash doit rester dans son domaine, l'animation vectorielle. Pour le reste, je souhaiterais qu'il prenne progressivement la porte ces prochaînes années.

Alors vu que c'est en plein essor, on verra bien comment ça évolue. Mais j'ai l'impression que beaucoup de gens partent du principe que dès le moment où il y a du javascript/AJAX, c'est forcément inaccessible, et donc ce n'est plus nécessaire de prendre la peine de faire de l'accessibilité. C'est tout faux. C'est généralement inaccessible parce qu'on s'y prend souvent mal, c'est tout.
Si les efforts continuent et commencent à porter effectivement leurs fruits en ce qui concerne le web du contenu, ça a quand même du mal de prendre du côté des applications je trouve.

Pour les fans du flash, il y a moyen de rendre les animations accessibles dans une certaine mesure... c'est comme pour le PDF: il existe des choses mais personne ne les utilise.

3. Accessibilité des applications de bureau

En ce qui concerne les applications de bureau, je n'ai pas vraiment trouvé de documentations bien claires, ni en français ni en anglais. Mais on serait étonné de constater à quel point ça ressemble en fait beaucoup à ce qu'on peut dire sur les applications web. Alors bien sûr pas de javascript ni d'AJAX en tant que tel, mais je trouve amusant certains points me paraissant communs :
* Les règles sur le déplacement du focus sont les mêmes: on ne déplace pas le focus quand l'utilisateur ne peut pas raisonnablement s'y attendre. Ici aussi, ça vaut en particulier pour un changement de sélection dans une liste déroulante ou non.
* Les règles sur les changements de page sont aussi les mêmes: sauf qu'ici on remplace les pages par le contenu d'une boîte de dialogue ou par l'apparition/disparition de boîtes de dialogues
* Les règles sur la focusabilité et l'ordre de tabulation sont encore les mêmes... un composant interactif non focusable n'est pas accessible, c'est aussi simple que ça
* Tous les composants doivent avoir un intitulé. Pour les boutons graphiques, il y a aussi des moyens pour indiquer un texte alternatif.
* ON n'oublie pas de mettre à jour les intitulés des composants même si les dits intitulés ne sont pas visibles... ça aussi c'est valable.

Mais là où la ressemblance est la plus troublante je trouve, c'est en ce qui concerne l'utilisation de composants standard: dans le monde des applications de bureau aussi, on doit au maximum utiliser les composants standard, et rien que les composants standard, pour faire des applications au maximum accessibles. Ce qui signifie en clair :
* API Win32 sous windows
* Cocoa sous mac
* GTK sous linux/gnome
* Pour KDE je sais pas mais il y a aussi une API native

SWT et WXWidget se reposent sur les composants standard, donc ils produisent aussi des applications globalement accessibles. Là où ça commence à se gâter, c'est qu'on doit pouvoir dire adieu à QT et à GTK ailleurs que sous gnome, ainsi qu'à toutes les autres bibliothèques dessinant leurs composants à leur manière. Le truc c'est qu'ils sont encore bien plus répandus encore que les composants JQuery mal fichus.
Swing de java se situe entre les deux en fait, car il est quasiment devenu aussi un standard. Il n'en reste pas moins qu'il se repose sur une API de liaison (access bridge), donc il restera forcément toujours moins bon que des composants purement standard.

Tout cela explique malheureusement pourquoi une bonne partie des logiciels libres ne sont pas accessibles, et pourquoi les utilisateurs de jaws comme moi sont encore en grande partie obligés d'utiliser les logiciels qu'on a bien voulu vous rendre accessible. Pour rappel, open office avec jaws, c'est pas terrible, safari et chrome on oublie d'entrée, et le support de firefox n'est pas si vieux que ça.
C'est pourquoi NVDA pourrait bien, à terme, détrôner jaws... ils ont déjà de l'avance sur certains points, notamment aria, et certaines choses fonctionnent mieux avec NVDA que jaws sous windows 7.

ON pourrait faire une comparaison entre IAccessible2, MSAA et aria, je suis sûr qu'il y a beaucoup de choses en commun. Je ne connais pas suffisament les deux premiers pour en juger. Ce qui est sûr, c'est qu'il vaut toujours mieux, sur le bureau comme sur le web, préférer les composants natifs plutôt qu'utiliser des béquilles type aria/MSAA/IAccessible2, le plus possible, et de réserver ces derniers seulement quand ils sont vraiment nécessaires et/ou quand on n'a pas de solution standard.


Merci de m'avoir lu. JE crois que je viens d'établir un nouveau record.

J’avais prévu de prendre le temps de répondre à la longue (et plaisante) réponse qui précède, mais je n’avais pas eu le temps (j’y pense).

Mais je passe pour dire que XUL pourrait peut-être correspondre à ce que je recherche (sous réserve que ça y corresponde techniquement aussi) : XUL (en)

a écrit :
In computer programming, XUL (pronounced /ˈzuːl/ "zool"), the XML User Interface Language […] XUL relies on multiple existing web standards and web technologies, including CSS, JavaScript, and DOM.

Ce qui conviendrait mieux que Windows Presentation Foundation (en)

a écrit :
[…] WPF attempts to provide a consistent programming model for building applications and provides a separation between the user interface and the business logic. […]

qui bien qu’ayant des objectifs qui me séduisent, n’est absolument pas portable.

La page web comme interface utilisateur universelle… oui, ça semble possible. J’espère seulement qu’il est possible de remplacer les scripts par des binaires au sens propre du terme (sinon, ce n’est pas la peine).
Modifié par hibou57 (02 Feb 2011 - 12:46)

Ca se fait actuellement pour mobiles si je ne me plante pas, des outils comme Phonegap permettent de transformer ce qui est, à la base principalement une application Html + CSS (et souvent JS + API spécifique) en une application qui puisse être installable sur tous les OS mobiles.

Ca ne correspond pas tout à fait à ce dont tu parles, à part quelques détails techniques (géolocalisation, detection de mouvement/inclinaison/rotation, accéléromètre) la plupart du temps ça reste une appli web incrusté dans un navigateur, le tout compilé, mais on s'en approche.

Dans le même registre, pour ordinateur cette fois, il y a sous Mac, Prism si mes souvenirs sont bons qui, grosso modo permet d'utiliser un site web comme une application : on lui attribut une icone, une adresse de base, et ensuite on ne voit qu'une page web et plus du tout un navigateur complet... Il faut toujours être en ligne, la technologie ne change pas, mais l'experience est différente !

L'idée de Phonegap n'est pas trop mal : faire une page web, l'insérer dans un navigateur, compiler le tout comme une application unique, ça permettrai de faire des applications portables, après niveau performances, on serait tout de suite limité ça c'est fort probable !

Ca me rappelle un projet de Mozilla Labs (qui après quelques recherches, s'avère être le futur de Prism).

Il s'agit du projet Chromeless. Je n'ai pas beaucoup étudié la question, mais je crois qu'avant il était possible de réaliser une application en utilisant XUL. Le but de Chromeless est de réaliser la même opération mais en html.

QuentinC a écrit :
Tout cela explique malheureusement pourquoi une bonne partie des logiciels libres ne sont pas accessibles, et pourquoi les utilisateurs de jaws comme moi sont encore en grande partie obligés d'utiliser les logiciels qu'on a bien voulu vous rendre accessible. Pour rappel, open office avec jaws, c'est pas terrible, safari et chrome on oublie d'entrée, et le support de firefox n'est pas si vieux que ça.
C'est pourquoi NVDA pourrait bien, à terme, détrôner jaws... ils ont déjà de l'avance sur certains points, notamment aria, et certaines choses fonctionnent mieux avec NVDA que jaws sous windows 7

Pour ce qui est d'open office, maintenant qu'il y a un fork (LibreOffice) dont une première version stable vient de sortir, j'espère qu'on aura plus de chance de voir les améliorations concernant l'accessibilité implémentées, maintenant que cette branche est détachée d'Oracle et qu'il y a déjà plus de transparence au niveau de la feuille de route.

À part de ça, es-tu sur Framagora ? Car je sais que depuis l'année dernière, Framasoft collabore avec l'April sur un groupe de travail sur l'accessibilité libre (lien), mais mis à part répertorier les logiciels d'aide à l'accessibilité comme NVDA ou ToutEnClic, il serait intéressant de discuter de l'accessibilité des logiciels libres en général, et à ma connaissance, je n'ai pas encore vu de Framanaute en situation de handicap... ou du moins qui l'ont déjà révélé, je n'en ai vu qu'un ou deux dont un membre de la famille atteint d'un handicap.

hibou57 a écrit :
je me dis que la page web, c’est l’interface utilisateur idéale

Hu, c'est exactement ce que je reproche aux applis web Le chrome du navigateur n'a aucune utilité ou presque dans la grande majorité des cas (éventuellement les boutons back/next, voire la barre d'adresse pour des applis basiques et linéaires). Certaines features sont même totalement confusantes. J'ai déjà assisté plusieurs fois au cas de l'utilisateur lambda qui tape sa recherche en haut à droite du browser pour faire une recherche au sein de l'app…

Bref: vive les technos web mais le cadre de travail, c'est pas encore ça.

Malheureusement d'accord avec Benjamin. c'est ce qui pousse certaines boites à préférer les clients lourds pour leurs ERP/CRM.

QuentinC a écrit :

C'est vrai qu'on parle souvent de l'accessibilité des contenus web, mais relativement peu d'autres cadres où l'accessibilité devrait être aussi importante :
1 - Accessibilité des contenus dans d'autres formats de document courants, PDF, word et open office notamment
2 - -Accessibilité des applications web, effectivement
3 - Accessibilité des applications de bureau, avec ou sans framework type WXWidget, QT, etc.

1a. accessibilité des documents word et open office
[...]

Désolé, je tarde encore à répondre à toute ta longue réponse. Mais comme tu avais parlé de l'accessibilité dans les logiciels open-source (ou gratuit ? ... vu la co,fusion est souvent faite), j'ai pensé à toi en voyant par exemple ça (qui va dans le bon sens) : SystemRescueCd [sysresccd.org]

a écrit :
SystemRescueCd is available for blind people. Now, the linux speakup screen reader is working well, and the speakup keymap is installed.

Ca a été une surprise de lire qu'il avait fait attention à ça, dans ce type d'application pourtant peu répandue.