На эти концепции в значительной степени влияют:

• Атомные блоки
• WordPress.com
• Библиотека дизайна

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

У нас есть поддержка для этого, но только для каждого типа записи, и шаблон применяется при загрузке со следующей логикой:

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

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

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

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

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

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

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

Из этого плагина тоже есть чему поучиться. https://wordpress.org/plugins/full-site-editing/ @obenland актуален ли сейчас плагин?

В нем отсутствует предварительный просмотр блока, который мы добавляли в последние несколько недель, но в остальном он работает.

Вот как выглядит текущая итерация с использованием blockPreview для большого предварительного просмотра шаблона справа:

@epiqueras написал:

У нас есть поддержка для этого, но только для каждого типа записи, и шаблон применяется при загрузке со следующей логикой:

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

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

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

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

Следующие шаги:

1. @melchoyce, чтобы также
2. Diverge: изучите, что делает wpcom, а также другие примеры из отрасли (например, Squarespace и т. Д.)
3. Конвергенция: объедините сильные паттерны в единый макет и UX-поток.
4. Мокапы и прототипы в Figma.

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

• Расширяйте макеты для работы на страницах, а не только на CPT.
• Создайте для авторов темы возможность «объявить» несколько шаблонов.
• Создайте способ для авторов тем классифицировать эти шаблоны.
• Создайте пользовательский интерфейс для выбора макета.

Рабочий стол

Посмотреть прототип

_Примечание: этот прототип был из предыдущего раунда, который я пробовал, и некоторые элементы устарели.

Мобильный

Посмотреть прототип

Поломка

Средство выбора макета, как и все остальное в Gutenberg, представляет собой блок. Он состоит из пары элементов:

• Название / описание блока.
• Вкладки для категоризации типов макетов (стилизованные после средства вставки блоков).
  
  
  
  • Они определены темой.
  
  
  • Когда у вас всего пара макетов (скажем, <5), вкладки не отображаются.
  
  
  • Если нет макетов по категориям, вкладки не отображаются.
  
  
• Список доступных макетов страниц.
  
  
  
  • Графика компоновки должна создаваться автоматически на основе входящих в нее блоков.
  
  
  • Изображения - это серые прямоугольники, текст - более темные серые линии, кнопки - синие и т. Д. Мы должны абстрагировать все в простые формы.
  
  
• Наконец, сам макет.
  
  
  
  • В этих мокапах вы можете увидеть стили темы, примененные к Гутенбергу. Если стили темы не объявлены, блоки будут возвращаться к общим стилям Гутенберга.
  
  
  • Вы также можете заметить глобальные элементы на странице - в данном случае логотип сайта, навигацию и нижний колонтитул. Они существуют для презентации, но не доступны для редактирования в этой первой версии макетов. Они не редактируются и отображаются с непрозрачностью 40%.
  
  

Изменение макетов

Я проработал то, как может выглядеть поток:

Посмотреть прототип

Поломка

Подождите, у меня может быть несколько макетов страницы?
Ага! Вы можете складывать их и комбинировать, как хотите.

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

Что, если они не хотели перезаписывать свой контент?
Пожалуйста, поддержите "отменить".

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

• Избранные изображения → Изображение
• Заголовок страницы → Заголовок

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

Общие блоки можно дублировать, сколько душе угодно.

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

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

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

Я также твердо убежден, что нам не следует добавлять дополнительную кнопку рядом с библиотекой блоков, потому что:

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

_Как только вы изучите пользовательский интерфейс блока, вы узнаете, как делать все_, это было руководящим принципом с самого начала, и, хотя его все еще нужно усовершенствовать, он относительно хорошо масштабируется. Буквально вчера мы обсуждали, как обработка _сайта_ как блока (# 16998) может быть выгодна, поскольку он повторно использует существующий пользовательский интерфейс. Если вместо того, чтобы рассматривать "шаблон блока" как новую функцию, а вместо этого рассматривать его как _просто другой блок, который случайно является заранее спроектированным и имеет дочерние блоки внутри_, внезапно это не новая функция, это _ уточнение существующей функции_, что кажется одновременно прагматичным и разумным с точки зрения охвата.

Мне кажется, что библиотека блоков является очевидным местом для этого интерфейса. Какие изменения мы можем внести в него, чтобы лучше приспособиться к шаблонам блоков? Он уже содержит блоки многократного использования, возможно, предшественники подобных шаблонов, и любые улучшения, которые мы вносим, ​​вероятно, принесут пользу и им. Есть ли вкладка Block Patterns? Библиотека блоков шире - такая же, как библиотека блоков и новая панель предварительного просмотра вместе? Требуется ли для шаблонов блоков отдельное окно предварительного просмотра, или мы можем использовать дополнительное пространство этой панели?

Еще одно упражнение - перевернуть вопрос с ног на голову: что такого в существующей сегодня библиотеке блоков предполагает, что нам нужен новый пользовательский интерфейс для шаблонов блоков?

Другой интерфейс, и Мэл очень элегантно его затрагивает, - это подключение к интерфейсу заполнителя. Что, если блок Site по умолчанию позволяет выбрать базовый шаблон?

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

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

Спасибо за внимание, @jasmussen! Разобраться в этом вопросе - ключевой момент. Недавно специалисты Happiness Engineers поделились, что некоторые пользователи даже не прокручивают библиотеку блоков, чтобы найти другие блоки за пределами того, что является основным. Это еще одна проблема, но ее следует учитывать при добавлении чего-либо еще в этот очень маленький интерфейс.

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

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

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

Блок-заполнитель (для справки):

Заполнитель блока сайта:

Это действительно смешно с мокапами @melchoyce выше.

Хорошие мысли, спасибо.

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

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

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

Это правда. Я потратил немного времени, чтобы попытаться немного смоделировать на основе этих отзывов, но объединив это с идеей единой библиотеки блоков. Не придавайте слишком большого значения высокому качеству этого мокапа, отчасти это моя зона комфорта, отчасти это способ «почувствовать себя реальным». Так что то, что он выглядит _деланным_, не означает, что его нельзя отклонить на основании дальнейших отзывов:

Здесь вы видите ту же библиотеку единичных блоков, которую вы нажимаете на кнопку (+) Add Block . Это делает его доступным на панели редактора, в конце документа, всякий раз, когда вы создаете новый абзац, или если вы ищете родственного модуля вставки.

Пользовательский интерфейс основан на том, что у нас есть, но добавляет две вкладки в дополнение к полю поиска:

• Вкладка "Блоки" по умолчанию, а содержимое - то, что у нас есть сегодня.
• Закладка Шаблоны блоков находится рядом с ней, и вместо отдельной панели предварительного просмотра на ней отображаются предварительно отрисованные изображения в виде эскизов самих шаблонов блоков.
  
  
  
  • Есть раскрывающееся меню _category_, которое позволяет плагинам классифицировать свои предложения.
  
  
  • Эскизы имеют фиксированную ширину (2 столбца), но разную высоту в стиле кладки.
  
  
  • Все всплывающее окно было увеличено, и, не показывая панель предварительного просмотра, мы получаем еще больше места. Мы даже можем изучить адаптивные трюки, чтобы изменить размер раскрывающегося списка в соответствии с доступной площадью экрана.
  
  
• При поиске вы выполняете поиск как по блокам, так и по шаблонам блоков.
  
  
  
  • Результаты блокировки группируются отдельно и отображаются первыми.
  
  
  • Результаты шаблона блока отображаются ниже
  
  

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

Надеюсь это поможет! Мысли?

Хорошо, поэтому, основываясь на вышеупомянутых исследованиях, я вижу, что мы разбиваем это на две задачи:

1. Предварительный просмотр и выбор макета страницы при создании новой страницы
2. Добавление новых шаблонов блоков впоследствии через устройство вставки

У @jasmussen есть несколько отличных исследований по вставке в https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480, которые мы можем повторить для вставщика.

@shaunandrews также поделился со мной идеей, над которой он работает для WordPress.com:

Когда вы создаете новую страницу, вам будет предложена возможность выбрать макет. Превью - приятное дополнение, которое мы с @mapk еще не использовали.

Один вопрос, который мы должны продумать: должны ли макеты всего страницы выполняться только для страниц, а не для сообщений?

должны ли макеты всего страницы выполняться только для страниц, а не для сообщений?

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

Возможно, шаблон после регистрации сам решает, для каких таксономий он должен быть разрешен?

Возможно, шаблон после регистрации сам решает, для каких таксономий он должен быть разрешен?

Хорошая идея - тогда шаблоны можно было бы также использовать для категорий / тегов и CPT.

(Выбор шаблона на страницах таксономии может быть крутым!)

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

Были опубликованы несколько снимков экрана конструктора сайтов GoDaddy, где аналогичный интерфейс существует и постоянно отображается при выборе. Основное отличие состоит в том, что этот пользовательский интерфейс различает небольшие блоки (текст, изображения) и большие разделы и показывает этот элемент управления только на последнем:

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

@jasmussen Могу я взять ваш файл для https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480?

Да, конечно. Я быстро собрал его в беспорядочный файл Figma, поэтому я скопировал его сюда:

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

Благодаря!

Придумывал несколько идей:

Я начал с идеи раскрывающегося списка и попробовал составить единственный список блоков:

Наряду с этим я пробовал использовать как два столбца, так и один столбец для шаблонов, используя эскизы для шаблонов в списке:

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

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

Мне нравится то, что @joen сделал с более интересным расположением паттернов, поэтому я также попробовал сделать быстрый макет с этим:

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

Мне очень понравилось читать этот выпуск, идеи читаются и выглядят великолепно!

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

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

• Части шаблона (например, для внутренней реализации с типом публикации wp_template_part , аналогично тому, как это делает плагин полного редактирования сайта ):
  
  
  
  • Части шаблона должны иметь возможность использоваться в различных местах, и должна быть возможность добавлять их к другому контенту (как обсуждалось здесь ранее).
  
  
• Шаблоны (например, для внутренней реализации с типом записи wp_template , см. # 17513):
  
  
  
  • Шаблоны должны представлять _все_ шаблоны, включая всю семантическую разметку, составляющую HTML-документ. Должны быть некоторые ограничения на то, как они могут быть размещены, например, полные шаблоны не имеют смысла в отдельном контенте публикации, а также не должно быть возможности добавить полный шаблон где-то еще - полный шаблон всегда должен переопределять существующий контент, и их основной вариант использования будет в самом начале создания нового шаблона с помощью Gutenberg (то есть «Выберите отправную точку»).
  
  
  • Хотя нам все еще нужно выяснить, как в целом поощрять (применять?) Твердую семантическую разметку (с помощью вышеупомянутых проблем), я считаю, что мы также должны рассмотреть здесь этот сценарий.
  
  

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

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

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

Быстрое и грязное исследование, взяв идеи @shaunandrews и @jasmussen и применив их к модальному окну вместо всплывающего окна:

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

Средство вставки модального диалога определенно приносит пространство. Это хорошо. Но он также теряет немного визуального контекста того, где находится ваш курсор / где будет вставлен блок или шаблон блока. Кроме того, возникает вопрос о том, станет ли это глобальным поведением для устройства вставки блоков или, например, тем, что вы видите, когда используете устройство для вставки родственных элементов или вариант, подобный «устройству для вставки разделов», предложенному выше. И если мы будем фрагментировать поведение, это хорошо?

Ваше исследование, @melchoyce , действительно помогает! Благодаря! У меня есть пара мыслей по этому поводу.

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

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

Хотя https://github.com/WordPress/gutenberg/issues/17335#issuecomment -539903480 - это не обязательно путь - категории начинают казаться бессмысленными, и многое происходит - я действительно чувствую, что _улучшение блока библиотека для размещения сложных блоков (и избегания модального диалога) - это правильный выбор.

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

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

Мне нравится идея «Узоров блоков» (может быть, ее следует изменить на «Макеты блоков?»), Но мне не нравится добавлять новый блок с помощью диалогового окна - это слишком отвлекает! (Если бы шаблоны блоков были добавлены таким образом, меня бы это устроило.)

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

Он _ мог_ работать внутри устройства для вставки, но мы можем обнаружить, что интерфейс становится более сложным и запутанным - не говоря уже о том, что устройство для вставки довольно мало. Использование крошечных превью узоров может быть не лучшим опытом. Нам нужно иметь возможность отображать более одного шаблона (чтобы предоставить пользователю правильный контекст для выбора), но также сделать предварительный просмотр достаточно большим, чтобы его можно было увидеть.

Возможно, мы немного подправим наши действия.

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

Вот скриншот (_ с фактическим содержанием Гутенберга_) того, как это может выглядеть:

Нужно было подумать, где именно это возьмет верх. Будет ли это между каждым блоком? Я не уверен.

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

Этот шаблон (или, по крайней мере, его части) можно увидеть на сайте GoDaddy Website + Marketing, а также на SquareSpace (и, возможно, где-то еще). Стоит исследовать.

Блок и макет должны быть РАЗНЫМИ.

Макет должен использовать фреймворк css, который он использует.

Примеры компоновки:

• Колонка ряд
• Сетка
• Слайдер
• Контейнер
• Табы, аккордеоны

Блок может находиться внутри макета или нет.

Выкройка может быть раскладкой + блоки?

Вот как это делает приложение Blocs. Он использует гораздо больший инсертер. Просто делюсь дополнительными исследованиями.

Больше смотреть на то, что делают другие.

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

Отличные акции, Марк.

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

А вот снимок того, как SquareSpace имеет отдельное взаимодействие для проектирования моего предыдущего комментария .

И вот продолжение разговора (Slack), который мы обсуждали на вчерашней встрече разработчиков:

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

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

Для меня ключевой вывод от Squarespace GIF заключается в том, что, хотя существует двойственность между двумя библиотеками, она сдерживается _контекстностью_. Интересно, можем ли мы сделать еще лучше, чтобы избежать двух совершенно разных по виду библиотек блоков. Например, когда вы вставляете блок _Navigation Menu_, интуитивно понятно, что библиотека блоков становится инструментом для вставки внутри только _Menu Items_. Есть ли аналогичный способ использования контекста в самом холсте редактирования?

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

Некоторое время у нас был модальный раздел и макет в Atomic Blocks, и я рад поделиться тем, что мы уже испытали с ним.

Чтобы уточнить вопросы @mapk :

1. Да, редактор блоков должен иметь специальный пользовательский интерфейс для работы с шаблонами блоков / разделами / макетами или как вы хотите их называть. Следующим логическим шагом после отдельных блоков является то, как мы объединяем их для создания современных выразительных макетов. Создание стандартизованного пользовательского интерфейса для этого позволит пользователям и разработчикам наслаждаться сплоченным опытом и избежать повторного изобретения колеса миллион раз (что уже началось). Несмотря на то, что у Atomic Blocks и некоторых других уже есть выделенный пользовательский интерфейс, я все же предпочел бы принять для этого стандартный (но расширяемый) пользовательский интерфейс.

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

1. Некоторые из предлагаемых здесь интерфейсов - отличное начало. Мне особенно нравится то , что я вижу из @shaunandrews и @melchoyce здесь . Я разделяю мнение @richtabor о том, что устройство вставки блоков слишком ограничивает возможности, подобные этой, и я думаю, что мы быстро перерастем его. Выразительное построение страницы с помощью блочных шаблонов заслуживает большего, чем интерфейс размером 700 x 430 пикселей.

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

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

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

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

В следующем макете я попытался решить эту проблему:

• Создание единого интерфейса унифицированной библиотеки с вкладками
• Показывать этот интерфейс как всплывающее окно, в полный рост, но не модальное при открытии из панели редактора
• Показывать его как диалоговое окно, по умолчанию на вкладке "Шаблоны" при открытии из родственного модуля вставки

_Обратите внимание, что этот пользовательский интерфейс использует незавершенные концепции пользовательского интерфейса, изучаемые в # 18667._

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

Этот интерфейс также использует предложенные здесь новые фразы категорий.

• Показывать его как диалоговое окно, по умолчанию на вкладке "Шаблоны" при открытии из родственного модуля вставки

Я думаю, мы кое-что нашли!

@jasmussen , будут ли шаблоны отображаться в / или просто в блоках?

Отличный вопрос. Может быть, если отнести к категории отдельно. Но, может быть, для выкроек больше нужен большой превью? «Найдено 2 шаблона» может вызвать диалог?

@jasmussen , будут ли шаблоны отображаться в / или просто в блоках?

Возможно. Хотя без предварительных просмотров, я не уверен, насколько полезно было бы иметь их в / - если только они не были очень однозначно названы (что, я сомневаюсь, будет иметь место, например, «Примерно 1», «Примерно 2») или если пользователи могут называть их так, как они считают нужным (в этом тоже нет 100% уверенности).

Если мы реализуем функцию «избранного», как @mikemcalister упоминал ранее в этой цепочке , возможно, будут отображаться только избранные шаблоны (при условии, что они были четко идентифицированы). И если мы разрешим их, потребуется ли шаблонам соответствующий значок (аналогичный блокам)? Или будет значок "шаблон" по умолчанию для классификации шаблонов блоков?

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

Об иерархии аккордеонов / навигации

Одна проблема, с которой я всегда сталкивался с устройством вставки, - это секции аккордеона (наиболее часто используемые, общие блоки и т. Д.). Первый раздел «Наиболее часто используемые» достаточно ясен, потому что он всегда открыт изначально, но он имеет тенденцию скрывать дополнительные разделы и затруднять поиск, особенно на мобильных устройствах.

Я поклонник того, как левая боковая панель выложена в вашем последнем мокапе, @lumberman. Как вы думаете, имеет ли смысл добавлять разделы в качестве элементов списка в иерархии навигации на левой боковой панели? Другими словами, элементы под Sections будут «Наиболее часто используемые», «Заголовки», «Нижние колонтитулы» и т. Д. (Или как там в конечном итоге будет именоваться группа)? Это могло бы решить проблему "скрытых секций" и потенциально позволить нам по существу устранить необходимость в аккордеонах, но я понимаю, что исторически это большое расхождение с библиотекой блоков, поэтому другим может не понравиться это предложение 😄

В "Избранное"

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

В библиотеке блоков, Overwhelm, IA и т. Д.

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

Стоит взглянуть на подход Mobirise к макетам страниц. Они предоставляют холст слева и ползунок выбора вертикальной панели справа, сегментированный на естественные вертикальные элементы страницы ... несколько вариантов панели для верхней панели, затем верхнего меню, затем основных панелей по бизнес-функциям (в зависимости от темы и тип страницы (например, панель карты, панель людей, если это страница «О нас»), затем нижний колонтитул, затем панель нижнего колонтитула. Вы просто перетаскиваете панели справа налево.

ВНИМАНИЕ: если вы являетесь участником Gutenberg, прочтите условия Mobirise, прежде чем принимать решение о просмотре любых материалов Mobirise ... в их условиях есть неприятный пункт, который касается их продуктов и веб-сайтов:

Вы заявляете и гарантируете, что вы не будете: копировать, изменять, создавать производные работы, адаптировать, реконструировать, эмулировать, переносить на другой сервис, переводить, компилировать, декомпилировать или дизассемблировать Сервисы;

А еще лучше ... вообще не заходите на их сайт.

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

Если вы считаете, что просмотр видео на YouTube не несет риска для ИС Гутенберга, канал Mobirise Youtube находится по адресу https://www.youtube.com/channel/UCt_tncVAetpK5JeM8L-8jyw/featured. Вы можете увидеть построение страницы для конкретной темы, перетащив панели в действии.

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

Как указывает @richtabor , имеет смысл изменить контекст, когда кто-то добавляет блок с панели инструментов, а не шаблон из одноуровневого модуля вставки. Мне нравится, что в модальном окне для шаблонов отведено дополнительное место!

Следующие шаги

1. Термин «готовые блоки» кажется немного неудобным. Можем ли мы попробовать там «блочные шаблоны», или это чувство столь же неловко?
2. Как это выглядит, когда я нажимаю на устройство вставки на верхней панели инструментов, а затем щелкаю вкладку «Шаблон блока»? Всплывающее окно становится модальным? Всплывающее окно меняет размер, но остается в том же положении? Сохраняет ли он тот же размер и положение, а теперь просто показывает закономерности?
3. Как выглядит взаимодействие, если щелкнуть одноуровневое средство вставки внутри редактора, а затем щелкнуть вкладку «Блоки»? Изменится ли модальное окно в размере или положении отсюда или останется модальным?
   
   
   
   1. Создайте прототип, который отвечает на эти вопросы. Я буду рад помочь здесь, если вы можете связать мне файл.
   
   

@lumberman тоже спасибо за ваши макеты! Мне очень нравится, как они используют существующий дизайн устройства для вставки и строят его поверх него. 👍 Есть ли способ уменьшить количество аккордеонов? Такое ощущение, что многие вещи могут открыться. Прямо сейчас юзабилити-тесты показали, что люди не нажимают на уже имеющиеся у нас аккордеоны.

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

Да, давайте обязательно попробуем шаблоны блоков.

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

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

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

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

Как выглядит взаимодействие, если щелкнуть одноуровневое средство вставки внутри редактора, а затем щелкнуть вкладку «Блоки»? Изменится ли модальное окно в размере или положении отсюда или останется модальным?

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

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

Вот файл Figma: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975 - это немного беспорядочно, но вы можете пинговать меня, если вам понадобится помощь.

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

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

** Выше приведен снимок экрана с разрешением 1200 x 800.

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

Это выглядит примерно так:

Когда вы фокусируетесь / наводите курсор на блок, содержимое "полосы" подсказок внизу изменяется соответственно:

В основном я просто перемещаю вещи:

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

Я также пробовал отображать миниатюры меньшего размера, но мне кажется, что превью сложнее читать:

При всем вышесказанном вкладка шаблонов блоков может выглядеть примерно так:

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

Спасибо за работу над этим Энрике!

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

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

Я не согласен с этим. У нас есть хорошие способы перевода модального окна на телефоны (полноэкранные), и мы можем показывать один столбец шаблонов вместо двух и трех.

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

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

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

Энрике, я бы с удовольствием поработал с вами, чтобы привнести некоторые из ваших тонкостей в высокие вертикальные макеты, показанные ранее. Вот файл Figma: https://www.figma.com/file/fnyj380i05vGzuuH60frLQ/G2-Design?node-id=85%3A6975 - в частности, он хорошо работает на настольной точке останова, но мобильные точки останова еще не конкретизированы . Я всегда готов поболтать, если это хоть немного поможет.

привет @jasmussen! 👋

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

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

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

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

Дайте мне знать, что вы думаете.

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

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

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

Спасибо тебе за это! Я позволю другим вмешиваться.

Вот еще пара исследований, повторяющихся на недавних мокапах:

1. Вкладки для блоков и шаблонов блоков + список категорий

2. Вкладки для блоков и шаблонов блоков + раскрывающийся список для категорий

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

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

@jasmussen @mapk @shaunandrews что ты думаешь?

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

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

Хорошо выглядишь @enriquesanchez! Номер 1 тоже чувствует себя правильным.

Несколько мыслей:

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

б. Как следует упорядочить категории? Есть приоритет через тему, потом через плагин? По алфавиту? Или комбинация?

c. Если тема регистрирует шаблоны для разных категорий, отображаются ли шаблоны в категории «Из темы», а также в указанной категории каждого шаблона?

Эхо для комментариев и вопросов Рича, прекрасное резюме. Хорошая работа!

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

б. Как следует упорядочить категории? Есть приоритет через тему, потом через плагин? По алфавиту? Или комбинация?

Вероятно, в итоге получится комбинация нескольких «благословенных» вверху, а затем алфавитная. До момента, когда плагины назовут свои категории __Sweet Blocks или 1. Sweet Blocks . Похоже, что это одна из тех вещей, о которых мы можем рискнуть, слишком много обдумывая _ сейчас_, и, поскольку это легко изменить в будущем, мы могли бы также пойти с самым простым решением и настроить при необходимости.

@richtabor @jasmussen благодарим вас за отличный отзыв.

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

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

б. Как следует упорядочить категории? Есть приоритет через тему, потом через плагин? По алфавиту? Или комбинация?

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

c. Если тема регистрирует шаблоны для разных категорий, отображаются ли шаблоны в категории «Из темы», а также в указанной категории каждого шаблона?

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

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

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

Не продвигать это как "САМОЕ" решение. Я просто подумал, что вы можете найти его полезным в качестве примера, а затем перевести то, что вам в нем нравится / не нравится, в желаемый дизайн.

Просто предложение :-)

Спасибо, что попробовали еще раз, @enriquesanchez!

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

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

«Из темы» кажется немного странным. Может быть, «Шаблоны тем» или просто «Тема» или даже «Тема: [название темы]». Может быть, им стоит сделать ставку наверху? Я не против держать их вместе в категории "тема" И выставлять их также в соответствующих категориях. Может, это станет чем-то вроде «сборника»? https://github.com/WordPress/gutenberg/issues/19873

В макете я заметил, что, хотя вкладка «Шаблоны» выделена, в поле поиска указано, что вы можете искать блоки и шаблоны. Это правильно? Или мне следует ограничиться блокировкой шаблонов на вкладке Pattern?

Вот смесь каркаса, которым поделился Обенланд:
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -536109796

и предложение Энрике по каркасу номер 1:
https://github.com/WordPress/gutenberg/issues/17335#issuecomment -582673937

Вот существующая область блоков плюс дополнительные параметры:

При выборе вкладки Block Variations она может измениться на что-то вроде этого:

Изменить: использование существующего интерфейса, но расширение его для дополнительных опций сохранит последовательность в том, как мы выбираем блоки сегодня. Для выбора блоков все равно нужно перейти в ту же область устройства вставки. Но на этот раз можно также выбрать Блоки (отдельные блоки) -> Варианты блоков (несколько блоков) -> Макеты страниц (шаблоны) -> Разделы сайта (верхний колонтитул, нижний колонтитул и т. Д.).

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

Может быть, это ошибочная надежда, а может, я не понимаю, как работает поисковый ввод.

В макете я заметил, что, хотя вкладка «Шаблоны» выделена, в поле поиска указано, что вы можете искать блоки и шаблоны. Это правильно? Или мне следует ограничиться блокировкой шаблонов на вкладке Pattern?

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

@mapk @shaunandrews Спасибо за отзыв! Не знаю, почему, но где-то по пути я переместил окно поиска, потому что изначально оно у меня было поверх вкладок (см. Https://github.com/WordPress/gutenberg/issues/17335#issuecomment-575835877).

Я согласен с @shaunandrews , я думаю, что ввод для поиска должен быть первым элементом в средстве вставки (как сейчас). Это первое, на что я обращаю внимание после того, как я открываю устройство для вставки, это эффективно и глобально.

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

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

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

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

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

Очевидно, это не идеально.

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

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

Это решение позволяет намного лучше использовать пространство, и мы сохранили несколько вещей, которые мне нравятся:

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

Что вы думаете?

@enriquesanchez Мне нравится это исследование.

1. Избавимся ли мы от превью в таком сценарии? (Я не обязательно против этого, просто любопытно)
2. Что произойдет, если категория будет слишком длинной? (Пример: https://d.pr/i/DSsHTW). Он просто перейдет в новую строку? В этом случае я бы просто убедился, что между категориями больше места, чтобы не было путаницы.
3. Мне нравится непрерывная прокрутка в отличие от аккордеонов.

Хорошо выглядеть. Хотя вопрос. Нужно ли уточнять « Блок » в « Образцах блоков »?

Спасибо за отзывы @jwold и @richtabor 👍

Избавимся ли мы от превью в таком сценарии?

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

Что произойдет, если категория будет слишком длинной?

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

Мне нравится непрерывная прокрутка в отличие от аккордеонов.

🙌

Хотя вопрос. Нужно ли уточнять «Блок» в «Шаблоны блоков»?

@richtabor Хороший вопрос. Итак, вы предлагаете использовать «блоки» и «шаблоны»?

Кстати, я думаю, что Паттерны были переименованы в Вариации.

Кстати, я думаю, что Паттерны были переименованы в Вариации.

Вариации не связаны с шаблонами - это техническая часть строительных блоков и не отображается в пользовательском интерфейсе как термин.

Я исследовал различные варианты библиотеки блоков при вызове из одноуровневого модуля вставки (где-то в середине документа).

1. Поповер

Это очень похоже на то, что у нас есть сейчас, только немного больше:

2. Большой модальный

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

3. Выдвижная панель.

Предложено @mapk. Очень похоже на https://github.com/WordPress/gutenberg/issues/17335#issuecomment -585425675 с точки зрения размера и размещения. Это заставляет меня задуматься, может ли вставка быть шаблоном по умолчанию как для верхней панели инструментов, так и для родственных модулей вставки 🤔

Вот простой прототип Figma, который объединяет все воедино.

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

❗️ _Примечание: вставка блоков и шаблонов еще не доступна в прототипе.

Привет, Энрике @enriquesanchez

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

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

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

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

Чаще всего используется синего цвета. Над ним - еще одна синяя линия, расположенная под полужирным текстом «Блоки» (разум не знает, почему здесь синяя линия, поскольку она так далеко от слова «Блоки», что кажется отдельной. Я знаю, почему логично). Справа узоры блоков не выделены жирным шрифтом и под ним нет линии. Ниже жирным шрифтом выделен наиболее часто используемый текст. Дальше вверху я вижу контур границы поля и текст поиска внутри него и снова могу расслабиться.

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

Привет.

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

Спасибо за отзывы @paaljoachim и @carolinan! 🙏

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

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

2. Большой модальный

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

Для инсертера-брата это кажется наиболее естественным, хотя макет Hi-Fi может помочь нам решить лучше. Возможно, создание основного модального темного фона поможет сосредоточить внимание на модальном окне (на фото ниже).

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

3. Выдвижная панель.

Предложено @mapk. Очень похож на # 17335 (комментарий) по размеру и размещению. Это заставляет меня задуматься, может ли вставка быть шаблоном по умолчанию как для верхней панели инструментов, так и для родственных модулей вставки 🤔

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

Кроме того, это будут не скриншоты, а «примеры», очень похожие на то, как вариации стиля поддерживают примеры - правильно?

Пример примера:

@richtabor Хороший вопрос. Итак, вы предлагаете использовать «блоки» и «шаблоны»?

Я бы так сказал.

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

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

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

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

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

Из того, что я собрал; блочные шаблоны серии блоков, которые являются макетом; но содержимое внутри блоков еще не определено пользователем и что содержимое такое же
и предназначены ли они для замены файлов template.php?
(Сложно, что шаблон в WordPress может представлять почти всю страницу или его можно абстрагировать, чтобы согласовать 3-4 дополнительных файла шаблона (внутренние шаблоны)

Будет ли шаблон блока решать вариант использования типа «Мне нужен блок выноски, который будет состоять из нескольких блоков: заголовок (уровень заголовка которого я смогу настроить на основе семантики)»
блок абзацев и ссылку для регистрации на мероприятие »)?

Предварительный просмотр паттернов

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

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

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

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

привет @mrleemon!

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

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

@enriquesanchez

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

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

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

иметь авторов, которые могут редактировать контент (изображения, видео, текст и т. д.) в макете, но не могут изменять сам макет

Да, было бы здорово иметь возможность блокировать блоки типа макета (группы, столбцы и т. Д.).

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

Это определенно доступно при создании шаблонов. Поскольку это API более низкого уровня, он пока недоступен с уровня создания шаблона.

Вот предложение, основанное на новейшем мокапе от @richtabor Рича.
Большой модальный 2. https://github.com/WordPress/gutenberg/issues/17335#issuecomment -587951100

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

Я продолжил макет Рича и добавил использование и редактирование и значок замка.
Это означает, что пользователь может редактировать узор или повторно используемый блок.
Редактировать нельзя, если шаблон заблокирован администратором.
Пользователь может щелкнуть «Использовать», «Заголовок рисунка» или сам рисунок, чтобы напрямую использовать / вставить в макет. Я также переместил синюю линию подчеркивания ближе к выбранной области.

Альтернатива.
Используйте группу настроек, чтобы создать раскрывающийся список, в котором отображается Редактировать (если объект можно редактировать), затем Импорт и Экспорт и т. Д.

Щелкнув Edit. Сфокусированная область только для редактирования шаблона / многоразового блока.

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