Интересная идея @melchoyce.

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

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

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

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

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

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

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

1. что они могут появляться при наведении
2. они не увеличивают площадь блока

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

2 может быть важным в зависимости от того, как мы работаем с боковым пользовательским интерфейсом во вложенных контекстах. Прямо сейчас мы сталкиваемся с некоторыми проблемами в https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863, и хотя я уверен, что мы сможем их решить, тот факт, что след не Смена помогает.

Все это не означает «не может работать» - это вполне может сработать. У старого макета был этот пользовательский интерфейс в виде наложения в углу:

Так что в общем, хорошие идеи, и хорошо, чтобы они оставались в курсе, как пути, которые можно исследовать в зависимости от отзывов, которые мы получаем от выпуска к выпуску!

Граница отображается при нажатии или при наведении?

Просто по щелчку. Hover будет похож на то, как он работает сейчас.

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

Всегда 👍

они не увеличивают площадь блока

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

Так что в общем, хорошие идеи, и хорошо, чтобы они оставались в курсе, как пути, которые можно исследовать в зависимости от отзывов, которые мы получаем от выпуска к выпуску!

👍 👍

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

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

1. что они могут появляться при наведении
2. они не увеличивают площадь блока

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

+1 Стоит отметить, что это также может помочь улучшить порядок табуляции элементов управления пользовательского интерфейса вокруг блоков. Как упоминалось в https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531, в мобильном пользовательском интерфейсе «боковые элементы управления» расположены более логично. См. Анимированный GIF, который иллюстрирует порядок табуляции, вы можете сравнить с предыдущим GIF с порядком табуляции в представлении рабочего стола в предыдущем комментарии https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052

Также принять во внимание:

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

1934 г. как общая проблема согласованности порядка табуляции

Это также может повлиять на решение некоторых проблем, поднятых в # 6272.

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

Да, то же самое происходит и с верхней панелью инструментов форматирования:

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

Да, я могу еще раз взглянуть.

+10 за попытку.

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

Я заметил, что инструмент для вставки блоков появляется рядом с элементами управления движением вверх / вниз. Если бы этот тип пользовательского интерфейса использовался для всех размеров экрана, как предлагает эта проблема, то, возможно, текущий блок-аппендер можно было бы удалить из вложенных контекстов блоков, сделав редактор больше похожим на интерфейс, удалив всегда присутствующее дополнительное пространство. каждым приложением блока для каждого уровня вложенности. (Я также предложил альтернативное решение проблемы appender-eat-up-space в # 6834.)

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

Еще одна идея:

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

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

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

Еще одна идея:

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

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

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

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

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

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

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

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

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

• # 7646 → когда элементы управления расположены выше / ниже, вам не нужно беспокоиться о размещении бокового интерфейса
• # 7182 → элементы управления, подобные тем, что в мокапах этого тикета, напрямую связаны с блоком и будут иметь согласованный пользовательский интерфейс независимо от уровня вложенности
• # 6451 → если верхняя / нижняя панели инструментов имеют сплошной фон, вам не нужно беспокоиться о том, как сделать элементы управления видимыми на темном фоне
• # 7114 / # 6265 → Если вы используете полноразмерную панель инструментов, как в некоторых из приведенных выше макетов, вы можете использовать пустую область для перетаскивания / перетаскивания

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

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

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

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

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

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

@karmatposed Я использовал запутанный жаргон - я имел в виду элементы управления, а не панели инструментов. Панели инструментов уже вверху - менять там нечего :)

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

Обычный:

Когда нижняя часть блока находится за пределами экрана:

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

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

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

@chrisvanpatten Да, я бы в любом случае не возражал, если бы элементы управления были разделены или нет.

Вот еще несколько мокапов:

Наведите:

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

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

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

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

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

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

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

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

Что-то меня смущает в том, что у элементов управления нет верхней границы: элементы управления все еще на белом фоне? Означает ли это, что за всем блоком стоит белый фон?

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

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

Согласен, наличие фона также решает # 6451.

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

Как предлагалось ранее, стрелки и многоточие могут использоваться как маркеры перетаскивания, и / или заголовок при наведении курсора может быть маркером перетаскивания. (См. # 7114.)

@SuperGeniusZeb, хотя я понимаю вашу точку

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

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

@SuperGeniusZeb Да, я не вижу, чтобы белый фон влиял на сам блок, только на элементы управления. Практически это могло быть примерно так:

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

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

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

@SuperGeniusZeb

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

Отличная идея 💡

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

@karmatposed

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

Я не совсем понимаю, что это значит? С какой стороны?

Рад видеть, что это произойдет. Напоминаю, что дело не только в визуальном размещении. Для a11y визуальный порядок и порядок табуляции (порядок DOM) должны совпадать, поэтому эти «инструменты блока» должны фактически перемещаться после редактируемой области блока в разметке.

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

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

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

@talldan Цитата из # 7500:

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

Выглядит действительно хорошо, я за это.

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

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

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

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

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

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

@hedgefield Мне это очень нравится, но он не работает в узком контексте (например, блок столбцов) или с длинными панелями инструментов.

@hedgefield @chrisvanpatten Возможно, элементы управления в виде стрелки / многоточия могут перемещаться ниже (или выше) элементов управления форматированием в случаях меньшей ширины?

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

Однако, возвращаясь к макету @hedgefield , можно было бы позволить элементам управления быть липкими, как инструменты форматирования, не

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

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

Это нежелательно, когда для этого есть определенный критерий успеха WCAG:
https://www.w3.org/TR/WCAG21/#focus -order

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

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

Как бы это выглядело для широких блоков:

Как бы это выглядело для тонких блоков:

Еще более тонкие блоки (думаю, 8 столбцов или что-то в этом роде):

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

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

однако объединение всего в одной строке - это объединение различных действий в одно место.

Играть в адвоката дьявола - разве не в этом по определению цель панели инструментов?

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

@karmatposed Как насчет разделения элементов управления по цвету?

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

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

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

@karmatposed Ладно. Вернемся к верхней панели редактирования:

(Не уверен, должна ли быть синяя линия над полосой).

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

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

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

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

Некоторые макеты:

С рамкой в ​​верхней части панели управления

Без рамки в верхней части панели управления

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

Делая эти макеты, я кое-что заметил: что делать в подобных ситуациях?

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

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

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

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

@SuperGeniusZeb Я как-то пропустил эти макеты. Спасибо за их изготовление!

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

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

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

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

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

Elementor делает почти то же самое.

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

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

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

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

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

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

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

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

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

Некоторые примечания о том, как это будет работать:

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

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

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

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

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

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

Я думаю, что это большая проблема с макетами. Что еще могло случиться?

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

@karmatposed

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

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

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

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

Кроме того, как в построителях страниц, так и в других пользовательских интерфейсах, подобных построителям, вложение, как правило, представляет собой гораздо меньшую проблему из-за ограничений на то, что может быть вложено. Divi имеет строгий раздел → Строка (со встроенными столбцами) → Настройка модуля (хотя и с некоторыми специальными разделами, разработанными для некоторых распространенных ситуаций с вложенными столбцами). Beaver Builder позволяет вкладывать столбцы в столбцы, как и Elementor. Они контролируют единственный вид объекта, который может иметь несколько уровней вложенности. По умолчанию все находится в разделе с одной строкой. Не существует неограниченного количества уровней вложенных блоков с потенциалом для любой комбинации пользовательских блоков, которые используют вложение для различных целей и различных стилей, таких как то, что позволяет Гутенберг.

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

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

То, что пытается сделать Гутенберг, уникально. Он пытается быть конструктором страниц WYSIWYG-except-for-the-selected-block-which-is-optimized-for-edit, который также является полнотекстовым редактором, и все, от разделов до столбцов и виджетов, одинаково объекта: блоки.

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

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

Плагины / темы WordPress

• Avada (Fusion Builder)
• BeTheme (Конструктор маффинов)
• Бобр Строитель
• Divi (конструктор Divi)
• Элементор
• Кислород
• Конструктор страниц SiteOrigin
• Процветающий архитектор
• Визуальный композитор
• X & Pro от Themeco

Конструкторы веб-сайтов вне WordPress

• Drupal
• Squarespace
• Weebly
• Wix

Вещи, которые не являются конструкторами страниц, но чем-то похожи на

• MailChimp
• Понятие

Это все, о чем я знаю сейчас.

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

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

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

Преимущества включают:

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

Бонусные баллы, если одноуровневое устройство вставки изменено для прямого открытия меню средства вставки (как обсуждается в # 7271) вместо вставки пустого блока абзаца.

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

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

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

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

@chrisvanpatten Я думал, что нижняя панель фактически займет место при

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

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

(РЕДАКТИРОВАТЬ: чтобы уточнить, это действительно усложняет задачу для пользователей мыши, потому что вы не можете действительно полагаться на то, что вещи находятся в одном и том же месте от одного момента к другому. Это вызывает много неловкости.)

@chrisvanpatten

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

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

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

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

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

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

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

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

Я по-прежнему уверен, что где-то здесь есть решение ... просто нужно продолжать итерацию!

@chrisvanpatten

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

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

В любом случае, как насчет прозрачности?

И если вы хотите немного пофантазировать и хотите, чтобы backdrop-filter был реализован во всех основных браузерах, вы можете добавить немного размытия:

Между прочим, это 60% непрозрачности.

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

@chrisvanpatten Действительно, это немного похоже на обман ... но какие еще варианты у нас есть?

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

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

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

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

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

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

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

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

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

Прозрачные панели инструментов:

Нет прозрачности:

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

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

Может ли это быть? Может ли эта итерация быть достаточно хорошей, чтобы заменить текущую? _ (Пожалуйста, скажите "да".: Stuck_out_tongue:) _

Спасибо всем за все исследования, сделанные здесь. Добавим еще одну причину, по которой полупрозрачность не идеальна: коэффициент контрастности значков с фоном должен быть 4,5: 1. Использование полупрозрачности сделало бы это невозможным, просто представьте себе изображение с преобладающими темными цветами, абзац с темным фоном или тему с темным фоном:

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

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

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

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

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

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

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

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

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

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

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

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

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

Как это?

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

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

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

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

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

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

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

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

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

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

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

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

Вернуться к чертежной доске… 🙂

Почему я считаю, что мой макет лучше текущего пользовательского интерфейса

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

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

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

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

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

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

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

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

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

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

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

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

В целом, я думаю, что мой последний макет улучшил больше ситуаций, чем стал хуже.

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

• Работает для блоков любой ширины.
• Лучшая доступность для одноуровневого устройства для вставки, элементов управления перемещением и многоточия.
• Лучшая видимость и удобство обнаружения для одноуровневого устройства для вставки и ручки перетаскивания.
• Области перетаскивания сбоку от блока могут быть удалены, а метка при наведении курсора не обязательно должна становиться ручкой перетаскивания (в любом случае она небольшая).
• Устройство для вставки сестры находится под блоками, где вы обычно хотите его использовать (в отличие от указанного выше).
• Нет необходимости в отдельном пользовательском интерфейсе устройства для вставки, что снижает сложность.
• Устройство для вставки родственных объектов больше не имеет проблем с перекрытием во вложенных контекстах. (Я думаю, это причина того, что № 6520 еще не появился.)
• Пользовательский интерфейс блока, окружающий блок, никогда не перекрывает содержимое этого блока.
• Автоматические поля блоков могут быть удалены, и блок может вообще не иметь внутреннего заполнения, а границы пользовательского интерфейса блока могут быть изменены обратно на фактические границы содержимого, и при этом ничто в содержимом блока не будет перекрываться какими-либо элементами управления. Такие крайние случаи возникают с пользовательскими блоками, поэтому их полезно учитывать.
• Все инструменты блока расположены довольно близко друг к другу, что упрощает доступ к ним и обнаружение их всех по сравнению с предыдущей ситуацией, когда многоточие и стрелки находятся на противоположных сторонах блока.
• Совершенно ясно, к какому блоку прикреплены элементы управления, по сравнению с путаницей, которую вы часто получаете с текущими элементами управления во вложенных контекстах.
• Элементы управления больше подходят для мобильных устройств.

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

Есть ... еще одна ... ~ Скайуокер ~ идея

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

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

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

Но подождите, это еще не все!

На самом деле, если задуматься, в чем разница между этой идеей и просто моим макетом и включением Fix Toolbar to Top ? Единственное, что вы получаете, полностью удаляя встроенные панели инструментов форматирования с мобильных устройств, - это возможность отображать элементы управления перемещением и многоточие над блоками, а не под ними. И технически это могло быть просто частью опции Fix Toolbar to Top .

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

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

@padraigobeirn Это хороший момент, о котором я забыл.

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

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

Вы знаете, я действительно начинаю думать, что Fix Toolbar to Top должен быть включен по умолчанию.

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

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

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

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

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

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

Не могли бы вы сделать скриншоты этого интерфейса @SuperGeniusZeb?

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

Не могли бы вы сделать скриншоты этого интерфейса @SuperGeniusZeb?

@chrisvanpatten Нет, у меня был временный доступ к нему, когда я помогал кому-то.

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

@chrisvanpatten Нашел статью, в которой кто-то рассказывает о построителе электронной почты в Infusionsoft, и у него есть видео:

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

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

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

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

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

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

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

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

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

Просто для того, чтобы держать их в актуальном состоянии, я обновил свои макеты, чтобы учесть изменения, предложенные тикетами @jasmussen , и недавние изменения пользовательского интерфейса в 3.6:

На самом деле, перемещение стрелок ниже блоков может даже не понадобиться, если реализованы # 9074 и # 9075. Было бы хорошо, если бы они остались сбоку от блока, поскольку многоточие соседних блоков больше не будет перекрывать их в таких вещах, как столбцы. Если бы возникли решения для # 8880, # 8881 и # 8883, и если бы были реализованы # 8836 и # 8920, то, возможно, пользовательский интерфейс уже был бы хорош для вложенных контекстов. Я начинаю склоняться к тому, чтобы стрелки вверх / вниз оставались на левой стороне блока.

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

Давайте сосредоточимся на получении итераций в @jasmussen, над

Благодаря вышеупомянутым # 9074 и # 9075, а также другим проблемам и PR, таким как # 8920 и # 9197, я решил, что перемещение стрелок ниже блока больше не имеет многих преимуществ.

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

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