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