Comments 101
Мне ближе первый вариант. Меньше лишних движений.
А неожиданная реакция на неправильный ввод — нормально?
А кто сказал что она должна быть неожиданная? Ведь не вылезает никаких месседжбоксов, ничё не прыгает, элементы интерфейса не «разъезжаются». Просто во время ввода надпись «Введите число» меняет цвет на красный, и иконка, чтобы внимание обратить, появляется аккуратно. И сразу видно, что что-то не так и надо(можно) исправить. И не надо после каждого исправления переводить руку с клавы на мышку чтобы курсором то на кнопку, то на поле ввода тыкать.
Меня это раздражает, когда к примеру, хочешь ввести число, промахнулся по клавиатуре, а оно — хоп! и покраснело. Ощущение что тебя за дурака держат ...
Промахнулся = покраснело = заметил = исправил.
Промахнулся = не проверило/не покраснело = не заметил = нажал кнопку = покраснело = сидишь и ищешь, что не так, где же промахнулся 0_o.
Промахнулся = не проверило/не покраснело = не заметил = нажал кнопку = покраснело = сидишь и ищешь, что не так, где же промахнулся 0_o.
Дык для того и краснеет чтоб не искать )
Вот поэтому я за первый вариант:)
Я тоже за первый, но с оговоркой. Либо убрать этот воскл знак и оставить только красную рамку (ибо он действиетльно "вылетающий"), либо в нормальном положении вместо него показывать что-то с ассоциацией "ожидаю ввода" и потом при правильном вводе менять на зеленый или на красный. Чтобы новых элементов не появлялось из неоткуда.
Здорово как раз. Юзер сразу увидит, что делает не то.
UFO just landed and posted this here
Первый вариант лучше:
- интуитивно понятно, что ввод данных обязателен;
- проверка при вводе избавляет от разочарования от факта, что "ввел, нажал, неправильно".
Хорошо бы кроме пиктограммы ошибки давать еще и пояснение.
- интуитивно понятно, что ввод данных обязателен;
- проверка при вводе избавляет от разочарования от факта, что "ввел, нажал, неправильно".
Хорошо бы кроме пиктограммы ошибки давать еще и пояснение.
Пояснение ведь есть: "Введите ЧИСЛО".
Ну вот я возьму и введу "ПЯТЬ". Число? Число. Но не ЧИСЛО %)
Так что если ошибка возникла, нужно детально описать возможные ее причины и способы устранения.
Так что если ошибка возникла, нужно детально описать возможные ее причины и способы устранения.
Слушайте 404, что-то подсказывает мне, что человек с таким ником знаком с ошибками не понаслышке :).
Можно поставить фильтр. Чтобы вводились только цифры.
Я в таких случаях лезу проверять шнур от клавиатуры =)
Просто необходимо визуально показывать пользователю. Например, при каждом плохом нажатий приморгнуть рамкой ввода.
Мне кажется это перегиб. Программинг, дизайнинг и багфиксинг будет золотой. Это нормально для какого-то мегаважного поля, как например в webmoneykeeper-е — потому что несколько раз введешь неверно — заблокируют аккаунт.
Кому перегиб, а кому — качественная работа ,)
или пустая трата ресурсов. Если у тебя будет много таких полей и они начнут мигать, в некоторых случаях можешь потерять производительность. Если это javascript, то подобные мелочи могут навредить только.
Спасибо — проапдейтил картинку: добавил «*» во втором варианте.
Подсказки всплывают по наведению на иконку. Выводить не хочется целиком, т.к. это стандартная фишка divexpress и там место оооочень мало.
Подсказки всплывают по наведению на иконку. Выводить не хочется целиком, т.к. это стандартная фишка divexpress и там место оооочень мало.
И все-таки мне кажется лучше, если изначально кнопка будет неактивна. Особенно, если эта форма является промежуточной в каком-нибудь мастере и кнопка находится на том же месте, где и кнопка в предыдущем экране. А расположение кнопок перехода на следующий шаг в одном и том же месте - это очень правильное решение.
Так вот, если кнопка "Вперед" расположена в одном и том же месте, и не "задизейблена", то есть шанс нарваться на двойной клик.
Так вот, если кнопка "Вперед" расположена в одном и том же месте, и не "задизейблена", то есть шанс нарваться на двойной клик.
а зачем вообще позволять вводить ошибочные данные?
А не всегда можно сразу ввести данные в нужном формате, не вводя промежуточные.
Кажется, в одной из версий фотошопа (а может ещё где-то), чтобы ввести отрицательное число нужно было написать сначало число, а потом пририсовать минус, а то если начинать вводить число с минуса, ввод распознаётся как некорректный.
Кажется, в одной из версий фотошопа (а может ещё где-то), чтобы ввести отрицательное число нужно было написать сначало число, а потом пририсовать минус, а то если начинать вводить число с минуса, ввод распознаётся как некорректный.
А вот мне ближе второй вариант, потому что не люблю когда форма реагирует без предупреждений. Мне понятно, что нажимая на кнопку «вперед» я либо пройду дальше либо увижу, что я сделал не так.
Как вариант промежуточного решения:
- кнопка "Вперед" неактивна;
- если в поле что-то введено, кнопка становится активна;
- проверка валидности введенных данных происходит по нажатию.
- кнопка "Вперед" неактивна;
- если в поле что-то введено, кнопка становится активна;
- проверка валидности введенных данных происходит по нажатию.
Хороший компромисс )
Согласен, т.к. у первого варианта еще одна возможная проблема: когда результат валидации (красность) появиться тогда, когда пользователь будет заполнять другое поле (проверенного уже и на экране может быть не видно). например если проверки "тяжелые", или коннект у пользователя плохой. Т.е. он заполнит поле, броситься заполнять следующее, а потом выясниться, что первое поле заполненно неправильно.
UFO just landed and posted this here
Первый. Правда видел такое я всего пару раз в программах Adobe при вводе серийника, да в инсталляторе Delphi в том же случае. Сразу видно, правильно ввел или нет.
Мне больше нравится первый вариант. Нажать на 'Далее', чтобы проверить, правильно я все-таки ввел, или нет - не по мне.
Первый вариант с указанием ошибки, при неправильном вводе.
Первый вариант, мне кажется, лучше. Пользователь сразу при вводе видит, правильно или не правильно. И сразу исправляет. Не нужно лишних кликов.
первый разумеется.
можно было бы ещё например извратиться и повесить небольшой прямоугольнчек сверху или снизу всех форм, который бы загорался красным и писал, что именно введено неверно (через запятую, ха) или же напротив загорался зелёным, если бы всё было введено верно.
кнопку вперёд, мне кажется, в любом случае надо отключать, пока не введут необходимые данные.
можно было бы ещё например извратиться и повесить небольшой прямоугольнчек сверху или снизу всех форм, который бы загорался красным и писал, что именно введено неверно (через запятую, ха) или же напротив загорался зелёным, если бы всё было введено верно.
кнопку вперёд, мне кажется, в любом случае надо отключать, пока не введут необходимые данные.
я за первый вариант, вот только почему то кажется, что стоит запретить ввод всего кроме цифр.
т.е. когда нажимаешь не цифровую клавишу - в поле ничего не вводится, и звучит стандартный сигнал ошибки (стоит ли выделять поле красным не уверен).
т.е. когда нажимаешь не цифровую клавишу - в поле ничего не вводится, и звучит стандартный сигнал ошибки (стоит ли выделять поле красным не уверен).
Сделайте возможным вводить в это поле только цифры. А при попытке пользователя ввести буквы, очень ненавязчиво, чтобы не вызывать раздражения, показать под полем ввода сообщение о том, что нужно ввести цифры.
Так:
- кнопка неактивна
- ввожу текст
- жму кнопку, вижу ошибку
Если проверять в процессе ввода:
1. проверка может быть сложной/трудоемкой, комп может подвиснуть и я не пойму причины, в отличие от того, что комп зависает именно в момент проверки, после нажатия кнопки
2. я могу вводить текст, глядя только на клавиатуру и не видеть того, что все уже давно плохо
3. могу испугаться того, что когда начинал вводить текст, форма была одной, когда поднял глаза, то увидел не совсем то, что ожидал увидеть :) Т.е. нужно будет понимать, что произошло.
- кнопка неактивна
- ввожу текст
- жму кнопку, вижу ошибку
Если проверять в процессе ввода:
1. проверка может быть сложной/трудоемкой, комп может подвиснуть и я не пойму причины, в отличие от того, что комп зависает именно в момент проверки, после нажатия кнопки
2. я могу вводить текст, глядя только на клавиатуру и не видеть того, что все уже давно плохо
3. могу испугаться того, что когда начинал вводить текст, форма была одной, когда поднял глаза, то увидел не совсем то, что ожидал увидеть :) Т.е. нужно будет понимать, что произошло.
UFO just landed and posted this here
software-программа - по моему звучит как маслянное масло.
Возможно имеется ввиду desktop application и web application?
По теме.
Первый вариант,
1. Если поле пустое кнопка не активна.
2. При вводе нецифрового символа на форме выводится алерт, кнопка не активна.
3. Если пользователь все делает правильно, то у него не возникает никаких проблем. Не правильно он просто неможет сделать.
Возможно имеется ввиду desktop application и web application?
По теме.
Первый вариант,
1. Если поле пустое кнопка не активна.
2. При вводе нецифрового символа на форме выводится алерт, кнопка не активна.
3. Если пользователь все делает правильно, то у него не возникает никаких проблем. Не правильно он просто неможет сделать.
Голосую за второй вариант. Аргументы:
1) Если кнопка предусмотренна, то она должна быть видна и активна при любом варианте.
Если кнопка не нажимается, то ее не должно быть вовсе. Не спрятана!!! А просто не должно быть.
2) Реализация глючности. Проверка на лету это хорошо, только проверять надо очень много событий - ввод с клавиатуры, копипаст мышкой, копипаст клавиатурой. Утверждать, что пользователь будет пользоваться только клавиатурным вводом нельзя. Вы готовы реализовать все возможные евенты?
1) Если кнопка предусмотренна, то она должна быть видна и активна при любом варианте.
Если кнопка не нажимается, то ее не должно быть вовсе. Не спрятана!!! А просто не должно быть.
2) Реализация глючности. Проверка на лету это хорошо, только проверять надо очень много событий - ввод с клавиатуры, копипаст мышкой, копипаст клавиатурой. Утверждать, что пользователь будет пользоваться только клавиатурным вводом нельзя. Вы готовы реализовать все возможные евенты?
UFO just landed and posted this here
Ну для десктопа да - методы есть. Вопрос по реализации снимается, но кнопку разлочить и позволить пользователю самому наступить на грабли о которых его предупреждали. Т.е. все равно вариант 2. И пусть выскакивает что-то модальное.
UFO just landed and posted this here
веб один из частных случаев application. Он может быть и очень даже десктоп.
То что предложено в первом варианте это ни что иное как "бантик", никак не влияющий на основной функционал программы.
То что кнопка должна быть доступна для нажатия всегда это даже не обсуждается - менее приемлемым решением было бы вывести в этой форме надписи типа "кнопка станет доступной, когда вы таки заполните поля правильно". Будет такая надпись на этой форме? - нет. Я работал "внедренцем" и знаю чем грозят такие "бантики".
Пользователь имеет право нажать на активную кнопку даже если он ничего в форме не заполнил. И получить свою порцию объяснений почему эта форма не будет сохранена.
Опять же про удобство - мне, например, удобно заполнять и редактировать форму, когда ничего лишнего меня не отвлекает, а то что предлагается в первом варианте - это именно лишнее мелтешение и моргание.
То что предложено в первом варианте это ни что иное как "бантик", никак не влияющий на основной функционал программы.
То что кнопка должна быть доступна для нажатия всегда это даже не обсуждается - менее приемлемым решением было бы вывести в этой форме надписи типа "кнопка станет доступной, когда вы таки заполните поля правильно". Будет такая надпись на этой форме? - нет. Я работал "внедренцем" и знаю чем грозят такие "бантики".
Пользователь имеет право нажать на активную кнопку даже если он ничего в форме не заполнил. И получить свою порцию объяснений почему эта форма не будет сохранена.
Опять же про удобство - мне, например, удобно заполнять и редактировать форму, когда ничего лишнего меня не отвлекает, а то что предлагается в первом варианте - это именно лишнее мелтешение и моргание.
Обычно, это одно событие, реагирующее на изменение текста в поле, напирмер, TextChanged в .NET
UFO just landed and posted this here
Объясните мне непонятливому что значит словосочетание "software-программа"?
По удобству кажется нормальным такой вариант:
Все практически так же как во втором варианте, но ещё можно добавить проверку значение когда убираем фокус с поля.
Все практически так же как во втором варианте, но ещё можно добавить проверку значение когда убираем фокус с поля.
не надо проверять! Одна проверка всей формы после нажатия кнопки. Просто, дешево и сердито.
Я бы все-таки объединил эти 2 варианта :)
Зачем отягщать код дополнительной проверкой, которая заведомо будет проведена при нажатии на кнопку? Только для того что бы довесить еще один бантик?
Мне кажется это будет чуть удобнее, и не намного перегружает ввод
Цель и назначение программы (конкретной формы)? Заполнить ее и сохранить, а не мелькать по каждому поводу и без повода. Наверняка это будет не одно поле и не одна проверка. И все это будет моргать, подмигивать и издавать звуки. Это допустимо в детской, развивающей игре, но не в серьезном корпоративном приложении. Опишите свои ощущения во время работы с первым вариантом, где таких полей будет более чем одно. Напишите сценарии работы. И не так, как есть сейчас, а с привязкой к окончательному пользователю - кто будет пользоваться этой формой - девушка Маша, которая вводит потоково вводит данные, бухгалтер, дирректор, менеджер, кто-то еще. Попробуйте стать на их место. На место пользователя, который видит ваше приложение в первый раз и инструкцию по применению еще не читал.
В том то и дело, что ошибки будут появляться постепенно. Это позволит походу все корректировать и не пугаться конечного результата. Когда в конце по нажатию на кнопку "далее", программа сообщит о наличии 5-6 ошибок, то можно и неплохо напугать пользователя, и ему прийдется дольше искать те поля, где именно он совершил ошибку, собираться с мыслями заново, так сказать.
Спор думаю особо смысла не имеет. Если выбирать между двумя предложенными автором способа - я выберу второй. Если свой вариант, то дополненный второй. Но не проверяющий во время воода (как в первом варианте), а после окончания ввода конкретного поля.
Спор думаю особо смысла не имеет. Если выбирать между двумя предложенными автором способа - я выберу второй. Если свой вариант, то дополненный второй. Но не проверяющий во время воода (как в первом варианте), а после окончания ввода конкретного поля.
Вариант 1.
Kengry 26 ноября 2007 13:52
"Меня это раздражает, когда к примеру, хочешь ввести число, промахнулся по клавиатуре, а оно — хоп! и покраснело".
Проверку делать не "на лету", а после нажатия кнопки.
Kengry 26 ноября 2007 13:52
"Меня это раздражает, когда к примеру, хочешь ввести число, промахнулся по клавиатуре, а оно — хоп! и покраснело".
Проверку делать не "на лету", а после нажатия кнопки.
На самом деле все зависит от того, что за проверку делать надо.
Если это строка/число причем в "тупом" понимании ("6" — число, а "шесть" — строка), то все просто.
А если надо проверять что-то более сложное? Если проверка включает в себя запрос к субд? Который при большом везении может быть выполнен в течение 5-10 сек?
Если надо разрешить ввести "стопятнядцать" и привести это к виду "115", если ввод "10" корректен, а "110" опечатка? Причем диапазон нечеткий и задается потоком данных (скажем какие-то измерения, которые должны лечь с определенной погреностью на некую кривую)?
С одной стороны надо стремиться минимизировать количество действий пользователя, не связанных непосредственно с вводом данных, а с другой стороны нельзя допустить попадания "шума" в БД.
Кстати, не рассмотрен 3-й вариант, данные принимаются в любом случае, проверка производится асинхронно, то, что можно исправить автоматически — исправляем (например "1 0" на "10" или "–10" на "-10"), то, что требует корректироваки пользователем, просим его поправить в специальной форме АРМа.
Если это строка/число причем в "тупом" понимании ("6" — число, а "шесть" — строка), то все просто.
А если надо проверять что-то более сложное? Если проверка включает в себя запрос к субд? Который при большом везении может быть выполнен в течение 5-10 сек?
Если надо разрешить ввести "стопятнядцать" и привести это к виду "115", если ввод "10" корректен, а "110" опечатка? Причем диапазон нечеткий и задается потоком данных (скажем какие-то измерения, которые должны лечь с определенной погреностью на некую кривую)?
С одной стороны надо стремиться минимизировать количество действий пользователя, не связанных непосредственно с вводом данных, а с другой стороны нельзя допустить попадания "шума" в БД.
Кстати, не рассмотрен 3-й вариант, данные принимаются в любом случае, проверка производится асинхронно, то, что можно исправить автоматически — исправляем (например "1 0" на "10" или "–10" на "-10"), то, что требует корректироваки пользователем, просим его поправить в специальной форме АРМа.
в десктопном приложении я бы крутилку (spinner) поставила. она же сразу отменяет возможность ввода не-чисел. кроме того, она позволяет вводить число как с клавиатуры, так и с помощью мыши. еще один плюс - с ее помощью вы сможете ограничить диапазон значений, если он у вас есть.
если же покаким-то политическим причинам ее использовать нельзя, то на мой взгляд лучше первый из предложенных вариант, т.к. он явно позволяет заполнить форму за меньшее, чем второй, время, поскольку указывает на ошибку в тот момент, когда мысли и фокус пользователя сосредоточены именно на этом поле.
если же покаким-то политическим причинам ее использовать нельзя, то на мой взгляд лучше первый из предложенных вариант, т.к. он явно позволяет заполнить форму за меньшее, чем второй, время, поскольку указывает на ошибку в тот момент, когда мысли и фокус пользователя сосредоточены именно на этом поле.
1й вариант конечно удобней для пользователя. Мне, например, нравится как это сделано в Windows XP (кажется) при вводе пароля - если при вводе нажат Caps Lock то висит балун (всплывающая подсказка) с предупреждением, но вводить по-прежнему допускается. Балун еще хорош тем, что дизайн формы не надо искажать так, чтобы можно было куда втиснуть эти сообщения об ошибках.
Но проверка после каждого нажатия действительно может тормозить. Что если проверка будет заключаться не в том введено ли число/не число, а существует ли такое значение в каком-то справочнике в БД?
Так что многое зависит от задачи. Плохо только, что пользователь к хорошему быстро привыкает и потом будет просить такие феньки везде, так что единообразие также очень важно.
Но проверка после каждого нажатия действительно может тормозить. Что если проверка будет заключаться не в том введено ли число/не число, а существует ли такое значение в каком-то справочнике в БД?
Так что многое зависит от задачи. Плохо только, что пользователь к хорошему быстро привыкает и потом будет просить такие феньки везде, так что единообразие также очень важно.
А ЕСЛИ КАПСЛОК ЭТО НОРМАЛЬНЫЙ СПОСОБ ВВОДА ДЛЯ ЭТОГО ПОЛЬЗОВАТЕЛЯ?
Извините, но пытаться играть в телепатию и угадайку это самый бестолковый пример, который можно было бы привести. А я капслок специально включил, что бы ввести пароль :) А мне тут балонами какими-то грозят.
Извините, но пытаться играть в телепатию и угадайку это самый бестолковый пример, который можно было бы привести. А я капслок специально включил, что бы ввести пароль :) А мне тут балонами какими-то грозят.
1. Это всего лишь пример того КАК можно отобразить сообщение, а не ПОЧЕМУ оно там появляется.
2. Конкретно в примере с паролем в 99,9 случаях из 100 предупреждение будет в точку, и даже если капс лок включен специально чтобы ввести пароль оно не помешает (может даже поможет как индикация). Вот если бы программа за вас принудительно его выключала или уменьшала регистр букв - это уже плохо.
2. Конкретно в примере с паролем в 99,9 случаях из 100 предупреждение будет в точку, и даже если капс лок включен специально чтобы ввести пароль оно не помешает (может даже поможет как индикация). Вот если бы программа за вас принудительно его выключала или уменьшала регистр букв - это уже плохо.
UFO just landed and posted this here
ого! Кнопка и тексбокс - раздули проблему. А что будем делать когда добавиться еще пара компонент?
Для web-приложения лучше 2-ой вариант, для локального — первый.
Но в целом мне лично симпатичнее первый вариант, по крайней мере стараемся внядрять именно такой подход в формах: автозаполнения, проверки заполнености на лету, проверки соответствия типа данных, количество заполненных данных и т.п.
Но в целом мне лично симпатичнее первый вариант, по крайней мере стараемся внядрять именно такой подход в формах: автозаполнения, проверки заполнености на лету, проверки соответствия типа данных, количество заполненных данных и т.п.
Не согласен с semo, по поводу кнопки.
Если проверять правильность ввода в процессе набирания (или как правильно заметили Copy/Paste) то кнопочку надо спрятать до появления нужного значения в поле.
Вводим: 1 (кнопка появляется) 1в (кнопка исчезает)
"Введите число" надо написать крупнее, чтобы бросалось в глаза.
Кстати, не стоит забывать о том, что любят люди нажимать кнопку Enter для продолжения.
Если все-таки кнопку показывать, то не пугайте пользователя.
"Введите число" пусть остается черным.
Можно моргнуть рамочкой ввода для привлечения внимания и выделить красным то, что неверно набрали (т.е. текст или знаки препинания).
Восклицательный знак уместен будет, когда таких полей ввода несколько на одном экране, чтобы дополнитьельно указать на строки с ошибками.
Если проверять правильность ввода в процессе набирания (или как правильно заметили Copy/Paste) то кнопочку надо спрятать до появления нужного значения в поле.
Вводим: 1 (кнопка появляется) 1в (кнопка исчезает)
"Введите число" надо написать крупнее, чтобы бросалось в глаза.
Кстати, не стоит забывать о том, что любят люди нажимать кнопку Enter для продолжения.
Если все-таки кнопку показывать, то не пугайте пользователя.
"Введите число" пусть остается черным.
Можно моргнуть рамочкой ввода для привлечения внимания и выделить красным то, что неверно набрали (т.е. текст или знаки препинания).
Восклицательный знак уместен будет, когда таких полей ввода несколько на одном экране, чтобы дополнитьельно указать на строки с ошибками.
а чем мотивирован выбор "числа" в примере?
Если проверять правильность набора во время набора по символьно, то как такового толка от твоей защиты нету. Символов все же не так много, и подобрать код не составит труда.
Лучше проверять налету после набора последнего символа.
Какую задачу решаем?
1) Минимизировать число ошибок со стороны пользователя
2) Сделать выполнение операции максимально простым и удобным
Что делаем?
1) Даём образец ввода - "введите число, например, 621"
2) Не принимаем в форму ничего, кроме цифр.
Это один из важнейших принципов - если система знает, что именно подлежит вводу в неё, то зачем ей прикидываться дурой, позволять вводить что попало, попутно ругая пользователя?
А так - первый вариант.
1) Минимизировать число ошибок со стороны пользователя
2) Сделать выполнение операции максимально простым и удобным
Что делаем?
1) Даём образец ввода - "введите число, например, 621"
2) Не принимаем в форму ничего, кроме цифр.
Это один из важнейших принципов - если система знает, что именно подлежит вводу в неё, то зачем ей прикидываться дурой, позволять вводить что попало, попутно ругая пользователя?
А так - первый вариант.
UFO just landed and posted this here
первый вариант, однозначно
На мой взгляд первый вариант лучше, можно его дополнить написав после "Введите число" (например, 546) для особо одарённых :)
Оба варианта плохи для десктопного приложения (думаю для интернет аналогично, просто веб сервисами занимаюсь недавно, а десктопными приложениями дольше).
Пользователь никогда, слышите, НИКОГДА не совершает ошибок! Ошибки совершает разработчик. Нельзя писать никаких сообщений об ошибке пользователя или других информативных сообщений, что пользователь делает что-то не так. Аналогично нельзя обрезать функциональность - отрезать возможность ввода букв.
Пользователь, как любой клиент, всегда прав. Он НИКОГДА не ошибается.
Исходя из той концепции что вы предложили, больше половины юзеров будут думать, что программа глючная, даже если она работает like a Swiss watch.
Здесь оптимальный вариант - спинер - он не даст вводить буквы, его можно плавно перемещать мышью, а не клавиатурой. Часть пользователей предпочитает делать мышью большинство действий. И не забудьте про дефолтное значение. Оно нужно.
Ещё я надеюсь в визарде на этом шаге не только ввод этого числа? Визард нужно использовать только в крайнем случае - в слишком сложной программе. Мало кто любит лишние шаги.
Вообще вы бы поподробнее расписали - что должна делать программа. Тогда можно посоветовать что-то более конкретное.
Пользователь никогда, слышите, НИКОГДА не совершает ошибок! Ошибки совершает разработчик. Нельзя писать никаких сообщений об ошибке пользователя или других информативных сообщений, что пользователь делает что-то не так. Аналогично нельзя обрезать функциональность - отрезать возможность ввода букв.
Пользователь, как любой клиент, всегда прав. Он НИКОГДА не ошибается.
Исходя из той концепции что вы предложили, больше половины юзеров будут думать, что программа глючная, даже если она работает like a Swiss watch.
Здесь оптимальный вариант - спинер - он не даст вводить буквы, его можно плавно перемещать мышью, а не клавиатурой. Часть пользователей предпочитает делать мышью большинство действий. И не забудьте про дефолтное значение. Оно нужно.
Ещё я надеюсь в визарде на этом шаге не только ввод этого числа? Визард нужно использовать только в крайнем случае - в слишком сложной программе. Мало кто любит лишние шаги.
Вообще вы бы поподробнее расписали - что должна делать программа. Тогда можно посоветовать что-то более конкретное.
В реальных формах валидация инпута намного сложнее. В некоторых случаях требуется объяснить пользователю почему ввод неверный, например если в поле никнейма введены символы !"·$%&/($, тогда можно показать сообщение о допустимых символах в этом поле.
- "Введите число".
Ну допустим...
И какое число вводить-то? Вообще, что это за число?
Может проще указать комментарием формат для ввода, пример или диапазон?
Лично мне не нравится ни один из ваших вариантов!
В первом: потому что я должен буду гадать, что за число я должен ввести, чтобы кнопка стала активной.
Во втором: я буду нервничать, когда по кнопке Вперед система высветит тупой значок и оставит меня наедине с формой без каких-то подсказок.
Ну допустим...
И какое число вводить-то? Вообще, что это за число?
Может проще указать комментарием формат для ввода, пример или диапазон?
Лично мне не нравится ни один из ваших вариантов!
В первом: потому что я должен буду гадать, что за число я должен ввести, чтобы кнопка стала активной.
Во втором: я буду нервничать, когда по кнопке Вперед система высветит тупой значок и оставит меня наедине с формой без каких-то подсказок.
первый вариант удобнее. меньше лишних движений
Sign up to leave a comment.
Задачка по юзабилити: Обработка формы в десктопном приложении