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

У меня есть форма, которая просит, чтобы пользователи ввели запуск и время окончания для события. Много лет мы позволили им вводить времена путем выбора часа (1-12), минуты (1-60), и/PM от трех выпадающих полей. Это хорошо работало без жалоб от клиентов. Однако сегодня я был поражен запросом для изменения входа на одно текстовое поле для пользователя для ввода времени в военное время (иначе 0000 - 2359). В моем пищеварительном тракте я полагаю, что это - плохая идея, но испытывает затруднения, придумывающие любые неопровержимые факты.

Каковы лучшие причины, которые я могу привести этому, это было бы плохой идеей?

Если бы существует лучшее решение для ввода времени, каково это было бы?

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

Обновление: Все мои пользователи локальны, и никакие другие формы (сеть или печать) не используют военное время в качестве стандарта.

5
задан AstroCB 15 August 2014 в 15:02
поделиться

16 ответов

Что ж, с точки зрения пользовательского интерфейса, это могло быть ошибкой просто в соответствии с некоторыми из эвристики пользовательского интерфейса Якоба Нильсена :

" Соответствие системы и реального мира ". Если ваши пользователи не привыкли вводить даты в военное время, просьба сделать это для вашего приложения может в лучшем случае отвлекать, а в худшем - разочаровывать.

«Предотвращение ошибок». Вы не устраняете условия, подверженные ошибкам, но, возможно, вводя их.

Возникает также вопрос, почему это изменение было сделано. Жалуются клиенты? Данные поступают неправильно? Как уже упоминалось другими, ваши пользователи привыкли к военному времени? Любое изменение интерфейса должно происходить по какой-то причине, ИМО, потому что вы собираетесь изменить взаимодействие с пользователем, и это будет иметь последствия; вопрос лишь в том, насколько большими будут эти разветвления. Я предполагаю, что ошибок ввода данных якобы удастся избежать - но так ли это? Просьба пользователя ввести время как «XX: XX» и разбор точки с запятой (или, как заявил Аарон Дигулла, ЛЮБЫХ нечисловых символов), а затем преобразование его по мере необходимости, с меньшей вероятностью приведет к ошибкам, чем просьба пользователя введите время в формате, который они не используют ежедневно.

Меня беспокоит, что пользователь хочет ввести 3:30 PM , и, не обращая особого внимания, просто вводит 330. Сейчас 3:30 AM , и пользователь никогда не заметит разницы, потому что приложение берет информацию и с радостью предполагает, что это именно то, что имеется в виду. Однако, позволяя пользователю вводить время в формате «XX: XX» и имея «AM / PM» выбор имеет гораздо больше смысла.

Что касается неопровержимых фактов, у меня их тоже нет. Но если ваш босс / клиент не подчинится эвристике Нильсена, я не уверен, что может изменить их мнение.

4
ответ дан 18 December 2019 в 05:21
поделиться

В моих собственных фреймах я принимаю время и дату в самых разных форматах. Когда поле теряет фокус, я попытаюсь проанализировать ввод и отформатировать его в «правильный» или «официальный» формат. Это дает пользователю удобный способ ввода данных и визуальную подсказку, когда что-то не так.

Например, в поле даты я приму «1» как «01.12.2009» (текущий месяц + год) . В поле времени я принимаю «1030», «10 30», «10.30» (т.е. я просто отфильтровываю все, что не является числом). «010409 1125» становится 1 апреля 2009 г., 11:25.

1
ответ дан 18 December 2019 в 05:21
поделиться

Вы можете рассмотреть возможность использования jQuery timepicker (или Telerik DateTimePicker в режиме только времени для WinForms), а также встроить поддержку на серверная часть для нескольких форматов в случае отключения JavaScript.

0
ответ дан 18 December 2019 в 05:21
поделиться

Я понимаю, почему вы думаете, что это плохая идея, глупые пользователи вводят неправильный формат и т. Д.

Однако вы рассматривали jQuery Маскированное поле ввода ?

1
ответ дан 18 December 2019 в 05:21
поделиться

Честно говоря, я считаю, что использование формата AM / PM - плохая практика, но это может быть потому, что я привык к 24-часовой шкале.

Одна из причин против - если все ваши пользователи привыкли к 12-часовой шкале, тогда большинство из них все равно может ввести 1:00 вместо 13:00 для 1:00. Поскольку PM здесь нет, это приведет к ошибкам.

Однако одна из веских причин для переключения - это просто потому, что это международный стандарт.

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

2
ответ дан 18 December 2019 в 05:21
поделиться

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

Обычно неплохо поговорить с заинтересованным лицом и спросить его: «Почему вам это нужно?» затем вы можете сопоставить их идеи с вашими, но если у вас есть «интуитивное» ощущение, что это неправильно, угадайте, кто выиграет спор. Интуиция не является веским аргументом в пользу бизнеса, особенно когда бизнес не ваш.

Короче говоря, делайте то, что хочет ваш клиент - просто убедитесь, что он хорошо понимает свои варианты,

3
ответ дан 18 December 2019 в 05:21
поделиться

«Они никоим образом не имеют отношения к военным»

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

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

3
ответ дан 18 December 2019 в 05:21
поделиться

Три выпадающих списка - кошмар с точки зрения удобства использования. Вы можете сократить их до двух, исключив AM / PM и перейдя к 24-часовому формату, но все же: раскрывающийся список с 60 элементами является излишним.

Я бы предпочел вводить время «вручную», при условии, что эти данные вводятся коробки будут достаточно умными (скажем, они должны уметь преобразовывать 18 в 1800 , 0 в 0000 , разрешить : как разделитель и т. Д.). Кроме того, не позволяйте пользователям вводить неверные данные.

Отвечу на ваш вопрос: я не вижу причин запрещать вашим пользователям делать то, что они хотят. В конце концов, они пользователи.

16
ответ дан 18 December 2019 в 05:21
поделиться

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

0
ответ дан 18 December 2019 в 05:21
поделиться

Почему бы не использовать какой-либо элемент управления TimePicker?

Вы не должны заставлять невоенных пользователей использовать странный для них формат времени.

0
ответ дан 18 December 2019 в 05:21
поделиться

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

но, если некоторые из ваших пользователей прибывают из нескольких стран, которые придерживаются AM / PM для формата времени, тогда принудительно «военный» формат на них без помощи программы тоже плох. используйте что-то вроде jQuery masked input plugin .

если бы я делал это, я бы использовал маскированный ввод текста и флажок «PM»: если значение больше 1259, флажок отключен . в противном случае - по умолчанию.

0
ответ дан 18 December 2019 в 05:21
поделиться

В дополнение ко всем остальным комментариям, вы должны сказать еще об одном.

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

Конечно, окончательное решение всегда остается за ними в качестве оплаты, но если вы чувствуете, что это неправильно и вы думаете, что знаете бизнес-модель лучше, чем они, тогда не принимайте слепо то, что они вам говорят.

1
ответ дан 18 December 2019 в 05:21
поделиться

Я не могу поверить, сколько внимания было уделено этой идее. Заставить пользователя делать что-то по-своему, потому что это «более эффективно» - ужасная идея.

Ваши формы должны быть как упрощенными (опытные пользователи могут быстро вводить данные с клавиатуры), так и понятными (впервые пользователи могут успешно перемещаться) . Переход на 24-часовое время сразу бросит людей. Я прожил в Квебеке почти шесть лет, и у меня все еще были проблемы с переключением с 24-часового времени. НЕ ДЕЛАЙТЕ ЭТОГО.

1
ответ дан 18 December 2019 в 05:21
поделиться

Немногие за пределами США знают слово «военное время». Также они предпочитают 24-часовой формат.

Если вы хотите глобализации, вы можете сделать одно из двух:

  • использовать принятые и фактические стандарты, такие как формат даты ISO8601, 24-часовое время и говорить по-английски
  • погрузиться в кошмар огромных региональных- основанная на сложности локализации (некоторые неудачливые программисты все равно должны это делать. Тогда они поддерживают AM / PM, unicode и никогда не показывающий желтый цвет для определенных культур)
1
ответ дан 18 December 2019 в 05:21
поделиться

Хммм, описание 24-часовых часов как «военное время», а затем указание на то, что пользователи не являются военными, заставляет меня немного нервничать.

Это будет зависеть от ваших пользователей, но Я думаю, что более чем разумно ожидать, что люди в современном обществе поймут 24-часовой формат времени и смогут вводить время, используя этот формат (учитывая, что я - возможно, наивно - ожидал, что этот формат будет использоваться для автобусов, расписания поездов, самолетов и другие расписания практически универсальны по той простой причине, что это однозначно). Возможно, это не так во всем мире - но это, безусловно, верно для всей Европы.

Тем не менее, изменения должны быть внесены по какой-то причине - «если он не сломан ...» - это очень здравый принцип для рабочего сайта и хотя я бы никогда не стал использовать am / pm для ввода времени, я не У меня есть проблема с использованием раскрывающихся списков для ввода времени - тем более, что один может ввести "в" их. В этом случае я думаю, что переход от раскрывающихся списков к текстовым полям, скорее всего, дает возможность внести ошибки (хотя, опять же, это скорее зависит от пользователей).

2
ответ дан 18 December 2019 в 05:21
поделиться

О боже.

Мой совет - выйти и найти другой проект.

Мы создали приложение для планирования для «военного заказчика» - и даже они не могли прийти к единому мнению о том, что такое «военное время». Половина из них хотела что-то под названием «Зулусское время» - другая половина хотела «GMT плюс смещение» - тогда некоторые хотели местное время в 24-часовом формате. Вопреки тому, что указано в нашем контракте, полковник настоял на том, чтобы мы использовали слово «зулу» - мы внесли изменения по политическим причинам (в нарушение нашего контракта) - а затем ОН пропустил присутствие на запланированном мероприятии, потому что он думал, что это было по местному времени . Затем управление контрактами обрушилось на нас, как тонна кирпичей.

(не говоря уже о том, что в опубликованном графике также использовалась устаревшая «компенсация», которая была пережитком времен «холодной войны», чтобы «одурачить русских»).

В этом смысле я просто рассказываю военную историю. . .

Настоящий ответ - это выяснить требования вашего клиента. Сделайте эти требования КОНКРЕТНО записанными в вашем контракте. Убедитесь, что заинтересованная сторона, выписывающая ваш чек, согласна. Развивайте именно эту спецификацию. Когда кто-то жалуется, скажите им заплатить за контрактный мод. Вы, вероятно, будете менять это взад и вперед среди множества различных настроек в течение следующих 10 лет. У вас будет стабильная работа, и вы поймете, почему военные контракты часто выходят за рамки бюджета и никогда не выходят из графика.

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

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

4
ответ дан 18 December 2019 в 05:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: