Perché non dovrei chiedere ai miei utenti di inserire orari utilizzando il formato militare

Question

Ho un modulo che chiede agli utenti di inserire un'ora di inizio e di fine per un evento. Per molti anni, abbiamo permesso loro di inserire i tempi selezionando l'ora (1-12), minuto (1-60) e AM/PM da tre caselle a cascata. Questo ha funzionato bene senza lamentele da parte dei clienti. Tuttavia, oggi sono stato colpito da una richiesta di modifica dell'input in una casella di testo affinché l'utente inserisse l'ora in tempo militare (ovvero 0000 - 2359). Nel mio intimo credo che questa sia una cattiva idea, ma sto avendo problemi a venire con fatti concreti.

Quali sono i migliori motivi che posso dare che questa sarebbe una cattiva idea?

Se c'è una soluzione migliore per entrare nel tempo, quale sarebbe?

Inoltre, FYI gli utenti che compila il modulo eseguono la gamma da pochissime abilità con i computer agli utenti avanzati. Non sono in alcun modo legati ai militari.

Aggiornamento: tutti i miei utenti sono locali e nessun altro modulo (Web o stampa) usa il tempo militare come standard.

Answer 1

Beh, dal punto di vista dell'interfaccia utente, questo potrebbe essere un errore semplicemente secondo alcuni dei Jakob Nielsen's user interface heuristics: "Corrispondenza tra sistema e mondo reale"

Se i tuoi utenti non sono abituati a inserire date in tempo militare, chiedere loro di farlo per la tua app può essere fonte di distrazione nella migliore delle ipotesi e frustrante nel peggiore dei casi.

"Prevenzione degli errori" Non si eliminano le condizioni soggette a errori, ma possono essere introdotte.

C'è anche la domanda sul perché questo cambiamento è stato fatto. I clienti si lamentano? I dati arrivano in modo errato? Come menzionato da altri, i tuoi utenti sono abituati al tempo militare? Qualsiasi cambiamento di interfaccia dovrebbe avvenire per un motivo, IMO, perché cambierai l'esperienza dell'utente e ci saranno conseguenze per questo; è solo una questione di quanto grandi saranno quelle ramificazioni. La mia ipotesi è che si presumibilmente si evitino errori di immissione dei dati, ma lo sono? Chiedere a un utente di inserire un tempo come "XX: XX" e analizzare il punto e virgola (o, come dichiarato da Aaron Digulla, QUALSIASI carattere non numerico) e quindi convertirlo in base alle esigenze sembra essere meno probabile che si traduca in errori rispetto a chiedere a un utente di inserisci un'ora in un formato a cui non sono abituati ad utilizzare quotidianamente.

La mia preoccupazione è che un utente vuole entrare 3:30 PM , e, pur non prestando molta attenzione, semplicemente entra 330. Questo è ora 03:30 AM , e l'utente non potrà mai conoscere il differenza, perché l'app prende le informazioni e presume felicemente che questo è ciò che si intende.Tuttavia, consentire all'utente di inserire l'ora nel formato "XX: XX" e avere una selezione "AM/PM" ha molto più senso.

Per quanto riguarda i fatti concreti, beh, non li ho neanche io. Ma se il tuo capo/cliente non sarà influenzato dall'euristica di Nielsen, non sono sicuro di cosa possa cambiare idea.

Answer 2

Tre dropdown sono un incubo usabilità-saggio. È possibile ridurli a due eliminando AM/PM e passando al formato 24 ore, ma comunque: un menu a discesa con 60 voci è eccessivo.

mi piacerebbe molto preferisce inserire tempo "manualmente", a condizione che tali caselle di input saranno abbastanza intelligenti (ad esempio, dovrebbero essere in grado di convertire 18 a 1800, 0-0000, consentire : come separatore, ecc). Inoltre, non consentire agli utenti di inserire dati errati in primo luogo.

Per rispondere alla tua domanda: non vedo alcun motivo per impedire agli utenti di fare ciò che vogliono. Dopo tutto, sono utenti.

Answer 3

Posso capire perché si pensa che questo è una cattiva idea, gli utenti sciocca ingresso formato sbagliato ecc

Tuttavia avete considerato un jQuery Masked input box?

Answer 4

"Non sono in alcun modo correlati militari".

Questa è una ragione sufficiente per me. È un formato non comune che, sebbene non sia esattamente "utente-ostile", non è tuttavia il modo in cui la maggior parte di noi è abituato a vedere le date e richiede agli utenti di eseguire la conversione nella propria testa per portare alla fine errori aritmetici.

Detto questo, anche le caselle a discesa non sono eccezionali. La cosa migliore è andare con 2 caselle di input e un menu a discesa AM/PM, a mio parere.

Answer 5

Honnestly, penso che l'uso del formato AM/PM sia una cattiva pratica, ma potrebbe essere dovuto al fatto che sono abituato alla scala delle 24 ore.

Uno dei motivi è che se tutti gli utenti sono abituati alla scala 12H, la maggior parte di essi potrebbe comunque immettere 1:00 anziché 13:00 per 1:00. Dal momento che il PM non è qui, si tradurrà in errori.

Tuttavia, una buona ragione per fare lo switch è semplicemente perché è lo standard internazionale.

A seconda di ciò che si vuole mettere l'accento (velocità o funzionalità) è possibile utilizzare un selettore di tempo che si baserebbe su impostazioni regionali per diplay il tempo nel formato utente o utilizzare un controllo di tipo orologio. Se la velocità è importante, potresti preferire una semplice maschera-casella di testo.

Answer 6

Potrebbe non essere una cattiva idea. Immagina il caso in cui gli utenti devono inserire quel bit di informazioni un sacco di volte, ad esempio perché sono in supporto per le chiamate. Oppure potrebbero trovare le caselle a discesa non abbastanza utilizzabili, anche dopo averle provate. Potrebbero preferire quell'altro formato.

Di solito è una buona idea per parlare allo allo stakeholder e chiedergli: "Perché lo vuoi in questo modo?" puoi quindi contrastare le loro idee con le tue, ma se le tue sono solo che hai la sensazione che questo non è giusto, indovina chi vincerà la discussione. Il sentimento istintivo non è un argomento di business valido, specialmente quando il business non è il tuo.

Quindi, in breve, fai quello che vuole il tuo cliente - assicurati solo che comprendano bene le loro opzioni, e segnala loro eventuali inconvenienti che potrebbero aver previsto - una volta trovato, cioè.

Answer 7

Si potrebbe voler considerare l'utilizzo di jQuery timepicker (o Telerik DateTimePicker in modalità Time-solo per WinForms) e anche costruire in appoggio, sul backend, per più formati nel caso in cui JavaScript è disabilitato.

Answer 8

Nelle mie cornici, accetto orari e date in un'ampia varietà di formati. Quando il campo perde lo stato attivo, cercherò di analizzare l'input e formattarlo nel formato "corretto" o "ufficiale". Questo dà all'utente un buon modo per inserire i dati e un segnale visivo quando qualcosa non va.

Ad esempio, in un campo data, accetto "1" come "01.12.2009" (mese corrente + anno). In una casella di tempo, accetterò "1030", "10 30", "10.30" (ad esempio, ho solo filtrato tutto ciò che non è un numero). "010409 1125" diventa 1. Aprile 2009, 11:25.

Answer 9

immissione data/ora tramite caselle di selezione è un design dell'interfaccia utente orribile.

ma, se alcuni dei vostri utenti provengono dai pochi paesi che si attengono a AM/PM per il formato dell'ora, forzare il formato "militare" su di essi senza l'assistenza del programma è anche negativo. usa qualcosa come jQuery masked input plugin.

se lo facessi, userei un input di testo mascherato e una casella di controllo "PM": se il valore è maggiore di 1259, la casella di controllo è disabilitata. in caso contrario, è chiaro per impostazione predefinita.

Answer 10

Hmmm, descrivendo l'orologio delle 24 ore come "tempo militare" e notando che gli utenti non sono militari, mi rende un po 'più nervoso.

Dipenderà dai vostri utenti, ma penso che sia più che ragionevole aspettarsi che le persone nella società contemporanea comprendano il formato delle 24 ore e di essere in grado di inserire i tempi usando quel formato (dato che vorrei - forse ingenuamente - aspettarsi che il formato sia utilizzato per autobus, treno, aereo e altri timemtables quasi universalmente per la semplice ragione che è inequivocabile). Forse questo non è vero in tutto il mondo - ma è certamente vero in tutta Europa.

Detto questo, i cambiamenti devono essere apportati per un motivo - "se non è rotto ..." è una massima molto valida per un sito di lavoro e mentre io non userei mai volentieri am/pm per volta voce Non ho problemi con l'uso di elenchi a discesa per l'immissione del tempo, in particolare perché uno può "immettere" in "". In questo caso, penso che passare dai menu a discesa alle caselle di testo sia molto probabilmente un'opportunità per introdurre errori (anche se di nuovo dipende piuttosto dagli utenti).

Answer 11

Pochi al di fuori degli stati uniti conoscono le parole "tempo militare". Preferiscono anche il formato 24 ore.

Se si vuole la globalizzazione, si può fare uno dei due:

• uso accettato e de-facto standard, come ad esempio ISO8601 formato della data, ora 24 ore e parlare l'inglese
• tuffo nell'incubo di la stragrande localizzazione complessità regionale a base di (alcuni programmatori sfortunati hanno a che fare lo stesso. Poi sostenere AM/PM, unicode e non-mostrando giallo-colore per alcune culture)

Answer 12

perché non utilizzare un controllo TimePicker di qualche tipo?

Non si dovrebbe obbligare gli utenti non militari a utilizzare un formato orario strano.

Answer 13

Non riesco a credere a quanto sia stata presa in considerazione questa idea. Forzare il tuo utente a fare le cose a modo tuo, perché è "più efficiente" è una pessima idea.

I moduli devono essere sia semplificati (gli utenti avanzati possono immettere rapidamente i dati dalla tastiera) che comprensibili (gli utenti che navigano per la prima volta possono navigare con successo). La conversione in 24 ore getterà le persone immediatamente. Ho vissuto in Quebec per quasi sei anni e ho ancora avuto problemi a passare da 24 ore. NON FARE QUESTO.

Answer 14

Proprio in aggiunta a tutto il resto dei commenti dovresti fare una cosa in più.

I programmatori e i progettisti di solito pensano che il cliente ci paghi solo per aver creato quello che ci dice di ... Questo è vero solo per metà. Ci pagano, anche se non se ne rendono conto, per dire loro di cosa hanno bisogno, cosa è meglio per loro.

Naturalmente, la decisione finale è sempre la loro, come la paga, ma se ritieni che sia sbagliato e pensi di conoscere il modello di business meglio di loro, allora non accettare ciecamente tutto ciò che ti hanno detto di fare.

Answer 15

Oh mio.

Il mio consiglio è di uscire e trovare un progetto diverso.

Abbiamo fatto un'app di pianificazione per un "cliente militare" - e anche loro non potevano concordare su cosa costituiva il "tempo militare". La metà di loro voleva qualcosa chiamato "Zulu Time" - l'altra metà voleva "GMT plus offset" - quindi alcuni volevano l'ora locale nel formato 24 ore. Contrariamente a quanto specificato dal nostro contratto, un colonnello ha insistito sul fatto che usassimo "Zulu" - abbiamo apportato il cambiamento per motivi politici (in violazione del nostro contratto) - e poi ha mancato la presentazione per un evento programmato, perché pensava che fosse in orario locale . Poi la gestione dei contratti ci è venuta addosso come una tonnellata di mattoni.

(non importa che il programma pubblicato usasse anche un "offset" obsoleto che era un holdover della guerra fredda inteso a "ingannare i russi").

In questo sono solo io a condividere una storia di guerra. . .

La vera risposta è ai requisiti Elicit dal tuo cliente. Ottieni questi requisiti SPECIFICAMENTE scritti nel tuo contratto. Accertati che lo stakeholder che sta effettivamente scrivendo il tuo assegno sia d'accordo. Sviluppa esattamente con questa specifica. Quando qualcuno si lamenta di dire loro di pagare un contratto mod. Probabilmente cambierai avanti e indietro tra molte impostazioni diverse per i prossimi 10 anni. Avrai un lavoro costante e capirai perché i contratti militari superano spesso il budget e non sono mai in programma.

Answer 16

In ogni caso, presupponendo che tutti gli input siano effettuati dagli utenti registrati, è possibile fornire più meccanismi (e sicuramente più modi se visualizza il tempo) e rendere la scelta una preferenza dell'utente. Ma raccomando vivamente che qualunque cosa tu faccia, per ogni dato utente gli orari dovrebbero essere inseriti e visualizzati in modo coerente.