it-swarm-eu.dev

DD / MM / RRRR - vědí lidé, co to znamená?

Právě jsem dokončil čtení Forms that Work Caroline Jarrett a Gerry Gaffneyho a všiml jsem si, že zatímco vydavatel použil snímek obrazovky na přední obálce s tímto formátem data, autoři se ve skutečnosti nedořešili problému DD/MM/YYYY v knize ... což vyvolalo diskusi o tom, když jsme knihu zkontrolovali na začátku tohoto týdne v knihkupectví UX.

Vyzkoušel někdo použití řetězce formátu DD/MM/RRRR, aby uživatelům sdělil, jak zadat datum do jednoho nebo dokonce trojitého textového pole? Nebo jste zjistili, že je jednodušší poskytnout rozbalovací seznamy roků a měsíců?

A co formuláře s podrobnostmi o kreditní kartě, kde se vstupní formát musí shodovat s kartou, takže musíte použít numerická data ve formátu MM/RR?

Jaké jsou některé alternativy, které umožňují rychlé zadávání data pomocí textových polí a také zajišťují správné pořadí?

30
Nathanael Boehm

William Hudson tento problém prošetřil v loňském roce. Prováděl průzkum téměř 1 000 lidí a ptal se jich jednoduše, jak napíšou dané datum („druhým srpnem letošního roku“ bylo, jak bylo uvedeno). Jejich odpověď byla zapsána do textového pole ve volném formátu. Respondenti byli poté vyzváni, aby si vybrali nejbližší „šablonu“ ze seznamu 32 - z nichž polovina byla v pořadí den/měsíc/rok a druhá polovina měsíce/den/rok („jiná“ byla poslední možnost).

Lidé používali širokou škálu formátů data. Účastníci, kteří používali řazení měsíc/den/rok, měli o něco silnější preference pro čistě numerické datum bez úvodních nul v měsíci nebo dni (8./2/09) ), ale druhý druhý použil celý měsíc (2. srpna 2009). Tyto dvě kategorie představovaly 53% této skupiny.

19
David Travis

Dobře - ze zkušenosti vím, že lidé z USA často mylně označují „DD/MM/RRRR“, protože jsou zvyklí „MM/DD/RRRR“. U webu, který oslovil britské a americké publikum, jsme zjistili, že máme nižší chybovost s „RRRR/MM/DD“ :-)

Pokud jde o alternativy, které umožňují rychlé zadávání textu - možná budete chtít podívejte se na způsoby, jak zadat data na nationalrail.co.uk , která má několik možností.

10
adrianh

Požadovat, aby uživatel zadával informace do textového pole zdarma ve formátu, který jste definovali, není vůbec dobrý.

Myslím, že výběr data (kalendář), více výběrových polí (s Janem, únorem atd. - jasně ukazuje, které pole je pro co), nebo vysoce inteligentní forma volného textu je mnohem lepší. Domnívám se však, že většina lidí by se musela zastavit a myslet, nebýt zvyklá na systém, který by pochopil věci jako „zítra“, což by vytvořilo jasnější uživatelské rozhraní jako první, které jsem navrhl lépe.

8
Jacob R

Stejně jako pozadí, existuje i mezinárodní standard (ISO) pro formát data:

Je to RRRR-MM-DD

http://www.w3.org/QA/Tips/iso-date

Je to vlastně docela složité, pokud jde o to, která země používá jaký formát - a je zde docela pěkný průvodce Wikipedie (platí běžné rezervace Wikipedie ...)

http://en.wikipedia.org/wiki/Calendar_date#List_of_the_world_locations_by_date_format_in_use

7
PhillipW

Zda uživatelé pochopí výzvu DD/MM/RRRR, bude samozřejmě záviset na publiku. Pro lidi, kteří tráví čas na jiných webech nebo obecně používají aplikace, se domnívám, že je to ve většině komunit docela dobře známé.

Rád podporuji volný vstup do systému, který je dostatečně inteligentní, aby zjistil, co tím myslíte. Kalendář Google tedy chápe „zítra“ a podle toho analyzuje a zachází 10. a 3. března jako 10. března (i když to samozřejmě závisí na místním prostředí).

Pro vypršení platnosti kreditní karty musí být upřednostňovaným formátem nic jiného než ten, který vás nutí vybrat si měsíc podle jména (protože to nutí uživatele „překládat“ z číselného měsíce vytištěného na kartě do kalendářního měsíce)!

5
gerry gaffney

Někteří lidé nemusí rozumět „dd/mm/rrrr“. Jasně řečeno, použijte prostou angličtin (den/měsíc/rok) a veďte jednoznačný příklad jako 30. 4. 2010. Zde je příklad.

 ________ 
Datum | ________ | den/měsíc/rok - například 30.5.2010
4
Bennett McElwee

Toto je standardní německý formát data. V němčině bych však očekával lokalizovaný řetězec „TT/MM/JJJJ“ :)

3
Brian

Pro Evropany DD/MM/RRRR pravděpodobně funguje dobře, i když bych přidal vzorové datum. Takže by to něco vypadalo takto (není jisté, zda formátování vyjde):

[..] [..] [....]

DD/MM/RRRR (např. 25/05/2010)

(Jak vidíte, jedna ošidná věc je, zda je požadováno vedení „0“ za prvních 9 měsíců nebo ne)

Použití výběr data funguje pouze pro blízká data (buď v blízkosti aktuálního data, nebo jiného známého data). Takže v nadcházejícím měsíci skvěle pracují na schůzkách, ale ne na narozeniny nebo jiná náhodná data.

Pro data vypršení platnosti kreditní karty bych použil dvě rozbalovací nabídky pro měsíce (1-12) a rok (běžný rok + dalších 5?).

2
Peter Boersma

Nikdy nebyl skutečný problém s DD/MM/RRRR - pro australské nebo novozélandské publikum. Zdá se, že většina lidí dostane to, co to znamená.

Narazili na funkční specifikaci, kde však klient chtěl DD/MM/CCYY.

To od mě dostalo červenou vlajku a byt "Ne". :)

2
Nathan-W

Pozice swapování vstupů pro měsíc a den se jeví jako nejproblematičtější.

Záleží na tom, odkud pochází většina vašich uživatelů. V USA je to striktně MM/DD/RRRR, opak oproti většině ostatních zemí a většina z těchto uživatelů vstoupí nebo vybere den následovaný měsícem. Je to vždy bolest, když se snažíte zjistit, jestli je to 7. března nebo 3. července, stejně jako přepnutí z jízdy vlevo na jízdu vpravo. Pokud neoddělujete uživatele podle místa, mělo by fungovat DD/MM/RRRR (od nejnižší k největší hodnotě) a povolit pouze 1 až 12 v zadání měsíce. Až na 7/3!

0
Ling

DD/MM/RRRR znamená samozřejmě „Dam * You“ - možná v mysli uživatele ;-)

Vážné však v průběhu let vyvíjejících se aplikace, které dostanou data - pokud jsou zadány ručně, vždy se stanou problémem, bez ohledu na to, co děláte. Existuje jen příliš mnoho způsobů, jak vymyslet data, ale také je napsat. Formát se v jednotlivých zemích liší a tak dále.

Datumová pole IMO musí být chráněna před dětmi nabídkou rozbalovacích nabídek - jedno pro rok, jedno pro měsíc a jedno pro den - nebo kalendář pro výběr data z mřížky.

Nikdy nenechte žádný uživatel zadat datum ručně!

0
epistemex