Почему я не должен просить своих пользователей вводить время, используя военный формат

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

О боже.

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

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

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

В том смысле, что это я рассказываю историю войны. , ,

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

«Они никоим образом не связаны с военными».

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

Answer 8

Просто в дополнение ко всем остальным комментариям следует упомянуть еще одну вещь.

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

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

Answer 9

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

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

Answer 10

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

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

• использовать принятые и де-факто стандарты, такие как формат даты ISO8601, время 24 часа и говорить по-английски
• погрузитесь в кошмар огромной региональной сложности локализации (некоторым неудачным программистам придется делать это в любом случае. Затем они поддерживают AM / PM, Unicode и никогда не показывающий желтый цвет для определенных культур)