Pelican-Editor (WIP)

Bonjour à tous !

Je viens vous présenter le projet sur lequel je bosse en ce moment avec mon collaborateur Qwerty, s'intitulant Pelican-Editor.

Le projet

Vous connaissez peut-être le moteur de blog statique Pelican ? Si ce n'est pas le cas, un petit rappel s'impose : Pelican est donc un moteur de blog statique, écrit en Python, destiné à générer des pages html à partir de fichiers markdown. Ainsi, on rédige les billets du blog au format Markdown, on passe le tout à la moulinette, et il en sort plein de pages web prêtes à être uploadées sur un serveur et consultées ! L'intérêt des blogs statiques est que le contenu n'est pas dynamique, ce qui permet au client de mettre en cache les pages dans son navigateur et de ne pas être obligé de les recharger entièrement à chaque visite.

Le point faible du projet Pelican est qu'il se contrôle entièrement par la ligne de commande. C'est là que notre projet intervient : Pelican-Editor vous met à disposition une interface web claire, accessible et conviviale qui vous permet de rédiger des billets en format Markdown, de les sauvegarder et de générer votre blog, et tout ceci dans votre navigateur !

Objectif du projet

L'objectif général du projet est de familiariser les blogueurs aux moteurs de blog statiques qui habituellement ne sont pas très user-friendly. En effet, nous sommes convaincus que démocratiser les blogs statiques permet d'améliorer l'expérience utilisateur, de réduire les temps de chargement, se qui implique sûrement une baisse de consommation d'énergie.

Originalité du projet

L'originalité du projet est simple : je ne connais à ce jour aucun éditeur de ce type pour Pelican, ce qui m'a étonné quand nous nous sommes lancés, Qwerty et moi, dans ce projet.

L'équipe

Nous sommes deux collaborateurs à travailler conjointement sur ce projet. Qwerty, qui s'occupe de toute la partie PHP et Javascript, et moi-même, m'occupant du design de l'interface.

Aujourd'hui, l'application est encore en cours de développement, mais nous pouvons néanmoins vous proposer de découvrir l'interface dont le design est proche de son état final. Vous pouvez découvrir cela sur mon espace personnel : Démo Pelican-Editor.

Nous attendons avec impatience vos commentaires sur le projet. Merci à vous d'avoir pris la peine de lire ce message !

Amicalement, Qwerty et Vinm.

D'ailleurs, on se posait une question, c'est la gestion de l'upload. Un petit drag and drop ou simplement un input file comme on fait habituellement ?

Librement.

Le projet est vraiment intéressant, je ne connaissait pas Pelican et je vais me renseigner sur ce que c'est plus en détails ; pour le moment, l'interface est vraiment propre et très professionnelle, le projet part dans une bonne direction une seule petite chose me dérange, je trouve que les prompt() JS - par exemple lorsque l'on veut insérer un lien - ne sont vont pas vraiment avec le reste du design, pourquoi ne pas avoir fait de choix de plutôt mettre des pop-in qui peuvent du coup se styliser en CSS ?

Pour la gestion de l'upload, pour être user-friendly, le drag and drop serait le mieux, mais il serait sympa que vous mettiez les deux - il est possible de dropper un fichier sur l'éditeur mais aussi de cliquer sur un bouton qui ouvre une pop-in avec un input file - ; est-il prévu de rendre le projet open-source - je suppose que oui, mais au cas où - ?

Je vais tenter de tout répondre :

• Pour les prompt, à vrai dire, on avait pompé depuis un tuto du sdz et on a pas vraiment changé. Faut qu'on le fasse (Vinm, je te ping ;))

• Pour le drag an drop, on se base sur ce script, faut voir comment adapter.

• Oui, c'est OpenSource, sous licence MIT, on va publier les sources quand ça sera à peu près fini (Sur Github ?)

Ok c'est noté pour le style des pop-up.

Salut à tous !

Quelques nouvelles du projet aujourd'hui : qwerty m'a récemment fait remarqué que proposer cet outil exclusivement par le biais du navigateur n'était pas forcément judicieux, surtout par rapport au fait que nous n'avions pas vraiment défini le type d'utilisateur ciblé. En effet, nous n'avions pas décidé si cet outil serait plutôt utilisé par des administrateurs de serveur qui l'installeraient pour ensuite le mettre à disposition de leurs utilisateurs, où si ce serait plutôt une application qui pourrait être installée par n'importe qui.

Du coup, on a réfléchi, et on s'est dit qu'il serait peut-être mieux de réaliser cet outil à travers une interface hors-ligne, à la manière d'un éditeur de texte, mais pour Pelican. Avec une fonction de navigation parmi les articles (voire un gestionnaire de blogs pour en prendre plusieurs en compte), une interface d'édition Markdown avec à côté l'aperçu du Markdown généré, une fonction d'enregistrement du fichier, et une fonction de génération du blog.

Que pensez-vous de ce changement de cap ? Trouvez-vous plus judicieux de procéder de la sorte, à savoir proposer Pelican Editor sous forme d'application hors-ligne à installer sur son système personnel, ou préférez-vous la première idée qui était de proposer l'éditeur comme une application à installer sur un serveur, comme une instance ?

Merci d'avance pour vos commentaires.

Une remarque par rapport à ce changement de cap : pourquoi est-ce que le projet hors-ligne exclut celui en ligne ? Du moins, s'il faut choisir entre l'un des deux projets, ou donner la priorité à l'un, je pencherais vers l'interface hors-ligne.

Oui oui bien sûr, on se concentrerait seulement sur l'application hors-ligne.

Salut!

Je suis pas convaincu par l'idée, personnellement. Si j'ai bien compris, l'éditeur hors-ligne modifirait une version local du blog, qu'il faudrait ensuite uploader ? Je ne comprends pas vraiment pourquoi on devrait se tracasser à uploader son blog à chaque nouveau article/édition d'article. Je suis à côté de la plaque ?

Bah, c'est le principe de Pelican… Habituellement, tu rédiges et génères le site en local, et ensuite tu upload les pages html générées sur le serveur. Tu comprends, c'est pas utile de rajouter une charge de travail au serveur (installer Pelican et générer les pages) quand on peut le faire en local. Après, on pourrait rajouter une fonction d'envoi via FTP sur notre application.

Je ne suis pas sûr que ce soit une grande charge de travail pour un serveur de générer des fichiers textes une fois par semaine. Après, je comprend que l'installation de Pelican sur le serveur est une étape à ne pas sous-estimer.

Dans tout les cas, je suivrais ce projet avec attention!

C'est pas une grande charge en soi, mais une accumulation de petites charges en produit une grosse. Aussi le nombre de génération dépend de la fréquence d'écriture du blog.

Pourtant c'est plus simple. Tu rédiges ton article dans ton éditeur favori, tu tapes la commande qui va bien, et c'est en ligne. Pas besoin de copier-coller dans 15 champs de texte dans ton navigateur.

C'est le workflow encouragé par les moteurs de blog statiques de toute façon…

Personnellement, j'ai pas d'éditeur sur ma tablette. Bref, on est juste en train de lister les avantages du web et les avantages des programmes natifs.

Personnellement, j'ai pas d'éditeur sur ma tablette.

Hé ben change de tablette ?..

Non, on est en train de t'expliquer le principe des moteurs de blog statiques.