Gutenberg: Улучшение инструментов для выбора дочерних / родительских блоков

Мне нравится идея панировочных сухарей. (На самом деле, я предлагал нечто очень похожее в # 6459 еще в апреле.) Что произойдет с хлебными крошками при включенной унифицированной панели инструментов?

Я также считаю, что идея перехода по ссылкам тоже хороша, и она уже используется на мобильных устройствах, поэтому добавляет последовательности. Однако я не так уверен в идее сквозной передачи; Я предполагаю, что это может вызвать путаницу из-за разного поведения блоков.

Мне нравятся панировочные сухари, но мне также нравится единая панель инструментов. Можем ли мы найти другую позицию для хлебных крошек :)

Также мне лично не нравятся границы вокруг родительского блока. Но если мы их сохраним, то как будем относиться к множественному выбору :). Должны ли мы показывать границы вокруг родительского элемента множества выбранных блоков?

Мне нравится вариант перехода по ссылке. Это потребует некоторой дополнительной работы над блоком 'passthrough' (например, каждый отдельный "столбец" не считается слоем, через который нужно щелкнуть), но я думаю, что это имеет большой смысл.

Что произойдет с хлебными крошками, если включена единая панель инструментов?
Мне нравятся панировочные сухари, но мне также нравится единая панель инструментов. Можем ли мы найти другую позицию для хлебных крошек :)

Хороший вопрос. Быстрый и грязный мокап:

Да, я вижу проблему с дублированием значка для переключателя. Я думаю, хорошо об этом думать. Также обратите внимание, что в этом дизайне отсутствует структура документа, которая заблокирована на # 4287.

Также мне лично не нравятся границы вокруг родительского блока. Но если мы их сохраним, то как будем относиться к множественному выбору :). Должны ли мы показывать границы вокруг родительского элемента множества выбранных блоков?

Я думаю, что важно показать их как указание на то, что внутренние блоки являются частью родительской группы. Они закрепляют внутренние блоки.

Вот как работает множественный выбор:

И вот что происходит, когда вы просто выбираете два дочерних блока:

Другими словами, в мастере у нас уже есть родительская граница, _и_ мы скрываем ее при множественном выборе дочерних блоков. На самом деле, я думаю, что отображение родительской границы всегда, даже при множественном выборе, имеет смысл, когда вы выбираете только дочерние блоки. Но, возможно, нам следует сделать множественный выбор другим, когда блок _parent_ мультивыбран. Поэтому вместо того, чтобы выделять каждый дочерний блок с помощью эффектов аддитивного слоя, мы выделяем только родительский блок. Это сработает?

Мне нравится вариант перехода по ссылке. Это потребует некоторой дополнительной работы над блоком 'passthrough' (например, каждый отдельный "столбец" не считается слоем, через который нужно щелкнуть), но я думаю, что это имеет большой смысл.

Да, прямо сейчас дочерний блок _column_ представляет несколько проблем пользовательского интерфейса. Например, вы не можете вставить перед ним блок, так почему вы можете его выбрать? Однако это чрезвычайно сложная техническая задача, и я понимаю, с какими проблемами она связана. Так что я не утверждаю, что это легко.

Когда я работал над https://github.com/WordPress/gutenberg/pull/9653 , я понял, что навигация по клавишам со стрелками у нас уже есть для навигации по иерархии (используйте клавишу со стрелкой вверх, когда выбран столбец, чтобы выбрать родительский , т.е. блок столбцов) работает очень хорошо. На самом деле настолько хорошо, что, возможно, простого вывода этой функции в виде кнопки «вверх», подобной «перейти в родительскую папку» в проводнике файлов Windows, может быть достаточно вместо полноценных хлебных крошек.

Вот как это могло выглядеть. Верхняя панель инструментов:

Панель инструментов блока:

CC: @youknowriad

Некоторые мысли

Панировочные сухари

Мне нравится решение для хлебных крошек, но оно страдает двусмысленностью, интерфейс только со значками может быть проблематичным, и я могу видеть, как нахожусь на значках, чтобы увидеть, что они собой представляют, или путаю хлебные крошки с панелью инструментов с параметрами, а не с панировочными сухарями.

Так что, возможно, верхняя панель инструментов - не лучшее место для ее отображения, и, возможно, вам помогут некоторые подсказки из хлебных крошек из других источников. Например, панель инструментов иерархии в PHPStorm, которая показывает файл -> класс -> метод / функцию, в которой вы сейчас находитесь, или панель инструментов папки в MacOS Finder и Windows Explorer?

Пролистать

Переход по щелчку был бы скрытым пользовательским интерфейсом, я вижу много недоразумений и путаницы, поскольку люди ожидают выбрать блок изображения только для того, чтобы обнаружить, что выбран содержащий блок столбца. Обычно щелчок по пользовательскому интерфейсу в программном обеспечении Adobe сбивает с толку, поскольку он вводит режимы, и трудно сказать, где вы находитесь и как выйти из него, особенно если есть вложенность. Например, если вы дважды щелкните, чтобы ввести дочерний блок, как вы вернетесь к родительскому блоку и как пользовательский интерфейс покажет, что вы внутри блока?

Существует много исследований и рекомендаций по режимам, и что-то не следует считать хорошим, потому что оно присутствует в Illustrator или Photoshop, нужно гораздо больше поработать над этим, чем просто щелкнуть, прежде чем оно станет подходящим решением.

https://medium.com/interaction-reimagined/dangers-of-modal-user-interfaces-316828de8161

http://www.azarask.in/blog/post/is_visual_feedback_enough_why_modes_kill/

При этом игнорируются все факторы доступности, с которыми это тоже не так.

Кнопка вверх

Идея кнопки вверх хороша. Меня беспокоит то, что это означает, что если вы нажмете на нее, появится кнопка вниз и блок будет двигаться вверх, это неоднозначно и страдает теми же проблемами, что и блок хлебных крошек.

Шаблон многоразовых блоков

Прямо сейчас многоразовые блоки уже имеют шаблон пользовательского интерфейса, который добавляет хром к интерфейсу блока, который не виден во внешнем интерфейсе. Могут ли столбцы делать то же самое?

Или супер-мусорный макет того, что я имею в виду

Таким образом, хром блока столбцов будет тем, что используется для его выбора, и он предоставляет что-то визуальное, на что можно навести мышь.

Один из потенциальных шаблонов UX, который мы могли бы использовать здесь, который соответствовал бы нашей модели панели инструментов, - это кнопка обхода папки OS X: https://cld.wthms.co/avtQLO

Я хотел бы отметить, что, как мне кажется, пользователи ожидают, что смогут выбирать дочерние / родительские блоки визуально с помощью щелчка мышью и выбора, но, очевидно, есть много сложностей в том, чтобы сделать это правильно. Приведенный выше шаблон обхода может быть хорошим первым шагом, и мы могли бы глубже погрузиться в разработку более элегантного решения на этапе 2.

Я _adore_ эту концепцию Alexis, особенно за более сложные блоки, как вы упомянули. Мне это так нравится, что я сразу же побежал с ним и переделал несколько мокапов, чтобы проиллюстрировать вашу идею.

Без выбора:

Блок выбран:

Вложенный блок внутри выделенного:

Откроется всплывающее окно кнопки обхода папки:

☝️ Мне нравится эта концепция, мне кажется, что она объединяет воедино все идеи и отзывы, которыми поделились в этой ветке, создавая _solid_ базовый уровень для повторения. Большое спасибо за такой свежий взгляд!

Мне нравится раскрывающийся список с визуальным деревом, часть меня думает, что просмотр всего документа в этом формате также был бы полезен и даже предоставил бы полезный способ изменить порядок вещей.

Однако при дальнейшем размышлении мне напомнили, что у нас уже есть такой механизм выбора и схема документа на информационной панели:

Это можно улучшить с помощью стиля в вашем макете и служить дополнительным указателем выбора. На данный момент он показывает только заголовки, но версия с полным деревом блоков и индикатором выбора была бы очень полезна.

Меня беспокоит только сам значок панели инструментов. это еще один загадочный значок со стрелкой, и это кнопка, которой нет в Finder в MacOS по умолчанию, если вы не настроите панель инструментов. Для тех из нас, кто не видит значков и не может легко различать значки, это проблематично.

С текстовой меткой все понятнее, но без нее большинство не узнало бы, что она делает, не щелкнув по ней:

Выглядит неплохо :) Можно попробовать немного упростить иконку для лучшей читаемости? Может быть, 3 строки с немного большим интервалом вместо 4?

С текстовой меткой это понятнее, но без нее большинство не узнало бы, что она делает, не щелкнув по ней.

Также будет всплывающая подсказка.

В комментарии re: @tomjn я также думаю, что стоило бы изучить, если бы это можно было интегрировать в общее дерево документа, а не создавать отдельное место. Задача заключается в сохранении простоты и возможности сканирования дерева при одновременном размещении гораздо большего количества уровней. Но, возможно, это станет больше похоже на панель слоев в Sketch или Photoshop (по функциональности, а не по дизайну!), Где это единственный источник истины для всей структуры страницы. Сложно добиться успеха, но, может быть, стоит изучить?

Опять же, вероятно, мы будем работать над этим итерацией, так что какой самый полезный MVP, который может превратиться в нечто более сложное?

Также будет всплывающая подсказка.

Не думаю, что этого достаточно, но я думаю, что это отдельное обсуждение и запрос функции, я открою новый тикет

Можно попробовать немного упростить значок для лучшей читаемости? Может быть, 3 строки с немного большим интервалом вместо 4?

Мне нравится, что:

Однако при дальнейшем размышлении мне напомнили, что у нас уже есть такой механизм выбора и схема документа на информационной панели:

Я также думаю, что стоит изучить, можно ли это интегрировать в общее дерево документа, а не создавать отдельное место.

Думаю, это сработает. Ранее я предлагал, чтобы этот элемент можно было переписать как плагин, чтобы он отображался справа (см. № 4287). Но я фанат переделывать это для дерева документов.

Что касается меток, мне нравятся метки, но возможность закрепить панель инструментов блока наверху должна рассматриваться в этом свете.

Это обсуждение напоминает мне # 9053 (CC: @westonruter) - я думаю, вам может понравиться предложение Алексис, показанное в https://github.com/WordPress/gutenberg/issues/9628#issuecomment -429012989.

Приятно видеть, как это происходит, и спасибо за концепцию @alexislloyd. @jasmussen Мне очень нравятся эти идея, из которой мы можем выполнить итерацию.

так какой самый полезный MVP, который может перерасти в нечто более сложное?

Я бы сказал, что построил это как более простой элемент управления обходом и посмотрел позже, чтобы увидеть, имеет ли смысл комбинировать с полем содержимого документа на основе выбора.

Согласно обсуждению в # 10767, повторное открытие для итерации.

См. Также дополнительные идеи, предложенные в # 11159.

Еще одна идея для упрощения работы со сложными блоками состоит в том, чтобы помнить, что _выбранный блок - это предварительный просмотр_, а _выбранный блок может отображать дополнительные элементы управления редактированием_.

Мы можем использовать эту идею, чтобы упростить выбор элементов блока столбцов. Например, когда выбран блок столбцов или любой его дочерний элемент, заполнение контейнера анимируется, чтобы освободить место для выбора дочерних элементов. Это также сделает доступным боковой пользовательский интерфейс. Мы хотели бы показать границу вокруг родительского блока - блока с расширенным заполнением - например, пунктирной линией.

Кажется, что это было бы относительно тривиально реализовать, если бы мы восстановили класс .is-selected в блоке верхнего уровня, даже когда выбран дочерний элемент. Некоторое время назад мы сделали это, используя опору hasSelectedInnerBlocks.

Вот что мы видим при наведении курсора на ячейку в блоке столбца:

Наведение курсора на ячейку в блоке Медиа и текст.

Виден внутренний блок и внешний блок.
Например, столбец -> абзац. Колонка -> YouTube. Медиа и текст -> YouTube

Было бы хорошо сделать информацию о панировочных сухарях (внутренний и внешний блоки) в информации о наведении курсора. Щелкните столбец, чтобы выбрать родительский элемент, или щелкните абзац, чтобы выбрать дочерний элемент.

Попробовав это прямо сейчас, я заметил одну вещь: самый простой способ выбрать родительский блок столбца - использовать дополнительную невидимую область попадания, которую мы предлагаем справа / слева от родительского блока:

Эта дополнительная область попадания недоступна сверху и снизу блока, что значительно затрудняет выбор этого способа.

Еще одна идея для упрощения работы со сложными блоками - помнить, что невыделенный блок - это предварительный просмотр, а выбранный блок может отображать дополнительные элементы управления редактированием.

Мы можем использовать эту идею, чтобы упростить выбор элементов блока столбцов. Например, когда выбран блок столбцов или любой его дочерний элемент, заполнение контейнера анимируется, чтобы освободить место для выбора дочерних элементов. Это также сделает доступным боковой пользовательский интерфейс. Мы хотели бы показать границу вокруг родительского блока - блока с расширенным заполнением - например, пунктирной линией.

Я не на 100% уверен, что это то, что предлагает @jasmussen выше, но добавление некоторого отступа + визуальный индикатор родительского блока в режиме редактирования может быть здесь большой помощью. Таким образом, есть четкое указание, где вы должны щелкнуть, если хотите выбрать родительский элемент:

Когда кто-то выходит из блока, это дополнительное заполнение может исчезнуть, чтобы показать более точное представление блока.

Эта дополнительная область попадания недоступна сверху и снизу блока, что значительно затрудняет выбор этого способа.

Я мог ПОКАЗАТЬСЯ, что по этой проблеме есть тикет, связанный с тем, как работает устройство для вставки братьев и сестер. Я не могу найти его прямо сейчас, но считаю, что эту проблему нужно исправить. @aduth звони в колокола, могу поклясться, что ты был в комментариях?

Я не на 100% уверен, что это то, что предлагает @jasmussen выше, но добавление некоторого отступа + визуальный индикатор родительского блока в режиме редактирования может быть здесь большой помощью. Таким образом, есть четкое указание, где вы должны щелкнуть, если хотите выбрать родительский элемент:

Это более или менее точно то, что я имел в виду, только более красиво визуализировано, чем я мог.

Вот дополнительный набросок карандашом, чтобы проиллюстрировать, что я имею в виду. Блок столбцов:

По сути, то, что у вас есть, Кьелл - возможно, пунктирная линия немного темнее. Также, в зависимости от того, как будет развиваться блок columns, помните, что есть также блоки _column_. Т.е. в настоящее время иерархия - _Columns → Column → Image_. Мы используем яростное волшебство CSS, чтобы сделать 2-й уровень более или менее невидимым, но если вы хотите выбрать его в будущем, например, чтобы применить к нему класс CSS или любые другие параметры, которые могут нам понадобиться для отдельных столбцов, это стоит учесть.

Блок слайд-шоу:

Для ясности: блок слайд-шоу не планируется. Это чисто набросано, чтобы показать, что режимы предварительного просмотра и редактирования блока могут быть _все_ разными. Переключаться между двумя режимами, просто выбирая и снимая выделение блоков, настолько легко и удивительно без прерывания работы, что мы должны позволить себе опереться на это и творчески использовать возможности.

В случае блока слайд-шоу, почти по определению, контент будет невидимым за пределами экрана / блока. Но этого не должно быть, когда вы его редактируете. Просто выберите блок, чтобы увидеть миниатюры с редактируемыми подписями. Затем снимите выделение с блока, чтобы просмотреть результат.

Я мог ПОКАЗАТЬСЯ, что по этой проблеме есть тикет, связанный с тем, как работает устройство для вставки братьев и сестер. Я не могу найти его прямо сейчас, но считаю, что эту проблему нужно исправить. @aduth звони в колокола, могу поклясться, что ты был в комментариях?

Я думаю, что наиболее близким может быть номер # 8883, # 8881, # 5180?

Хотя дерево документов полезно, оно по-прежнему требует от меня переключения фокуса с того, чем я пытаюсь манипулировать. Мне действительно нужен лучший способ напрямую пролистывать фактические блоки и вложенные блоки. Я думаю, что метод перехода по @jasmussen , заслуживает более подробного изучения.

Вот проблема, с которой я обычно сталкиваюсь:

Как пользователь, я буду бороться с этим хотя бы минуту, прежде чем найду другое решение, расположенное где-нибудь еще на экране. 😉

* _Когда я добавил этот комментарий, появилось множество других комментариев. Возможно, сейчас это не так актуально, но я сохраню его здесь, чтобы задокументировать борьбу.

но добавление некоторого отступа + визуальный индикатор родительского блока в режиме редактирования могло бы здесь помочь. Таким образом, есть четкое указание, где вы должны щелкнуть, если хотите выбрать родительский элемент:

Меня беспокоит это решение, как заполнение работает по отношению к окружающим блокам:

1. Отражается ли отступ в родительском блоке на интерфейсе? Или просто больше отступов в редакторе?

2. Добавляется ли заполнение динамически, когда блок выбран, например?

1. Или, может быть, родительский элемент с дополнениями появляется над окружающими блоками, как это?

Просто пытаюсь углубиться в эту концепцию. Хотелось бы подумать об этом.

Спасибо @aduth , ты заставил меня найти хотя бы билет, который идет в правильном направлении. GIF в # 9229 объясняет проблему: желтая область в этом GIF «зарезервирована» для устройства вставки родственного объекта. Это то, что мешает вам выбрать блок, щелкнув отступ над или под блоком. Это ответ на комментарий @kjellr :

Эта дополнительная область попадания недоступна сверху и снизу блока, что значительно затрудняет выбор этого способа.

Чтобы еще больше уточнить, эта желтая область предназначена только для того, чтобы сделать кнопку устройства для вставки сестры ВИДИМОЙ. Так что все, что нам нужно для перехвата, на самом деле, это действие _hover_. Было бы неплохо, если бы щелчок по-прежнему мог проходить через эту желтую полосу и позволял вам выбрать блок ниже.

Хотя дерево документов полезно, оно по-прежнему требует от меня переключения фокуса с того, чем я пытаюсь манипулировать. Мне действительно нужен лучший способ напрямую пролистывать фактические блоки и вложенные блоки. Я думаю, что метод перехода по @jasmussen , заслуживает более подробного изучения.

Вы можете протестировать это прямо сейчас, даже если текущая реализация немного недоработана.

• Запустите Гутенберг, любую версию.
• Вставьте блок столбцов с содержимым.
• Измените размер окна ниже точки останова 600 пикселей, затем выберите.

Другими словами, это реализовано для мобильных устройств, чтобы упростить выбор родительского блока.

GIF:

Проблема с реализацией прямо сейчас заключается в том, что «состояние» сбрасывается после того, как вы углубитесь до самого глубокого уровня. Итак, это Columns> Column> Paragraph, Columns> Column> Paragraph, даже если вы просто дважды выбираете один и тот же абзац. Очевидное решение этой проблемы - сделать так, чтобы после того, как вы «углубились» до желаемого уровня, вы _ оставались_ на этом уровне, пока снова не отмените выбор блока. То есть Столбцы> Столбец> Абзац, Абзац, Абзац, отменить выбор, перемотать назад и т. Д.

Я также считаю, что для _ некоторых_ блоков этот метод перехода будет критически важен. Тем более, что мы начинаем изучать шаблоны страниц, которые могут включать в себя всевозможный вложенный контент.

Вдохновляющие идеи о том, как может работать переход по клику, когда это потрясающе, также можно попробовать в Keynote. Вставьте несколько фигур, и вы можете щелкнуть их напрямую. Как только вы группируете две фигуры, они становятся новой формой, которую легко перемещать. Но для редактирования содержимого группы нужно дважды щелкнуть мышью.

Чтобы ответить на ваши хорошие вопросы в https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456637172:

Отражается ли отступ в родительском блоке на интерфейсе? Или просто больше отступов в редакторе?

Нет, это дополнение есть только в редакторе и только когда _block выбран_. Это основано на блочном принципе

• невыделенный блок - это предварительный просмотр. Он должен выглядеть максимально приближенно
• выбранный блок - это, по сути, «режим редактирования блока», и в этом состоянии блок может выводить дополнительные элементы управления и даже выглядеть совершенно иначе.

Это то, что я попытался выделить в приведенном выше примере каракули блока слайд-шоу: когда блок слайд-шоу не выбран, это слайд-шоу. Когда он выбран, вы находитесь в _ режиме редактирования слайд-шоу_ и видите сетку эскизов каждого слайда, так что вы можете легко редактировать подписи, переупорядочивать и т. Д.

Добавляется ли заполнение динамически, когда блок выбран, например?

Да, более-менее.

Я думаю, что стоит создать прототип, чтобы лучше объяснить и почувствовать это.

В конечном счете, эта функция, вероятно, должна быть опорой самого блока, которую блок может использовать. Например, цитата с вложенными абзацами, вероятно, не должна использовать этот интерфейс, но при редактировании столбцов он может быть идеальным.

Вот быстрый прототип кода: https://codepen.io/joen/pen/exmMQv?editors=1100

Это немного статично, но, надеюсь, разъясняет суть.

Вот быстрый прототип кода: https://codepen.io/joen/pen/exmMQv?editors=1100

Это немного статично, но, надеюсь, разъясняет суть.

Это действительно помогает донести мысль. Я немного отредактировал, чтобы мы могли видеть, как эти пунктирные границы могут появиться при нажатии:

https://codepen.io/kjellr/pen/jdEJQb?editors=0110

Это прекрасно, спасибо, Кьелл! Именно это я имел в виду. Я считаю, что мы, вероятно, захотим настроить некоторые аспекты реализации и обсудить, как это выглядит, когда непосредственный родитель (единственный столбец) - это тот, который получает заполнение. Но это круто! Я думаю, это может сработать.

Мне действительно это нравится.
Стоит ли переходить к созданию PR для тестирования с большим количеством блоков и контента?
Нужно ли нам определять, на какие блоки это повлияет?

Я тоже копаю.

Мы, вероятно, можем сейчас прототипировать это в блоке Columns, но для того, чтобы он приземлился, нам, вероятно, потребуется, чтобы этот _method_ был универсальным, поэтому другие блоки (как вы говорите) могут использовать это, но также и опору, чтобы блок мог выберите это. Скорее всего, это будет мешать блоку Quote, если он получит вложенные блоки.

@gziolo есть мысли? В частности, о подходе, нарисованном Кьеллом в https://github.com/WordPress/gutenberg/issues/9628#issuecomment -456811415

@gziolo есть мысли? В частности, о подходе, нарисованном Кьеллом в № 9628 (комментарий)

Выглядит отлично. Это позволило бы, наконец, легко выбрать родительский блок при необходимости. Мой единственный вопрос: как бы вы отнеслись к тому, чтобы сделать ширину столбца ближе к исходному размеру за счет уменьшения ширины других столбцов. В настоящий момент все столбцы уменьшаются при выборе одного из них, что может быть неоптимальным при наличии 3+ столбцов. @jasmussen у вас есть еще вопросы, я должен ответить?

Мой единственный вопрос: как бы вы отнеслись к тому, чтобы сделать ширину столбца ближе к исходному размеру за счет уменьшения ширины других столбцов.

Я склонен согласиться с тем, что это то, что мы должны отрегулировать и сбалансировать, возможно, в процессе реализации. Мы также можем рассмотреть возможность увеличения ширины / высоты родительского элемента, чтобы не уменьшать размер дочернего элемента, хотя это, вероятно, технически более сложно.

у вас есть еще вопросы, я должен ответить?

В основном интерфейс, который мы здесь обсуждаем, таков: добавить отступы к родительскому блоку, когда дочерний блок выбран, чтобы упростить выбор . Это хорошо ощущается в прототипе Кьелла для блока Columns. Это, вероятно, будет очень приветствоваться в других блоках, таких как блоки разделов или многих других блоках, где дочерний контент, вероятно, заполнит все доступное пространство внутри. Но, вероятно, это было бы не так хорошо для чего-то вроде блока Quote, который, по общему признанию, еще не использует вложенность, но, вероятно, будет использовать это в будущем.

Так что было бы неплохо построить этот интерфейс выбора родителя таким образом, чтобы он был _генеричным_ для всех блоков, _ выключен по умолчанию_, но что-то, что блок мог бы выбрать для использования опоры.

Есть ли у вас какие-нибудь предложения, как лучше всего подойти к этому?

Все блоки, которые содержат вложенные блоки (на данный момент столбцы, мультимедиа и текст), отображают этот компонент InnerBlocks который отображает класс .editor-inner-blocks :
https://github.com/WordPress/gutenberg/blob/16a718a4bf359c53f0fb9c3626b08e2434a6fd7d/packages/editor/src/components/inner-blocks/index.js#L103
Это может помочь прийти к общему решению, которое будет работать со всеми вложенными блоками. Однако это может быть сложно, поскольку .is-selected применяется к одному из элементов-потомков.

Edit: Если это не работает исключительно с CSS. Мы всегда можем найти способ обновить состояние родителя, чтобы показать там информацию о том, что выбран один из вложенных блоков. @jorgefilipecosta и @aduth могли бы получить больше информации об этом, поскольку они проводили много времени с вложенными блоками :)

Так что было бы неплохо построить этот интерфейс выбора родителя таким образом, чтобы он был универсальным для всех блоков, по умолчанию отключен, но что-то, что блок может выбрать для использования опоры.

Какие блоки вы рассматриваете для этого подхода, которые не используют вложение? Это заставило меня задуматься, почему они вообще не используют вложение? Представьте, что мы конвертируем Gallery в контейнер с вложенными блоками изображений. Мы получили бы это поведение бесплатно, но также и сортировку в качестве бонуса.

Какие блоки вы рассматриваете для этого подхода, которые не используют вложение?

Галерея интересная.

Честно говоря, я в основном думаю о более продвинутых блоках макета, таких как блоки макета сетки, блоки Tabgroup или другие подобные блоки «компоновки страниц». Вероятно, этот интерфейс не следует использовать для всего, что связано с конкретным содержанием.

Честно говоря, я в основном думаю о более продвинутых блоках макета, таких как блоки макета сетки, блоки Tabgroup или другие подобные блоки «компоновки страниц». Вероятно, этот интерфейс не следует использовать для всего, что связано с конкретным содержанием.

Я ожидаю, что все они подходят для категории контейнерных блоков, а это значит, что они должны использовать InnerBlocks качестве детали реализации, следовательно, должны соответствовать этой категории. Мы по-прежнему можем предложить отказ, аналогичный тому, как мы это делаем для других функций, с помощью группы supports в определении блока.

Я ожидаю, что все они подходят под категорию контейнерных блоков, что означает, что они должны использовать InnerBlocks в качестве детали реализации, поэтому должны соответствовать этой категории.

Но не будет ли блок Quote также использовать внутренние блоки, если / когда он получил функции вложения?

Но не будет ли блок Quote также использовать внутренние блоки, если / когда он получил функции вложения?

Да, Цитата, Список, Обложка - раньше считалось, что эти 3 были преобразованы во вложенные блоки.

Одна проблема (которая не должна блокировать эксперименты, но стоит просто отметить!) Заключается в том, что уже есть некоторые проблемы с блоками столбцов с точки зрения того, насколько узкими они могут быть и как это влияет на инструменты режима редактирования. Это предложение фактически сделает столбцы даже _ более узкими_ во время редактирования взаимодействий, что может повторно выявить эти проблемы узости.

Он также продвигается дальше от паритета редактирования / просмотра 1 к 1, что может вызывать или не беспокоить. По общему признанию, я уже делаю что-то подобное (дополнительное заполнение при выборе) для пользовательского блока с помощью InnerBlocks, и это работает хорошо, но означает, что вид редактирования не совсем точен.

Так что было бы неплохо построить этот интерфейс выбора родителя таким образом, чтобы он был универсальным для всех блоков, по умолчанию отключен, но что-то, что блок может выбрать для использования опоры.

Возможность подписаться на что-то подобное было бы здорово при создании блока Jetpack Form.

Он также продвигается дальше от паритета редактирования / просмотра 1 к 1, что может вызывать или не беспокоить.

Я думаю, что это нормально, если есть некоторые изменения между выбранным и невыбранным состояниями , особенно если это улучшает UX ... хотя сейчас это можно оспорить в отношении внутренних блоков.

Также что происходит, когда у меня есть блоки, вложенные в 3 глубины? Распространяется ли параметр заполнения на второй уровень, если второй уровень также является родительским блоком?

@mapk

Также что происходит, когда у меня есть блоки, вложенные в 3 глубины? Распространяется ли параметр заполнения на второй уровень, если второй уровень также является родительским блоком?

Заполнение всех уровней вложенности, на которые влияют, звучит так, как будто это может привести к некоторому значительному увеличению или уменьшению размера при выборе глубоко вложенных блоков, например, абзаца в цитате в столбце в строке в разделе. В идеале, выбор блока не должен кардинально изменять внешний вид всех остальных блоков, поэтому мне кажется достаточно просто изменить интервал между его непосредственным родителем.

Пока вы можете выбрать непосредственного родителя, вы сможете продвигаться вверх по иерархии, поскольку выбор родителя приведет к тому, что его родитель станет легко выбираемым и так далее. Меню блочной навигации можно использовать для более быстрого доступа, и, как некоторые предлагали ранее, его можно превратить в закрепляемую боковую панель, чтобы к ней можно было быстро получить доступ. (См. # 11408 и # 11688.)

Я бы посоветовал в любой момент изменить заполнение ТОЛЬКО на выбранный блок и прямых потомков.

На всякий случай, если это повлияет на эту работу, могу ли я быстро обнаружить, что работа, которую я надеюсь выполнить, чтобы добавить вертикальное выравнивание в блок столбцов, делает _индивидуальные_ столбцы доступными для выбора (ранее их нельзя было выбирать)

https://github.com/WordPress/gutenberg/pull/13899

работа, которую я надеюсь выполнить, чтобы добавить вертикальное выравнивание к блоку столбцов, делает _индивидуальные_ столбцы доступными для выбора (ранее их нельзя было выбирать)

Спасибо, что отметили это здесь. Это еще одна причина, чтобы навести порядок в этом взаимодействии раньше, чем позже.

Просто хотел поделиться тем, что я обсуждал с @jasmussen сегодня, относительно границ блоков.

Это немного встречается в некоторых из вышеперечисленных макетов , но об этом стоит упомянуть явно: в дополнение к добавленным отступам, которые мы обсуждаем здесь, я думаю, что навигация по внутреннему блоку + выбор будет намного проще, если мы будем четко понимать структуру блоки в целом. С этой целью, я думаю, было бы неплохо принять пару уровней иерархии границ. Например:

В этом примере я использую темную рамку для сфокусированного состояния. Если блок является родительским или дочерним блоком, я добавил пунктирную светлую границу (а также некоторые дополнительные отступы) вокруг других связанных элементов. Это помогает пользователям четко визуализировать, где они находятся в иерархии блоков, а также дает им четкое представление о том, где они могут щелкнуть, чтобы выбрать другие вложенные блоки.

@kjellr Мне это очень нравится. Это дает очень четкое представление о структуре.

Однако… Думаю, мы снова столкнемся с проблемой контрастности пунктирной линии. Я не могу сказать с уверенностью, но подозреваю, что введение пунктирной линии означает, что необходимо следовать критериям доступности. И я думаю, что увеличение контрастности, вероятно, вызовет некоторую визуальную тяжесть, которая может свести на нет преимущества ...

Просто немного подумай вслух. Очень нравится внешний вид как дальновидный пользователь, но было бы любопытно услышать приятный отзыв, так как мне это нравится :)

На моем экране я сначала даже не увидел пунктирную линию. Он кажется практически невидимым, если немного наклонить экран.

Нет необходимости сильно снижать контраст, если это сделает его менее доступным. Пока это _маленькая_ зажигалка и используется другой border-style я думаю, он будет работать нормально.

Извините, в моем первоначальном комментарии следовало быть более ясным: я создал этот макет всего за несколько минут, разговаривая с Джоэном. Думаю, я просто случайно выбрал цвет из некоторых оттенков серого, которые были на моем экране в то время. 😄 Точные оттенки не предназначены для передачи окончательного решения, это просто общий подход.

В ответ на опасения по поводу добавления заполнения к родительскому блоку, из-за которого внутренние блоки становятся несовместимыми с внешним интерфейсом (# 14148 # 14169), я разработал другую идею.

Для этого потребуется дополнительная разработка, но это может быть хорошим вариантом.

По сути, при нажатии на родительский блок он расширяется (становится больше обычных блоков), чтобы обеспечить заполнение, необходимое для легкого выбора дочернего / родительского блока. Это сохраняет визуальное соответствие внутренних блоков интерфейсу.

Скринкаст

Прототип InVision

https://wp.invisionapp.com/share/EGQRWRC8MFT

ЗА

1. Внутренние блоки сохраняют правильную ширину.
2. Внутренние блоки визуально соответствуют интерфейсу.
3. Выбранный изменяющийся размер блока - это уже используемый шаблон.

МИНУСЫ

1. Расширение выбора блока (ширины) за пределы обычного выбора блока - это новый шаблон.
2. Я не уверен, как это будет работать, когда блоки установлены на полную ширину.

По сути, при нажатии на родительский блок он расширяется (становится больше обычных блоков), чтобы обеспечить заполнение, необходимое для легкого выбора дочернего / родительского блока. Это сохраняет визуальное соответствие внутренних блоков интерфейсу.

Копай это. Мне бы хотелось, чтобы панель инструментов блока оставалась на одном уровне с левой границей, но это деталь реализации.

Это будет проблемой для небольших экранов, когда он не может стать больше, но это также кажется чем-то решаемым.

Примечательно, что такой подход можно масштабировать до _ любого_ блока, который имеет внутренние блоки, даже до блока Quote, который является настолько базовым текстовым блоком, что выбор должен быть максимально беспрепятственным.

На самом деле, по-настоящему копайся в своей работе, Кьелл - она ​​не только может незримо работать с идеей Марка, но и помогает выделить структуру документа, _ когда она вам нужна_, но не прерывать поток, когда вы просто хотите писать. Это похоже на твердое направление, и в следующем нам нужен сильный разработчик.

На заметку о реализации - пунктирный родительский элемент _ теоретически может_ иметь тот же цвет, что и выбранный блок, но в силу того, что он штриховой, он все еще будет казаться второстепенным. При наведении курсора на родительский элемент контур может стать сплошным, и мы можем даже сделать _child_ (то, что вы выбрали при наведении курсора) пунктирной линией, чтобы показать, что вот-вот произойдет при нажатии.

На заметку о реализации - пунктирный родительский элемент _ теоретически может_ иметь тот же цвет, что и выбранный блок, но в силу того, что он штриховой, он все еще будет казаться второстепенным. При наведении курсора на родительский элемент контур может стать сплошным, и мы можем даже сделать _child_ (то, что вы выбрали при наведении курсора) пунктирной линией, чтобы показать, что вот-вот произойдет при нажатии.

Да! Я думаю, что это тоже может сработать. Давайте посмотрим, где находится # 14145, а затем разберемся с лечением оттуда. 👍

Я также возился с границами, когда делал отдельные столбцы доступными для выбора, но удалял их как вне рамок моего PR. Определенно чувствовал себя как улучшение UX. Любить путь, который идет!

Просто предупреждаю: я превращаю вышеприведенную идею в отдельную лаконичную задачу для изучения. Следуйте здесь:

https://github.com/WordPress/gutenberg/issues/14935

Если кто-то может вмешаться, чтобы добавить класс has-child-selected к родительским блокам, когда их дочерний элемент выбран, это единственный блокировщик для начала.

Связанная проблема, которую я обнаружил при тестировании недавно представленного группового блока:

На данный момент сбивает с толку то, что когда вы вставляете блок Group, вы фактически видите блок Paragraph:

Можем ли мы хотя бы сделать что-нибудь вроде:

или то, что @mtias предложил в нашем приватном чате повторно использовать функции блочной навигации:

_Это ни в коем случае не окончательные предложения по дизайну 😃_

@gziolo, эта проблема должна быть решена с помощью # 14241. Я согласен с вами, кстати, так что было бы здорово скоро отправить его :)

@gziolo, эта проблема должна быть решена с помощью # 14241. Я согласен с вами, кстати, так что было бы здорово скоро отправить его :)

Ну, я бы сказал частично. Когда вы вставляете абзац с помощью этого нового специального средства вставки, мы возвращаемся к исходной точке 🤷‍♂️

Думаю, здесь поможет и # 14935. Мы также должны изучить некоторые параметры на боковой панели, чтобы иметь больше способов гарантировать, что текущий выбранный блок является вложенным.

О да. Я думал о том, чтобы воскресить хлебные крошки на боковой панели, как здесь:

https://github.com/WordPress/gutenberg/issues/13309#issuecomment -458452168

Простой и относительно элегантный, он также поможет в решении этой проблемы (9628).

Отбрасываем итерацию некоторых из приведенных выше идей:

Что, если бы мы переместили преобразования / стили блоков в отдельный элемент, а иконку блока сделали отдельной панелью «Дерево блоков»?

Я думаю, что это может улучшить видимость преобразований / стилей блоков, а также поможет людям более четко переходить к другим вложенным блокам. Вот макет более сложного примера:

(Обе композиции также используют контуры / отступы из # 14961)

Выглядит очень интересно, Кьелл! Затем он будет связан с областью блочной навигации, создавая согласованность между ними. По мере того, как человек учится использовать навигацию по блокам, такое же обучение может продолжать выбирать вложенные блоки.

Мне очень нравится макет на концептуальном уровне, но что-то в его исполнении кажется немного скучным. Не знаю, обязательно ли у меня есть идея получше, но мне интересно, есть ли способ сделать это немного легче?

Я знаю, что изо всех сил пытался найти краткое описание моей блочной структуры, поэтому эта концепция - отличная идея для решения этой проблемы.

Моя забота здесь имитирует беспокойство @chrisvanpatten . Хотя это хорошо продумано, кажется, что это много.

1. В некоторых блоках в определенных контекстах существуют различные способы отображения раскрывающихся списков.

Я думаю, что добавление еще одного шеврона (хотя он серый и направо) может усложнить синтаксический анализ.

1. Другая проблема заключается в том, что панель инструментов становится длиннее. Возможно, это не имеет большого значения, но это может быть, когда мы добавляем метки для значков https://github.com/WordPress/gutenberg/issues/10524 и https://github.com/WordPress/gutenberg/issues/ 15311.

Просто некоторые мысли, над которыми стоит задуматься, исследуя это. Это может быть самый простой способ сообщить, что происходит.

Интересно, есть ли способ сделать это немного легче?

Да, я думаю, это как-то связано с отсутствием иерархии. Первый элемент панели инструментов должен быть больше похож на заземляющий элемент, а остальные - как второстепенные опции для блока. Требуется какое-то разделение. Это неправильное решение, но я думаю, что это немного помогает в разговоре:

В некоторых блоках в определенных контекстах существуют различные способы отображения раскрывающихся списков. Я думаю, что добавление еще одного шеврона (хотя он серый и направо) может усложнить синтаксический анализ.

Может быть. Вероятно, есть другой способ представить это, о котором я тоже не думаю. Честно говоря, это может быть даже более простой значок «дерево блоков» на панели инструментов, автоматически добавляемый для любых родительских или дочерних элементов:

Другая проблема заключается в том, что панель инструментов становится длиннее. Может быть, это не имеет большого значения, но может быть, если мы добавим ярлыки для значков # 10524 и # 15311.

Согласовано. Независимо от того, будет ли это направление, нам в любом случае нужно будет найти решение для очень длинных панелей инструментов. Я думаю, что такие усилия, как https://github.com/WordPress/gutenberg/pull/16557, немного помогут в этом, как и более полное переосмысление иерархии панели инструментов, например https://github.com/WordPress/gutenberg/issues/ 15096.

Одна вещь, которая поражает меня в идее дерева блоков в качестве кнопки панели инструментов, заключается в том, что оно в некотором роде уникально тем, что является элементом панели инструментов блока, который не имеет отношения к чему-либо, присущему самому блоку, а скорее к тому, как блок относится к остальная часть документа.

Это больше похоже на размышления, чем на что-либо другое, но, если использовать аналогию с графическими приложениями, этот тип «многоуровневого» и «группирующего» пользовательского интерфейса обычно (я уверен, что есть примеры, доказывающие мою неправоту) существует только на уровне _document_ вместо того, чтобы быть доступным на уровне блока.

Я знаю, что существуют различные проблемы доступности вокруг «разрыва» между блоком и инструментами на уровне документа, и наличие этого на уровне блока может облегчить навигацию.

Это больше похоже на размышления, чем на что-либо другое ... что-то в этом инструменте заметно отличается от других инструментов, доступных на панели инструментов, с точки зрения того, как он связывает блок с другими контекстами.

Это больше похоже на размышления, чем на что-либо другое ... что-то в этом инструменте заметно отличается от других инструментов, доступных на панели инструментов, с точки зрения того, как он связывает блок с другими контекстами.

Да, у меня такое же чувство.

Прямо сейчас у нас есть этот элемент управления на верхней панели инструментов, которая кажется слишком далекой от самого блока. Может, боковая панель - лучшее место для этого? Кажется, что элемент управления должен быть связан с блоком, но как отдельная панель инструментов, но мы определенно не хотим добавлять еще одну из них. 😄

Прямо сейчас у нас есть этот элемент управления на верхней панели инструментов, которая кажется слишком далекой от самого блока.

Я также добавлю, что это верно только в настройках Гутенберга по умолчанию. Если бы кто-то выбрал параметр «Верхняя панель инструментов», чтобы переместить все панели инструментов блока на верхнюю панель инструментов, это определенно не так. Но при этом я сомневаюсь, что большинство пользователей изменят этот параметр.

С другой стороны, я действительно хотел бы увидеть, как люди отреагируют на настройку верхней панели инструментов, которая является настройкой по умолчанию в Гутенберге. Он лучше согласуется с классическим редактором, обеспечивая более знакомство с новыми пользователями Gutenberg.

Эта настройка панели инструментов была много изучена, и после небольшого тестирования было выбрано лучшее значение по умолчанию. Вы можете узнать больше об исследованиях здесь: https://github.com/WordPress/gutenberg/issues/2983.

Я сомневаюсь, что большинство пользователей меняют этот параметр.

Оказывается, положение панели инструментов - это очень личная настройка. На первом этапе тестирования выяснилось, что те, кто начинает использовать WordPress, предпочитают блок, а те, кто находится на вершине. Панель инструментов работает по умолчанию в обоих местах, и это то, что у нас есть сейчас, - лучшие варианты. Кроме того, вероятно, поэтому он больше похож на классический редактор. Я лично рекомендую не менять значение по умолчанию.

@jasmussen Должны ли мы закрыть это в пользу # 17088

Да, думаю, сможем. Этот билет исследован по-разному, тогда как другой теперь уточняет некоторые идеи. Этот билет все еще можно будет найти, если вы перейдете по ссылке на новом билете Thanks Riad.