Idée intéressante @melchoyce.

Ma première réaction a été de savoir comment, en les déplaçant vers le bas, cela rend le bloc plus `` bloc '' - ce qui est une chose étrange à dire mais quelque chose que cela me fait ressentir. La bordure s'affiche-t-elle au clic ou au survol? Je pense que j'ai moins de problème avec lui au clic que s'il est en survol. Un autre visuel intéressant qui fait qu'au moins vos exemples ressemblent à une image Polaroid, très intéressant comment mon cerveau y est allé.

C'est ma première réaction cependant, creusant un peu plus, je pense qu'il y a du mérite à explorer une position différente pour les icônes d'interaction sur un bloc. Je pense que ce qui lui est gagné est absolument un moyen qui fonctionne mieux sur tous les écrans, que nous devrions garder comme guide à mesure que de nouvelles explorations se produisent.

Je pense que nous perdons un peu de contexte avec les interactions. Par exemple, un bloc avec un espace réservé plus grand aurait ces interactions non directement visibles. Je pense que cela va être un problème qui pourrait se traduire par moins de découvrabilité.

Tout cela étant dit, je ne dis absolument pas que ce que nous avons maintenant devrait être la voie à suivre. Êtes-vous prêt pour itérer et peut-être explorer davantage? J'espère vraiment que vous l'êtes.

Je pense que visuellement c'est sympa. C'est essentiellement l'interface utilisateur mobile, sur le point d'arrêt du bureau, et c'est quelque chose que j'ai considéré à la fois comme un plan B si l'interface utilisateur latérale ne fonctionnait pas, ou peut-être pour des contextes imbriqués.

Depuis lors, nous avons tous deux fait des progrès avec l'interface utilisateur latérale, plus récemment sur https://github.com/WordPress/gutenberg/pull/6141 , et nous l'avons également fait fonctionner correctement dans des contextes imbriqués, bien que cela l'aspect a encore besoin d'amour.

Bien que pas aussi joli, les principaux avantages d'avoir cette interface utilisateur sur le côté sont,

1. qu'ils peuvent apparaître en survol
2. ils n'élargissent pas l'empreinte du bloc

1 est particulièrement important, car depuis le début, il a été un objectif explicite de s'assurer que le glisser-déposer est _additif_, et non la forme principale d'interaction avec le placement, la réorganisation et le tri des blocs. Si nous les plaçons sous le bloc, ils apparaîtront vraisemblablement au clic, ce qui rendrait secondaire le glisser-déposer qui fonctionnerait toujours en survol.

2 pourrait être important selon la façon dont nous traitons l'interface utilisateur latérale dans des contextes imbriqués. À l'heure actuelle, nous sommes confrontés à des défis sur https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863, et même si je suis sûr que nous serons en mesure de les résoudre, le fait que l'empreinte ne le changement n'aide pas.

Tout cela ne veut pas dire "ne peut pas fonctionner" - cela pourrait très bien fonctionner. Une ancienne maquette waaaay avait cette interface utilisateur en superposition dans le coin:

Donc dans l'ensemble, de bonnes idées, et bien de les garder dans la nouille comme des pistes qui peuvent être explorées en fonction des commentaires que nous recevons de la sortie à la sortie!

La bordure s'affiche-t-elle au clic ou au survol?

Juste un clic. Le survol serait similaire à la façon dont cela fonctionne maintenant.

Êtes-vous prêt pour itérer et peut-être explorer davantage? J'espère vraiment que vous l'êtes.

Toujours 👍

ils n'élargissent pas l'empreinte du bloc

Ouais, certainement un problème avec cette idée. Même dans ce prototype, vous pouvez en voir sauter à cause du changement de taille.

Donc dans l'ensemble, de bonnes idées, et bien de les garder dans la nouille comme des pistes qui peuvent être explorées en fonction des commentaires que nous recevons de la sortie à la sortie!

👍 👍

Je pense que nous perdons un peu de contexte avec les interactions. Par exemple, un bloc avec un espace réservé plus grand aurait ces interactions non directement visibles. Je pense que cela va être un problème qui pourrait se traduire par moins de découvrabilité.

Bien que pas aussi joli, les principaux avantages d'avoir cette interface utilisateur sur le côté sont,

1. qu'ils peuvent apparaître en survol
2. ils n'élargissent pas l'empreinte du bloc

Je pense qu'une façon de résoudre ces problèmes serait de faire apparaître la barre d'outils des outils de bloc au-dessus des blocs ci-dessous et de ne pas augmenter l'espace que le bloc prend réellement dans l'éditeur. En ce qui concerne la découvrabilité avec de grands blocs, la barre d'outils peut être rendue collante de sorte que si vous faites défiler vers le haut, la barre d'outils ne sort pas de l'écran. (Il disparaît toujours lorsqu'il ne survole pas le bloc, bien sûr, et peut-être qu'il ne pourrait apparaître que lorsque vous survolez la partie inférieure du bloc qui est actuellement visible, de la même manière que les commandes latérales fonctionnent actuellement.) Cela pourrait également prendre la forme autant d'espace que nécessaire pour afficher tous les boutons, et ne pas occuper une rangée entière d'espace vide entre 2 ensembles de commandes comme c'est le cas dans la maquette dans l'article principal de ce numéro.

+1 Juste pour noter que cela pourrait également aider à améliorer l'ordre de tabulation des contrôles de l'interface utilisateur autour des blocs. Comme mentionné dans https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531, l'interface utilisateur mobile a les «commandes latérales» placées d'une manière plus logique. Voir le GIF animé qui illustre l'ordre de tabulation, vous pouvez comparer avec le GIF précédent avec l'ordre de tabulation dans la vue du bureau dans un commentaire précédent https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

A prendre également en considération:

3976 propose une troisième option pour placer la barre d'outils du bloc (la barre d'outils de formatage) sous le bloc; ce serait formidable d'envisager une conception avec à la fois la barre d'outils du bloc _et_ les commandes latérales placées sous le bloc pour voir si cela pourrait fonctionner.

1934 en tant que problème général de cohérence de l'ordre de tabulation

Cela pourrait également avoir un impact sur la résolution de certains des problèmes soulevés dans le # 6272.

En ce qui concerne la découvrabilité avec de grands blocs, la barre d'outils peut être rendue collante de sorte que si vous faites défiler vers le haut, la barre d'outils ne sort pas de l'écran.

Oui, c'est également ce qui se passe avec la barre d'outils de mise en forme supérieure:

En lisant tous les commentaires impressionnants ici, il semble que cela résout un certain nombre de problèmes pour l'avenir et aujourd'hui avec l'accessibilité. Cela à l'esprit, je pense que nous devrions peut-être travailler sur quelques itérations ici et ensuite passer à un PR pour prototyper. Seriez-vous prêt à faire ça @melchoyce?

Ouais, je peux jeter un autre coup d'oeil.

+10 pour avoir essayé ça.

Voici à quoi ressemble l'interface utilisateur du bloc lorsque je réduis la largeur de la fenêtre de mon navigateur. (Si je la rétrécis un peu plus, la barre d'outils du bloc se déplace sous le bloc, mais ce n'est pas pertinent par rapport à ce que je suggère.)

J'ai remarqué que l'inséreuse de bloc apparaît à côté des commandes de mouvement haut / bas. Si ce type d'interface utilisateur était utilisé pour toutes les tailles d'écran comme le propose ce problème, alors peut-être que l'appender de bloc actuel pourrait être supprimé des contextes de blocs imbriqués, ce qui donnerait à l'éditeur une apparence plus similaire au frontal en supprimant l'espace supplémentaire toujours présent ajouté. par chaque ajout de bloc pour chaque niveau d'imbrication. (J'ai également suggéré une solution alternative au problème de l'espace de consommation d'appendeurs dans # 6834.)

En outre, ce n'est qu'une note latérale, mais le bouton Supprimer est-il censé se trouver à droite du bouton Plus d'options , ou devrait-il être à gauche? Dans la plupart des conceptions d'interface utilisateur, les menus d'ellipse sont placés à l'extrême droite.

Une autre idée:

Affichez ces contrôles de bloc en bas lors du survol, mais dans cet état, ils ne prennent pas d'espace sur la page et apparaissent au-dessus de tout ce qui se trouve sous le bloc survolé (tout comme la barre d'outils des blocs le fait pour les blocs au-dessus de l'actuel un) ou peut-être au-dessus du bloc survolé. Les contrôles de bloc en bas ne doivent pas non plus être une barre blanche ininterrompue en survol, mais 2 barres plus petites de chaque côté, similaires à la barre d'outils de bloc, afin de faire en sorte que les contrôles prennent moins de place et ne couvrent pas autant.

Lorsque vous sélectionniez un bloc, les contrôles de bloc en bas prendraient de l'espace, augmentant l'empreinte visuelle du bloc et poussant les blocs ci-dessous à l'écart, comme lorsque vous sélectionnez un bloc Image, l'espace réservé de la légende apparaît. Cela faciliterait la sélection du bloc ci-dessous s'il s'agissait d'un bloc verticalement court comme un bloc de paragraphe sur une seule ligne.

Cette approche vous permettrait de conserver les avantages des contrôles de survol actuels vous permettant de déplacer / supprimer facilement des blocs sans les sélectionner au préalable, tout en vous assurant que les contrôles ne couvrent rien lorsque le bloc est en cours d'édition, ce qui le rend plus facile de sélectionner ensuite un bloc différent.

Encore une idée:

Permettez à la barre de contrôles de bloc entière (et à la barre d'outils de bloc) de servir de poignée de glissement (y compris les boutons, comme le fonctionnement des barres d'en-tête GTK). Je pense que cela résoudrait à peu près le problème de la découvrabilité par glisser-déposer, en particulier dans le contexte des blocs sélectionnés, où la barre de commandes inférieure semble faire partie du bloc dans les maquettes du message initial, et par conséquent être plus susceptible d’envisager de l’utiliser comme poignée de glissement.

Comparez cela avec la situation actuelle où les côtés du bloc ne semblent pas faire partie du bloc, et il n'est donc pas si évident qu'ils peuvent agir comme des poignées de glissement, et il y a aussi le problème où les blocs de paragraphe sur une seule ligne n'ont pratiquement pas d'espace vide sur les côtés pour traîner (Et comme les boutons de commande latéraux ne peuvent pas être actuellement utilisés comme poignées de glissement à moins qu'ils ne soient désactivés, le problème est encore pire.)

Beaucoup de discussions géniales à ce sujet, voyons si je peux donner quelques commentaires récapitulatifs pour vous donner, espérons-le, quelque chose à faire pour passer à l'itération avec @melchoyce.

Dans l'ensemble, je pense que j'ai besoin de ressentir cela dans un prototype et je pense que beaucoup de mes pensées peuvent être atténuées avec cela. Cependant, il y a quelques considérations que je souhaiterais travailler dans un simulacre:

• Une solution pour les grands blocs.
• Un sentiment moins `` bloc '': cela peut simplement montrer les états d'espace réservé dans un simulacre, je le lis comme plus évident avec ces changements.
• Montrant comment cela fonctionne avec l'imbrication.

J'aimerais voir comment cela s'adapte également à différents appareils, je pense qu'il y a moins de variations et que cela pourrait être une bonne chose.

@SuperGeniusZeb quelques pensées intéressantes que vous avez là-bas. Je voudrais voir où Mel en vient avec les itérations ci-dessus. Je pense que doubler l'interface utilisateur pour faire glisser les poignées est quelque chose à éviter pour l'instant, il y a des changements d'imbrication en cours de travail sur lesquels j'aimerais y entrer. Je ne dis pas que nous n'itérerons pas, mais cette interface utilisateur n'est pas spécifiquement pour cela. Je pense aussi que vous pouvez déduire l'appartenance sans être explicite visuellement et là où cela devient trop explicite, c'est là que le sentiment négatif des blocages entre en jeu - cela semble proche et trop limitatif.

J'étais en train de chercher le # 7211 et dans le contexte de ce travail, j'ai découvert le # 7646, ce qui m'a ramené à cette idée, qui me semble vraiment être la meilleure solution pour un tas de problèmes.

Ce ticket réglerait, directement ou indirectement, tout un tas de choses:

• # 7646 → avec les commandes positionnées au-dessus / en dessous, vous n'avez pas à vous soucier de l'adaptation de l'interface utilisateur latérale
• # 7182 → les contrôles comme ceux des maquettes de ce ticket sont directement connectés au bloc et auraient une interface utilisateur cohérente quel que soit le niveau d'imbrication
• # 6451 → si les barres d'outils haut / bas ont un arrière-plan uni, vous n'avez pas à vous soucier de savoir comment rendre les contrôles visibles sur des arrière-plans sombres
• # 7114 / # 6265 → Si vous utilisez une barre d'outils pleine largeur comme dans certaines des maquettes ci-dessus, vous pouvez utiliser la zone vide pour faire glisser / déposer

Tout ça pour dire que, s'il y a encore une chance qu'un changement aussi important puisse arriver à Gutenberg, je pense que cela pourrait résoudre beaucoup de problèmes et rendre beaucoup de choses plus faciles :) Je vais me joindre à l'amusement et travailler sur quelques maquettes / concepts espérons ce week-end.

@chrisvanpatten juste pour ajouter de la perspective, ce problème concerne les contrôles et non la barre d'outils déplacés vers le bas. Cela causerait beaucoup plus de problèmes d'utilisabilité. Il suffit de vérifier que certains problèmes que vous liez semblent concerner les barres d'outils.

Je serais totalement en faveur d'essayer cela, car cela améliore beaucoup l'ordre des onglets. Une mise à jour rapide: le bouton de suppression "poubelle" a été déplacé dans le menu points de suspension. Je suggère également d'essayer de respecter le principe de proximité des commandes et de placer le bouton de sélection immédiatement à droite des déménageurs. Je ne sais pas pourquoi il devrait rester si loin à droite:

@afercia car ce sont des contrôles différents, je pense qu'avoir les points de suspension sur la droite a du sens. Explorons cela comme une première étape. Nous devons nous concentrer sur l'exploration des éléments suivants:

Une solution pour les grands blocs.
Un sentiment moins `` bloc '': cela peut simplement montrer les états d'espace réservé dans un simulacre, je le lis comme plus évident avec ces changements.
Montrant comment cela fonctionne avec l'imbrication.

Ces points doivent être explorés pour déterminer l'itinéraire à partir de ce point prometteur.

@karmatosed J'utilisais un jargon déroutant - je parlais de contrôles, pas de barres d'outils. Les barres d'outils sont déjà en haut - rien à changer là :)

Je viens de faire quelques maquettes de ce à quoi j'imagine que les outils de bloc pourraient ressembler s'ils étaient placés sous le bloc. Notez que dans ces maquettes, les outils de bloc ne prennent jamais de place, agissant uniquement comme des superpositions comme les barres d'outils de bloc sur le bureau. Les blocs sont également sélectionnés dans ces maquettes. Si vous survolez uniquement un bloc, les barres d'outils de bloc en haut ne seront pas affichées. Gardez également à l'esprit que les commandes du bas ne peuvent toujours apparaître que lorsque vous passez près d'elles, comme les commandes latérales actuelles.

Ordinaire:

Lorsque le bas d'un bloc est hors écran:

(Remarque latérale: la barre d'outils Bloc d'image ne correspond pas à celle de ces maquettes car elle a différentes options dans sa barre d'outils Bloc.)

Étant donné les problèmes avec les outils de bloc situés sur les côtés et les nombreux avantages de les avoir en bas, je suis maintenant convaincu que les avoir en bas est la voie à suivre.

@SuperGeniusZeb C'est essentiellement exactement ce à quoi je pensais, sauf que j'allais positionner le bouton plus d'options avec la flèche haut / bas au lieu de la droite, comme une barre d'outils combinée.

@chrisvanpatten Oui, cela ne me dérangerait pas que les contrôles soient séparés ou non.

Voici quelques maquettes supplémentaires:

Flotter:

Sélectionné avec une barre pleine largeur qui prend de la place (plutôt que d'être simplement une superposition) comme sur un mobile et pourrait servir de poignée de glissement:

Je dois dire que je pense que nous risquons un peu que cela devienne trop bloc ... c'est une façon étrange de décrire cela, mais ça va avec :) Par exemple, le survol montré dans la dernière maquette est assez intense. Je pense que nous devons voir cela plus pour ce que Mel a montré dans la première image qui a une bordure de moins et cela aide vraiment à ne pas avoir cela.

J'ai pris les premières simulations et enlevé la poubelle pour obtenir ce que je pense être le mieux pour progresser:

Nous n'avons pas besoin des frontières supplémentaires et nous n'avons pas besoin du poids ajouté. De cette façon, il permet un glissement facile sans les contours inhabituels en vol stationnaire.

@karmatosed J'ai modifié votre maquette pour montrer à quoi elle ressemblerait lorsque vous survoleriez un bloc:

Et le voici avec le bloc sélectionné et la barre d'outils des blocs affichée:

(J'ai également mis à jour l'espace réservé du bloc d'image pour qu'il corresponde à celui actuel de Gutenberg.)

Quelque chose qui me déroute à propos de l'absence de bordure supérieure sur les contrôles: les contrôles sont-ils toujours sur un fond blanc? Cela signifie-t-il que tout le bloc a un fond blanc derrière lui? Cela semble causer des problèmes dans des contextes imbriqués où un bloc est imbriqué dans un conteneur avec un arrière-plan sombre, car la sélection (et / ou le survol) entraînerait une modification de l'arrière-plan du bloc, ce qui semblerait assez discordant.

Quelque chose qui me déroute à propos de l'absence de bordure supérieure sur les contrôles: les contrôles sont-ils toujours sur un fond blanc? Cela signifie-t-il que tout le bloc a un fond blanc derrière lui?

C'est vrai, mais les contrôles ont des objectifs. Je pense que cela vaut la peine d'être montré et évite les problèmes visuels de bloc sans. Cela doit absolument être exploré lors de la nidification, mais sans l'arrière-plan, la nidification visuelle serait encore pire.

C'est vrai, mais les contrôles ont des objectifs. Je pense que cela vaut la peine d'être montré et évite les problèmes visuels de bloc sans. Cela doit absolument être exploré lors de la nidification, mais sans l'arrière-plan, la nidification visuelle serait encore pire.

D'accord, et avoir le fond résout également # 6451.

Je n'aime pas avoir cette grande barre vide affichée en survol dans ces dernières maquettes. Idéalement, vous voudriez couvrir le moins possible des blocs environnants en survol, mais cela couvre une grande partie du bloc ci-dessous. Que diriez-vous quelque chose comme ça?

Comme suggéré précédemment, les flèches et les points de suspension peuvent servir de poignées de glissement et / ou le titre de survol peut être une poignée de glissement. (Voir # 7114.)

@SuperGeniusZeb alors que je comprends vos points dans ce cas, avoir les blocs décrits n'est vraiment pas génial visuellement. Restons fidèles à la maquette que j'ai faite sur la base du travail impressionnant de Mel pour la voir en prototype.

Quelque chose que je viens de réaliser à propos de l'apparition d'un fond blanc derrière des blocs sélectionnés: qu'en est-il des blocs avec une couleur de texte blanche (ou de couleur claire) destinée à être vue dans une zone de couleur sombre (fournie par quelque chose comme le bloc Conteneur)? Avoir un fond blanc pour tout le bloc ne fonctionnerait pas dans ce cas.

L'arrière-plan est autour de la barre d'outils qui aura toujours ces contrôles.

@SuperGeniusZeb Ouais, je ne vois pas le fond blanc impactant le bloc lui-même, seulement les contrôles. Pratiquement, cela pourrait être quelque chose comme ceci:

Ou le remplissage pourrait potentiellement être supprimé (j'aime vraiment cette approche, mais c'est évidemment une question plus importante qui a des implications avec le glisser-déposer. Je pense toujours que cela vaut la peine d'être considéré):

@chrisvanpatten J'aime cette dernière maquette. Je ne pense pas que le glisser-déposer serait un problème puisque la barre inférieure pourrait servir de poignée de glissement (et potentiellement les boutons de la barre fonctionneraient également). Vous pouvez même ajouter une icône de poignée de glissement à la barre inférieure en survol ou simplement en avoir toujours une pour indiquer que vous pouvez faire glisser le bloc en l'utilisant.

Avec cette approche, je ne vois aucune raison de garder la zone déplaçable près des frontières du bloc. La suppression de ce remplissage pourrait également aider à rapprocher le survol du bloc / les contours sélectionnés des bordures réelles du bloc, car ils n'auraient plus à tenir compte de cet espace de glissement et n'auraient qu'à s'ajuster pour être plus grand que le bloc réel dans cas d'imbrication pour faciliter la sélection des blocs parents. (La sélection des blocs parents serait moins problématique si des éléments comme la maquette de ce commentaire dans # 6459 étaient implémentés.)

@SuperGeniusZeb

Vous pouvez même ajouter une icône de poignée de glissement à la barre inférieure en survol ou simplement en avoir toujours une pour indiquer que vous pouvez faire glisser le bloc en l'utilisant.

Excellente idée 💡

Je pense que laissons de côté la zone déplaçable et implémentons ceci. Il est important de se concentrer sur la résolution de ce que cela résout en premier. Je dois dire que je ne suis pas sûr qu'une icône soit la bonne approche, cela dit, revenons une fois que nous aurons mis cela en œuvre sans cela.

@karmatosed

Je pense que laissons de côté la zone déplaçable et implémentons ceci.

Je ne sais pas trop ce que cela signifie? Quel côté?

Heureux de voir que cela va arriver. Juste un petit rappel qu'il ne s'agit pas seulement de placement visuel. Pour a11y, l'ordre visuel et l'ordre de tabulation (ordre DOM) doivent correspondre afin que ces "outils de bloc" soient réellement déplacés après la zone modifiable de bloc dans le balisage.

Un avantage intéressant du passage aux commandes situées sous le bloc est qu'il ouvre l'espace latéral pour permettre à l'inséreur frère d'être repensé en quelque chose comme ceux de Squarespace si la conception actuelle rencontre des problèmes. Les commandes latérales actuelles auraient chevauché ce type d'inséreuse et sembleraient encombrées, mais avec les commandes déplacées vers le bas, ce n'est plus un problème.

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc -insert-points

Je viens de commenter ceci sur # 7500. Je me demandais à quoi ressembleraient les paragraphes successifs avec cette conception? Je pense qu'avoir la barre en bas entraînerait un écart assez important entre les paragraphes.

@talldan Me citant de # 7500:

Les contrôles de bloc ne prendraient pas de place en survol (tout comme eux et la barre d'outils de bloc ne prennent pas de place maintenant), et pour autant que je sache, il n'est même pas encore décidé s'ils prendraient de la place sur un bloc sélectionné. Et bien sûr, les contrôles ne seraient affichés que pour les blocs sélectionnés ou survolés. La distance standard entre les blocs ne doit pas être affectée par le changement; seul le bloc sélectionné peut être affecté.

Cela a l'air vraiment bien, je suis tout à fait d'accord.

Une chose à considérer dans ce que nous n'avons pas avant. Et les longs blocs? Qu'arrive-t-il à ceux-ci et au bas de l'écran de l'éditeur avec des blocs?

Vous voulez dire quand le bloc est si long qu'il défile hors de vue? Je dirais qu'avant que cela n'arrive, les gens auront vu comment cela fonctionne et sauront où le trouver. Nous aurions juste à tester si cela devient ennuyeux si vous écrivez beaucoup de longs paragraphes sur un petit écran. Mais j'aime que cela reflète mieux l'expérience mobile. Quelles préoccupations avez-vous pour le dernier bloc d'un message?

Comment verraient-ils si leur premier bloc était un bloc vraiment long?

Nous devrions au moins ajouter une astuce NUX à ce sujet;) mais ce qui vous inquiète, c'est le cas où quelqu'un ouvre un message existant qui est peut-être un long paragraphe ou ne s'est pas converti correctement en blocs? C'est possible ... S'ils commencent un nouveau message, ils le verront presque certainement sur le premier bloc d'espace réservé, non?

En y réfléchissant, je ne vois pas ici d'exploration de placer les commandes en haut du bloc, ce qui pourrait être une option. A fait une maquette rapide pour cela. (La combinaison des barres est également mentionnée ici )

Si un bloc est trop grand, les commandes du bas ne resteront-elles pas bloquées en bas de l'écran, comme la façon dont les commandes du haut restent bloquées vers le haut ou comment cela fonctionne sur mobile?

@hedgefield J'aime beaucoup cela mais cela ne fonctionne pas bien dans des contextes étroits (comme un bloc de colonnes), ou avec de longues barres d'outils.

@hedgefield @chrisvanpatten Peut-être que les commandes de flèche / points de suspension pourraient se déplacer en dessous (ou au-dessus) des commandes de mise en forme dans le cas de largeurs plus minces?

@karmatosed Je dirais que les commandes peuvent être collantes et rester visibles en bas de l'écran. Cependant, cela provoque le problème des contrôles couvrant la ligne que vous essayez d'écrire dans un paragraphe à chaque fois que vous commencez à écrire (ils seraient probablement masqués pendant la frappe, comme cela fonctionne maintenant). Mais de toute façon, cette solution semble discutable.

Pour en revenir à la maquette de @hedgefield , cependant, cela pourrait permettre aux contrôles d'être collants, tout comme les outils de mise en forme, sans

Il y a aussi le souci d'accessibilité. La maquette de @hedgefield contient

et je ne sais pas si une incohérence entre l'apparence visuelle et l'ordre de la source doit se produire est souhaitable

Ce n'est pas souhaitable à un moment donné, il existe un critère de succès WCAG spécifique pour cela:
https://www.w3.org/TR/WCAG21/#focus -order

Je dirais que les commandes pourraient être collantes et rester visibles en bas de l'écran. Cependant, cela provoque le problème des contrôles couvrant la ligne que vous essayez d'écrire dans un paragraphe à chaque fois que vous commencez à écrire (ils seraient probablement masqués pendant la frappe, comme cela fonctionne maintenant). Mais de toute façon, cette solution semble discutable.

En fait, en y réfléchissant un peu plus, les contrôles ne couvriraient pas la dernière ligne d'un paragraphe à moins que le paragraphe ne soit juste à côté du bas de l'écran, donc # 353 pourrait en faire un non-problème. Et même sans # 353, vous pouvez toujours faire défiler vers le bas (ce que la plupart des gens font de toute façon), et comme mentionné précédemment, les commandes ne s'afficheraient également que lorsque vous déplaciez votre souris. J'ai changé d'avis. Cela pourrait fonctionner!

À quoi cela ressemblerait pour des blocs larges:

À quoi cela ressemblerait pour les blocs minces:

Des blocs encore plus minces (pensez à 8 colonnes ou quelque chose):

Je pense que je commence vraiment à aimer ce design. Pour les blocs plus larges, je ne suis pas sûr que les commandes de déplacement de flèche doivent aller à gauche des commandes de formatage ou à droite, cependant.

Merci pour les explorations, mais combiner tout dans une seule ligne, c'est fusionner différentes actions en un seul endroit. Je ne suis pas sûr que cela ait du sens. Nous avons également la considération de ce qui se passe quand quelqu'un colle une barre d'outils en haut - il choisit de ne pas avoir quelque chose «en place» et maintenant les contrôles le sont. Cela ressemble à une expérience moins que car nous ne pouvons pas avoir de contrôles de blocage dans la barre d'outils - ce serait très étrange à vivre.

cependant, tout combiner en une seule ligne, c'est fusionner différentes actions en un seul endroit.

Jouer l'avocat du diable, n'est-ce pas, par définition, le but d'une barre d'outils?

Pour ajouter davantage, bien que je puisse comprendre l'idée derrière la séparation de certains contrôles, je ne suis pas sûr qu'il y ait un argument suffisamment convaincant pour cela dans ce cas. Une barre d'outils est une barre d'outils; mettre toutes les commandes d'un bloc donné en un seul endroit est logique, plutôt que de trouver des raisons floues pour lesquelles certains outils appartiennent à certains endroits alors que d'autres outils appartiennent à d'autres endroits que les plugins ignoreront inévitablement de toute façon.

@karmatosed Que diriez-vous de séparer les commandes via la couleur?

@SuperGeniusZeb, malheureusement, cela ne résout pas mes autres points non et je ne suis pas sûr que cela fonctionne.

Je pense vraiment que dans ce cas, il s'agit d'essayer d'adapter un design qui est censé fonctionner plutôt que d'obtenir celui qui fonctionnera. Que diriez-vous de prendre du recul et de considérer les autres points que j'ai soulevés?

@chrisvanpatten une barre d'outils n'est pas par définition un endroit pour tout mettre, pour être utile une barre d'outils doit avoir du contexte et de l'ordre. En tant qu'utilisateur, vous devez vous attendre à ce qu'il y ait les bonnes options. Bien que nous puissions débattre de la signification d'un mot singulier pendant un certain temps - c'est amusant de le faire - nous ne pouvons pas perdre de vue le fait que cela combine beaucoup trop de choses à la fois et que cela poserait un problème à plus de gens.

@karmatosed D'accord alors. Revenons à avoir la barre d'outils d'édition en haut:

(Je ne sais pas si cette ligne bleue au-dessus de la barre doit être là ou non.)

Y a-t-il quelque chose qui ne va pas avec cette conception? La barre d'outils d'édition pourrait apparaître après le bloc dans l'ordre source pour l'accessibilité; ce n'est pas l'idéal, mais comme placer la barre d'outils d'édition sous le bloc ne semble pas être une option viable, cela semble être la seule chose que nous pouvons faire.

Aussi, j'avais juste une idée: et si la barre en bas était partiellement transparente en survol? Cela le rendrait-il plus léger?

@SuperGeniusZeb juste pour avoir des vues, puis-je suggérer que nous ayons des

Juste pour obtenir une simulation de l'étape suivante. @SuperGeniusZeb à quoi

Quelques maquettes:

Avec bordure en haut de la barre des contrôles

Sans bordure en haut de la barre des contrôles

Notez que la barre d'outils ne prend pas d'espace en survol, mais qu'elle le fait lorsque le bloc est sélectionné.

En réalisant ces maquettes, j'ai remarqué quelque chose: que faut-il faire dans de telles situations?

Il existe ici un conflit entre l'affichage à la fois de la barre d'outils de mise en forme du bloc sélectionné et des commandes inférieures du bloc survolé. Si la barre d'outils de mise en forme était en bas (ou si les contrôles de bloc étaient tous en haut), ce ne serait pas un problème, mais ici, la combinaison des contrôles indiqués ci-dessous et des contrôles affichés au-dessus des blocs crée un problème.

La meilleure solution à laquelle je puisse penser serait de faire en sorte que le bloc survolé et sa barre d'outils aient un z-index plus élevé et apparaissent au-dessus du bloc ci-dessous et de sa barre d'outils de formatage. Je ne suis cependant pas sûr que ce soit la bonne approche. Voici une maquette de ce à quoi cela ressemblerait:

Et encore une fois, sans la frontière entre la barre inférieure et le contenu du bloc:

Je n'aime pas vraiment l'idée que le bloc survolé chevauche celui sélectionné, mais sinon je ne vois aucun moyen d'utiliser les barres inférieures des blocs survolés directement au-dessus de ceux sélectionnés. Êtes-vous sûr qu'il ne serait pas préférable d'avoir tous les contrôles dans une seule barre en haut ou en bas, au moins sur le bureau? Cela éviterait certainement des problèmes comme celui-ci.

@SuperGeniusZeb J'avais en quelque sorte manqué ces maquettes. Merci de les faire!

C'est un très bon point auquel je n'avais pas pensé (survoler le bloc au-dessus du bloc sélectionné). C'est définitivement un problème. En tant qu'expert en création de pages résident, existe-t-il d'autres modèles similaires dans d'autres constructeurs de pages, avec des barres d'outils en couches comme celle-ci?

Aussi, pour ce que ça vaut, je pense que les barres d'outils devraient toujours être survolées, sélectionnées ou non. Le fait de prendre _parfois_ de l'espace conduira à un contenu instable qui est une expérience plus gênante dans l'ensemble.

@chrisvanpatten Tous les constructeurs de pages que j'ai vus n'ont que des contrôles (sauf peut-être un inséreur frère) affichés en haut d'un module / widget. Divi est l'un des meilleurs exemples, à mon avis:

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

Non montré dans la vidéo, la barre d'outils de mise en forme dans Divi apparaît lorsque vous cliquez sur le texte dans un module, et apparaît dans une petite fenêtre contextuelle au-dessus de la ligne que vous écrivez.

Elementor fait presque la même chose.

Dans Beaver Builder, cliquer sur le texte d'un widget entraînera le remplacement de la barre d'outils des contrôles de bloc par la barre d'outils de mise en forme jusqu'à ce que votre souris se déplace en dehors des bordures du widget, ce qui fera apparaître les contrôles de bloc standard lors du prochain survol du widget. , bien que vous puissiez toujours taper le widget. En cliquant à nouveau sur le texte, la barre d'outils de mise en forme remplacera à nouveau la barre d'outils standard.

Aussi, pour ce que ça vaut, je pense que les barres d'outils devraient toujours être survolées, sélectionnées ou non. Le fait de prendre parfois de la place conduira à un contenu instable, ce qui est globalement une expérience plus délicate.

C'est vrai, mais je m'inquiète des implications que cela a pour avoir une interface utilisateur propre. Si la barre d'outils de mise en forme chevauche une partie du contenu ci-dessus, tout va bien. Mais si vous ajoutez une barre pleine largeur au bas du bloc, vous chevauchez maintenant beaucoup d'autres contenus.

Idéalement, vous voudriez que toutes les commandes se trouvent en haut ou en bas du bloc. Cela empêcherait les barres d'outils de se chevaucher dans la plupart des cas. Par souci d'accessibilité, placer les commandes en bas serait idéal. Cependant, vous pouvez rencontrer des problèmes où les barres d'outils chevauchent le contenu que vous écrivez dans quelque chose comme un bloc de paragraphe. Il convient de noter, cependant, que seule la barre d'outils de mise en forme est vraiment nécessaire pour être visible à tout moment, car les flèches et les points de suspension ne sont pas quelque chose qui serait utilisé presque aussi souvent. De plus, si la partie du contenu d'un bloc en cours de modification est suffisamment éloignée du bas de l'écran, la barre d'outils de mise en forme n'aura pas à la chevaucher.

Si placer les commandes en bas semble trop gênant, alors il semble que la meilleure option suivante consiste à tous les placer en haut. Bien sûr, il y a le problème potentiel des commandes qui semblent gênantes pour les blocs minces.

Dans le cas d'un ordinateur de bureau ou d'un mobile, vous pouvez généralement changer la position des barres d'outils. À l'heure actuelle, la barre d'outils de mise en forme et les autres commandes sont toutes affichées sous le bloc actuellement sélectionné et occupent de l'espace sur le mobile.

Dans les cas de blocs larges par rapport à des blocs minces, cependant, déplacer des commandes pour les blocs plus minces peut sembler gênant. L'aspect le plus cohérent peut être d'avoir la barre d'outils de mise en forme en haut et les autres contrôles en bas. Mais cela nous ramène à la question du chevauchement des barres d'outils et de l'augmentation du chevauchement de contenu.

Gutenberg est conçu autour de l'idée que l'apparence du bloc sélectionné est optimisée pour l'édition, donc je pense que le fait d'avoir des barres d'outils occupant de l'espace physique n'est pas si mal, à condition que vous sélectionniez le bloc pour déplacer uniquement les éléments autour du bloc et ne pas bouger. le bloc sélectionné lui-même.

En fin de compte, j'ai l'impression que ces maquettes sont toujours une très bonne option. Ce n'est pas parfait, mais cela a du sens du point de vue de l'accessibilité, cela n'a pas l'air trop gênant, cela est cohérent avec le mobile et cela devrait rarement entraîner le chevauchement des barres d'outils.

Quelques notes sur la façon dont cela fonctionnerait:

Les commandes n'occupent aucun espace en survol, mais prennent de la place lorsque le bloc est sélectionné. Lors du survol d'un bloc, seuls les éléments de déplacement de flèche et les points de suspension sont affichés, mais la sélection du bloc fait apparaître la barre d'outils de mise en forme, ce qui pousse les autres contrôles vers le bas. C'est probablement le plus gros problème avec cette conception. Je pense que pour que cela fonctionne mieux, vous voudriez que le contenu du bloc soit poussé vers le haut lors de la sélection d'un bloc en cliquant sur la barre d'outils Déplacements / Points de suspension, mais vous voudriez que les barres d'outils se déplacent si vous avez sélectionné le bloc en cliquant sur la zone de contenu.

Lorsqu'un bloc s'étend sous la zone de contenu, les flèches et les points de suspension seront hors écran, mais la barre d'outils de mise en forme restera visible, étant collée au bas de l'écran (ou dans la zone de l'éditeur de contenu).

Si ce n'est pas la meilleure solution, je choisirais essentiellement la même chose, mais avec les contrôles tous en haut, avec les éléments de déplacement / points de suspension apparaissant au-dessus de la barre d'outils de formatage pour les blocs minces, et peut-être à gauche des contrôles de formatage pour blocs larges. Mobile pourrait toujours ressembler à ce qu'il fait maintenant.

Une autre pensée: vous pouvez vous débarrasser à la fois du problème des commandes de changement de vitesse et des barres d'outils qui se chevauchent si vous n'affichez simplement aucun contrôle au survol. Cela rendrait l'affichage des barres d'outils en haut et en bas des blocs beaucoup moins problématique. Mais bien sûr, vous perdez les avantages d'avoir des commandes affichées en survol. Je ne sais pas vraiment si c'est dans cette direction que quiconque veut aller, mais je commence à me demander si c'est nécessaire.

Je dois dire que l'idée du chevauchement des blocs survolés ne me plaît pas non plus. Cela nécessite un peu plus de réflexion, je pense. L'idée de commandes occupant un espace différent potentiellement en vol stationnaire semble un peu gênante.

Les commandes n'occupent aucun espace en survol, mais prennent de la place lorsque le bloc est sélectionné. Lors du survol d'un bloc, seuls les éléments de déplacement de flèche et les points de suspension sont affichés, mais la sélection du bloc fait apparaître la barre d'outils de mise en forme, ce qui pousse les autres contrôles vers le bas. C'est probablement le plus gros problème avec cette conception.

Je pense que c'est un gros problème avec les simulacres. Que pourrait-il arriver d'autre?

Alors que regarder les constructeurs de pages est un aspect, qu'en est-il des autres applications et produits? Est-ce résolu ailleurs?

@karmatosed

Alors que regarder les constructeurs de pages est un aspect, qu'en est-il des autres applications et produits? Est-ce résolu ailleurs?

Essayer de trouver des exemples analogues d'interface utilisateur que Gutenberg pourrait utiliser est difficile, car presque rien ne doit rendre compte de tout ce que fait Gutenberg.

De nombreux plugins de création de pages plus simples / plus anciens n'ont pas à se soucier de couvrir le contenu de leur équivalent d'un bloc, car toute l'édition de contenu est effectuée dans une barre modale ou latérale. Cela les libère pour permettre à leurs commandes de module de chevaucher le contenu.

Même dans des cas comme Divi ou Beaver Builder, où vous pouvez éditer le texte sans ouvrir une barre modale / latérale, la barre modale / latérale reste le principal moyen d'édition. Divi et Beaver Builder montrent tous deux ce qui est essentiellement une réplique parfaite du front-end, sans avoir à s'inquiéter d'avoir à optimiser pour des choses comme les utiliser comme éditeur de texte ou s'assurer que la majorité du contenu du bloc majeur peut être édité en ligne à le bloc.

De plus, tant dans les générateurs de pages que dans d'autres interfaces utilisateur de création, l'imbrication a tendance à être beaucoup moins problématique en raison des restrictions sur ce qui peut être imbriqué. Divi a une section stricte → Ligne (avec des colonnes intégrées) → Configuration du module (bien qu'avec certaines sections spécialisées conçues pour certaines situations de colonnes imbriquées courantes). Beaver Builder autorise uniquement les colonnes à être imbriquées dans des colonnes, tout comme Elementor. Ils contrôlent le seul type d'objet pouvant avoir plusieurs couches d'imbrication. Tout est dans une section avec une seule ligne par défaut. Il n'y a pas de couches illimitées de blocs imbriqués avec un potentiel pour toute combinaison de blocs personnalisés qui utilisent l'imbrication à des fins diverses et dans divers styles comme ce que Gutenberg permet.

Divi peut coder en couleur ses contrôles pour les sections, les lignes et les modules car il a une structure stricte et il ne peut y avoir aucun module personnalisé qui agit sur une section ou une ligne. (Cela lui permet également d'afficher plusieurs boutons d'insertion sur la même ligne, mais avec des couleurs différentes pour distinguer ce que chacun fera.) Dans la majorité des constructeurs, les modules sont séparés des éléments de mise en page. Beaver Builder peut faire des choses similaires en raison de la séparation des modules et des éléments de mise en page.

Si vous regardez des choses qui ne sont pas des constructeurs de pages, comme des éditeurs de texte, vous pouvez voir que ceux-ci n'ont pas à se soucier de tout ce que les constructeurs de pages doivent gérer. Si vous regardez la plupart des constructeurs de pages, ils ne gèrent pas les éléments de l'éditeur de texte via des contrôles WYSIWYG en ligne directs.

Ce que Gutenberg essaie de faire est unique. Il essaie d'être un constructeur de page WYSIWYG-sauf-pour-le-bloc-sélectionné-qui-est-optimisé-pour-l'édition qui est également un éditeur de texte complet, et tout, des sections aux colonnes en passant par les widgets, est du même genre d'objet: blocs.

Fondamentalement, c'est un problème compliqué car Gutenberg essaie de faire plusieurs choses différentes en même temps que rien d'autre ne tente apparemment de faire. : stuck_out_tongue:

Quoi qu'il en soit, voici une liste de choses qui pourraient être examinées pour voir comment ils gèrent l'interface utilisateur des blocs / modules / widgets:

Plugins / thèmes WordPress

• Avada (Fusion Builder)
• BeTheme (constructeur de muffins)
• Bâtisseur de castor
• Divi (Divi Builder)
• Elementor
• Oxygène
• Générateur de pages SiteOrigin
• Architecte Thrive
• Compositeur visuel
• X & Pro par Themeco

Créateurs de sites Web en dehors de WordPress

• Drupal
• Squarespace
• Weebly
• Wix

Des choses qui ne sont pas des créateurs de pages mais qui sont un peu similaires

• MailChimp
• Notion

Voilà tout ce que je sais pour le moment.

Il y a un problème avec l'inséreuse frère: il chevauche toujours le contenu du bloc sélectionné. Ce problème s'aggrave encore lorsque vous essayez de vous débarrasser de choses comme les marges automatiques sur chaque bloc pour rendre Gutenberg plus WYSIWYG.

La solution? Eh bien, si nous allons ajouter une barre au bas des blocs, pourquoi ne pas simplement jeter l'inséreuse frère dans cette barre également?

De plus, je viens de trouver un moyen de rendre la bordure de la variante survolée un peu moins choquante. Changez simplement la couleur de la bordure qui sépare le contenu du bloc de la barre inférieure!

Les avantages comprennent:

• L'inséreuse sœur ne chevauche jamais le contenu du bloc sélectionné. Cela signifie qu'il ne devrait plus y avoir d'interface utilisateur qui chevauche le contenu du bloc sélectionné, à l'exception de la barre d'outils de mise en forme collante, qui ne couvre pas le contenu si vous faites simplement défiler vers le haut ou si vous tapez simplement et ne déplacez pas la souris.
• L'inséreuse fraternelle apparaît maintenant dans le même ordre que l'ordre de tabulation HTML, ce qui est bon pour l'accessibilité.
• L'inserteur frère apparaît maintenant sous les blocs au lieu d'en haut. Cela a plus de sens, à mon avis.
• L'inserteur frère est toujours visible pour le bloc sélectionné (sauf peut-être lors de la saisie si les contrôles sont toujours rendus invisibles comme ils le sont maintenant)
• Cohérence avec l'interface utilisateur mobile.
• Toutes les marges et le remplissage interne des blocs pourraient être supprimés, et les bordures de bloc pourraient être modifiées pour redevenir la taille réelle du bloc, le tout sans que l'interface utilisateur du bloc ne gêne le contenu du bloc.

Des points bonus si l'inséreuse sœur est modifiée pour ouvrir directement le menu de l'inséreuse (comme décrit dans # 7271) plutôt que d'insérer un bloc de paragraphe vide.

Bien sûr, la question de savoir ce qui se passe lorsque vous passez le curseur au-dessus de celui sélectionné est toujours un problème. Cependant, je ne pense pas que cela me dérange vraiment beaucoup. Tout ce que vous avez à faire est de cliquer sur le bloc pour le sélectionner et voir les contrôles, et si les contrôles de survol sont affichés sous le bloc actuellement sélectionné, c'est bien puisque le bloc sélectionné est censé être le focus.

Je pense que c'est une bonne conception pour aller de l'avant. Je pense que tous les aspects positifs l'emportent sur les inconvénients, et je pense que c'est certainement mieux que ce qui existe actuellement. Que pensez-vous les gens?

J'ai simulé à quoi cela ressemble si les barres d'outils supérieures et inférieures se chevauchent, et à quoi cela ressemblerait si le bloc survolé prend toujours le z-index le plus élevé sur un bloc sélectionné.

J'aime beaucoup ça, mais il y a un petit problème… les blocs d'une seule ligne n'ont pas de chance, car ils seront presque complètement cachés sous la barre de contrôle inférieure.

@chrisvanpatten Je pensais que la barre du bas prendrait de la place lorsque le bloc est sélectionné. Je pense que cela réglerait le problème des blocs sur une seule ligne. Pourriez-vous faire une maquette pour montrer à quoi cela ressemble? De plus, comment se passe-t-il si le bloc survolé ne chevauche pas le bloc sélectionné?

En outre, il devrait peut-être y avoir une ombre sous la barre inférieure lorsqu'elle chevauche quelque chose.

@SuperGeniusZeb Je m'oppose fermement à ce que la barre inférieure prenne de l'espace - cela conduit à sauter l'interface utilisateur. Les blocs réutilisables le font maintenant lorsque vous les sélectionnez et cela me rend fou.

(EDIT: pour élaborer, cela rend les choses vraiment difficiles pour les utilisateurs de souris, car vous ne pouvez pas vraiment compter sur les choses qui se trouvent au même endroit d'un moment à l'autre. Cela cause beaucoup de gêne.)

@chrisvanpatten

Je pense principalement que dans le contexte de la rédaction de messages, vous ne voudriez probablement pas couvrir le paragraphe sous celui que vous tapez. Pour le moment, il semble que le bloc Paragraphe sous celui sélectionné manque sa première ligne. Je pense que je préférerais que les blocs environnants sautent un peu lorsque vous en sélectionnez un plutôt que de ne pas pouvoir voir le haut du bloc après celui que je suis en train de modifier. Personnellement, le saut ne me dérange pas beaucoup.

Il est assez courant dans Gutenberg que quelque chose change de taille lorsque vous le sélectionnez: les espaces réservés de légende d'image, les espaces réservés de citation de citation, l'espace réservé / inserteur dans la galerie et les blocs réutilisables, comme vous l'avez mentionné. Gutenberg est généralement conçu autour de l'idée que l'apparence d'un bloc doit être optimisée pour être éditée lorsqu'il est sélectionné. Je dirais que cela permet d'augmenter la hauteur du bloc car la barre inférieure prend de l'espace.

Sinon, peut-être que la barre inférieure pourrait être rendue semi-transparente pour indiquer un peu plus clairement qu'il y a un bloc en dessous? Comment ça sonne? Je pense que je pourrais être d'accord avec ça.

Le seul problème est que la transparence n'est utilisée nulle part ailleurs dans l'interface utilisateur de Gutenberg. Cela ne veut pas dire qu'il ne devrait pas être utilisé ... simplement qu'il n'y a pas d'exemples existants, donc nous pourrions introduire une incohérence dans la conception de l'interface utilisateur.

Il y a aussi l'idée de se débarrasser de l'espace vide entre les commandes à gauche et à droite, mais cela a été abattu plus tôt dans le ticket en raison de rendre l'interface utilisateur trop "en bloc".

@chrisvanpatten Cela dit, je pense que je préférerais toujours votre maquette à ce qui existe actuellement . Le problème de la première ligne du bloc suivant semble disparaître est mineur par rapport à toutes les choses que l'une ou l'autre de nos maquettes résoudrait.

@SuperGeniusZeb Je pense que ce qui le rend particulièrement gênant dans ce cas, c'est que les commandes sont là lorsque vous survolez. Avec tous les autres exemples de commandes de saut, au moins elles ne sont pas là lorsque vous survolez, elles ne sont là que lors de la sélection.

Je ne pense pas que cela vaille la peine d'être abandonné à cause des problèmes de survol / sélection / saut / paragraphe sur une seule ligne, mais cela nécessite certainement un peu plus de réflexion.

Je suis toujours convaincu qu'il existe une solution ici quelque part… il suffit de continuer à répéter!

@chrisvanpatten

Je pense que ce qui le rend particulièrement gênant dans ce cas, c'est que les commandes sont là lorsque vous survolez. Avec tous les autres exemples de commandes de saut, au moins elles ne sont pas là lorsque vous survolez, elles ne sont là que lors de la sélection.

Eh bien ... vous ne pourriez avoir aucun contrôle affiché en survol, mais je pense qu'il est prudent de supposer que personne ne le veut vraiment. Je sais que j'aime certainement les commandes disponibles en survol.

Quoi qu'il en soit, qu'en est-il de la transparence?

Et si vous voulez rêver un peu et souhaiter que backdrop-filter soit implémenté dans tous les principaux navigateurs, vous pouvez ajouter un peu de flou:

C'est une opacité de 60%, d'ailleurs.

L'opacité aide certainement, mais je ne suis pas sûr d'introduire de l'opacité dans l'équation. C'est un peu comme tricher.

@chrisvanpatten En effet, on a un peu l'impression de tricher ... mais quelles autres options avons-nous?

Nous ne pouvons pas mettre les contrôles de côté, d'où ce problème existant en premier lieu.

Nous ne pouvons pas mettre les contrôles dans le bloc, car cela couvrirait le contenu.

Nous ne pouvons pas placer les contrôles en haut à cause de la barre de mise en forme déjà présente et des problèmes qui seraient causés pour les blocs minces.

Mettre les commandes en bas a plus de sens car cela fonctionne mieux pour l'accessibilité, fournit un endroit pratique pour insérer à la fois l'inséreuse frère et la poignée de glissement et résoudre les problèmes liés à ceux-ci, est plus cohérent avec le mobile et fonctionne le mieux pour les minces blocs.

Pour réduire l'espace occupé par la barre du bas, il n'y a vraiment que peu de choses que nous pourrions faire:

• Diminuez la hauteur de la barre.
• Supprimez l'espace vide entre l'inséreuse / les éléments de déplacement / la poignée de déplacement et les points de suspension.
• Poussez les points de suspension vers la gauche et supprimez l'espace supplémentaire sur la droite.
• Faites-le prendre de l'espace lorsqu'il est sélectionné. (Mais tu ne veux pas de ça.)

En dehors de cela, tout ce qui peut être fait est de le rendre semi-transparent pour le rendre visuellement plus léger et permettre de voir plus facilement ce qui se trouve en dessous.

Une autre pensée: peut-être que la transparence ne donnerait pas l'impression de tricher si les barres d'outils _both_ étaient transparentes plutôt que simplement celle du bas.

Fait quelques maquettes supplémentaires pour essayer certaines des choses mentionnées ci-dessus.

Barres d'outils transparentes:

Pas de transparence:

Je pense en fait que je préfère cela sans transparence. Qu'est-ce que tu penses? Je pense que réduire la largeur de la barre inférieure a résolu le problème du chevauchement du début du bloc suivant. Bien sûr, cela se produira toujours à des largeurs plus petites ... mais cela se produit déjà avec la barre d'outils de formatage de toute façon, donc je ne pense pas que ce soit vraiment un problème ici.

Notez également que j'ai laissé un peu d'espace pour une poignée de glissement. Il pourrait avoir de petits points grisés qui sont souvent utilisés dans les applications pour représenter les poignées de glissement, ou il pourrait avoir une icône de glissement affichée en survol ou tout le temps. Ou il pourrait simplement rester vide. Il pourrait aussi techniquement être un peu plus fin, mais je l'ai laissé la largeur d'un bouton pour plus de confort.

Serait-ce cela? Serait-ce l'itération assez bonne pour remplacer l'actuelle? _ (Veuillez dire «oui».: Stuck_out_tongue:) _

Merci à tous pour toutes les explorations faites ici. Sauter juste pour ajouter une autre raison pour laquelle la semi-transparence n'est pas idéale: le rapport de contraste des icônes avec l'arrière-plan doit être de 4,5: 1. L'utilisation de la semi-transparence rendrait cela impossible, il suffit de penser à une image avec des couleurs sombres prédominantes, ou un paragraphe avec un arrière-plan sombre, ou un thème avec un arrière-plan sombre:

Merci à tous pour l'excellente discussion ici. Il est réconfortant et ravissant de voir la passion avec laquelle ce défi est relevé.

J'ai regardé un peu de loin, après avoir conçu la configuration initiale du bloc - avec une barre d'outils ancrée, les flèches haut / bas sur le côté, et finalement les points de suspension sur la droite. J'ai donc ajouté les ingrédients parce que je pensais qu'il était très utile de donner aux déménageurs un bien immobilier de premier ordre comme alternative au glisser-déposer qui est souvent fastidieux et sujet aux erreurs, alors que les déménageurs sont toujours prévisibles dans leur comportement.

Je reconnais parfaitement les défis que cela pose pour les blocs imbriqués, et j'ai longtemps réfléchi à la meilleure solution. Ce qui est dans master - superposer gauche et droite même si imbriqué - fonctionne, mais ce n'est pas génial non plus, je le reconnais. Une autre option consiste à utiliser l'interface utilisateur mobile - afficher l'interface utilisateur sous le bloc lorsqu'elle est sélectionnée, qui est en quelque sorte maquillée dans diverses variantes ici, fonctionne, en particulier pour les mobiles. Mais sur le bureau, cela peut devenir très perturbateur et nerveux lorsque vous voulez simplement sélectionner un paragraphe pour faire une petite modification et que tout saute. De même, si la barre d'outils est superposée comme dans la dernière version, on a l'impression qu'elle se penche trop loin de l'expérience d'écriture, dans l'expérience de mise en page. C'est l'équilibre constant que nous avons essayé d'atteindre.

Une deuxième option est de revenir aux anciennes maquettes de waaaay que j'avais, celle-ci:

Peut-être qu'avec quelques ajustements, cela pourrait être ceci:

Mais je n'aime pas ça. Et _soit_ cela rendrait les déplacés visibles uniquement lorsque le bloc est survolé, ou nous voudrions modifier un peu le traitement. Cela réduit également de plusieurs pixels les zones de frappe des boutons, ce qui n'est pas génial pour la convivialité.

En tant que telles, ces variantes n'ont pas été considérées jusqu'à présent car elles ne se sentaient pas supérieures à ce que nous avions. Cependant, poster ici, peu importe au cas où ils pourraient inspirer des traitements pour que cela fonctionne.

Le plus gros problème que je vois avec la combinaison des outils de bloc avec l'étiquette de survol est que cela crée une incohérence entre un bloc sélectionné et un bloc survolé, à moins que vous ne vouliez également commencer à afficher l'étiquette pour les blocs sélectionnés. Et si vous faites cela, alors l'étiquette ne doit pas être dans les limites du bloc, mais plutôt en dehors de celui-ci.

Mais même si vous faites cela, vous rencontrez simplement le problème d'avoir trop de contrôles en haut du bloc et de devoir trouver comment rendre cela cohérent pour les blocs larges et fins.

Je pense fermement que, à l'exception des barres d'outils collantes qui restent à l'écran, aucune des interfaces utilisateur de bloc standard sélectionnées ne devrait couvrir une partie de ce bloc.

Avoir les outils de bloc en bas fournit un bon endroit pour placer l'inséreuse frère, ce qui aide à la fois à atteindre l'objectif de non-chevauchement ci-dessus, tout en rendant l'inséreur frère plus visible et résout ses propres problèmes de chevauchement. (Je pense que la mise à jour des blocs imbriqués vers le bloc Quote ne s'est pas encore produite en raison du chevauchement des inserteurs frères.)

En raison des avantages de l'inséreuse fraternelle et de l'accessibilité, je pense qu'être en dessous du bloc est le meilleur endroit possible pour mettre les outils de bloc.

Maintenant, je ne pensais pas que rendre les commandes beaucoup plus petites était sur la table, car les rendre plus petites peut les rendre plus difficiles à utiliser, bien sûr. Cependant, puisque vous ne semblez pas y être contre, pourquoi ne pas l'essayer?

Comment est-ce?

Les boutons de la barre inférieure (mais pas les icônes) ont été réduits en taille de 38px à 32px, et j'ai corrigé une incohérence dans l'espacement entre les commandes de déplacement des maquettes précédentes. Notez que vous pourriez le rendre un peu plus petit horizontalement si le bouton de sélection était plus fin que les autres (comme celui de la barre supérieure de l'éditeur).

Vous pouvez également réduire la taille de la zone de la poignée de glissement vide pour que la barre occupe encore moins d'espace. Ce serait encore plus viable si toutes les commandes de la barre étaient doublées en poignées de glissement, comme le fonctionnement des barres supérieures des fenêtres dans GNOME.

Notez que sur mobile, les contrôles ressembleraient probablement presque exactement à ce qu'ils font dans master , où les barres prennent de l'espace et donc les agrandir n'est pas un problème. Cette réduction de taille ne devrait affecter que les utilisateurs de bureau et les commandes sont toujours utilisables au toucher à cette taille.

J'ai également fait une petite exploration en déplaçant les contrôles dans une barre d'outils supérieure, ce qui résout un ensemble de problèmes ... mais lorsque vous sélectionnez le bloc, vous êtes de retour à une barre d'outils Tout qui ne fonctionne pas dans des contextes étroits, ce qui était un raison importante de cette exploration en premier lieu.

J'essaie toujours de comprendre ce que je ressens à propos de ces dernières maquettes. Les commandes suspendues au bas me semblent un peu gênantes. Je ne suis pas sûr d'avoir une meilleure idée, c'est juste que cela nous ramène à ce genre de sentiment de bloc / fragmenté que @karmatosed voulait éviter.

Merci à tous pour tout le travail ici. Je vais essayer de donner quelques commentaires, mais je dois dire pour le moment que je ne pense pas que ce soit prêt à passer au prototype. Je pense toujours qu'il y a des problèmes d'imbrication et aussi différents appareils à résoudre, mais comme je l'ai mentionné dans les commentaires précédents, je ne pense pas que la piste actuelle soit correcte. Je pense que nous sommes également en train de retourner sur le territoire que j'ai déjà suggéré d'éviter dans ce domaine.

Je ne veux pas décourager l'exploration, mais pour le moment, je suggérerais d'envisager des suggestions alternatives. Le gros problème est que l'ajout de demi-onglets en bas augmente la densité visuelle sans gain. Pensons à ce que nous essayons de résoudre ici:

• Que se passe-t-il sur différents appareils.
• Insertion fraternelle (bien que cela puisse être résolu dans d'autres problèmes) ou du moins comment il interagit.
• Visibilité d'imbrication et facilité d'interaction.

Le principal moteur de tout cela était la façon dont il réagissait et s'emboîtait.

Considérons ce que nous créons si nous augmentons ou diminuons la convivialité. Par exemple, utiliser des éléments tels que des transparents et des calques alors que cela convient à quelqu'un avec une vision normale, cela ne l'améliore pas pour beaucoup d'autres personnes. Pensez aux mises en page complexes, à celles avec des vidéos et de nombreuses images. Dans cette structure d'information dense, ce qui est suggéré ne tient pas.

Pensez aux mises en page complexes, à celles avec des vidéos et de nombreuses images. Dans cette structure d'information dense, ce qui est suggéré ne tient pas.

Ouais, je pense que c'est le plus gros point, et j'ajouterais cette densité vraiment _compounds_ dans des espaces plus petits, ce qui est une autre partie du défi. Les blocs imbriqués ont généralement besoin des mêmes contrôles que les blocs non imbriqués, mais ils doivent le faire avec une fraction de l'espace, et idéalement d'une manière non unique (par exemple, les blocs imbriqués devraient généralement ressembler à des blocs non imbriqués; la cohérence engendre utilisabilité).

Retour à la planche à dessin… 🙂

Pourquoi je pense que ma maquette est meilleure que l'interface utilisateur actuelle

Je comprends le désir d'éviter un look blocky, mais je n'ai pas encore trouvé quoi que ce soit qui ne soit pas blocky, mais toujours aussi fonctionnel. Le problème est que vous devez connaître les bords du bloc dans lequel vous travaillez et que vous voulez que les commandes ne couvrent pas le contenu du bloc, mais couvrent aussi peu à l'extérieur du bloc. Cela garantit à peu près un look un peu en bloc.

En regardant simplement la capture d'écran en haut de ce numéro, vous pouvez voir comment Gutenberg à un moment donné avait une interface utilisateur très bloc. Mais le problème avec cette interface utilisateur était qu'il était difficile de dire où se trouvaient les bords d'un bloc. C'est pourquoi nous avons l'interface utilisateur que nous avons maintenant.

Et lorsque vous posez les problèmes avec l'inséreuse frère, vous réalisez que vous devez faire en sorte que le bouton d'insertion frère soit en dehors de la bordure de contenu du bloc. Combinez cela avec le fait que vous voulez généralement insérer des blocs après l'actuel (plutôt qu'avant) et aussi le désir d'une accessibilité accrue, et vous finirez par devoir avoir quelque chose comme ma dernière maquette.

Personnellement, je préférerais cette interface utilisateur en bloc à quelque chose qui ressemble aux premières maquettes. Ces premières maquettes semblent déroutantes en raison du manque de frontière entre le contenu et les contrôles, et les barres consomment beaucoup d'espace inutile. Puisque nous ne voulons pas sauter l'interface utilisateur, la barre inférieure doit être une superposition sur le contenu en dehors du bloc sélectionné, et elle doit donc être aussi petite que possible.

De plus, je pense que ma maquette est certainement meilleure dans les contextes imbriqués que celle actuelle. Comme je l'expliquerai ci-dessous, les barres d'outils / situations de contenu qui se chevauchent sont meilleures avec cette interface utilisateur que la précédente. Et dans les contextes imbriqués, vous avez besoin de connaître encore plus les frontières d'un bloc, donc un aspect un peu en bloc aide réellement dans cette situation.

Les barres d'outils qui se chevauchent sont beaucoup moins déroutantes et moins susceptibles de poser un problème, car les blocs sont beaucoup moins susceptibles d'être verticalement petits sur les petits écrans , par rapport à la probabilité qu'ils soient horizontalement petits sur les petits écrans, ce qui a causé des problèmes avec des éléments comme le bloc Colonnes. . Lorsqu'un bloc de texte devient plus mince, son texte s'habille et il devient plus grand.

Dans les contextes imbriqués, survoler le bloc au-dessus du bloc actuel ne couvrira presque jamais tout le contenu du bloc ci-dessous, car soit le bloc sera suffisamment large pour que la barre inférieure ne couvre pas tout, ou bien le bloc serait assez grand et il aurait donc encore de la place pour le sélectionner.

De plus, la barre inférieure d'un bloc ne doit apparaître que lorsque vous survolez le bloc, et pas seulement lorsque votre souris est à proximité. En raison des poignées de glissement étranges et invisibles sur les côtés des blocs, ce n'est pas le cas avec l'interface utilisateur actuelle.

Pour ajouter au point ci-dessus, seul le bloc au-dessus du bloc actuel peut couvrir tout ce qui se trouve dans le bloc sélectionné. Les 3 autres côtés sont tout à fait corrects, car le survol d'un bloc horizontalement adjacent ne couvrira rien dans le bloc actuel, et les blocs survolés n'ont pas d'interface utilisateur au-dessus d'eux, donc le survol du bloc sous celui sélectionné est également très bien.

De plus, vous pouvez simplement choisir de ne pas faire en sorte que les blocs survolés ne couvrent jamais celui actuellement sélectionné, ce qui entraînerait littéralement zéro problème de chevauchement avec le bloc sélectionné dans des contextes imbriqués. Étant donné que les blocs survolés n'ont qu'une barre en bas, celle sous la barre actuelle ne chevaucherait jamais celle sélectionnée. La seule chose à laquelle vous renoncez dans cette situation est la possibilité d'accéder aux outils de blocage pour le bloc au-dessus du bloc actuel, sauf si vous le sélectionnez.

Encore une autre idée: la barre inférieure pourrait être automatiquement masquée lorsque le curseur survole un autre bloc. Il ne reviendrait pas tant que le curseur ne serait pas à nouveau déplacé dans les bordures du bloc. Cela pourrait aider encore plus dans les contextes imbriqués.

En plus de tout cela, si vous voulez toujours moins de problèmes de chevauchement dans des contextes imbriqués, vous pouvez ancrer la barre d'outils de mise en forme à la barre supérieure de l'éditeur. (Cela n'a aucun effet sur le mobile, mais sur le mobile, les barres prennent de l'espace et ne se chevauchent rien, il n'y a donc pas de problèmes de chevauchement en premier lieu.)

Dans l'ensemble, je pense qu'il y a plus de situations améliorées par ma dernière maquette que de situations qui sont aggravées.

Dans l'état actuel des choses, je pense que quelque chose comme ma maquette (ou à proximité) résout beaucoup plus de problèmes qu'il n'en crée. En plus de ce qui précède, les avantages comprennent:

• Fonctionne pour toutes les largeurs de bloc.
• Meilleure accessibilité pour l'inséreuse fraternelle, les commandes de mouvement et les points de suspension.
• Meilleure visibilité et découvrabilité pour l'inséreuse frère et la poignée de glissement.
• Les zones de glissement sur le côté du bloc peuvent être supprimées et l'étiquette de survol n'a pas besoin de devenir une poignée de glissement (elle est de toute façon un peu petite).
• L'inserteur frère se trouve sous les blocs, c'est là que vous souhaitez généralement l'utiliser (par opposition à ci-dessus).
• Pas besoin d'interface utilisateur d'insertion de frères et sœurs séparée, ce qui réduit la complexité
• L'inséreuse fraternelle n'a plus de problèmes de chevauchement dans les contextes imbriqués. (Je pense que c'est la raison pour laquelle # 6520 n'est pas encore arrivé.)
• L'interface utilisateur de bloc entourant un bloc ne chevauche jamais le contenu de ce bloc.
• Les marges automatiques des blocs pourraient être supprimées, et un bloc pourrait ne pas avoir de rembourrage interne, et les bordures de l'interface utilisateur du bloc pourraient être modifiées pour revenir aux bordures de contenu réelles, et pourtant rien dans le contenu du bloc ne serait chevauché par des contrôles. Ces types de cas extrêmes se produiront avec des blocs personnalisés, il est donc bon d'en tenir compte.
• Tous les outils de bloc sont assez proches les uns des autres, ce qui permet de les atteindre tous et de les découvrir tous, par rapport à la situation précédente où les ellipses et les flèches se trouvaient sur des côtés opposés du bloc.
• Le bloc auquel les contrôles sont attachés est très clair, comparé à la confusion que vous obtenez souvent avec les contrôles actuels dans des contextes imbriqués.
• Les contrôles sont plus cohérents avec le mobile.

Alors oui, je pense que ma maquette fonctionne mieux dans des contextes imbriqués, et je pense que l'interface utilisateur en bloc n'est pas importante par rapport à ce que vous gagnez. Qu'est-ce que tu penses? Si vous n'êtes pas d'accord, pourriez-vous signaler des situations dans lesquelles la maquette serait nettement pire que l'interface utilisateur actuelle et aucune des suggestions mentionnées précédemment ne résoudrait le problème?

Il y a ... une autre ... idée de ~ Skywalker ~

Si tout le reste échoue, j'ai une idée qui résoudrait techniquement tous les problèmes majeurs. Et si la barre d'outils de mise en forme était toujours ancrée en haut comme elle l'était dans Gutenberg 1.6, mais cette fois, les commandes de mouvement et les points de suspension seraient affichés au-dessus des blocs plutôt que sur les côtés? (Vous pouvez également les avoir en bas comme ma maquette.)

Dans ce concept, l'inséreuse frère n'existerait pas, car l'inséreuse dans la barre supérieure de l'éditeur aurait la même fonction, et dans ce contexte, elle serait plus proche puisque la barre d'outils de mise en forme serait dans la même zone.

L'interface utilisateur mobile serait exactement la même que celle du moment. Ce changement n'affecterait que les utilisateurs de bureau (et peut-être de tablettes).

Mais attendez, il y a plus!

En fait, si vous y réfléchissez, quelle est la différence entre cette idée et le simple fait d'avoir ma maquette et d'activer Fix Toolbar to Top ? La seule chose que vous gagnez en supprimant entièrement les barres d'outils de mise en forme en ligne du mobile est la possibilité d'afficher les commandes de mouvement et les points de suspension au-dessus des blocs plutôt qu'en dessous. Et techniquement, cela pourrait faire partie de l'option Fix Toolbar to Top .

Comparez à l'interface utilisateur actuelle où Fix Toolbar to Top ne supprime pas tous les problèmes de contrôle qui se chevauchent, car l'interface utilisateur latérale est toujours divisée entre deux côtés et les poignées de glissement invisibles déroutantes sont toujours là, et les inserteurs frères se chevauchent toujours dans des contextes imbriqués, et etc.

Est-il définitivement gravé dans la pierre pour l'avenir que chaque paragraphe de texte soit un bloc séparé? Si tel est le cas, l'affichage des outils de bloc devrait prendre en compte la sélection de plusieurs blocs de texte (ce qui, je crois, arrive à un certain stade).

@padraigobeirn C'est un bon point que j'avais oublié.

Notamment, les contrôles de l'interface utilisateur actuelle ne tiennent pas compte des longues sélections. Les commandes de mouvement et les points de suspension restent en haut à gauche et à droite du premier bloc de la sélection. Même la barre d'outils de mise en forme n'est collante que pour le premier bloc de la sélection. Voir # 7962.

Pour la barre inférieure de mes maquettes, vous pouvez théoriquement la faire fonctionner avec plusieurs sélections en la faisant rester collante au bas de l'écran lorsque vous faites défiler vers le haut. Ce comportement persistant peut cependant être souhaitable uniquement pour le ou les blocs sélectionnés.

Vous savez, je commence vraiment à penser que Fix Toolbar to Top devrait être activé par défaut.

Dans l'état actuel des choses, vous ne pouvez vraiment faire que tant de choses pour adapter autant de contrôles autour d'un bloc, et même avec mes dernières maquettes, il y a encore des cas où l'interface utilisateur pourrait sembler encombrée. Il y a aussi l'inquiétude concernant le sentiment d'interface utilisateur trop bloc.

Pour résoudre ces problèmes, je pense que l'ancrage de la barre d'outils de mise en forme vers le haut devrait être la valeur par défaut. Cela économise de l'espace autour d'une grande partie du bloc et réduit considérablement la quantité de chevauchement possible des commandes.

Je pense que je préfère toujours que les commandes de mouvement et les points de suspension soient en bas, mais ils pourraient également être déplacés vers le haut lorsque la barre d'outils de mise en forme est ancrée. Le fait de ne pas avoir la barre d'outils de mise en forme attachée au bloc permettrait à la barre d'outils de bloc d'être placée en bas à droite ou en haut à droite également, sans avoir l'air gênant ou manger trop d'espace.

Je pense que je préférerais en bas à gauche ou en bas à droite, cependant. De cette façon, les contrôles viennent après le bloc à la fois visuellement et dans l'ordre de tabulation, ce qui me semble le plus logique. Il est plus logique de lancer l'inséreur frère après un bloc que de le faire apparaître avant un bloc.

Note latérale: j'ai récemment remarqué que le générateur d'e-mails d'Infusionsoft a en fait son propre concept de «bloc», et il a des outils de blocage (dupliquer et supprimer) affichés au-dessus des blocs en haut à droite. Les contrôles de mise en forme apparaissent dans une barre en haut de l'éditeur lorsque votre curseur entre dans une zone de texte.

J'ai récemment remarqué que le générateur d'e-mails d'Infusionsoft a en fait son propre concept de «bloc», et il a des outils de blocage (dupliquer et supprimer) affichés au-dessus des blocs en haut à droite. Les contrôles de mise en forme apparaissent dans une barre en haut de l'éditeur lorsque votre curseur entre dans une zone de texte.

Pourriez-vous couper quelques captures d'écran de cette interface @SuperGeniusZeb?

Quand j'ai commencé à utiliser Gutenberg, j'étais définitivement une personne «corriger la barre d'outils vers le haut», mais après l'avoir utilisée pendant un certain temps, je ne suis pas sûr de vouloir revenir en arrière. Je reconnais totalement que la barre d'outils est à bien des égards la cause de tous ces problèmes - c'est le plus susceptible d'avoir beaucoup de choses qui sont coupées dans des contextes imbriqués, et prennent de l'espace que vous pourriez utiliser pour les commandes latérales - mais l'avoir jumelé avec le bloc est tellement gentil. Il garde tout ce dont vous avez besoin au même endroit, évite beaucoup de mouvements oculaires et de souris, etc. Je suis surpris de le dire maintenant, mais je pense que c'est quelque chose que je ne pourrais pas vivre sans.

Pourriez-vous couper quelques captures d'écran de cette interface @SuperGeniusZeb?

@chrisvanpatten Non, je n'y ai eu qu'un accès temporaire en aidant quelqu'un.

Je ne suis pas vraiment convaincu des barres d'outils de mise en forme fixes / non fixes, mais je pencherais vers des barres d'outils fixes, car cela aiderait à réduire l'encombrement visuel autour des blocs. Sur la base des commentaires des utilisateurs, qu'est-ce que les autres préfèrent et pourquoi?

@chrisvanpatten J'ai trouvé un article dans lequel quelqu'un parle du générateur d'e-mails dans Infusionsoft et en a une vidéo:

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpatten Argh, je viens de vérifier et il semble que cette vidéo soit obsolète ... on dirait qu'à l'époque, la barre d'outils de formatage était attachée à des blocs, comme ce que fait Gutenberg en ce moment. Intéressant qu'ils l'aient changé, cependant.

Quelques idées:

Si vous allez insérer un bloc au milieu d'un message, vous voulez généralement le faire _après_ celui que vous avez sélectionné, non? Vous ne souhaitez généralement pas insérer _avant_ le bloc sélectionné. L'insertion après un bloc a également du sens du point de vue de l'accessibilité. Quelqu'un est-il en désaccord avec cela? Pour moi, cela semble être un argument fort en faveur de l'apparition d'inserteurs frères quelque part près du bas d'un bloc.

Les inserteurs frères ne doivent pas chevaucher le contenu du bloc sélectionné. Rien ne doit chevaucher en permanence le contenu du bloc sélectionné. Quelqu'un est-il en désaccord avec cela? Cela m'amène à croire que les inserteurs frères devraient être positionnés en dehors du contenu du bloc sélectionné.

Je le souligne parce que je pense que quel que soit l'endroit où les commandes de mouvement et les points de suspension doivent aller, l'inséreuse frère semble devoir apparaître dans une sorte de barre d'outils sous le bloc sélectionné, même si tout est par lui-même et / ou la barre d'outils a pas de bordure / arrière-plan. Je suppose que cela pourrait ressembler presque exactement à ce qu'il fait maintenant, mais s'est déplacé vers le bas et a changé pour apparaître sous les blocs, plutôt qu'au-dessus d'eux.

Une autre pensée: serait-ce une amélioration par rapport à master de mettre les ellipses du même côté que les flèches de mouvement ou vice-versa? Cela pourrait résoudre de nombreux problèmes liés au chevauchement des contrôles dans des contextes imbriqués, au prix d'une plus grande quantité d'interface utilisateur de bloc sur le côté gauche (ou droit) d'un bloc.

Je viens d'essayer # 8836. Je pense que s'il était fusionné, cela pourrait aider à réduire les problèmes d'interface utilisateur lourds / bloquants que beaucoup de conceptions d'interface utilisateur de ce ticket semblent avoir.

Dans les tickets # 9074 et # 9075, je propose deux petits pas, inspirés de cette discussion, pour atténuer et améliorer la situation. Dans le premier, il est suggéré de déplacer le bouton Ellipse / Plus vers la barre d'outils, de sorte que nous n'avons qu'un seul élément de l'interface utilisateur latérale (déménageurs), et dans l'autre, il y a une proposition de laisser la barre d'outils de bloc réduire les ensembles pour mieux s'intégrer contextes fins.

Juste pour les garder à jour, j'ai mis à jour mes maquettes pour tenir compte des modifications proposées par les tickets de

En fait, déplacer les flèches sous les blocs peut même ne plus être nécessaire si # 9074 et # 9075 sont implémentés. Cela pourrait être très bien s'ils restent sur le côté du bloc, car les ellipses des blocs adjacents ne les chevaucheraient plus dans des éléments comme des colonnes. Si des solutions pour # 8880, # 8881 et # 8883 se produisaient, et si # 8836 et # 8920 étaient implémentées, alors peut-être que l'interface utilisateur conviendrait déjà parfaitement pour les contextes imbriqués. Je commence à me pencher pour que les flèches haut / bas restent sur le côté gauche du bloc.

Cela dit, je pense toujours que l'inséreur frère appartient définitivement au-dessous des blocs , bien que vous puissiez certainement faire apparaître l'inserteur frère seul sous les blocs. Peut-être qu'il pourrait être centré comme l'inserteur frère actuel, mais agir et ressembler aux commandes de mouvement haut / bas, apparaissant comme un bouton flottant sous les blocs lorsque vous survolez la partie inférieure d'un bloc.

Concentrons-nous sur l'obtention des itérations dans lesquelles travaille les # 9074 et # 9075, puis nous pouvons envisager les étapes suivantes. J'ai vraiment envie de changer beaucoup de choses, mais équilibrons-nous.

Grâce aux # 9074 et # 9075 susmentionnés, ainsi qu'à d'autres problèmes et PR comme les # 8920 et # 9197, j'ai décidé que déplacer les flèches sous le bloc n'avait plus de nombreux avantages.

Au lieu de cela, je propose maintenant que seul l'inséreur frère soit déplacé sous le bloc, agissant et apparaissant comme une commande flottante similaire aux mouvements haut / bas. Voir # 9202.

Clôturons celui-ci pour le moment car de nombreuses améliorations ont émergé de cette discussion et d'autres. Les dernières améliorations à apporter concernent l'inséreuse arrière.