Extraits et chapitre

a marqué ce sujet comme résolu.
Auteur du sujet

Reprise du dernier message de la page précédente

Une API qui permettrait à tous types de clients (lourd, web, mobile, que sais-je…) d'éditer les contenus à la guise de chacun n'en ferait-il pas partie ?

Clairement, non. Soyons honnête et pragmatique, 90% des utilisateurs utiliserons l'interface web primaire du site. Seul quelques power-user utiliseront un outils externe.

On a bien eu une extension Chrome puis Firefox pour avoir des notifications, des clients lourds qui permettent d'éditer des tutos, pourquoi pas des clients Web ou autres ?

Le client lourd pour éditer les tutos prouve bien que ça ne résous pas tout puisqu'il est disponible et manifestement ça n'a pas résolu nos problèmes.


On est d'accord cependant sur ta dernière phrase et je l'ai dit : si quelqu'un veut faire l'API pour le contenu (car c'est de ça qu'on parle), elle sera accepté (enfin je pense, c'est pas moi qui décide).

Ce sur quoi on est pas d'accord c'est sur son importance. Tu présente ça comme la façon la plus simple/importante/évidente façon de régler nos problèmes. Je ne suis pas d'accord pour plusieurs raisons. La première est que c'est un très gros morceaux. On a déjà eu l'expérience ici, que ce soit à la création du site, ou sur la zep qui concernait l'amélioration du module : au vue de nos effectifs et de leur logique volatilité (en terme de disponibilité), dans le meilleurs des cas cette API n'arrivera pas avant 6 mois (1 ans ou + me semble plus vraisemblable). Moi ça me gène franchement d'attendre encore 1 ans sans toucher à quoique ce soit dans ce module pour attendre une hypothétique API qui résolurai par magie tous nos problèmes (alors qu'en réalité, une fois l'API développé, il faudra attendre plusieurs mois que ces effets soit accessibles à tous).

J'ai rien, bien au contraire, que quelqu'un travail dessus. Mais il y a surement des améliorations qu'on peut mettre par évolution mineurs qui nous permettraient déjà d'améliorer les choses. On a déjà identifié un bouton "sauvegarder" et une pré-visualisation asynchrone. Si déjà ces deux actions qui peuvent être faites rapidement sont implémenté, ça aidera déjà nos utilisateurs. Ça ne résoudra pas tout mais je préfère qu'on améliore les choses que d'attendre 2 ans une solution miracle.

Les deux ne s'opposent pas. Des gens peuvent travailler sur une API contenu. Mais il y a certainement beaucoup de choses qui peuvent être amélioré sans.

PS: Tes propositions tu peux probablement déjà les expérimentés en rajoutant 2-3 vues assez faciles à faire dans Django. De toute façon un gros changement d'ampleur nécessitera plusieurs passes.

+3 -0

voici ce que je propose :

quelqu'un se lance dans un code JS. À un moment il tombe sur un cas qui est trop chiant à gérer avec nos trucs. Il m'appelle à la rescousse et je lui pop un endpoint d'api à la volée pour qu'on avance.

+0 -0
Auteur du sujet

Je ferai remarquer au passage que les petites améliorations qui ont été décidés (bouton de sauvegarde asynchrone et aperçu asynchrone) sont deux petites améliorations direct pour les utilisateurs ET deux vues/endpoint dont les dev JS peuvent probablement bien profiter pour améliorer l'interface actuel, non ?

+0 -0

Je profite du up de artragis pour préciser que l’aperçu asynchrone sur les pages de rédaction de contenus a été ajouté. Ça sera donc normalement disponible sur la prochaine version de ZdS.

Je travaille aussi sur une idée d’interface de merge pour les contenus en co-rédaction. Il y a une (belle ?) interface et le but est de rendre les choses vraiment accessible à tous. En bref l’idée est d’éviter l’écrasement du contenu quand plusieurs auteurs rédigent sur la même partie en même temps.

Bref, côté interface de rédaction ça bouge pas mal :)

+6 -0

POur information, la fonctionnalité qui permet la rédaction d’un article/chapitre dans une seule textarea sera bientôt prête pour un mode expérimental.

Pourquoi expérimental?

  • pour aller plus vite à la sortir, par exemple je n’ai pas mis en place de prévisualisation, car c’est pas trivial (faut gérer la hiérarchie des chapitres)
  • pour qu’en cas de bug, un simple flag permette aux sysadmin de désactiver le tout sans que ça n’impacte les auteurs
  • pour que vous puissiez rapidement faire des retours à propos de ça
  • pour que des premiers tests de l’API pour tuto qui a été de ce fait ajouté soient réalisés. Si firm1 est là ça peut l’intéresser pour zestwriter.
+4 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte