Ces concepts sont largement influencés par:

• Blocs atomiques
• WordPress.com
• Bibliothèque de conception

Je pense que la standardisation d'un flux UX pour cette interaction profiterait à Gutenberg et aux utilisateurs.

Nous avons un support pour cela, mais uniquement par type de publication et le modèle est appliqué au chargement, avec la logique suivante:

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

Je ne vois pas beaucoup de valeur à cela et j'aimerais bien avoir quelque chose comme ce que vous venez de décrire.

J'aime davantage l'approche de superposition car elle a plus d'espace d'écran pour montrer les modèles disponibles.

Cette fonctionnalité serait parallèle à tout travail de zones de bloc. Il pourrait y avoir des modèles faits pour les articles et des modèles faits pour les modèles ou toute autre zone de bloc. Par exemple, un modèle de modèle peut être utilisé pour changer rapidement le modèle de publication unique en une mise en page avec une barre latérale.

Gutenberg ne devrait pas définir les valeurs par défaut, mais les thèmes par défaut devraient certainement être livrés avec eux.

Ma première pensée est que ce modèle de bloc ajouté ne remplacerait PAS le contenu de la page, mais ajouterait plutôt les blocs au bas. De cette façon, le modèle de bloc peut être ajouté à tout moment pendant la construction / l'écriture du contenu. Ce serait un flux similaire aux blocs Atomic, mais j'espère sans un bloc qui contient tous les autres blocs comme ils le font.

Ouais, je l'aime plus comme ça aussi, pour les mêmes raisons que vous avez indiquées.

Il pourrait également y avoir quelque chose d'intéressant à apprendre de ce plugin. https://wordpress.org/plugins/full-site-editing/ @obenland Le plugin est-il actuellement à jour?

Il manque le travail d'aperçu de bloc que nous avons ajouté au cours des dernières semaines, mais il est fonctionnel autrement.

Voici à quoi ressemble l'itération actuelle, en utilisant blockPreview pour le grand aperçu du modèle de droite:

@epiqueras a écrit:

Nous avons un support pour cela, mais uniquement par type de publication et le modèle est appliqué au chargement, avec la logique suivante:

 * Synchronizing a block list with a block template means that we loop over the blocks
 * keep the block as is if it matches the block at the same position in the template
 * (If it has the same name) and if doesn't match, we create a new block based on the template.
 * Extra blocks not present in the template are removed.

Je ne vois pas beaucoup de valeur à cela et j'aimerais bien avoir quelque chose comme ce que vous venez de décrire.

Juste avant que quiconque n'ait des idées sur cette fonctionnalité remplaçant les modèles de bloc, je tiens simplement à noter que cette fonctionnalité est extrêmement précieuse. Il permet aux développeurs de définir spécifiquement la composition d'un type de publication donné. Nous utilisons largement cette fonctionnalité chez @meredithcorp où bon nombre de nos types de contenu sont strictement organisés.

Je pense que cette fonctionnalité "Block Patterns" est une idée géniale, mais je veux être sûr qu'elle est considérée comme un "en plus", et non comme un remplacement complet de la fonctionnalité actuelle de modèle de bloc de type de publication.

Prochaines étapes:

1. @melchoyce pour communiquer également ses explorations.
2. Diverge: explorez ce que fait wpcom avec d'autres exemples dans l'industrie (par exemple Squarespace, etc.)
3. Converger: rassemblez les modèles les plus forts en une seule maquette cohérente et un flux UX.
4. Maquettes et prototype à Figma.

L'année dernière, j'ai exploré quelques prototypes de mises en page de Gutenberg. Mes explorations comportaient quelques morceaux:

• Étendez les mises en page pour travailler sur les pages, pas seulement sur les CPT.
• Créez un moyen pour les auteurs de thèmes de «déclarer» plusieurs modèles.
• Créez un moyen pour les auteurs de thèmes de catégoriser ces modèles.
• Créez l'interface utilisateur pour sélectionner une mise en page.

Bureau

Voir le prototype

_Remarque: ce prototype était d'un cycle précédent que j'ai essayé, et certains des éléments sont obsolètes ._

Mobile

Voir le prototype

La panne

Le sélecteur de mise en page, comme tout le reste de Gutenberg, est un bloc. Il se compose de quelques éléments:

• Titre / description du bloc.
• Onglets pour classer les types de mise en page (stylisés après l'inséreuse de blocs).
  
  
  
  • Ceux-ci sont définis par thème.
  
  
  • Lorsque vous n'avez que quelques mises en page (disons <5), les onglets n'apparaissent pas.
  
  
  • S'il n'y a pas de mises en page catégorisées, les onglets n'apparaissent pas.
  
  
• Une liste des mises en page disponibles.
  
  
  
  • Les graphiques de mise en page doivent être générés automatiquement en fonction des blocs qu'ils contiennent.
  
  
  • Les images sont des cases grises, le texte est des lignes grises plus foncées, les boutons sont bleus, etc. Nous devrions tout résumer en formes simples.
  
  
• Enfin, la mise en page elle-même.
  
  
  
  • Dans ces maquettes, vous pouvez voir les styles de thème appliqués à Gutenberg. Si les styles de thème ne sont pas déclarés, les blocs reviendraient aux styles génériques de Gutenberg.
  
  
  • Vous pouvez également remarquer les éléments globaux sur la page - dans ce cas, le logo du site, la navigation et le pied de page. Ceux-ci existent pour la présentation, mais ne sont pas modifiables dans cette première version de mises en page. Ils ne peuvent pas être modifiés et affichés à une opacité de 40%.
  
  

Changement de disposition

J'ai travaillé sur ce à quoi le flux pourrait ressembler:

Voir le prototype

La panne

Alors attendez, je peux avoir plus d'une mise en page?
Ouaip! Vous pouvez les empiler et les combiner comme vous le souhaitez.

N'est-ce pas ridicule?
Ouais, ça pourrait. Mais probablement pas dans la plupart des cas. Être explicite au sujet de l'écrasement ou de l'ajout signifie que les gens sont moins susceptibles de perdre du contenu. La suppression de blocs est facile, donc s'ils s'ajoutent et veulent se débarrasser des blocs plus anciens, il suffit d'un clic ou deux.

Et s'ils ne voulaient pas écraser leur contenu?
S'il vous plaît, soutenons "annuler".

Qu'en est-il des éléments spécifiques à la page tels que les images de fonctionnalités et les titres de page?
Si vous ajoutez des mises en page, nous devons convertir tous les éléments spécifiques à la page en leur équivalent générique le plus proche. Par exemple:

• Image en vedette → Image
• Titre de la page → En-tête

Qu'en est-il des blocs en double?
Si un bloc spécifique (comme les derniers messages) est dupliqué, nous devrions l'autoriser - les gens peuvent vouloir afficher un autre bloc de messages d'une catégorie différente.

Les blocs génériques peuvent être dupliqués à votre guise.

Comment appelle-t-on une mise en page une fois que vous y avez ajouté une autre mise en page?
Nous devrions l'appeler «mise en page personnalisée» et rendre à nouveau l'image d'aperçu en fonction de ce qui a changé.

Il y a beaucoup de choses obsolètes dans ces simulacres depuis qu'ils ont plus d'un an, mais nous pourrons peut-être réutiliser certains concepts.

Excellente discussion ici, merci de l'avoir démarrée. Je suis convaincu que cela peut aider à simplifier encore plus la mise en page des pages, et j'ai hâte qu'elle arrive.

Je pense également fortement que nous ne devrions pas ajouter un bouton supplémentaire à côté de la bibliothèque de blocs, car:

• il dilue et fragmente la bibliothèque de blocs comme endroit singulier pour insérer quoi que ce soit sur la page
• il ajoute une interface utilisateur supplémentaire pour l'insertion et l'apprentissage, pour rendre accessible et travailler sur mobile et bureau
• il est ajouté dans un endroit déjà bondé et devrait sans doute être réduit plutôt que ajouté à
• il sépare le "modèle" du "bloc", créant effectivement un type de contenu différent, alors qu'il pourrait sans doute être le même

_Une fois que vous apprenez l'interface utilisateur de bloc, vous apprenez à tout faire_, était un principe directeur dès le début, et bien qu'il doive encore être affiné, il a relativement bien évolué. Hier encore, nous avons discuté de la manière dont le traitement du site lui-même comme un bloc (# 16998) pourrait être bénéfique car il réutilise l'interface utilisateur existante. Si au lieu de traiter un "modèle de bloc" comme une nouvelle fonctionnalité, mais plutôt de le traiter comme _juste un autre bloc qui se trouve être préconçu et qui contient des blocs enfants_, du coup ce n'est pas une nouvelle fonctionnalité, c'est un _refinement d'une fonctionnalité existante_, ce qui semble à la fois pragmatique et raisonnable, du point de vue de la portée.

Pour moi, la bibliothèque de blocs semble l'emplacement évident pour cette interface. Quels changements pouvons-nous y apporter pour mieux s'adapter aux modèles de blocs? Il contient déjà des blocs réutilisables, sans doute des précurseurs de modèles comme ceux-ci, et toutes les améliorations que nous apporterons profiteront probablement à ces derniers. Existe-t-il un onglet Modèles de bloc? La bibliothèque de blocs est-elle plus large - aussi large que la bibliothèque de blocs et le nouveau volet de prévisualisation ensemble? Les modèles de bloc ont-ils besoin d'une fenêtre d'aperçu séparée ou pouvons-nous tirer parti de l'espace supplémentaire de ce volet d'aperçu?

Un autre exercice consiste à retourner la question sur sa tête: qu'est-ce que la bibliothèque de blocs telle qu'elle existe aujourd'hui suggère que nous avons besoin d'une nouvelle interface utilisateur pour les modèles de blocs?

Une autre interface, et Mel aborde très élégamment cela, consiste à accéder à l'interface d'espace réservé. Que faire si le bloc Site, par défaut, vous permet de choisir le modèle de base?

Ce qui suit n'est pas une idée exceptionnellement réfléchie, comme cela est évident, mais juste un rapide croquis montrant à quoi cela ressemblerait si nous ajoutions un menu déroulant "sélecteur de type" à la bibliothèque de blocs, vous permettant de rechercher à la fois des blocs et des motifs de blocs ensemble :

Pour moi, la bibliothèque de blocs semble l'emplacement évident pour cette interface. Quels changements pouvons-nous y apporter pour mieux s'adapter aux modèles de blocs?

Merci d'avoir plongé, @jasmussen! Comprendre cette question est essentiel. Récemment, Happiness Engineers a déclaré que certains utilisateurs ne faisaient même pas défiler la bibliothèque de blocs pour trouver d'autres blocs en dehors de ce qui est au centre. C'est un autre problème, mais quelque chose à considérer par rapport à l'ajout de quoi que ce soit d'autre à cette toute petite interface.

qu'en est-il de la bibliothèque de blocs telle qu'elle existe aujourd'hui qui suggère que nous avons besoin d'une nouvelle interface utilisateur pour les modèles de blocs?

Je dirais que c'est la taille même de la bibliothèque de blocs qui rend difficile l'ajout de modèles de bloc de page complète. À l'heure actuelle, l'utilisateur affiche une icône de bloc et un petit aperçu du bloc. Cela fonctionne parce que c'est une petite zone de la page qui est focalisée. Les modèles de blocs fonctionnent beaucoup mieux lorsque l'utilisateur peut voir la plus grande partie de la page et comment ces blocs existent ensemble. La taille de la bibliothèque rend cela difficile.

Le concept de "Bloc de site" semble plutôt intéressant. De nombreux blocs ont un espace réservé, de sorte qu'un bloc de site peut également avoir un espace réservé avec des options de mise en page. Cette idée fonctionne bien pour les nouvelles pages, mais pas tant pour les pages qui ont un contenu existant. Mais voici une maquette rapide autour de cela de toute façon.

Bloquer l'espace réservé (pour référence):

Espace réservé de bloc de site:

Cela correspond vraiment aux maquettes de @melchoyce ci-dessus.

Bonnes pensées, merci.

Récemment, Happiness Engineers a déclaré que certains utilisateurs ne faisaient même pas défiler la bibliothèque de blocs pour trouver d'autres blocs en dehors de ce qui est au centre.

C'est une bonne idée, et une raison de plus pour améliorer la bibliothèque de blocs avec toutes les conceptions améliorées que nous faisons pour les modèles de blocs.

Je dirais que c'est la taille même de la bibliothèque de blocs qui rend difficile l'ajout de modèles de bloc de page complète là-bas

Cela sonne vrai. J'ai pris un peu de temps pour essayer de me moquer un peu de ces commentaires, mais en combinant cela avec l'idée d'une bibliothèque de blocs singuliers. Ne mettez pas trop de poids dans la haute fidélité de cette maquette, en partie c'est ma zone de confort, en partie c'est une façon de la rendre "réelle". Donc, ce n'est pas parce que cela semble fini, qu'il ne peut pas être rejeté sur la base de commentaires supplémentaires:

Ce que vous voyez ici est la même bibliothèque de blocs singuliers que vous appuyez sur le bouton (+) Add Block . Cela le rend disponible dans la barre de l'éditeur, à la fin du document, à chaque fois que vous créez un nouveau paragraphe ou si vous recherchez l'inséreuse frère.

L'interface utilisateur s'appuie sur ce que nous avons, mais ajoute deux onglets en plus du champ de recherche:

• L'onglet Blocs est par défaut et le contenu est ce que nous avons aujourd'hui
• L'onglet Modèles de bloc se trouve à côté de lui, et au lieu d'avoir un volet d'aperçu séparé, celui-ci affiche les aperçus rendus sous forme de vignettes de modèle de bloc lui-même.
  
  
  
  • Il existe une _category dropdown_, qui est un bon moyen pour les plugins de catégoriser leurs offres.
  
  
  • Les miniatures ont des largeurs fixes (2 colonnes), mais des hauteurs variables, de style maçonnerie.
  
  
  • Toute la fenêtre contextuelle a été agrandie et en ne montrant pas de volet de prévisualisation, nous obtenons encore plus de biens immobiliers. Nous pouvons même explorer des astuces réactives pour dimensionner la liste déroulante en fonction de la surface d'écran disponible.
  
  
• Lorsque vous recherchez, vous recherchez à la fois les blocs et les modèles de blocs.
  
  
  
  • Les résultats des blocs sont regroupés séparément et apparaissent en premier
  
  
  • Les résultats du modèle de bloc apparaissent en dessous de cela
  
  

Encore une fois, même si cela semble très fidèle, cela ne doit pas être considéré comme un évangile. Il vise simplement à faire avancer la conversation. J'ai été inspiré par certains des travaux de @shaunandrews pour l'édition complète du site, et je suis sûr qu'il aura également des idées à partager.

J'espère que cela t'aides! Pensées?

D'accord, donc sur la base des explorations ci-dessus, je nous vois décomposer cela en deux tâches:

1. Aperçu et choix d'une mise en page lors de la création d'une nouvelle page
2. Ajout de nouveaux modèles de blocs par la suite, via l'inséreuse

@jasmussen a d'excellentes explorations d'inséreuse dans https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480 sur lesquelles nous pouvons itérer pour l'inséreuse.

@shaunandrews a également partagé avec moi cette idée sur laquelle il travaille pour WordPress.com:

Lorsque vous créez une nouvelle page, une option vous permet de sélectionner une mise en page. L'aperçu est un ajout intéressant que ni @mapk ni moi n'avons encore exploré.

Une question à laquelle nous devrions réfléchir: les mises en page complètes devraient-elles se produire pour les pages, pas pour les articles?

les mises en page complètes devraient-elles se produire uniquement pour les pages, pas pour les articles?

Un aspect est ce que nous utilisons par défaut, un autre est la distinction technique. Ie c'est très probablement techniquement trivial puisque c'est la même chose sous le capot, donc simplement une question de décider ce que nous autorisons. L'avantage de l'autoriser partout est que c'est un flux prévisible qui est le même partout. L'inconvénient est que nous ne voulons probablement pas que vous créiez un nouvel article utilisant le modèle de page d'accueil du blog.

Peut-être que le modèle, lorsqu'il est enregistré, décide lui-même sur quelles taxonomies il doit être autorisé?

Peut-être que le modèle, lorsqu'il est enregistré, décide lui-même sur quelles taxonomies il doit être autorisé?

Bonne idée - des modèles pourraient également être utilisés pour les catégories / tags et les CPT.

(Un sélecteur de modèles sur les pages de taxonomie pourrait être cool!)

Tangentiellement lié aux modèles de bloc - sections de contenu - un ami a partagé quelques réflexions sur l'introducteur frère, le plus qui apparaît au survol entre les blocs, notant qu'il serait plus utilisable s'il était toujours visible lorsque le bloc était sélectionné. La raison pour laquelle ce n'est pas le cas actuellement est que cela entre en conflit avec le simple fait de vouloir cliquer sur le texte à modifier et avec les contrôles de redimensionnement présents sur les blocs d'espacement et de couverture. La clé ici étant que tout est un bloc.

Quelques captures d'écran du constructeur de site GoDaddy ont été partagées, où une interface similaire existe et est visible en permanence lors de la sélection. La principale différence étant que cette interface utilisateur différencie les petits blocs (texte, images) et les sections plus grandes, et ne montre ce contrôle que sur ces dernières:

Alors que nous continuons sur les modèles de blocs, il serait intéressant de se demander si ce concept ouvre la porte à une simplification supplémentaire de l'interface utilisateur de base en ajoutant des fonctionnalités aux sections plus grandes.

@jasmussen Puis-je récupérer votre fichier pour https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480?

Oui bien sûr. Je l'ai rapidement assemblé dans une sorte de fichier Figma en désordre, alors je l'ai copié ici:

https://www.figma.com/file/VaSKQJDS70ov87XY1alOVs/Block-Library-w.-Block-Patterns?node-id=0%3A1

Merci!

J'ai joué avec quelques idées:

J'ai commencé avec l'idée d'une liste déroulante et j'ai essayé une seule liste de blocs:

Parallèlement à cela, j'ai essayé à la fois deux colonnes et une seule colonne pour les modèles, en utilisant des vignettes pour les modèles de la liste:

J'ai alors décidé que la recherche était dans un endroit déroutant et j'ai pris du recul. J'ai essayé d'ajouter une liste déroulante à côté de la recherche et des onglets sous la recherche:

Avec les onglets sous la recherche, j'ai également essayé d'afficher des miniatures de motifs à la fois en orientation paysage et portrait.

J'aime ce que @joen a fait avec la mise en page plus intéressante des motifs, alors j'ai également essayé une maquette rapide avec cela:

De grandes explorations. Je pense que les onglets fonctionnent un peu mieux en tant que modèle, car la liste déroulante à côté de la recherche donne l'impression que les deux sont liés ensemble - comme, je ne peux rechercher que dans des modèles ou des modèles, et non pas changer ma vue en en sélectionnant un.

J'ai vraiment apprécié la lecture de ce numéro, les idées sont lues et ont fière allure!

Je voudrais signaler les problèmes connexes # 15623 et # 17512 qui se concentrent sur la fourniture des types de blocs et de l'infrastructure nécessaires respectivement pour permettre l'édition complète du site.

Bien que les modèles de bloc tels que discutés ici aient du sens dans les deux contextes (article individuel vs modèle entier), je pense que nous devons différencier deux types de modèles:

• Parties du modèle (par exemple, à implémenter avec un type de publication wp_template_part interne, similaire à la façon dont le plugin Full Site Editing le fait):
  
  
  
  • Les parties du modèle doivent pouvoir être utilisées à divers endroits et il doit être possible de les ajouter à d'autres contenus (comme indiqué ci-dessus).
  
  
• Modèles (par exemple à implémenter avec un type de publication wp_template interne, voir # 17513):
  
  
  
  • Les modèles sont censés représenter les modèles _entiers_, y compris tout le balisage sémantique qui compose un document HTML. Il doit y avoir des restrictions sur la façon dont ils peuvent être placés, par exemple, les modèles complets n'ont pas de sens dans le contenu de l'article individuel, et il ne devrait pas non plus être possible d'ajouter un modèle complet ailleurs - un modèle complet devrait toujours remplacer le contenu existant, et leur cas d'utilisation principal serait au tout début de la création d'un nouveau modèle avec Gutenberg (c'est-à-dire "Sélectionnez votre point de départ").
  
  
  • Bien que nous ayons encore besoin de trouver comment encourager généralement (appliquer?) Un balisage sémantique solide (via les problèmes susmentionnés), je pense que nous devrions également envisager ce scénario ici.
  
  

Jusqu'à présent, ce problème semble principalement axé sur les éléments du modèle, et cela a du sens, mais ce serait formidable si nous pouvions également réfléchir à la façon d'étendre cela à des modèles complets à l'avenir.

Jusqu'à présent, ce problème semble principalement axé sur les éléments du modèle, et cela a du sens, mais ce serait formidable si nous pouvions également réfléchir à la façon d'étendre cela à des modèles complets à l'avenir.

Une clarification - la configuration des «modèles de blocs» concerne moins les pièces de gabarit (qui sont structurellement significatives) que les éléments de conception généraux constitués de blocs plus petits. Une fois insérés, ils ne sont pas stockés séparément. Par exemple, une image "Couverture" qui combine quelques blocs pour obtenir un aspect spécifique qui, autrement, nécessiterait du travail pour les utilisateurs. Pensez-y davantage comme une collection de designs qui peuvent être ajoutés n'importe où sans nécessairement représenter une partie réutilisable d'un modèle de thème.

Une exploration rapide et sale, prenant les idées de @jasmussen et les appliquant à un modal au lieu d'un popover:

Je creuse les onglets et la mise en page de recherche, même si je dois admettre que j'utilise personnellement _toujours_ la recherche dans la bibliothèque de blocs, donc en tant que point de données d'un, je préférerais rechercher d'abord.

L'inséreuse de boîte de dialogue modale apporte définitivement de l'espace. C'est bon. Mais cela perd également un peu du contexte visuel de l'endroit où se trouve votre curseur / où le bloc ou le motif de bloc sera inséré. De plus, cela pose la question de savoir si cela devient le comportement global de l'inséreuse de blocs, ou par exemple simplement ce que vous voyez lorsque vous utilisez l'inséreuse frère ou une variante comme "l'inséreuse de sections" suggérée ci-dessus. Et si nous fragmentons le comportement, est-ce bien?

Votre exploration là-bas, @melchoyce , aide vraiment! Merci! J'ai quelques réflexions à ce sujet.

Dans un cas, le modal communique les nombreux blocs disponibles, ce que les gens ont du mal à explorer en ce moment. Mais d'un autre côté, voir tous ces blocs comme celui-ci devient un peu accablant. Un modal convient aux motifs, mais pas aux blocs individuels. Mais la maquette montre également les accordéons ouverts, donc cela peut changer complètement si seulement un est ouvert comme nous le faisons par défaut.

Même si j'aime l'espace supplémentaire de la version de dialogue, y dormir, cela ne me semble pas être la bonne approche. Cela supprime tout le contexte du contenu et semble écrasant lorsque vous insérez des blocs simples comme des paragraphes ou des images. Je ressens de plus en plus la même chose à propos des blocs prédéfinis ou des modèles de blocs - ce ne sont que des collections de blocs et devraient être insérés de la même manière.

Bien que https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480 ne soit pas nécessairement la voie à suivre - les catégories commencent à sembler inutiles et il se passe beaucoup de choses - je pense que _améliorer le blocage bibliothèque pour accueillir des blocs complexes_ (et éviter un dialogue modal) est la voie à suivre.

Je pense que l'amélioration de la bibliothèque de blocs pour accueillir des blocs complexes (et éviter un dialogue modal) est la voie à suivre.

Maintenant que nous avons le panneau d'aide qui fournit plus d'espace dans la bibliothèque, nous pouvons probablement travailler un peu avec cela. Peut-être que les motifs sont un autre onglet à séparer des blocs individuels, mais la zone d'aperçu reste toujours dans le côté du panneau d'aide qui peut être défilée verticalement si nécessaire.

J'aime l'idée de "Block Patterns" (peut-être qu'il devrait être changé en "Block Layouts?") Mais je n'aime pas ajouter un nouveau bloc en utilisant une boîte de dialogue - c'est trop distrayant! (Si des motifs de bloc devaient être ajoutés de cette façon, je serais d'accord.)

Je suggérerais que le Block Inserter devrait rester un petit popover (comme il se trouve aujourd'hui) tandis que les modèles de bloc devraient être un composant complètement différent - car le contexte dans lequel chacun est utilisé pourrait très bien être différent: un pour la construction de pages (modèles) - l'autre pour ajouter des blocs / peaufiner ces pages.

Cela pourrait fonctionner dans l'inséreuse, mais nous pouvons constater que l'interface devient plus compliquée et déroutante - et sans parler, l'inséreuse est assez petite. Apporter de minuscules aperçus de modèles n'est peut-être pas la meilleure expérience. Nous devons être en mesure d'afficher plus d'un modèle (pour fournir un contexte approprié au choix de l'utilisateur), mais aussi de rendre les aperçus suffisamment grands pour être visibles.

Peut-être que nous modifions un peu notre façon de faire les choses.

Il suffit de penser à voix haute ici, mais que se passerait-il si nous avions l'Inserter en haut à gauche, tel qu'il se présente aujourd'hui, et introduisions un nouveau modèle UX entre les blocs existants - où les gens peuvent ajouter des modèles / mises en page de blocs (selon ce que nous les appelons). Cela remplacerait l'introducteur de bloc en survol (+) qui réside actuellement entre les blocs et resterait visible (ne pas se cacher lorsqu'il n'est pas survolé).

Voici une capture d'écran (_ avec le contenu réel de Gutenberg_) sur ce à quoi cela pourrait ressembler:

Il faudrait réfléchir à l'endroit où cela prendrait le relais. Serait-ce entre chaque bloc? Je ne suis pas sûr.

L'ouverture de l'inséreuse de modèle déclencherait un modal à partir duquel l'utilisateur peut sélectionner un nouveau modèle à ajouter à sa page. Voici une exploration du modal, en utilisant une sélection catégorielle de haut niveau, bien que je ne sois pas à 100% ici sur ce à quoi cela ressemblerait.

Ce modèle (ou au moins une partie de celui-ci) est visible sur l'offre Site Web + Marketing de GoDaddy, ainsi que sur SquareSpace (et peut-être ailleurs). Ça vaut le détour.

Un bloc et une mise en page doivent être DIFFÉRENTS.

Une mise en page doit tirer parti du framework CSS qu'elle utilise.

Exemples de mise en page:

• Colonne / ligne
• la grille
• Un curseur
• Un contenant
• Tabs, accordéons

Un bloc peut vivre à l'intérieur d'un layout ou non.

Un motif peut être une mise en page + des blocs?

Voici comment fonctionne l'application Blocs. Il utilise un inserteur beaucoup plus grand. Je partage simplement plus de recherches.

Plus en regardant ce que les autres font là-bas.

Qubely utilise un bouton dans la barre d'outils supérieure pour ouvrir un modal.

Excellentes actions, Mark.

Je voudrais noter que l'approche Qubely est celle que je pense que nous devrions éviter, et c'est une approche adoptée par un certain nombre d'autres collections de blocs. L'approche suppose que l'utilisateur est sur un écran de bureau et n'utilise pas l'option "Barre d'outils supérieure", ni même la future option "Afficher les étiquettes pour toutes les icônes". Donc, si nous devions ajouter un bouton séparé, nous voudrions probablement l'ajouter dans le contexte direct de l'inséreuse de blocs, et nous devrions probablement regarder comment nous pourrions réduire les autres boutons présents dans cet espace.

Et voici un aperçu de la façon dont SquareSpace a une interaction distincte pour l'architecture de page et l'édition de contenu , fournissant un contexte à mon commentaire précédent .

Et voici une conversation continue (Slack) dont nous avons discuté lors de la réunion de conception d'hier:

J'ai beaucoup réfléchi à une interaction de modèle par rapport à une interaction de bloc. Déplacer des motifs comme interaction de "construction" de niveau supérieur, tout en conservant les blocs comme interaction "ajout / ajustement". Bien sûr, on pourrait construire des "modèles" avec des blocs évidemment, mais ce n'est pas exactement simple et nécessite beaucoup plus d'interactions à accomplir. Et s'il y avait une différence distincte entre l'architecture de page et l'architecture de contenu?

Merci d'avoir partagé ça, Rich. Il semble que l'équilibre à trouver soit entre le fait qu'il soit trivial pour les utilisateurs d'insérer de grandes sections de contenu utiles pour créer rapidement des pages quand ils le souhaitent, mais un accès trivialement intuitif aux blocs individuels lorsque c'est ce dont ils ont besoin.

Pour moi, la clé à retenir du GIF Squarespace est que, bien que la dualité entre deux bibliothèques existe, elle est tempérée par _contextuality_. Je me demande si nous pouvons faire encore mieux, cependant, afin d'éviter deux bibliothèques de blocs complètement différentes. Par exemple, lorsque vous insérez un bloc _Navigation Menu_, il semble intuitif que la bibliothèque de blocs devienne un outil pour insérer uniquement des _éléments de menu_ à l'intérieur. Existe-t-il une manière similaire d'exploiter le contexte dans le canevas d'édition lui-même?

Quant à la façon d'ajouter une mise en page, peut-être dans la zone Paramètres de l'onglet Documents, il pourrait y avoir une liste de mises en page avec un graphique montrant à l'utilisateur à quoi ressemble la mise en page?

Nous avons une section et un mode de mise en page dans Atomic Blocks depuis un moment maintenant et je suis heureux de partager ce que nous en avons vécu jusqu'à présent.

Pour élaborer sur les questions de @mapk :

1. Oui, l'éditeur de blocs doit avoir une interface utilisateur dédiée pour travailler avec des modèles de blocs / sections / mises en page ou tout ce que vous voulez les appeler. La prochaine étape logique après les blocs individuels est de savoir comment nous les combinons pour créer des mises en page modernes et expressives. Créer une interface utilisateur standardisée pour cela permettra aux utilisateurs et aux développeurs de profiter d'une expérience cohérente et d'éviter de réinventer la roue un million de fois (ce qui a déjà commencé). Même si Atomic Blocks et plusieurs autres ont déjà une interface utilisateur dédiée, je préférerais toujours adopter une interface utilisateur standard (mais extensible) pour cela.

Que le noyau fournisse ou non des modèles de bloc pour remplir cette interface utilisateur est une autre question. Il est peut-être logique que les thèmes de base fournissent des modèles de blocs opiniâtres pour compléter et étendre leurs conceptions.

1. Plusieurs des interfaces utilisateur proposées ici sont un bon début. J'aime particulièrement ce que je vois de @shaunandrews et @melchoyce ici . Je partage l' opinion de inséreuse de blocs est trop limitative pour une fonctionnalité comme celle-ci, et je pense que nous allons vite la dépasser. La création de pages expressives avec des motifs de blocs mérite plus qu'une interface de 700 px x 430 px.

Nous avons distingué une différence entre les sections et les mises en page dans notre interface utilisateur, les sections faisant partie d'une page et les mises en page étant une mise en page complète. Il s'agit d'une décision avisée et logique dans notre implémentation actuelle, mais cela pourrait également être résolu avec une interface de catégorie ou de filtrage à la place.

Atomic Blocks dispose également d'une fonction de favoris pour permettre aux utilisateurs de créer facilement des favoris et de revoir leurs sections et mises en page fréquemment utilisées. Ce type de fonctionnalité sera nécessaire car la quantité de motifs augmentera rapidement. Une autre façon de responsabiliser l'utilisateur serait d'autoriser les modèles de liste blanche et de liste noire à contrôler la sortie dans l'interface utilisateur des modèles.

La puissance de l'éditeur de blocs sera plus apparente et validée dans des fonctionnalités telles que les modèles de blocs et les modèles de blocs, qui changent fondamentalement la façon dont nous construisons des sites Web dans WordPress. Nous avons également la possibilité de découvrir le Far West des interfaces WordPress personnalisées et de commencer à offrir une expérience plus cohérente et prévisible avec la normalisation.

J'ai quelques maquettes à partager aujourd'hui qui tentent de répondre à une idée passée . Pour élaborer sur le défi: un utilisateur peut ne pas se soucier de la différence entre un bloc, un motif ou une mise en page, et comme l'un ou l'autre peut être inséré à n'importe quel endroit, la création d'interfaces différentes pour chacun est susceptible de prêter à confusion.

Dans la maquette suivante, j'ai essayé de résoudre ce problème en:

• Création d'une interface de bibliothèque unifiée unique, par onglets
• Afficher cette interface sous forme de popover, pleine hauteur mais non modale, lorsqu'elle est ouverte à partir de la barre d'édition
• Affichez-le sous forme de boîte de dialogue, par défaut dans l'onglet Modèles, lorsqu'il est ouvert à partir de l'inséreuse frère

_Notez que cette interface utilisateur exploite les concepts d'interface utilisateur inachevés explorés dans # 18667._

Dans cette configuration, les utilisateurs peuvent insérer un bloc ou un modèle sans avoir à regarder à travers différentes interfaces, mais nous reconnaissons que vous voudrez peut-être plus d'espace d'écran lors de l'insertion de modèles plus grands.

Cette interface exploite également les nouveaux formulations de catégories suggérées ici .

• Affichez-le sous forme de boîte de dialogue, par défaut dans l'onglet Modèles, lorsqu'il est ouvert à partir de l'inséreuse frère

Je pense que nous sommes sur quelque chose ici!

@jasmussen , est-ce que les motifs apparaissent également dans / , ou juste des blocs?

C'est une excellente question. Peut-être si catégorisé séparément. Mais peut-être que le grand aperçu est plus nécessaire pour les motifs? "2 modèles trouvés" pourrait invoquer le dialogue?

@jasmussen , est-ce que les motifs apparaissent également dans / , ou juste des blocs?

Peut-être. Bien que sans aperçus, je ne suis pas sûr de l'utilité de les avoir dans / - à moins qu'ils ne portent un nom très unique (ce qui, je doute, sera le cas, c'est-à-dire "Environ 1", "Environ 2") ou si les utilisateurs pouvaient les nommer comme ils l'entendent (pas sûr à 100% à ce sujet également).

Si nous implémentons une fonctionnalité "favoris", comme @mikemcalister le mentionne plus tôt dans ce fil, peut-être que seuls les modèles favoris s'afficheront (à condition qu'ils soient clairement identifiables). Et si nous les autorisons, les motifs auraient-ils besoin d'une icône correspondante (similaire aux blocs)? Ou y aurait-il une icône "motif" par défaut pour classer les motifs de bloc?

Salut à tous, je voulais juste faire apparaître ma tête et dire que j'adore où cela va. Les dernières maquettes et pistes de réflexion sont merveilleuses. Alors que je réfléchis à la façon dont cela se traduirait par Gutenberg mobile natif, je pense que la dernière maquette de @lumberman est bien organisée et devrait être assez évolutive, mais j'ai une préoccupation concernant la hiérarchie et l'interaction. Pardonnez-moi si je n'ai pas le contexte historique complet, mais je pense que la perspective mobile serait utile dans ce contexte.

Sur les accordéons / la hiérarchie de navigation

Un problème que j'ai toujours eu avec l'inséreuse concerne les sections d'accordéon (blocs les plus utilisés, les plus courants, etc.). La première section "Most Used" est assez claire car elle est toujours ouverte au départ, mais elle a tendance à enterrer les sections supplémentaires et à gêner la recherche, en particulier sur mobile.

Je suis fan de la disposition de la barre latérale gauche dans votre dernière maquette, @lumberman. Pensez-vous qu'il serait judicieux d'ajouter les sections en tant qu'éléments de liste dans la hiérarchie de navigation de la barre latérale gauche? En d'autres termes, les éléments sous Sections seraient "Les plus utilisés", "En-têtes", "Pieds de page", etc. (ou quelle que soit la dénomination du groupe)? Cela pourrait résoudre le problème des «sections enterrées» et nous permettre potentiellement de supprimer essentiellement le besoin des accordéons, mais je comprends que c'est une grande divergence par rapport à la bibliothèque de blocs historiquement, donc d'autres pourraient ne pas aimer cette suggestion 😄

Sur "Favoris"

Un des concepts discutés (par @mikemcalister au départ je crois) est celui de "favoris". C'est presque exactement comme une idée que j'ai explorée il y a quelque temps sur la GB mobile native , où vous choisiriez des blocs préférés pour créer "Ma bibliothèque" de blocs pendant le processus d'intégration en GB et à partir de là, la bibliothèque de blocs se concentrerait sur ceux-ci principalement tout en fournissant un chemin évident vers la bibliothèque de blocs complète. Le principal problème avec cela était la découvrabilité, même si je pense qu'il existe des moyens de résoudre ce problème.

Sur la bibliothèque de blocs, Overwhelm, IA, etc.

Il y a une chose sur laquelle je reviens constamment concernant l'inséreuse en général, qui devient encore plus claire à mesure que nous la rendons plus robuste. Lors des tests d'utilisabilité du Web mobile, nous (l'équipe mobile d'Automattic) avons souvent entendu dire que la bibliothèque de blocs est écrasante. Il y a beaucoup de choix et les regroupements ne sont pas immédiatement clairs. Je pense que les nouvelles idées d'interface utilisateur proposées ici aident car elles «respirent» un peu plus, mais le nombre de blocs est toujours écrasant et ne fera qu'empirer avec l'introduction d'un autre groupement (Block Patterns). Je pense qu'à mesure que nous intensifions cela (ce qui, je pense, est la bonne direction, la capacité de type "favoris" pourrait atténuer cela.

Cela vaut la peine de jeter un coup d'œil à l'approche Mobirise des mises en page. Ils fournissent un canevas à gauche et un curseur de sélection de panneau vertical à droite segmenté en éléments de page verticaux naturels ... quelques choix de panneau pour la barre supérieure, puis le menu supérieur, puis les panneaux du corps par fonction métier (selon le thème et type de page (par exemple, panneau de carte, panneau de personnes s'il s'agit d'une page À propos de nous), puis pied de page, puis barre de pied de page. Il vous suffit de glisser-déposer les panneaux de la droite vers la gauche.

AVERTISSEMENT: Si vous êtes un contributeur à Gutenberg, lisez les conditions de Mobirise avant de décider de parcourir tout matériel Mobirise ... ils ont une clause désagréable dans leurs termes qui concerne leurs produits et leur site Web:

Vous déclarez et garantissez que vous ne pourrez pas: copier, modifier, créer des œuvres dérivées de, adapter, faire de l'ingénierie inverse, émuler, migrer vers un autre service, traduire, compiler, décompiler ou désassembler les services;

Mieux encore ... n'allez pas du tout sur leur site Web.

Au lieu de cela, vous pouvez envisager de simplement regarder les vidéos YouTube de Mobirise. Je ne suis pas au courant d'un terme dépassant la licence que YouTube exige des téléchargeurs de contenu, mais Caveat Emptor ... Je ne suis pas avocat.

Si vous pensez que regarder des vidéos YouTube ne présente aucun risque pour l'IP Gutenberg, la chaîne Youtube Mobirise se trouve à l' adresse https://www.youtube.com/channel/UCt_tncVAetpK5JeM8L-8jyw/featured. Vous pouvez voir la création d'une page spécifique à un thème par glisser-déposer des panneaux en action.

@jasmussen , vos maquettes ici sont superbes. Je serais ravi de les voir dans un prototype fonctionnel si possible qui pourrait être en mesure de répondre à certaines de mes questions ci-dessous.

Comme indiqué par @richtabor , il est logique de modifier les contextes lorsque quelqu'un ajoute un bloc à partir de la barre d'outils, par opposition à l'ajout d'un modèle à partir de l'inséreur frère. J'aime que l'espace supplémentaire soit donné dans un modal pour les motifs!

Prochaines étapes

1. Le terme "Premade Blocks" semble un peu maladroit. Pouvons-nous essayer des "Block Patterns" là-bas, ou est-ce que ce sentiment est tout aussi gênant?
2. À quoi cela ressemble-t-il lorsque je clique sur l'inséreuse dans la barre d'outils supérieure, puis que je clique sur l'onglet «Motif de bloc»? Le popover passe-t-il à un modal? Le popover change-t-il de taille mais reste-t-il un popover dans la même position? Conserve-t-il la même taille et la même position et affiche-t-il simplement des motifs maintenant?
3. À quoi ressemble l'interaction lorsque vous cliquez sur l'inséreuse frère dans l'éditeur, puis sur l'onglet "Blocs"? Le modal change-t-il de taille ou de position à partir d'ici ou reste-t-il un modal?
   
   
   
   1. Créez un prototype qui répond à ces questions. Je suis heureux de vous aider ici si vous pouvez me lier le fichier.
   
   

@lumberman merci pour vos maquettes aussi! J'aime vraiment la façon dont ils utilisent la conception existante de l'inséreuse et s'appuient dessus. 👍 Existe-t-il un moyen de réduire la quantité d'accordéons? Cela ressemble à beaucoup de choses qui peuvent s'ouvrir. À l'heure actuelle, des tests d'utilisabilité ont révélé que les gens ne cliquaient pas sur les accordéons que nous avons déjà.

Le terme "Premade Blocks" semble un peu maladroit. Pouvons-nous essayer des "Block Patterns" là-bas, ou est-ce que ce sentiment est tout aussi gênant?

Oui, essayons définitivement les modèles de blocs.

Personnellement, je pense que ce terme est plus gênant, mais je suis également conscient qu'il a été discuté dans les discussions de conception et ailleurs, et que le coût de son essai dans le plugin est très faible, donc aucune raison de ne pas le faire! Cela peut sembler parfait, ou il peut se révéler comme ayant besoin de modifications, et nous reviendrons sur.

À quoi cela ressemble-t-il lorsque je clique sur l'inséreuse dans la barre d'outils supérieure, puis que je clique sur l'onglet «Motif de bloc»? Le popover passe-t-il à un modal? Le popover change-t-il de taille mais reste-t-il un popover dans la même position? Conserve-t-il la même taille et la même position et affiche-t-il simplement des motifs maintenant?

Aucun changement ne se produirait. Ce serait juste la même chose que le gros modal, mais dans un espace plus petit / plus étroit. Peut-être n'y a-t-il de l'espace que pour une seule colonne de motifs de blocs.

Mais je pense toujours que cela en vaut la peine, avoir la même interface utilisateur et les deux blocs et modèles, disponibles dans les deux endroits.

À quoi ressemble l'interaction lorsque vous cliquez sur l'inséreuse frère dans l'éditeur, puis sur l'onglet "Blocs"? Le modal change-t-il de taille ou de position à partir d'ici ou reste-t-il un modal?

Une bonne question à laquelle un PR / prototype pourrait répondre. J'imagine zéro changement, qu'il y a juste plus d'espace pour regarder les blocs, ce que certains pourraient préférer!

Créez un prototype qui répond à ces questions. Je suis heureux de vous aider ici si vous pouvez me lier le fichier.

Voici le fichier Figma: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975 - c'est un peu compliqué mais vous pouvez me faire un ping si vous avez besoin d'aide.

Voici quelques explorations basées sur les excellentes idées que vous partagez. Je me suis volontairement contraint à travailler dans l'espace fourni par l'inséreuse de blocs actuelle. J'ai fait cela pour deux raisons:

1. Cela nous permettra de traduire plus facilement cette interface utilisateur sur de petits écrans.
2. Pour la taille d'écran moyenne, je pense que l'inséreuse actuelle occupe déjà suffisamment d'espace d'écran. Je crois donc qu'un modal plus grand et centré ne fournira pas beaucoup d'avantages.

** Ce qui précède est une capture d'écran prise à 1200 x 800.

Étant donné que j'ai les contraintes de taille de l'inséreuse de blocs, j'ai essayé d'explorer comment nous pourrions tirer le meilleur parti possible de l'espace disponible. Bien que le panneau d'aide fonctionne correctement pour les blocs, il nous gêne lorsque nous essayons d'afficher des miniatures plus grandes pour les modèles de bloc. J'ai donc essayé de le supprimer, sans me débarrasser de son contenu . Cela nous donne plus d'espace, non seulement pour les modèles de blocs, mais aussi pour les blocs. J'aime aussi beaucoup la façon dont les miniatures d'aperçu recherchent des modèles de bloc dans certaines des maquettes partagées ici, et comme nous faisons déjà des aperçus de bloc sur le panneau d'aide, je me suis demandé pourquoi ne pas essayer.

Cela ressemble à quelque chose comme ceci:

Lorsque vous faites la mise au point / survolez un bloc, le contenu de la «bande» des conseils en bas change en conséquence:

En gros, je ne fais que déplacer les choses:

Les aperçus de bloc ne prennent vraiment pas beaucoup plus d'espace que ce que font les boutons actuels, et nous pouvons maintenant en afficher plus de 3 par ligne.

J'ai également essayé d'afficher des miniatures plus petites mais je pense que les aperçus sont plus difficiles à lire:

Avec tout ce qui précède, l'onglet des modèles de bloc pourrait ressembler à ceci:

Nous pouvons avoir une interface utilisateur familière pour les blocs et les modèles de blocs qui tire le meilleur parti de l'espace disponible dans l'inséreuse.

Merci d'avoir travaillé sur ce Enrique!

Je me suis volontairement contraint à travailler dans l'espace fourni par l'inséreuse de blocs actuelle. J'ai fait cela pour deux raisons:

• Cela nous permettra de traduire plus facilement cette interface utilisateur sur de petits écrans.
• Pour la taille d'écran moyenne, je pense que l'inséreuse actuelle occupe déjà suffisamment d'espace d'écran. Je crois donc qu'un modal plus grand et centré ne fournira pas beaucoup d'avantages.

Je ne suis pas d'accord avec cela. Nous avons de bons moyens de traduire un modal en téléphones (plein écran), et nous pouvons afficher une colonne de modèles au lieu de deux et trois.

Je dis cela après avoir exploré des conceptions pas trop différentes des vôtres , donc je suis également en désaccord avec mon moi passé.

Ce que j'ai réalisé, c'est que si nous voulons montrer de vastes motifs de blocs succulents, nous avons besoin de tout l'espace que nous pouvons obtenir. Il s'agissait de relier les points soulignés par Mark et Rich , ce qui a abouti à ces maquettes ( fichier Figma ).

J'ai essayé une bibliothèque de blocs qui occupe tout l'espace vertical disponible, supprime le texte d'aide et détache la fenêtre d'aperçu dans # 19836. Il peut servir de prototype à l'idée globale.

Enrique J'adorerais travailler avec vous pour apporter une partie de votre finesse aux grandes maquettes verticales montrées plus tôt. Voici le fichier Figma: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975 - notamment cela fonctionne bien sur le point d'arrêt du bureau, mais les points d'arrêt mobiles ne sont pas encore étoffés . Je suis toujours prêt à discuter aussi, si cela peut être utile.

hé @jasmussen! 👋

Voici une maquette rapide combinant vos grandes maquettes verticales avec des aperçus de motifs de blocs:

Je l'aime. Les gros aperçus se sentent bien à cette taille. Un problème que j'ai est que je ne suis pas sûr que les catégories d'accordéon fonctionnent bien pour la navigation et la découvrabilité lorsque les aperçus sont aussi grands.

J'ai passé du temps à explorer l'idée d'avoir les catégories sur le côté à la place:

Je pense que cela facilite l'analyse des catégories disponibles, mais cela pousse les catégories des modèles de bloc vers le bas, et je ne suis pas sûr que je pense que c'est correct.

Laissez-moi savoir ce que vous pensez.

Voici une maquette rapide combinant vos grandes maquettes verticales avec des aperçus de motifs de blocs:

C'est génial! Notamment, voir des motifs dans l'interface verticale est très éclairant et fonctionne légèrement mieux que je ne l'avais supposé.

Les catégories sur le côté ne sont pas mauvaises non plus, bien que je me demande si elles sont mieux servies comme liste déroulante dans la version popover en haut à gauche, mais elles pourraient bien fonctionner dans la version de dialogue ouverte par l'inséreuse fratrie?

Merci pour ça! Je vais laisser les autres intervenir également.

Voici quelques explorations supplémentaires itérant sur les maquettes récentes:

1. Onglets pour les blocs et les modèles de blocs + liste des catégories

2. Onglets pour les blocs et les modèles de blocs + liste déroulante pour les catégories

Je pense que 1 se sent bien. J'aime la façon dont la liste des catégories est entièrement visible (mieux pour la découvrabilité), et je pense que cela devrait bien évoluer.

Bien que 2 semble plus ordonné, je crains que la liste des catégories soit cachée derrière un clic, ce qui affecte la découvrabilité.

@jasmussen @mapk @shaunandrews qu'en pensez-vous?

Je pense que 1 se sent bien. J'aime la façon dont la liste des catégories est entièrement visible (mieux pour la découvrabilité), et je pense que cela devrait bien évoluer.

Bien que 2 semble plus ordonné, je crains que la liste des catégories soit cachée derrière un clic, ce qui affecte la découvrabilité.

Vous cherchez bien @enriquesanchez! Le numéro 1 se sent bien aussi.

Quelques réflexions:

une. Nous devrons trouver un mécanisme pour ce qui se passe s'il y a une longue liste de catégories.

b. Comment les catégories doivent-elles être classées? Y a-t-il une priorité via le thème, puis le plugin? Alphabétique? Ou une combinaison?

c. Si le thème enregistre des modèles pour différentes catégories, les modèles apparaissent-ils dans la catégorie "À partir du thème", ainsi que la catégorie spécifiée pour chaque modèle?

Un écho aux commentaires et questions de Rich, magnifique résumé. Bon travail!

Une chose à considérer est que, selon la thèse actuelle, la bibliothèque apparaît comme une grande boîte de dialogue lorsqu'elle est ouverte à partir de l'inséreuse frère, et inversement est plus petite lorsqu'elle est ouverte en haut à gauche. Nous _pourrions_ utiliser par défaut les catégories sur le côté et les _couler dans une liste déroulante_ lorsque les défis réactifs le dictent.

b. Comment les catégories doivent-elles être classées? Y a-t-il une priorité via le thème, puis le plugin? Alphabétique? Ou une combinaison?

Probablement finira par être une combinaison de quelques "bénis" en haut, puis par ordre alphabétique. Jusqu'au point où les plugins nomment leurs catégories __Sweet Blocks ou 1. Sweet Blocks . Cela semble être l'une de ces choses sur lesquelles nous pouvons risquer de trop réfléchir, et comme il est facile de s'ajuster sur la route, nous pourrions aussi bien opter pour la solution la plus simple et modifier si nécessaire.

@richtabor @jasmussen merci pour les excellents commentaires.

une. Nous devrons trouver un mécanisme pour ce qui se passe s'il y a une longue liste de catégories.

D'accord. Je ne sais pas si quelque chose de similaire a été nécessaire pour la bibliothèque de blocs et si nous pouvons en tirer des leçons.

b. Comment les catégories doivent-elles être classées? Y a-t-il une priorité via le thème, puis le plugin? Alphabétique? Ou une combinaison?

Je fais écho à la suggestion de Joen. Un certain ordre initial doit être établi et regarder l'itération quand / si le système est cassé.

c. Si le thème enregistre des modèles pour différentes catégories, les modèles apparaissent-ils dans la catégorie "À partir du thème", ainsi que la catégorie spécifiée pour chaque modèle?

Ma première réaction est oui. Je m'attends à ce que certains modèles apparaissent sous différentes catégories. Je pense que ça va. L'idée d'avoir une catégorie "À partir du thème" n'est en aucun cas définitive, mais j'ai pensé que ce serait un moyen facile d'aider les gens à faire en sorte que leur site "ressemble à la démo".

Je vais continuer à répéter à ce sujet. Je vais travailler sur quelques prototypes pour avoir une meilleure idée de l'apparence et de la convivialité de la bibliothèque.

J'ai trouvé l'approche mobirise pratique sur le terrain. Ils ont deux colonnes de sélection de panneaux de blocs ... un regroupant les vignettes des panneaux de blocs sous les catégories de page courantes (en-tête, menus, contenu, pied de page, etc.) avec un index de catégorie adjacent afin que vous puissiez voir toutes les catégorie d'intérêt.

Ne pas pousser cela comme "LA" solution. J'ai juste pensé que vous pourriez le trouver utile comme exemple, puis traduire ce que vous faites / n'aimez pas à ce sujet dans le design que vous voulez.

Juste une suggestion :-)

Merci de tenter une autre chance, @enriquesanchez!

Je suis aussi en faveur du numéro 1. L'affichage de la liste évite à l'utilisateur d'avoir à parcourir une série de clics pour obtenir le résultat souhaité. Le faire s'effondrer comme Joen l'a suggéré pour les écrans réactifs semble très intéressant.

Je ne connais aucun mécanisme actuellement dans Gutenberg qui gère de longues listes, donc c'est quelque chose qui doit être réfléchi. Séparer les blocs des motifs grâce à l'utilisation d'onglets aide déjà. Bravo sur celui-là!

"Du thème" semble un peu étrange. Peut-être "Modèles de thème" ou simplement "Thème" ou même "Thème: [nom du thème]". Peut-être que ceux-ci devraient être priorisés en haut? Je suis d'accord pour les garder ensemble dans la catégorie «thème» ET les exposer également dans les catégories pertinentes. Peut-être que cela devient quelque chose comme une "collection"? https://github.com/WordPress/gutenberg/issues/19873

J'ai remarqué dans la maquette que même si l'onglet "Modèles" est mis en surbrillance, le champ de recherche indique que vous pouvez rechercher des blocs et des modèles. Est-ce correct? Ou devrais-je être limité à bloquer les motifs sous l'onglet Motif?

Voici un mélange du wireframe Obenland partagé:
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -536109796

et la suggestion filaire numéro 1 d'Enrique:
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -582673937

Voici la zone des blocs existants ainsi que des options supplémentaires:

Lorsque vous sélectionnez l'onglet Variations de bloc, il peut devenir quelque chose comme ceci:

Edit: Utiliser l'interface existante mais l'étendre pour des options supplémentaires garderait une cohérence dans la façon dont nous sélectionnons les blocs aujourd'hui. On irait toujours dans la même zone d'insertion pour sélectionner des blocs. Mais cette fois, on peut également choisir parmi Blocs (blocs simples) -> Variations de blocs (blocs multiples) -> Mise en page (modèles) -> Sections du site (en-tête, pied de page, etc.)

Une chose à considérer est l'emplacement du champ de recherche et ce que cela implique. Avec vos dernières créations @enriquesanchez, le champ de recherche serait répété pour chacun des onglets supérieurs (blocs et motifs), ce qui me fait penser que je ne peux rechercher qu'un groupe à la fois. Mes premiers espoirs ici étaient que nous pourrions avoir une seule entrée pour permettre la recherche à travers les deux blocs _et_ motifs.

C'est peut-être un espoir erroné, ou peut-être que je ne comprends pas comment fonctionne l'entrée de recherche.

J'ai remarqué dans la maquette que même si l'onglet "Modèles" est mis en surbrillance, le champ de recherche indique que vous pouvez rechercher des blocs et des modèles. Est-ce correct? Ou devrais-je être limité à bloquer les motifs sous l'onglet Motif?

Avec vos dernières créations @enriquesanchez, le champ de recherche serait répété pour chacun des onglets supérieurs (blocs et motifs), ce qui me fait penser que je ne peux rechercher qu'un groupe à la fois.

@mapk @shaunandrews Merci pour vos commentaires! Je ne sais pas pourquoi, mais quelque part en cours de route, j'ai déplacé le champ de recherche parce que je l'avais initialement en haut des onglets (voir https://github.com/WordPress/gutenberg/issues/17335#issuecomment-575835877).

Je suis d'accord avec @shaunandrews , je pense que l'entrée de recherche devrait être le premier élément de l'inséreuse (telle qu'elle est actuellement). C'est la première chose qui se concentre après l'ouverture de l'inséreuse, c'est efficace et global.

Je pense que l'entrée de recherche devrait être le premier élément de l'inséreuse (telle qu'elle est actuellement). C'est la première chose qui se concentre après l'ouverture de l'inséreuse, c'est efficace et global.

Pouvez-vous également explorer à quoi cela pourrait ressembler? Lorsqu'une requête de recherche renvoie des résultats à la fois sous forme de bloc et de modèles, à quoi cela ressemble-t-il?

J'ai passé un certain temps à regarder comment les blocs seront affichés si nous présentons un modal plus grand pour la bibliothèque de blocs, comme cela a été exploré sur ce problème.

Je continue de me pencher pour avoir une liste de gauche pour les catégories, comme le premier exemple de ce commentaire précédent.

Et si nous suivions le même schéma mais pour les blocs? Cela signifie que nous abandonnerions l'utilisation des accordéons comme nous le faisons actuellement. Cela signifie également que pour la plupart des catégories, il y aurait BEAUCOUP d'espace inutilisé:

De toute évidence, ce n'est pas idéal.

Une autre itération m'a conduit à l'idée d'avoir une liste continue de toutes les catégories de blocs et d'avoir les liens sur la liste de gauche pour vous faire défiler jusqu'à l'endroit correspondant. Quelque chose comme ça:

J'imagine que si je suis allé de l'avant et que j'ai commencé à faire défiler (au lieu de cliquer sur l'un des liens), l'état actif sur la liste de gauche se mettra à jour en conséquence pour communiquer la position.

Cette solution fait une bien meilleure utilisation de l'espace, et nous gardons quelques trucs que j'aime:

1. La liste de toutes les catégories est toujours visible, ce qui signifie que la découverte et l'exploration en bénéficient.
2. Nous n'avons plus besoin de cliquer pour ouvrir un accordéon de catégorie, et comme la liste de tous les blocs est désormais déroulante, la navigation devient plus facile.

Que pensez-vous tous?

@enriquesanchez J'adore cette exploration.

1. Pourrions-nous nous débarrasser des aperçus dans ce genre de scénario? (Je ne suis pas forcément opposé à ça, juste curieux)
2. Que se passerait-il si une catégorie était trop longue? (Exemple: https://d.pr/i/DSsHTW). Serait-il simplement intégré dans une nouvelle ligne? Dans ce cas, je voudrais simplement m'assurer que les catégories ont plus d'espace entre elles afin qu'il n'y ait pas de confusion.
3. J'adore le défilement continu par opposition aux accordéons.

Ça a l'air bien. Question cependant. Avons-nous besoin de clarifier " Block " dans " Block Patterns "?

Merci pour les commentaires @jwold et @richtabor 👍

Pourrions-nous nous débarrasser des aperçus dans ce genre de scénario?

Je penche vers ça, mais seulement pour les blocs. L'aperçu semble être très utile pour les motifs. J'aime aussi cette distinction visuelle entre les deux: blocs = petites icônes, motifs = vignettes plus grandes

Que se passerait-il si une catégorie était trop longue?

Je suis d'accord, ils emballeraient, quelque chose comme ça:

J'adore le défilement continu par opposition aux accordéons.

🙌

Question cependant. Avons-nous besoin de clarifier "Block" dans "Block Patterns"?

@richtabor C'est une bonne question. Alors vous suggérez que nous utilisions "Blocks" et "Patterns"?

Btw je pense que les Patterns ont été renommés Variations.

Btw je pense que les Patterns ont été renommés Variations.

Les variations ne sont pas liées aux modèles - c'est une partie technique des blocs de construction et n'est pas exposée dans l'interface utilisateur en tant que terme.

J'ai exploré différentes variantes de la bibliothèque de blocs lorsqu'elle est appelée depuis un inséreur frère (quelque part au milieu du document).

1. Popover

C'est très similaire à ce que nous avons actuellement, juste un peu plus grand:

2. Gros modal

Devrait faciliter la navigation dans les modèles. Je ne suis pas sûr d'aimer le fait qu'il couvre le contenu derrière.

3. Panneau coulissant

Suggéré par @mapk. Très similaire à https://github.com/WordPress/gutenberg/issues/17335#issuecomment -585425675 en termes de taille et de placement. Je me demande si le slide-in pourrait être le modèle par défaut à la fois pour la barre d'outils supérieure et les inserteurs frères

Voici un simple prototype Figma à cliquer qui rassemble tout cela.

Essayez d'ouvrir la bibliothèque de blocs à partir de la barre d'outils supérieure, de basculer entre les onglets de blocs et de modèles de bloc et d'effectuer une recherche. Enfin, essayez d'ouvrir la bibliothèque de blocs à partir du frère ou du milieu de l'inséreuse de documents.

❗️ _Remarque: l'insertion de blocs et de motifs n'est pas encore disponible dans le prototype._

Hey Enrique @enriquesanchez

Avoir un simple prototype Figma fait vraiment une énorme différence. Comme cela donne vraiment une idée de ce à quoi une version finie ressemblerait.

L'écran Blocs donne vraiment un meilleur aperçu de ce qui existe aujourd'hui. On peut facilement voir les blocs disponibles sans avoir à ouvrir des accordéons pour voir quels blocs ils contiennent. Il y a également plus d'espace disponible.

Un exercice des yeux et de l'esprit le samedi matin ... :)
L'esprit / les yeux se déplacent en remarquant la zone des blocs les plus utilisés et les plus communs qui contiennent la symétrie et l'équilibre.

Lorsque les yeux se déplacent vers la gauche, ils voient une liste descendant en commençant par Les plus utilisés et en se terminant par Embeds.

Le plus utilisé est en bleu. Au-dessus, il y a une autre couleur bleue, une ligne sous le texte en gras Blocks (l'esprit ne sait pas pourquoi la ligne bleue est là car elle est si loin du mot Blocks qu'elle semble séparée. Logique je sais pourquoi.). Vers la droite Les motifs de bloc ne sont pas en gras et sans ligne en dessous. Vous trouverez ci-dessous un texte le plus utilisé en gras. Plus loin, mon esprit voit le contour de la bordure d'une boîte et le texte de recherche à l'intérieur et est capable de se détendre à nouveau.

Cela signifie regarder chaque petit élément et comment ils se rapportent à ce qui se trouve à proximité et à la zone globale dans laquelle il se trouve.

Salut.

Il doit y avoir de la place pour une présentation textuelle du motif de bloc.
Tous les utilisateurs ne seront pas aidés par une image d'aperçu.

Merci pour les commentaires @paaljoachim et @carolinan! 🙏

Il doit y avoir de la place pour une présentation textuelle du motif de bloc.

Je suis d'accord avec toi. J'ajouterai plus de fidélité au prototype, y compris les descriptions de bloc / modèle en survol, nous devons nous assurer que ces descriptions sont communiquées à AT.

2. Gros modal

Devrait faciliter la navigation dans les modèles. Je ne suis pas sûr d'aimer le fait qu'il couvre le contenu derrière.

Pour l'introducteur frère, ce _feels_ est le plus naturel, bien qu'une maquette hi-fi puisse nous aider à mieux décider. Peut-être que faire le fond sombre modal de base aidera à mettre l'accent sur le modal (illustré ci-dessous).

Fournit un espace de visualisation suffisant pour que l'utilisateur puisse distinguer correctement les modèles individuels - leur donnant une idée plus claire de ce qui sera ajouté à la page. Nous pourrions même garder les motifs sur deux colonnes de large - en nous assurant qu'ils sont correctement visibles.

3. Panneau coulissant

Suggéré par @mapk. Très similaire à # 17335 (commentaire) en termes de taille et de placement. Je me demande si le slide-in pourrait être le modèle par défaut à la fois pour la barre d'outils supérieure et les inserteurs frères

C'est intéressant, même si je pense que ce sera trop déconnecté de l'introducteur frère. Et si nous bloquons de toute façon la vue du contenu / site derrière lui, je dirais qu'opter pour un mode complet permet une meilleure utilisation de l'espace. À ce stade, notre attention doit être consacrée aux motifs / à l'inséreuse.

En outre, ce ne seront pas des captures d'écran - mais des "exemples", tout comme la façon dont les variations de style prennent en charge les exemples - correct?

Exemple d'exemple:

@richtabor C'est une bonne question. Alors vous suggérez que nous utilisions "Blocks" et "Patterns"?

Je le dirais.

J'ai commencé à décomposer cela en petites itérations et j'ai ajouté une liste de tâches à la description du problème. Cette liste n'est pas exhaustive et nous découvrirons très probablement des choses au fur et à mesure de la mise en œuvre. Certains de ces éléments peuvent ne pas être implémentés dans le cadre de ce problème.

Pour ce que ça vaut, il serait vraiment utile de modifier le commentaire d'origine pour définir succinctement
ce qu'est exactement un modèle de bloc et en quoi ils sont différents des modèles de bloc.

Cela serait utile pour accélérer le processus d'intégration des contributeurs potentiels;
et rappelez aux membres principaux qui cherchent à se perfectionner et à se mettre au courant dans ce domaine; et de s'assurer que tous les contributeurs sont sur la même page (jeu de mots).

Il y a eu une certaine confusion parmi les membres principaux existants (lisez également les commentaires qui suivent immédiatement le commentaire lié) au sujet de l'utilisation conflictuelle de la terminologie avec les modèles.

En lisant les deux premiers commentaires, je ne savais pas en quoi les "modèles de bloc" étaient différents des modèles internes (qui peuvent être réutilisés dans plusieurs types de publication, ne doivent pas nécessairement être liés à une partie spécifique d'une page).

De ce que j'ai recueilli; blocs modèles série de blocs qui sont la disposition; mais le contenu à l'intérieur des blocs n'a pas encore été défini par l'utilisateur et que le contenu est le même
et sont-ils destinés à remplacer les fichiers template.php?
(il est compliqué qu'un modèle dans WordPress puisse représenter la quasi-totalité de la page ou il puisse être résumé pour cohérent de 3-4 fichiers de modèle supplémentaires (modèles internes)

Un modèle de bloc résoudrait-il un cas d'utilisation de "J'ai besoin d'un bloc de légende qui se composerait de plusieurs blocs: un en-tête (dont je pourrais personnaliser le niveau de titre en fonction de la sémantique)
un bloc de paragraphes et un lien pour vous inscrire à un événement ")?

Aperçu des modèles

je l'ai vu l'autre jour. C'est un exemple de la façon dont l'aperçu suit la position verticale du curseur. Si nous optons pour un aperçu détaché, cela pourrait valoir la peine d'être exploré.

un exemple de la façon dont l'aperçu suit la position verticale du curseur. Si nous optons pour un aperçu détaché, cela pourrait valoir la peine d'être exploré.

En fait, je pense qu'avoir l'aperçu dans une position fixe pourrait faciliter le _scrub_ des éléments de la liste - vous pouvez garder l'œil dans le même espace.

Juste une question. Les modèles de bloc permettront-ils de définir des zones verrouillées, afin que les utilisateurs ne puissent pas modifier la structure de base dans un modèle de bloc? Par exemple, serons-nous en mesure de verrouiller le nombre de zones d'entités dans le modèle de bloc attaché, afin qu'aucune ne puisse être ajoutée ou supprimée? Envisagez-vous ce cas d'utilisation?

salut @mrleemon!

Nous n'avons pas envisagé ce scénario. À partir de maintenant, les modèles de bloc sont destinés à être des sections que les utilisateurs peuvent ajouter et modifier si nécessaire. Cela signifie également adapter le contenu à leurs besoins.

Pourriez-vous en dire un peu plus sur le cas d'utilisation que vous avez partagé? Quand et pourquoi serait-il utile de l'avoir?

@enriquesanchez

Je pense à une conception d'une page avec une série de blocs de groupe dans un ordre spécifique permettant aux utilisateurs (avec le rôle d'éditeur, par exemple) de modifier le contenu de ces blocs, mais pas de les supprimer ou de changer leur ordre, donc le les ancres de menu en haut de la page continuent de correspondre à la structure de la page.

Pourriez-vous en dire un peu plus sur le cas d'utilisation que vous avez partagé? Quand et pourquoi serait-il utile de l'avoir?

Du travail passé avec des clients, j'ai également entendu cette demande, généralement de grandes organisations avec des flux de travail éditoriaux spécifiques. Habituellement, ils veulent fournir une mise en page approuvée pour un type de contenu spécifique, puis ont des auteurs qui peuvent modifier le contenu (images, vidéos, texte, etc.) dans la mise en page, mais pas modifier la mise en page elle-même. Le raisonnement derrière cela est généralement de maintenir une conception et une image de marque cohérentes pour le contenu du ou des sites, même lorsque de nombreuses personnes différentes génèrent et éditent du contenu.

avoir des auteurs qui peuvent modifier le contenu (images, vidéos, texte, etc.) dans la mise en page, mais pas modifier la mise en page elle-même

Oui, avoir la possibilité de verrouiller des blocs de type disposition (groupes, colonnes, etc.) serait génial.

Je sais pertinemment que cela s'est déjà produit auparavant, et je pourrais jurer qu'il y avait un aspect de verrouillage dans les modèles qui vous permettrait d'accomplir cela, mais cela m'échappe. Dans tous les cas, le cas d'utilisation semble légitime, et intéressant à résoudre.

Ceci est définitivement disponible lors de la création de modèles. Comme il s'agit d'une API de niveau inférieur, elle n'est pas encore accessible à partir du niveau de création de modèle.

Voici une suggestion basée sur la dernière maquette de Rich's @richtabor
Gros modal 2. https://github.com/WordPress/gutenberg/issues/17335#issuecomment -587951100

Grand module vs petit module. Il pourrait peut-être y avoir une icône quelque part pour rendre l'écran d'insertion plus petit. On clique sur l'icône la plus petite et l'inséreuse de blocs devient petite de sorte que l'on puisse se concentrer sur le motif que l'on pense utiliser en relation avec le contenu de la mise en page.

J'ai continué la maquette de Rich et ajouté Use and Edit et une icône de verrouillage.
Cela signifie que l'utilisateur peut modifier un modèle ou un bloc réutilisable.
La modification n'est pas disponible là où l'administrateur a verrouillé le modèle.
L'utilisateur peut cliquer sur Utiliser, le titre du motif ou le motif lui-même pour utiliser / insérer directement dans la mise en page. J'ai également rapproché le soulignement bleu de la zone sélectionnée.

Alternative.
Utilisez une configuration gir pour créer une liste déroulante qui affiche Modifier (si l'objet peut être modifié), puis Importer et exporter, etc.

Cliquez sur Modifier. Zone focalisée pour éditer uniquement un motif / bloc réutilisable.

La version initiale de ceci est terminée. Il y a encore quelques tâches de suivi ici (recherche, catégories ...) Je vais cependant fermer ce problème car nous avons celui-ci # 21080 avec une bonne liste de suivis.