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

S>Я не утверждаю, что только юзабилити решает вопросы безопасности, разумеется. Было бы, по крайней мере, неразумно это предполагать. То интерфейсны пользователя могут являться и являются компонентами решений вопросов безопасности. Хотите пример? Lotus Notes — при вводе пароля пользователя показываются различные иконки перескакивающие, которые физиологически отвлекают возможного злоумышленника, стоящего за спиной.
Это ты сам придумал, или прочитал сообщение дегенератов из usability hall of shame?
Открою тебе тайну: иконки в лотусе никакого отношения к развлечению злоумышленников не имеют. Это именно usability для пользователя.
Они ОДНОЗНАЧНО определяются по введенному паролю. Это помогает тебе понять, правильно ли ты его ввел, еще до того, как ты нажал Enter. И сделано это потому, что в лотусе даже количество букв, введенных в пароле, ты не поймешь — они разное количество крестиков отображают. Так что отсутствие иконочек привело бы к резкому просаду юзабилити и росту количества неверных попыток.
S> Хотите пример попроще? Ввод пароля в Windows — отображаются звёздочки... Так что я бы не стал на вашем месте утеврждать, что элементы юзабилити не используются для решения вопросов безопасности.
Звездочки в винде показываются заради ровно одной цели — дать пользователю понять, ввел ли он уже весь пароль, или еще не весь. Вопрос безопасности решался бы не показом вообще ничего.
S>Юзабилити, как некий качественный признак системы, может быть измерян по некоторым характеристикам и оценен, в том числе, относительно целей продукта. И, если одной из целей продукта является безопасная реализация каких-нибудь бизнес-процессов, то юзабилити вполне может являться средством реализации данной цели.
Пока не вижу никаких аргументов в пользу этого утверждения. Единственное что — ускорение процедур, возникающее благодаря улучшению юзабилити, поможет сократить время нахождения в "закрытой зоне" и уменьшить риск компрометации безопасности. Все остальное, имхо, домыслы.

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

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

S>>Я не утверждаю, что только юзабилити решает вопросы безопасности, разумеется. Было бы, по крайней мере, неразумно это предполагать. То интерфейсны пользователя могут являться и являются компонентами решений вопросов безопасности. Хотите пример? Lotus Notes — при вводе пароля пользователя показываются различные иконки перескакивающие, которые физиологически отвлекают возможного злоумышленника, стоящего за спиной.
S>Это ты сам придумал, или прочитал сообщение дегенератов из usability hall of shame?
Старшие товарищи рассказали.

S>Открою тебе тайну: иконки в лотусе никакого отношения к развлечению злоумышленников не имеют. Это именно usability для пользователя.Они ОДНОЗНАЧНО определяются по введенному паролю. Это помогает тебе понять, правильно ли ты его ввел, еще до того, как ты нажал Enter. И сделано это потому, что в лотусе даже количество букв, введенных в пароле, ты не поймешь — они разное количество крестиков отображают. Так что отсутствие иконочек привело бы к резкому просаду юзабилити и росту количества неверных попыток.
Про такую модель даже не думал. Лююопытно. Если кинешь ссылочку на источник — буду признателен.

S>> Хотите пример попроще? Ввод пароля в Windows — отображаются звёздочки... Так что я бы не стал на вашем месте утеврждать, что элементы юзабилити не используются для решения вопросов безопасности.
S>Звездочки в винде показываются заради ровно одной цели — дать пользователю понять, ввел ли он уже весь пароль, или еще не весь. Вопрос безопасности решался бы не показом вообще ничего.
Хм. Вопрос "весь — не весь" мне, например, проще воспринимать числом, показывающей количество введённых символов. Пересчитать звёздочки, когда пароль больше 10 символов, например, очень непросто. Также хотелось бы увидеть ссылочку на источник информации. Наверняка есть.

Кстати, насколько я понял, роль звёздочек у MS и Lotus различна. Интересно, почему?

S>>Юзабилити, как некий качественный признак системы, может быть измерян по некоторым характеристикам и оценен, в том числе, относительно целей продукта. И, если одной из целей продукта является безопасная реализация каких-нибудь бизнес-процессов, то юзабилити вполне может являться средством реализации данной цели.
S>Пока не вижу никаких аргументов в пользу этого утверждения.
Согласен. Моя фраза теоретически неправильно построена, поскольку "признак" не может быть "средством" — это просто метрика. А любая метрика является отражением чего-то. В данном случае юзабилити может (да и практически всегда так и получается) снижаться при увеличении требований к безопасности бизнес-процесса. Например, в некоторых системах требуется повторный ввод пароля при работе с отдельными модулями системы (такого же, как при авторизации), даже если пользователь уже авторизован в системе.

S>Единственное что — ускорение процедур, возникающее благодаря улучшению юзабилити, поможет сократить время нахождения в "закрытой зоне" и уменьшить риск компрометации безопасности. Все остальное, имхо, домыслы.

Hello, Spidola!

S>> Звездочки в винде показываются заради ровно одной цели — дать
S>> пользователю понять, ввел ли он уже весь пароль, или еще не весь.
S>> Вопрос безопасности решался бы не показом вообще ничего.
S> Хм. Вопрос "весь — не весь" мне, например, проще воспринимать числом,
S> показывающей количество введённых символов. Пересчитать звёздочки, когда
S> пароль больше 10 символов, например, очень непросто. Также хотелось бы
S> увидеть ссылочку на источник информации. Наверняка есть.

S> Кстати, насколько я понял, роль звёздочек у MS и Lotus различна.
S> Интересно, почему?

В LN количество "звездочек" не пропорционально количеству введенных символов для пущей безопастности. Чтоб затруднить злоумышленнику стоящему за спиной узнать количество символов в пароле пользователя. А чтоб юзер таки имел возможность понять то он ввел или нет ему рисуют иконку.

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

GIV>В LN количество "звездочек" не пропорционально количеству введенных символов для пущей безопастности. Чтоб затруднить злоумышленнику стоящему за спиной узнать количество символов в пароле пользователя. А чтоб юзер таки имел возможность понять то он ввел или нет ему рисуют иконку.

Т.е. правильно ли я понимаю, что в Lotus Notes при вводе пароля СПЕЦИАЛЬНО сделано так, чтобы запутать злоумышленника, который стоит за спиной?

И как это кореллирует с высказыванием Синклера в предыдущем посте:

Вопрос безопасности решался бы не показом вообще ничего.

Hello, Spidola!

GIV>> В LN количество "звездочек" не пропорционально количеству введенных
GIV>> символов для пущей безопастности. Чтоб затруднить злоумышленнику
GIV>> стоящему за спиной узнать количество символов в пароле пользователя.
GIV>> А чтоб юзер таки имел возможность понять то он ввел или нет ему
GIV>> рисуют иконку.

S> Т.е. правильно ли я понимаю, что в Lotus Notes при вводе пароля
S> СПЕЦИАЛЬНО сделано так, чтобы запутать злоумышленника, который стоит за
S> спиной?

То что выводиться разное количиство звездочек на введенную букву — ДА.
То что меняется иконка при этом — НЕТ. Она для удобства юзера. Чтоб он имел хоть какуюто информацию о том правильно ли введен пароль до того как жмакнуть Enter... У меня вот пароль с желтенькой птичкой сейчас

S> И как это кореллирует с высказыванием Синклера в предыдущем посте:
S>

S> Вопрос безопасности решался бы не показом вообще ничего.

Плохо

Здравствуйте, Spidola, Вы писали:
S>>Это ты сам придумал, или прочитал сообщение дегенератов из usability hall of shame?
0S>Старшие товарищи рассказали.
Ну значит они вычитали это в той самой статье. Потому как повторно изобрести такой бред, имхо, невозможно.
S>Про такую модель даже не думал. Лююопытно. Если кинешь ссылочку на источник — буду признателен.
Источник — умозаключения. Моя гипотеза объясняет поведение Lotus лучше, чем гипотеза про развлечения для злоумышленников. Потому как развлечение не требовало бы ни синхронизации с клавиатурой, ни стабильности картинки для одинакового пароля. Этим особенностям UI развлекательная гипотеза объяснения не дает.
S>Хм. Вопрос "весь — не весь" мне, например, проще воспринимать числом, показывающей количество введённых символов. Пересчитать звёздочки, когда пароль больше 10 символов, например, очень непросто. Также хотелось бы увидеть ссылочку на источник информации. Наверняка есть.
Опять же, умозаключения. Возможно, все было проще — для ввода пароля использовали ровно тот же текстбокс, введя в него минимальные изменения функционала. Это уменьшает количество базовых метафор UI, которые должен освоить пользователь. Минимальные изменения — это замена отображаемых символов на password char и запрет копирования в клипборд.
Обратная связь должна быть у любого элемента управления.
S>Кстати, насколько я понял, роль звёздочек у MS и Lotus различна. Интересно, почему?
Как уже объяснили, разработчики Lotus решили, что звездочки слишком сильно компрометируют безопасность — если кто-то получил доступ к экрану в момент ввода, то он сможет определить как минимум длину пароля. А это сильно сокращает перебор.
S>Согласен. Моя фраза теоретически неправильно построена, поскольку "признак" не может быть "средством" — это просто метрика. А любая метрика является отражением чего-то. В данном случае юзабилити может (да и практически всегда так и получается) снижаться при увеличении требований к безопасности бизнес-процесса. Например, в некоторых системах требуется повторный ввод пароля при работе с отдельными модулями системы (такого же, как при авторизации), даже если пользователь уже авторизован в системе.
Ну, в жизни получается так, что требования к безопасности практически всегда снижают юзабилити. Это стоит учитывать при проектировании системы: если безопасность окажется слишком неудобной, то сами пользователи снизят ее до неприемлемого уровня. Самые частые примеры — это выдача всем пользователям привилегий Power User а то и Domain Admin (чтобы они меньше трахали сисадминов своими запросами), использование сочетаний типа "123" для паролей, которые нужно часто вводить, и прочие нездоровые практики.
Так что самая строгая безопасность должна быть все еще максимально удобной для пользователя (оставаясь все еще неудобной для злоумышленника).

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

S>Здравствуйте, adontz, Вы писали:
A>>ИМХО первый вариант вообще нельзя использовать, второй лучше но не идеален, а надо так
A>>Ну и колечно когда выбрано use default value EDIT должен быть выключен.
S>Подход совершенно верный. Я бы еще дополнил, что бизнес-логика в таком случае на самом деле включает в себя два вопроса. И только второй из них про значение. При этом текст вопроса может и должен зависеть от бизнес логики. Например:
S>

S>[x] Отправлять ли извещения об изменениях в данной категории?
S>    Введите адрес: [_________________________________________]
S>

S>Или:
S>

S>[x] Ограничить максимальный размер занимаемой памяти?
S>    Ограничение, МB: [_________________________[v]
S>

S>И т.д. А то, что оба ответа можно спрятать в одно поле СУБД — игра слепого случая

Итак, имеется конкретная задача: рабочее место врача-эксперта (члена некоей комиссии).
Врач должен отразить свое мнение по баальшущему списку (~100) вопросов, каждый из которых имеет ~10 вариантов ответов. Причем практически по любому из них у него мнения может и не быть (не уверен, не уполномочен и т.п.) — т.е. типичное значение "не известно","не знаю" — т.е. NULL. И что же, прикажете вместо 100 контролов (комобо-боксов в этом случае) лепить 200?!
Действительно, бизнес-логика включает два вопроса, но зачем же этим загружать пользователя (и перегружать интерфейс)?! И средствами одного контрола можно показать, что значение не определено (если spin-edit пустой — IMHO все и так понятно). Это ж не бумажный документ, где нужно явно ставить прочерк или Z, чтобы враг не вписал чего лишнего!
Достаточно дать пользователю единообразный способ очистки (сброса в NULL) любого атрибута (комбинация клавиш и кнопка на тул-баре, а для комбо-бокса, кроме того, в список можно ввести пустую строку или строку типа "Не определено").
По-моему, грузить пользователя различиями между "пусто", "отсутствует", "не определено", "по-умолчанию" и т.п. нужно, только если без этого действительно не обойтись (в случае текста, если пустая строка имеет смысл, отличный от "не определено" или в случае, если атрибут — множественное значение на основе справочника).

Здравствуйте, Аноним, Вы писали:

А>И что же, прикажете вместо 100 контролов (комобо-боксов в этом случае) лепить 200?!

На самом деле да! Просто тут логика работы приложения несколько другая выходит. По умолчанию выделен radiobutton default_value, а как только в текстовое поле начинают что-то вводить выделяется radiobutton specified_value.
с одной стороны внешне стандартный интерфейс, с другой удобство заполнения

Здравствуйте, <Аноним>, Вы писали:
А>Итак, имеется конкретная задача: рабочее место врача-эксперта (члена некоей комиссии).
А>Врач должен отразить свое мнение по баальшущему списку (~100) вопросов, каждый из которых имеет ~10 вариантов ответов. Причем практически по любому из них у него мнения может и не быть (не уверен, не уполномочен и т.п.) — т.е. типичное значение "не известно","не знаю" — т.е. NULL. И что же, прикажете вместо 100 контролов (комобо-боксов в этом случае) лепить 200?!
Ну почему двести. Может, и тысячу надо. Вот только в таких опросниках очень часто сам состав вопросов зависит от ответов на первые из них. Ленивый разработчик просто дает возможность забить лишние ответы нуллами. Специалист по юзабилити задает только те вопросы, которые необходимы.
А>По-моему, грузить пользователя различиями между "пусто", "отсутствует", "не определено", "по-умолчанию" и т.п. нужно, только если без этого действительно не обойтись (в случае текста, если пустая строка имеет смысл, отличный от "не определено" или в случае, если атрибут — множественное значение на основе справочника).

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

S>... Ленивый разработчик просто дает возможность забить лишние ответы нуллами. Специалист по юзабилити задает только те вопросы, которые необходимы.

Согласен, конечно, но вот говорят же, что медицина — не наука. По мне — может быть и наука, но как предметная область очень плохо она поддается формализации (как и вся хм... наша жызнь). Точнее она поддается, но в моей задаче очень постепенно, от версии к версии системы — вместе с сознанием работающих с ней людей. Неужели в Вашей практике всегда было все так гладко и строго: "только те, которые необходимы"? А ведь, наверное, есть еще системы где без голого SQL в качестве UI не обойтись?
И все-таки. Неужели я совсем неправ?! Пользователи моей системы исторически привыкли работать с бумажными формами о двадцати страницах, в которых они ставят галочки, подчеркивают слова и вписывают произвольный текст. Ну, натурально, я в качестве основной метафоры интерфейса использовал понятие "документ" — оглавление, значить, слева, а на остальной части формы с вертикальным скроллингом, сгруппированные в параграфы, расположены контролы всякие (и гриды и tree-list-ы встречаются, но комбо-боксы в основном). Каждый из этих контролов — это знакомый пользователям по докомпьютерной жизни реквизит. Операции унифицированные для реквизитов определил, из которых "очистить" — для всех работает, а "изменить", "добавить", "удалить", "вверх", "вниз" и т.д. — для сложных (списков, например), все это и в тул-баре и в контекстном меню дублируется...
Даже отдельные параграфы громоздкими получаются (а они у меня строго соответствуют параграфам "бумажным"), так мне еще и дополнительные чек-боксы рядом с каждым реквизитом ставить? Кстати да — общее число реквизитов в документе может и тысячи досигать и рядом с каждым по вашему должно "Использовать реквизит" быть написано? И это будет юзабилити?!

Здравствуйте, sokohigh, Вы писали:
S> Даже отдельные параграфы громоздкими получаются (а они у меня строго соответствуют параграфам "бумажным"), так мне еще и дополнительные чек-боксы рядом с каждым реквизитом ставить? Кстати да — общее число реквизитов в документе может и тысячи досигать и рядом с каждым по вашему должно "Использовать реквизит" быть написано? И это будет юзабилити?!
Еще раз и по буквам: то, что ничего кроме "использовать реквизит" в голову не лезет — симптом недостаточной проработки предметной области. Еще раз подчеркиваю важность правильного наименования "чекбокса". Например:

126. Была ли измерена температура? [x]
126a. Температура тела пациента: [____]
127. Было ли измерено давление? [x]
127a. Давление: [____]

Предполагается, что 126a показывается или енаблится только при правильном ответе на 126.
Это — осмысленный UI.
А вот бессмысленный UI:

126. Использовать реквизит: [x] Температура тела пациента: [____]
127. Использовать реквизит: [x] Давление: [____]

А вот — еще более бездарный UI:

126. Температура тела пациента: [____] Примечание: оставьте пустым, если температура не была измерена, или была нормальной, или еще в каком-нибудь случае. Пусть читатель анкеты догадывается, что вы имели в виду.

S>А вот — еще более бездарный UI:
S>

126. Температура тела пациента: [____] Примечание: оставьте пустым, если температура не была измерена, или была нормальной, или еще в каком-нибудь случае. Пусть читатель анкеты догадывается, что вы имели в виду.

Хмм... Если исключить комментарий, то именно такой UI мне кажется наиболее приемлемым именно для медицины. Если такая анкета дублирует/повторяет бумажную, то самое то (то, что доктор прописал ). Все равно в бумажных анкетах/формах/отчетах медики заполняют только то, что нужно

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

S>Предполагается, что 126a показывается или енаблится только при правильном ответе на 126.

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

Лучше сделать что бы при заполнении поля 126a чекбокс 126 включался автоматом (по умолчанию все они выключены).

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

Doc>Лучше сделать что бы при заполнении поля 126a чекбокс 126 включался автоматом (по умолчанию все они выключены).

Как это сделано, например в Print Setup в ворде для поля Page Range -> Pages:

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

S>Еще раз и по буквам: то, что ничего кроме "использовать реквизит" в голову не лезет — симптом недостаточной проработки предметной области. Еще раз подчеркиваю важность правильного наименования "чекбокса". Например:
S>

S>126. Была ли измерена температура? [x]
S>126a. Температура тела пациента: [____]
S>127. Было ли измерено давление? [x]
S>127a. Давление: [____]

S>Предполагается, что 126a показывается или енаблится только при правильном ответе на 126.
S>Это — осмысленный UI.
S>А вот бессмысленный UI:
S>

126. Использовать реквизит: [x] Температура тела пациента: [____]
S>127. Использовать реквизит: [x] Давление: [____]

S>А вот — еще более бездарный UI:
S>

126. Температура тела пациента: [____] Примечание: оставьте пустым, если температура не была измерена, или была нормальной, или еще в каком-нибудь случае. Пусть читатель анкеты догадывается, что вы имели в виду.

Спасибо за науку! Согласен. На 99.9%. Но меня опять терзают смутные подозрения... Что касается "Использовать реквизит" — так это я для краткости, мне понятно что в каждом конкр.случае должна быть своя формулировка.
Мучает же меня другой вопрос: "Кто сильнее: кит или слон?" ... блин сорри, "Что лучше (для юзабилити, конечно): 100 контролов + общая операция очистки реквизита (сброса в значение по умолчанию, кот.видно пользователю,напр: Температура тела: [36.62 ] > жмем кнопку "Очистить"> Температура тела: [Не измер.]) ИЛИ 200 контролов с безупречной логикой и с 2x ОБЪЕМОМ ВИЗУАЛЬНОЙ ИНФОРМАЦИИ для глазок пользователя (часто позднепенсионного возраста в моей задаче)?" А?

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

Doc>>Лучше сделать что бы при заполнении поля 126a чекбокс 126 включался автоматом (по умолчанию все они выключены).
M>Как это сделано, например в Print Setup в ворде для поля Page Range -> Pages:

Уже предлагал

Автор: adontz
Дата: 30.05.05

не понравилось

Здравствуйте, sokohigh, Вы писали:
S> Мучает же меня другой вопрос: "Кто сильнее: кит или слон?" ... блин сорри, "Что лучше (для юзабилити, конечно): 100 контролов + общая операция очистки реквизита (сброса в значение по умолчанию, кот.видно пользователю,напр: Температура тела: [36.62 ] > жмем кнопку "Очистить"> Температура тела: [Не измер.]) ИЛИ 200 контролов с безупречной логикой и с 2x ОБЪЕМОМ ВИЗУАЛЬНОЙ ИНФОРМАЦИИ для глазок пользователя (часто позднепенсионного возраста в моей задаче)?" А?
Это сферический конь в вакууме. Как правило, длинные анкеты имеют свойство содержать сильно связанные группы вопросов. Тогда один признак рулит группой вопросов, и реально объем действий уменьшается, а не увеличивается:

-- [x] У вас есть квартира? --
 Площадь: [     ] кв.м.
  Комнат:  [ 1[v]]
    Этаж:  [ 1 +-]
 Количество прописанных: []
 [x] Приватизирована
     Дата приватизации: [  .  .    ]

Вместо очистки 4х полей достаточно снять одну галочку.