Gutenberg: Экран блокировки виджетов в wp-admin

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

Странно иметь возможность редактировать все области виджетов / блоков на одной странице. Я думаю, что этот экран должен работать больше как редактор области виджетов в Настройщике. Примечательно, что одним из преимуществ текущей страницы wp-admin Widgets является то, что вы можете перетаскивать виджет из одной области виджетов в другую. Я не уверен, как бы вы воспроизвели эту функциональность, если бы экран виджетов стал больше похож на настройщик. Возможно, области виджетов будут отображаться в виде вкладок на верхней или боковой панели, и перетаскивание блока по этим вкладкам переключит представление на эту область блока ... вроде как вы можете перетаскивать текст / изображения с одной вкладки на другую в веб-браузере или из одного приложения в другое в большинстве операционных систем.

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

Кроме того, выбор блока слева кажется немного странным. Я думаю, что он должен измениться, чтобы он стал сочетанием средства вставки блоков в редакторе сообщений и средства вставки виджетов Customizer. Кстати говоря, это похоже на хорошую возможность добавить вставку с перетаскиванием в средство вставки блоков. Текущие редакторы области виджетов как в wp-admin и в Настройщике имеют вставку перетаскиванием, а средство вставки блоков в редакторе сообщений в настоящее время этого не делает. См. №1511.

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

В общем, страница виджетов в wp-admin кажется странной, а в текущем макете она кажется еще более странной.

Собираемся ли мы смешивать виджеты и блоки или по сути отказываемся от виджетов?

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

@nicholasio Я думаю, что текущий план «Legacy Widget», который позволит вам встраивать любой старый виджет в блочную область. (Предположительно, вы можете использовать блок «Legacy Widget» где угодно, что означает, что вы действительно можете использовать виджеты в сообщениях и на страницах ... что-то было невозможно раньше.) Большинство, если не все, основные виджеты WordPress будут устаревшими и заменены на новые блочные аналоги.

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

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

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

Кроме того, выбор блока слева кажется немного странным.

Как аккордеон, он, скорее всего, был бы разрушен и не был бы таким подавляющим.

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

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

Кроме того, выбор блока слева кажется немного странным.

Как аккордеон, он, скорее всего, был бы разрушен и не был бы таким подавляющим.

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

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

Я попытался использовать Figma для прототипирования. Вот концепция, которую я собрал. Я хотел посмотреть, есть ли другой способ, которым мы могли бы контекстно отображать «области виджетов» вместо того, чтобы накладывать их друг на друга. Это заменит /widgets.php в файле wp-admin.

Опытный образец

https://www.figma.com/proto/O6SyONtxLjcUxsHq59EfStPs/integration-widgets?node-id=0%3A1&scaling=min-zoom

видео

Мысли?

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

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

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

Предлагаю отказаться от этого предложения и закрыть вопрос в пользу №13205.

Было бы сложно разместить все области виджетов на одном экране таким образом, чтобы это имело смысл.

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

Экран администратора виджетов принципиально не связан с тем, как на самом деле работают области виджетов.

Это правда, и причина исследования выше. Я абсолютно согласен!

Предлагаю отказаться от этого предложения и закрыть вопрос в пользу №13205.

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

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

Предлагаю отказаться от этого предложения и закрыть вопрос в пользу №13205.

То же самое, что уже сделано для экрана меню, см. Https://github.com/WordPress/gutenberg/issues/13206#issuecomment -455452477. Настройщик не полностью доступен. Экран виджетов администратора - единственное место, где люди с потребностями в доступности могут управлять виджетами, не сталкиваясь с большими препятствиями доступности.

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

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

Re: выбор блоков слева:

Как аккордеон, он, скорее всего, был бы разрушен и не был бы таким подавляющим.

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

Тем не менее, насколько я понимаю, все основные виджеты будут блоками. Однако что происходит с пользовательскими виджетами, добавленными плагинами и темами? Не все из них сразу будут преобразованы в блоки. Есть ли необходимость в каком-то механизме обратной совместимости, как в случае с мета-блоками? / Cc @youknowriad

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

Идея состоит в том, чтобы создать классический блок виджетов, способный отображать редактирование и предварительный просмотр любого виджета (как сейчас) https://github.com/WordPress/gutenberg/issues/4770

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

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

Идея состоит в том, чтобы создать классический блок виджетов, способный отображать редактирование и предварительный просмотр любого виджета (как сейчас) # 4770

+100
Это как раз то, что нам нужно. Спасибо, что уже об этом думали!

А как насчет того, чтобы поэкспериментировать с различными способами отображения виджетов в разных частях сайта? Я упомянул некоторые варианты использования поиска на https://make.wordpress.org/core/2018/12/08/gutenberg-phase-2/#comment -35058.

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

Странно иметь возможность редактировать все области виджетов / блоков на одной странице.

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

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

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

И не забываем про неактивную область виджетов

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

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

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

Вы правы, @ радостно. Виджеты уже похожи на блоки. Однако их нелегко добавить где-нибудь на странице, особенно в Гутенберге. Преобразование их в блоки решает эту проблему. Виджеты-блоки теперь обрабатываются наравне с другими блоками и могут быть добавлены в любом месте Гутенберга. Экран виджетов в wp-admin меняется, чтобы отразить это и помочь всем понять парадигму блоков.

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

1. Замена слов с «Виджеты» на «Блоки виджетов», чтобы помочь сообщить о смене.
2. Сохраняет функциональность текущего экрана виджетов.
3. Использует блок-вставку Gutenberg в выдувной панели. Я оставил этот белый цвет, чтобы это было очевидное изменение, а также имитировал устройство вставки блоков Гутенберга.
4. Области блоков виджетов по-прежнему отображаются как обычно, но отражают _blocks_ аналогично редактору Гутенберга. По сути, они похожи на мини-гутенберги. 😉
5. Мне не хватает инспектора (боковая панель Гутенберга), который, вероятно, следует продумать подробнее. Если экран виджета будет включать все, что делает Гутенберг для взаимодействия с блоками (панель инструментов, средство вставки, инспектор), возможно, это станет большим экраном Гутенберга, который позволяет все это.

Опытный образец:

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

Видео прототипа:

Доступность

Я хотел бы получить краткий обзор этих мыслей. Удовлетворяет ли устройство вставки блоков Gutenberg каким-либо требованиям? Если да, то работает ли этот прототип по отношению к a11y? Теперь пользователь должен иметь возможность вставлять блок прямо из новой области виджетов.

Зачем смешивать блоки виджетов с блоками ?
Я думаю, их следует разделить ...

Подобно абзацу или заголовку - это не виджеты-блоки ...
Почему бы вместо этого не сделать текстовый редактор или блок виджета Гутенберга, в котором будут все эти блоки внутри ...?

Зачем смешивать блоки виджетов с блоками?

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

Но, возможно, такая формулировка вызовет еще большую путаницу?

Почему бы вместо этого не сделать текстовый редактор или блок виджета редактора Гутенберга, в котором будут все эти блоки внутри ...?

Я не уверен, что следую, но сейчас разрабатывается блок Classic Widget (# 4770), который будет действовать как блок (может быть добавлен в любом месте интерфейса Gutenberg), но будет содержать виджеты, которые еще не преобразованы в блоки.

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

Где неактивные виджеты? Можете ли вы переместить виджет из одной области в другую?

Где описания, которые можно определить для виджетов?

Почему блок переходит в первую область виджетов, когда вы нажимаете на него в левом столбце? Открыты две области виджетов, как узнать, куда они пойдут? + только для блоков ГБ? Или это для всех, что у вас слева?

где кнопка Сохранить? В настоящее время для каждого виджета есть кнопка «Сохранить».

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

Где неактивные виджеты? Можете ли вы переместить виджет из одной области в другую?

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

Где описания, которые можно определить для виджетов?

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

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

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

+ Только для блоков ГБ? Или это для всех, что у вас слева?

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

Надеюсь, это объяснение поможет.

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

Первоначальное описание:

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

Я считаю, что это заблуждение. Во-первых, непонятно, что все выглядит одинаково, когда задачи сильно отличаются. А виджеты - это не то же самое, что редактировать сообщение или страницу. Он должен выглядеть по-другому, больше похоже на то, что уже есть.
Во-вторых, вы не обратились к базовой архитектуре. Если вы хотели изменить способ создания виджетов, вы меняете способ их хранения? Вы меняете то, как они пишутся? Вы меняете способ их вывода?
Основные виджеты уже превратились в блоки. Блоки не обязательно должны становиться виджетами.
Какая здесь настоящая цель? Если вы просто хотите, чтобы страница виджета выглядела как страница редактора, я думаю, что это плохая идея. Если вы хотите что-то переставить, просто чтобы было по-другому, я не думаю, что это хорошее использование ресурсов. Если Фаза 2 действительно больше связана с настройщиком, то, возможно, эту страницу виджетов следует просто оставить в покое, и целью должно быть создание нового интерфейса в настройщике ... но здесь возникают те же вопросы.

Удовлетворяет ли устройство вставки блоков Gutenberg каким-либо требованиям?

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

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

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

Вместо этого на этом экране нет ограничений из-за нехватки места. В частности, в качестве начальных соображений:

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

Кроме того: «Управление с предварительным просмотром в реальном времени» вверху всегда ранило меня может быть, это была бы хорошая возможность переосмыслить это.

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

Опытный образец
https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen?node-id=14%3A297&viewport=-818%2C1575%2C0.5&scaling=min-zoom

Гифка

_ Вот ссылка на Фигма

• Он сохраняет верхнюю панель инструментов и боковую панель Гутенберга, поэтому добавление и редактирование блоков знакомо. Мы также можем включить обычную индикацию автосохранения Гутенберга и т. Д.
• Хотя рамка редактирования очень похожа на Гутенберга, вы редактируете в маленьких контейнерах виджетов, как все привыкли.
• Вместо того, чтобы использовать стандартную кнопку для вставки крошечных блоков, я включил более крупную и более очевидную кнопку [ + Add block ] внутри каждого контейнера (вдохновленный кнопкой Добавить в галереях изображений).
• Он также включает в себя неактивную область виджетов.

@kjellr Я думаю, что этот

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

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

Неактивные блоки по-прежнему могут отображаться внизу, подобно тому, как метабоксы отображаются внизу редактора сообщений. Однако я сомневаюсь в полезности функции неактивных виджетов / блоков в контексте Гутенберга. Система многоразовых блоков уже может действовать как своего рода хранилище для предварительно сконфигурированных блоков, поэтому, возможно, следует пересмотреть всю идею неактивных виджетов.

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

Кроме того, как упоминалось в @afercia , панель поиска в

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

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

Кроме того, как упоминалось в @afercia , панель поиска в

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

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

Тот же вопрос.

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

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

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

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

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

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

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

Несколько ресурсов (за и против):

• https://medium.com/simple-human/floating-labels-are-a-bad-idea-82edb64220f6
• https://medium.com/@mds/are -float-labels-really-that-problematic-after-all-da7ffe7d5417
• https://joshuawinn.com/ux-input-placeholder-are-not-labels/
• https://feedbackguru.com/articles/form-without-labels-dont-use-placeholder-text/

Что касается использования реальных, видимых элементов <label> вместо заполнителей, обратитесь к ресурсам, связанным с соответствующим тикетом Trac https://core.trac.wordpress.org/ticket/40331

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

Действительно любят макеты , @kjellr! Спасибо, что обдумали это.

1. Мне нравится интерфейс Гутенберга, и я готов сделать этот прыжок на этом экране, потому что он включает в себя Инспектор (боковая панель). Это необходимый ход.
2. Хранение областей виджетов, расположенных так же, как они используются сегодня, сохраняет тот уровень осведомленности, который, как я думаю, необходим для существующих пользователей прямо сейчас.
3. Давайте отбросим слово «виджеты» с верхней панели, и, возможно, на данный момент Inspector - это просто инспектор «блоков». Поэтому мы отбрасываем оттуда «области виджетов». На этом этапе мы делаем прочный визуальный переход к блокам.
4. Сохраняет ли навигация wp-admin соглашение об именах "виджетов"? Я склоняюсь к "да" прямо сейчас.
5. Мне нравится вставка блоков. Мое единственное предложение состоит в том, что средство вставки в блоке галереи использует регистр предложений, а не регистр заголовков. Может, этому подражать? «Добавить блок»

@mapk

Давайте отбросим слово «виджеты» с верхней панели, и, возможно, на данный момент Inspector - это просто инспектор «блоков». Поэтому мы отбрасываем оттуда «области виджетов». На этом этапе мы делаем прочный визуальный переход к блокам.

Согласовано.

Сохраняет ли навигация wp-admin соглашение об именах "виджетов"? Я склоняюсь к "да" прямо сейчас.

Я думаю, что в долгосрочной перспективе эту страницу следует переименовать в «Блоки областей» или что-то в этом роде? Возможно, даже сначала назовите это «Блокировать области (виджеты)» в навигации.

Давайте отбросим слово «виджеты» с верхней панели, и, возможно, на данный момент Inspector - это просто инспектор «блоков». Поэтому мы отбрасываем оттуда «области виджетов». На этом этапе мы делаем прочный визуальный переход к блокам.

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

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

Ага. Обновлен в файле / прототипе Фигмы. 👍

Он сохраняет верхнюю панель инструментов и боковую панель Гутенберга.

Как указано в отчете группы специальных возможностей по Гутенбергу , макет с 1) верхней панелью 2) областью содержимого 3) боковой панелью является одним из основных барьеров доступности, поскольку он чрезвычайно затрудняет навигацию с клавиатуры.

Зачем вообще нужна верхняя планка? Что там должно быть?

На начальном этапе разработки Gutenberg было продолжительное обсуждение размещения кнопки «Сохранить / Опубликовать». Размещение его сверху не является идеальным для доступности. Единого мнения по этому поводу не было, но, увы, прошло. Я не уверен, что повторение на этой странице неидеального шаблона - лучший путь вперед.

Линеаризация контента - это базовый принцип хорошей информационной архитектуры.

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

Естественный, наиболее очевидный логический поток обычно таков:

• делать что-то, заполнять поля и т. д., устанавливать настройки и т. д.
• и _затем_ сохраните

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

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

Боковая панель: не уверен, что в этом есть необходимость.

Какие элементы управления или настройки должны быть на вкладке «Области виджетов»?

Какие элементы управления на вкладке «Блокировать»? Ранее уже обсуждались настройки блока на боковой панели: ужасно сложно сохранить блок в «выбранном» состоянии, а затем перейти на боковую панель, чтобы работать с размещенными там настройками блока. Этого следует избегать любой ценой.

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

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

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

В любом случае, я поддерживаю @afercia в том, что я не хочу, чтобы те же проблемы с редактором сообщений дублировались на странице виджетов.

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

Некоторые незначительные правки в указанном выше направлении . В основном просто переименование предметов и проверка чуть более подробной информации.

Опытный образец:

https://www.figma.com/proto/WdbvnvIHDFbgVDWwkyNCqFA7/Gutenberg-Widgets-Admin-Screen-Exploration?node-id=14%3A297&viewport=2639%2C1532%2C0.5&scaling=min-zoom

GIF:

• "Области виджетов" переименованы в "Области блокировки" в соответствии с примечаниями @mapk .
• Я переместил заголовок страницы в область содержимого.
• Я сохранил глобальную боковую панель для «Блочных областей», чтобы объяснить, что они собой представляют, а также предоставить быстрые ссылки для редактирования каждой из них (в случае, если они прокручиваются за пределы экрана, как показано позже в прототипе).
• Принята альтернативная обработка блочного аппендера @jasmussen из # 8589.

^ Кроме того, я мог видеть, что это довольно легко переводится в nav-menus.php .

Хороший макет, @kjellr; Я думаю, это выглядит довольно близко к тому, как могла бы выглядеть новая страница Block Areas, если бы она была основана на текущем пользовательском интерфейсе редактора сообщений. Однако, как указывалось ранее, я думаю, что редактор Гутенберга следует сделать более доступным, прежде чем заменять текущую страницу виджетов.

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

• # 3976
• # 10519
• # 10524
• # 11581
• # 12254
• # 13309

Кроме того, описание в части боковой панели «Блокировать области», вероятно, следует читать

(ранее "Области виджетов")

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

Также ... может быть, нам следует называть их «Глобальные области блокировки», а не просто «области блокировки»? Технически каждый экземпляр post_content является «блочной областью», поэтому термин «глобальный» может помочь прояснить, о чем идет речь.

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

Это на самом деле связано с # 13519, не так ли? В будущем (глобальные) области блоков могут стать не чем иным, как повторно используемыми блоками, и не будет страницы «Блоки областей» вообще, а будет просто страница, содержащая список повторно используемых блоков, а также страница, содержащая список шаблонов страниц ... все из которых можно редактировать с помощью Гутенберга.

В долгосрочной перспективе, я не думаю, что страница «(Глобальные) области блоков» вообще будет существовать, но макет @kjellr, вероятно, близок к тому, что произойдет в краткосрочной перспективе, поскольку создание / редактирование шаблона страницы все еще далеко в будущее.

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

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

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

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

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

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

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

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

@afercia

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

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

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

Мне любопытно: какие части настройщика недоступны должным образом?

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

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

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

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

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

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

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

Я согласен. Хотя мне интересно, куда именно он должен идти. Будет ли он доступен с помощью кнопки «Справка» на верхней панели, кроме того, что должно быть внизу? Или будет кнопка «Справка» рядом или под заголовком страницы? Будет ли информация отображаться на боковой панели или во всплывающем окне?

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

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

@youknowriad et all: пожалуйста, дайте мне знать, что вы думаете, когда у вас будет возможность.

При этом сказано:

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

• кнопка «Добавить блок» не имеет особого смысла, потому что сначала нужно выбрать область виджета
• «Отменить» и «Вернуть» не могут быть «глобальными», как в редактируемом сообщении, они должны быть привязаны к виджету. Как отметил @ZebulanStanphill : «редактор сообщений предназначен для редактирования одного сообщения за раз, а не нескольких»
• будут ли на этой странице иметь смысл «структура содержимого» и «блочная навигация»? Я думаю нет
• Сохранить / опубликовать: все еще неясно (см. Предыдущий комментарий)
• Думаю, нет необходимости в кнопке "Настройки" для переключения боковой панели.
• кнопка с многоточием "еще": не уверен, будут ли для этой страницы "инструменты и параметры"

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

Боковая панель:

как бы вы справились с настройками инспектора для блоков без боковой панели

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

Мне любопытно: какие части настройщика недоступны должным образом?

Все они? :) Начиная со структуры документа, в пользовательском интерфейсе настройщика все представляет собой список, все заголовки - h3 . Раздвижные панели - ужасный опыт для пользователей программ чтения с экрана. Взаимодействие с клавиатурой часто бывает неожиданным и вынуждает переключаться назад. Обилие элементов управления, состоящих только из значков. Много других вещей.
Настройщик действительно не был разработан с учетом специальных возможностей. Со временем мы (команда по обеспечению доступности) попытались устранить наиболее важные препятствия для доступа, но сделать настройщик доступным еще предстоит долгий путь. Однако это определенно выходит за рамки данной проблемы.

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

Хорошие мысли в этой ветке.

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

В этом случае одна из целей этапа 2 - расширить область применения блоков . Принцип объединения из этапа 1 остается: чем меньше интерфейсов вам придется изучить, тем лучше, и блокировка может объединить несколько интерфейсов в один. Это относится и к редактору. Поскольку редактор продолжает развиваться, вполне вероятно, что блоки могут взять на себя роль, которую играли виджеты; область виджета может отображаться на область блока, а виджет может отображаться на блок.

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

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

@jasmussen, спасибо, я очень ценю ваше предложение взглянуть на общую картину.

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

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

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

Одна из целей фазы 2, как было объявлено в State of the Word, - также улучшить совместную работу различных команд в WordPress. Дизайн, доступность и т. Д. - все это элементы, которые необходимо интегрировать с первого дня.

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

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

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

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

скриншот блока Recent Posts от # 1594 (там много настроек ...)

снимок экрана текущего блока Последние комментарии:

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

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

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

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

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

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

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

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

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

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

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

Любые комментарии Настройщика, относящиеся к виджетам / блокам, также должны быть делегированы этой конкретной проблеме [# 13205].

@afercia Я не

Копируя прототип @kjellr , я сделал несколько правок.
Убрана верхняя панель, так что там есть только H1 по желанию a11y и кнопка Save , которая сохраняет все области виджетов ... а также указывает автосохранение.

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

Прототип Фигмы

https://www.figma.com/proto/R0KYBQGGpdCsqgW2EWFDtK/Gutenberg-Widgets-Admin-Screen-Exploration-v2?node-id=14%3A297&scaling=min-zoom

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

Первый - показать все области блока на одной странице:

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

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

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

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

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

Доступ к различным областям блокировки можно получить со страницы списка областей блокировки (по сути, /wp-admin/edit.php?post_type=block_area ). Темы, как обычно, управляют шириной содержимого, поэтому верхние и нижние колонтитулы могут быть широкими, а боковые панели - короткими.

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

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

Кнопка «Справка» также может принадлежать панели внизу (то же самое для кнопки «Управление с помощью предварительного просмотра») ... Я не уверен, где она находится.

Я вижу несколько проблем с отображением только одной области виджетов за раз.

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

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

Я вижу несколько проблем с отображением только одной области виджетов за раз.

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

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

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

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

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

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

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

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

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

Я очень ценю, что вы добавили этот мокап, @ZebulanStanphill! Определенно помогает мне визуализировать.

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

мы обнаружили в предыдущем пользовательском тестировании (стр. 23)

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

Положение кнопки «Сохранить» в Гутенберге уже обсуждалось несколько месяцев назад без единого мнения. Я понимаю, что _ визуально_ некоторые пользователи предпочитают кнопку вверху. Однако в линеаризованном интерфейсе навигации текущее положение кнопки далеко не идеально, поскольку заставляет пользователей переходить назад через весь интерфейс.

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

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

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

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

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

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

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

@melchoyce
В дополнение к тому, что сказал @afercia , я бы сказал, что часть проблемы с нижней панелью в демо-версии Crazyhorse заключается в том, что она _ действительно_ выглядит_ как всплывающее окно или браузер Chrome:

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

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

Я действительно не вижу в этом проблемы. Многие приложения помещают элементы управления в панель в нижней части экрана, например Spotify, Twitter и Instagram. Даже Gutenberg Mobile уже размещает несколько своих элементов управления внизу:

Учитывая огромные различия между Crazyhorse Demo и Gutenberg, я бы сказал, что они даже не сопоставимы. Но в любом случае спасибо за указание на это старое пользовательское тестирование; Раньше я не знал о его существовании.

@mapk

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

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

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

Я согласен.

@jasmussen

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

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

Если мы обновили области блоков для поддержки черновиков, запланированных обновлений и отмены / возврата, то под каждой областью блока могли появиться кнопки «Отменить», «Вернуть», «Сохранить как черновик» и «Обновить». Но учитывая, что в долгосрочной перспективе страница блоковых областей, вероятно, полностью перестанет существовать, когда появятся шаблоны страниц, я не уверен, что стоит реализовывать эту дополнительную функциональность.

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

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

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

https://github.com/WordPress/gutenberg/issues/13204#issuecomment -459175233

@youknowriad , как вы думаете, мы можем начать работу над этим?

Еще нет, этот PR # 13088 является здесь обязательным требованием, и мы начнем исследования, как только он приземлится.

Также хотелось бы отметить, что была создана проблема [# 13663] для работы над проблемами, обсуждаемыми здесь.

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

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

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

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

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

Для справки, это тот пользовательский интерфейс, который я должен добавить во Фронтенберге во время фазы 2? :)

Да, @tomjn , это пользовательский интерфейс: https://github.com/WordPress/gutenberg/issues/13204#issuecomment -459175233, но я полностью ожидаю, что биты будут меняться по мере того, как мы переходим в разработку, особенно в отношении сохранения отдельных виджеты-блоки.

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

Добавление примечания здесь о том, что был поднят запрос trac, указывающий на проблему, когда разные пользователи одновременно редактируют виджеты, предлагая систему блокировки:
https://core.trac.wordpress.org/ticket/12722

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

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

Стоит отметить, что, хотя следующий тикет посвящен совместному редактированию с использованием WebRTC, в процесс вошло множество идей и дизайна, и концепция та же: блокировка блока для пользователя, редактирующего его. Поэтому, возможно, стоит взглянуть на этот интерфейс в поисках справочных идей:
https://github.com/WordPress/gutenberg/issues/1930#issuecomment -333455412

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

• PR с наивысшим приоритетом: реализация конечных точек отдыха, которые абстрагируют область виджетов в виде блоков. https://github.com/WordPress/gutenberg/pull/15015
  - (в процессе) Некоторые обновления к совсем недавнему обзору ожидают рассмотрения, но PR все еще может извлечь выгоду из обзоров.
• Второй PR с наивысшим приоритетом: Подключите конечные точки виджетов к редактору блоков на экране виджетов.
  https://github.com/WordPress/gutenberg/pull/15074
  - Зависит от https://github.com/WordPress/gutenberg/pull/15015.
  - (в процессе) Ожидаются проверки.
• Визуализируйте области виджетов, которые ссылаются на post_id во внешнем интерфейсе веб-сайта.
  - https://github.com/WordPress/gutenberg/pull/15074.
  - (в процессе) Ожидаются проверки.

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

В Parallel нам нужны другие улучшения, чтобы блоки работали должным образом на экране виджетов.

Удалите использование wordpress / редактора из основных блоков (wordpress / редактор недоступен на экране виджетов).

• https://github.com/WordPress/gutenberg/pull/15635
• https://github.com/WordPress/gutenberg/pull/15572
• https://github.com/WordPress/gutenberg/pull/15521

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

• https://github.com/WordPress/gutenberg/pull/15472
• https://github.com/WordPress/gutenberg/pull/15470

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

• всплывающее окно блока не отображается в нужных местах.
• Инспектор блоков по-прежнему недоступен.
• У нас нет чего-то эквивалентного глобальному устройству вставки, мы можем вставлять блоки только с помощью устройства вставки родственного брата и модуля вставки автозаполнения "/". Может быть, нам нужен глобальный модуль вставки для каждой области виджета?

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

Объединенные PR (связанные с работой на главном экране): https://github.com/WordPress/gutenberg/pull/15015 , https://github.com/WordPress/gutenberg/pull/15074 , https://github.com / WordPress / Gutenberg / pull / 15651

Был предложен PR, который позволяет устаревшему блоку виджетов ссылаться на существующий виджет https://github.com/WordPress/gutenberg/pull/15801.

Устаревшие виджеты по-прежнему не работают должным образом на экране виджетов, поэтому нам нужно убедиться, что мы можем разместить компонент рендеринга на стороне сервера на этом экране https://github.com/WordPress/gutenberg/pull/15635, и нам нужно PR ранее упоминалось https://github.com/WordPress/gutenberg/pull/15801. Оба PR ожидают рассмотрения / повторного рассмотрения.

Что касается работы по удалению использования wordpress / редактора из основных блоков:
https://github.com/WordPress/gutenberg/pull/15572 был объединен. https://github.com/WordPress/gutenberg/pull/15635 ожидает повторной проверки, и я скоро обновлю https://github.com/WordPress/gutenberg/pull/15521, чтобы учесть отзывы.

Что касается работы по исправлению проблем пользовательского интерфейса, из-за которых экран не работает должным образом или экран не оптимален: https://github.com/WordPress/gutenberg/pull/15472 был закрыт, потому что мы обновили код в другом PR, который устраняет основную причину проблемы.
https://github.com/WordPress/gutenberg/pull/15470 обсуждается и ожидает решения.

Одна из основных проблем, которые у меня есть, - это единственная кнопка сохранения и единственная функция черновика / публикации.

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

Очередное обновление.
Доска краткосрочных проектов доступна по адресу https://github.com/WordPress/gutenberg/projects/27.

Мы объединили еще два важных PR https://github.com/WordPress/gutenberg/pull/15521 , https://github.com/WordPress/gutenberg/pull/15396

PR, которые требуют обзоров

Следующий PR с более высоким приоритетом -
https://github.com/WordPress/gutenberg/pull/15801, который при слиянии позволит использовать устаревшие виджеты на экране виджетов.

https://github.com/WordPress/gutenberg/pull/15548 практически готов и требует окончательного утверждения.

https://github.com/WordPress/gutenberg/pull/15948 был обновлен и также требует окончательного утверждения.

В коде PHP были обнаружены некоторые проблемы / потенциальные улучшения, и было отправлено два PR. Было бы несколько дополнительных глаз на них:
https://github.com/WordPress/gutenberg/pull/15981
https://github.com/WordPress/gutenberg/pull/15983

Реквизит @TimothyBJacobs за предварительную проверку одного из этих PR.

Ожидающие обновления / обсуждения

https://github.com/WordPress/gutenberg/pull/15635 обсуждался, и, похоже, мы пришли к возможному решению. Мне понравилось предложение @gziolo о наличии ServerSideRenderProvider; Я собираюсь реализовать это в ближайшие часы.

https://github.com/WordPress/gutenberg/pull/15470 @aduth предлагает альтернативную идею, раскрывающую новый компонент, который включает в себя BlockEditorProvider, а также некоторые артефакты, ожидаемые от редактора блоков, например, поток записи. Думаю, если бы никто не беспокоился об этом подходе, лучшим способом было бы реализовать этот компонент и обновить https://github.com/WordPress/gutenberg/pull/15470, чтобы использовать его.

Прочие обновления

https://github.com/WordPress/gutenberg/pull/15988, предложенный @aduth , разблокирует проблему позиций всплывающих окон на экране виджетов. Я рассмотрю ее в следующие несколько часов.

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

Я так не думаю, @ellatrix. Если вы хотите закрыть это, у нас есть Совет по проекту , у которого также есть список проблем.

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

Хорошо, поскольку на доске проекта нет никаких движений и никаких движений по этому вопросу, я удалю его с доски WP 5.5.

@ellatrix Мне

Все PR Хорхе, упомянутые здесь: https://github.com/WordPress/gutenberg/issues/13204#issuecomment -499078467
Были объединены.

Привет, Аслан. @jcklpe

Статус функции заключается в том, что над экраном виджетов в wp-admin уже давно никто не работал, поэтому он удален с доски проекта WP 5.5. Это не значит, что над ним не будут работать, только то, что это не приоритет для 5.5.

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