Здравствуйте, Carc, Вы писали:
C>А зачем правка то? Для самого себя что ли напоминалка? Если разобрался, то зачем писать самому себе такую справку? Если не разобрался, то писать и нечего… Не? C>Какой смысл то?
Коллега, вы когда-нибудь работали со сложными системами, описывающими сложные бизнес-процессы, например, математические моделирование нефтепереработки по экономическим критериям? Например, пользователь А создал некоторую модельную сущность, допустим описал мелкий опт дизелей через станцию Замухлюевка отдельной переменной. Пользователь Б увидел какую-то переменную и подумал: "чё за хрень?" А вот чтобы он так не подумал, пользователь А написал комментарий, мол ввел спецпеременную чтобы оценить переброску дизелей со станций Задрищинск Товарная 1 и 2 на Замухлюевку. И тогда пользователь Б сразу поймет что вообще происходит. А поскольку пользователей много, у каждого свои задачи, каждый решает их по своему, комментарии становятся необходимы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Насколько такая контекстная помощь нынче востребована неопытными пользователями? Есть ли варианты с похожей функциональностью, но удобнее?
Нынче принято видео ролик на youtube смотреть как пользоваться программой, это проще, понятней и не требует установки да и посмотреть можно с телефона
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как известно, в Windows 95 многие системные диалоги были с контекстной справкой по интерфейсу ЕМ>Насколько такая контекстная помощь нынче востребована неопытными пользователями?
Судя по тому, что никто даже не заметил, как её убрали, не особо-то и была востребована! По кр. мере лично вообще никогда не юзал.
На мой взгляд, у диалогов не должно быть такой тупой подсказки "тыкни в контрол, читай!". Диалог — это логически связанный набор редакторов, предназначенный для решения конкретной задачи. Если ты не понимаешь задачу, тебе и подсказка по комбобоксу не поможет. Все фэйлы с диалогами как правило из-за пробелов в знаниях оператора. Нет смысла в настройке сети писать "это поле для ввода маски сети" — ламер ни "маски", ни "маски подсети" никогда не знал. Хочешь редактировать — прочти хотя бы 1-страничный хэлп. И вот как раз на него должна вести F1, нажатая из диалога. Думаю, так будет наиболее разумно.
Как известно, в Windows 95 многие системные диалоги были с контекстной справкой по интерфейсу (стиль WS_EX_CONTEXTHELP, добавлявший в шапку значок "?", чтобы открывать справку по элементу интерфейса, просто указав его). В XP его убрали из бОльшей части диалогов, а в висте выпилили окончательно (об этом как-то писал Чен). Поддержка самой фичи осталась, но реализована она через задницу — этот стиль несовместим с WS_MINIMIZE, для минимизации окна приходится добавлять кнопку в клиентской области, поскольку добавление кнопок в шапку — хак еще тот.
Как с этим обстоит в более других системах? На мой взгляд, это очень удобная штука для новичка в изучении мало-мальски сложного интерфейса, где много кнопок, тулбаров, чекбоксов и прочего. ToolTips позволяют понять, что к чему, но описание поведения конкретных элементов в обычной справке приходится разыскивать по названиям или по картинкам, это весьма раздражает.
Насколько такая контекстная помощь нынче востребована неопытными пользователями? Есть ли варианты с похожей функциональностью, но удобнее?
Здравствуйте, Kernan, Вы писали:
K>Где сложнее, там саппорт есть
Так в том и вопрос, что в саппорт часто пишут с вопросами, которые полностью и подробно отвечены в справке. Другое дело, что справка довольно объемная, и найти эти ответы можно либо по оглавлению, либо контекстным поиском, а этого большинство пользователей не умеет. Пользователь мог бы довольно быстро найти ответ, ткнув в элемент интерфейса, имеющий отношение к вопросу, но он не делает и этого. В этой ситуации ему можно как-то помочь иначе, чем тупо брать за руку и водить туда-сюда?
K>ролики в ютубе как использовать софт
Когда я впервые задумался о том, чтобы сделать ролик, выяснилось, что их уже в количестве наделали сами пользователи. Многие так и пишут, что разбирались по этим роликам. Таких конкретных примеров в сети выше крыши, но проблема в том, что любой конкретный пример, как правило, нельзя тупо перенести на похожую конфигурацию — нужно его немного изменить, а чтобы понять, как именно изменить, нужно понимать, как работает вся эта кухня.
K>например, уроки по фотошопу
Во, хороший пример. Сколько нужно "уроков по фотошопу", чтобы человек, не понимающий принципов смешения цветов, наложения слоев и подобных элементарных (в отношении компьютерной графики) вещей, научился уверенно в нем работать? Ну посмотрит он два, три или десять примеров, где выделяют области, фильтруют цвета, разделяют на слои и т.п., но поленится разбираться в принципах и деталях. Если у него похожая ситуация — повторит и получит нечто подобное, а если другая — будет дергать саппорт, присылая свои картинки и сумбурно описывая, что он хотел бы с ними сделать. Вот такому пользователю можно как-то помочь иначе, чем непосредственной работой конкретно с ним?
ЕМ>>А на мой интерфейс регулярно жалуются, что сложно в изучении.
K>Значит тебе явно подают сигналы что у тебя плохой UX дизайн
Я ж там специально подчеркнул, что UI является следствием концепции/модели, а они придуманы не мной (это собственная виндовая модель), и влиять на них без применения хакерских технологий, которые чреваты, я не могу.
K>Ты телеметрию в свой софт вставил как я тебе предлагал? Нет, не вставил. Ты не знаешь как используют твой софт, т.е. тебе не известны пользовательские сценарии
Сценарии мне известны и без телеметрии — пользователи сами их в изобилии описывают. В типовом случае это выглядит, как "у меня есть приложения A, B и C, мне нужно передать звук от A к B, от C — к A, от B — к A и C, и чтоб при этом ничего не трещало, не фонило и работало стабильно". В применении, скажем, к кулинарии, это будет примерно "купила мясорубку, блендер и мультиварку, в продуктах и готовке ничего не понимаю, изучать некогда, как мне по-быстрому приготовить котлеты под грибным соусом, и чтоб повкуснее?".
K>они могут быть не тривиальные и не покрываются справкой в которую они вряд ли ходит.
Именно так — даже если выделить несколько типовых сценариев, в них все равно будут меняться какие-то параметры. Если описывать каждый набор отдельно, справка распухнет до неприличия, и найти нужный станет еще сложнее.
K>Люди из принципа просто снесут твой софт и купят у конкурентов, либо купят МАК и/или железо, вот и всё.
Те, которые "из принципа" мне малоинтересны. Им чаще всего нужны готовые решения, а не инструмент. У меня — именно инструмент.
K>Никто не будет тратить своё время на что-то непонятное если это не отраслевой стандарт.
Это именно отраслевой стандарт — звуковая подсистема Windows. Она такая уже пятнадцать лет — с выхода висты. Но ее, как и любые звуковые технологии вообще, мало кто понимает целиком — или понимают отдельные части, домысливая остальные, или вообще не понимают, пользуясь интуитивно.
K>Единственный реальный факт о котором ты сам и говоришь — пользователи жалуются на сложность твоего интерфейса.
Еще раз: не интерфейса, как такового, а модели, которую отражает интерфейс, и которая придумана не мной. Если смотреть в справку, отталкиваясь от элементов интерфейса ("что это и зачем?"), то можно найти нужные описания быстрее.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как известно, в 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.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
C>>Если нормально расположить, то не зарябит. ЕМ>А как их "нормально" расположить вот в таком окне?
Да, тут действительно сложновато расположить…
Тут имхо, или всё окно рефакторить, что я так понял, не вариант.
Или тот же знак вопросика, но показывать его динамически.
Примерно такой юз-кейс 1) Пользователь наводит мыша на контрол\галку\кнопку\прочия.
2) Если к нему есть дополнительная инфа, та которая будет во всплывающей подсказке,
то появляется этот самый значок вопросика.
Появляется где-то рядом: справа например, ну или как то "заалгоритмить" вычисление расположение такого значка-вопросика рядом с контролом (справа, слева или как то там).
3) Ну дальше просто: щелчок по появившемуся значку-вопросику показывает ту самую всплывающую подсказку с доп. инфой, ссылками и прочия. Подсказка автоматически не закрывается. Чтобы пользователь мог спокойно читать, скроллить подсказку, если там много инфы (список). Закрывать подсказку обычным крестиком в окне подсказки.
4) Если пользователь не щелкал по значку-вопросика в п.3 выше, то при уходе мыша с контрола\галки\кнопки\прочия прячется и этот самый значок-вопросик.
PS: что характерно, все тупо можно прописать кодом, не мучая шаблон UI. В этом случае значок-вопросик один на всё окно. Он только показывается рядом с нужными галками\кнопками\прочия.
Да и технически несложно реализнуть. Значок-вопросик при показе знает к какому контролу\галке\кнопке\прочия сию секунду он имеет отношение (да хоть Значок-вопросик::SetWindowLong(GWL_USERDATA + ID контрола\галки\кнопки).
Соответственно, тогда и обработку по щелчку уже по значку-вопросику можно централизовано написать (нехай шлётЪ какую-нить WM_NOTIFY самому окну с настройками).
PPS: и чуть не забыл… Курсор над значком-вопросиком должен быть ака над ссылками, веб-браузёвый… Чтобы явно намекать пользователю, что этот значок-вопросиёк — кликабельный.
Здравствуйте, kov_serg, Вы писали:
_>Для этого есть cправка, лучше всего в chm
Вот есть у пользователя справка в CHM, которая по F1 открывается на заглавной странице. И есть в интерфейсе какая-нибудь кнопка или движок, при наведении на которые можно увидеть всплывающую подсказку, что это вообще такое. А звена, связывающего этот элемент управления с конкретным местом в CHM, где он подробно описан, нет. Отыскиванием в тексте справки нужного места почему-то загружают пользователя. Как это соотносится с usability?
_>Но если взять то же photoshop то сценарии использования вообще не следуют из описания программы и её интерфейса.
Сценарии использования — это уже следующий уровень. Я пока исключительно про описание работы конкретных элементов интерфейса.
Re[3]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А по каким словам в этом поиске можно найти пошаговую инструкцию по написанию рассказа, повести, романа, которые гарантированно станут популярными и будут стабильно продаваться? У массового-то пользователя задача стоит именно так.
Это — уже в гугл
Такие пошаговые инструкции стоят денег.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Контекстная справка по элементам интерфейса
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>Насколько такая контекстная помощь нынче востребована неопытными пользователями? Есть ли варианты с похожей функциональностью, но удобнее? _>Нынче принято видео ролик на youtube смотреть как пользоваться программой, это проще, понятней и не требует установки да и посмотреть можно с телефона
Таких людей надо пытать и заставить посмотреть точно такой же ролик, например, по планированию и разворачиванию Active Directory — взять какого-нибудь Моргенштерна и пусть на пальцах рассказывает под свои йоу это все часа 2-3.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Насколько такая контекстная помощь нынче востребована неопытными пользователями?
Не востребована. Справку и подсказки в примитивных приложениях никто не читает, более того, все эти всплывающие подсказки захламляют UI и требуют эфортов на поддержку. Сейчас всё делается через визуальную подачу, или, как это называется, через нормальный UX дизайн. За реальной справкой ходят в гугол, а с него либо на reddit/SO, либо на тематический ресурс, либо вообще в таки места как 4chan.
Я уже несколько раз объяснял, попробую объяснить через еще одну аналогию. Представьте, что для езды на автомобиле не нужно учиться и сдавать экзамен. Человек покупает автомобиль, но не понимает, как он устроен, не знает правил, не умеет ездить, ориентироваться ни на дороге, ни на карте, учиться всему этому или не хочет, или просто не знает, с какой стороны подступиться. Он лезет в гугл, где находит 100500 статей и роликов "как на Ford Focus доехать от Москвы до Петербурга", "как на Ладе Приоре объехать пост ДПС под Саратовом" и т.п. А у него Toyota Tundra, и ему нужно отвезти холодильник в загородный дом. Но ни ролика, ни статьи о том, как везти холодильник на Toyota Tundra именно по этому маршруту, он не находит, поэтому садится в машину и начинает тупо нажимать кнопки/педали и дергать рычаги в надежде, что машина поедет хоть куда-нибудь. Почему бы именно в этот момент ему не подсунуть информацию о том, как заводить машину, трогаться и рулить, разместив где-нибудь рядом информацию о ПДД, дорожных указателях, картах и прочем?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Насколько такая контекстная помощь нынче востребована неопытными пользователями? Есть ли варианты с похожей функциональностью, но удобнее?
Есть две категории пользователей, те, кто застал Win95/98 и помнят про эту опцию, из них есть те, кто ею пользовался и негодуют, когда в новых версиях не находят этой фичи. И есть те, кто никогда ею не пользовались, они ничего не заметят. Множество тех, кому именно эта фича нужна постоянно сокращается, но с другой стороны, контекстная помощь бывает нужна. Причем не просто статическая справка, а редактируемая, чтобы пользователь мог добавлять свои пометки. Мы решили это следующим образом: по F1 (это пока помнят все), открывается диалог с возможностью правки (в формате markdown) со справкой на данный вид интерфейса. Пользователи могут добавлять свои комментарии к справке. Оказалось полезная фича, пользователи одобрили, хотя привыкали некоторое время, все-таки непривычная опция.
Счастье — это Glück!
Re[2]: Контекстная справка по элементам интерфейса
Здравствуйте, Dym On, Вы писали:
DO>Есть две категории пользователей, те, кто застал Win95/98 и помнят про эту опцию, из них есть те, кто ею пользовался и негодуют, когда в новых версиях не находят этой фичи. И есть те, кто никогда ею не пользовались, они ничего не заметят. Множество тех, кому именно эта фича нужна постоянно сокращается, но с другой стороны, контекстная помощь бывает нужна. Причем не просто статическая справка, а редактируемая, чтобы пользователь мог добавлять свои пометки. Мы решили это следующим образом: по F1 (это пока помнят все), открывается диалог с возможностью правки (в формате markdown) со справкой на данный вид интерфейса. Пользователи могут добавлять свои комментарии к справке. Оказалось полезная фича, пользователи одобрили, хотя привыкали некоторое время, все-таки непривычная опция.
А зачем правка то? Для самого себя что ли напоминалка? Если разобрался, то зачем писать самому себе такую справку? Если не разобрался, то писать и нечего… Не?
Какой смысл то?
Или эти правки как-то уходят разработчикам? Кагбэ такой эдакий фидбек. Вот такое, наверное, было бы интересно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Насколько такая контекстная помощь нынче востребована неопытными пользователями?
Очень востребована
ЕМ>Есть ли варианты с похожей функциональностью, но удобнее?
Да, часто применяется в мобильных приложениях так называемый onboarding, когда для нового пользователя или после обновления интерфейса отображается инструкция прямо поверх интерфейса со стрелками куда нажимать и что получить.
Re[4]: Контекстная справка по элементам интерфейса
Здравствуйте, Dym On, Вы писали:
DO>Коллега, вы когда-нибудь работали со сложными системами, описывающими сложные бизнес-процессы, например, математические моделирование нефтепереработки по экономическим критериям? Например, пользователь А создал некоторую модельную сущность, допустим описал мелкий опт дизелей через станцию Замухлюевка отдельной переменной. Пользователь Б увидел какую-то переменную и подумал…
А-а-а-а, я просто Вас не понял. Получается, что пользователь уже комментирует не прошитые какие-то настройки, галки и прочия. А собственный суть "контент" (модель, сущность или как там). Тогда действительно это логично, ибо суть "комментарии", причем наглядные и на виду.
Здравствуйте, Carc, Вы писали:
C>А-а-а-а, я просто Вас не понял. Получается, что пользователь уже комментирует не прошитые какие-то настройки, галки и прочия. А собственный суть "контент" (модель, сущность или как там). Тогда действительно это логично, ибо суть "комментарии", причем наглядные и на виду.
Да, просто такие софты с моделями поставляются в некоторой базовой комплектации, которая потом развивается пользователями самостоятельно.
Счастье — это Glück!
Re[2]: Контекстная справка по элементам интерфейса
Здравствуйте, Kolesiki, Вы писали:
K>Судя по тому, что никто даже не заметил, как её убрали, не особо-то и была востребована!
В простых диалогах с тремя кнопками — не была. А в окнах со сложным интерфейсом ее сама MS не применяла. Возможно, также и потому, что реализовано оно через задницу — альтернативно кнопкам Minimize/Maximize. А так-то идея вполне годная.
K>На мой взгляд, у диалогов не должно быть такой тупой подсказки "тыкни в контрол, читай!". Диалог — это логически связанный набор редакторов, предназначенный для решения конкретной задачи.
Это простые диалоги — самостоятельные или последовательные этапы wizard'ов. В таких случаях вопросов по интерфейсу почти никогда не возникает. А в окнах с большим количеством элементов управления (такие окна нередко бывают и диалогами) такая справка в самый раз.
K>прочти хотя бы 1-страничный хэлп. И вот как раз на него должна вести F1, нажатая из диалога.
А если в том хэлпе минимум полста страниц, и F1, нажатая в окне, всегда ведет на первую, что в этом хорошего?
Re[2]: Контекстная справка по элементам интерфейса
Здравствуйте, kov_serg, Вы писали:
_>Нынче принято видео ролик на youtube смотреть как пользоваться программой, это проще, понятней
Проще/понятней это только для тупых, которые ограничиваются столь же тупым подмножеством функций. Этим вообще надо делать большую зеленую кнопку "сделать зашибись", и никаких роликов не нужно.
_>и не требует установки да и посмотреть можно с телефона
Когда программа уже установлена, и человек с нею работает, но еще не запомнил особенностей применения всех элементов управления — ему снова и снова смотреть ролик, наугад отыскивая в нем нужные места? Если делать это параллельно с телефона — поможет?
Re[4]: Контекстная справка по элементам интерфейса
Здравствуйте, Dym On, Вы писали:
DO>Например, пользователь А создал некоторую модельную сущность, допустим описал мелкий опт дизелей через станцию Замухлюевка отдельной переменной.
Сама идея комментирования таких вещей совершенно правильна, но при чем здесь справка по самой программе? Для комментирования сущностей, создаваемых в рабочих базах, предусматриваются специальные поля в соответствующих структурах.
Re[3]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда программа уже установлена, и человек с нею работает, но еще не запомнил особенностей применения всех элементов управления — ему снова и снова смотреть ролик, наугад отыскивая в нем нужные места? Если делать это параллельно с телефона — поможет?
Для этого есть cправка, лучше всего в chm или в печатном виде (несколько стелажей как например к атс)
Но если взять то же photoshop то сценарии использования вообще не следуют из описания программы и её интерфейса. И все описания как правило описывает интерфейс и базовые функции.
А приёмы которые применяют дизайнеры вообще из разряда "а что так можно было?".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Сама идея комментирования таких вещей совершенно правильна, но при чем здесь справка по самой программе? Для комментирования сущностей, создаваемых в рабочих базах, предусматриваются специальные поля в соответствующих структурах.
Это просто пример. Конечно нужно смотреть на функционал диалога и назначение программы в целом.
Счастье — это Glück!
Re[3]: Контекстная справка по элементам интерфейса
Здравствуйте, RonWilson, Вы писали:
RW>Таких людей надо пытать и заставить посмотреть точно такой же ролик, например, по планированию и разворачиванию Active Directory — взять какого-нибудь Моргенштерна и пусть на пальцах рассказывает под свои йоу это все часа 2-3.
Вас никто не заставляет снимать нудные ролики на 2-3 часа. Достаточно 15-30 секундного ролика что бы привлечь внимание потенциального клиента. А 3-5 мин на демонстрацию своих уникальных функций, в руках профессионала будут более ценные чем 200 листов текста. Взгляните на blender так книг с описанием — учитаетесь. Но что бы понять как что-то сделать проще посмотреть ролик и только потом пользоваться справкой.
Здравствуйте, Kernan, Вы писали:
K>Справку и подсказки в примитивных приложениях никто не читает
Про примитивные речи нет. Вот у меня интерфейс однозначно не примитивный, но бывают и еще сложнее, и далеко не везде есть контекстная помощь. А на мой интерфейс регулярно жалуются, что сложно в изучении. Точнее, жалуются не столько на сам интерфейс, сколько на концепции и правила применения продукта (это не мой выбор, в звуковой подсистеме винды оно так by design, для получения нетривиального поведения приходится применять непростые алгоритмы).
K>За реальной справкой ходят в гугол, а с него либо на reddit/SO
А зачем, если вся нужная информация есть во встроенной справке? Из принципа, из врожденного чувства противоречия?
Я вот сперва пытаюсь найти нужное в родной справке, но они, как правило, достаточно бедные, и не покрывают тонкостей использования, за которыми и приходится ходить в гугол.
Re[5]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот есть у пользователя справка в CHM, которая по F1 открывается на заглавной странице. И есть в интерфейсе какая-нибудь кнопка или движок, при наведении на которые можно увидеть всплывающую подсказку, что это вообще такое. А звена, связывающего этот элемент управления с конкретным местом в CHM, где он подробно описан, нет. Отыскиванием в тексте справки нужного места почему-то загружают пользователя. Как это соотносится с usability?
Ну что вам мешает сразу в нужное место в chm файле открывать? http://www.help-info.de/en/Help_Info_HTMLHelp/hh_context-id.htm
Дело в том чтобы ткнуть стрелкой со знаком вопроса в контрол, до этого контрола еще надо добраться. Что нынче бывает весьма не тривиально.
А так обычно в chm есть полнотекстовый поиск и оглавление.
ps: Самые простые принципы обучения — подрожание (делай как я) и только когда уже умеют пользоваться за деталями лезут в справочники и то не всегда. Плюс стараются делать интуитивно понятно (т.е. как у всех что бы принцип наименьшего удивления работал)
Re[3]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Проще/понятней это только для тупых, которые ограничиваются столь же тупым подмножеством функций. Этим вообще надо делать большую зеленую кнопку "сделать зашибись", и никаких роликов не нужно.
Так-то это вообще для всех хороший вариант, не только для тупых.
Всякие опции и настройки появляются зачастую потому, что разработчик сам не знает, как лучше, и перекладывает проблему выбора на пользователя.
С больной головы на здоровую, как говорится.
Не заставляйте пользователя думать (с) Психбольница в руках пациентов
Re[3]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> Вот у меня интерфейс однозначно не примитивный, но бывают и еще сложнее, и далеко не везде есть контекстная помощь.
Где сложнее, там саппорт есть, ролики в ютубе как использовать софт, например, уроки по фотошопу, фьюжн 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? Делать для них дополнительные описания, примеры, или записать в безнадежно тупые и махнуть рукой?
Re[4]: Контекстная справка по элементам интерфейса
Здравствуйте, bnk, Вы писали:
ЕМ>>делать большую зеленую кнопку "сделать зашибись"
bnk>Так-то это вообще для всех хороший вариант, не только для тупых.
Вариант хороший, когда пространство решений небольшое, и продукт в состоянии сам обеспечить нужное решение.
bnk>Всякие опции и настройки появляются зачастую потому, что разработчик сам не знает, как лучше, и перекладывает проблему выбора на пользователя.
В конкретно моем случая я знаю, как лучше. Проблема в том, что основной продукт не из тех, что могут все сделать сами. Он лишь связующее звено между большим количеством разнообразных приложений, которые могут с ним работать (именно они с ним, а не он с ними). Причем работать не непосредственно, а через промежуточные виндовые интерфейсы, сквозь которые продукт не видит, кто и как именно его использует. И настройка самого продукта нередко зависит от настроек этих приложений. Вот и догадайтесь, как именно в каждом из сотен возможных вариантов будет выглядеть "зашибись" для конкретного пользователя.
Re[5]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
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? Делать для них дополнительные описания, примеры, или записать в безнадежно тупые и махнуть рукой?
Добавить обучающий режим с объяснением возможностей или виртуального помошника, который по патернам поведения будет сообщать что то что вы пытаетесь сделать можно сделать проще или отсылать в поддержку
Re[7]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У меня полнотекстовый поиск изначально есть в каждом CHM. Через какое-то время выяснилось, что большинство пользователей просто не обращает внимания на вкладку Search.
Так это о софта зависит, если у вас скриптовый язык встроен, то полнотекстовый поиск будет задействован. А так обычно можно обойтись нормальным оглавлением.
Re[6]: Контекстная справка по элементам интерфейса
Здравствуйте, bnk, Вы писали:
bnk>Мне кажется в этом случае классическая документация с поиском.
Она есть с момента первого выпуска продукта. Вопрос — как загнать пользователя в тот поиск. Рекомендации на сайта и на заглавной странице документации помогают плохо.
bnk>Ну или просто значки "?" рядом с каждым контролом
Это идея, спасибо. Скорее всего, будет работать лучше, чем "?" в шапке окна.
bnk>В подсказку также можно линк поставить на мануал на сайте. Проблема что стандартные контролы такую фишку не поддерживают.
Это поддерживают ToolTip'ы, которые у меня есть. Но непонятно, как удержать подсказку видимой, чтобы можно было навести курсор на линк. Возможно, с balloon tooltips это вообще нельзя, и нужно переделать на in-place.
bnk>Почему бы не рассмотреть HTML-вариант интерфейса (тот же sciter например)
Я рассматривал, но слишком уж оно толстое для той малой части функционала, которая мне требуется.
Re[7]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>В подсказку также можно линк поставить на мануал на сайте. Проблема что стандартные контролы такую фишку не поддерживают.
ЕМ>Это поддерживают ToolTip'ы, которые у меня есть. Но непонятно, как удержать подсказку видимой, чтобы можно было навести курсор на линк. Возможно, с balloon tooltips это вообще нельзя, и нужно переделать на in-place.
Сейчас так никто не делает (даже microsoft office — весь его интерфейс сейчас это не виндовые контролы, а xml/html)
bnk>>Почему бы не рассмотреть HTML-вариант интерфейса (тот же sciter например)
ЕМ>Я рассматривал, но слишком уж оно толстое для той малой части функционала, которая мне требуется.
Можно старую версию взять, HTMLayoutSDK. Если не ошибаюсь, оно было всего ~500кб, у меня раньше использовалось когда страдал перфекционизмом
Но это полное переписывание UI по сути.
Re[8]: Контекстная справка по элементам интерфейса
Здравствуйте, Carc, Вы писали:
C>Для таких безнадежных пользователей сделать платную поддержку. Причем оплата лучше бы сразу за вопрос, а вовсе не период… То бишь один вопрос, одна оплата. Что-то типа премиум-поддержки.
Я думал над этим, но такие пользователи склонны устраивать разборки "я вам заплатил, а вы мне не помогли". Такое хорошо для компании, где разработчики надежно защищены несколькими эшелонами сотрудников поддержки. Для одиночки это чаще всего дополнительный геморрой, который не окупается. Поэтому хочется максимально ориентировать пользователя на самопомощь, а совсем безнадежных — отсеивать.
C>оструктурить эти вопросы, понять откуда ноги растут, и понять глубинные причины, почему вопрошают.
Глубинные причины давно понятны — сфера непростая, интуитивно непонятная, а разбираться большинству лень. Достаточно посмотреть, сколько по литературе и сети гуляет откровенных мифов о качестве и стабильности цифрового звука, которые они трудолюбиво пересказывают друг другу, чтобы потерять остатки надежды на нормальное образование в этой области.
C>Соответственно, может получиться понять, что и как переделать, улучшить, переосмыслить в подаче справочного материала.
Саму структуру справки я понемногу переделываю, но проблема в том, что многие вообще туда не идут, пока не ткнешь носом. Или открывают, и тупо пытаются найти подробное описание именно их конкретного сценария, которых сотни.
C>частые вопросы вынести в F.A.Q.
Это давно есть.
C>Тогда весь ответ будет занимать полминуты копипастой
Так и делаю.
C>из этих частых вопросов хорошо вырисовывается основные проблемы, непонятки пользователя, что именно у них "не едет сходу".
С ходу не едет главным образом понимание того, что в существующих условиях принципиально невозможна абсолютная стабильность звукового потока. Упоминания об этом раскиданы по всей документации, с перекрестными ссылками. Поэтому и стараюсь любым способом загнать всех в документацию, чтобы увидели хотя бы предупреждения, зацепились за ссылки, и нашли хоть что-нибудь из общих принципов.
C>И вот енту выжимку в мыслях оформить уже как лендинг именно под эти частые вопросы у себя на сайте.
Именно отдельную страницу? Чем это лучше отдельного раздела? Мне-то больше нравятся как раз мелкие страницы с перекрестными ссылками, но нынче ж общий тренд к слеплению всего на одной большой странице. Мне это кажется неудобным, но специалисты уверяют, что это и есть то, что нужно юзеру.
Вообще, у меня CHM-версия полностью проецируется на сайт. Имеет смысл сделать страницы более мелкими, чтобы помещались в одно-два браузерных окна?
C>Уж не помню, у кого именно из великих брендов прошедших лет был классный мем на этот случай. “Это НЕ наш клиент!”
Это я применяю в полный рост.
C>
C>Думать, что программист такой же пользователь, это великое заблуждение.
На это есть другое: "если создать систему, которой сможет пользоваться даже дурак, то лишь дурак пожелает ею воспользоваться".
Тут еще проблема в том, что оголтелый маркетинг воспитывает в народе убеждение, будто каждая кухарка может управлять государством любой дурак может без умственных затрат делать сколь угодно сложные вещи. Когда у дураков это не получается, они обвиняют почему-то разработчиков, а не маркетологов.
C>PPS: Я б еще посоветовал Алистера Коберна полистать про сценарии использования. Хорошо там раскладывается, причем с примерами, и вполне так структурировано как понимать пользователя и его сценарии использования.
Это все хорошо, когда продукт независимый, и сам может организовать выполнение сценария. У меня совершенно не так.
Re[8]: Контекстная справка по элементам интерфейса
Здравствуйте, kov_serg, Вы писали:
_>Добавить обучающий режим с объяснением возможностей или виртуального помошника, который по патернам поведения будет сообщать что то что вы пытаетесь сделать можно сделать проще или отсылать в поддержку
Я бы с удовольствием, но проблема в том, что управление самим продуктом — лишь вторичная задача, а первичная — управление приложениями, которые его используют.
Re[8]: Контекстная справка по элементам интерфейса
Здравствуйте, kov_serg, Вы писали:
ЕМ>>У меня полнотекстовый поиск изначально есть в каждом CHM. Через какое-то время выяснилось, что большинство пользователей просто не обращает внимания на вкладку Search.
_>Так это о софта зависит, если у вас скриптовый язык встроен, то полнотекстовый поиск будет задействован.
Не уловил связи между скриптовым языком и полнотекстовым поиском в отношении CHM.
_>А так обычно можно обойтись нормальным оглавлением.
По-моему, наличие поиска очень полезно в любой документации, объем которой превышает две-три страницы.
Re[9]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
_>>Так это о софта зависит, если у вас скриптовый язык встроен, то полнотекстовый поиск будет задействован. ЕМ>Не уловил связи между скриптовым языком и полнотекстовым поиском в отношении CHM.
Связь такая если ищут текст, то будут пользоваться текстовым поиском.
А если ищут сценарий использования, то оглавлением.
_>>А так обычно можно обойтись нормальным оглавлением. ЕМ>По-моему, наличие поиска очень полезно в любой документации, объем которой превышает две-три страницы.
Не всегда понятно по каким словам искать. Например попробуйте найти описания на символ ? в C# или на любые другие стоп слова and, or ... которые выкидываются из полнотекстового индекса.
Вы же пользователю предоставляете программу которая решает его конкретную задачу, вот и снимите пару коротких роликов пошагово демонстрирующих эти сценарии использования. Это снимит огромное количество обращений в поддержку. Ссылки на эти ролики можете вставить в документацию или в startup tips.
Re[5]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда я впервые задумался о том, чтобы сделать ролик, выяснилось, что их уже в количестве наделали сами пользователи. Многие так и пишут, что разбирались по этим роликам. Таких конкретных примеров в сети выше крыши, но проблема в том, что любой конкретный пример, как правило, нельзя тупо перенести на похожую конфигурацию — нужно его немного изменить, а чтобы понять, как именно изменить, нужно понимать, как работает вся эта кухня.
Может тогда например какой-нибудь каталог со ссылками сделать на сценарии использования, по минимум — плейлист может?
Там под каждым видео в описании можно текст еще писать, типа ссылка на документацию например.
Re[9]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Carc, Вы писали:
C>>Для таких безнадежных пользователей сделать платную поддержку. Причем оплата лучше бы сразу за вопрос, а вовсе не период… То бишь один вопрос, одна оплата. Что-то типа премиум-поддержки.
ЕМ>Я думал над этим, но такие пользователи склонны устраивать разборки "я вам заплатил, а вы мне не помогли". Такое хорошо для компании, где разработчики надежно защищены несколькими эшелонами сотрудников поддержки. Для одиночки это чаще всего дополнительный геморрой, который не окупается. Поэтому хочется максимально ориентировать пользователя на самопомощь, а совсем безнадежных — отсеивать.
Ну тут согласен… Нужно действовать очень аккуратно и осмотрительно…
ЕМ>Саму структуру справки я понемногу переделываю, но проблема в том, что многие вообще туда не идут, пока не ткнешь носом. Или открывают, и тупо пытаются найти подробное описание именно их конкретного сценария, которых сотни.
C>>частые вопросы вынести в F.A.Q. ЕМ>Это давно есть.
C>>из этих частых вопросов хорошо вырисовывается основные проблемы, непонятки пользователя, что именно у них "не едет сходу". ЕМ>С ходу не едет главным образом понимание того, что в существующих условиях принципиально невозможна абсолютная стабильность звукового потока. Упоминания об этом раскиданы по всей документации, с перекрестными ссылками. Поэтому и стараюсь любым способом загнать всех в документацию, чтобы увидели хотя бы предупреждения, зацепились за ссылки, и нашли хоть что-нибудь из общих принципов.
Ну мне кажется тут нужно делать иначе. Т.е. чтобы справка была контекстной прям под рукой. Я такое делал для развесистого меню (всплывающие подсказки для любого элемента меню + сопутствующая информация по теме, как пример: для стандартной команды "Вставить" показывалось содержание буфера обмена).
Или второй вариант: уже для контролов (кнопки, галки, комбобоксы и.т.д.) отдельное окошко рядом с основным диалогом. В нем всяки разные пояснения, ссылки на статьи на сайте и.т.д. Как окошко появляется решать Вам: можно по предложенному выше значку вопроса рядом с контролом, можно автоматически.
Что характерно: вот в таком отдельном окошке можно и сделать нечто вроде веб-интерфейса, на том же самом HTMLayout.
Что характерно, сие окошко может быть вообще отдельным exe, и соответственно зависимости от HTMLayout в основном и вовсе не будет. Просто основной exe, с уже сделанным GUI должен будет как-то взаимодействовать с этим отдельным окошком с HTMLayout (да хоть какой-нить MMF например).
Опыт личный, собственными ручками есть по всем этим вариантам. Если понадобится потом могу скинуть ссылки на этт проекты, если захочется посмотреть.
C>>И вот енту выжимку в мыслях оформить уже как лендинг именно под эти частые вопросы у себя на сайте. ЕМ>Именно отдельную страницу? Чем это лучше отдельного раздела? Мне-то больше нравятся как раз мелкие страницы с перекрестными ссылками, но нынче ж общий тренд к слеплению всего на одной большой странице. Мне это кажется неудобным, но специалисты уверяют, что это и есть то, что нужно юзеру.
Ну конечно это часть сайта, но в SiteMap сайта эта лендинг-пейдж все равно попадет?!? И гугл его заиндексит.
А по содержанию должно быть что-то конкретное, решение какой-нить конкретной задачи (которую наверное частенько гуглят пользователи).
А внизу такой страницы, стандартные "См. также", ну и ссылки там на близкие по тематике статьи, форму тех. поддержки и.т.д.
ЕМ>Вообще, у меня CHM-версия полностью проецируется на сайт. Имеет смысл сделать страницы более мелкими, чтобы помещались в одно-два браузерных окна?
C>>Уж не помню, у кого именно из великих брендов прошедших лет был классный мем на этот случай. “Это НЕ наш клиент!” ЕМ>Это я применяю в полный рост.
А без этого никуда теперь
C>>PPS: Я б еще посоветовал Алистера Коберна полистать про сценарии использования. Хорошо там раскладывается, причем с примерами, и вполне так структурировано как понимать пользователя и его сценарии использования.
ЕМ>Это все хорошо, когда продукт независимый, и сам может организовать выполнение сценария. У меня совершенно не так.
Та н-е-е-е, там другое у Алистера. Там как выявлять сценарии (по шагам, цели, причины, шаги) там больше про суть. Остальное уже как профессионалы мы и сами сделаем, это уже технические+юзабильские подробности.
Здравствуйте, Sinclair, Вы писали:
S>Неопытный пользователь испытывает затруднения не потому, что не знает, что делает конкретная кнопка или чекбокс. А потому, что не понимает, как ему сделать что-то.
Это уже здесь обсуждалось.
S>В итоге, для данной конкретной задачи, в связи с отсутствием в Адобе нормальной пользовательской документации
Я как раз пояснял здесь, что многие пользователи упорно не хотят идти в документацию, хотя на главном окне есть кнопка "Help", а в хелпе есть контекстный поиск. Поэтому и возникла идея загонять их туда хотя бы через подсказки интерфейса.
S>То есть, к примеру, надо мне узнать, сколько символов в черновике рассказа, который я пишу в рамках домашки по писательскому курсу. А я не знаю, где Word count спрятано в новомодном MS Word 2019. Никакая кнопочка вопросика мне в этом никак не поможет — хоть утыкайся. А помогает поиск, причём более-менее приблизительный. То есть можно искать count characters, можно char count, и всё равно найдётся нужный action.
А по каким словам в этом поиске можно найти пошаговую инструкцию по написанию рассказа, повести, романа, которые гарантированно станут популярными и будут стабильно продаваться? У массового-то пользователя задача стоит именно так.
Re[3]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Sinclair, Вы писали:
S>>Неопытный пользователь испытывает затруднения не потому, что не знает, что делает конкретная кнопка или чекбокс. А потому, что не понимает, как ему сделать что-то.
S>>В итоге, для данной конкретной задачи, в связи с отсутствием в Адобе нормальной пользовательской документации
ЕМ>Я как раз пояснял здесь, что многие пользователи упорно не хотят идти в документацию, хотя на главном окне есть кнопка "Help", а в хелпе есть контекстный поиск. Поэтому и возникла идея загонять их туда хотя бы через подсказки интерфейса.
ЕМ>А по каким словам в этом поиске можно найти пошаговую инструкцию по написанию рассказа, повести, романа, которые гарантированно станут популярными и будут стабильно продаваться? У массового-то пользователя задача стоит именно так.
Опять вы ребяты решаете несуществующую задачу. Никто и не спорит, что значительно чаще пользователю нужен ответ на вопрос "как сделать это", а не "что это такое".
Соответственно, это и решает контекстный поиск. Но он должен быть под рукой, по месту. А не где-то там, в каком то ёпырш главном окне (пользователи-то и слова такого не знают "главное", да еще и "окно"). Куда-то там идти, чего-то там нажимать, и все такое.
Нужно, чтобы такая контекстная справка была по месту, прямо под рукой.
Это может быть значок (иконка) вопроса, всплывающая подсказка, что-то еще. Но с перечнем ссылок на статьи в хелпе (или где там) про "Как решать задачу", которая скорее всего интересует пользователя. Какие именно задачи интересны пользователю в этом месте — вычисляется эмпирически.
А все эти: "сходи в главное окно", "нажми кнопку Help", "введи чой-то там… "… Та ну нафиг!
PS: отчасти это можно делать через аля "Советы дня". Только не в таком убогом виде, что Microsoft предложила делать еще во времена Вин9х. Это делается совсем по другому…
Здравствуйте, Carc, Вы писали:
C>Опять вы ребяты решаете несуществующую задачу.
Я решаю как раз существующую: как заставить пользователя, пытающегося скрестить ежа с ужом, хоть немного понять, что же именно он пытается сделать.
C>значительно чаще пользователю нужен ответ на вопрос "как сделать это", а не "что это такое".
Когда в описании "как" фигурирует, например, электролобзик — пользователю очень желательно знать, что это такое, как это держать, куда нажимать и т.п. Как минимум — чтобы не отрезать себе яйца пальцы. Как максимум — чтобы получилось хотя бы примерно то, чего хотелось.
C>Соответственно, это и решает контекстный поиск. Но он должен быть под рукой, по месту. А не где-то там, в каком то ёпырш главном окне (пользователи-то и слова такого не знают "главное", да еще и "окно").
Так у меня почти весь GUI — то самое главное окно. Куда уж ближе-то?
C>Такие советы должны быть под рукой, прям по месту.
А где оно, это место? Вот у пользователя родилась идея, чтобы звук из приложения A попадал в приложение B, оно отправляло его в сеть, а приходящий звук направлялся в приложение C. Где конкретно в этой схеме находится "место", в котором пользователь станет искать решение своей задачи? Ну, кроме гугла, конечно.
При этом сковородка стоит на газовой горелке, установленной на лесной поляне, а прихватку забыли дома.
C>Это может быть значок (иконка) вопроса, всплывающая подсказка, что-то еще.
Знак вопроса у элемента интерфейса — интересная идея, кое-где применяется, но тогда интерфейс должен быть "разреженным" (не больше десятка элементов в окне/диалоге). У меня пока все управление на виду — всегда казалось, что так удобнее (большинство интерфейсов реального времени так или иначе копирует аппаратные пульты, где все ручки/кнопки тоже на одной панели, а не скрыты дверцами или выдвижными панелями). Если к каждому элементу присобачить еще и знак вопроса — в глазах не зарябит?
Пока идеальным решением мне кажется размещение ссылок на документацию во всплывающих подсказках. Они там даже поддерживаются искаропки, только в винде невозможно навести курсор на подсказку — она исчезает. Наверное, нужно управлять их показом вручную, а не автоматически.
C>А все эти: "сходи в главное окно", "нажми кнопку Help", "введи чой-то там… "… Та ну нафиг!
Пока вообще не предлагается ничего никуда вводить. В шапке окна есть значок "?", общий для всех элементов. Какова должна быть степень тупости пользователя, чтобы не пользоваться столь простым инструментом?
C>Вместо решения задачи пользователя предлагается способ поиска решения. А ему не нужен способ, ему нужно само решение.
Это когда продукт технически способен самостоятельно обеспечить это решение. А если нет?
C>PS: отчасти это можно делать через аля "Советы дня".
Я думал об этом. Но те советы показываются в случайном порядке. В лучшем случае можно как-то сортировать их по тому, что делает пользователь с интерфейсом, но лишь в том случае, когда удается более-менее надежно распознать паттерн. Без этого можно показывать советы до скончания века, но пользователь не увидит там того, что ему нужно.
Re[4]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Carc, Вы писали:
C>>Опять вы ребяты решаете несуществующую задачу.
ЕМ>Я решаю как раз существующую: как заставить пользователя, пытающегося скрестить ежа с ужом, хоть немного понять, что же именно он пытается сделать.
По моему в Win API не было и нет такого инструмента (а соответственно и стиля окна) как
C>>Такие советы должны быть под рукой, прям по месту.
ЕМ>А где оно, это место? Вот у пользователя родилась идея, чтобы звук из приложения A попадал в приложение B, оно отправляло его в сеть, а приходящий звук направлялся в приложение C. Где конкретно в этой схеме находится "место", в котором пользователь станет искать решение своей задачи?
Ну дык это и есть юзабилити... Пользователь же сосредоточен на конкретной галке, кнопке, и.т.д.!?! Соответственно, и знак того же вопросика должен быть где-то рядом, а не фиг знает где, в каком то заголовке, на другом конце экрана.
Пользователь просто туда не посмотрит.
ЕМ>Знак вопроса у элемента интерфейса — интересная идея, кое-где применяется, но тогда интерфейс должен быть "разреженным" (не больше десятка элементов в окне/диалоге). У меня пока все управление на виду — всегда казалось, что так удобнее (большинство интерфейсов реального времени так или иначе копирует аппаратные пульты, где все ручки/кнопки тоже на одной панели, а не скрыты дверцами или выдвижными панелями). Если к каждому элементу присобачить еще и знак вопроса — в глазах не зарябит?
Если нормально расположить, то не зарябит.
ЕМ>Пока идеальным решением мне кажется размещение ссылок на документацию во всплывающих подсказках. Они там даже поддерживаются искаропки, только в винде невозможно навести курсор на подсказку — она исчезает. Наверное, нужно управлять их показом вручную, а не автоматически.
Это может быть отдельный контрол со списком ссылок где-то рядом, в основном окне . Т.е. как-то так
1) Рядом с галкой\кнопкой\и.т.д. есть знак вопроса
2) Щелчок по знаку вопроса показывает этот отдельный контрол со списком ссылок на статье\хелпы, относящиеся тем или иным образом к этой самой кнопке\галке\прочия.
C>>PS: отчасти это можно делать через аля "Советы дня".
ЕМ>Я думал об этом. Но те советы показываются в случайном порядке.
Сие есть ложь! Какой такой случайный порядок? Здесь же не розыгрыш самодвижущихся экипажей, для тех кто вакцинировался… Вот там действительно случайный порядок, лотерея.
Тут несколько иначе всё ж
Мои советы? Где хочу, там и показываю.
Мои советы? В каком порядке хочу, в таком и показываю.
Мои советы? Чего хочу, то в них и ворочу.
Ессесна, "подсказки" искаропки" то скроются, то слетают, то позиция не туда, не то, и не эдак. Написать свой контрол — делов-то на пару часов "рыбу", заготовку изваять. Ну и до ума довести пару дней.
Позже, со временем, опыт применения такого контрола сам по себе и идеи подскажет, и требования к нему… Я именно поэтому пути и шел.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я уже несколько раз объяснял, попробую объяснить через еще одну аналогию. Представьте, что для езды на автомобиле не нужно учиться и сдавать экзамен. Человек покупает автомобиль, но не понимает, как он устроен, не знает правил, не умеет ездить, ориентироваться ни на дороге, ни на карте, учиться всему этому или не хочет, или просто не знает, с какой стороны подступиться. Он лезет в гугл, где находит 100500 статей и роликов "как на Ford Focus доехать от Москвы до Петербурга", "как на Ладе Приоре объехать пост ДПС под Саратовом" и т.п. А у него Toyota Tundra, и ему нужно отвезти холодильник в загородный дом. Но ни ролика, ни статьи о том, как везти холодильник на Toyota Tundra именно по этому маршруту, он не находит, поэтому садится в машину и начинает тупо нажимать кнопки/педали и дергать рычаги в надежде, что машина поедет хоть куда-нибудь. Почему бы именно в этот момент ему не подсунуть информацию о том, как заводить машину, трогаться и рулить, разместив где-нибудь рядом информацию о ПДД, дорожных указателях, картах и прочем?
Ну дык подсуньте эту инфу, кто ж против то!?! Только при такой весьма обобщенной формулировке (ПДД, дорожные знаки, карты, как трогаться — если по аналогии) — одной ссылкой НЕ обойдешься.
Скорее всего ссылок будет несколько.
Вот тогда может и сработает прием, который я уже описывал: отдельный контрол с целом списком ссылок, которые относятся к какой-то галке\кнопке\прочия.
Я ж другое предлагал.
1) Есть обычный тултип к галке\кнопке с минимум инфы, обычный всплывающий.
2) Есть контрол с целым списком ссылок, которые относятся к конкретной галке\кнопке\прочия. Нвскидку: хелпы, пояснения, ссылки на статьи на сайте.
3) Рядом с галкой\кнопкой есть значок знака вопроса, который и активизирует (показывает) тот самый контрол со списком ссылок из п.2.
Как-то так бы я делал.
Подробности
Пункт 3 в списке выше, про знак вопроса, нужен чтобы контрол со списком ссылок\статей\хелпов не маячил перед глазами постоянно. Он будет только мешать, и загромождать экран (окно).
Щелчок по значку вопроса рядом с галкой\кнопкой\и.т.д дает явную команду обновить ссылки\статьи\пояснения в контроле со списком.
Пользователь быстро уловит связь, что щелчок по значку вопроса рядом с галкой\кнопкой показывает дополнительную инфу по этой конкретной галке\кнопке в этом самом контроле-списке (пояснения, советы, ссылки на статьи, хелпы).
Здравствуйте, Carc, Вы писали:
C>Пользователь же сосредоточен на конкретной галке, кнопке, и.т.д.!?! Соответственно, и знак того же вопросика должен быть где-то рядом, а не фиг знает где, в каком то заголовке, на другом конце экрана. Пользователь просто туда не посмотрит.
Ему достаточно один раз узнать, что этот знак вопросика там есть, дальше уже не забудет. По-моему, правильнее будет изначально как-то привлечь его внимание (дополнительным текстом во всплывающей подсказке, цветом/миганием значка, или теми же всплывающими "Did you know..."), нежели все время показывать по значку возле каждого элемента. При нескольких десятках элементов в окне, это будет выглядеть страшновато.
C>Если нормально расположить, то не зарябит.
А как их "нормально" расположить вот в таком окне?
C>У меня советы дня умеют еще и действия непосредственно в пользовательском интерфейсе на лету вопроиводить: выделить команду меню, показать диалог, запустить какой-нить процесс в самой софтине.
У меня так не выйдет. Софтинам недостаточно собственных действий, нужна инфраструктура с участием других приложений и системы.
C>Ессесна, "подсказки" искаропки" то скроются, то слетают, то позиция не туда, не то, и не эдак. Написать свой контрол
Возможно, в итоге так и придется сделать.
Re[8]: Контекстная справка по элементам интерфейса
Здравствуйте, Carc, Вы писали:
C>Только при такой весьма обобщенной формулировке (ПДД, дорожные знаки, карты, как трогаться — если по аналогии) — одной ссылкой НЕ обойдешься.
Никто не говорит про одну ссылку. Главная задача — как можно чаще побуждать пользователя, не понимающего толком, как это работает, открывать документацию. А там уже можно сделать коротенькие описания с гиперссылками на терминах, по которым он сможет узнать больше.
C>Вот тогда может и сработает прием, который я уже описывал: отдельный контрол с целом списком ссылок, которые относятся к какой-то галке\кнопке\прочия.
Вот только чем он будет принципиально отличаться от знака вопроса в шапке? Или выделенной цветом кнопки со знаком вопроса, которая периодически может выбрасывать всплывающую подсказку вроде "нажми здесь, а потом нажми интересующий элемент"?
Re[7]: Контекстная справка по элементам интерфейса
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Carc, Вы писали:
C>>Пользователь же сосредоточен на конкретной галке, кнопке, и.т.д.!?! Соответственно, и знак того же вопросика должен быть где-то рядом, а не фиг знает где, в каком то заголовке, на другом конце экрана. Пользователь просто туда не посмотрит.
ЕМ>Ему достаточно один раз узнать, что этот знак вопросика там есть, дальше уже не забудет.
Проблема в другом: этого самого одного-единственного раза так никогда и не случится. И соответственно, пользователь и ничего и не вспомнит, ибо вспоминать ему нечего.
ЕМ>По-моему, правильнее будет изначально как-то привлечь его внимание (дополнительным текстом во всплывающей подсказке, цветом/миганием значка, или теми же всплывающими "Did you know..."), нежели все время показывать по значку возле каждого элемента.
А не нужно показывать автоматически всё время, по наведению мыша. Нужно показывать по щелчку по значку вопроса.
Здравствуйте, Евгений Музыченко, Вы писали:
C>>Ессесна, "подсказки" искаропки" то скроются, то слетают, то позиция не туда, не то, и не эдак. Написать свой контрол ЕМ>Возможно, в итоге так и придется сделать.
Та это несложно — написать такой контрол-подсказку. Поскольку такой контрол четко заточен под весьма конкретные нужды, то и соответственно круг требований к нему ограничен.
Можно отсабкласить какой-нить std::ToolTip_Class (или отнадклассить, я и такой вариант пробовал).
А можно и с нуля свой контрол сделать.
А чтоб юзера в ступор не вгонять, слизнуть внешний вид (цвета фона, шрифта) с тех же системных настроек (GetSysColor + иже с ними). Что б выглядел привычно, что б крякал как утка, летал как утка, но всё ж не утка (начинка своя, под себя заточенная).
C> щелчок по появившемуся значку-вопросику показывает ту самую всплывающую подсказку
Достаточно просто наведения. Сначала навести на элемент UI, появится вопрос рядом — можно навести на вопрос, а можно не навести.
Кроме того, первое наведение наверное лишнее. Мне понравилась выше по треду идея с буквой (i), которая размещена заранее.
Кроме "вопроса" ещё были "лампочка" и "скрепыш" (который закрывал подсказку по крестику).
По кр. мере лично вообще никогда не юзал.
При таком подходе хана шницелям © — привет угольной промышленности. 
