Как стать автором
Обновить

Комментарии 8

Первое.
Подсветка надписей — не сильно нравится. Лучше всё-таки цветные звёздочки — слева или справа от требуемых полей (а не около подписи!!). И ещё — ничто не бесит больше, чем глючной порядок табуляции в формах, где надо много бегать клавиатурой.

Второе.
Действительно проще. Допустим…

if edName.Text<>''
then raise EValidation.Create('Имя не должно быть пустым.');

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

Третье. Усилия должны быть пропорциональны эффекту! В смысле, небольшую утилитку не стоит писать с красивыми окошечками. В этом плане окончательно бездарен большой и жирный Logitech SetPoint, который и пускают-то в интерактивном режиме раз в пятилетку. А в памяти эти 9 мегабайт висят постоянно.
Чтобы программа стоила скинования, сама программа должна этого заслужить! То есть, либо большая сложная программа, либо популярная, для большой аудитории.

А самый большой грех — не смешивать стандартные окна со скинованными. Хорошо сделано в Photoshop: там скины предельно «прозрачны» и отлично уживаются практически с любым скином ОС. Своими глазами видел программу, где _часть_ окон была с искусственным скином, имитирующим Windows XP — на «классической» теме Windows смотрелось аляповато.
1. Звездочки уже привычно. Хотя все равно. Тут уже вопрос дизайна. Главное единообразно. А там при частой работе с приложением можно ко всему привыкнуть.
2. Если есть зависимость между вводимыми данными то при сохранении. Да вообще привычнее при сохранении.
1,2 Есть предложение делать значки слева (или справа) от полей. Звездочка обязательное поле. Восклицательный знак — допущена ошибка. Анимированная фигнюшка — поле вводится.
Плюс, не забывайте про клавиатурную навигацию. Правильный порядок табуляции. Еще мне было бы удобно, если при исправлении ошибочных данных таб проходился не по всем полям, а только по полям с ошибкой.
3. Нет. В 98% случаев это лишнее. Тот же скайп настолько выделяется из моей темы, что выглядит не хорошо.
Лично мне нравится идея смены фона для обязательного поля с белого на светло-желтый. Он нормально воспринимается и не отвлекает от процесса.
Попробуйте заглянуть сюда, там есть ссылки на рекомендации, в т.ч. и от Microsoft:
en.wikipedia.org/wiki/Human_interface_guidelines
Мои пять копеек

Первое
Как уже говорилось, это дело вкуса. Я предпочитаю выделять такие поля жирным шрифтом. Другим цветом тоже можно, но это не должно вызывать отторжения (ну, то есть совсем уж кислотные цвета не стоит использовать). Кроме того, при выделении цветом надо учитывать то, что пользователь может сменить палитру (конечно, если приложение само по себе допускает смену цветов окошек)

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

Третье
Если программа имеет свой интерфейс — то это хорошо. С другой стороны современные средства скинования позволяют изменить приложения до неузнаваемости и зачастую в ущерб юзабилити. То есть всё хорошо в меру. Я могу порекомендовать подумать над своим стилем, который не будет идти вразрез с идеологией Виндовс, но тем не менее будет немного отличаться (в смысле цветового решения, например, или самодельных иконок). Небольшой документ, опысывающий принципы построения интерфейса также хорош, если в команде работает несколько разработчиков. Нет ничего хуже плавающего размера кнопок или разного расположения, когда один разработчик ставит кнопки в порядке OK/Cancel, а другой Cancel/OK, и.т.д.
1. В давние времена я рисовал красную звездочку около нужного элемента, теперь использую стандартный textual cue. Установить его для edit окна можно через сообщение EM_SETCUEBANNER

2. Тут зависимость от того, как выводится ошибка. Если для отображения ошибки вы используете красный цвет для текста, то лучше делать проверку одновременно с процессом ввода данных. Но лично я предпочитаю использовать стандартный системный balloon. Проверка естественно делается при потере фокуса ввода.


3. Не хорошо ,) Если уж и делать не стандартный интерфейс, то лучше всего заказать его в профессиональной студии, вот пример. И самое главное не облажаться как разработчики скайпа в вашем примере, потому что запросить размеры рамок у системы можно элементарно.

Дополнение к второму пункту: встречался с такой ситуацией, что люди после длительного опыта работы с программой начинают набирать данные не глядя на экран, поэтому крайне желательно не забыть делать beep для них при ошибочных данных. И как вариант с моим balloon'ом, также включать красный цвет текста, чтобы в конце набора (все же проигнорировав звуковые предупреждения) они сразу могли увидеть все места, в каких допустили ошибки.
По п.3, считаю, что интерфейс допустимо скинировать: менять цвета, форму виджетов, элементы виджетов (кружочки/стрелочки комбо/чекбоксов), закруглить углы окна. Но сама суть работы с оконным интерфейсом не должна меняться: главное меню, манели, закладки, чекбоксы/комбобоксы и т.д. должны выполнять свою работу. То есть как в стандартном GUI.
В работе сталкивался с решениями, когда обычная кнопка посреди формы раскрывала на форме какую-то панель, что весьма не логично. Либо поверх табличной части была установлена кнопка (не как элемент ввода внутри ячейки). Лично меня такие решения, как пользователя, ставят в ступор, потому что работа интерфейса для меня становится не очевидной.
В процессе работы на производстве пришли к следующим выводам: 1) поведение — стандартный win gui интерфейс; 2) контроль ввода данных (ошибки выводили в msgBox); 3) узкий коридор действий, допускающий выполнять только то, что положено данному пользователю (права доступа); 4) показывать в интерфейсе только то, что положено данному пользователю (ничего лишнего и только один способ получения результата, а не как в 1с).
В качестве примера качественного интерфейса я всегда ставил интерфейс 1сv8: все элементы интерфейса у них рисуются самостоятельно, красиво и своими цветами — это дает гарантию, что интерфейс будет выглядеть одинаково на всех машинах, не смотря на цветовые настройки и настройки шрифтов в windows у данного пользователя. Они допускают мелкие хитрости, например, вместо Label выводят Edit, но без рамки и с цветом фона. Выглядит это как Label, но позволяет выделять и копировать надпись.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории