Почему я не должен просить своих пользователей вводить время, используя военный формат
У меня есть форма, которая просит пользователей ввести время начала и окончания события. В течение многих лет мы позволяли им вводить время, выбирая часы (1-12), минуты (1-60) и AM/PM из трех выпадающих списков. Это работало нормально без жалоб от клиентов. Однако сегодня я получил запрос на изменение ввода в одно текстовое поле, чтобы пользователь мог вводить время в военное время (он же 0000 - 2359). В моей интуиции я считаю, что это плохая идея, но мне трудно придумать какие-либо неопровержимые факты.
Каковы наилучшие причины, которые я могу привести, что это будет плохой идеей?
Если есть лучшее решение для ввода времени, что бы это было?
Кроме того, к сведению пользователей, заполняющих форму, охватывают весь спектр навыков от компьютеров до опытных пользователей. Они никак не связаны с военными.
Обновление: все мои пользователи являются локальными, и никакие другие формы (веб или печатные) не используют военное время в качестве стандарта.
16 ответов
Ну, с точки зрения пользовательского интерфейса, это может быть ошибкой просто в соответствии с некоторыми эвристиками пользовательского интерфейса Якоба Нильсена:
"Матч между системой и реальным миром". Если ваши пользователи не привыкли вводить даты в военное время, попросить их сделать это для вашего приложения в лучшем случае может отвлечь, а в худшем - разочарование.
"Предотвращение ошибок" Вы не устраняете подверженные ошибкам условия, но, возможно, вводите их.
Существует также вопрос, почему это изменение было сделано. Клиенты жалуются? Данные поступают неправильно? Как уже упоминалось, ваши пользователи привыкли к военному времени? Любое изменение интерфейса должно произойти по какой-то причине, IMO, потому что вы собираетесь изменить пользовательский интерфейс, и для этого будут последствия; это просто вопрос того, насколько велики будут эти разветвления. Я предполагаю, что ошибок при вводе данных якобы избегают, но так ли это? Попросить пользователя ввести время в формате "XX:XX" и разобрать точку с запятой (или, как сказал Аарон Дигулла, ЛЮБЫЕ нечисловые символы), а затем преобразовать его по мере необходимости, с меньшей вероятностью приведет к ошибкам, чем запрос пользователя введите время в формате, к которому они не привыкли ежедневно.
Меня беспокоит то, что пользователь хочет войти в 15:30 и, не обращая особого внимания, просто вводит 330. Сейчас 3:30, и пользователь никогда не узнает разницу, потому что приложение берет информацию и счастливо предполагает, что это то, что имеется в виду. Тем не менее, предоставление пользователю возможности вводить время в формате "XX:XX" и выбор "AM/PM" имеет гораздо больше смысла.
Что касается неопровержимых фактов, у меня их тоже нет. Но если ваш босс / клиент не будет зависеть от эвристики Нильсена, я не уверен, что может изменить их мнение.
Три выпадающих списка - кошмар с точки зрения удобства использования. Вы можете сократить их до двух, исключив AM/PM и перейдя к 24-часовому формату, но все же: выпадающий список с 60 пунктами излишний.
Я бы предпочел вводить время "вручную", при условии, что эти поля ввода будут достаточно интеллектуальными (скажем, они должны быть в состоянии преобразовать 18 в 1800, 0 в 0000, разрешать : в качестве разделителя и т. д.). Плюс не позволяйте пользователям вводить неверные данные в первую очередь.
Чтобы ответить на ваш вопрос: я не вижу причин запрещать вашим пользователям делать то, что они хотят. Ведь они пользователи.
Боже мой
Мой совет - выйти и найти другой проект.
Мы сделали приложение для "военного клиента", и даже они не могли договориться о том, что представляет собой "военное время". Половина из них хотела что-то под названием "Время Зулу", а другая половина - "GMT плюс смещение" - тогда некоторые хотели местное время в 24-часовом формате. Вопреки тому, что указано в нашем контракте, полковник настоял, чтобы мы использовали "Зулу" - мы внесли изменения по политическим причинам (в нарушение нашего контракта) - а затем он пропустил показ на запланированном мероприятии, потому что он думал, что это было по местному времени, Тогда управление контрактами обрушилось на нас, как тонна кирпичей.
(не говоря уже о том, что в опубликованном графике также использовалось устаревшее "смещение", которое было пережитком холодной войны, означавшим "одурачить русских").
В этом только я рассказываю историю войны.,,
Реальный ответ на это, чтобы определить требования от вашего клиента. Получите эти требования, специально записанные в вашем контракте. Убедитесь, что заинтересованный участник, который фактически выписывает ваш чек, согласен. Разработайте точно по этой спецификации. Когда кто-то жалуется, скажите им, чтобы заплатить за контракт мод. Вероятно, вы будете менять это в разных настройках в течение следующих 10 лет. У вас будет стабильная работа, и вы поймете, почему военные контракты часто выходят за рамки бюджета и никогда не идут по графику.
"Они никоим образом не связаны с военными".
Это достаточно хорошая причина для меня. Это необычный формат, который, хотя и не является "враждебным по отношению к пользователю", тем не менее, большинство из нас не привыкли видеть даты, и требование, чтобы ваши пользователи выполняли преобразование в своей голове, в конечном итоге приведет к арифметическим ошибкам.
Тем не менее, выпадающие окна тоже не очень хороши. На мой взгляд, лучше всего использовать 2 поля ввода и раскрывающийся список AM/PM.
Это не может быть плохой идеей. Представьте себе случай, когда пользователи должны вводить этот бит информации много раз, например, потому что они поддерживают вызов. Или же они могут найти выпадающие окна недостаточно полезными даже после того, как попробовали их. Они могут предпочесть этот другой формат.
Обычно хорошей идеей является поговорить с заинтересованным лицом и спросить его: "Почему вы хотите так?" затем вы можете сопоставить их идеи с вашими, но если у вас есть только то, что у вас есть "внутреннее" чувство, что это неправильно, угадайте, кто победит в споре. Чувство интуиции не является действительным деловым аргументом - особенно, когда бизнес не ваш.
Короче говоря, делайте то, что хочет ваш клиент - просто убедитесь, что он хорошо понимает свои варианты, и укажите им на любые неудобства, которые они могли предвидеть, - как только вы найдете один, то есть.
Хммм, описание 24-часовых часов как "военного времени", а затем замечание, что пользователи не военные, делает меня более чем немного раздражительным.
Это будет зависеть от ваших пользователей, но я думаю, что более чем разумно ожидать, что люди в современном обществе поймут 24-часовой формат времени и смогут вводить время, используя этот формат (учитывая, что я - возможно, наивно - ожидал бы этот формат почти универсально использоваться для автобусов, поездов, самолетов и других расписаний по той простой причине, что это однозначно). Возможно, это не так во всем мире, но это, безусловно, верно для всей Европы.
Тем не менее, изменения должны быть сделаны по причине - "если это не сломано..." - очень разумный принцип для рабочего сайта, и хотя я никогда не буду охотно использовать am / pm для ввода времени, я не У него нет проблем с использованием раскрывающихся списков для ввода времени - тем более, что их можно вводить "в". В этом случае я думаю, что переход от выпадающих списков к текстовым полям - это, скорее всего, возможность внести ошибки (хотя, опять же, это скорее зависит от пользователей).
Честно говоря, я думаю, что использование формата AM/PM - плохая практика, но это может быть потому, что я привык к 24-часовой шкале.
Одна из причин этого заключается в том, что если все ваши пользователи привыкли к шкале 12 ч, то большинство из них все равно могут ввести 1:00 вместо 13:00 для 1:00. Так как премьер-министра здесь нет, это приведет к ошибкам.
Тем не менее, одна из веских причин сделать это просто потому, что это международный стандарт.
В зависимости от того, что вы хотите сделать акцент (скорость или функциональность), вы можете использовать средство выбора времени, которое будет полагаться на региональные настройки, чтобы отобразить время в пользовательском формате или использовать элемент управления, подобный часам. Если скорость важна, вы можете предпочесть простую маску-текстовое поле.
Мало кто за пределами США знает слова "военное время". Они также предпочитают 24-часовой формат.
Если вы хотите глобализации, вы можете сделать одно из двух:
- использовать принятые и де-факто стандарты, такие как формат даты ISO8601, время 24 часа и говорить по-английски
- Погрузитесь в кошмар огромной региональной сложности локализации (некоторые неудачливые программисты должны делать это в любом случае. Затем они поддерживают AM/PM, Unicode и никогда не показывающие желтый цвет для определенных культур)
Я не могу поверить, сколько внимания получила эта идея. Заставлять вашего пользователя делать все по-своему, потому что это "более эффективно" - ужасная идея.
Ваши формы должны быть как упрощенными (опытные пользователи могут быстро вводить данные с клавиатуры), так и понятными (впервые пользователи могут успешно перемещаться). Преобразование в 24-часовое время бросит людей немедленно. Я жил в Квебеке почти шесть лет, и у меня по-прежнему были проблемы с переключением туда и обратно с 24 часов. НЕ ДЕЛАЙТЕ ЭТОГО.
В своих собственных рамках я принимаю время и даты в самых разных форматах. Когда поле теряет фокус, я попытаюсь разобрать ввод и отформатировать его в "правильный" или "официальный" формат. Это дает пользователю хороший способ ввода данных и визуальную подсказку, когда что-то не так.
Например, в поле даты я приму "1" как "01.12.2009" (текущий месяц + год). Во временном интервале я приму "1030", "10 30", "10.30" (т.е. я просто отфильтрую все, что не является числом). "010409 1125" становится 1. апреля 2009 г., 11:25.
Просто в дополнение ко всем остальным комментариям следует упомянуть еще одну вещь.
Программисты и дизайнеры обычно думают, что клиент платит нам только за то, что он нам говорит... Это только наполовину правда. Они платят нам, даже если они этого не понимают, за то, что они говорят им, что им нужно, что лучше для них.
Конечно, окончательное решение всегда остается за ними, как за вознаграждение, но если вы чувствуете, что это неправильно, и думаете, что знаете бизнес-модель лучше, чем они, то не принимайте вслепую того, что они сказали вам делать.
Я понимаю, почему вы думаете, что это плохая идея, глупые пользователи вводят неверный формат и т. Д.
Однако рассматривали ли вы поле ввода jQuery Masked?
Почему бы не использовать какой-либо элемент управления TimePicker?
Не следует заставлять невоенных пользователей использовать странный для них формат времени.
Ввод даты / времени через поля выбора - ужасный дизайн пользовательского интерфейса.
но, если некоторые из ваших пользователей приехали из нескольких стран, которые придерживаются формата AM/PM для формата времени, то навязывание им "военного" формата без помощи программы также плохо. используйте что-то вроде плагина ввода с маской jQuery.
если бы я делал это, я использовал бы ввод маскированного текста и флажок "PM": если значение больше 1259, флажок отключен. в противном случае это понятно по умолчанию.
В любом случае, предполагая, что весь ввод осуществляется зарегистрированными пользователями, вы можете предоставить несколько механизмов (и, конечно, несколько способов отображения времени) и сделать выбор предпочтением пользователя. Но я настоятельно рекомендую, чтобы что бы вы ни делали, для любого данного времени пользователя следует вводить и отображать в согласованном порядке.
Возможно, вы захотите использовать jQuery timepicker (или Telerik DateTimePicker в режиме Time-only для WinForms), а также встроенную поддержку на внутреннем интерфейсе для нескольких форматов в случае отключения javascript.