exppad* / blog / Syndication web logicielle

Syndication web logicielle

L'interface graphique des applications de bureau est assez unifiée et simplifiée grâce aux bibliothèques de fonctions graphiques, mais la même chose est-elle possible pour les applis web ?

J'ai déjà parlé longuement de mon intérêt pour la syndication de contenus dans le cadre des flux RSS (de news, ou pas). Mais je pense qu'on peut aller plus loin et faire de la syndication logicielle.

Elle est partout

Le concept de syndication est inhérent à l'informatique : On peut dire qu'il y a syndication dès qu'un même programme est exécuté sur deux machines différentes, ou deux environnements différents. On fait sans cesse croire à un programme qu'il a accès aux mêmes informations alors qu'il tourne sur un matériel différent, éventuellement un OS différent, avec des paramètres différents, etc. C'est la raison pour laquelle on retrouve autant de couches d'abstractions superposées de partout.

Fondamentalement, dès qu'il y a un format ou un standard (et donc plusieurs implémentations différentes), ou même simplement une API, alors il y a de la syndication.

De façon plus concrète, le terminal ou le navigateur web en sont des exemples parfaits. Les pages (ou applications) web sont fournies en tant que texte, en HTML, et rien d'autre. C'est ensuite le navigateur, qui le transforme en quelque chose de regardable, manipulable, utilisable. On a d'ailleurs tellement poussé à bout ce mécanisme que le navigateur est devenu une vraie petite machine virtuelle, qui peut même prendre la place de l'OS comme pour Firefox OS ou les Chromebooks.

À un autre niveau, les bibliothèques de fonctions, voire les appels système de l'OS, sont un exemple intéressant aussi. La logique des libs est un peu différente : la lib fournit souvent les mêmes fonctions chez tout le monde. C'est plutôt du côté des libs graphiques qu'on trouve de bons exemples de syndication puisqu'elles permettent alors de donner un style graphique uniformisé entre les différents programmes.

Ou presque

Là où je trouve qu'on en manque, c'est du côté des services web. J'installe sur mon petit serveur perso tout plein de services web : Lutim, Zerobin, phpMyAdmin, Etherpads, Shaarli, Leed, Freeder, etc. Et j'ai aussi diverses interfaces web de services système : ZNC, BitlBee, etc.

Le résultat final ressemble à un grand puzzle dont chaque pièce a une origine et un style différents… Certains services sont assez simples à « thèmer », ceux qui utilisent RainTPL par exemple (Zerobin, Shaarli, Freeder) mais ça reste une tâche assez longue et surtout qui nécessite de comprendre un minimum comment l'appli est faite.

Ce qu'il faudrait, c'est que l'appli dise « J'ai besoin de telles et telles entrées dans le menu, puis d'une zone de texte ici, un bouton par là » mais sans donner les détails d'agencement et de style qui seraient eux laissés à un code écrit une fois pour toutes par l'utilisateur.

Exactement comme les libs graphiques en fait. Mais pour le web.

Je ne demande pas à ce que le backend se plie à une UI fixée. Ça c'est mal… C'est plutôt une couche d'abstration entre la logique et l'UI et son apparence à laquelle il serait pratique d'avoir accès.

Ça permettrait même des économies de temps à des petits projets. C'est d'ailleurs ce qui fait la force de la ligne de commande à mon avis : pas besoin de s'intéresser à l'interface utilisateur puisqu'elle est automatiquement faite (bien qu'un peu austère).

Ce qu'on peut déjà trouver

YunoHost

Un projet qui m'a fait penser à cette idée est le projet YunoHost (en lequel j'ai pas mal d'espoir soit dit en passant). Il propose à l'installation ce genre de services, mis sous forme de paquets, avec une très légère surcouche (un bouton permettant de revenir au menu principal en gros).

L'idée de regrouper est là, mais chaque appli conserve son style complet. Je pense qu'un moyen de syndiquer l'interface graphique serait utile pour ce projet.

D'autre part, la base d'applis déjà disponibles dans les dépôts de YunoHost permet déjà de faire le point sur les besoins des différentes applications, de faire ressortir les points communs et mettre en évidence certaines difficultés.

Un autre projet dans la même veine est ArkOS.

Standards

On peut aussi chercher du côté des standards déjà existant. Il y a par exemple moyen de définir des variables CSS dont les valeurs sont attribuées par le client plutôt que le serveur. Ça peut déjà servir de base, même si ce n'est qu'un draft, notamment pour les services comme Etherpad qui sont fondamentalement pas évidents à personnaliser. On peut déjà choisir un jeu de couleur de base, à défaut de plus.

Mais si un tel standard existe, c'est bien pour aller dans ce sens, et il en existe peut-être d'autres que je n'ai pas trouvé. Je pense notamment qu'il faudrait chercher du côté des standards développés pour le Firefox OS puisqu'il a lui aussi grandement besoin de cette syndication !

Récapitulatif

Le protocole que je recherche devrait permettre :

  1. D'avoir un style unifié entre les différentes applis, et simple à personnaliser.
  2. De simplifier le développement de projets rapides ne voulant pas se soucier de l'interface graphique.
  3. De rester tout de même assez souple pour permettre aux applications de faire comme elles veulent si elles préfèrent, au moins pour certaines parties de l'interface, garder le contrôle.
  4. D'avoir plusieurs niveaux de personnalisation : juste des couleurs de base, puis un thème CSS complet, voire un moteur avec des règles plus complexes pour déterminer l'agencement des widgets.

Pour ça, la première étape est de chercher ce qui existe déjà dans les standards, du style des variables CSS utilisateur. Il faut ensuite définir plus en détails ce dont on a besoin en étudiant des exemples — ceux des dépôts de YunoHost par exemple. Et une fois un premier brouillon de protocole établit, il faut y adapter des applis phares, type Shaarli, Etherpad ou RoundCube, pour lancer le truc !

Surtout, si vous avez croisé ou avez eu des idées allant dans ce sens, n'hésitez pas à m'en faire part.

Article publié le 7 Septembre 2014 par Elie

Élie Michel


Réactions

Élie 9 Septembre2014 [source]

Oui voilà l'idée est de séparer interface et *backend* d'une façon plus ou moins standard. J'ai voulu modifier tous les services que j'ai installé de sorte à ajouter ne serait-ce que le bandeau Exppad dessus, mais j'ai renoncé puisque même pour unifier un peu les couleurs il faut passer plusieurs heures sur chaque service… Et évidemment que l'unité c'est moche si c'est un nivellement par le bas ! Il faut juste faire un beau thème et plus de problème. =P

Tom 8 Septembre2014 [source]

En effet, j'avais exagéré ma pensée pour mettre en évidence l'ineptie de l'utilisation massive de bootstrap et autres frameworks CSS. je n'avais pas saisi par contre que tu parlais également d'un système complet de vues, pour le coup c'est intéressant, parce que ça donne un cadre assez strict aux applis, donc si le travail d'ergo/ux (qui, comme tu le dis très bien, ne se limite pas à un choix de couleurs) est fait en amont, ça peut donner une unité complète, et pas qu'au niveau des couleurs (pour exagérer). Pour l'aspect monotone, je maintiens qui ça donne un côté pas toujours très sympa, en particulier quand l'interface commune est... moche (java, windows). Mais tu as bien raison en parlant de osx et elementary, j'avais un peu oublié cet exemple... Du coup, on peut imaginer que n'importe quel soft séparant déjà fortement gestion et interface, ou qui propose une API digne de ce nom, pourrait être implémenté dans ce "système" facilement ? Un avantage indéniable de ton idée est qu'elle pousse à une bonne séparation calcul (au sens large) et interface. Typiquement le lecteur de Mister aiR qui n'est qu'une page php et propose une appli js pour l'interface. Cela permet d'implémenter ce "système", sans créer de fork ni d'incompatibilité niveau code...

Élie 8 Septembre2014 [source]

@Tom: J'ai hésité à parler de bootstrap parce que, tout comme toi, je suis assez sceptique vis à vis de sa prolifération. Tu as raison en disant que c'est triste de voir un tel manque de diversité. Mais je pense en fait à un truc plus avancé qu'un simple CSS commun. Je pense plutôt à un générateur d'interface qui déciderait où placer les options, où placer le contenu, où placer les menus, etc. Mais par « où » j'entends « où dans l'appli », pas où dans la page. Il génèrerait un ensemble de vues. Évidemment, c'est un peu ambitieux et je ne présente aucune piste de mise en pratique, mais je n'avais pas l'intention de limiter l'idée au CSS. D'autre part, je pense comme Phyks qu'un peu d'unité ne ferait pas de mal. Ça fait plus *propre* du point de vue de l'utilisateur. Il ne perd pas ses repères entre les applications, n'a pas à tout réapprendre à chaque fois. Et puis c'est agréable à utiliser… Les applis bureau sont capables d'innover aussi. Peu de programmes n'utilisent que les widgets de base du système en général. Mais elles gardent en commun quelques couleurs du système comme le surlignement des menus ou l'aspect des fenêtres, des boutons, des textes, etc. Dans le cadre d'applis web, on n'a pas de de fenêtres bien sûr mais on peut vouloir conserver quelques éléments d'unité : un bandeau avec des boutons de navigation, une façon de présenter les menus, les fontes, les couleurs de base, etc. L'idée est aussi que chacun ait son propre thème chez lui. Les projets pourraient se contenter d'utiliser des thèmes déjà existants ou bien d'en créer un fait sur mesure, suggéré à l'utilisateur ne désirant pas utiliser les fonctionnalités de style commun. Mais du coup la comparaison avec bootstrap n'a plus lieu : n'utilisent bootstrap que ceux qui le veulent, chez eux. Et quand je parle d'accélérer le dev de petits services, je pense vraiment qu'il faut comparer au terminal plutôt. Un projet qui vise à être une suite complète et élaborée doit avoir son propre style, ses propres choix de design. Mais l'interface web de configuration de ZNC, par exemple, n'a aucune raison de se concentrer sur le design de ses widgets et des pages. C'est un outil, qui s'intègre dans une grande boîte à outil, et qui pourrait très bien être présenté de la même façon que les autres outils. Pour finir, le job de webdesigner est loin d'être mis en péril. Le travail sur l'UX va bien au delà de la couleur des bontous à mon avis. Il est plus important encore de réfléchir aux fonctionnalités à proposer, aux options par défaut, aux options disponibles tout court, à la clareté de l'UX, etc. Et tout ça, je ne pense pas qu'une machine puisse le faire elle-même aussi bien qu'un humain.

Phyks 7 Septembre2014 [source]

@Tom: +1 pour l'unité affreuse et la nécessité de designers dans le libre. Après, il faut aussi reconnaître que c'est l'unité graphique qui fait la force d'un Mac OS ou d'un elementary OS, non ? En fait, faudrait trouver un juste milieu. Le bootstrap de base à peine modifié, c'est pas top. Mais les applis qui partent dans tous les sens, c'est compliqué à thèmer et c'est mal intégré (cf Shaarli qui est hum… moche ?).

Tom 7 Septembre2014 [source]

En fait ce dont tu parles, c'est plus un framework non ? Typiquement, prends une appli faite avec bootstrap : changes le fichiers CSS et c'est stylé différemment. Les widgets de base permettent de faire boutons, calendriers, colones, bref, tout comme avec un créateur d'interface desktop. Si tu considères toutes les applis faites avec bootstrap, tu as une sacrée unitée graphique. Mon avis sur la chose maintenant : je trouve que cette unité est affreuse et déprimante. Que ce soit sur bureau ou sur le web. Ça permet d'avoir une bonne base dans le cas d'un dev rapide, mais au final, ça fait penser qu'il n'y à plus besoin des designers (ici j'entends par ce mot design et ux). Et le monde du libre à déja des devs, il n'a besoin que d'une chose (en exagérant un peu) : de designers. On peut utiliser ces thèmes de base pour deux choses je pense : prototypage, et applications métiers. Un projet libre qui se construit entièrement sur une interface préfabriquée ne se laisse pas la possibilité de prendre des partis pris ergonomiques forts, et peut se freiner dans le cas d'une évolution future (va essayer de reprendre une appli faite avec bootstrap… [J'ai déjà tenté, bah j'ai abandonné]). Bref, selon moi avoir une interface unifiée peut accélérer les choses dans un premier temps, mais fait perdre tout un pan du développement logiciel. Parce que ne pas se soucier de l’interface utilisateur, c'est faire à moitié son travail, et c'est ouvrir la porte à un web aussi triste que le monde des applis bureau.

In order to react, you are invited to use Webmentions.