Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, Spidola, Вы писали:
S>>Дело в том, что в описании было примерно так — использовать ли ограничение по количеству, а если использовать, то какое...
SDB>Тогда Ромин вариант самое то.
S>>А так бы тоже пнул
SDB>Очень мило! Мы тут с протянутой рукой, помочь хотели, а он — пинаться...
Ну я ж образно говоря — чего к словам придираться А то я тоже умею придираться — как это "с протянутой рукой", да и "помочь"?
Здравствуйте, sokohigh, Вы писали: S> Даже отдельные параграфы громоздкими получаются (а они у меня строго соответствуют параграфам "бумажным"), так мне еще и дополнительные чек-боксы рядом с каждым реквизитом ставить? Кстати да — общее число реквизитов в документе может и тысячи досигать и рядом с каждым по вашему должно "Использовать реквизит" быть написано? И это будет юзабилити?!
Еще раз и по буквам: то, что ничего кроме "использовать реквизит" в голову не лезет — симптом недостаточной проработки предметной области. Еще раз подчеркиваю важность правильного наименования "чекбокса". Например:
126. Была ли измерена температура? [x]
126a. Температура тела пациента: [____]
127. Было ли измерено давление? [x]
127a. Давление: [____]
Предполагается, что 126a показывается или енаблится только при правильном ответе на 126.
Это — осмысленный UI.
А вот бессмысленный UI:
126. Использовать реквизит: [x] Температура тела пациента: [____]
127. Использовать реквизит: [x] Давление: [____]
А вот — еще более бездарный UI:
126. Температура тела пациента: [____] Примечание: оставьте пустым, если температура не была измерена, или была нормальной, или еще в каком-нибудь случае. Пусть читатель анкеты догадывается, что вы имели в виду.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Spidola, Вы писали:
S>Дык в данном случае (в банке) наоборот юзабилити как раз и направлено на решение задач безопасности. Если тебе положено что-то знать, ты знаешь и делаешь. Если не положено, то нечего экпериментировать и догадываться... Это как с ФАПСИшниками — когда систему демонстрируешь — они говоря: "Неправильно, не соответствует по безопасности". А когда спрашиваешь, что сделать, чтобы соответствовало, отвечают: "Не скажем — это ваша забота. Наша забота — проверить на соответствие".
Не может юзабилити решать задачи безопасности. Эти задачи решаются ограничениями. Либо есть возможность сделать что-то, либо она закрыта. Если возможность есть — то пользователь может ее найти, и с точки зрения безопасности не важно как она реализована. При этом для безопасности не важно какими юзабилити-свойствами обладает продукт — важно чтобы все дырки были закрыты.
С другой стороны, качество продукта с точки зрения юзабилити не зависят от того — банковская это система или какая-то другая и какие требования выдвигаются по части безопасности.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Fktrc, Вы писали: F>>Существует банковская система ИБСО (разработка Центра Финансовых Технологий в Новосибирске). Там этот вопрос решен так: null-значение в поле ставится тогда, когда в поле нажата комбинация Shift+Del, иначе,даже если поле пустое, оно считается заполненным каким то (хоть даже пустым) значением. При null-значении фон всего поля ввода залит желтым цветом, иначе там остается белый прямоугольник, показывающий, что какое то значение все же есть. S>Нда. Хрен догадаешься.
А в банковских системах как раз не надо догадываться. Надо знать. Если не знаешь — значит не положено.
Здравствуйте, adontz, Вы писали: A>ИМХО первый вариант вообще нельзя использовать, второй лучше но не идеален, а надо так A>Ну и колечно когда выбрано use default value EDIT должен быть выключен.
Подход совершенно верный. Я бы еще дополнил, что бизнес-логика в таком случае на самом деле включает в себя два вопроса. И только второй из них про значение. При этом текст вопроса может и должен зависеть от бизнес логики. Например:
[x] Отправлять ли извещения об изменениях в данной категории?
Введите адрес: [_________________________________________]
Или:
[x] Ограничить максимальный размер занимаемой памяти?
Ограничение, МB: [_________________________[v]
И т.д. А то, что оба ответа можно спрятать в одно поле СУБД — игра слепого случая
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, <Аноним>, Вы писали: А>Итак, имеется конкретная задача: рабочее место врача-эксперта (члена некоей комиссии). А>Врач должен отразить свое мнение по баальшущему списку (~100) вопросов, каждый из которых имеет ~10 вариантов ответов. Причем практически по любому из них у него мнения может и не быть (не уверен, не уполномочен и т.п.) — т.е. типичное значение "не известно","не знаю" — т.е. NULL. И что же, прикажете вместо 100 контролов (комобо-боксов в этом случае) лепить 200?!
Ну почему двести. Может, и тысячу надо. Вот только в таких опросниках очень часто сам состав вопросов зависит от ответов на первые из них. Ленивый разработчик просто дает возможность забить лишние ответы нуллами. Специалист по юзабилити задает только те вопросы, которые необходимы. А>По-моему, грузить пользователя различиями между "пусто", "отсутствует", "не определено", "по-умолчанию" и т.п. нужно, только если без этого действительно не обойтись (в случае текста, если пустая строка имеет смысл, отличный от "не определено" или в случае, если атрибут — множественное значение на основе справочника).
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Spidola, Вы писали:
S>Я не утверждаю, что только юзабилити решает вопросы безопасности, разумеется. Было бы, по крайней мере, неразумно это предполагать. То интерфейсны пользователя могут являться и являются компонентами решений вопросов безопасности. Хотите пример? Lotus Notes — при вводе пароля пользователя показываются различные иконки перескакивающие, которые физиологически отвлекают возможного злоумышленника, стоящего за спиной.
Это ты сам придумал, или прочитал сообщение дегенератов из usability hall of shame?
Открою тебе тайну: иконки в лотусе никакого отношения к развлечению злоумышленников не имеют. Это именно usability для пользователя.
Они ОДНОЗНАЧНО определяются по введенному паролю. Это помогает тебе понять, правильно ли ты его ввел, еще до того, как ты нажал Enter. И сделано это потому, что в лотусе даже количество букв, введенных в пароле, ты не поймешь — они разное количество крестиков отображают. Так что отсутствие иконочек привело бы к резкому просаду юзабилити и росту количества неверных попыток. S> Хотите пример попроще? Ввод пароля в Windows — отображаются звёздочки... Так что я бы не стал на вашем месте утеврждать, что элементы юзабилити не используются для решения вопросов безопасности.
Звездочки в винде показываются заради ровно одной цели — дать пользователю понять, ввел ли он уже весь пароль, или еще не весь. Вопрос безопасности решался бы не показом вообще ничего. S>Юзабилити, как некий качественный признак системы, может быть измерян по некоторым характеристикам и оценен, в том числе, относительно целей продукта. И, если одной из целей продукта является безопасная реализация каких-нибудь бизнес-процессов, то юзабилити вполне может являться средством реализации данной цели.
Пока не вижу никаких аргументов в пользу этого утверждения. Единственное что — ускорение процедур, возникающее благодаря улучшению юзабилити, поможет сократить время нахождения в "закрытой зоне" и уменьшить риск компрометации безопасности. Все остальное, имхо, домыслы.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Fktrc, Вы писали: F>Существует банковская система ИБСО (разработка Центра Финансовых Технологий в Новосибирске). Там этот вопрос решен так: null-значение в поле ставится тогда, когда в поле нажата комбинация Shift+Del, иначе,даже если поле пустое, оно считается заполненным каким то (хоть даже пустым) значением. При null-значении фон всего поля ввода залит желтым цветом, иначе там остается белый прямоугольник, показывающий, что какое то значение все же есть.
Нда. Хрен догадаешься.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
126. Температура тела пациента: [____] Примечание: оставьте пустым, если температура не была измерена, или была нормальной, или еще в каком-нибудь случае. Пусть читатель анкеты догадывается, что вы имели в виду.
Хмм... Если исключить комментарий, то именно такой UI мне кажется наиболее приемлемым именно для медицины. Если такая анкета дублирует/повторяет бумажную, то самое то (то, что доктор прописал ). Все равно в бумажных анкетах/формах/отчетах медики заполняют только то, что нужно
... << RSDN@Home 1.1.4 beta 7 rev. 447>> ... <<Winamp is playing "Silence">> ...
Здравствуйте, Spidola, Вы писали:
S>Дело в том, что в описании было примерно так — использовать ли ограничение по количеству, а если использовать, то какое...
Тогда Ромин вариант самое то.
S>А так бы тоже пнул
Очень мило! Мы тут с протянутой рукой, помочь хотели, а он — пинаться...
[ posted via RSDN@Home 1.1.4 beta 7 r456, accompanied by silence ]
Здравствуйте, 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" для паролей, которые нужно часто вводить, и прочие нездоровые практики.
Так что самая строгая безопасность должна быть все еще максимально удобной для пользователя (оставаясь все еще неудобной для злоумышленника).
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Существует свойство (к примеру, числовое), которое может использоваться, а может не использоваться в системе (физически в базе данных хранится либо число, либо NULL).
Пользователю нужно дать интерфейс настройки данного свойства.
Один вариант — когда один контрол — что-то введено — учитывается, ничего не введено — не учитывается.
Второй вариант — когда два контрола. Первый определяет учитывать или не учитывать, а второй определяет value свойства.
Теперь сам вопрос: есть ли какие-либо рекомендации по использованию/неиспользованию первого или второго способов? Имеется виду рекомендации типа Microsoft-овских по интерфейсу и подобных.
Если нет, то какова общая практика?
Зависит использование первого или второго способа от контекста или нет?
Интересно также научно-казуистическое обоснование того или иного способа...
Здравствуйте, Spidola, Вы писали:
S>Если нет, то какова общая практика?
Мое скромное ИМХО: поставить под элементом управления для ввода значения флажок "Use default value" и разрешать/запрещать сам элемент управления в зависимости от того, сбросил пользрователь этот флажок или нет (самой собой, в случае запрета элемента управления "поле ввода" необходимо очистить).
[ posted via RSDN@Home 1.1.4 beta 7 r456, accompanied by silence ]
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, Spidola, Вы писали:
S>>Если нет, то какова общая практика?
SDB>Мое скромное ИМХО: поставить под элементом управления для ввода значения флажок "Use default value" и разрешать/запрещать сам элемент управления в зависимости от того, сбросил пользрователь этот флажок или нет (самой собой, в случае запрета элемента управления "поле ввода" необходимо очистить).
Как-то несколько путано, честно говоря, получается. Я не совсем понял про Default value... Там ведь не значение по умолчанию, а использовать/не использовать.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Spidola, Вы писали:
A>ИМХО первый вариант вообще нельзя использовать, второй лучше но не идеален, а надо так A>
A>Ну и колечно когда выбрано use default value EDIT должен быть выключен.
Да, так очень неплохо. А что насчёт официальных рекомендаций?
Здравствуйте, Spidola, Вы писали:
S>Как-то несколько путано, честно говоря, получается. Я не совсем понял про Default value... Там ведь не значение по умолчанию, а использовать/не использовать.
Просто мне кажется, что вариант "использовать/не использовать" вызовет у рядового пользователя больше вопросов, чем "использовать значение по умолчанию", а уж как оно там в программе на самом деле обрабатывается — он все равно знать не будет.
P.S.
А почему это в Ромином ответе про "default value" понятно, а в моем — нет?
[ posted via RSDN@Home 1.1.4 beta 7 r456, accompanied by silence ]
Здравствуйте, Spidola, Вы писали:
A>>Ну и колечно когда выбрано use default value EDIT должен быть выключен. S>Да, так очень неплохо. А что насчёт официальных рекомендаций?
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, Spidola, Вы писали:
S>>Как-то несколько путано, честно говоря, получается. Я не совсем понял про Default value... Там ведь не значение по умолчанию, а использовать/не использовать.
SDB>Просто мне кажется, что вариант "использовать/не использовать" вызовет у рядового пользователя больше вопросов, чем "использовать значение по умолчанию", а уж как оно там в программе на самом деле обрабатывается — он все равно знать не будет.
Это я виноват — выдернул из контекста вопрос. Дело в том, что в описании было примерно так — использовать ли ограничение по количеству, а если использовать, то какое...
SDB>P.S. SDB>А почему это в Ромином ответе про "default value" понятно, а в моем — нет? Да, и действительно... Я просмотрел в Ромином ответе слово "default", ухватившись глазом за идею более высокого порядка значимости... А так бы тоже пнул
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, adontz, Вы писали: A>>ИМХО первый вариант вообще нельзя использовать, второй лучше но не идеален, а надо так A>>Ну и колечно когда выбрано use default value EDIT должен быть выключен. S>Подход совершенно верный. Я бы еще дополнил, что бизнес-логика в таком случае на самом деле включает в себя два вопроса. И только второй из них про значение. При этом текст вопроса может и должен зависеть от бизнес логики. Например: S>
S>[x] Отправлять ли извещения об изменениях в данной категории?
S> Введите адрес: [_________________________________________]
S>
О! Вот вот. Такое объяснение (от требований, так сказать), мне больше всего нравится. Именно поэтому я указал второй вариант в оригинальном посте точно тот, который вы предложили.
Фактически более правильно ИМХО предлагать пользователю воспользоваться возможностью (с дальнейшим уточнением параметров данной возможности), нежели вынуждать пользователя выбирать одно из двух.
Кстати, почему-то чекбоксы вообще как-то лучше воспринимаются пользователями. Возможно, потому что они ближе к реальной жизни — на бумажке чаще оперируют галочками (отметил, что сделал, например), а не радиобаттонами (мол, отметь — либо сделал, либо нет!)
S>И т.д. А то, что оба ответа можно спрятать в одно поле СУБД — игра слепого случая
Это я тоже согласен — конкретная реализация пользователя нисколько не волнует. Однако наличие NULL-ов (т.е. когда ситуация неопределена) пользователь воспринимает уже гораздо труднее , чем ноль/не ноль.
А ещё у пользователей часто замечаю пристрастие рассматривать неопределённую ситуацию как нулевую (например, если неизвестно, есть ли товар на складе или нет, то считаем, что его нет).
Здравствуйте, Spidola, Вы писали:
S>Существует свойство (к примеру, числовое), которое может использоваться, а может не использоваться в системе (физически в базе данных хранится либо число, либо NULL).
S>Пользователю нужно дать интерфейс настройки данного свойства. S>Один вариант — когда один контрол — что-то введено — учитывается, ничего не введено — не учитывается. S>Второй вариант — когда два контрола. Первый определяет учитывать или не учитывать, а второй определяет value свойства.
Существует банковская система ИБСО (разработка Центра Финансовых Технологий в Новосибирске). Там этот вопрос решен так: null-значение в поле ставится тогда, когда в поле нажата комбинация Shift+Del, иначе,даже если поле пустое, оно считается заполненным каким то (хоть даже пустым) значением. При null-значении фон всего поля ввода залит желтым цветом, иначе там остается белый прямоугольник, показывающий, что какое то значение все же есть.
Здравствуйте, Spidola, Вы писали:
S>А в банковских системах как раз не надо догадываться. Надо знать. Если не знаешь — значит не положено.
Неправильный подход. То что начальник может заставить работника освоить систему — никак не влияет на качества самой системы (в данном случае — на юзабилити).
Здравствуйте, nzeemin, Вы писали:
N>Здравствуйте, Spidola, Вы писали:
S>>А в банковских системах как раз не надо догадываться. Надо знать. Если не знаешь — значит не положено.
N>Неправильный подход. То что начальник может заставить работника освоить систему — никак не влияет на качества самой системы (в данном случае — на юзабилити).
Дык в данном случае (в банке) наоборот юзабилити как раз и направлено на решение задач безопасности. Если тебе положено что-то знать, ты знаешь и делаешь. Если не положено, то нечего экпериментировать и догадываться... Это как с ФАПСИшниками — когда систему демонстрируешь — они говоря: "Неправильно, не соответствует по безопасности". А когда спрашиваешь, что сделать, чтобы соответствовало, отвечают: "Не скажем — это ваша забота. Наша забота — проверить на соответствие".
Здравствуйте, nzeemin, Вы писали:
N>Здравствуйте, Spidola, Вы писали:
S>>Дык в данном случае (в банке) наоборот юзабилити как раз и направлено на решение задач безопасности. Если тебе положено что-то знать, ты знаешь и делаешь. Если не положено, то нечего экпериментировать и догадываться... Это как с ФАПСИшниками — когда систему демонстрируешь — они говоря: "Неправильно, не соответствует по безопасности". А когда спрашиваешь, что сделать, чтобы соответствовало, отвечают: "Не скажем — это ваша забота. Наша забота — проверить на соответствие".
N>Не может юзабилити решать задачи безопасности. Эти задачи решаются ограничениями. Либо есть возможность сделать что-то, либо она закрыта. Если возможность есть — то пользователь может ее найти, и с точки зрения безопасности не важно как она реализована. При этом для безопасности не важно какими юзабилити-свойствами обладает продукт — важно чтобы все дырки были закрыты.
Я не утверждаю, что только юзабилити решает вопросы безопасности, разумеется. Было бы, по крайней мере, неразумно это предполагать. То интерфейсны пользователя могут являться и являются компонентами решений вопросов безопасности. Хотите пример? Lotus Notes — при вводе пароля пользователя показываются различные иконки перескакивающие, которые физиологически отвлекают возможного злоумышленника, стоящего за спиной. Хотите пример попроще? Ввод пароля в Windows — отображаются звёздочки... Так что я бы не стал на вашем месте утеврждать, что элементы юзабилити не используются для решения вопросов безопасности.
Юзабилити, как некий качественный признак системы, может быть измерян по некоторым характеристикам и оценен, в том числе, относительно целей продукта. И, если одной из целей продукта является безопасная реализация каких-нибудь бизнес-процессов, то юзабилити вполне может являться средством реализации данной цели.
N>С другой стороны, качество продукта с точки зрения юзабилити не зависят от того — банковская это система или какая-то другая и какие требования выдвигаются по части безопасности.
Ещё как зависит... Следуя вашим рассуждениям, безопасность — это ограничения, а ограничения касаются в том числе удобства использования. Далее самостоятельно
Здравствуйте, 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> Вопрос безопасности решался бы не показом вообще ничего.
Плохо
Posted via RSDN NNTP Server 1.9
WBR, Igor Evgrafov
Re[3]: Позвольте не согласиться
От:
Аноним
Дата:
30.05.05 17:14
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, adontz, Вы писали: A>>ИМХО первый вариант вообще нельзя использовать, второй лучше но не идеален, а надо так A>>Ну и колечно когда выбрано use default value EDIT должен быть выключен. S>Подход совершенно верный. Я бы еще дополнил, что бизнес-логика в таком случае на самом деле включает в себя два вопроса. И только второй из них про значение. При этом текст вопроса может и должен зависеть от бизнес логики. Например: S>
S>[x] Отправлять ли извещения об изменениях в данной категории?
S> Введите адрес: [_________________________________________]
S>
S>И т.д. А то, что оба ответа можно спрятать в одно поле СУБД — игра слепого случая
Итак, имеется конкретная задача: рабочее место врача-эксперта (члена некоей комиссии).
Врач должен отразить свое мнение по баальшущему списку (~100) вопросов, каждый из которых имеет ~10 вариантов ответов. Причем практически по любому из них у него мнения может и не быть (не уверен, не уполномочен и т.п.) — т.е. типичное значение "не известно","не знаю" — т.е. NULL. И что же, прикажете вместо 100 контролов (комобо-боксов в этом случае) лепить 200?!
Действительно, бизнес-логика включает два вопроса, но зачем же этим загружать пользователя (и перегружать интерфейс)?! И средствами одного контрола можно показать, что значение не определено (если spin-edit пустой — IMHO все и так понятно). Это ж не бумажный документ, где нужно явно ставить прочерк или Z, чтобы враг не вписал чего лишнего!
Достаточно дать пользователю единообразный способ очистки (сброса в NULL) любого атрибута (комбинация клавиш и кнопка на тул-баре, а для комбо-бокса, кроме того, в список можно ввести пустую строку или строку типа "Не определено").
По-моему, грузить пользователя различиями между "пусто", "отсутствует", "не определено", "по-умолчанию" и т.п. нужно, только если без этого действительно не обойтись (в случае текста, если пустая строка имеет смысл, отличный от "не определено" или в случае, если атрибут — множественное значение на основе справочника).
Здравствуйте, Аноним, Вы писали:
А>И что же, прикажете вместо 100 контролов (комобо-боксов в этом случае) лепить 200?!
На самом деле да! Просто тут логика работы приложения несколько другая выходит. По умолчанию выделен radiobutton default_value, а как только в текстовое поле начинают что-то вводить выделяется radiobutton specified_value.
с одной стороны внешне стандартный интерфейс, с другой удобство заполнения
Здравствуйте, Sinclair, Вы писали:
S>... Ленивый разработчик просто дает возможность забить лишние ответы нуллами. Специалист по юзабилити задает только те вопросы, которые необходимы.
Согласен, конечно, но вот говорят же, что медицина — не наука. По мне — может быть и наука, но как предметная область очень плохо она поддается формализации (как и вся хм... наша жызнь). Точнее она поддается, но в моей задаче очень постепенно, от версии к версии системы — вместе с сознанием работающих с ней людей. Неужели в Вашей практике всегда было все так гладко и строго: "только те, которые необходимы"? А ведь, наверное, есть еще системы где без голого SQL в качестве UI не обойтись?
И все-таки. Неужели я совсем неправ?! Пользователи моей системы исторически привыкли работать с бумажными формами о двадцати страницах, в которых они ставят галочки, подчеркивают слова и вписывают произвольный текст. Ну, натурально, я в качестве основной метафоры интерфейса использовал понятие "документ" — оглавление, значить, слева, а на остальной части формы с вертикальным скроллингом, сгруппированные в параграфы, расположены контролы всякие (и гриды и tree-list-ы встречаются, но комбо-боксы в основном). Каждый из этих контролов — это знакомый пользователям по докомпьютерной жизни реквизит. Операции унифицированные для реквизитов определил, из которых "очистить" — для всех работает, а "изменить", "добавить", "удалить", "вверх", "вниз" и т.д. — для сложных (списков, например), все это и в тул-баре и в контекстном меню дублируется...
Даже отдельные параграфы громоздкими получаются (а они у меня строго соответствуют параграфам "бумажным"), так мне еще и дополнительные чек-боксы рядом с каждым реквизитом ставить? Кстати да — общее число реквизитов в документе может и тысячи досигать и рядом с каждым по вашему должно "Использовать реквизит" быть написано? И это будет юзабилити?!
Здравствуйте, 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:
Здравствуйте, sokohigh, Вы писали: S> Мучает же меня другой вопрос: "Кто сильнее: кит или слон?" ... блин сорри, "Что лучше (для юзабилити, конечно): 100 контролов + общая операция очистки реквизита (сброса в значение по умолчанию, кот.видно пользователю,напр: Температура тела: [36.62 ] > жмем кнопку "Очистить"> Температура тела: [Не измер.]) ИЛИ 200 контролов с безупречной логикой и с 2x ОБЪЕМОМ ВИЗУАЛЬНОЙ ИНФОРМАЦИИ для глазок пользователя (часто позднепенсионного возраста в моей задаче)?" А?
Это сферический конь в вакууме. Как правило, длинные анкеты имеют свойство содержать сильно связанные группы вопросов. Тогда один признак рулит группой вопросов, и реально объем действий уменьшается, а не увеличивается:
-- [x] У вас есть квартира? --
Площадь: [ ] кв.м.
Комнат: [ 1[v]]
Этаж: [ 1 +-]
Количество прописанных: []
[x] Приватизирована
Дата приватизации: [ . . ]
Вместо очистки 4х полей достаточно снять одну галочку.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А то я тоже умею придираться — как это "с протянутой рукой", да и "помочь"? 
