Q

¿Por qué no debo pedir a mis usuarios que ingresen las horas usando el formato militar

2009-12-21 8 views 5 likes

5

Tengo un formulario que solicita a los usuarios ingresar una hora de inicio y finalización para un evento. Durante muchos años, les hemos permitido ingresar a los horarios seleccionando la hora (1-12), los minutos (1-60) y AM/PM de tres cuadros desplegables. Esto ha funcionado bien sin quejas de los clientes. Sin embargo, hoy recibí una solicitud para cambiar la entrada a un cuadro de texto para que el usuario ingrese la hora en tiempo militar (también conocido como 0000 - 2359). En mi instinto, creo que esta es una mala idea, pero tengo problemas para encontrar hechos concretos.¿Por qué no debo pedir a mis usuarios que ingresen las horas usando el formato militar

¿Cuáles son las mejores razones que puedo dar para que esto sea una mala idea?

Si hay una mejor solución para ingresar el tiempo, ¿cuál sería?

Además, para su información, los usuarios que completen el formulario abarcan toda la gama desde muy poca habilidad con computadoras hasta usuarios avanzados. No están de ninguna manera relacionados con el ejército.

Actualización: Todos mis usuarios son locales y ninguna otra forma (web o impresa) utiliza el tiempo militar como estándar.

2009-12-21 Jason

A

Respuesta

4

Pues bien, desde el punto de vista de interfaz de usuario, esto podría ser un error simplemente de acuerdo con algunos de Jakob Nielsen's user interface heuristics: "Partido entre el sistema y el mundo real"

Si sus usuarios no están acostumbrados a ingresar fechas en tiempo militar, pedirles que lo hagan para su aplicación puede ser una distracción en el mejor de los casos, y frustrante en el mejor de los casos.

"Prevención de errores" No está eliminando las condiciones propensas a errores, pero posiblemente las está introduciendo.

También está la cuestión de por qué se está realizando este cambio. ¿Los clientes se están quejando? ¿Los datos están ingresando incorrectamente? Como lo mencionaron otros, ¿sus usuarios están acostumbrados al tiempo militar? Cualquier cambio de interfaz debería ocurrir por una razón, IMO, porque vas a cambiar la experiencia del usuario y habrá ramificaciones para eso; solo es cuestión de qué tan grandes serán esas ramificaciones. Mi suposición es que supuestamente se evitarán los errores de entrada de datos, pero ¿lo son? Pedirle a un usuario que ingrese una hora como "XX: XX" y analizar el punto y coma (o, como dijo Aaron Digulla, CUALQUIER carácter no numérico) y luego convertirlo según sea necesario parece menos probable que genere errores que pedirle a un usuario que ingrese una hora en un formato que no están acostumbrados a usar diariamente.

Mi preocupación sería que un usuario quiere entrar en 3:30 PM , y, aunque no prestar mucha atención, simplemente entra en 330. Esto es ahora 03:30 AM , y el usuario nunca sabrá la diferencia, porque la aplicación toma la información y felizmente asume que esto es lo que significa.Sin embargo, permitir que el usuario ingrese la hora en formato "XX: XX" y tener una selección "AM/PM" tiene mucho más sentido.

En cuanto a hechos concretos, bueno, tampoco los tengo. Pero si su jefe/cliente no se deje influir por la heurística de Nielsen, no estoy seguro de qué puede cambiar su opinión.

2009-12-21 17:16:38

16

Tres listas desplegables son una pesadilla usabilidad sabio. Puede reducirlos a dos eliminando AM/PM y cambiando al formato de 24 horas, pero aún así: un menú desplegable con 60 elementos es excesivo.

me gustaría mucho prefieren entrar en el tiempo "manualmente", a condición de que estos cuadros de entrada serán lo suficientemente inteligente (por ejemplo, que debe ser capaz de convertir a 181800, 0 a 0000, permitirá : como separador, etc.) Además, no permite que los usuarios ingresen datos incorrectos en primer lugar.

Para responder a su pregunta: No veo ninguna razón para no permitir que sus usuarios hagan lo que quieran. Después de todo, ellos son usuarios.

2009-12-21 17:02:11

+5

+1: los menús desplegables son horribles. Piénselo desde la perspectiva del usuario; no piensan en el tiempo en los desplegables, lo consideran como "6:30" y es mucho mejor para ellos poder escribir esto en una caja. Tienes que validar la fecha en el servidor * de todos modos * para que los envíos basura no sean una razón para hacer esto; verifique el valor cuando el campo pierda el foco y presente una advertencia si es ininteligible. –

+0

¿No puede su formulario leer un campo de tiempo y usar el hecho de que un tiempo ingresado es> "1200" y <= "2400", luego configure el AM/PM en consecuencia? Múltiples cajas separadas es una interfaz horrible para la entrada de tiempo. Usted * podría * tener un selector "Usar entrada de 24 horas" en alguna parte. – DaveE

1

puedo ver por qué cree que esto es una mala idea, tonto usuarios de entrada de formato incorrecto etc.

Sin embargo se han considerado un jQuery Masked input box?

2009-12-21 17:02:30 Rippo

+0

JQuery no funciona en WPF, Win-Forms, etc. OP no especifica su medio. –

+2

Es cierto. Pero una caja de entrada enmascarada sigue siendo una buena solución para cualquier GUI que esté usando. – Rippo

+0

Tiendo a encontrar cajas de entrada enmascaradas que son horribles de navegar ... demasiado entrenadas posiblemente (-: – Murph

3

"No están de ninguna manera relacionadas con el ejército".

Esa es una buena razón para mí. Es un formato poco común que, aunque no es exactamente "hostil al usuario", no es la forma en que la mayoría de nosotros estamos acostumbrados a ver las fechas, y exigir a los usuarios que hagan la conversión en su cabeza dará lugar a errores aritméticos con el tiempo.

Dicho esto, los cuadros desplegables tampoco son geniales. Lo mejor es ir con 2 cuadros de entrada y un menú desplegable AM / PM, en mi opinión.

2009-12-21 17:03:38 Reynolds

+1

"Es un formato poco común": es muy cómodo de escribir, ya que no tiene que cazar los dos puntos entre HH y MM .si el programa no es lo suficientemente inteligente como para reconocer que 1130 es 11:30, o que 130 es 01:30, entonces es simplemente tonto. –

+3

Poco común en los Estados Unidos, tal vez, pero muy común en Europa. ¿Están todos los usuarios locales? ? – Useless

+3

Sin embargo, depende del país: los EE. UU., Canadá y Australia están fuera de lugar por el gran uso de 12 horas de comunicación oral y escrita, y EE. UU. Se destaca aún más ya que el tiempo de 12 horas incluso se utiliza en plazos áreas como la programación (el ejército de los Estados Unidos es la única excepción notable). La mayoría del resto del mundo utiliza un reloj de 24 horas para todo, o muy a menudo, un reloj de 24 horas para uso escrito y formal, y un reloj de 12 horas para una conversación informal. – David

2

Sinceramente, creo que usar el formato AM/PM es una mala práctica, pero puede ser porque estoy acostumbrado a la escala de 24 horas.

Una razón en contra es que si todos los usuarios están acostumbrados a la escala 12H, la mayoría de ellos aún podría ingresar a la 1:00 en lugar de a las 13:00 para la 1:00. Como el PM no está aquí, dará lugar a errores.

Sin embargo, una buena razón para hacer el cambio es simplemente porque es el estándar internacional.

Dependiendo de lo que desee poner énfasis (velocidad o funcionalidad), puede usar un selector de tiempo que dependería de la configuración regional para mostrar el tiempo en el formato de usuario o usar un control tipo reloj. Si la velocidad es importante, es posible que prefiera un cuadro de texto de máscara simple.

2009-12-21 17:03:53

+0

"una buena razón para hacer el cambio es simplemente porque es el estándar internacional" ... también lo es el sistema métrico y todos sabemos cuán preparada está la gente para adaptarse a ese. –

+0

Estoy de acuerdo contigo, pero los cambios en algún momento también son necesarios. El sistema métrico no es tan malo, mucho, mucho más fácil de usar :) –

+0

Incluso podría agregar, si los usuarios son de diferentes lugares con diferente estándar, usar el más popular suele ser una buena idea. –

3

Puede que no sea una mala idea. Imagine el caso en el que los usuarios deben ingresar ese bit de información muchas veces, por ejemplo porque están en soporte de llamadas. O pueden encontrar que las cajas desplegables no son lo suficientemente útiles, incluso después de haberlas probado. Ellos pueden preferir ese otro formato.

Por lo general, es una buena idea hablar a la parte interesada y preguntarle: "¿Por qué lo quieres de esta manera?" entonces puedes contrastar sus ideas con las tuyas, pero si las tuyas son solo porque tienes la sensación "instintiva" de que esto no está bien, adivina quién ganará la discusión. El presentimiento no es un argumento comercial válido, especialmente cuando el negocio no es tuyo.

En resumen, haga lo que quiera su cliente, solo asegúrese de que comprenda bien sus opciones y señale los inconvenientes que pueda haber previsto, una vez que encuentre uno.

2009-12-21 17:04:34

+1

+1: ocasionalmente he encontrado estudios de usabilidad en los que se centraron en ese problema específico. Si se usa con la suficiente frecuencia, la facilidad de uso prevalece sobre la facilidad de aprendizaje. Dicho todo esto, creo que usar 3 cuadros desplegables no es tan lento si los usuarios interactúan con los cuadros desplegables mediante la tecla de tabulación y el teclado numérico. – Brian

0

Es posible que desee considerar el uso de jQuery timepicker (o Telerik DateTimePicker en modo de solo tiempo para WinForms) y también compilar compatibilidad, en el backend, para múltiples formatos en caso de que javascript esté deshabilitado.

2009-12-21 17:05:01 tvanfosson

1

En mis propios cuadros, acepto horarios y fechas en una amplia variedad de formatos. Cuando el campo pierda el foco, intentaré analizar la entrada y formatearla en el formato "correcto" u "oficial". Esto le da al usuario una buena forma de ingresar los datos y una señal visual cuando algo está mal.

Por ejemplo, en un campo de fecha, aceptaré "1" como "01.12.2009" (mes actual + año). En un cuadro de tiempo, aceptaré "1030", "10 30", "10.30" (es decir, simplemente filtraré cualquier cosa que no sea un número). "010409 1125" pasa a ser 1. abril de 2009, 11:25 a.m.

2009-12-21 17:07:50

0

entrada de fecha/hora a través de cuadros de selección es un diseño de interfaz de usuario horrible.

pero, si algunos de sus usuarios provienen de los pocos países que se adhieren a AM/PM para formato de hora, entonces forzar el formato "militar" en ellos sin ayuda del programa también es malo. utiliza algo como el jQuery masked input plugin.

si estuviera haciendo esto, usaría una entrada de texto enmascarado y una casilla de verificación "PM": si el valor es más de 1259, la casilla de verificación está deshabilitada. de lo contrario, está claro por defecto.

2009-12-21 17:18:04

2

Hmmm, describir el reloj de 24 horas como "hora militar" y luego señalar que los usuarios no son militares me da un poco más de nerviosismo.

Depende de sus usuarios, pero creo que es más que razonable esperar que la gente de la sociedad contemporánea comprenda el formato de las 24 horas y pueda ingresar las horas utilizando ese formato (dado que lo haría, posiblemente ingenuamente - se espera que el formato esté en uso para autobuses, trenes, aviones y otras tablas de horarios casi universalmente por la sencilla razón de que no es ambiguo). Tal vez esto no sea cierto en todo el mundo, pero es cierto en toda Europa.

Dicho esto, los cambios deben realizarse por una razón: "si no está roto ..." es una máxima muy buena para un sitio de trabajo y mientras que yo nunca usaría voluntariamente am/pm por tiempo entrada No tengo ningún problema con el uso de listas desplegables para la entrada de tiempo, especialmente cuando uno puede escribir "en" ellos. En este caso, creo que pasar de los menús desplegables a los cuadros de texto probablemente sea una oportunidad para introducir errores (aunque nuevamente depende de los usuarios).

2009-12-21 17:31:13 Murph

1

Pocos fuera de los Estados Unidos conocen las palabras "tiempo militar". También prefieren el formato de 24 horas.

Si desea globalización, que puede hacer uno de los dos:

uso aceptado y de-facto estándares, tales como formato de fecha ISO8601, el tiempo de 24h y hablar Inglés
sumergirse en la pesadilla de la gran complejidad basada en la regional de localización (algunos programadores desafortunados tienen que hacerlo de todos modos. Luego apoyar AM/PM, unicode y nunca mostrando-amarillo-color para ciertas culturas)

2009-12-21 17:38:24

+0

¿Qué culturas no les gusta mirar amarillas? No pude encontrar nada como esto debajo de "amarillo" en wikipedia. –

+0

Estoy intrigado también. Nunca escuché ningún sentimiento anti-amarillo específico de la cultura. Tiendo a alejarme de esto porque es difícil de leer en la mayoría de los fondos, pero ahora tengo curiosidad, a menos que sea solo un ejemplo gracioso. –

+2

Lo traje del curso de localización de .NET de Microsoft que una vez visité. La declaración exacta era la siguiente: "en algunas culturas, amarillo significa amor y prosperidad, y en otros significa viceversa, y debes saber cómo localizar correctamente". La última vez que traté de estudiar chino mandarín, me explicaron los significados de los colores y por qué nunca deberías traer un regalo verde a un amigo o significaría que estás interesado en una aventura amorosa con su esposa. Esto fue sobre el momento en que me rendí. –

0

por qué no utilizar un control TimePicker de ¿algún tipo?

No debe forzar a los usuarios no militares a utilizar un formato de tiempo extraño para ellos.

2009-12-21 17:40:44

1

No puedo creer la cantidad de consideración que ha tenido esta idea. Obligar a su usuario a hacer las cosas a su manera, porque es "más eficiente" es una idea terrible.

Sus formularios deben ser simplificados (los usuarios avanzados pueden ingresar datos rápidamente desde el teclado) y ser comprensibles (los usuarios primerizos pueden navegar con éxito). La conversión a 24 horas hará que la gente se mueva de inmediato. Viví en Quebec durante casi seis años y todavía tenía problemas para cambiar de 24 horas. NO HAGAS ESTO.

2009-12-21 17:40:45

1

Simplemente, además del resto de los comentarios, debería pensar en una cosa más.

Los programadores y diseñadores suelen pensar que el cliente nos paga solo por crear lo que nos dice ... Eso es solo una verdad a medias. Nos pagan, incluso si no se dan cuenta, por decirles lo que necesitan, lo que es mejor para ellos.

Por supuesto, la decisión final es siempre suya, como el pago, pero si siente que está mal y cree que conoce el modelo de negocio mejor que ellos, entonces no acepte ciegamente lo que le dijeron que hiciera.

2009-12-21 17:45:03

4

Oh mi.

Mi consejo es dejar de fumar y encontrar un proyecto diferente.

Hicimos una aplicación de programación para un "cliente militar", e incluso ellos no pudieron ponerse de acuerdo sobre lo que constituía "tiempo militar". La mitad de ellos quería algo llamado "Zulu Time" - la otra mitad quería "GMT plus offset" - luego quería la hora local en formato 24h. Al contrario de lo que especificaba nuestro contrato, un Coronel insistió en que usáramos "Zulú" - hicimos el cambio por razones políticas (en violación de nuestro contrato) - y luego él se perdió de asistir a un evento programado, porque pensó que era hora local . Entonces la gerencia del contrato cayó sobre nosotros como una tonelada de ladrillos.

(no importa que el cronograma publicado también utilizara un "desplazamiento" obsoleto que era un remanente de guerra fría destinado a "engañar a los rusos").

En que esto es solo yo compartiendo una historia de guerra. . .

La verdadera respuesta es obtener los requisitos de su cliente. Obtenga esos requisitos ESPECÍFICAMENTE escritos en su contrato. Asegúrese de que la parte interesada que está escribiendo su cheque esté de acuerdo. Desarrolla a esa especificación exactamente. Cuando alguien se queja, dígales que paguen un contrato mod. Probablemente esté cambiando esto de ida y vuelta entre muchas configuraciones diferentes durante los próximos 10 años. Tendrás un trabajo estable y comprenderás por qué los contratos militares a menudo superan el presupuesto y nunca se cumplen a tiempo.

2009-12-21 18:07:01 NDP

+2

+1 por la historia de guerra increíble. –

0

En cualquier caso, suponiendo que todas las entradas son por usuarios registrados, puede proporcionar varios mecanismos (y ciertamente múltiples formas si muestra tiempo) y hacer la elección una preferencia del usuario. Pero recomiendo encarecidamente que haga lo que haga, para cualquier hora de usuario dada, debe ingresarse y mostrarse de manera consistente.

2009-12-21 19:04:20

Cuestiones relacionadas