Gutenberg: Considérez l'utilisation réelle de WordPress pour quantifier les hypothèses formulées dans le projet Gutenberg

Créé le 17 avr. 2018  ·  33Commentaires  ·  Source: WordPress/gutenberg

Aperçu du problème

Le projet de l'API REST a été au centre de l'attention de 2012 jusqu'à l'achèvement de son inclusion dans WordPress 4.7. Son développement a duré quatre ans.

Malgré cette longue période de développement, ce n'est que lorsque le développement de Gutenberg a commencé en 2017 que les lacunes de l'API REST ont vraiment été constatées à une échelle percutante. L'étiquette Core REST API Task suit les problèmes dans l'API REST de base qui ont été identifiés à la suite de ce que les développeurs de Gutenberg essaient de faire avec.

Tout cela pour dire que l'API REST a traversé quatre années de développement mais présente des lacunes qui n'ont été identifiées que lorsque les développeurs ont commencé à créer un produit réel destiné à l'utilisateur final qui la consomme. Les tentatives pour remplacer la fonctionnalité admin-ajax.php dans la zone d'administration de WordPress par des appels d'API REST ont également rencontré des problèmes.

Quel est mon point? Mon point est que l'API REST n'a pas été suffisamment exposée à _l'utilisation du monde réel_ au cours de son cycle de développement, et cela ne devient apparent que lorsque les développeurs commencent à créer des applications innovantes dessus et que des lacunes sont découvertes. Pas assez de gens ont construit des choses qui ont utilisé l'API REST pendant son développement afin de découvrir si ce qui était construit résolvait réellement les problèmes.


Ce ticket servira à éviter que le même problème n'arrive à l'éditeur Gutenberg. Avant même qu'une proposition de fusion puisse être envisagée, une quantité substantielle d'utilisation de Gutenberg dans le monde réel doit être effectuée, rassemblée, analysée, réitérée et considérée comme des aspects directeurs de son développement continu.

L'utilisation réelle de Gutenberg couvre un spectre beaucoup plus large que l'API REST. Cela couvre:

  • Utilisateurs finaux non techniques utilisant l'éditeur pour publier du contenu représentatif de 30 % du Web.
  • Les blogueurs, les rédacteurs de journaux, les journalistes citoyens et les écoliers publient jour après jour du contenu détaillé.
  • Les réalisateurs créent des sites de commerce électronique et des sites d'adhésion, des répertoires d'entreprises, des sites de brochures, des portefeuilles de photographies et des sites Web d'équipes de football à l'aide de plugins et de thèmes standard.
  • Des développeurs inexpérimentés piratent ensemble des plugins et des thèmes avec des constructeurs de pages, des scripts et des styles en ligne et remplacent trente filtres dans WordPress pour obtenir le résultat qu'ils souhaitent.
  • Les propriétaires d'entreprise faisant tout ce qui précède.
  • Les gens qui traitent du contenu écrit il y a vingt ans.
  • Des équipes de développeurs expérimentés créent et maintiennent des sites commerciaux critiques pour les éditeurs, les banques, les conseils, les universités et les gouvernements.
  • Les agences repoussent les limites et souhaitent utiliser Gutenberg dès qu'elles le peuvent.
  • Développeurs à tous les niveaux souhaitant créer des types de blocs personnalisés, des workflows éditoriaux personnalisés, des types de publication personnalisés avec des dizaines de méta-boîtes.
  • Développeurs et utilisateurs finaux de frameworks pour la création de champs méta personnalisés et de champs méta.
  • Administrateurs système et développeurs s'occupant des migrations, des scripts de ligne de commande pour le traitement du contenu, de l'analyse du contenu, des sauvegardes et des pistes d'audit.
  • Propriétaires de sites Web qui utilisent un hébergement mutualisé avec des ressources informatiques et réseau extrêmement limitées.
  • Les développeurs à l'intérieur et à l'extérieur de l'écosystème WordPress créent des plugins et des thèmes gratuitement ou pour gagner leur vie.
  • Les développeurs qui souhaitent que WordPress avance en termes d'architecture technique.
  • Les développeurs qui s'attendent à ce qu'une décennie de compatibilité descendante soit maintenue.
  • Utilisateurs qui n'utilisent pas l'anglais comme langue maternelle.
  • Les utilisateurs qui souffrent de handicaps situationnels, temporaires ou permanents qui affectent leur capacité à publier et à gérer leur contenu.
  • Utilisateurs n'utilisant pas la dernière génération de MacBook Pro avec 16 Go de RAM.
  • Les utilisateurs qui paient pour chaque Mo de données qu'ils utilisent.
  • Utilisateurs et développeurs des applications mobiles et de tout autre élément qui communique avec WordPress via l'une de ses nombreuses interfaces externes.
  • Les utilisateurs qui se débrouillent très bien avec WordPress tel quel.
  • Les utilisateurs qui ne peuvent pas faire ce qu'ils veulent avec WordPress tel quel.
  • Les utilisateurs qui cliquent sur le bouton « Mettre à jour WordPress » sur leur site Web de production sans jamais penser à ce qu'ils pourraient faire en cas de panne.

J'ai ouvert ce problème parce que je pense que le projet dans sa phase actuelle ne prend pas en compte l'utilisation dans le monde réel, et je ne pense pas que l'on ait suffisamment réfléchi aux problèmes qu'il résout. Deux questions ouvertes illustrent ce point :

  • #3354 - Aperçu en langage clair de la portée, de la direction et des objectifs du projet. Cette esquisse ne semble pas exister, après plus d'un an de développement.
  • #4894 - Portée et fonctionnalités : MVP. Cette liste se concentre sur quoi sans mentionner pourquoi . Ce n'est pas ainsi que sont construits les produits à succès.

Le résultat est que le projet fait de nombreuses hypothèses sur les utilisateurs finaux et sur la manière dont ils utiliseront un site WordPress alimenté par Gutenberg. Des tests utilisateurs ont été effectués (le plus récemment, je crois à WCUS en décembre), mais avec un scénario étroit et contrôlé qui n'est pas représentatif de la façon dont 30% du Web utilise WordPress. J'aime actuellement utiliser et expérimenter Gutenberg, mais je ne suis pas du tout représentatif de l'utilisateur cible.

Pour réussir, le projet doit prendre un peu de recul et considérer ce qu'il essaie d'accomplir, pour qui et à quel titre.

Je veux que Gutenberg réussisse. En fait, je pense que Gutenberg _doit_ réussir, mais ce ne sera pas le cas à moins que l'utilisation du monde réel ne soit placée au premier plan des considérations prises en compte lors du développement du projet.

À cette fin, une question : comment les considérations d'utilisation du monde réel peuvent-elles être intégrées dans la conception et le développement en cours du projet pour garantir son succès ?


Addendum : Ma propre disponibilité pour travailler sur ce problème, et Gutenberg lui-même, est malheureusement presque nulle (ironiquement en raison du travail sur un projet alimenté par Gutenberg pour un client) mais je garderai un œil sur ce problème dès que je le pourrai.

_Edit :_ J'ai mis à jour le titre du problème pour plus de clarté.

Commentaire le plus utile

Je travaille sur un site chez 10up pour une division gouvernementale et nous prévoyons également d'expédier avec Gutenberg, qu'il s'agisse d'une fusion ou d'un plugin. Le calendrier de lancement est également juin/juillet.

Comme @chrisvanpatten, notre plan initial était de vraiment tout faire et d'utiliser Gutenberg pour les pages, les articles et même les modèles comme la page d'accueil ou d'autres pages de destination qui seraient généralement des modèles archive-*.php plus ou moins codés en dur avec des zones de widgets. ou des commandes de personnalisation ou autre.

Cependant, certains problèmes que nous rencontrons lors de l'utilisation de Gutenberg sont essentiellement des "bloqueurs" (jeu de mots) pour faire tapis :

  • le manque de bonne prise en charge des modèles de page.
  • le manque de possibilité de liste blanche/liste noire à la fois pour l'ensemble de l'éditeur (personne n'a besoin de 62 blocs prêts à l'emploi), mais aussi pour la liste blanche/noire des blocs autorisés qui peuvent aller dans des blocs imbriqués. . .(comme quels blocs devraient être autorisés dans une colonne 1/8 ou d'autres blocs emboîtables spécifiques, etc.) - et d'autres conditions, comme le rôle d'utilisateur, le modèle de page, le post_type, etc.
  • l'absence d'une API côté serveur pour fournir une validation sur l'entrée de l'utilisateur. La validation du client est agréable, mais nous pensons qu'il est toujours sage de _ne jamais faire confiance au client_

J'ai d'autres préoccupations générales, mais ce sont certaines de celles qui entravent vraiment l'utilisation actuelle du monde réel pour nous.

Tous les 33 commentaires

Je pense que Gutenberg doit réussir

Qu'est-ce que le succès ? Gutenberg aura réussi quand … ?

Je pense également que des tests utilisateurs informels liés à l'accessibilité ont été effectués récemment au CSUN.

Merci d'avoir prêté votre voix à ce problème, @johnbillion.

Comme vous et beaucoup d'autres le savez, les tests d'utilisabilité sont l'un de mes sujets préférés. Jusqu'à présent, nous avons eu de petits groupes de test organisés car je pense qu'il est important de savoir qui et ce que nous avons testé. Mon espoir, comme la plupart, est qu'à mesure que Gutenberg se rapproche de la fusion, nous verrons encore plus de tests.

Pouvons-nous jamais faire trop de tests et obtenir trop de retours ? Probablement pas. L'ajout de nouvelles fonctionnalités à 30 % du Web n'est pas sans risques. Nous avons beaucoup itéré sur les fonctionnalités existantes, à tel point qu'il est maintenant temps d'obtenir un produit stable, pour ensuite tendre la main à des groupes de test de plus en plus diversifiés.

J'aimerais en savoir plus sur ce que vous, John et d'autres construisez avec Gutenberg. Que pouvons-nous faire pour rendre ce processus plus facile pour ceux qui créent et ceux qui utilisent l'expérience ? Quelles sont les histoires de cas de stress que nous devons entendre ? Plus les gens utilisent, développent et lancent avec Gutenberg, plus nous nous rapprocherons d'un produit prêt pour 30 % d'Internet.

@johnbillion Je travaille activement sur Gutenberg maintenant s'il y a des conversations spécifiques dans aimeriez m'impliquer .

Je voudrais d'abord saluer le travail acharné, les tentatives délibérées d'inclusion et la patience louable dont l'équipe de base de Gutenberg a fait preuve depuis sa création.

Souvent pour le mieux, Gutenberg est opiniâtre. Il prend en compte les réalités du stockage des données, du contenu hérité et des besoins des utilisateurs. Mais je pense que ma préoccupation est que la nature opiniâtre reproche un certain contrôle historique des utilisateurs (et des développeurs), et cela risque de s'aliéner certains marchés. Cela pourrait également ouvrir de nouvelles portes pour WordPress qui le soutiennent ¯_(ツ)_/¯.

Les métaboîtes encourageaient les utilisateurs à afficher et masquer, réorganiser et créer de nombreuses expériences différentes. C'est une force et une faiblesse primordiales.

De nombreuses boîtes méta peuvent être ouvertes, cependant, un seul onglet/accordéon peut être ouvert. La réduction de Gutenberg est peut-être puissante, peut-être saine, permet peut-être des produits plus complexes à l'avenir, mais réduit la capacité du HUD à faire défiler une longue page sans interaction et peut limiter certains cas d'utilisation.

Je pense que mes préoccupations les plus fortes sont :

  • Les modèles de volet droit et de bloc de Gutenberg sont limités en espace d'écran, ce qui encourage les développeurs à rechercher une solution similaire à l'ancien PostFrame pour créer des interfaces de recherche complexes vers les API de service (entreprise Elasticsearch, YouTube, Getty, etc.). Ce serait formidable si Gutenberg imposait de bonnes habitudes ici ou présentait un chemin privilégié pour les interfaces utilisateur complexes avec beaucoup d'entrées.
  • Je crains que le fait d'avoir deux bases de code JavaScript très disparates qui doivent se mélanger puisse entraver l'adoption, les outils communautaires partagés et l'élan.
  • Bien qu'il s'agisse d'un défi de taille, les blocs de Gutenberg ne résolvent pas une lacune des codes courts avec un contenu dynamique en ligne avec du texte comme des liens d'affiliation, des variables personnalisées ou des notes de bas de page. Je crains que de bonnes intentions avec Blocks ne créent des situations où le "sur-blocage" devient un modèle sur lequel les développeurs/utilisateurs s'appuient pour obtenir un effet.

Mon équipe et moi venons de lancer un projet de reconstruction d'un site WordPress pour un magazine nord-américain semi-éminent/bien diffusé. Nous prévoyons d'être les premiers à être Gutenberg et souhaitons également l'utiliser pour gérer la mise en page de la page d'accueil (en plus du contenu de l'article et de la page statique). Le lancement de la cible est fin juin/début juillet.

J'espère publier des articles de blog en cours de route sur l'expérience et j'encouragerai certainement l'équipe à contribuer à Gutenberg, d'autant plus que nous travaillons avec l'équipe éditoriale du magazine et que nous avons une idée de la façon dont ils l'utilisent dans leur flux de travail. Je conviens que voir Gutenberg dans des situations du monde réel est essentiel et j'espère que notre expérience pourra être utile pour l'aider à se développer.

S'il existe d'autres moyens spécifiques d'aider l'équipe Gutenberg, nous serions ravis de le faire !

Grande note et articulation admirable d'un sujet sensible. @johnbillion a identifié ici un certain nombre de personnalités d'utilisateurs qui pourraient être affectées négativement par la version Gutenberg. Beaucoup d'entre eux sont des utilisateurs que je qualifierais de .org , contre .com . Certains des utilisateurs peuvent être caractérisés comme enterprise , vs consumer .

Je pense que c'est une déclaration juste que le .com + consumer a été un objectif démographique clé pour l'équipe Gutenberg.

De nombreux développeurs de ce fil représentent .org + enterprise . Un exemple admirable est donné par @chrisvanpatten et d'autres équipes qui construisent maintenant pour Gutenberg. Je les considère comme des efforts critiques pour comprendre Gutenberg et tout delta entre son état actuel et ce qui est nécessaire pour un lancement réussi.

Mais en ce qui concerne ces .org + enterprise efforts, je suis curieux de connaître le timing. L'un de ces projets serait-il lancé avant la fusion de Gutenberg dans Core ? Une salle de rédaction multi-auteurs et de grande capacité envisage-t-elle d'utiliser Gutenberg avant une version 5.0 ? Pour l'anecdote, j'ai moi-même été découragé de le faire à l'heure actuelle car le risque/la récompense n'est pas là.

Matt et Automattic ont fait un bon travail pour expliquer pourquoi Gutenberg devrait être une priorité pour WordPress, et en tant que fondateur du projet, il a le droit du BDFL de définir une stratégie de manière non démocratique. Mais pour se prémunir contre un éventuel lancement infructueux de Gutenerg, je pense qu'A8c pourrait aider la communauté en encourageant, en aidant et en subventionnant les tests au niveau de l'entreprise avant la version 5.0. Bien que les mentions publiques d'une date de sortie aient été rares, il semble toujours y avoir une rumeur selon laquelle mai/juin pourrait voir 5.0. Cette chronologie semble précipitée, et comme je l'ai souligné sur Twitter, Gutenberg semble déjà être un inadapté au regard "les délais ne sont pas arbitraires". Donc retarder davantage semble bien.

@davisshaver Je ne peux parler que pour nous-mêmes, mais nous prévoyons absolument d'expédier, que Gutenberg ait été fusionné ou non (et fonctionne en supposant qu'il n'aura pas encore été fusionné).

Il convient également de noter que Automattic _is_ encourage et assiste les déploiements d'entreprise, via WordPress VIP. Lors de la récente manifestation #BigWP à New York , ils ont annoncé qu'ils publierons une formation Gutenberg au public (potentiellement demain?) Et en libérant une plus la version configurable du plug -

Nous ne sommes pas un partenaire VIP, donc c'est agréable de les voir mettre (certaines de) ces ressources à la disposition du public, et j'espère qu'ils continueront à le faire !

D'accord! Les ressources d'ingénierie sont bonnes et appréciées! Mon point concernant Automattic n'était pas sur la documentation ou la qualité du code. Il s'agit plus d'une préoccupation générale concernant les inconnues inconnues et la responsabilité particulière d'A8c ayant mélangé ses activités d'entreprise et open source. Comme très bien démontré par les ressources VIP ;).

Ce qui n'est pas documenté, ce que vous allez générer, c'est l'apprentissage du lancement dans une salle de rédaction à volume élevé. À ma connaissance, si vous deviez vous lancer, vous seriez parmi les premières organisations à atteindre la désignation .org + enterprise utilisant le produit. Cela me semble sous-optimal; une utilisation plus importante serait préférable, et tous les types d'utilisateurs mentionnés par @johnbillion auraient idéalement le temps de tester l'expérience sur route.

À l'heure actuelle, il semble que le plan soit de mettre Gutenberg à la porte et de s'attendre à ce que les salles de rédaction des entreprises changent à la fin de l'année. Mais que se passe-t-il si nous découvrons quelque chose de critique au cours de cette première période ? Avant que l'entreprise n'ait migré, après qu'elle soit dans Core. Cette période où les utilisateurs se forment des opinions sur le chemin de mise à niveau et Gutenberg. Nous n'avons qu'une seule chance d'y parvenir. Nous voulons tous éviter toute rupture dans la communauté ou avoir besoin d'ajouter une version LTS. Personnellement, je ne pense pas que la réduction des risques à ce jour ait été adéquate pour l'échelle du projet WordPress.

Je travaille sur un site chez 10up pour une division gouvernementale et nous prévoyons également d'expédier avec Gutenberg, qu'il s'agisse d'une fusion ou d'un plugin. Le calendrier de lancement est également juin/juillet.

Comme @chrisvanpatten, notre plan initial était de vraiment tout faire et d'utiliser Gutenberg pour les pages, les articles et même les modèles comme la page d'accueil ou d'autres pages de destination qui seraient généralement des modèles archive-*.php plus ou moins codés en dur avec des zones de widgets. ou des commandes de personnalisation ou autre.

Cependant, certains problèmes que nous rencontrons lors de l'utilisation de Gutenberg sont essentiellement des "bloqueurs" (jeu de mots) pour faire tapis :

  • le manque de bonne prise en charge des modèles de page.
  • le manque de possibilité de liste blanche/liste noire à la fois pour l'ensemble de l'éditeur (personne n'a besoin de 62 blocs prêts à l'emploi), mais aussi pour la liste blanche/noire des blocs autorisés qui peuvent aller dans des blocs imbriqués. . .(comme quels blocs devraient être autorisés dans une colonne 1/8 ou d'autres blocs emboîtables spécifiques, etc.) - et d'autres conditions, comme le rôle d'utilisateur, le modèle de page, le post_type, etc.
  • l'absence d'une API côté serveur pour fournir une validation sur l'entrée de l'utilisateur. La validation du client est agréable, mais nous pensons qu'il est toujours sage de _ne jamais faire confiance au client_

J'ai d'autres préoccupations générales, mais ce sont certaines de celles qui entravent vraiment l'utilisation actuelle du monde réel pour nous.

Super article, @jasonbahl 💯

J'utilise actuellement Gutenberg pour mes articles de blog, mais je n'ai pas encore l'intention de l'utiliser pour des pages de sites Web, principalement en raison du manque de colonnes réactives, de largeur non égale et de largeur variable, ainsi que du manque de sections . Sans ceux-ci, je ne peux tout simplement pas utiliser Gutenberg pour créer des pages sérieuses. Je comprends qu'ils arrivent dans le futur, mais je préférerais vraiment qu'ils arrivent avant la version WordPress 5.0.

J'ai testé la version 2.7 récemment et l'une des principales raisons d'utiliser Gutenberg, le bloc de colonnes, continue d'être très difficile à utiliser, donc pour le moment, utiliser Gutenberg sur les sites Web clients est interdit pour moi.

Merci à tous jusqu'à présent pour les commentaires impressionnants. Je veux entrer spécifiquement dans les points de réponse si je peux pour essayer de m'assurer que nous avons tous les deux des problèmes et plus d'informations pour tout.

@chrisvanpatten vraiment excité de voir votre lancement !

S'il existe d'autres moyens spécifiques d'aider l'équipe Gutenberg, nous serions ravis de le faire !

Oui tant de façons! Nous avons toujours besoin de contributions au code, par exemple des relations publiques et du triage des problèmes. Cependant, au-delà de cela, l'utilisation et le retour d'informations là où se trouvent les points de stress sont une contribution inestimable. Publier ce message que vous dites que vous allez faire est également une énorme contribution, merci.

@davisshaver si je peux juste réfléchir à votre commentaire ici :

Je pense que c'est une déclaration juste que le consommateur .com + a été un objectif démographique clé pour l'équipe Gutenberg.

En fait, la plus grande source de commentaires a été de l'entreprise .org +. Je sais que cela peut surprendre beaucoup, mais c'est vrai. Je note les commentaires au fur et à mesure que le produit est construit et influencé par les commentaires qu'il reçoit.

Juste pour m'assurer que tout le monde a les informations, comme cela a été mentionné, je voudrais signaler https://testgutenberg.com/ et https://vipgutenberg.com/ pour des ressources impressionnantes. Il y a aussi d'autres parcours comme les super parcours de @zgordon : https://gutenberg.courses/.

@jasonbahl c'est passionnant à lire !

Je travaille sur un site chez 10up pour une division gouvernementale et nous prévoyons également d'expédier avec Gutenberg, qu'il s'agisse d'une fusion ou d'un plugin. Le calendrier de lancement est également juin/juillet.

Permettez-moi d'essayer d'aborder chaque point que vous soulevez :

le manque de bonne prise en charge des modèles de page.

Puis-je vérifier ce que vous voulez dire là et si le problème suivant aide ou non ?

Si ce n'est pas le cas, pouvez-vous peut-être dire exactement ce qui bloque et nous pouvons créer un problème pour vous, ou n'hésitez pas à en créer un bien sûr.

le manque de possibilité de liste blanche/liste noire à la fois pour l'ensemble de l'éditeur

Je ne vois pas de problème pour cela en particulier, alors vous vous demandez si vous aimeriez en faire un ? Je connais des plugins qui limitent comme https://wordpress.org/plugins/block-options/. J'aimerais creuser un peu plus là-bas cependant.

l'absence d'une API côté serveur pour fournir une validation sur l'entrée de l'utilisateur.

Cela couvre-t-il cela : https://github.com/WordPress/gutenberg/pull/5602 ? Je veux juste m'assurer que nous avons un problème à ce sujet.

J'ai d'autres préoccupations générales, mais ce sont certaines de celles qui entravent vraiment l'utilisation actuelle du monde réel pour nous.

J'aimerais les entendre ici ou contactez-moi sur chat.wordpress.org.

@davisshaver si je peux juste réfléchir à votre commentaire ici :

Je pense que c'est une déclaration juste que le consommateur .com + a été un objectif démographique clé pour l'équipe Gutenberg.

En fait, la plus grande source de commentaires a été de l'entreprise .org +. Je sais que cela peut surprendre beaucoup, mais c'est vrai. Je note les commentaires au fur et à mesure que le produit est construit et influencé par les commentaires qu'il reçoit.

Pour clarifier cela, je veux dire les utilisateurs dans les environnements .org + enterprise , pas les ingénieurs qui les servent. @karmatosed y a-t-il déjà eu un test sur un site à fort volume ?

Juste pour m'assurer que tout le monde a les informations, comme cela a été mentionné, je voudrais signaler testgutenberg.com et vipgutenberg.com pour des ressources impressionnantes.

@karmatosed vipgutenberg.com n'est disponible que pour les clients WordPress VIP, n'est-ce pas ? Cela exclut de nombreux (la plupart ?) développeurs et agences.

@greatislander, deux de ces cours VIP sont des versions en

Ils lancent également aujourd'hui du contenu gratuit sur vipgutenberg.com.

Merci pour la précision @zgordon !

@davisshaver Je ne veux pas citer de noms (pas ma place !) mais je peux dire qu'il y a certainement des organisations qui expérimentent Gutenberg en éditorial. Je ne connais aucune organisation plus grande qui l'utilise en production, mais elle est certainement exposée aux utilisateurs non-développeurs en entreprise.

@chrisvanpatten Comme vous l'avez noté, cela a été discuté lors de la récente réunion Big WP. Mais ce que je veux dire, c'est qu'idéalement > 0 organisations ont été testées en production avant la version 5.0. Je prépare actuellement le lancement d'OnwardState.com sur Gutenberg la semaine prochaine.

Pour clarifier cela, je veux dire les utilisateurs à l'intérieur des environnements .org + entreprise, pas les ingénieurs qui les servent. @karmatosed y a-t-il déjà eu un test sur un site à fort volume ?

@davisshaver , il y a eu des retours mais on peut toujours en avoir plus. Cela dépend aussi de ce dont on parle avec un volume élevé. Il est important d'obtenir tous les cas de stress, je suis absolument d'accord.

C'est super que tu te lances la semaine prochaine. Quelque chose que vous pouvez transmettre comme une leçon dans peut-être un article de blog ? Si vous ne pouvez pas publier en public, veuillez contacter le privé. J'aimerais en savoir plus de chacun quant à leurs expériences.

@greatislander : excuses, j'aurais dû ajouter que c'était pour bientôt. Comme le dit @zacgordon , tout aura du contenu gratuit à partir d'aujourd'hui - ce qui est génial !

Merci à tous pour le ton continu et la qualité de ce numéro, il est extrêmement important d'obtenir des informations comme celle-ci.

@karmatosed Je vais développer un peu plus mon commentaire précédent.

le manque de bonne prise en charge des modèles de page.

Actuellement, lorsqu'un utilisateur sélectionne un modèle de page, il est _trivial_ d'ajouter une prise de conscience contextuelle aux métaboîtes afin que l'utilisateur puisse saisir du contenu spécifique à ce modèle. S'ils changent de modèle, ils verront différentes métaboîtes.

Idéalement, lorsqu'un modèle de page est sélectionné, un utilisateur se voit présenter un "modèle de bloc" qui lui permet de modifier le modèle de page.

@melchoyce a présenté une vision convaincante pour cela à LoopConf, mais ce n'était qu'une vision, pas la fonctionnalité actuelle de Gutenberg.

Il y a des problèmes liés à cela. En fait, la recherche du "modèle de page" dans le référentiel Github affiche actuellement 136 résultats : https://github.com/WordPress/gutenberg/search?q=page+template&type=Issues

Quelques-uns pertinents : #3588, #5521 #5537 #4482 (probablement d'autres qui sont également pertinents)

le manque de possibilité de liste blanche/liste noire à la fois pour l'ensemble de l'éditeur (personne n'a besoin de 62 blocs prêts à l'emploi), mais aussi pour la liste blanche/noire des blocs autorisés qui peuvent aller dans des blocs imbriqués. . .(comme quels blocs devraient être autorisés dans une colonne 1/8 ou d'autres blocs emboîtables spécifiques, etc.) - et d'autres conditions, comme le rôle d'utilisateur, le modèle de page, le post_type, etc.

Il existe des moyens documentés de liste blanche/liste noire, mais ils ne sont actuellement pas fonctionnels. J'ai développé plus dans ce numéro: #4848, qui est un doublon de #5895 et dans les deux cas, la solution présentée déplace l'enregistrement de bloc vers le serveur, a'la #2751, où j'ai également écrit quelques livres d'une valeur de mes pensées :wink:

Ce qui nous amène au point suivant :

l'absence d'une API côté serveur pour fournir une validation sur l'entrée de l'utilisateur. La validation du client est agréable, mais nous pensons qu'il est toujours sage de ne jamais faire confiance au client

J'ai pas mal expliqué pourquoi je pense que l'API côté serveur a besoin de plus d'attention dans #2751. Également engagé dans une discussion sur l'importance pour Gutenberg d'avoir une API côté serveur sur make.wordpress.org en ce qui concerne le plan des applications natives iOS et Android pour prendre en charge Gutenberg : https://make.wordpress.org/mobile/2018/03 /21/gutenberg-on-mobile/#comment -19383

Le projet sur lequel nous travaillons maintenant a exprimé très tôt qu'ils souhaitaient que certains contenus soient modifiables par certains rôles et verrouillés sur d'autres rôles.

Les blocs sont un excellent exemple de la façon dont cela _pourrait_ être possible, et il existe probablement des moyens rudimentaires d'essayer de le faire sur le client à un certain niveau, mais en réalité, le serveur doit avoir le dernier mot sur ce que les utilisateurs peuvent faire avec quels blocs. Le client ne doit pas faire confiance. Le client _devrait_ fournir une validation au mieux de ses capacités, mais le serveur doit avoir le dernier mot.

Je pense que la possibilité de valider les commentaires du client est assez critique pour que quiconque adopte vraiment Gutenberg.

Il y a également eu des prototypes d'édition collaborative sur des blocs. . .sans une bonne API côté serveur pour savoir quelles données peuvent/ne peuvent pas faire partie d'un bloc pour agir en tant que négociateur de contrat intermédiaire entre les clients, vous demandez à des gens de se faire pirater. Si nous parlons directement de client à client, j'imagine que quelqu'un comprendra assez facilement comment envoyer quelque chose qui commence à suivre vos frappes ou quoi que ce soit d'autre. Je ne suis pas un hacker, je ne sais pas ce qu'un hacker trouverait, mais je peux vous dire que ce ne serait pas amusant à gérer. Le fait qu'un serveur effectue la validation appropriée sur l'entrée Block avant d'envoyer des données via le câble à un autre client est assez crucial lorsque vient le jour d'avoir une édition collaborative.

FWIW, il semble qu'il y ait une action à ce sujet ici : https://github.com/WordPress/gutenberg/pull/5802

Mais, toutes les ressources, la documentation, etc. indiquent toujours à tout le monde comment tout faire sur le client. Il doit y avoir un GRAND effort pour solidifier cette API serveur le plus tôt possible, puis passer en revue et mettre à jour tous les documents disponibles, y compris les documents tiers tels que les cours que @zgordon et autres ont rassemblés sur la façon d'enregistrer correctement les blocs via un L'API du serveur et faire savoir aux gens que l'enregistrement des blocs uniquement pour le client n'est généralement _pas_ recommandé.

J'ai d'autres préoccupations générales, mais ce sont certaines de celles qui entravent vraiment l'utilisation actuelle du monde réel pour nous.

  • Je pourrais probablement signaler plus de frustrations/préoccupations, mais je pense que ce que j'ai décrit ci-dessus et dans d'autres problèmes du repo m'a assez bien couvert pour le moment.

@jasonbahl merci pour ces réponses. Je suis tout à fait d'accord pour dire que la vision de Mel est excitante et que cela arrivera - mais cela ne se produit pas maintenant. Je voulais vous remercier d'avoir plongé dans le repo, je suis ravi de vous voir apparaître sur quelques problèmes.

Si jamais vous souhaitez signaler d'autres préoccupations ou problèmes, veuillez également nous contacter ici ou via chat.wordpress.org Slack. Il est important en tant qu'équipe de les entendre de tout le monde. Cela s'étend à tout le monde dans cette discussion.

@karmatosed

ça arrivera - mais ça n'arrive pas maintenant

Des éclaircissements sur ce que cela signifie ?

Quelle partie de cela ne se produit pas? Bon support pour les blocs imbriqués ? Prise en charge du contrôle des blocs pouvant être imbriqués dans d'autres blocs ? La possibilité d'échanger des modèles de blocs à la volée lorsque "Modèle de page" est modifié ?

Ce serait bien d'avoir des éclaircissements sur les fonctionnalités actuelles, telles que les blocs imbriqués, qui sont affinées afin qu'elles fonctionnent bien ou supprimées parce qu'elles sont trop difficiles à faire fonctionner ou quoi que ce soit d'autre.

Quelle partie de cela ne se produit pas? Bon support pour les blocs imbriqués ? Prise en charge du contrôle des blocs pouvant être imbriqués dans d'autres blocs ?

Hé, bonnes questions. Permettez-moi de tenter de répondre, en fonction de l'endroit où je pense que nous en sommes actuellement.

Bon support pour les blocs imbriqués ? Prise en charge du contrôle des blocs pouvant être imbriqués dans d'autres blocs ?

Pour autant que je sache, ces améliorations sont en cours : https://github.com/WordPress/gutenberg/issues?q=nested+label%3A%22%5BComponent%5D+Nested+%2F+Inner+Blocks%22

Je pense que nous allons terminer de nombreux os prenant en charge les mises en page pour la version 5.0, mais nous n'allons pas voir les mises en page natives de Gutenberg avant la sortie initiale. Le travail que j'ai fait pour pouvoir sélectionner des mises en page (au lieu des anciens modèles de page) est toujours en cours de conception et ne sera pas intégré à la version initiale de Gutenberg.

La possibilité d'échanger des modèles de blocs à la volée lorsque "Modèle de page" est modifié ?

C'est définitivement prévu, et j'ai travaillé sur des maquettes à ce sujet, mais je ne le vois pas se produire avant la version 5.0.

Personnellement, j'aimerais que la deuxième version de Gutenberg se concentre sur les pages – mises en page, meilleurs blocs pour créer des mises en page complexes, blocs plus dynamiques, etc. – mais cela reste à déterminer, en fonction du déroulement de la version initiale de Gutenberg.

@johnbillion , totalement d'accord avec tout jusqu'à la dernière section de votre billet. ??

Pour utiliser la terminologie dans un commentaire précédent, les commentaires .org et enterprise arrivent à un bon rythme en ce moment, et ont été influents et formidables. En fait, je suis plus préoccupé par certains des personnages dont on parle qui sont des utilisateurs finaux plus réguliers qui ont soit demandé à quelqu'un d'autre de configurer leur site, soit qui sont plus .com .

Ce que je pense résoudra, c'est (1) les promotions dans le tableau de bord pour que le plugin Gutenberg soit installé sur les sites .org, mis dans une future version 4.9.x et (2) la disponibilité de Gutenberg sur .com , probablement s'inscrire également dans un premier temps, à la fois dans wp-admin et Calypso. Je pense que cela augmentera nos sites actifs et nos testeurs d'un ordre de grandeur, des ~10 000 sites que nous avons aujourd'hui aux centaines de milliers, ce qui devrait éclipser toute fonctionnalité de base que nous avons fusionnée dans la mémoire récente. Une partie de mon incertitude quant à la date de sortie est purement fonction du nombre de commentaires bloquants provenant de l'exposition à ces nouveaux publics. (Il est possible que les excellents tests utilisateurs que nous avons effectués jusqu'à présent signifient que ce n'est en fait pas si mal.)

Je pense que nous avons appris beaucoup de leçons de la fusion de l'API REST, et je suis heureux que vous ayez soulevé le problème.

@jasonbahl , merci d'avoir demandé des éclaircissements et @melchoyce merci d'avoir ajouté votre contribution, la phase deux va être passionnante après avoir jeté les bases.

@johnbillion Compte tenu du calendrier proposé à WCEU, y a-t-il des mesures spécifiques et réalisables que vous suggéreriez que nous prenions qui ne sont pas déjà en cours ?

Je suis vraiment ravi d'apprendre qu'un plan est en place pour commencer les tests utilisateurs de Gutenberg sur WordPress.com. C'est probablement une bonne idée d'ouvrir un numéro qui décrit les plans qui sont en place pour recueillir et analyser les commentaires qui seront soumis par les utilisateurs dans le cadre de cette phase de test afin qu'ils puissent être suivis, triés et traités par la communauté. @danielbachhuber Est-ce quelque chose que vous pouvez coordonner ? Malheureusement, je manque encore de temps.

Si je devais choisir dans ma liste d'origine ci-dessus, je pense qu'il est important de regarder l'impact que Gutenberg a sur le type de sites qui constituent la majorité de la longue queue des sites WordPress mais qui sont (ironiquement) généralement vus moins fréquemment par la communauté WordPress principale : des sites qui sont bricolés avec un grand nombre de plugins, y compris des constructeurs de pages, des plugins de commerce électronique, des galeries de photographies, des plugins d'adhésion, des plugins multilingues et des thèmes prêts à l'emploi. Il existe un risque réel de nuire à la réputation de WordPress si l'éditeur Gutenberg casse en masse ce genre de sites ou perturbe l'expérience d'édition.

J'ajouterais 💯 ce dernier paragraphe de @johnbillion si GitHub me le permettait.
Malheureusement, ce type de site particulier et répandu peut être difficile à obtenir pour les tests.

Par exemple, le support client des plugins me permet de voir des back-ends potentiellement problématiques presque quotidiennement, et c'est probablement vrai pour d'autres supports, mais cela ne nous permet évidemment pas de tester Gutenberg sur ces sites.

Ce que les représentants de l'assistance des fournisseurs de plugins, y compris moi-même, pourraient aider à faire, c'est faire passer le mot.
Dans mon cas, notre produit n'interagit même pas directement avec Gutenberg, et cela pourrait être la même chose pour de nombreux autres fournisseurs de plugins. Cependant, cela ne signifie pas que nous devons rester silencieux. Si Gutenberg s'est avéré faire exploser les sites Web de nos clients, devinez où ces clients viennent en premier pour obtenir de l'aide…

Je vais discuter des moyens de sensibiliser les clients de l'assistance de WP Media à Gutenberg avec notre niveau C, et j'aimerais encourager les autres représentants de l'assistance d'autres sociétés à faire de même.
_(Bien que je sois conscient qu'il y a de fortes chances que je sois en retard à la fête et que beaucoup de choses se produisent déjà.)_

Je pense qu'il est important d'examiner l'impact que Gutenberg a sur le type de sites qui constituent la majorité de la longue traîne des sites WordPress mais qui sont (ironiquement) généralement vus moins fréquemment par la communauté WordPress principale : des sites bricolés avec un grand nombre de plugins, notamment des constructeurs de pages, des plugins de commerce électronique, des galeries de photographies, des plugins d'adhésion, des plugins multilingues et des thèmes prêts à l'emploi.

Cette!

C'est probablement une bonne idée d'ouvrir un numéro qui décrit les plans qui sont en place pour recueillir et analyser les commentaires qui seront soumis par les utilisateurs dans le cadre de cette phase de test afin qu'ils puissent être suivis, triés et traités par la communauté. @danielbachhuber Est-ce quelque chose que vous pouvez coordonner ?

Oui, certainement, si c'est approprié/efficace.

Un projet à mettre sur le radar de tout le monde est le travail de #hosting-community sur Try Gutenberg Hosting Support Best Practices . Essentiellement, l'objectif est d'identifier les meilleures pratiques pour héberger des équipes de support en ce qui concerne la mise à disposition de Gutenberg à un public plus large. Plus précisément, nous souhaitons que les équipes de support :

  1. Comprendre ce qu'est Gutenberg et comment il fonctionne.
  2. Soyez confiant dans le diagnostic des demandes de support/rapports de bogues.
  3. Savoir agir sur le résultat de son diagnostic (que ce soit l'ouverture d'un nouveau problème Gutenberg, le signalement du conflit à l'auteur du plugin, etc.).

Nous discutons de ce document dans nos discussions hebdomadaires depuis environ un mois maintenant. Notre plan initial était de « tester » le document avec les équipes d'assistance DreamHost et InMotion avant de faire une publicité plus large. Cependant, il pourrait être intéressant de publier un article de bloc à ce sujet plus tôt.

cc @jadonn @getsource @0aveRyan

Si je devais choisir dans ma liste d'origine ci-dessus, je pense qu'il est important de regarder l'impact que Gutenberg a sur le type de sites qui constituent la majorité de la longue queue des sites WordPress mais qui sont (ironiquement) généralement vus moins fréquemment par la communauté WordPress principale : des sites qui sont bricolés avec un grand nombre de plugins, y compris des constructeurs de pages, des plugins de commerce électronique, des galeries de photographies, des plugins d'adhésion, des plugins multilingues et des thèmes prêts à l'emploi. Il existe un risque réel de nuire à la réputation de WordPress si l'éditeur Gutenberg casse en masse ce genre de sites ou perturbe l'expérience d'édition.

Oui, et c'est certainement quelque chose sur lequel le #hosting-community a une bonne visibilité et sur lequel il est possible d'agir. Un peu d'effort de la part de petites équipes testant de manière proactive sur les sites de transfert des clients pourrait aller très loin.

Bien que la discussion dans ce numéro ait fait apparaître de nombreux points positifs, je pense qu'une bonne règle pour nos problèmes est qu'ils doivent être exploitables et discrets/spécifiques. Ce problème est assez large dans sa portée et je ne sais pas comment le mesurer "terminé".

J'espère que beaucoup des bons points autour de la recherche et des tests sont intériorisés par l'équipe travaillant sur Gutenberg et sur d'autres parties de WordPress. Je vais clore ce problème car je ne pense pas qu'il soit exploitable tel quel, mais s'il y a des problèmes discrets à en sortir qui peuvent être classés séparément, c'est cool

Cette page vous a été utile?
0 / 5 - 0 notes