Здравствуйте, Евгений Музыченко, Вы писали:

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

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

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

Не заставляйте пользователя думать (с) Психбольница в руках пациентов

Здравствуйте, Евгений Музыченко, Вы писали:

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

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

ЕМ>Точнее, жалуются не столько на сам интерфейс, сколько на концепции и правила применения продукта (это не мой выбор, в звуковой подсистеме винды оно так by design, для получения нетривиального поведения приходится применять непростые алгоритмы).
Такое и стараются спрятать за UI, ты, видимо, не пробовал.

ЕМ>А зачем, если вся нужная информация есть во встроенной справке?
Ты телеметрию в свой софт вставил как я тебе предлагал? Нет, не вставил. Ты не знаешь как используют твой софт, т.е. тебе не известны пользовательские сценарии, а они могут быть не тривиальные и не покрываются справкой в которую они вряд ли ходит. У меня есть живая статистика по которой из нескольких десятков тысяч пользователей продукта, предметно, в хелп, заглянуло всего 2 тысячи, поэтому хелп особо и не нужен если UX нормальный, а если что-то надо сделать эдакое или решить проблему, то нужен гайд который показывает как решить проблему где-нибудь на ютубе или "живой" саппорт на "реддите".

ЕМ>Из принципа, из врожденного чувства противоречия?
Люди из принципа просто снесут твой софт и купят у конкурентов, либо купят МАК и/или железо, вот и всё. Никто не будет тратить своё время на что-то непонятное если это не отраслевой стандарт.

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

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

_>Ну что вам мешает сразу в нужное место в chm файле открывать?

Мне — ничего, я именно так и делаю (используя WS_EX_CONTEXTHELP). Речь о том, отчего эта фича реализована криво, не применяется самой MS в своих приложениях с нетривиальным интерфейсом, не рекомендуется к применению другими, и редко применяется по факту.

_>Дело в том чтобы ткнуть стрелкой со знаком вопроса в контрол, до этого контрола еще надо добраться. Что нынче бывает весьма не тривиально.

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

_>А так обычно в chm есть полнотекстовый поиск и оглавление.

У меня полнотекстовый поиск изначально есть в каждом CHM. Через какое-то время выяснилось, что большинство пользователей просто не обращает внимания на вкладку Search. Добавил ее упоминание и на заглавную страницу CHM, и в описание софта на сайте. Без толку. Что еще может быть проще и понятнее для пользователя, чем возможность получить помощь по элементу, непосредственно ткнув в него мышкой?

_>ps: Самые простые принципы обучения — подрожание (делай как я) и только когда уже умеют пользоваться за деталями лезут в справочники и то не всегда.

Ну вот, грубо говоря, программа умеет переименовывать файлы. В справке есть пример, как переименовать файл abc.doc в cde.doc. Что делать с пользователями, которые регулярно спрашивают, как им переименовать файл foo.doc в bar.doc? Делать для них дополнительные описания, примеры, или записать в безнадежно тупые и махнуть рукой?

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

ЕМ>>делать большую зеленую кнопку "сделать зашибись"

bnk>Так-то это вообще для всех хороший вариант, не только для тупых.

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

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

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

Здравствуйте, Евгений Музыченко, Вы писали:

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

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

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

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



Офис на HTML в частности и по этой причине перевели.
Почему бы не рассмотреть HTML-вариант интерфейса (тот же sciter например)

Здравствуйте, Евгений Музыченко, Вы писали:

_>>ps: Самые простые принципы обучения — подрожание (делай как я) и только когда уже умеют пользоваться за деталями лезут в справочники и то не всегда.

ЕМ>Ну вот, грубо говоря, программа умеет переименовывать файлы. В справке есть пример, как переименовать файл abc.doc в cde.doc. Что делать с пользователями, которые регулярно спрашивают, как им переименовать файл foo.doc в bar.doc? Делать для них дополнительные описания, примеры, или записать в безнадежно тупые и махнуть рукой?

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

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

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

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

В третьих, из этих частых вопросов хорошо вырисовывается основные проблемы, непонятки пользователя, что именно у них "не едет сходу". Суть их сценариев использования. И вот енту выжимку в мыслях оформить уже как лендинг именно под эти частые вопросы у себя на сайте.
Вуаля! Трафик растет, просто новички просветляются и поют вам мантры. Особо тупые визжат от восторга и несколько вариантов (нужное подчеркнуть ©):
а) либо визжат от восторга и кажный оный раз платютЪ вам денежку, сиречь равно профит

б) либо все таки учатся, и перестают сносить моск… А заодно и Вам помогают если не понять их проблемы, то хотя бы взглянуть на их проблемы именно с их колокольни. Что азмъ езмъ тоже профит. Но не в деньгах, а в перспективах. Сиречь, инвестиции (в будущее развитие).

в) Либо не платят, не учатся, но и больше к Вам не ломятся… Что тоже хорошо уже. Эти, с извинения, сказать пользователи, они все равно из бронепоезда… И объяснить им, что они в глубоком бронепоезде просто бесполезно. Ну и тогда правую руку вверх, резко опускаем, и произносим сакральное "Ну и x#р c ними".
Уж не помню, у кого именно из великих брендов прошедших лет был классный мем на этот случай. “Это НЕ наш клиент!”

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

PS: у кого то из классиков то ли у Алана Купера, то ли у Брукса:

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

PPS: Я б еще посоветовал Алистера Коберна полистать про сценарии использования. Хорошо там раскладывается, причем с примерами, и вполне так структурировано как понимать пользователя и его сценарии использования.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ну вот, грубо говоря, программа умеет переименовывать файлы. В справке есть пример, как переименовать файл abc.doc в cde.doc. Что делать с пользователями, которые регулярно спрашивают, как им переименовать файл foo.doc в bar.doc? Делать для них дополнительные описания, примеры, или записать в безнадежно тупые и махнуть рукой?

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У меня полнотекстовый поиск изначально есть в каждом CHM. Через какое-то время выяснилось, что большинство пользователей просто не обращает внимания на вкладку Search.
Так это о софта зависит, если у вас скриптовый язык встроен, то полнотекстовый поиск будет задействован. А так обычно можно обойтись нормальным оглавлением.

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

K>Где сложнее, там саппорт есть

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

K>ролики в ютубе как использовать софт

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

K>например, уроки по фотошопу

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

ЕМ>>А на мой интерфейс регулярно жалуются, что сложно в изучении.

K>Значит тебе явно подают сигналы что у тебя плохой UX дизайн

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

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

Сценарии мне известны и без телеметрии — пользователи сами их в изобилии описывают. В типовом случае это выглядит, как "у меня есть приложения A, B и C, мне нужно передать звук от A к B, от C — к A, от B — к A и C, и чтоб при этом ничего не трещало, не фонило и работало стабильно". В применении, скажем, к кулинарии, это будет примерно "купила мясорубку, блендер и мультиварку, в продуктах и готовке ничего не понимаю, изучать некогда, как мне по-быстрому приготовить котлеты под грибным соусом, и чтоб повкуснее?".

K>они могут быть не тривиальные и не покрываются справкой в которую они вряд ли ходит.

Именно так — даже если выделить несколько типовых сценариев, в них все равно будут меняться какие-то параметры. Если описывать каждый набор отдельно, справка распухнет до неприличия, и найти нужный станет еще сложнее.

K>Люди из принципа просто снесут твой софт и купят у конкурентов, либо купят МАК и/или железо, вот и всё.

Те, которые "из принципа" мне малоинтересны. Им чаще всего нужны готовые решения, а не инструмент. У меня — именно инструмент.

K>Никто не будет тратить своё время на что-то непонятное если это не отраслевой стандарт.

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

K>Единственный реальный факт о котором ты сам и говоришь — пользователи жалуются на сложность твоего интерфейса.

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

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

bnk>Мне кажется в этом случае классическая документация с поиском.

Она есть с момента первого выпуска продукта. Вопрос — как загнать пользователя в тот поиск. Рекомендации на сайта и на заглавной странице документации помогают плохо.

bnk>Ну или просто значки "?" рядом с каждым контролом

Это идея, спасибо. Скорее всего, будет работать лучше, чем "?" в шапке окна.

bnk>В подсказку также можно линк поставить на мануал на сайте. Проблема что стандартные контролы такую фишку не поддерживают.

Это поддерживают ToolTip'ы, которые у меня есть. Но непонятно, как удержать подсказку видимой, чтобы можно было навести курсор на линк. Возможно, с balloon tooltips это вообще нельзя, и нужно переделать на in-place.

bnk>Почему бы не рассмотреть HTML-вариант интерфейса (тот же sciter например)

Я рассматривал, но слишком уж оно толстое для той малой части функционала, которая мне требуется.

Здравствуйте, Евгений Музыченко, Вы писали:

bnk>>В подсказку также можно линк поставить на мануал на сайте. Проблема что стандартные контролы такую фишку не поддерживают.

ЕМ>Это поддерживают ToolTip'ы, которые у меня есть. Но непонятно, как удержать подсказку видимой, чтобы можно было навести курсор на линк. Возможно, с balloon tooltips это вообще нельзя, и нужно переделать на in-place.

Со стандартными тултипами это вроде не работает. Раньше для этого писали всякие классы типа
https://www.codeproject.com/Articles/3655/CPPToolTip-v2-1

Сейчас так никто не делает (даже microsoft office — весь его интерфейс сейчас это не виндовые контролы, а xml/html)

bnk>>Почему бы не рассмотреть HTML-вариант интерфейса (тот же sciter например)

ЕМ>Я рассматривал, но слишком уж оно толстое для той малой части функционала, которая мне требуется.

Можно старую версию взять, HTMLayoutSDK. Если не ошибаюсь, оно было всего ~500кб, у меня раньше использовалось когда страдал перфекционизмом
Но это полное переписывание UI по сути.

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

C>Для таких безнадежных пользователей сделать платную поддержку. Причем оплата лучше бы сразу за вопрос, а вовсе не период… То бишь один вопрос, одна оплата. Что-то типа премиум-поддержки.

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

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

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

C>Соответственно, может получиться понять, что и как переделать, улучшить, переосмыслить в подаче справочного материала.

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

C>частые вопросы вынести в F.A.Q.

Это давно есть.

C>Тогда весь ответ будет занимать полминуты копипастой

Так и делаю.

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

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

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

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

Вообще, у меня CHM-версия полностью проецируется на сайт. Имеет смысл сделать страницы более мелкими, чтобы помещались в одно-два браузерных окна?

C>Уж не помню, у кого именно из великих брендов прошедших лет был классный мем на этот случай. “Это НЕ наш клиент!”

Это я применяю в полный рост.

C>

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

На это есть другое: "если создать систему, которой сможет пользоваться даже дурак, то лишь дурак пожелает ею воспользоваться".

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

C>PPS: Я б еще посоветовал Алистера Коберна полистать про сценарии использования. Хорошо там раскладывается, причем с примерами, и вполне так структурировано как понимать пользователя и его сценарии использования.

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

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

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

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

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

ЕМ>>У меня полнотекстовый поиск изначально есть в каждом CHM. Через какое-то время выяснилось, что большинство пользователей просто не обращает внимания на вкладку Search.

_>Так это о софта зависит, если у вас скриптовый язык встроен, то полнотекстовый поиск будет задействован.

Не уловил связи между скриптовым языком и полнотекстовым поиском в отношении CHM.

_>А так обычно можно обойтись нормальным оглавлением.

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

Здравствуйте, Евгений Музыченко, Вы писали:

_>>Так это о софта зависит, если у вас скриптовый язык встроен, то полнотекстовый поиск будет задействован.
ЕМ>Не уловил связи между скриптовым языком и полнотекстовым поиском в отношении CHM.
Связь такая если ищут текст, то будут пользоваться текстовым поиском.
А если ищут сценарий использования, то оглавлением.

_>>А так обычно можно обойтись нормальным оглавлением.
ЕМ>По-моему, наличие поиска очень полезно в любой документации, объем которой превышает две-три страницы.
Не всегда понятно по каким словам искать. Например попробуйте найти описания на символ ? в C# или на любые другие стоп слова and, or ... которые выкидываются из полнотекстового индекса.

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

Здравствуйте, Евгений Музыченко, Вы писали:

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

Может тогда например какой-нибудь каталог со ссылками сделать на сценарии использования, по минимум — плейлист может?
Там под каждым видео в описании можно текст еще писать, типа ссылка на документацию например.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:

C>>Для таких безнадежных пользователей сделать платную поддержку. Причем оплата лучше бы сразу за вопрос, а вовсе не период… То бишь один вопрос, одна оплата. Что-то типа премиум-поддержки.

ЕМ>Я думал над этим, но такие пользователи склонны устраивать разборки "я вам заплатил, а вы мне не помогли". Такое хорошо для компании, где разработчики надежно защищены несколькими эшелонами сотрудников поддержки. Для одиночки это чаще всего дополнительный геморрой, который не окупается. Поэтому хочется максимально ориентировать пользователя на самопомощь, а совсем безнадежных — отсеивать.
Ну тут согласен… Нужно действовать очень аккуратно и осмотрительно…

ЕМ>Саму структуру справки я понемногу переделываю, но проблема в том, что многие вообще туда не идут, пока не ткнешь носом. Или открывают, и тупо пытаются найти подробное описание именно их конкретного сценария, которых сотни.

C>>частые вопросы вынести в F.A.Q.
ЕМ>Это давно есть.

C>>из этих частых вопросов хорошо вырисовывается основные проблемы, непонятки пользователя, что именно у них "не едет сходу".
ЕМ>С ходу не едет главным образом понимание того, что в существующих условиях принципиально невозможна абсолютная стабильность звукового потока. Упоминания об этом раскиданы по всей документации, с перекрестными ссылками. Поэтому и стараюсь любым способом загнать всех в документацию, чтобы увидели хотя бы предупреждения, зацепились за ссылки, и нашли хоть что-нибудь из общих принципов.
Ну мне кажется тут нужно делать иначе. Т.е. чтобы справка была контекстной прям под рукой. Я такое делал для развесистого меню (всплывающие подсказки для любого элемента меню + сопутствующая информация по теме, как пример: для стандартной команды "Вставить" показывалось содержание буфера обмена).

Или второй вариант: уже для контролов (кнопки, галки, комбобоксы и.т.д.) отдельное окошко рядом с основным диалогом. В нем всяки разные пояснения, ссылки на статьи на сайте и.т.д. Как окошко появляется решать Вам: можно по предложенному выше значку вопроса рядом с контролом, можно автоматически.
Что характерно: вот в таком отдельном окошке можно и сделать нечто вроде веб-интерфейса, на том же самом HTMLayout.
Что характерно, сие окошко может быть вообще отдельным exe, и соответственно зависимости от HTMLayout в основном и вовсе не будет. Просто основной exe, с уже сделанным GUI должен будет как-то взаимодействовать с этим отдельным окошком с HTMLayout (да хоть какой-нить MMF например).

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

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

Ну конечно это часть сайта, но в SiteMap сайта эта лендинг-пейдж все равно попадет?!? И гугл его заиндексит.
А по содержанию должно быть что-то конкретное, решение какой-нить конкретной задачи (которую наверное частенько гуглят пользователи).
А внизу такой страницы, стандартные "См. также", ну и ссылки там на близкие по тематике статьи, форму тех. поддержки и.т.д.

ЕМ>Вообще, у меня CHM-версия полностью проецируется на сайт. Имеет смысл сделать страницы более мелкими, чтобы помещались в одно-два браузерных окна?

C>>Уж не помню, у кого именно из великих брендов прошедших лет был классный мем на этот случай. “Это НЕ наш клиент!”
ЕМ>Это я применяю в полный рост.
А без этого никуда теперь

C>>PPS: Я б еще посоветовал Алистера Коберна полистать про сценарии использования. Хорошо там раскладывается, причем с примерами, и вполне так структурировано как понимать пользователя и его сценарии использования.

ЕМ>Это все хорошо, когда продукт независимый, и сам может организовать выполнение сценария. У меня совершенно не так.
Та н-е-е-е, там другое у Алистера. Там как выявлять сценарии (по шагам, цели, причины, шаги) там больше про суть. Остальное уже как профессионалы мы и сами сделаем, это уже технические+юзабильские подробности.

Вот эта книга на Озоне: https://www.ozon.ru/context/detail/id/8747662/
Имхо, она и в сети в е-виде мне как-то вроде попадалась. Можно порыскать

А вот вроде неплохая выжимка про книгу на Хабре https://habr.com/ru/post/468267/

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как известно, в Windows 95 многие системные диалоги были с контекстной справкой по интерфейсу (стиль WS_EX_CONTEXTHELP, добавлявший в шапку значок "?", чтобы открывать справку по элементу интерфейса, просто указав его). В XP его убрали из бОльшей части диалогов, а в висте выпилили окончательно (об этом как-то писал Чен). Поддержка самой фичи осталась, но реализована она через задницу — этот стиль несовместим с WS_MINIMIZE, для минимизации окна приходится добавлять кнопку в клиентской области, поскольку добавление кнопок в шапку — хак еще тот.

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

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

Фича умерла потому, что она решает несуществующую проблему.
Неопытный пользователь испытывает затруднения не потому, что не знает, что делает конкретная кнопка или чекбокс. А потому, что не понимает, как ему сделать что-то.
Ну вот из моего недавнего опыта: монтируем фильм в Adobe Premiere. Надо уменьшить громкость звука в одном из фрагментов. И куда я буду тыкать этой волшебной кнопкой-с-вопросом? В меню? В тулбары? В полоску звуковой дорожки?
Это какой-то квест.
В итоге, для данной конкретной задачи, в связи с отсутствием в Адобе нормальной пользовательской документации, самый быстрый способ — это погуглить. Тогда мы сразу найдём видеоролик: https://www.youtube.com/watch?v=rshxsWSiHa8&t=73s

Кстати, это один из немногих случаев, в которых я готов смотреть видео — ровно потому, что там сразу показано, куда нажимать, и что крутить.
Текстовая документация, которую я предпочитаю в 13 случаях из 14, конкретно в этом случае потребует от меня мучительно искать описанные там элементы управления. Особенно офигенно, когда читаешь справку по англоязычной версии, а пользуешься русифицированной. Или просто по какой-то причине гуя отличается от той, которую описывал автор. (Вот я щас Power BI осваиваю, там такое через раз).

Хелп должен идти от задачи, а не от элемента интерфейса. Тот же микрософт заменил context help встроенным поиском по фичам. То есть, к примеру, надо мне узнать, сколько символов в черновике рассказа, который я пишу в рамках домашки по писательскому курсу. А я не знаю, где Word count спрятано в новомодном MS Word 2019. Никакая кнопочка вопросика мне в этом никак не поможет — хоть утыкайся. А помогает поиск, причём более-менее приблизительный. То есть можно искать count characters, можно char count, и всё равно найдётся нужный action.

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

S>Неопытный пользователь испытывает затруднения не потому, что не знает, что делает конкретная кнопка или чекбокс. А потому, что не понимает, как ему сделать что-то.

Это уже здесь обсуждалось.

S>В итоге, для данной конкретной задачи, в связи с отсутствием в Адобе нормальной пользовательской документации

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

S>То есть, к примеру, надо мне узнать, сколько символов в черновике рассказа, который я пишу в рамках домашки по писательскому курсу. А я не знаю, где Word count спрятано в новомодном MS Word 2019. Никакая кнопочка вопросика мне в этом никак не поможет — хоть утыкайся. А помогает поиск, причём более-менее приблизительный. То есть можно искать count characters, можно char count, и всё равно найдётся нужный action.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А по каким словам в этом поиске можно найти пошаговую инструкцию по написанию рассказа, повести, романа, которые гарантированно станут популярными и будут стабильно продаваться? У массового-то пользователя задача стоит именно так.
Это — уже в гугл
Такие пошаговые инструкции стоят денег.