Сейчас эта логика основана на парадигмах, которые в большинстве случаев не формулируются явно. Это результат интуиции и общения с клиентами. Такая стратегия в основном позволяет избежать регрессий и катастроф, таких как потеря клиента. Однако у неё есть свои пределы. Не существует чёткого масштаба, по которому можно было бы измерять прогресс. Поэтому прагматичные KPI, такие как «Сколько пользователей пожаловались на изменение / похвалили его?» и «Были ли достигнуты вторичные цели, например, улучшение производительности и т. д.?», будут определять, было ли изменение успешным.
Проблема в том, что потенциальные пользователи и потенциальные клиенты не могут пожаловаться.
Пользовательский интерфейс подобен языку. Наша способность понимать этот язык зависит от культуры, в которой мы социализировались. Если мы не формулируем явно те парадигмы, которые используем при создании таких интерфейсов, мы внедряем в эти системы свою культуру. Это означает, что ими будет легко пользоваться людям, похожим на нас, но не обязательно всем остальным.
Преимущества, которые может принести дизайн-система с абстрактной точки зрения:
Последовательный внешний вид и взаимодействие, поддерживающие знакомство пользователя, могут снизить сложность обучения, когнитивные и операционные затраты, а также повысить эффективность работы. источник
Благодаря чётко определённым категориям компонентов пользовательского интерфейса путаница между компонентами «отображения данных» и действиями пользователя (для которых, например, может использоваться кнопка) не возникла бы. Если бы существовала страница, подобная этой, где были бы перечислены все различные компоненты UI и их назначение, можно было бы провести рациональное обсуждение. Также было бы хорошо, если бы такие обсуждения проводились публично, а не ограничивались только сообщениями в коммитах git.
Я только что добавил похожую подсказку, но не в плейсхолдер. Учитывая все языки, на которые переведён Discourse, длинная строка в плейсхолдере рискует быть обрезанной. Кроме того, как только вы начинаете вводить текст, плейсхолдер исчезает. Вместо этого я добавил подсказку, выровненную по правому краю, в строку поиска по всем темам/сообщениям:
Мой опыт использования поиска внутри темы на Meta сейчас таков: он кажется странно сломанным.
Когда я хочу найти что-то на веб-странице, я привык нажимать Ctrl+F, вводить текст и нажимать Enter. Я понимаю, почему Discourse перехватывает или улучшает это поведение для длинных тем.
Что происходит сейчас, когда я нажимаю Ctrl+F на Meta и ввожу «theme» в поле поиска:
Показывается множество пользователей (что за бред) или тегов (полезно).
Если я нажимаю Enter, показывается множество других тем (что за бред, я пытаюсь искать внутри текущей темы).
Если я нажимаю «ещё», контекст темы полностью теряется.
Мой вывод: вы полностью игнорируете устоявшиеся ожидания пользователей относительно того, как работает поиск внутри страницы в интернете.
Предложения:
(1) Если пользователь активировал поиск через Ctrl+F, по умолчанию выполнять поиск внутри темы; но сохранять поиск по всем темам как стандартный вариант, когда поиск вызывается через другие элементы глобальной навигации.
(2) Не показывать пользователей по умолчанию, так как большинство людей ищут темы.
Честно говоря, я в недоумении, почему вы применили такой радикальный подход к этой задаче; я бы подумал, что влияние на производительность при поиске по каждому символу можно было бы обработать задержкой в 500 мс перед запуском поиска.
Я чувствую то же самое, хотя хочу также отметить, что понимаю аргументы команды, касающиеся причин такого решения, и признаю, что изменения принесли и другие значимые преимущества. Похоже, дело лишь в том, чтобы всё отладить, возможно, с дальнейшим улучшением нового дизайна. К сожалению, у меня пока нет конкретных идей для улучшений, иначе я бы открыл тему для…
Тем не менее, у меня возникла та же мысль:
Хотя у команды нет обязательной необходимости отвечать, я всё же надеюсь, что они это сделают. Однако, похоже, это не требует отдельной темы.
Однако, похоже, это не требует отдельной темы.