Réflexions sur SPIP, CMS, gestion de contenu

We wanted a service-based architecture, so that we could evolve the system, experiment with different technologies and replace parts of the whole without a complete rewrite.

Quand bien même certain⋅e⋅s disent que c’est une approche uniquement, ou trop, orientée dev-barbu⋅e, je pense de mon côté que c’est une des conditions majeures pour justement ensuite se focaliser facilement sur LES interfaces possibles à offrir aux utilisateurices.

Le fait de commencer par avoir des bases solides pour gérer le contenu, indépendamment de l’interface (ou après-coup, comme pour SPIP, de vouloir se focaliser d’abord sur le nettoyage du moteur, de la gestion des objets, du contenu, etc), permet ensuite de développer, de tester facilement diverses interfaces, et même d’en avoir plusieurs différentes activées en même temps (webapp, emails, logiciels, etc).

Voilà pourquoi dans cette réflexion que je me faisais sur SPIP, c’est dans le chapitre Édition que je parle des API.
►http://rastapopoulos.artizanal.info/notes/reflexions-sur-spip-cms-gestion-de-contenu

So, that’s the challenge. How can we help people relearn how the web is now?

Just like when people have a content management problem, a lot of people are turning to technology for the answers. And just like content management problems, my experience is software can’t fix it. Because it’s a people problem, not a software problem.

#interface #pédagogie

Je note au passage que Mark Boulton a décrit exactement le même découpage des CMS que ce que j’ai écrit il y a quelques semaines : en trois espaces. Et qui plus est, dans le même ordre.

1) A space for writing. For writing and structuring.
2) A space for management. For adding meta data, workflow, configuration and managing roles and people.
3)The website space. Basically your website. A place where you begin the access user journey. Or preview your content. Generally the starting points for lots of little administration tasks.

Réflexions sur #SPIP, CMS, gestion de contenu
►http://rastapopoulos.artizanal.info/notes/reflexions-sur-spip-cms-gestion-de-contenu

Dans un logiciel comme SPIP, il y a plein de fonctionnalités différentes, mais si on prend un peu de recul, je pense que l’on peut découper en trois grandes zones :
– Édition de contenu : créer et modifier des objets éditoriaux
– Gestion de contenu : stocker, classer, versionner et gérer les droits d’accès
– Publication du contenu : rendre visible aux autres du contenu, que ce soit celui provenant de l’édition OU d’autre part (boucle DATA, etc)

Bon, il m’a grillé de 14 jours : il a publié ça le 3 septembre, et moi le 17 septembre. :)

et cc @tetue je pense que ça peut l’intéresser.

Pas mal cette phrase aussi (vraiment plein de trucs biens quoi) :

But for most use cases, a WYSIWYG is not useful for content people. It’s just familiar.

(Après cinq ou six commentaires j’aurai fini par citer l’article en entier, haha.)

Et 4) une zone d’échange, ou comment répondre à la publication, la commenter — ce qui invoque les réflexions en cours sur les commentaires décentralisés (ou pas).

D’accord avec le reste, oui. Je pense aussi que ces « espaces » doivent être des briques modulaires indépendantes : qu’on puisse rédiger avec un outil A et publier via l’outil B. Ce qui signifie que nos/mes contributions ne doivent plus se faire au sein de tel ou tel CMS, mais être autonomes pour être plugables sur l’un ou l’autre.

J’approuve vos commentaires @rastapopoulos et @tetue ! ;-)