Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 200
О юзабилити все верно,
кстати должен вам сказать что вашей идеей пользуются ВСЕ сайты специализирующиеся на бронирование отелей.
Я бы этого так не оставил...
кстати должен вам сказать что вашей идеей пользуются ВСЕ сайты специализирующиеся на бронирование отелей.
Я бы этого так не оставил...
обзор хорош, но у меня возникло сразу несколько вопросов:
1) а если я хочу указать только месяц и день? такое часто бывает - и было бы глупо запрещать..
2) а если речь пойдет не только о годах рождения? список годов будет все так же катастрофически велик :(
1) а если я хочу указать только месяц и день? такое часто бывает - и было бы глупо запрещать..
2) а если речь пойдет не только о годах рождения? список годов будет все так же катастрофически велик :(
По первому вопросу. Автор со мной согласится, что поле для ввода дня будет доступно только после выбора месяца, но ни как не года и тогда ни каких проблем, год можно и не ставить при этом и в феврале не будет 31 дня.
На ближайшие ~ 392 года это верно :) но в 2400 в феврале будет 28 дней - и этого не отследить, заблокировав только месяц и оставив свободным год. Так что идея блокировки дней годами и месяцами вместе - вполне приемлема.
Жжом помаленьку:
А на самом-то деле лучшая форма для ввода даты та, что была дана в самом начале статьи:
Введите дату:[__________] (текстовое поле)
Во-первых, никуда не надо ничем тыкать, форма не должна быть расчитана на мышь.
Во-вторых, пользователь может ввести дату как ему хочется:
1 марта 2008
Март 1 2008
2008-03-01
1/3/2008
01.03.08
1-е марта 2008 г.
и прочие вариации на тему. Обработчик ввода должен не ленится и разобрать это, благо во вменяемых средах (perl, ruby и т.д.) это делается в одно движение наподобие Time::ParseDate. В третьих, это избавляет от громоздкого кода на клиентской стороне, и сильно упрощает логику (ввод в три приёма это же ужос).
Единственная недоднозначность, которая может возникнуть, если кто-то решит, что он американец, и нужно вводить месяц-день-год, тогда 3/1/2008 будет неверно, но если форма по-русски, вероятность такого ноль.
Ну и ещё нужно смотреть на варианты типа 01.03.08, и при обнаружении неоднозначности такого рода форму не принимать. И только если дату не удалось ввести сразу верно (3% оригиналов), то выводить подсказку, помогающее заблудшему с форматом:
Введите дату (ДД-ММ-ГГГГ):[__________]
Этим мы убиваем двух собак: дать без ограничений ввести дату нормальным людям, которые её вводят однозначно, и заставить всё же её ввести ненормальных со второй попытки.
Интерфейс должен быть удобен большинству. Из-за немногочисленных альтернативно одарённых так усложнять жизнь нельзя.
Кто вводил месяц числом, а кто и цифрой.
А на самом-то деле лучшая форма для ввода даты та, что была дана в самом начале статьи:
Введите дату:[__________] (текстовое поле)
Во-первых, никуда не надо ничем тыкать, форма не должна быть расчитана на мышь.
Во-вторых, пользователь может ввести дату как ему хочется:
1 марта 2008
Март 1 2008
2008-03-01
1/3/2008
01.03.08
1-е марта 2008 г.
и прочие вариации на тему. Обработчик ввода должен не ленится и разобрать это, благо во вменяемых средах (perl, ruby и т.д.) это делается в одно движение наподобие Time::ParseDate. В третьих, это избавляет от громоздкого кода на клиентской стороне, и сильно упрощает логику (ввод в три приёма это же ужос).
Единственная недоднозначность, которая может возникнуть, если кто-то решит, что он американец, и нужно вводить месяц-день-год, тогда 3/1/2008 будет неверно, но если форма по-русски, вероятность такого ноль.
Ну и ещё нужно смотреть на варианты типа 01.03.08, и при обнаружении неоднозначности такого рода форму не принимать. И только если дату не удалось ввести сразу верно (3% оригиналов), то выводить подсказку, помогающее заблудшему с форматом:
Введите дату (ДД-ММ-ГГГГ):[__________]
Этим мы убиваем двух собак: дать без ограничений ввести дату нормальным людям, которые её вводят однозначно, и заставить всё же её ввести ненормальных со второй попытки.
Интерфейс должен быть удобен большинству. Из-за немногочисленных альтернативно одарённых так усложнять жизнь нельзя.
Для ввода даты рождения такая форма действительно вполне подойдет.
Но индустрия бронирования (отели, билеты, экскурсии) очень сильно завязана на день недели. И вот там как раз предложенный автором статьи метод просто обязан применяться. С добавной подсветки выходных и общегосударственных праздников в идеале.
Но индустрия бронирования (отели, билеты, экскурсии) очень сильно завязана на день недели. И вот там как раз предложенный автором статьи метод просто обязан применяться. С добавной подсветки выходных и общегосударственных праздников в идеале.
Ну а если говорить уже о применении новых технологий, то я считаю, что можно просто добавить такой елемент как autocompleter (использовав такой плагин, как к примеру Autocomplete от jQuery).
При вводе данных, уже введенная строка посылается на сервер. Колбек (callback - серверный скрипт для обработки и посылки данных применяемых в технологии AJAX) обрабатывает данные, определяя формат вводимых данных и сразу предлагает пользователю ввести дату в определенном формате, а если пользователь вводит какой-то месяц, то и закончит ввод месяца.
Метод сокращает лишние действия пользователя и дает сразу правильный результат.
А на худой конец можно использовать предопределенный формат в текстовом поле будет сразу храниться текущее значение даты и при замене пользователем данных в этом поле будут выводиться подсказки с помощью JavaScript о требуемом формате на текущем этапе ввода.
При вводе данных, уже введенная строка посылается на сервер. Колбек (callback - серверный скрипт для обработки и посылки данных применяемых в технологии AJAX) обрабатывает данные, определяя формат вводимых данных и сразу предлагает пользователю ввести дату в определенном формате, а если пользователь вводит какой-то месяц, то и закончит ввод месяца.
Метод сокращает лишние действия пользователя и дает сразу правильный результат.
А на худой конец можно использовать предопределенный формат в текстовом поле будет сразу храниться текущее значение даты и при замене пользователем данных в этом поле будут выводиться подсказки с помощью JavaScript о требуемом формате на текущем этапе ввода.
Во-первых, никуда не надо ничем тыкать, форма не должна быть расчитана на мышь.Переключаться между селекторами Табом не большая примудрость.
согласен, но, ваш вариант забывает про бесклавиатурных пользователях.
Я тоже за единственное поле ввода и нормальный парсинг и валидацию. Вам плюс (правда он останется у меня в уме).
Меня бы такое поле взбесило, так как я привык, что большинство программ понимают только определенный формат. Из-за этого первой мыслью будет: "Какого черта не написали, в каком формате вводить?"
А как распарсится тот же 01.03.08 из Вашего примера? 1 марта или 3 третье января?
Никак, будет дана вторая форма ввода, уже с указанием формата. Если вы не смогли дать непротиворечивую дату в свободной форме, значит свободная форма не для вас. Идея как бы в том, что таких будет мало. Причём тут выбор не между 1-ым марта и 3-им января, а между 1 марта 2008 и 8 марта 2001. Предполагать, что человек может ввести м.д.г через ТОЧКУ мы даже не будем, такому пользователю никакая форма не поможет. Если бы вы сказали 01/03/2008, тогда предположение м/д/г имеет право на жизнь, и также будет предложена повторная форма.
Почему в 2400 будет 28 дней?
Вот уж не сказал бы что год в такой дикой таблице найти проще чем в выпадающем списке, глаза разбегаются.
Нужны, конечно, какие-то секунды на то, чтобы сориентироваться, но основное преимущество скорей в том, что нет дикого скроллинга на 100 лет. Это плюс.
А почему нельзя просто запретить ввод любых символов кроме цифр в текстфилд и на стороне сервере проверять что же ввёл пользователь? Допустим, года, начинающиеся с 19хх и 20хх разрешать, остальные отсекать.
Ну 100 летний разброс это в теории, на самом деле - больша часть все же колеблется между 1970 и 1990, и если начинать годы с 2000 то крутить большинству приходится не так много. Все таки простота здесь является плюсом - сориентироваться в выпадающем списке намного проще (ну во всяком случае для меня).
А я юзаю вот это: http://dali.mty.itesm.mx/~hugo/js/datepickercontrol/ (это лично мой выбор — на самом деле подобных календариков великое множество) и давно уже забыл о трех селектах для выбора даты :)
это накладывает некоторые ограничения. мне к примеру иногда гараздо удобнее вбивать дату с клавиатуры, а не клацая мышкой...
с другой стороны, допустив прямой ввод с клавиатуры мы упираемся вот в это: "Люди заполняли данно поле кто как мог и привык: 12 июля 1980 12-07-1980 07/12/80"
с другой стороны, допустив прямой ввод с клавиатуры мы упираемся вот в это: "Люди заполняли данно поле кто как мог и привык: 12 июля 1980 12-07-1980 07/12/80"
Не работает с високосными годами ( 29/02/2008 )
выбрать далекий год в таких формах очень затруднительно
Да, чтобы выбрать из такого календаря, скажем, 1 января 1960 года, нужно несколько десятков кликов
Как эволюционное продолжение приведенных в качестве примеров вариантов - да, это "оно". Но, как вам кажется, может, лучше использовать старый добрый "Календарь", не мудрствуя лукаво и не разбивая его на компоненты (год, месяц, день)?
Фигня это все, обычное текстовое поле, подпись под ним "В формате чч.мм.гггг, например 29.06.1982", здой говорящий валидатор через аякс.
Если конечно 100% дебилы - не ваша ЦА.
Если конечно 100% дебилы - не ваша ЦА.
Злой говорящий валидатор!!! В-о-о-т )
Пользователь голосом Петросяна:
"Мотороллер не мой, я просто разместил объяву!"
В полу программиста открывается люк, оттуда вылазит монах, бьет программиста в ухо и кричит:
"Мотороллер не его, он просто разместил объяву!"
"Мотороллер не мой, я просто разместил объяву!"
В полу программиста открывается люк, оттуда вылазит монах, бьет программиста в ухо и кричит:
"Мотороллер не его, он просто разместил объяву!"
Пожалуй поясню... На пыхэпэ:
interface Core_Validator
{
````/**
````* @return bool
````*/
````public function isValid();
}
interface Core_Validator_Speaking
{
````/**
````* @return array
````*/
````public function getErrors();
}
final class Model_Validator_Date implements Core_Validator, Core_Validator_Speaking
{
````public function isValid()
````{
`````````if (чото) {
``````````````$this->errors[] = 'Блин, так нельзя';
`````````}
`````````if (чото-еще) {
``````````````$this->errors[] = 'Блин, темболе нельзя';
`````````}
`````````if (чото-ужсовсемплохое) {
``````````````$this->errors[] = 'Блин, так ващенизяникак';
`````````}
````public function getErrors()
````{
````````return $this->errors;
````}
}
interface Core_Validator
{
````/**
````* @return bool
````*/
````public function isValid();
}
interface Core_Validator_Speaking
{
````/**
````* @return array
````*/
````public function getErrors();
}
final class Model_Validator_Date implements Core_Validator, Core_Validator_Speaking
{
````public function isValid()
````{
`````````if (чото) {
``````````````$this->errors[] = 'Блин, так нельзя';
`````````}
`````````if (чото-еще) {
``````````````$this->errors[] = 'Блин, темболе нельзя';
`````````}
`````````if (чото-ужсовсемплохое) {
``````````````$this->errors[] = 'Блин, так ващенизяникак';
`````````}
````public function getErrors()
````{
````````return $this->errors;
````}
}
Согласен!
Проще нажимать цифирьки и пару раз кнопочку Tab, чем 6 раз тыкать мышкой при этом аккуратно целясь, попутно решая нетривиальную когнитивную задачу: куда-же ткнуть...
Проще нажимать цифирьки и пару раз кнопочку Tab, чем 6 раз тыкать мышкой при этом аккуратно целясь, попутно решая нетривиальную когнитивную задачу: куда-же ткнуть...
Если речь идет об удобстве, то самая удобная форма - первая. Пусть пользователь пишет дату как ему удобно, а уж компьютер пусть переводит в нужный формат, на то он и компьютер.
Плюс это позволяет вводить дату копипастом.
разберите дату 12/11/1990
а ведь в разных странах по разному принято указывать порядок месяца и дня. И то ли это 11 декабря толи 12 ноября...
а ведь в разных странах по разному принято указывать порядок месяца и дня. И то ли это 11 декабря толи 12 ноября...
Применительно к России это 12 ноября 1990 года
только при условии что ресурс узконационализирован :)
Если ресурс многонациональный - логичен будет выбор страны :)
Представьте себе, что Вы американец приехавший на работу в Россию (малопредставляемо вообще-то :)) или наоборот, Вы поехали работать в Штаты. Могут возникнуть много непоняток.
Как русский, находящийся сейчас в Штатах, я прекрасно осведомлён об отличиях культур, таких как неметрическая система и обратный порядок дат. Поэтому я всегда обращаю внимание на поля для ввода дат, что вполне разумно. А уж если я обратил внимание, то я прочитаю и подпись, где будет пояснён формат ввода.
Буквально сегодня в разделе отчотов менеджера Пейпала столкнулась с селектом даты где месяц и число в числовом виде и без подписей кто где. В контексте текущего месяца, непонятно что выбирать. 03/01 или 01/03...
Мне кажется, там, где среди вариантов есть число 13, — число.
Согласен. Нужно одно поле, а перед принятием решения как интерпретировать ввод, явно спросить у пользователя в полном формате.
в случае возникновения конфликта можно спрашивать об этом пользователя дополнительно
да и если вводил американец - тут всё однозначно, если россинин - тоже
да и если вводил американец - тут всё однозначно, если россинин - тоже
а ведь в разных странах по разному принято указывать порядок месяца и дня.А я вот тут задумался, нельзя ли по HTTP-заголовкам (мы ведь на вебе, да?) типа Accept-Language судить о локали пользователя и на основании этого суждения трактовать 12/11/1990 как 11 декабря либо 12 ноября...
Все, что может быть корректно автоматизировано, должно быть автоматизировано.
Я, например, ползуюсь ОС с оригинальными языковыми пакетыми. Что Виндовс, что Линукс у меня чисто-английский.
Другое дело проверять IP-адрес пользователя и страну, но это тоже не выход, т.к. человек может быть в другой стороне по работе или каким-то другим делам.
Другое дело проверять IP-адрес пользователя и страну, но это тоже не выход, т.к. человек может быть в другой стороне по работе или каким-то другим делам.
Accept-Language не зависит от языка операционной системы и браузера.
Угу, и многие ли люди добавляют туда что-то?
У нас в конторе какие-то языки, кроме дефолтового, добавлены только у меня (делал многоязыковую поддержку) и у тестера (который это потом проверял). У остальных там только дефолтовый английский.
У нас в конторе какие-то языки, кроме дефолтового, добавлены только у меня (делал многоязыковую поддержку) и у тестера (который это потом проверял). У остальных там только дефолтовый английский.
Взято отсюда.
Содержимое элемента $_SERVER['HTTP_ACCEPT_LANGUAGE'] можно использовать для определения национальной принадлежность посетителей. Однако результаты будут приблизительными, так как многие пользователи используют английские варианты браузеров, которые будут извещать сервер о том, что посетитель предпочитает лишь один язык — английский.
Вот и у меня такая ситуация.
Параллельно вводу выдавать расшифровку вводимой даты. Американец увидит "12 ноября" и исправится.
Да и боты под это удобнее программировать ^_^
Англоцентричное исполнение: http://www.datejs.com/
Оно может и удобнее, но сейчас такая форма будет постоянно меня гипнотизировать.
сегодняшний пользователь хреново знает клавиатуру, но уже хорошо водит мышкой
> Кто вводил месяц числом, а кто и цифрой.
буквами наверное имелось ввиду?
буквами наверное имелось ввиду?
у меня как-то тож сразу глаз не зацепился за десятки (верхняя строка), а первый раз и потом все вис и вис на левом столбце, тем более он выделен серым.
по мне было бы удобней годА (десятки) сделать в левом столбце, т.е. не по столбцам выбирать, а по строкам
1960 1961 1962 1963 ...
1970 1971 1972 1973 ...
1980 1981 1982 1983 ...
по мне было бы удобней годА (десятки) сделать в левом столбце, т.е. не по столбцам выбирать, а по строкам
1960 1961 1962 1963 ...
1970 1971 1972 1973 ...
1980 1981 1982 1983 ...
согласен, и самое главное убрать лишние "19" и "20" из каждой даты
что-то типа:
1900
70 71 72...
80 81 82...
90 91 92...
2000
00 01 02...
что-то типа:
1900
70 71 72...
80 81 82...
90 91 92...
2000
00 01 02...
Не знаю - тут: на вкус и цвет.... если еще чуток порационализировать - потребуется отдельный мануал по выбору даты в таком списке. Тем более, что есть большой класс людей которые очень легко теряются в любых таблицах цифр.
а в вашей... слишком много для юзверя "думать надо".
ИМХО - удобнее ограничение по маске ввода в обычном текстовом поле.
а в вашей... слишком много для юзверя "думать надо".
ИМХО - удобнее ограничение по маске ввода в обычном текстовом поле.
Как автор мог про это забыть? http://marcgrabanski.com/code/ui-datepicker/
Ну и ему подобные юзабилити для пользователя.
Ну и ему подобные юзабилити для пользователя.
На мой взгляд, далеко не самое красивое решение проблемы.
Правда, мне вот именно в таком виде получение даты от юзверов еще ни разу не требовалось, но я бы сделал проще: Поле для ввода с подписью ожидаемого формата, а снизу, например, прописывание нормальным человеческим языком, как была понята дата, вписаная юзвером.
Например мы хотим формат ДД.ММ.ГГ, человек нам вводит 03.03.08, мы ему подписываем для контроля, что мы это поняли как 3 марта 2008 года.
Причем для пущей юзабельности сделать валидатор прям на js, потому как ajax тут нафиг не уперся, в котором предусмотреть основные возможные ошибки (типа запятые или слэши автоматом понимать как разделитель и т.п.)
В случае кривого, непонятного нам ввода, так прямо и пишем, что введена хня и форму сабмитить не давать.
Правда, мне вот именно в таком виде получение даты от юзверов еще ни разу не требовалось, но я бы сделал проще: Поле для ввода с подписью ожидаемого формата, а снизу, например, прописывание нормальным человеческим языком, как была понята дата, вписаная юзвером.
Например мы хотим формат ДД.ММ.ГГ, человек нам вводит 03.03.08, мы ему подписываем для контроля, что мы это поняли как 3 марта 2008 года.
Причем для пущей юзабельности сделать валидатор прям на js, потому как ajax тут нафиг не уперся, в котором предусмотреть основные возможные ошибки (типа запятые или слэши автоматом понимать как разделитель и т.п.)
В случае кривого, непонятного нам ввода, так прямо и пишем, что введена хня и форму сабмитить не давать.
Если упрощать дальше, то после указания года и месяца скрипт может вычислить возможные варианты числа (4-5 вариантов).
Интересное исследование по теме
Лень было регистрироваться, но прочитав пост, понял что обязан приплюсовать
"высокостный год" это что?
год высокой кости?
год высокой кости?
Скорее всего это год рождения (смерти?) Роберта Першинга.
Кстати, а каковы возможные последствия неверного ввода даты?
Если это гостиница/билеты - там, как правило, выбирать надо в текущем, максимум, следующем месяце - для этого вываливать календарик, пожалуй, оптимально.
А если надо спросить для той самой статистики дату рождения - ну введут пять человек из тысячи 12/11 вместо 11/12. И что?
Ещё вариант - после того как пользователь покинул поле ввода даты, рядом рисовать нечто вроде валидатора - писать дату человеческим языком: [01/02/03 ].......1 февраля 2003 года.
Тогда сразу понятно кто что имел в виду и кто как кого понял.
Если это гостиница/билеты - там, как правило, выбирать надо в текущем, максимум, следующем месяце - для этого вываливать календарик, пожалуй, оптимально.
А если надо спросить для той самой статистики дату рождения - ну введут пять человек из тысячи 12/11 вместо 11/12. И что?
Ещё вариант - после того как пользователь покинул поле ввода даты, рядом рисовать нечто вроде валидатора - писать дату человеческим языком: [01/02/03 ].......1 февраля 2003 года.
Тогда сразу понятно кто что имел в виду и кто как кого понял.
я пока сешарп изучал, не заметил встроенный класс, изобрёл свой лисопед, который проверял високосный год, 31ые ноября и прочее щячло одним ifом. И вполне так быстро накатал :)
в особо редких случаях использую чужие "велосипеды"
http://dynamicdrive.com/dynamicindex7/jasoncalendar.htm
удобное API, удобная работа с всевозможными форматами данных и нет проблем с 31 февраля.
http://dynamicdrive.com/dynamicindex7/jasoncalendar.htm
удобное API, удобная работа с всевозможными форматами данных и нет проблем с 31 февраля.
Когда вас спрашивают дату, вы какой число вспоминаете первым? Вы вспомните сначала день, затем месяц, а уж потом год. Почему же надо вводить в обратном порядке?
логичнее наоборот, сперва год, потом месяц, потом день: 2007-12-25
я записываю даты так или "20071225", заодно и сортируется сразу правильно, и искать проще
я записываю даты так или "20071225", заодно и сортируется сразу правильно, и искать проще
это уже не юзабилити, если среднестатистического пользователя выводят из привычных ему норм освоения или ввода информации, он начинает паниковать и может наступить фрустрация
на кого наступить?
хабрачеловек
ostanin
хабрачеловек
ostaninсогласен что для сортировки удобнее год месяц день сам ее использую уже с порядок...
но мы говорим о "среднестатистическом пользователе"
но мы говорим о "среднестатистическом пользователе"
дык - на тебя никто не наступает есс-но.
тот, на кого не планируется наступать - тут писать вообще не будет :)
А я лучше помню - времена года, а по ним месяцы... потом уже года и даты.
тот, на кого не планируется наступать - тут писать вообще не будет :)
А я лучше помню - времена года, а по ним месяцы... потом уже года и даты.
Автор, перед публикацией текста проверяй написанное хотя бы в Word'e. Уйма ошибок!
------------------
Ну вроде проблемм возникать не должно, пользовать по обычаю двигаеться слева направо.
------------------
проблемм -> проблем
двигаеться -> двигается
пользовать -> пользователь
по обычаю -> обычно
Это не говоря уже о пунктуации.
Вообщем, рекомендую изучать не юзабилити, а грамматику и пунктуацию.
------------------
Ну вроде проблемм возникать не должно, пользовать по обычаю двигаеться слева направо.
------------------
проблемм -> проблем
двигаеться -> двигается
пользовать -> пользователь
по обычаю -> обычно
Это не говоря уже о пунктуации.
Вообщем, рекомендую изучать не юзабилити, а грамматику и пунктуацию.
И вы говорите об удобстве? ;))
Самый ужасный вариант ввода - разбиение на 3 поля...
А идеальный - текстовое поле с кнопкой календарика.
Итого:
Дату рождения проще всего ввести с клавиатуры, не шарясь мышкой по экрану, в то время, как ближайшие даты лучше выбирать на календаре. Распознавание даты - задача просто элементарная, надо лишь учитывать американский формат (ММ/ДД/ГГГГ) - либо упомянуть об этом, либо, как очень хорошо уточнили выше, выводить рядом то, как дату понял скрипт.
Об удобстве календаря тоже можно много чего сказать, формат комментария для этого не слишком удобен. Можно например воспользоваться "скроллинговым" календарем (Горбунов, Apple etc) для ближних дат, либо "полноразмерным" календарем (ваш вариант, ext-js etc), в котором каждую часть даты можно выбирать из полного списка.
Далее, разумеется, это все улучшать, например совмещая подходы - календарь со скроллом, в котором клик на год показывает большое табло.
В итоге получаем компактное поле с большими возможностями. Очень хочу в ближайшее время написать подробные разборы различных элементов интерфейса.
Все это, конечно, было имхо, но я надеюсь, что так думаю не я один...
Самый ужасный вариант ввода - разбиение на 3 поля...
А идеальный - текстовое поле с кнопкой календарика.
Итого:
Дату рождения проще всего ввести с клавиатуры, не шарясь мышкой по экрану, в то время, как ближайшие даты лучше выбирать на календаре. Распознавание даты - задача просто элементарная, надо лишь учитывать американский формат (ММ/ДД/ГГГГ) - либо упомянуть об этом, либо, как очень хорошо уточнили выше, выводить рядом то, как дату понял скрипт.
Об удобстве календаря тоже можно много чего сказать, формат комментария для этого не слишком удобен. Можно например воспользоваться "скроллинговым" календарем (Горбунов, Apple etc) для ближних дат, либо "полноразмерным" календарем (ваш вариант, ext-js etc), в котором каждую часть даты можно выбирать из полного списка.
Далее, разумеется, это все улучшать, например совмещая подходы - календарь со скроллом, в котором клик на год показывает большое табло.
В итоге получаем компактное поле с большими возможностями. Очень хочу в ближайшее время написать подробные разборы различных элементов интерфейса.
Все это, конечно, было имхо, но я надеюсь, что так думаю не я один...
Полностью согласен - я в итоге пришел в варианту номер один + кнопка календарика.
Дату пользователь вводит в каком угодно формате сам, а как её распарсить - это уже моя задача.
Единственная загвоздка с американским форматом дат: если кто-то введёт 03/04/2008 - это можно понять двояко, но поскольку моя аудитория исключительно европейская, я принимаю такие строки как европейский формат дат (о чём отдельно сообщаю пользователю).
Дату пользователь вводит в каком угодно формате сам, а как её распарсить - это уже моя задача.
Единственная загвоздка с американским форматом дат: если кто-то введёт 03/04/2008 - это можно понять двояко, но поскольку моя аудитория исключительно европейская, я принимаю такие строки как европейский формат дат (о чём отдельно сообщаю пользователю).
чудесно! не хватает только js-объекта реализующего эту функциональность :)
Поправлю и себя:
Вообщем -> В общем
lol
Вообщем -> В общем
lol
А слабо сначала ввести день и месяц, а потом отобразить года, когда такое возможно? Или даже после ввода дня в списке оставить только возможные месяцы.
Вообще через 15 лет за людей будут вводить даты моллюски, управляемые имплантатами в мозгу. Нужно уже думать над интерфейсами в этом направлении.
Вообще через 15 лет за людей будут вводить даты моллюски, управляемые имплантатами в мозгу. Нужно уже думать над интерфейсами в этом направлении.
а я вот вообще не силён в написании хорошого кода,..
но я думаю, что вообще это должно выгляеть след. оброзом:
просто, ПРОСТО! одно поле(к которому прикручен хитрый ява скрипт)
и в этом поле юзер вводит свою дату, просто нажимая на кнопки цыфирек...
в любом порядке, тоесть, либо в америкоском стандарте (02.17.80), либо в русском (17.02.80)
вот и все!
п.с. мое мнение-мнение абсолютного юзера.
но я думаю, что вообще это должно выгляеть след. оброзом:
просто, ПРОСТО! одно поле(к которому прикручен хитрый ява скрипт)
и в этом поле юзер вводит свою дату, просто нажимая на кнопки цыфирек...
в любом порядке, тоесть, либо в америкоском стандарте (02.17.80), либо в русском (17.02.80)
вот и все!
п.с. мое мнение-мнение абсолютного юзера.
Смысл всей этой кухни не в этом! Ведь пользователь может и с защитой от "дурака-юзера"...поставить то, что он захочет в пределах возможного, и в итоге сайт опять не получает достоверных данных. Пользователь должен быть замотивирован на это, только тогда он внесет настоящие данные о себе, причем в любую по сложности форму.
Здесь речь об удобстве ввода, а не о достоверности данных.
сайт никогда не получит достоверных данных!
если мне щас 28, что мне мешает поставить 25, 27 или 33???
помему тут речь не о достоверности, всетаки, а о ЮЗАбИЛИТИ...
если мне щас 28, что мне мешает поставить 25, 27 или 33???
помему тут речь не о достоверности, всетаки, а о ЮЗАбИЛИТИ...
С точки зрения юзабилити будет правильнее разместить годы так:
2000 1990 1980
2001 1991 1981
2002 1992 1982
... ... ...
Потому что большинство вводимых дат в районе 1970 - 2000, и пользователю не придется вести курсор в конец таблицы, как в авторском варианте.
2000 1990 1980
2001 1991 1981
2002 1992 1982
... ... ...
Потому что большинство вводимых дат в районе 1970 - 2000, и пользователю не придется вести курсор в конец таблицы, как в авторском варианте.
А если бы с точки зрения посещаемости *вашего* сайта: большинство было бы 18-25 лет, затем 11-18, а затем 25-60 вы бы так и проранжировали (с точки зрения "юзабилити" интересует)?
Ну конечно же нет :)
Оптимизируя разметку для уменьшения расстояний и числа кликов, необходимых для достижения цели, не следует забывать и о логике.
Но если бы количество пользователей из одной категории значительно превышало всех вместе взятых из других(>95%), я бы рискнул поставить эту категорию уже выбраной по умолчанию.
Оптимизируя разметку для уменьшения расстояний и числа кликов, необходимых для достижения цели, не следует забывать и о логике.
Но если бы количество пользователей из одной категории значительно превышало всех вместе взятых из других(>95%), я бы рискнул поставить эту категорию уже выбраной по умолчанию.
Точно, обычно логичный интерфейс и бывает удобным. А в вашем примере нужно читать как литературный японский - сверху вниз плюс справа налево, но европейский глаз обычно будет искать 1980 слева от 1981 (а не выше).
Если честно, то я не знаю какой вариант будет быстрее:
в авторском интерфейсе необходимо взглядом пробежать ~8 четырехзначный цифр, прежде чем пользователь найдет 'свой' ряд.
В случае с 'японским' порядком - 3 наиболее часто выбираемые даты находятся сразу под полем 'выберите год', т.е. глазу никуда бежать не надо - все цифры перед ним, полжзователь даже удивиться не успеет :)
в авторском интерфейсе необходимо взглядом пробежать ~8 четырехзначный цифр, прежде чем пользователь найдет 'свой' ряд.
В случае с 'японским' порядком - 3 наиболее часто выбираемые даты находятся сразу под полем 'выберите год', т.е. глазу никуда бежать не надо - все цифры перед ним, полжзователь даже удивиться не успеет :)
>я не знаю какой вариант будет быстрее
По-моему быстрее будет привычный глазу порядок. Ну хотя бы вот так (намеренно снизу вверх):
2000 2001 2002 2003 ...
1990 1991 1992 1993 ...
1980 1981 1982 1983 ...
Имхо это как раз тот случай когда эргономичность (минимизация времени, расстояний) отличается от юзабилити (понятность, логичность). Быть может если нужно было бы выбирать 100 дат, было бы разумнее сделать эргономичным, но в выборе даты рождения время на нахождение закономерности (и целесообразности, мол почему вдруг все наоборот?) не окупится.
По-моему быстрее будет привычный глазу порядок. Ну хотя бы вот так (намеренно снизу вверх):
2000 2001 2002 2003 ...
1990 1991 1992 1993 ...
1980 1981 1982 1983 ...
Имхо это как раз тот случай когда эргономичность (минимизация времени, расстояний) отличается от юзабилити (понятность, логичность). Быть может если нужно было бы выбирать 100 дат, было бы разумнее сделать эргономичным, но в выборе даты рождения время на нахождение закономерности (и целесообразности, мол почему вдруг все наоборот?) не окупится.
Ну вот, оказывается вы уже раньше меня это написали) Мне приведённый вами сейчас вариант кажется именно что наиболее понятным и логичным. Последние годы должны быть в начале. Точка отсчёта десятков, локальный ноль - двухтысячный, а непонятный девятисотый.
Но тут мне интересно, почему вариант строчного расположения показался вам более удобным, чем столбцами?
Но тут мне интересно, почему вариант строчного расположения показался вам более удобным, чем столбцами?
Представьте (не смотря в таблицу) что первый ваш взгляд упал на, скажем, 1965 и подумайте в каком порядке вы бы искали предыдущий ему год - слева, справа, выше, ниже? И потом то же, но с десятилетиями. Это те два направления закономерность которых и нужно отыскать чтобы (далее незадумываясь) найти свой год. В идеале у большинства пользователей должно быть минимум ошибочных (глазо-)движений, т.е. идем ладьей на нужную клетку за два хода.
А может то, что такой формат:
2000 1990 1980 ...
2001 1991 1981 ...
2002 1992 1982 ...
больше похож на обычные выпадающие списки(по годам от десятков), то он более легче будет восприниматься?
2000 1990 1980 ...
2001 1991 1981 ...
2002 1992 1982 ...
больше похож на обычные выпадающие списки(по годам от десятков), то он более легче будет восприниматься?
Есть такая штука — <input type="date">
Правда, работает пока только в Опере ;)
Правда, работает пока только в Опере ;)
Не плохо, я был бы очень рад, если бы многие сайты ввели такое новшество, а то действительно стандартные филды страх как неудобны и очень надоели.
в идеале было бы так:
Edit сверху синхронизировать с календариком снизу
Или выберите из списка:
Edit сверху синхронизировать с календариком снизу
Интересно было почитать. Я сам использую поле для ввода и кнопку для календарика.
Думаю в этой статье не хватает сопоставления различных видов (динамических)форм с сайтами различной тематики. В смысле где было бы удобнее так, а где эдак.
Думаю в этой статье не хватает сопоставления различных видов (динамических)форм с сайтами различной тематики. В смысле где было бы удобнее так, а где эдак.
Можно еще оставить одно поле для ввода возраста, и по нему считать год, а список месяцев и дней выводить в зависимости от этого значения (возраста). Т.е. после ввода двузначного числа скрипт выдает два выпадающих списка, с месяцами и днями, причем только с теми, которые попадают в неопределившийся промежуток. Например сейчас март и мне 19 лет - год считается автоматом 1988, и выдается список месяцев март-декабрь, и список дней. К томуже если человек родился в декабре и регистрируется в этом же месяце, то останется выбрать только день. Хотя последнее все же частность, но здоровый список с годами нам уже ненужен в любом случае.
autocomplete выкинут за борт :)
Когда создавал новую версию моего проекта по поиску собак, тоже не раз задавался вопросом, как упростить жизнь пользователю... И ответ пришел сам:
Пользователи не должны задумываться о том, как правильно вводится дата, чтобы наша систем а её распознала.
Пользователи не должны задумываться о том, как правильно вводится дата, чтобы наша систем а её распознала.
Мрачнее всего выглядит перспектива писать два варианта кода - для тех, у кого включен яваскрипт и для тех кто прикола ради его отключил.
Вот это кстати проблема на сегодняшний день имхо не актуальна. Поскольку множество проектов сейчас активно юзают JS, в частности аякс. Поэтому если пользователь хочет юзабилити, пусть держит включеным. Ну а по поводу безопасности... смотрите что кушаете, и все будет хорошо + аверы мониторят странички.
Progressive enhancement с самого начала — и париться о проблемах не надо будет. :)
Преамбула: bash.org.ru, wordstream. »Социально активный сайт«, между прочим. Видим на нем массу идиЁтов, коих фильтровать стоит по году рождения до 1985 включительно, и некоторое количество вопросов »кисакуку ASL?«
Сейчас в своей песочнице леплю что-то вроде этого:
Идея в том, что некоторая критическая дата (скажем, допуск только лицам двадцатилетней степени разложения) каждый раз отображается новая, в зависимости от года за окном. И в БД сохраняется однажды.. обеспечивая проверку уровня допуска. Набегают орки, рисуют предупреждения, гоняют малолеток — если пользователю явно меньше 13 лет, то согласиться с утверждений количеством диких придется ему, на свой страх и риск.
Поскольку всех данных нам, в общем-то, и не надо (а кое-что дублируется сервисами проекта) — хватает отображения общих. Если человек захочет ввести личные данные — от лишнего клика по тексту не обеднеет (иначе »ахтунг, быдлокун«). А по клику можно хоть десять скрытых div'ов|слоев вывести, хоть для указания времени рождения в Unix time-формате, ня.
Да, за копипаст зодиакального круга с DreamsTime'а попрошу не бить.
Сейчас в своей песочнице леплю что-то вроде этого:
Идея в том, что некоторая критическая дата (скажем, допуск только лицам двадцатилетней степени разложения) каждый раз отображается новая, в зависимости от года за окном. И в БД сохраняется однажды.. обеспечивая проверку уровня допуска. Набегают орки, рисуют предупреждения, гоняют малолеток — если пользователю явно меньше 13 лет, то согласиться с утверждений количеством диких придется ему, на свой страх и риск.
Поскольку всех данных нам, в общем-то, и не надо (а кое-что дублируется сервисами проекта) — хватает отображения общих. Если человек захочет ввести личные данные — от лишнего клика по тексту не обеднеет (иначе »ахтунг, быдлокун«). А по клику можно хоть десять скрытых div'ов|слоев вывести, хоть для указания времени рождения в Unix time-формате, ня.
Да, за копипаст зодиакального круга с DreamsTime'а попрошу не бить.
Соответственно, на «национальных проектах» не возбраняется проводить первый этап выбора по типу выдачи документа, удостоверяющего личность. От тугаментов царских времен (знаем, знаем, сам при регистрации 1901 год ставлю) до новеньких биометрических паспортов.
Двенадцать знаков зодиака это рунично, но абсолютная проверка допуска еще не значит признак отсечения малолеток, например. Любой случайный клик и баланс нарушается, делая напрасным целесообразность любой био- и психометрии.
Мне, например, такой вариант удобнее:
http://www.therandom.org.ua/files/dateform.png
Последний формат даты можно подгружать, учитывая региональные стандарты отображения даты пользователя (страну, например, по IP можно предположить).
http://www.therandom.org.ua/files/dateform.png
Последний формат даты можно подгружать, учитывая региональные стандарты отображения даты пользователя (страну, например, по IP можно предположить).
А где пунктик [x] ничего из вышеперечисленного? :)
ЗЫ. Если серьезно, то дату с любым разделителем и любым данным написанием может разобрать сам скрипт (не нагружая человека), если только не учитывать (а у вас это тоже не берется в расчет) что 12/02 кто-то прочтет как 12 декабря, а американец как 2 декабря.
Согласен с тем, что парсер даты со строки можно написать либо найти готовый.
Но с моей точки зрения на юзабилити (она сугубо субъективна и не претендует на абсолютную истину) пользователю необходимо(!) дать возможность принимать решение — что и в каком формате передавать "незнакомым людям". Даже не смотря на то, что после ввода парсер все-таки перепроверит и в случае нестыковки переформатирует дату.
Но с моей точки зрения на юзабилити (она сугубо субъективна и не претендует на абсолютную истину) пользователю необходимо(!) дать возможность принимать решение — что и в каком формате передавать "незнакомым людям". Даже не смотря на то, что после ввода парсер все-таки перепроверит и в случае нестыковки переформатирует дату.
Очень бесполезно и неудобно.
Возможно, оффтоп, но:
Проблемма - *проблема
Естесвенно - *Естественно
данно - *данное (в контексте)
побарабану - *по барабану
програмисты - *программисты
следующие - *следующее (в контексте)
Вродебы - *Вроде бы
вбивалься - *вбивался
избешать - *избежать
Не всё, не усну - дополню
Проблемма - *проблема
Естесвенно - *Естественно
данно - *данное (в контексте)
побарабану - *по барабану
програмисты - *программисты
следующие - *следующее (в контексте)
Вродебы - *Вроде бы
вбивалься - *вбивался
избешать - *избежать
Не всё, не усну - дополню
слежущее - *следущее
неисключают - *не исключают
высокостный - *високосный
ахренел - *охренел (приставки "а" не существует)
Стилистику, и, пунктуацию? дажетрогать небуду.
неисключают - *не исключают
высокостный - *високосный
ахренел - *охренел (приставки "а" не существует)
Стилистику, и, пунктуацию? дажетрогать небуду.
Блин, ну это уже надоедать начинает. Напишите автору сообщение и не захламляйте топик. Вот как ни гляну на какой-нибудь пост — всегда прибежит три-четыре борца за грамотность и будет тыкать в ошибки, вместо того, чтобы обсуждать собственно тему поста.
следущее - *следующее
Хватит флудить... соц.сеть филологов находится по адресу disneyland.com - разбираем "Введите хуй...бр... с утра опять перепутал... дату :)
Спасибо Вам! Люди, позволяющие себе писать неграмотно, небрежно относятся и к содержанию (как правило).
Предлагаю вариант Висту.
Там намного удобнее.
Там намного удобнее.
Не знаю, пожалуй что это от пользователя зависит, но мне таблица лет была бы удобнее построчной, а не столбцами, и снизу вверх десятки, слева направо единицы.
2000 01 02 ..
1990 91 92 ..
Это наверняка depends, и говорю я с позиции пользователя, а никак не юзабелиста:), так что на всякий случай объяснюсь. Отсчёт прошедших лет мне представляется задом наперёд, т.е. десятки удобнее воспринимать, начиная с последнего. Но, поскольку десятки служат отправной точкой, после отлова её нужный год проще выбрать уже просто цифрой (без обратного отсчёта).
Ну а строчки vs столбцы мотивировать не могу, они уж, наверное, точно кому как.
2000 01 02 ..
1990 91 92 ..
Это наверняка depends, и говорю я с позиции пользователя, а никак не юзабелиста:), так что на всякий случай объяснюсь. Отсчёт прошедших лет мне представляется задом наперёд, т.е. десятки удобнее воспринимать, начиная с последнего. Но, поскольку десятки служат отправной точкой, после отлова её нужный год проще выбрать уже просто цифрой (без обратного отсчёта).
Ну а строчки vs столбцы мотивировать не могу, они уж, наверное, точно кому как.
Щас будем исправлять ошиПки.
помоему уже давно есть созданные модули, которые позволяют выбрать дату в календаре. Весьма удобно и практично... Нового ничего не открылось
в HTML 5, может стоит подумать над использованием этого инструмента ?
сорри, в исправление предыдущего коммента:
в HTML 5 есть type date для input. может стоит подумать приспособить его ?
снизу ссылка на скрин работы тэга.
http://img84.imageshack.us/my.php?image=clipboardqt6.jpg
в HTML 5 есть type date для input. может стоит подумать приспособить его ?
снизу ссылка на скрин работы тэга.
http://img84.imageshack.us/my.php?image=clipboardqt6.jpg
а по-моему достаточно удобно выбирать дату в календарике сразу. В таком какой есть в том же Windows XP, когда необходимо поменять дату.. ;)
Хотя пользователю как таковому всегда быстрее и удобнее впечатать день, месяц и год с клавиатуры, потому что это быстрее ))
я бы как пользователь предпочла этот вариант. Другое дело, что действительно ошибок будет масса
Хотя пользователю как таковому всегда быстрее и удобнее впечатать день, месяц и год с клавиатуры, потому что это быстрее ))
я бы как пользователь предпочла этот вариант. Другое дело, что действительно ошибок будет масса
Господа, просто нужно свои юпитерские щупальца, которыми пишутся интерфейсы интерпретировать под пять пальцев на каждой руке землянина, тогда все проблемы - не проблемы.
PS
Лучший вариант - интуитивно понятный для любого имбицила, то есть первый.
PS
Лучший вариант - интуитивно понятный для любого имбицила, то есть первый.
Я когда-то мыслил похожим с автором поста образом, и перепробовал кучу всяких вариантов, в том числе и этот. На самом деле ввод происходит построчно — пользователь видит сначала первую строку, потом, после клика, первую и вторую, и т.п.
Однако, после зрелых размышлений, я эту штуку убрал подальше, и сделал обычные списки — может длинный скролл кого-то и смущает, зато однозначно и всем понятно.
Однако, после зрелых размышлений, я эту штуку убрал подальше, и сделал обычные списки — может длинный скролл кого-то и смущает, зато однозначно и всем понятно.
Кстати, если не трудно, вы не могли бы показать, как это смотрится у вас? Судя по комментарию контраст явно недостаточен, хотя по задумке «невидимые» надписи достаточно хорошо различимы.
Митя, точно так же тупил секунд 10, прежде чем вник, что это за матрица там :)
Гм... Необычное решение.
По крайней мере нестандартное и смелое.
Но разобраться точно трудно.
По крайней мере нестандартное и смелое.
Но разобраться точно трудно.
И всё это не будет работать без JavaScript. ;)
а я посмею согласится с beeos. Мне нравится такой подход. Отличное решение для стандартной процедуры. Шрифты? Серый фон? Да это всё меняется на раз, тут уж, дело личного вкуса, я считаю, ну или вкуса заказчика, как хотите. Разобрался вообще сходу. Так что респект за идейку.
Ваш вариант выбора года просто ужас, имхо.
Почему не использовать выбиралку даты в виде обычного и привычного календаря? (Например как в настраивалке времени в винде или кде) ?
Почему не использовать выбиралку даты в виде обычного и привычного календаря? (Например как в настраивалке времени в винде или кде) ?
у меня есть некие размышления о стандартизации инета.. глобально.. в связи с этим:
например, в опере есть фича, которая по одному нажатию заполняет все поля - от имени и фамилии до почтового индекса. Один раз туда забил данные - рассовывай по всему инету, не жалко.
я понимаю, что к разработчикам сайтов это отношения не имеет, но всё же..
Если в опере это есть, наверняка существуют плагины и в Огнелис, и в прочие.
Я конечно же отдаю отчёт в том что это некие проблемы.. Но если уж речь об этом..
Ну например.. Ввёл юзер неправильно дату у вас, а вы ему вместе с уведомлением о косяке ссылочку на такой плагин. И помощь, и развитие некое.
Все же пользуются автозаполнением/автовходом на сайты...
А через какое-то время в будущем - на сайте вместо огромного количества форм только разрешение на ввод данных из браузера (с какой-нить возможностью корректировать при желании)
например, в опере есть фича, которая по одному нажатию заполняет все поля - от имени и фамилии до почтового индекса. Один раз туда забил данные - рассовывай по всему инету, не жалко.
я понимаю, что к разработчикам сайтов это отношения не имеет, но всё же..
Если в опере это есть, наверняка существуют плагины и в Огнелис, и в прочие.
Я конечно же отдаю отчёт в том что это некие проблемы.. Но если уж речь об этом..
Ну например.. Ввёл юзер неправильно дату у вас, а вы ему вместе с уведомлением о косяке ссылочку на такой плагин. И помощь, и развитие некое.
Все же пользуются автозаполнением/автовходом на сайты...
А через какое-то время в будущем - на сайте вместо огромного количества форм только разрешение на ввод данных из браузера (с какой-нить возможностью корректировать при желании)
Минималистический вариант - старый добрый <input> + input masking, отображающий требуемый формат даты в этом же поле и "на лету" фильтрующий вводимые данные. Пример - тут (закладка Demo).
вообще думается надо давать возможность выбрать мышкой в красивой такой сраной менюшке, но чтобы было текстовое поле все таки было, желательно даже такое, чтобы табом не скакать. Вспомните поле ввода айпишника в винде. Можно сделать облачко, как для тэгов, где покрупнее выделены года, наиболее часто которые выбирают, либо в которые больше людей родилось )) либо на результат исследования возрастной аудитории сайта.
Вот вы как хотите, а я родился 21 ноября 1986 а не 1986 ноябрь 21, признайте что дико звучит :)
Если человек "дурак" то никто не помешает отправить 31 февраля GET на сервер, а если опечатался, то только поблагодарит если появится подсказочка что такой даты нет и вы вероятно ошиблись.
Если человек "дурак" то никто не помешает отправить 31 февраля GET на сервер, а если опечатался, то только поблагодарит если появится подсказочка что такой даты нет и вы вероятно ошиблись.
Странно, что Якоб Нильсен об этом ещё не писал... ;)
мне конечный вариант не понравился, может быть это логически правильно или очень всё корректно, но как сложно, пользователь ожидая увидеть что-то среди ранее рассмотренных вариантов, к чему он уже привык видит очень громоздкие выпадашки с множеством чисел
Поддерживаю идею с одним текстовым полем. Что знаю - в Django такое поле используется для дат по умолчанию + две очень удобных кнопки, Календарь и Сегодня.
Предлагаю текстовое поле с кнопкой для показа, или просто показывающее при клике что-то вроде предложенных тут выпадающих списков, последовательно. Преимущества:
1. можно ввести вручную
2. 4 клика вместо 6ти
3. поле ввода покороче, и покакуратнее выглядит
4. в выборе года можно один пункт сделать "не указывать" или вроде того
Различные календарики, как по мне, подходят только для дат не сильно далеко отклоняющихся от текущей, дату рождения не удобно вводить
1. можно ввести вручную
2. 4 клика вместо 6ти
3. поле ввода покороче, и покакуратнее выглядит
4. в выборе года можно один пункт сделать "не указывать" или вроде того
Различные календарики, как по мне, подходят только для дат не сильно далеко отклоняющихся от текущей, дату рождения не удобно вводить
Слишком сложно.
Проще проверить дату после введения и сообщить, если ввод неправильный. Большинство введет дату верно, и потратят на ввод меньше времени, чем с вашим решением. У Яндекса хороший вариант.
Проще проверить дату после введения и сообщить, если ввод неправильный. Большинство введет дату верно, и потратят на ввод меньше времени, чем с вашим решением. У Яндекса хороший вариант.
1. а без JS
2. а без привлечения внимания пользователя к освоению "инновационного интерфейса"?
2. а без привлечения внимания пользователя к освоению "инновационного интерфейса"?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Юзабилити на практике: «Введите дату»