Привет,

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

Идея компонента следующая:

Есть текстовое поле для много-строчного ввода текста, но не более 2–3 строк ❶. Есть другая область — live-рендера ранее вводимого текста ❷. Пользовательский ввод это формально какой-то мета язык со своим синтаксисом (хорошая аналогия — Markdown) и не будет превышать 100 символов (max=2–3 строки как я сказал раньше).

Суммарно все пространство очень ограничено, (т. о. разделить на две половины, как это делают обычно в редакторе: на левую сторону — ввод и правую — просмотр) не получится. Мало места. В поле ввода присутствует окраска синтаксиса.

Идея сделать «парящую» кнопку ❸ поверх поля ввода ❶ с синтаксисом, которая бы показывалась только при активном фокусе в поле, таким образом если поле ввода не в фокусе, оно выглядит как обычный текстовый редактор:



Когда компонент будет в фокусе, то появляется кнопка «Preview» ❸. Эту кнопку нельзя двигать пользователю, ее координаты рассчитываются на основе заполненности текстом поля ввода. Почему не хочу делать вверху toolbar с одной кнопкой? Много занимает, хочу не загромождать лишними элементами управления:


При нажатии ❸ переключается в режим «рендера ввода» ❷

При отжатии кнопки ❸ возвращается в прежний режим ❶ Таким образом еще одно нестандартное поведение — нажатие и отжатие вместо одиночного клика мыши.

⸻
Буду рад, если подскажите, если где-либо такую же реализацию вы видели, насколько удачная это идея. Потому что пугает «нестандартность подхода» c этим overlapped ui-control.

Здравствуйте, r0nd, Вы писали:

R>Буду рад, если подскажите, если где-либо такую же реализацию вы видели, насколько удачная это идея. Потому что пугает «нестандартность подхода» c этим overlapped ui-control.

Ввод с клавиатуры?
Экран сенсорный или мыша, стилус есть?
Монохром?

Можно просто по таймауту переводить в preview, а при фокусе обратно в raw вид

On Mar 1, 2024, 1:03 AM, kov_serg <39543@users.rsdn.org> wrote:

KS>Ввод с клавиатуры?
KS>Экран сенсорный или мыша, стилус есть?
KS>Монохром?

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

KS>Можно просто по таймауту переводить в preview, а при фокусе обратно в raw вид

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

Здравствуйте, r0nd, Вы писали:

R>насколько удачная это идея. Потому что пугает «нестандартность подхода» c этим overlapped ui-control.

Мне такая идея не нравится.
1. Слишком много кликов.
2. Неочевидный интерфейс.
3. Загораживает текстовое поле.

Есть такая штука как правило трёх кликов.
1. Но одно дело сделать три очевидных клика.
2. Другое дело сделать три неочевидных клика.

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

Вот тебе несколько примеров.

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

2. Точно так же с исчезающими и появляющимися меню и панелями инструментов. Это в графических 3D редакторах и САПР такое практикуется, но не только. Называется режимом чего-то там, верстаком, ещё какой-то ерундой. Получается у меня мозг должен постоянно адаптироваться под перестраивающийся интерфейс.

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

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

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

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

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

Кстати, вот ещё минус, лично я плохо воспринимаю кнопки находящиеся внизу. Если ты их поместишь ещё ниже в строку состояния, то я даже буду периодически забывать, что там есть какая-то функциональность. Проверено на кучи графических 3D редакторах и САПРов.

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

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

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

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

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

On Mar 1, 2024, 3:18 AM, velkin <99832@users.rsdn.org> wrote:

V>Мне такая идея не нравится.
V>1. Слишком много кликов.
V>2. Неочевидный интерфейс.

Жаль, что ты не внимательно читал, что я написал. Здесь один клик с эффектом переключателя (пока нажата кнопка — «предварительный просмотр написанного», отжата — вернулись обратно). Где здесь «много кликов»? Кстати, сейчас вспомнил, что недавно ChatGPT такую же всплывающую кнопку над выделенным словом.

V>3. Загораживает текстовое поле.

Да, верно, загораживает текстовое поле на 3⅓ процента от площади поля ввода, которое рассчитано на небольшой текст (100 символов). У тебя есть идея лучше, ну кроме неисчезающей панелью справа с единственной кнопкой?

Здравствуйте, r0nd, Вы писали:

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

Впрочем, пробуй. Реализовать-то несложно.

Здравствуйте, r0nd, Вы писали:

V>>3. Загораживает текстовое поле.
R>Да, верно, загораживает текстовое поле на 3⅓ процента от площади поля ввода, которое рассчитано на небольшой текст (100 символов). У тебя есть идея лучше, ну кроме неисчезающей панелью справа с единственной кнопкой?

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

Хочешь в опыты, вперёд. Если это был опрос, то мне твоя идея не понравилась. И я даже подробно описал почему.

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

По крайне мере не пили такую фичу ультимативно неснимаемо, дай пользователям от неё избавиться. В наше время убирается даже главное меню типа ctrl+m, если оно кому-то не нужно или наоборот нужно.

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

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

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

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

Здравствуйте, r0nd, Вы писали:
R>Идея компонента следующая:
Было бы неплохо помимо самой идеи привести формулировку проблемы, которую эта идея призвана решить.
Почему нельзя сделать просто wysiwyg безо всяких raw и live preview?

On Mar 4, 2024, 9:17 AM, Sinclair <5743@users.rsdn.org> wrote:

S>Почему нельзя сделать просто wysiwyg безо всяких raw и live preview?

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

Здравствуйте, r0nd, Вы писали:

R>К сожалению этот момент я не описал в первом сообщении, но в этом тексте еще могут присутствовать макросы (помимо языка гипер-разметки), эти макросы разворачиваются в сложные конструкции только в момент рендера (единожды). Предполагаемая кнопка выполняет задачу запуска рендера не только разметки, но и преобразования этих «макроопределений».
Ну, вот скажем в Microsoft Word аналогичная штука есть уже лет 30 как; и работает в WYSIWYG режиме. Почему вы считаете этот способ непригодным?

On Mar 5, 2024, 5:03 AM, Sinclair <5743@users.rsdn.org> wrote:

S>Ну, вот скажем в Microsoft Word аналогичная штука есть уже лет 30 как; и работает в WYSIWYG режиме. Почему вы считаете этот способ непригодным?

Ты решил с козырей зайти? Неплохо.

Все зависит от решаемых задач, конкретно мои задачи не решаются с помощью Microsoft Word™. Впрочем я уже все сделал и протестировал:

Здравствуйте, r0nd, Вы писали:
R>Ты решил с козырей зайти? Неплохо.
Я всегда стараюсь понять, как решить задачу (а не как улучшить конкретное решение, возможно неудачное изначально).
R>Все зависит от решаемых задач, конкретно мои задачи не решаются с помощью Microsoft Word™.
Эмм, я, наверное, плох объясняю: речь не о том, чтобы решить задачу с помощью Microsoft Word.
А о том, чтобы решить задачу с помощью подхода Microsoft Word.
R>Image: editor-with-overlapped-button.png
Это по-прежнему не означает оптимальности такого UX для пользователя. Текст у вас обтекает кнопку или затекает под неё? В данном примере унопка съела примерно 7% площади контрола.

По скриншоту непонятно, какими параметрами отображения позволяет управлять ваш язык разметки. Например, если в нём нет понятия "цвета", то можно выделять макросы не выходя из WYSIWYG-режима.
Непонятно также, на какой input рассчитан контрол — это десктоп с клавиатурой и мышкой, или touch-интерфейс?
Ведь если это полноценный десктоп, то всю стилизацию (bold/italic/strikethrough/underline/monospace) можно сделать через шорткаты, продублированные контекстным меню по правой кнопке мыши.
И таким же образом переходить в режим редактирования конкретного макроса, который закрывается по выходу из редактора.

On Mar 5, 2024, 8:23 AM, Sinclair <5743@users.rsdn.org> wrote:

S>Это по-прежнему не означает оптимальности такого UX для пользователя. Текст у вас обтекает кнопку или затекает под неё?

Затекает под нее в случае, но если до нее дойдет, чего не происходит в большинстве случаев.

S>Например, если в нём нет понятия «цвета», то можно выделять макросы не выходя из WYSIWYG-режима.

В этом окне главное не разметка, а макросы. Разметка есть, но управление цветом в ней нет.

S>Непонятно также, на какой input рассчитан контрол — это десктоп с клавиатурой и мышкой, или touch-интерфейс?

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

S>Ведь если это полноценный десктоп, то всю стилизацию (bold/italic/strikethrough/underline/monospace) можно сделать через шорткаты, продублированные контекстным меню по правой кнопке мыши.

Можно сделать, если бы это был полноценный редактор с большим размером как Word, но это элемент UI настройки в окне настройки шаблонов, которая вызывается из окна настройки редактора. То есть это даже не прямая настройка.

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

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

Хотя и кнопка не мешает.

	Скрытый текст

Здравствуйте, Sinclair, Вы писали:

S>Почему нельзя сделать просто wysiwyg безо всяких raw и live preview?

>Пользовательский ввод это формально какой-то мета язык со своим синтаксисом (хорошая аналогия — Markdown)

Раз есть мета-язык, значит и возможность писать на нём должна быть.

Здравствуйте, r0nd, Вы писали:

R>Буду рад, если подскажите, если где-либо такую же реализацию вы видели

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

Загораживать ввод плавающей переключалкой я бы не стал. Дико бесит, когда не можешь увидеть контент под контролом и начинаешь его оттягивать скроллом/пальцем (в лучшем случае) или просто понимаешь, что ничего нельзя сделать (кроме как временно новых строк навставлять). Единственный раз, когда я такое писал, была кнопка разворачивания контрола на весь экран, и она отображалась исключительно при ховере (т.е. навредить она не могла). Меня даже в гугловских "Контактах" это отвращает. В общем, переключалку лучше разместить справа или снизу от контрола.

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