Exppad*

haut de page

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


Réactions

Les réactions on étés désactivées. Vous êtes invités à réagir par email (cf page de contact).