Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Давайте хотя бы дадим пользователю вводить дату с клавиатуры с однозначным и ясным форматом. А то любимая фишка горе-писателей: введите год рождения и кнопочка для тырканья мышкой с календарем по месяцам. И торкай себе до 1950 года какого-нибудь начиная с текущей даты.
PS Конкретно в вашем случае я где-нибудь рядом с формой (или внутри) приписал сам формат «дд/мм/гг», чтобы не приходилось гадать.
PS Конкретно в вашем случае я где-нибудь рядом с формой (или внутри) приписал сам формат «дд/мм/гг», чтобы не приходилось гадать.
Мне кажется, что элементов управления многовато. Без мышки будет трудно пользоваться. Наверное, потому вариант с отдельным вводом такой живучий — он очень простой.
Не вижу в Вашей статье размышлений над таким феноменом. Или ERP системы обычно заточены только на один стандарт? В противном случае нельзя давать юзеру вводить дату с клавиатуры.
Согласен, не рассмотрел указанный аспект — а надо было. Дело в том, что во многих случаях порядок следования даты/месяца/года разруливается контекстно. К сожалению, в противоречивых случаях приходится закладываться на какой-то один предпочтительный порядок.
Собственно, мы так и поступаем.
Собственно, мы так и поступаем.
По разделителям я пояснения дал в статье — принимаются любые.
Я сам всегда за упрощение вода и допущение многовариантности ввода, но в статье явно перебор. Самое слабое звено в любой системе — человек. И если допущений слишком много, как здесь, то банальная опечатка может быть неверно истолкована.
Если система требует ввода полной даты, то это должна быть полная дата, т.е. строка, содержащая и число, и месяц, и год. Разделителем может быть точка, дефис, слеш — неважно, но присутствовать должны все три компонента
Если система требует ввода полной даты, то это должна быть полная дата, т.е. строка, содержащая и число, и месяц, и год. Разделителем может быть точка, дефис, слеш — неважно, но присутствовать должны все три компонента
Собственно по дате — перед написанием статьи посмотрел много разных систем — подавляющее большинство допускают ограниченный ввод. Так чем период то хуже? Более того, транзактивные учетные данные очень часто требуют ввода даты (изложенные консенсус уже сложился), а период обычно вводится при получении отчетов. Так зачем напрягать пользователя больше там, где ответственность меньше?
Я же написал, в чем проблема — в распознавании опечаток, которые всегда были, есть и будут. Я на своем опыте знаю, как часто юзеры делают опечатки, и некоторые разумные ограничения могут упростить общение гуманоида с интерфейсом, уменьшая саму возможность опечатки. Добавлю, что излишние ограничения (типа длиннющего списка годов) меня самого напрягают. Но излишняя свобода, когда вбивай, что хочешь и как хочешь — это тоже перебор.
И мне не очень нравится, что в Вашем варианте и дата, и период — все вводится в одном поле. ИМХО, должно четко фиксироваться — вводится единичная дата или период, т.е. какой-то переключатель, типа «дата/период». И если период, то вводить надо две даты в разных полях. Ибо банальный пропуск одной точки — это будет самая частая ошибка юзеров, поверьте. В итоге Ваше упрощение не облегчит жизнь пользователям, а только усложнит, вызывая у них раздражение.
И мне не очень нравится, что в Вашем варианте и дата, и период — все вводится в одном поле. ИМХО, должно четко фиксироваться — вводится единичная дата или период, т.е. какой-то переключатель, типа «дата/период». И если период, то вводить надо две даты в разных полях. Ибо банальный пропуск одной точки — это будет самая частая ошибка юзеров, поверьте. В итоге Ваше упрощение не облегчит жизнь пользователям, а только усложнит, вызывая у них раздражение.
Секунду! Ввод single-даты я не рассматривал. Для этого существует отдельный тип поля ввода со своим календарем и своими же правилами. Здесь речь идет только о вводе периода. То есть, никакой такой путаницы нет и быть не может. Если в поле ввода периода пользователь указал 12, то это значит, что он хочет отчет с 12-го числа текущего месяца по 12-е же число текущего месяца. А если при вводе в поле даты (например в задаче) он указал 12, то система воспринимает это как, скажем, due date 12 числа текущего месяца.
Соответственно, поле ввода даты (из примера) будет иметь метку «Дата исполнения», а поле ввода периода, скажем, в фильтре отчета о продажах — «Период».
Соответственно, поле ввода даты (из примера) будет иметь метку «Дата исполнения», а поле ввода периода, скажем, в фильтре отчета о продажах — «Период».
Если в поле ввода периода пользователь указал 12, то это значит, что он хочет отчет с 12-го числа текущего месяца по 12-е же число текущего месяца
Это Вы так решили. А некоторые юзеры запросто может решить, что таким образом он может ввести 12-й месяц (с 1-го по 31-е число). И если им указать на ошибку, то многие из них еще и возмущаться начнут: «Сами же говорили, что можно только месяц указать!»
У меня есть опыт массового внедрения софта среди «мирного населения», поэтому насмотрелся всякого…
По опечаткам. Поле ввода — не последняя инстанция в контроле правильности ввода. Существует проверка при commit'е формы (диалога), далее — при проведении транзакции система не имеет права закладываться на то, что кто-то ей предоставил верные данные — следовательно имеем, как минимум, третий эшелон обороны от некорректного ввода.
Здесь же речь идет только о том, что бы увеличить производительность сотрудников и снизить их утомляемость (раздражение) в узко очерченной области.
Здесь же речь идет только о том, что бы увеличить производительность сотрудников и снизить их утомляемость (раздражение) в узко очерченной области.
Помню, надо нам было вбивать данные с сотен анкет для голосования (где люди от руки ставили баллы конкурсным работам). Придумали удобный интерфейс — чтобы с клавиатуры можно было быстро набивать, причем форма выглядела похожей на анкету (чтобы легко проверить, корректно ли всё вбил). В разработке интерфейса участвовали те, кто должен был вводить данные.
В итоге, на практике не менее половины вбивальщиков предпочли пользоваться редактором FAR'a :-)
В итоге, на практике не менее половины вбивальщиков предпочли пользоваться редактором FAR'a :-)
Только я по заголовку подумал, что речь в статье о вводе десятичного разделителя?
Если вашему пользователю трудно ввести две даты, то тогда на вашу форму инструкцию писать придется.
Три кнопки внизу справа позволяют, соответственно, открыть относительно выбранной даты период слева (..5/11/2013), выбрать пустой период, открыть относительно выбранной даты период слева (1/11/2013..).Может, три кнопки слева, а для третьей кнопки — период справа?
А вообще, ИМХО, слишком сложная и неинтуитивная форма. Пользователи не страдают? Я был слегка ошеломлён, когда увидел скриншот :)
Из практики разработки CRM — как ни странно, но таких многофакторных отчетов не встречалось. Всегда требовались либо годовые/квартальные, либо за определенные дни/периоды.
В первом случае было два поля: год и номер квартала/месяца.
Во втором случае делалось тоже два поля: дата начала и дата окончания периода. Но рядом ставилась небольшая кнопка для быстрого выбора из выпадающего списка самых часто используемых дат с последующим автозаполнением (например, «текущий месяц», «прошлый месяц», «начало недели», «конец недели» и т.п.).
В первом случае было два поля: год и номер квартала/месяца.
Во втором случае делалось тоже два поля: дата начала и дата окончания периода. Но рядом ставилась небольшая кнопка для быстрого выбора из выпадающего списка самых часто используемых дат с последующим автозаполнением (например, «текущий месяц», «прошлый месяц», «начало недели», «конец недели» и т.п.).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ввод периода: хватит терроризировать пользователей