войти зарегистрироваться

Эти пользовательские интерфейсы whois

индекс
153,03

Юзабилити на практике: «Введите дату»

Всем снова привет.
Сегодня буду рассказывать о моем любимом — о Юзабилити.

В русском языке есть этому модному слову замена — Удобство. Но когда речь идет об удобстве взаимодействия человека с компьютером, то мы сразу говорим юзабилити.

В этой статье будет рассмотрена всего лишь форма ввода даты, которая нам так часто встречается при регистрации на любом сайте. Чаще всего просят вводить свою дату рождения. Зачем всем на свете админам знать день моего рождения — неизвестно, но будем считать, что для статистики.

Сначала окунемся в историю.

Все самые первые сайты и программы предлагали пользователю вот такое поле:

1.gif

Естественно, сразу возникли проблемы. Люди заполняли данное поле кто как мог и привык:
12 июля 1980
12-07-1980
07/12/80

и так далее...

Поэтому было придумано следующее:

2.gif

Но некоторым было по барабану на это, другие просто не читали, то, что было написано в скобках.
Тогда программисты и придумали разделить поле на три:

3.gif

Вроде бы можно было облегченно вздохнуть. Но пользователи народ тупой и плевать они хотели на эти поля. По этим причинам в поле день вбивался месяц и наоборот. Кто вводил месяц числом, а кто и словом.

Разработчики призадумались и поняли что лучший способ избежать ошибок от тупых пользователей это не дать им возможности допустить их. И изобрели они вот это:
4.gif

В таком виде, данная форма встречается, на большинстве сайтов, и по сей день. И вроде бы все нормально, но есть много НО.

Во-первых, она не исключает всяких там 31 февраля.
во-вторых, само легко выбрать месяц, но вот день, а в особенности год выбирать очень сложная задача. Посудите сами:
5.gif

Нужно долго скролировать, чтобы добраться до нужного года. А мы, ведь, стремимся к идеальности и должны адаптировать интерфейс, как для стариков, так и для младенцев. В связи с этим на многих нынешних сайтах мы видим следующее:

mail.ru
6.gif


Яндекс
71.gif

Всякие форумы
8.gif

ebay
9.gif 

К сожалению, все эти формы на защищены от дурака и не исключают ввода, допустим, такой даты: 31 ноября 3450 года.

Что же мы можем сделать? А сделать можно многое. Мы можем учитывать особенности каждого месяца, а также високосный год или нет.

— Да ты ахренел! — скажут программисты.

Но я скажу, что данный модуль придется сделать один раз и потом в будущем его без проблем прикручивать к любому вашему продукту.

Но в связи с этим порядок заполнения придется поменять: сначала мы будем вводить год и месяц, а потом на основе полученных данных в список День ставить нужное количество деньков. Причем список День будет не доступен для пользователя, пока он не выберет Год и Месяц.
10.gif

11.gif

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

Но проблемы еще есть. Списки Год и День все еще не юзабельны.
Что мы можем предпринять?

Я придумал вот, что:

121.gif

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

Список Месяц, вроде бы, не требует ни каких модернизаций.

А вот День, можно представить в классическом календарном блоке

13.gif

Естественно дни следует выводить на основе, первых двух полей.

На мой взгляд, такая форма ввода даты рождения, позволит избежать заведомо неверных дат и даст пользователю удобный ввод.

Буду рад любым комментариям.
+46
3 марта 2008, 18:07
49
Alexsas

комментарии (200)

  • О юзабилити все верно,
    кстати должен вам сказать что вашей идеей пользуются ВСЕ сайты специализирующиеся на бронирование отелей.
    Я бы этого так не оставил...
    • Мы тут все люди грамотные так что сегодня у нас1204566233
      • есть куча удобных pop-up js-календарей, в который довольно удобно выбирать и год рождения, и дату.
  • обзор хорош, но у меня возникло сразу несколько вопросов:
    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% оригиналов), то выводить подсказку, помогающее заблудшему с форматом:

          Введите дату (ДД-ММ-ГГГГ):[__________]

          Этим мы убиваем двух собак: дать без ограничений ввести дату нормальным людям, которые её вводят однозначно, и заставить всё же её ввести ненормальных со второй попытки.

          Интерфейс должен быть удобен большинству. Из-за немногочисленных альтернативно одарённых так усложнять жизнь нельзя.
          • Для ввода даты рождения такая форма действительно вполне подойдет.
            Но индустрия бронирования (отели, билеты, экскурсии) очень сильно завязана на день недели. И вот там как раз предложенный автором статьи метод просто обязан применяться. С добавной подсветки выходных и общегосударственных праздников в идеале.
          • Ну а если говорить уже о применении новых технологий, то я считаю, что можно просто добавить такой елемент как autocompleter (использовав такой плагин, как к примеру Autocomplete от jQuery).

            При вводе данных, уже введенная строка посылается на сервер. Колбек (callback - серверный скрипт для обработки и посылки данных применяемых в технологии AJAX) обрабатывает данные, определяя формат вводимых данных и сразу предлагает пользователю ввести дату в определенном формате, а если пользователь вводит какой-то месяц, то и закончит ввод месяца.

            Метод сокращает лишние действия пользователя и дает сразу правильный результат.

            А на худой конец можно использовать предопределенный формат в текстовом поле будет сразу храниться текущее значение даты и при замене пользователем данных в этом поле будут выводиться подсказки с помощью JavaScript о требуемом формате на текущем этапе ввода.
            • И кстати первый вариант можно реализовать просто на JavaScript, предложенный вариант можно расценивать просто как "метод в лоб, без затрат энергии".
          • Во-первых, никуда не надо ничем тыкать, форма не должна быть расчитана на мышь.
            Переключаться между селекторами Табом не большая примудрость.
            • Небольшая. А вот со всеми этими выпадающими календарями, сколько я их видел, премудрость несколько большая. Соглашений об интерфейсе нет, а зачастую разработчик и в голову взять не может, как это может быть без мыши.
          • согласен, но, ваш вариант забывает про бесклавиатурных пользователях.
            • Что же делать безклавиатурным пользователям, когда надо ввести имя?
              • Использовать gestures, вестимо :)
          • Я тоже за единственное поле ввода и нормальный парсинг и валидацию. Вам плюс (правда он останется у меня в уме).
          • Меня бы такое поле взбесило, так как я привык, что большинство программ понимают только определенный формат. Из-за этого первой мыслью будет: "Какого черта не написали, в каком формате вводить?"
            • А второй: "Раз так, введу в каком хочу!" :)
          • А как распарсится тот же 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"
    • Не работает с високосными годами ( 29/02/2008 )
    • выбрать далекий год в таких формах очень затруднительно
    • Да, чтобы выбрать из такого календаря, скажем, 1 января 1960 года, нужно несколько десятков кликов
  • Как эволюционное продолжение приведенных в качестве примеров вариантов - да, это "оно". Но, как вам кажется, может, лучше использовать старый добрый "Календарь", не мудрствуя лукаво и не разбивая его на компоненты (год, месяц, день)?
    • см. выше мой комент
      • Это уже вопрос усовершенствования календаря. К примеру, устанавливая различные "точки отсчета" для разных нужд: для даты рождения, к примеру, глупо было бы предлагать текущий год.
        • вот я об этом же... в каледаре на пользователя накидываются сразу три возможности.. и год и месяц и день.. сфокусироваться сразу на всем трудно.. пользователю надо подумать что выбрать первым месяц или же год...

          в моей форме — фокус последователен
  • Фигня это все, обычное текстовое поле, подпись под ним "В формате чч.мм.гггг, например 29.06.1982", здой говорящий валидатор через аякс.

    Если конечно 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;
          ````}
          }
          • ````/**
            ````* @param mixed $value
            ````* @return bool
            ````*
            ````*/
            ````public function isValid($value);
            , если точнее
    • Согласен!
      Проще нажимать цифирьки и пару раз кнопочку Tab, чем 6 раз тыкать мышкой при этом аккуратно целясь, попутно решая нетривиальную когнитивную задачу: куда-же ткнуть...
  • Если речь идет об удобстве, то самая удобная форма - первая. Пусть пользователь пишет дату как ему удобно, а уж компьютер пусть переводит в нужный формат, на то он и компьютер.
    • Плюс это позволяет вводить дату копипастом.
      • разберите дату 12/11/1990
        а ведь в разных странах по разному принято указывать порядок месяца и дня. И то ли это 11 декабря толи 12 ноября...
        • Применительно к России это 12 ноября 1990 года
          • только при условии что ресурс узконационализирован :)
            • Если ресурс многонациональный - логичен будет выбор страны :)
              • Представьте себе, что Вы американец приехавший на работу в Россию (малопредставляемо вообще-то :)) или наоборот, Вы поехали работать в Штаты. Могут возникнуть много непоняток.
                • Как русский, находящийся сейчас в Штатах, я прекрасно осведомлён об отличиях культур, таких как неметрическая система и обратный порядок дат. Поэтому я всегда обращаю внимание на поля для ввода дат, что вполне разумно. А уж если я обратил внимание, то я прочитаю и подпись, где будет пояснён формат ввода.
                  • Это Вы как IT-шник заявляете, а большинство студентов, которые едут в Штаты по обмену врядли будут заморачиваться такими вопросами.
        • Буквально сегодня в разделе отчотов менеджера Пейпала столкнулась с селектом даты где месяц и число в числовом виде и без подписей кто где. В контексте текущего месяца, непонятно что выбирать. 03/01 или 01/03...
          • Мне кажется, там, где среди вариантов есть число 13, — число.
            • Где вы 13 увидели?
              • Дано: два селекта, в обоих числа. В одном нужно выбрать месяц, в другом — число.

                Найти: в каком выбирать число, а в каком — месяц.

                Решение: смотрим, в каком селекте среди вариантов есть число 13. Это число. Другой селект — месяц.
                • А, вот вы о чём. Так речь идёт о разборе именно вручную введённой строки, а не о случае с селектами.
                  • Мне показалось, NatalieG говорила о селектах.
                • Месяц обычно вообще словами указывается, так что даже 13 не надо искать.
        • Согласен. Нужно одно поле, а перед принятием решения как интерпретировать ввод, явно спросить у пользователя в полном формате.
        • в случае возникновения конфликта можно спрашивать об этом пользователя дополнительно

          да и если вводил американец - тут всё однозначно, если россинин - тоже
        • а ведь в разных странах по разному принято указывать порядок месяца и дня.
          А я вот тут задумался, нельзя ли по HTTP-заголовкам (мы ведь на вебе, да?) типа Accept-Language судить о локали пользователя и на основании этого суждения трактовать 12/11/1990 как 11 декабря либо 12 ноября...

          Все, что может быть корректно автоматизировано, должно быть автоматизировано.
          • Я, например, ползуюсь ОС с оригинальными языковыми пакетыми. Что Виндовс, что Линукс у меня чисто-английский.
            Другое дело проверять IP-адрес пользователя и страну, но это тоже не выход, т.к. человек может быть в другой стороне по работе или каким-то другим делам.
            • Accept-Language не зависит от языка операционной системы и браузера.
              • Угу, и многие ли люди добавляют туда что-то?
                У нас в конторе какие-то языки, кроме дефолтового, добавлены только у меня (делал многоязыковую поддержку) и у тестера (который это потом проверял). У остальных там только дефолтовый английский.

              • Взято отсюда.

                Содержимое элемента $_SERVER['HTTP_ACCEPT_LANGUAGE'] можно использовать для определения национальной принадлежность посетителей. Однако результаты будут приблизительными, так как многие пользователи используют английские варианты браузеров, которые будут извещать сервер о том, что посетитель предпочитает лишь один язык — английский.

                Вот и у меня такая ситуация.
        • Параллельно вводу выдавать расшифровку вводимой даты. Американец увидит "12 ноября" и исправится.
      • Да и боты под это удобнее программировать ^_^
    • НЛО прилетело и опубликовало эту надпись здесь.
    • Англоцентричное исполнение: http://www.datejs.com/
      • Ввожу 12.4.8 - думает что имею ввиду 8 апреля 2012. не катит.
        • В условиях задачи разве запрещено адаптировать для русских пользователей исходники скрипта?
        • я сам не понимаю что это за дата. чего же вы хотите от бездушного робота :) - выругаться и всё тут..
    • Оно может и удобнее, но сейчас такая форма будет постоянно меня гипнотизировать.
    • сегодняшний пользователь хреново знает клавиатуру, но уже хорошо водит мышкой
  • > Кто вводил месяц числом, а кто и цифрой.
    буквами наверное имелось ввиду?
  • у меня как-то тож сразу глаз не зацепился за десятки (верхняя строка), а первый раз и потом все вис и вис на левом столбце, тем более он выделен серым.

    по мне было бы удобней годА (десятки) сделать в левом столбце, т.е. не по столбцам выбирать, а по строкам
    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...
      • Не знаю - тут: на вкус и цвет.... если еще чуток порационализировать - потребуется отдельный мануал по выбору даты в таком списке. Тем более, что есть большой класс людей которые очень легко теряются в любых таблицах цифр.
        а в вашей... слишком много для юзверя "думать надо".
        ИМХО - удобнее ограничение по маске ввода в обычном текстовом поле.
  • Как автор мог про это забыть? http://marcgrabanski.com/code/ui-datepicker/
    Ну и ему подобные юзабилити для пользователя.
  • На мой взгляд, далеко не самое красивое решение проблемы.
    Правда, мне вот именно в таком виде получение даты от юзверов еще ни разу не требовалось, но я бы сделал проще: Поле для ввода с подписью ожидаемого формата, а снизу, например, прописывание нормальным человеческим языком, как была понята дата, вписаная юзвером.

    Например мы хотим формат ДД.ММ.ГГ, человек нам вводит 03.03.08, мы ему подписываем для контроля, что мы это поняли как 3 марта 2008 года.

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

    В случае кривого, непонятного нам ввода, так прямо и пишем, что введена хня и форму сабмитить не давать.
  • Если упрощать дальше, то после указания года и месяца скрипт может вычислить возможные варианты числа (4-5 вариантов).
  • Интересное исследование по теме
  • Лень было регистрироваться, но прочитав пост, понял что обязан приплюсовать
  • "высокостный год" это что?
    год высокой кости?
  • Кстати, а каковы возможные последствия неверного ввода даты?

    Если это гостиница/билеты - там, как правило, выбирать надо в текущем, максимум, следующем месяце - для этого вываливать календарик, пожалуй, оптимально.

    А если надо спросить для той самой статистики дату рождения - ну введут пять человек из тысячи 12/11 вместо 11/12. И что?

    Ещё вариант - после того как пользователь покинул поле ввода даты, рядом рисовать нечто вроде валидатора - писать дату человеческим языком: [01/02/03 ].......1 февраля 2003 года.
    Тогда сразу понятно кто что имел в виду и кто как кого понял.
    • выбирать надо в текущем, максимум, следующем месяце
      как-то вы мелко мыслите :) я иногда билеты и за полгода покупаю
      а вот валидатор — это хорошая идея, причём "валидировать" прямо во время ввода
      • Я тоже.
        Но, похоже, мы в меньшинстве.
  • я пока сешарп изучал, не заметил встроенный класс, изобрёл свой лисопед, который проверял високосный год, 31ые ноября и прочее щячло одним ifом. И вполне так быстро накатал :)
  • в особо редких случаях использую чужие "велосипеды"
    http://dynamicdrive.com/dynamicindex7/jasoncalendar.htm

    удобное API, удобная работа с всевозможными форматами данных и нет проблем с 31 февраля.
  • Когда вас спрашивают дату, вы какой число вспоминаете первым? Вы вспомните сначала день, затем месяц, а уж потом год. Почему же надо вводить в обратном порядке?
    • логичнее наоборот, сперва год, потом месяц, потом день: 2007-12-25
      я записываю даты так или "20071225", заодно и сортируется сразу правильно, и искать проще
      • это уже не юзабилити, если среднестатистического пользователя выводят из привычных ему норм освоения или ввода информации, он начинает паниковать и может наступить фрустрация
        • на кого наступить?
          хабрачеловек посмотреть профиль ostanin спросил, какое число мы вспоминаем первым, когда нас спрашивают дату. год вспомнить проще, потом месяц, потом число — я ориентируюсь по своим архивам фотографий :) они у меня так и называются: "2007-11-16, В горах Атлантики" или "2005-06-13, в кофешопе в Амстердаме" и т.п. :)
          • согласен что для сортировки удобнее год месяц день сам ее использую уже с порядок...
            но мы говорим о "среднестатистическом пользователе"
          • дык - на тебя никто не наступает есс-но.
            тот, на кого не планируется наступать - тут писать вообще не будет :)

            А я лучше помню - времена года, а по ним месяцы... потом уже года и даты.
  • Одно поле все-таки лучше, чем три, да еще со списками. Большинство пользователей введут дату правильно, особенно если им подсказать, например, написав серым цветов в самом поле даты желаемый формат «день/месяц/год». Если от даты что-то зависит, например, это сайт знакомств, то пользователи тем более будут стараться все ввести правильно, ну или как им хочется чтобы было правильно :) Если от даты ничего не зависит, то зачем вообще о ней заботится? Проще оставить ее как есть. Если от даты что-то зависит, то опять-таки оставить как есть, но ненавязчиво намекнуть пользователю, что дата не распознана.

    Парсер для дат написать не так уж и сложно. Если введенный пользователем текст хранится как он есть, можно время от времени искать все даты, которые парсер не смог распознать, и если это был недостаток парсера, дописывать ему вариантов. Через какое-то время он будет распознавать почти все.
  • Автор, перед публикацией текста проверяй написанное хотя бы в Word'e. Уйма ошибок!

    ------------------
    Ну вроде проблемм возникать не должно, пользовать по обычаю двигаеться слева направо.
    ------------------

    проблемм -> проблем
    двигаеться -> двигается
    пользовать -> пользователь
    по обычаю -> обычно

    Это не говоря уже о пунктуации.

    Вообщем, рекомендую изучать не юзабилити, а грамматику и пунктуацию.
    • Вообщем -> в общем :)
      • спасибо!
      • Да, сенькс. Я поправил себя ниже http://habrahabr.ru/blog/ui_design_and_usability/36974.html#comment693181

        Но важно проверять всё же текст статьи перед выкладкой. Комментировать можно и с ошибками, это не важно.
        Хотя сам лоханулся, да. Признаю)
  • И вы говорите об удобстве? ;))
    Самый ужасный вариант ввода - разбиение на 3 поля...
    А идеальный - текстовое поле с кнопкой календарика.
    Итого:
    Дату рождения проще всего ввести с клавиатуры, не шарясь мышкой по экрану, в то время, как ближайшие даты лучше выбирать на календаре. Распознавание даты - задача просто элементарная, надо лишь учитывать американский формат (ММ/ДД/ГГГГ) - либо упомянуть об этом, либо, как очень хорошо уточнили выше, выводить рядом то, как дату понял скрипт.
    Об удобстве календаря тоже можно много чего сказать, формат комментария для этого не слишком удобен. Можно например воспользоваться "скроллинговым" календарем (Горбунов, Apple etc) для ближних дат, либо "полноразмерным" календарем (ваш вариант, ext-js etc), в котором каждую часть даты можно выбирать из полного списка.
    Далее, разумеется, это все улучшать, например совмещая подходы - календарь со скроллом, в котором клик на год показывает большое табло.

    В итоге получаем компактное поле с большими возможностями. Очень хочу в ближайшее время написать подробные разборы различных элементов интерфейса.

    Все это, конечно, было имхо, но я надеюсь, что так думаю не я один...
    • Полностью согласен - я в итоге пришел в варианту номер один + кнопка календарика.
      Дату пользователь вводит в каком угодно формате сам, а как её распарсить - это уже моя задача.
      Единственная загвоздка с американским форматом дат: если кто-то введёт 03/04/2008 - это можно понять двояко, но поскольку моя аудитория исключительно европейская, я принимаю такие строки как европейский формат дат (о чём отдельно сообщаю пользователю).
  • чудесно! не хватает только js-объекта реализующего эту функциональность :)
  • Поправлю и себя:
    Вообщем -> В общем

    lol
  • А слабо сначала ввести день и месяц, а потом отобразить года, когда такое возможно? Или даже после ввода дня в списке оставить только возможные месяцы.

    Вообще через 15 лет за людей будут вводить даты моллюски, управляемые имплантатами в мозгу. Нужно уже думать над интерфейсами в этом направлении.
  • а я вот вообще не силён в написании хорошого кода,..
    но я думаю, что вообще это должно выгляеть след. оброзом:

    просто, ПРОСТО! одно поле(к которому прикручен хитрый ява скрипт)
    и в этом поле юзер вводит свою дату, просто нажимая на кнопки цыфирек...
    в любом порядке, тоесть, либо в америкоском стандарте (02.17.80), либо в русском (17.02.80)
    вот и все!
    п.с. мое мнение-мнение абсолютного юзера.
  • Смысл всей этой кухни не в этом! Ведь пользователь может и с защитой от "дурака-юзера"...поставить то, что он захочет в пределах возможного, и в итоге сайт опять не получает достоверных данных. Пользователь должен быть замотивирован на это, только тогда он внесет настоящие данные о себе, причем в любую по сложности форму.
    • Здесь речь об удобстве ввода, а не о достоверности данных.
      • К сожалению все эти формы на защищены от дурака, и неисключают ввода допустим такой даты: 31 ноября 3450 года.
        • Проверка на стороне клиента. Проверка на стороне сервера.
          • Разумеется проверка на стороне сервера. Я процитировал статью, в которой говорится не только об удобстве вводу, а и о достоверности данных.
            Проверка на стороне клиента пускай будет на JS.
    • сайт никогда не получит достоверных данных!
      если мне щас 28, что мне мешает поставить 25, 27 или 33???
      помему тут речь не о достоверности, всетаки, а о ЮЗАбИЛИТИ...
  • С точки зрения юзабилити будет правильнее разместить годы так:
    2000 1990 1980
    2001 1991 1981
    2002 1992 1982
    ... ... ...
    Потому что большинство вводимых дат в районе 1970 - 2000, и пользователю не придется вести курсор в конец таблицы, как в авторском варианте.
    • А если бы с точки зрения посещаемости *вашего* сайта: большинство было бы 18-25 лет, затем 11-18, а затем 25-60 вы бы так и проранжировали (с точки зрения "юзабилити" интересует)?
      • Ну конечно же нет :)
        Оптимизируя разметку для уменьшения расстояний и числа кликов, необходимых для достижения цели, не следует забывать и о логике.
        Но если бы количество пользователей из одной категории значительно превышало всех вместе взятых из других(>95%), я бы рискнул поставить эту категорию уже выбраной по умолчанию.
        • Точно, обычно логичный интерфейс и бывает удобным. А в вашем примере нужно читать как литературный японский - сверху вниз плюс справа налево, но европейский глаз обычно будет искать 1980 слева от 1981 (а не выше).
          • Если честно, то я не знаю какой вариант будет быстрее:
            в авторском интерфейсе необходимо взглядом пробежать ~8 четырехзначный цифр, прежде чем пользователь найдет 'свой' ряд.
            В случае с 'японским' порядком - 3 наиболее часто выбираемые даты находятся сразу под полем 'выберите год', т.е. глазу никуда бежать не надо - все цифры перед ним, полжзователь даже удивиться не успеет :)
            • >я не знаю какой вариант будет быстрее
              По-моему быстрее будет привычный глазу порядок. Ну хотя бы вот так (намеренно снизу вверх):

              2000 2001 2002 2003 ...
              1990 1991 1992 1993 ...
              1980 1981 1982 1983 ...

              Имхо это как раз тот случай когда эргономичность (минимизация времени, расстояний) отличается от юзабилити (понятность, логичность). Быть может если нужно было бы выбирать 100 дат, было бы разумнее сделать эргономичным, но в выборе даты рождения время на нахождение закономерности (и целесообразности, мол почему вдруг все наоборот?) не окупится.
              • Ну вот, оказывается вы уже раньше меня это написали) Мне приведённый вами сейчас вариант кажется именно что наиболее понятным и логичным. Последние годы должны быть в начале. Точка отсчёта десятков, локальный ноль - двухтысячный, а непонятный девятисотый.

                Но тут мне интересно, почему вариант строчного расположения показался вам более удобным, чем столбцами?
                • Представьте (не смотря в таблицу) что первый ваш взгляд упал на, скажем, 1965 и подумайте в каком порядке вы бы искали предыдущий ему год - слева, справа, выше, ниже? И потом то же, но с десятилетиями. Это те два направления закономерность которых и нужно отыскать чтобы (далее незадумываясь) найти свой год. В идеале у большинства пользователей должно быть минимум ошибочных (глазо-)движений, т.е. идем ладьей на нужную клетку за два хода.
                  • я полностью согласен. в этом отношении может и столило сделать построчную сортировку
              • А может то, что такой формат:
                2000 1990 1980 ...
                2001 1991 1981 ...
                2002 1992 1982 ...
                больше похож на обычные выпадающие списки(по годам от десятков), то он более легче будет восприниматься?
                • Может и так. Вернее будет провести эксперимент с реальными людьми, согласными помочь.
  • Есть такая штука — <input type="date">

    Правда, работает пока только в Опере ;)
    • есть, но только там года листать стрелочками только можно, и пока лет хх отлистаешь назад от текущей даты - уже и регестрироваться перехочется :(
  • Не плохо, я был бы очень рад, если бы многие сайты ввели такое новшество, а то действительно стандартные филды страх как неудобны и очень надоели.
  • в идеале было бы так:

    Или выберите из списка:


    Edit сверху синхронизировать с календариком снизу
    • Такой вариант как бы говорит нам "Я разработчик и незнаю как было бы лучше. Пользователь думай давай сам".
      • кажется, в Outlook сделано так, есть поле ввода даты и кнопка календарика — оптимальный вариант
    • А как зарегистрироваться счастливому(?) человеку, которому стукнуло 110 лет? ;)
  • Интересно было почитать. Я сам использую поле для ввода и кнопку для календарика.
    Думаю в этой статье не хватает сопоставления различных видов (динамических)форм с сайтами различной тематики. В смысле где было бы удобнее так, а где эдак.
  • Много раз встречала момент с февралём, но недоделанный. То есть 29 февраля невозможно было указать для любого года, ну поленились високосные реализовать ;) Обидно. А ваше решение мне очень нравится, особенно решение с годами, действительно удобно.
  • Можно еще оставить одно поле для ввода возраста, и по нему считать год, а список месяцев и дней выводить в зависимости от этого значения (возраста). Т.е. после ввода двузначного числа скрипт выдает два выпадающих списка, с месяцами и днями, причем только с теми, которые попадают в неопределившийся промежуток. Например сейчас март и мне 19 лет - год считается автоматом 1988, и выдается список месяцев март-декабрь, и список дней. К томуже если человек родился в декабре и регистрируется в этом же месяце, то останется выбрать только день. Хотя последнее все же частность, но здоровый список с годами нам уже ненужен в любом случае.
  • autocomplete выкинут за борт :)
  • Когда создавал новую версию моего проекта по поиску собак, тоже не раз задавался вопросом, как упростить жизнь пользователю... И ответ пришел сам:

    Удобный календарик

    Пользователи не должны задумываться о том, как правильно вводится дата, чтобы наша систем а её распознала.
    • А что это за PETKNRL? На каком это языке, учитывая, что слово «Календарь», по-видимому, на русском?
    • На эстонском
  • Мрачнее всего выглядит перспектива писать два варианта кода - для тех, у кого включен яваскрипт и для тех кто прикола ради его отключил.
    • Вот это кстати проблема на сегодняшний день имхо не актуальна. Поскольку множество проектов сейчас активно юзают JS, в частности аякс. Поэтому если пользователь хочет юзабилити, пусть держит включеным. Ну а по поводу безопасности... смотрите что кушаете, и все будет хорошо + аверы мониторят странички.
    • Progressive enhancement с самого начала — и париться о проблемах не надо будет. :)
  • Преамбула: bash.org.ru, wordstream. »Социально активный сайт«, между прочим. Видим на нем массу идиЁтов, коих фильтровать стоит по году рождения до 1985 включительно, и некоторое количество вопросов »кисакуку ASL?«
    Сейчас в своей песочнице леплю что-то вроде этого:

    Идея в том, что некоторая критическая дата (скажем, допуск только лицам двадцатилетней степени разложения) каждый раз отображается новая, в зависимости от года за окном. И в БД сохраняется однажды.. обеспечивая проверку уровня допуска. Набегают орки, рисуют предупреждения, гоняют малолеток — если пользователю явно меньше 13 лет, то согласиться с утверждений количеством диких придется ему, на свой страх и риск.

    Поскольку всех данных нам, в общем-то, и не надо (а кое-что дублируется сервисами проекта) — хватает отображения общих. Если человек захочет ввести личные данные — от лишнего клика по тексту не обеднеет (иначе »ахтунг, быдлокун«). А по клику можно хоть десять скрытых div'ов|слоев вывести, хоть для указания времени рождения в Unix time-формате, ня.

    Да, за копипаст зодиакального круга с DreamsTime'а попрошу не бить.
    • Соответственно, на «национальных проектах» не возбраняется проводить первый этап выбора по типу выдачи документа, удостоверяющего личность. От тугаментов царских времен (знаем, знаем, сам при регистрации 1901 год ставлю) до новеньких биометрических паспортов.
    • Двенадцать знаков зодиака это рунично, но абсолютная проверка допуска еще не значит признак отсечения малолеток, например. Любой случайный клик и баланс нарушается, делая напрасным целесообразность любой био- и психометрии.
  • Мне, например, такой вариант удобнее:
    http://www.therandom.org.ua/files/dateform.png

    Последний формат даты можно подгружать, учитывая региональные стандарты отображения даты пользователя (страну, например, по IP можно предположить).


    • А где пунктик [x] ничего из вышеперечисленного? :)

      ЗЫ. Если серьезно, то дату с любым разделителем и любым данным написанием может разобрать сам скрипт (не нагружая человека), если только не учитывать (а у вас это тоже не берется в расчет) что 12/02 кто-то прочтет как 12 декабря, а американец как 2 декабря.
      • Согласен с тем, что парсер даты со строки можно написать либо найти готовый.
        Но с моей точки зрения на юзабилити (она сугубо субъективна и не претендует на абсолютную истину) пользователю необходимо(!) дать возможность принимать решение — что и в каком формате передавать "незнакомым людям". Даже не смотря на то, что после ввода парсер все-таки перепроверит и в случае нестыковки переформатирует дату.
        • Понятно. А что если пользователь не хочет принимать решение ("ну чего там снова нужно выбирать"), или еще хуже он задумается аки буриданов осел: "а что собственно лучше?" :)
          • Признаю, вариант не идеален.
            Поэкспериментируем:
            http://www.therandom.org.ua/files/dateform2.png

            Извините, не могу напрямую картинку добавить
            • Имхо здорово! :)
              • Спасибо.
                В процессе дискуссии рождаються интересные вещи )
      • Очень бесполезно и неудобно.
  • Возможно, оффтоп, но:
    Проблемма - *проблема
    Естесвенно - *Естественно
    данно - *данное (в контексте)
    побарабану - *по барабану
    програмисты - *программисты
    следующие - *следующее (в контексте)
    Вродебы - *Вроде бы
    вбивалься - *вбивался
    избешать - *избежать
    Не всё, не усну - дополню
    • слежущее - *следущее
      неисключают - *не исключают
      высокостный - *високосный
      ахренел - *охренел (приставки "а" не существует)
      Стилистику, и, пунктуацию? дажетрогать небуду.
      • Блин, ну это уже надоедать начинает. Напишите автору сообщение и не захламляйте топик. Вот как ни гляну на какой-нибудь пост — всегда прибежит три-четыре борца за грамотность и будет тыкать в ошибки, вместо того, чтобы обсуждать собственно тему поста.
        • Не захламляете ли вы топик подобными возмущёнными комментариями?
          Мне кажется, хабралюдям удобнее будет читать грамотно написанный текст.
          А про личное сообщение... Исправлюсь.
          • Я первый раз не сдержался, а такое вижу постоянно, ну чего вы
      • следущее - *следующее
      • Хватит флудить... соц.сеть филологов находится по адресу disneyland.com - разбираем "Введите хуй...бр... с утра опять перепутал... дату :)
    • Спасибо Вам! Люди, позволяющие себе писать неграмотно, небрежно относятся и к содержанию (как правило).
      • Вы в корне не праВы!
        • Вернее правы но не в корне
  • Одна строка. Пользователь вводит дату 04.03.2008. Рядом отображаем результат распознавания (4 марта 2008), и, в спорных случаях, пишем рядом что-нибудь вроде «вообще-то, я родился 3 апреля!», при клике на этой надписи выставляем датой 03.04.2008
  • Предлагаю вариант Висту.
    Там намного удобнее.
  • Не знаю, пожалуй что это от пользователя зависит, но мне таблица лет была бы удобнее построчной, а не столбцами, и снизу вверх десятки, слева направо единицы.

    2000 01 02 ..
    1990 91 92 ..

    Это наверняка depends, и говорю я с позиции пользователя, а никак не юзабелиста:), так что на всякий случай объяснюсь. Отсчёт прошедших лет мне представляется задом наперёд, т.е. десятки удобнее воспринимать, начиная с последнего. Но, поскольку десятки служат отправной точкой, после отлова её нужный год проще выбрать уже просто цифрой (без обратного отсчёта).
    Ну а строчки vs столбцы мотивировать не могу, они уж, наверное, точно кому как.
    • да мне тоже как пользователю и юзабелисту удобноее, когда года все в одном столбце. Причем мне удобнее, чтобы нумерация шла из настоящего в прошлое по убыванию.
  • Щас будем исправлять ошиПки.
  • помоему уже давно есть созданные модули, которые позволяют выбрать дату в календаре. Весьма удобно и практично... Нового ничего не открылось
    • А вы много знаете людей, родившихся в 2009 году? :-) Мне кажется, с 2000 можно убрать.
    • Это я не вам, а автору топика :-)


  • в HTML 5, может стоит подумать над использованием этого инструмента ?
  • сорри, в исправление предыдущего коммента:

    в HTML 5 есть type date для input. может стоит подумать приспособить его ?
    снизу ссылка на скрин работы тэга.

    http://img84.imageshack.us/my.php?image=clipboardqt6.jpg
  • а по-моему достаточно удобно выбирать дату в календарике сразу. В таком какой есть в том же Windows XP, когда необходимо поменять дату.. ;)
    Хотя пользователю как таковому всегда быстрее и удобнее впечатать день, месяц и год с клавиатуры, потому что это быстрее ))
    я бы как пользователь предпочла этот вариант. Другое дело, что действительно ошибок будет масса
  • Господа, просто нужно свои юпитерские щупальца, которыми пишутся интерфейсы интерпретировать под пять пальцев на каждой руке землянина, тогда все проблемы - не проблемы.

    PS
    Лучший вариант - интуитивно понятный для любого имбицила, то есть первый.
    • какой ужас... секунд 20 пытался понять, что это вообще такое Вы тут нарисовали.
      еще 20 секунд — почему два ряда годов. потом заметил мелкие блеклые буковки с примечаниями. офигел.

      сейчас уже, начав писать комментарий, увидел еще совсем мелкие и совсем неразличимые циферки рядом с месяцами. секунд 10 на то, чтобы понять, что они обозначают.

      не говоря уже о последних цифрах годов в верхней строке и завершающей строке с невидимой надписью «подтвердить».

      скажите честно: вы издеваетесь? или это в шутку запостили?
      • Я когда-то мыслил похожим с автором поста образом, и перепробовал кучу всяких вариантов, в том числе и этот. На самом деле ввод происходит построчно — пользователь видит сначала первую строку, потом, после клика, первую и вторую, и т.п.

        Однако, после зрелых размышлений, я эту штуку убрал подальше, и сделал обычные списки — может длинный скролл кого-то и смущает, зато однозначно и всем понятно.
        • Вы не совсем правы. ввод-то идет построчно, но перед тем как ввести что-то, пользователь окидывает взглядом страницу, чтобы понять, что вообще ему тут дают. и вот такая форма просто введет неопытного пользователя в ступор. он будет долго втыкать, что ж это такое, нафига оно ему и как этим пользуются. да даже и опытный. так что хорошо, что Вы отказались от этой затеи :)
      • Кстати, если не трудно, вы не могли бы показать, как это смотрится у вас? Судя по комментарию контраст явно недостаточен, хотя по задумке «невидимые» надписи достаточно хорошо различимы.
        • фотоаппарата нет под рукой, увы
        • но в любом случае, бледно-серое на темно-сером = плохо.
      • Митя, точно так же тупил секунд 10, прежде чем вник, что это за матрица там :)
    • Гм... Необычное решение.
      По крайней мере нестандартное и смелое.

      Но разобраться точно трудно.
    • И всё это не будет работать без JavaScript. ;)
    • а я посмею согласится с beeos. Мне нравится такой подход. Отличное решение для стандартной процедуры. Шрифты? Серый фон? Да это всё меняется на раз, тут уж, дело личного вкуса, я считаю, ну или вкуса заказчика, как хотите. Разобрался вообще сходу. Так что респект за идейку.
  • Ваш вариант выбора года просто ужас, имхо.
    Почему не использовать выбиралку даты в виде обычного и привычного календаря? (Например как в настраивалке времени в винде или кде) ?
    • да потому чтобы выбрать свой год в этом календарике надо пятьсот раз тыкнуть мышкой, что совсем неудобно
  • не самое удачное решение выбора года. я лично сначала взглядом по привычке проигнорировал заголовок. долго бегал глазами, чтобы понять, по какому принципу вообще организован этот дикий набор цифер.
    потом, так ли много пользователей, родившихся в 1900м году? или 1910? сомнительно. но это мелочи. главное — это то, что такая куча цифер просто сбивает с толку сразу.
  • у меня есть некие размышления о стандартизации инета.. глобально.. в связи с этим:
    например, в опере есть фича, которая по одному нажатию заполняет все поля - от имени и фамилии до почтового индекса. Один раз туда забил данные - рассовывай по всему инету, не жалко.

    я понимаю, что к разработчикам сайтов это отношения не имеет, но всё же..
    Если в опере это есть, наверняка существуют плагины и в Огнелис, и в прочие.
    Я конечно же отдаю отчёт в том что это некие проблемы.. Но если уж речь об этом..
    Ну например.. Ввёл юзер неправильно дату у вас, а вы ему вместе с уведомлением о косяке ссылочку на такой плагин. И помощь, и развитие некое.
    Все же пользуются автозаполнением/автовходом на сайты...

    А через какое-то время в будущем - на сайте вместо огромного количества форм только разрешение на ввод данных из браузера (с какой-нить возможностью корректировать при желании)
  • Минималистический вариант - старый добрый <input> + input masking, отображающий требуемый формат даты в этом же поле и "на лету" фильтрующий вводимые данные. Пример - тут (закладка Demo).
  • вообще думается надо давать возможность выбрать мышкой в красивой такой сраной менюшке, но чтобы было текстовое поле все таки было, желательно даже такое, чтобы табом не скакать. Вспомните поле ввода айпишника в винде. Можно сделать облачко, как для тэгов, где покрупнее выделены года, наиболее часто которые выбирают, либо в которые больше людей родилось )) либо на результат исследования возрастной аудитории сайта.
  • Вот вы как хотите, а я родился 21 ноября 1986 а не 1986 ноябрь 21, признайте что дико звучит :)
    Если человек "дурак" то никто не помешает отправить 31 февраля GET на сервер, а если опечатался, то только поблагодарит если появится подсказочка что такой даты нет и вы вероятно ошиблись.
  • Странно, что Якоб Нильсен об этом ещё не писал... ;)
  • мне конечный вариант не понравился, может быть это логически правильно или очень всё корректно, но как сложно, пользователь ожидая увидеть что-то среди ранее рассмотренных вариантов, к чему он уже привык видит очень громоздкие выпадашки с множеством чисел
  • Поддерживаю идею с одним текстовым полем. Что знаю - в Django такое поле используется для дат по умолчанию + две очень удобных кнопки, Календарь и Сегодня.
  • Предлагаю текстовое поле с кнопкой для показа, или просто показывающее при клике что-то вроде предложенных тут выпадающих списков, последовательно. Преимущества:
    1. можно ввести вручную
    2. 4 клика вместо 6ти
    3. поле ввода покороче, и покакуратнее выглядит
    4. в выборе года можно один пункт сделать "не указывать" или вроде того
    Различные календарики, как по мне, подходят только для дат не сильно далеко отклоняющихся от текущей, дату рождения не удобно вводить
  • Слишком сложно.

    Проще проверить дату после введения и сообщить, если ввод неправильный. Большинство введет дату верно, и потратят на ввод меньше времени, чем с вашим решением. У Яндекса хороший вариант.
  • 1. а без JS
    2. а без привлечения внимания пользователя к освоению "инновационного интерфейса"?
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.