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

Пользователю нужно дать интерфейс настройки данного свойства.
Один вариант — когда один контрол — что-то введено — учитывается, ничего не введено — не учитывается.
Второй вариант — когда два контрола. Первый определяет учитывать или не учитывать, а второй определяет value свойства.



Теперь сам вопрос: есть ли какие-либо рекомендации по использованию/неиспользованию первого или второго способов? Имеется виду рекомендации типа Microsoft-овских по интерфейсу и подобных.
Если нет, то какова общая практика?
Зависит использование первого или второго способа от контекста или нет?
Интересно также научно-казуистическое обоснование того или иного способа...

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

ИМХО первый вариант вообще нельзя использовать, второй лучше но не идеален, а надо так


Ну и колечно когда выбрано use default value EDIT должен быть выключен.

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

S>Если нет, то какова общая практика?

Мое скромное ИМХО: поставить под элементом управления для ввода значения флажок "Use default value" и разрешать/запрещать сам элемент управления в зависимости от того, сбросил пользрователь этот флажок или нет (самой собой, в случае запрета элемента управления "поле ввода" необходимо очистить).

Здравствуйте, 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" понятно, а в моем — нет?

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

A>>Ну и колечно когда выбрано use default value EDIT должен быть выключен.
S>Да, так очень неплохо. А что насчёт официальных рекомендаций?

Дык это собственно они и были (от MS)

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

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

S>>Как-то несколько путано, честно говоря, получается. Я не совсем понял про Default value... Там ведь не значение по умолчанию, а использовать/не использовать.

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

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

SDB>P.S.
SDB>А почему это в Ромином ответе про "default value" понятно, а в моем — нет?
Да, и действительно... Я просмотрел в Ромином ответе слово "default", ухватившись глазом за идею более высокого порядка значимости... А так бы тоже пнул

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

S>Дело в том, что в описании было примерно так — использовать ли ограничение по количеству, а если использовать, то какое...

Тогда Ромин вариант самое то.

S>А так бы тоже пнул

Очень мило! Мы тут с протянутой рукой, помочь хотели, а он — пинаться...

Здравствуйте, Spidola:

Можно так


состояние "по умолчанию" каждой такой пары надо смотреть по месту.

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

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

S>>Дело в том, что в описании было примерно так — использовать ли ограничение по количеству, а если использовать, то какое...

SDB>Тогда Ромин вариант самое то.

S>>А так бы тоже пнул

SDB>Очень мило! Мы тут с протянутой рукой, помочь хотели, а он — пинаться...

Ну я ж образно говоря — чего к словам придираться А то я тоже умею придираться — как это "с протянутой рукой", да и "помочь"?

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

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

Или:

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

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

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

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

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

S>Или:
S>

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

О! Вот вот. Такое объяснение (от требований, так сказать), мне больше всего нравится. Именно поэтому я указал второй вариант в оригинальном посте точно тот, который вы предложили.

Фактически более правильно ИМХО предлагать пользователю воспользоваться возможностью (с дальнейшим уточнением параметров данной возможности), нежели вынуждать пользователя выбирать одно из двух.

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

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

Это я тоже согласен — конкретная реализация пользователя нисколько не волнует. Однако наличие NULL-ов (т.е. когда ситуация неопределена) пользователь воспринимает уже гораздо труднее , чем ноль/не ноль.

А ещё у пользователей часто замечаю пристрастие рассматривать неопределённую ситуацию как нулевую (например, если неизвестно, есть ли товар на складе или нет, то считаем, что его нет).

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

S>Существует свойство (к примеру, числовое), которое может использоваться, а может не использоваться в системе (физически в базе данных хранится либо число, либо NULL).

S>Пользователю нужно дать интерфейс настройки данного свойства.
S>Один вариант — когда один контрол — что-то введено — учитывается, ничего не введено — не учитывается.
S>Второй вариант — когда два контрола. Первый определяет учитывать или не учитывать, а второй определяет value свойства.

Существует банковская система ИБСО (разработка Центра Финансовых Технологий в Новосибирске). Там этот вопрос решен так: null-значение в поле ставится тогда, когда в поле нажата комбинация Shift+Del, иначе,даже если поле пустое, оно считается заполненным каким то (хоть даже пустым) значением. При null-значении фон всего поля ввода залит желтым цветом, иначе там остается белый прямоугольник, показывающий, что какое то значение все же есть.

Здравствуйте, Fktrc, Вы писали:
F>Существует банковская система ИБСО (разработка Центра Финансовых Технологий в Новосибирске). Там этот вопрос решен так: null-значение в поле ставится тогда, когда в поле нажата комбинация Shift+Del, иначе,даже если поле пустое, оно считается заполненным каким то (хоть даже пустым) значением. При null-значении фон всего поля ввода залит желтым цветом, иначе там остается белый прямоугольник, показывающий, что какое то значение все же есть.
Нда. Хрен догадаешься.

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

S>Здравствуйте, Fktrc, Вы писали:
F>>Существует банковская система ИБСО (разработка Центра Финансовых Технологий в Новосибирске). Там этот вопрос решен так: null-значение в поле ставится тогда, когда в поле нажата комбинация Shift+Del, иначе,даже если поле пустое, оно считается заполненным каким то (хоть даже пустым) значением. При null-значении фон всего поля ввода залит желтым цветом, иначе там остается белый прямоугольник, показывающий, что какое то значение все же есть.
S>Нда. Хрен догадаешься.
А в банковских системах как раз не надо догадываться. Надо знать. Если не знаешь — значит не положено.

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

S>А в банковских системах как раз не надо догадываться. Надо знать. Если не знаешь — значит не положено.

Неправильный подход. То что начальник может заставить работника освоить систему — никак не влияет на качества самой системы (в данном случае — на юзабилити).

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

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

S>>А в банковских системах как раз не надо догадываться. Надо знать. Если не знаешь — значит не положено.

N>Неправильный подход. То что начальник может заставить работника освоить систему — никак не влияет на качества самой системы (в данном случае — на юзабилити).

Дык в данном случае (в банке) наоборот юзабилити как раз и направлено на решение задач безопасности. Если тебе положено что-то знать, ты знаешь и делаешь. Если не положено, то нечего экпериментировать и догадываться... Это как с ФАПСИшниками — когда систему демонстрируешь — они говоря: "Неправильно, не соответствует по безопасности". А когда спрашиваешь, что сделать, чтобы соответствовало, отвечают: "Не скажем — это ваша забота. Наша забота — проверить на соответствие".

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

S>Дык в данном случае (в банке) наоборот юзабилити как раз и направлено на решение задач безопасности. Если тебе положено что-то знать, ты знаешь и делаешь. Если не положено, то нечего экпериментировать и догадываться... Это как с ФАПСИшниками — когда систему демонстрируешь — они говоря: "Неправильно, не соответствует по безопасности". А когда спрашиваешь, что сделать, чтобы соответствовало, отвечают: "Не скажем — это ваша забота. Наша забота — проверить на соответствие".

Не может юзабилити решать задачи безопасности. Эти задачи решаются ограничениями. Либо есть возможность сделать что-то, либо она закрыта. Если возможность есть — то пользователь может ее найти, и с точки зрения безопасности не важно как она реализована. При этом для безопасности не важно какими юзабилити-свойствами обладает продукт — важно чтобы все дырки были закрыты.
С другой стороны, качество продукта с точки зрения юзабилити не зависят от того — банковская это система или какая-то другая и какие требования выдвигаются по части безопасности.

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

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

S>>Дык в данном случае (в банке) наоборот юзабилити как раз и направлено на решение задач безопасности. Если тебе положено что-то знать, ты знаешь и делаешь. Если не положено, то нечего экпериментировать и догадываться... Это как с ФАПСИшниками — когда систему демонстрируешь — они говоря: "Неправильно, не соответствует по безопасности". А когда спрашиваешь, что сделать, чтобы соответствовало, отвечают: "Не скажем — это ваша забота. Наша забота — проверить на соответствие".

N>Не может юзабилити решать задачи безопасности. Эти задачи решаются ограничениями. Либо есть возможность сделать что-то, либо она закрыта. Если возможность есть — то пользователь может ее найти, и с точки зрения безопасности не важно как она реализована. При этом для безопасности не важно какими юзабилити-свойствами обладает продукт — важно чтобы все дырки были закрыты.

Я не утверждаю, что только юзабилити решает вопросы безопасности, разумеется. Было бы, по крайней мере, неразумно это предполагать. То интерфейсны пользователя могут являться и являются компонентами решений вопросов безопасности. Хотите пример? Lotus Notes — при вводе пароля пользователя показываются различные иконки перескакивающие, которые физиологически отвлекают возможного злоумышленника, стоящего за спиной. Хотите пример попроще? Ввод пароля в Windows — отображаются звёздочки... Так что я бы не стал на вашем месте утеврждать, что элементы юзабилити не используются для решения вопросов безопасности.

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

N>С другой стороны, качество продукта с точки зрения юзабилити не зависят от того — банковская это система или какая-то другая и какие требования выдвигаются по части безопасности.

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