{"id":2930,"date":"2017-07-27T23:29:55","date_gmt":"2017-07-27T21:29:55","guid":{"rendered":"http:\/\/blog.nebule.org\/?p=2930"},"modified":"2017-07-27T23:31:29","modified_gmt":"2017-07-27T21:31:29","slug":"reflexion-sur-levolution-de-linterface-web-pour-nebule","status":"publish","type":"post","link":"http:\/\/blog.nebule.org\/?p=2930","title":{"rendered":"R\u00e9flexion sur l’\u00e9volution de l’interface web pour nebule"},"content":{"rendered":"

Au fil du temps l’interface graphique, commun\u00e9ment appel\u00e9e Interface Homme-Machine (IHM), impl\u00e9ment\u00e9e dans les d\u00e9riv\u00e9s de nebule<\/a> s’am\u00e9liore et se structure autour de la biblioth\u00e8que<\/a> commune. Cette biblioth\u00e8que incorpore de mieux en mieux la pr\u00e9paration de plus en plus d’\u00e9l\u00e9ments graphiques communs.<\/p>\n

Cependant elle reste insatisfaisante.<\/p>\n

Il n’est pas question de parler d’un interface d’application qui apporterait quelques solutions \u00e0 certains probl\u00e8mes mais entra\u00eenerait de fait bien des probl\u00e8mes d’interop\u00e9rabilit\u00e9 et le suivi des codes qui vont avec.<\/p>\n

L’interface web semble la plus adapt\u00e9e aujourd’hui mais tra\u00eene malgr\u00e9 sa bonne standardisation la question de la gestion des multiples supports d’affichages. La philosophie habituelle \u00e0 la mode consiste \u00e0 faire g\u00e9rer par m\u00eame page l’ensemble des affichages possibles dans tout le gradient entre les plus minuscules smartphones et les ordinateurs aux \u00e9crans tr\u00e8s haute r\u00e9solution. Sans parler du tr\u00e8s faible \u00e9cart en r\u00e9solution des \u00e9crans \u00e0 mettre en parall\u00e8le \u00e0 leur l’\u00e9cart de tailles.<\/p>\n

C’est sans compter aussi le questionnement sur l’usage invasif et disproportionn\u00e9 du JavaScript<\/em> (JS). De plus en plus de pages web sur Internet incorporent des parties de code\/JS\/images\/etc venant de diff\u00e9rents CDN. L’\u00e9clatement du moteur de la page en de multiples d\u00e9pendances est tenable avec l’Internet actuel mais est profond\u00e9ment en opposition au fonctionnement de nebule<\/em> et est par nature tr\u00e8s sensible \u00e0 la fragmentation possible de l’Internet dans le futur. Le JS trop pointu est clairement une source de dysfonctionnement ainsi qu’une source de probl\u00e8mes de s\u00e9curit\u00e9.<\/p>\n

L’interface comporte deux parties:<\/p>\n

    \n
  1. le contenu de la page contenant l’information principale attendue par l’utilisateur ;<\/li>\n
  2. le cadre de la page avec des informations li\u00e9es \u00e0 l’environnement de l’information affich\u00e9e ou \u00e0 l’application.<\/li>\n<\/ol>\n

    Ces deux parties doivent \u00eatre plus clairement d\u00e9corr\u00e9l\u00e9es graphiquement. L’id\u00e9e est d’essayer de rendre plus l\u00e9ger, a\u00e9rien, le contenu et plus discret le cadre.<\/p>\n

    La vision d’avenir, sauf catastrophe, ce sont d’un c\u00f4t\u00e9 des \u00e9crans toujours plus grands avec des r\u00e9solutions toujours plus fines. Quand on dit grand c’est vraiment<\/span> grand, au point que de vouloir mettre en plein \u00e9cran une application n’ai plus vraiment de sens. Et d’un autre c\u00f4t\u00e9 une scission des appareils nomades en de multiples composants plus ou moins autonomes parmi lesquels l’\u00e9cran sera d\u00e9tach\u00e9 au plus pr\u00e8s des yeux de l’utilisateur, l\u00e0 encore avec des r\u00e9solutions tr\u00e8s fortes et avec de la transparence (canal alpha). Il faut aussi voir dispara\u00eetre le clavier et la souris au profit du tactile, de la commande vocale et du pilotage par les yeux et m\u00eame via une interface avec le cerveau. Il faut penser d\u00e8s maintenant \u00e0 pr\u00e9parer l’affichage des pages pour qu’il y ai une continuit\u00e9 entre la page web affich\u00e9e aujourd’hui et celle affich\u00e9e avec les \u00e9volutions pr\u00e9visibles de demain.<\/p>\n

    La pr\u00e9sence quasi syst\u00e9matique du double carr\u00e9 d’un objet peut permettre de le rendre actif en y cachant un menu des actions possibles simplement en cliquant dessus. Ainsi une liste d’objet ne sera plus pollu\u00e9e par de multiples boutons dans le cadre et sous chaque objets. Le menu li\u00e9 \u00e0 l’objet est bien s\u00fcr contextuel dans l’application et d\u00e9pendant du type d’objet. Dans la page qui affiche les entit\u00e9s, cliquer sur une entit\u00e9 fera afficher le menu lui correspondant dans lequel on trouvera le bouton qui permet de se connecter avec cette entit\u00e9.<\/p>\n

    Dans les menus du cadre ou des objets, l’activation d’un bouton ne sera plus imm\u00e9diatement suivi d’une action, et d’un rechargement de page, mais fera appara\u00eetre des informations plus pr\u00e9cises sur l’action du bouton et demandera un d\u00e9placement explicite sur un nouveau bouton pour valider l’action. Ainsi ce fonctionnement n’est pas trop p\u00e9nalisant pour un usage \u00e0 la souris et est tr\u00e8s adapt\u00e9 \u00e0 l’usage mobile tactile sur de petits \u00e9crans.<\/p>\n

    Les messages qui s’affichent en d\u00e9but de contenu, typiquement des alertes, seront syst\u00e9matiquement affich\u00e9s \u00e0 chaque rechargement d’une page mais devront pourvoir \u00eatre cach\u00e9s pour mieux acc\u00e9der au contenu.<\/p>\n

    L’affichage du contenu doit \u00eatre centr\u00e9 par d\u00e9faut horizontalement et verticalement. Sur un \u00e9cran de petite r\u00e9solution on doit limiter l’affichage pour avoir juste ascenseur vertical. Sur un \u00e9cran de haute r\u00e9solution le cadre sera suffisamment loin pour que tout ce que l’on fait sur l’objet en cours d’affichage soit clairement une action sur l’objet. On peut \u00e0 l’avenir imaginer que l’espace du contenu dispose de plusieurs zones qui affichent des objets diff\u00e9rents simultan\u00e9ment, et donc potentiellement dans des contextes diff\u00e9rents.<\/p>\n

    Le cadre doit contenir les informations sur l’entit\u00e9 connect\u00e9e et le contenu doit faire r\u00e9f\u00e9rence au besoin \u00e0 la vue restreinte \u00e0 une entit\u00e9 si ce n’est pas l’entit\u00e9 connect\u00e9e.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Au fil du temps l’interface graphique, commun\u00e9ment appel\u00e9e Interface Homme-Machine (IHM), impl\u00e9ment\u00e9e dans les d\u00e9riv\u00e9s de nebule s’am\u00e9liore et se structure autour de la biblioth\u00e8que commune. Cette biblioth\u00e8que incorpore de mieux en mieux la pr\u00e9paration de plus en plus d’\u00e9l\u00e9ments graphiques communs. Cependant elle reste insatisfaisante. Il n’est pas question de parler d’un interface d’application … Continuer la lecture de R\u00e9flexion sur l’\u00e9volution de l’interface web pour nebule<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[55,398,397,7,13,24],"tags":[],"_links":{"self":[{"href":"http:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts\/2930"}],"collection":[{"href":"http:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2930"}],"version-history":[{"count":6,"href":"http:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts\/2930\/revisions"}],"predecessor-version":[{"id":2936,"href":"http:\/\/blog.nebule.org\/index.php?rest_route=\/wp\/v2\/posts\/2930\/revisions\/2936"}],"wp:attachment":[{"href":"http:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2930"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2930"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.nebule.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2930"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}