Grav-plugin-admin: UX : ajouter du contenu modulaire

Nous avons certainement des projets pour améliorer la gestion modulaire des pages. La situation actuelle n'est qu'une question de simplicité et de cohérence du côté du code. Ce n'est pas encore la configuration idéale, mais cela fonctionne et une documentation aidera également à améliorer la situation.

Merci pour la réponse Andy. Je suis toujours très préoccupé par l'expérience utilisateur avec la présentation actuelle, mais uniquement en termes de création de page, y a-t-il une portée des changements que vous envisageriez à ce stade ?

Juste une réflexion de suivi rapide - si rien d'autre, je pense que changer le texte de la boîte de dialogue Ajouter un module de "Ajouter un contenu modulaire" à "Ajouter un contenu modulaire à la page" pourrait être utile ici. À plus long terme, et je sais que vous avez déjà des plans en tête, je pense toujours qu'avoir une boîte de dialogue "Ajouter une page" avec la possibilité de créer des pages de contenu parent, enfant ou modulaire pourrait être une approche viable à explorer.

Je me demande également si le fait de placer la liste déroulante "Page parente" comme premier élément dans "Ajouter une page" et "Ajouter un module" serait également plus utile pour les utilisateurs, car cette décision vient vraiment avant de nommer la page, etc. Qu'en pensez-vous ?

+1 pour améliorer la gestion avec des pages modulaires dans le plugin Admin

Du point de vue d'un utilisateur non technique, je pense qu'il serait plus logique d'avoir les sous-pages modulaires dans une union de la page parent. Alors peut-être que les éléments internes (= sous-pages modulaires) sont cachés à l'utilisateur et qu'il peut simplement voir et ajouter des blocs de contenu séparés à l'intérieur de la page parent.

Je suis d'accord avec @Jugibur

Un client normal va juste penser "je veux éditer cette page". Ils cliqueront probablement sur le nom de la page et verront ceci :

Qu'ils veuillent ajouter du contenu ou modifier ce qui s'y trouve, ils ne sauront pas quoi faire à partir d'ici. Ce serait un défi de bien le concevoir, mais j'imagine une page où je peux faire défiler les cases modifiables pour chacun des modules de la page dans l'ordre dans lequel ils apparaissent, et un bouton pour en ajouter un nouveau.

Comme je l'ai déjà dit, c'est quelque chose que nous voulons revoir. Nous savons que ce n'est pas idéal, mais c'est fonctionnel. C'est à dire que ça marche.

Nous travaillons actuellement sur une réécriture JS complète de l'admin. Cela nous permettra de développer l'interface utilisateur de la page modulaire que nous souhaitions depuis le début, mais que nous n'avions tout simplement pas le temps de mettre en œuvre correctement dans la version initiale.

Je pense que le plus gros problème en ce moment n'est pas l'interface utilisateur mais l'impossibilité de commander manuellement des pages modulaires. Je pense que cela devrait être par défaut, car les cas d'utilisation les plus courants pour les pages modulaires sont les lignes de contenu. Et pour ceux qui ont la date ou le nom, l'ordre n'a aucun sens.

De plus, ce qui aiderait est connecté à ceci https://github.com/getgrav/grav-plugin-admin/issues/735 . Nous devrions également pouvoir définir des pages qui ne sont pas modifiables pour les clients. Avec ces éléments, vous pouvez rendre la modification des pages assez sûre pour le client.

Quelque chose comme ça serait incroyable :
https://craftcms.com/docs/matrix-fields
https://github.com/benjamminf/craft-neo

En ce qui concerne la récente fusion de # 1174, il y a eu des discussions sur la façon dont l'interface utilisateur de l'administrateur gère cette désambiguïsation. Pour citer Paul Massendari à la fin de ce numéro :

Doit-on renommer "Add modular" en "Add module" ? https://github.com/getgrav/grav-plugin-admin/blob/develop/languages/en.yaml#L36

Le bouton typique pour ajouter du contenu se présente comme suit :

Ce qui est comme prévu compte tenu des trois principaux types de structures que possède Grav : page régulière, dossier et page modulaire. Cependant, la même liste déroulante sera présente dans d'autres contextes - ce qui persiste dans l'ambiguïté de ce qu'est une page et de ce qu'est une page modulaire. Pour me citer de Slack :

Conceptuellement, une page modulaire n'est pas une page ordinaire avec une collection, c'est une structure contenant des composants - des modules - et ne devrait avoir aucun autre type de page qui lui soit subordonné. Ainsi, alors qu'une page modulaire peut avoir des pages enfants régulières en termes de /sample/page, son contenu est entièrement défini par la collection qui dessine uniquement dans les modules, et ces modules ne sont pas visibles ou routables ailleurs. Bien sûr, en tant que construction, il ne s'agit en réalité que d'un sous-ensemble d'une page permettant une gestion plus facile des composants - le même effet peut être obtenu avec Twig et YAML - mais sur le plan conceptuel, il ne _devrait_ pas se mélanger dans des pages régulières. C'est pourquoi une séparation des préoccupations dans la liste déroulante "Ajouter" serait préférable, du point de vue de la façon dont Grav définit les pages.

De ce point de vue, un modulaire _ne devrait pas avoir de pages enfants régulières ou d'autres éléments enfants autres que les modules, mais avec l'interface utilisateur actuelle, ceux-ci peuvent être mélangés assez librement. Un exemple de Paul Massendari :

- home
- blog
  -_introtext
  -_latestarticles
  - _subscribe  
  - article1
  - article2

Ce qui en soi est sémantiquement parfaitement logique, mais l'ambiguïté entre une page normale et un modulaire est préservée. Ainsi, pour la séparation entre les deux - bien qu'un Modular soit un sous-ensemble de Page - l'interface utilisateur doit limiter les choix à ce qui est contextuellement approprié. La liste déroulante dans /admin/pages doit proposer d'ajouter une page, un dossier ou un module, sur une page modulaire, elle doit proposer d'ajouter un module, et dans la page et le dossier, elle doit également proposer d'ajouter les trois.

Un résumé de la séparation contextuelle (mis à jour le 28 août) :
Discuté plus en détail avec @paulhibbitts et @paulmassen , et en quelque sorte arrivé à cette distinction - bien que peut-être "Child" devrait être "Child Page" pour plus de clarté.

+Ajouter des éléments de menu sur la vue de liste de pages
Ajouter une page
Ajouter une page d'annonce
Ajouter une page modulaire
(Ajouter le dossier)

+Ajouter des éléments de menu sur la vue de page standard
Ajouter un enfant
(Ajouter le dossier)

+Ajouter des éléments de menu sur la vue de la page Liste (parent)
Ajouter un enfant
(Ajouter le dossier)

+Ajouter des éléments de menu sur la vue de page modulaire (parent)
Ajouter un module
Ajouter un enfant
(Ajouter le dossier)

Où le dossier est entre parenthèses car il doit toujours être en bas et séparé des types de page ci-dessus par un indicateur visuel tel qu'une fine bordure supérieure pour indiquer qu'il ne s'agit _pas_ d'un type de page, alors que tous les éléments ci-dessus sont adaptés au contexte les types. Les trois; Page, Listing, Modular sont alors des types standard par défaut, et https://learn.getgrav.org/content/content-pages devrait probablement être mis à jour pour refléter cela.

La logique la plus claire semble être : une page est n'importe quel fichier Markdown rendu par Grav, tandis qu'une page de liste est un sous-ensemble de page utilisé pour énumérer ses pages enfants autonomes, tandis qu'une page modulaire est un sous-ensemble de page qui habite ses pages enfants. comme des parties de lui-même. Ainsi, la liste des liens vers des éléments enfants séparés et Modular les affiche en lui-même. Page et Listing ont des pages enfants régulières, où Listing les répertorie principalement de manière ordonnée. Seul Modular a des modules.

Cependant, il est également nécessaire que les thèmes communiquent via des plans qu'ils prennent en charge des types de page spécifiques. Tous les thèmes n'ont pas de modèle par défaut, ou un pour la liste ou modulaire. Ainsi, les dialogues, les modaux, les boutons ou toute autre méthode d'ajout de pages doivent refléter ce que le thème prend en charge de manière inhérente à travers ses modèles.