Улучшение удобства настройки авто-сетки для менее чем 3 изображений

Внести вклад Функция
1

Настраиваемое минимальное количество изображений для автоматических сеток

Я столкнулся с ограничением функции автоматических сеток изображений.

В настоящее время поведение автоматической сетки, похоже, контролируется параметром сайта для автоматических сеток изображений, но фактический порог, при котором редактор вставляет [grid]...[/grid], всё ещё задан жёстко в клиентском коде.

Соответствующая логика редактора в настоящее время использует жёстко заданное значение:

const MIN_IMAGES_TO_AUTO_GRID = 3;

Так что, насколько я могу судить, у администраторов на данный момент есть выбор между:

Что могут сделать администраторы сейчас Результат
Включить автоматические сетки изображений Загрузки из 3 или более последовательных изображений автоматически оборачиваются в [grid]...[/grid]
Отключить автоматические сетки изображений Нет автоматического оборачивания в сетку
Изменить порог с 3 на другое число В настоящее время недоступно как параметр сайта

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

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

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

Предлагаемое направление

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

Что-то вроде:

auto_grid_images_minimum_count
```\n
Например:

| Параметр | Пример значения |
| --- | --- |
| `enable_auto_grid_images` | `true` |
| `auto_grid_images_minimum_count` | `5` |

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

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

## Экспериментальная ветка / возможный старт

Я создал небольшую экспериментальную ветку здесь, на случай если кто-то с большим опытом разработки Discourse найдёт время, чтобы форкнуть её, очистить или развить идею:

[ветка image-grid-num-setting](https://github.com/Ethsim12/discourse/tree/image-grid-num-setting)

Ветка не предназначена как готовый PR. Это скорее отправная точка, показывающая предполагаемое направление:

- добавить новый параметр сайта для минимального количества изображений в автоматической сетке
- сделать этот параметр доступным для клиента
- заменить жёстко заданную проверку `MIN_IMAGES_TO_AUTO_GRID = 3` в коде загрузки редактора на настроенное значение
- обновить текст параметра администратора, чтобы существующее описание автоматической сетки больше не подразумевало, что порог всегда равен 3
- добавить/обновить клиентские тесты при необходимости

Примерное изменение на стороне клиента, которое я имел в виду:

```js
const minImagesToAutoGrid = Number(
  this.siteSettings.auto_grid_images_minimum_count ?? 3
);

if (
  this.siteSettings.enable_auto_grid_images &&
  this.#consecutiveImages?.length >= minImagesToAutoGrid &&
  this.textManipulation
) {
  this.textManipulation.autoGridImages([...this.#consecutiveImages]);
  this.#consecutiveImages.length = 0;
}

Также есть недавний пример параметра сайта в стиле Discourse (перечисление) в PR #36014:

PR #36014 - FEATURE: добавляет параметр calendar_upcoming_events_default_view

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

Связанные ссылки

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

Отключение автоматических сеток изображений?

Объявление об автоматических сетках изображений:

Автоматическое применение сеток к загруженным изображениям

Пример PR, демонстрирующий архитектуру параметров сайта:

PR #36014 - FEATURE: добавляет параметр calendar_upcoming_events_default_view

Моя экспериментальная ветка:

ветка image-grid-num-setting

2 лайка
2

Не могли бы вы рассказать подробнее о вашем конкретном опыте?

Какое значение вы бы выбрали и почему?

3

Спасибо — да.

Для своего сайта я, вероятно, установил бы порог в 5 изображений.

Причина в том, что многие сообщения могут естественным образом содержать 3 изображения, не являясь при этом настоящей «галереей». Например, пользователь может загрузить:

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

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

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

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

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

Именно поэтому я считаю, что настройка сайта, например auto_grid_images_minimum_count, была бы полезной. Сайты, которым нравится текущее поведение, могут оставить значение 3, в то время как сайты, подобные моему, могут повысить его до 5, 2 или другого значения.

2 лайка
4

В вашем конкретном случае, что если вместо этого:

  • auto-grid по умолчанию использовал бы раскладку «карусель» или
  • пользователям было бы проще «разгруппировать» всю группу

Мне только что пришла в голову ещё одна мысль…

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

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

5

Да, я думаю, что такое разделение имеет смысл.

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

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

Мне кажется, логичным было бы следующее:

  • редактор сообщений распознаёт или создаёт группу изображений, то есть распознавание в редакторе WYSIWYG или создание в редакторе Markdown.
  • для группы есть выбор макета: список, сетка или карусель — параметр BBCode.
  • пользователи или модераторы могут менять этот макет одним действием, что возможно через вторую панель в редакторе Markdown.
  • сообщение не зависит от того, понимают ли пользователи и тщательно сохраняют ли теги [grid], что является одной из причин полезности однопанельного редактора WYSIWYG.

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

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

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

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

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

1 лайк
6

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

  • когда загружено более 1 изображения, оборачиваем в [grid]
    • когда количество <=3, по умолчанию делаем [grid mode=list]
    • когда количество > 3 и <=10, по умолчанию делаем [grid mode=grid]
    • когда количество > 10, по умолчанию делаем [grid mode=carousel]
  • в режиме rich и в превью делаем удобным для пользователя переключение между режимами list, grid и carousel

@chapoi и @renato, интересно ваше мнение по этому поводу.

1 лайк
7

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

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

1 лайк