Este tema se trata en los siguientes documentos del W3C: http://www.w3.org/International/questions/qa-date-format http://www.w3.org/TR/NOTE-datetime
Personalmente me inclino por cualquier opción "de letras": - dd/mm/aaaa - mm/dd/yyyy - yyyy/mm/dd En cualquiera de ellas se entiende que la d es el Día o Day, la m es el Mes o Month y el grupo de cuatro letras (aaaa o yyyy) es el año. Aún si sólo se usaran dos letras para el año (aa o yy), despejadas la m y la d, la incógnita restante se hace trivial. Saludos -- _____________________ Fernando Gutiérrez http://ferguweb.tx.com.ru/ 2006/6/7, oscar reales <[EMAIL PROTECTED]>: > > En tu propia pregunta va la respuesta: > > m = mes > d = dia > y = year > > es decir, el formato con letras solo funciona bien en el idioma del > usuario, > pero lo hace incomprensible para otros usuarios. > > Sin embargo, utilizando un ejemplo real con numeros, podemos evitar esa > confusion. Como te dije antes, un ejemplo de fecha bien utilizado no puede > dar lugar a la confusión: ej. 31-08-2006, queda bien claro que 31 solo > puede > ser el dia, en cualquier idioma, ya que no existen 31 meses. Por tanto, 08 > solo puede ser el mes 8 (agosto) y asi.... > > Claro, si utilizas una fecha inadecuada como ejemplo, pues no eliminas la > confusión: 01-02-2006. Esta fecha puede ser el dia 1 de Febrero, o puede > ser > el día 2 de Enero..... asi que un mal ejemplo. > > De esta forma, con numeros, evitas el tener que "localizar" el ejemplo a > cada idioma utilizado. Utilizando letras, en español debieramos poner algo > así: dd-mm-aaaa, en ingles: mm-dd-yyyy. Es decir, variar el formato - > ejemplo en cada idioma. Con numeros, un ejemplo - formato es suficiente > para > todos ellos. > > El día 7/06/06, Gabriel Hernan Porras Rivera <[EMAIL PROTECTED]> > escribió: > > > > Que tal Oscar... > > > > Una pregunta: ¿Por qué consideras inadecuada la opción de indicar con > > letras el formato, por ejemplo (mm-dd-yyyy)? > > > > Pienso, por el contrario, que sería lo más fácil para el usuario > > hispanohablante, precisamente por la confusión entre días y meses, que > puede > > causar un ejemplo en números. > > > > Saludos! > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf > > Of Oscar Reales > > Sent: Martes, 06 de Junio de 2006 04:35 p.m. > > To: Lista de Cadius > > Subject: Re: [cadius] Selección de fechas... > > > > Mi opinión, despues de observar el comportamiento de varios usuarios y > > también teniendo en cuenta las implicaciones de desarrollo y también de > > internacionalización: > > > > Si el usuario de la "aplicación" tiene que introducir muchas fechas, la > > opción más usable (por rápida y eficaz) es establecer un formato e > indicarlo > > junto a un campo de texto en el que el usuario introduce las fechas > > manualmente. Tener que introducir varias fechas en una aplicación > utilizando > > calendarios javascript y/o "combos" es muy lento y pesado. Esta opción > la > > veo más recomendable en aplicaciones del tipo intranet, o en aquellos > casos > > donde los usuarios tienen un conocimiento de la aplicación y la utilizan > > frecuentemente. Una sola indicación, que puede parecer obvia, pero que a > > veces no se hace bien, si indicamos el formato de fecha junto al campo, > > hemos de asegurarnos que es entendible perfectamente por el usuario, y > que > > no hay lugar a la confusión entre el día y el mes. Por ejemplo, un > ejemplo > > que considero erróneo es: 01-02-1998. No queda claro que digito puede > ser el > > dia y que digito el mes. Sin embargo: 18-02-1998 no deja lugar a la > duda: el > > 18 solo puede ser un digito correspondiente al dia. Finalmente, hay > gente > > que opta por indicar con letras el formato, por ejemplo (mm-dd-yyyy). A > > todas luces esta última opción me parece inadecuada. > > > > Si queremos reducir la posibilidad de error por parte del usuario, y > sobre > > todo, si queremos facilitar la introduccion de la fecha en un sitio > > multi-idioma, veo mejor separar en 3 combos el día, el mes y el año. Si > se > > implementa bien, esta opción elimina toda confusión entre dia - mes. > > > > En los dos casos anteriores, sea cual sea el utilizado, estamos > exigiendo > > del usuario un conocimiento exacto de la fecha a introducir. ¿Pero que > > ocurre cuando el usuario no tiene más que una idea aproximada de la > fecha > > que desea introducir? En esos casos hay una neceisdad evidente de > utilizar > > un calendario. Por ejemplo, si el usuario rellena un formulario para > salir > > en un vuelo, es muy probable que tenga una idea aproximada de la fecha > en > > que volará, pero necesitará un calendario para comprobar, por ejemplo, > que > > el día 14 es Viernes, y por tanto el día en que quiere salir, y no el 13 > que > > es Jueves.... También ocurre con frecuencia que el usuario no tiene > porque > > conocer si Agosto tiene 30 ó 31 días, y por tanto, una vez más necesita > el > > apoyo de un calendario para no cometer errores. > > > > Es por esta razón por la que el "calendario" es tan útil y tan > utilizado, > > especialmente en aplicaciones donde la fecha no es conocida con > exactitud > > por el usuario. > > > > Conclusión, la que suelo utilizar como opción más completa cuando se > trata > > de una aplicación dirigida al público en general: 3 combos + calendario. > De > > esta forma cubro gran parte de los problemas de usabilidad que presentan > las > > fechas. Solo desaconsejo esta opción si hay que introducir muchas > fechas, en > > cuyo caso, el esfuerzo por adaptarse a un formato por parte del usuario, > se > > compensa con la velocidad de interacción una vez aprendido el mismo. > > > > On 6/6/06 16:59, "Gabriel Hernan Porras Rivera" < > [EMAIL PROTECTED] > > > > > wrote: > > > > > Buenos días, > > > > > > No sé si este tema se ha tratado en la lista pero quisiera saber su > > > opinión al respecto de la selección de fechas por parte de un usuario > de > > una página web. > > > > > > Una situación que se presenta constantemente en las aplicaciones web > > > que he hecho es la selección de fechas. > > > He sido de la opinión que es más usable y accesible (sin haber hecho > > > ningún tipo de pruebas con usuarios) una de estas dos opciones: > > > - Un label donde se explique el formato + una caja de texto. > > > 0 > > > - Tres combos para cada parte de la fecha: uno para día, otro para mes > > > y finalmente otro para año. > > > > > > Sin embargo los clientes nunca toman estas propuestas. Siempre > > > seleccionan los selectores de fecha en Javascript. > > > En ellos hay una caja de texto seguida de un icono, el cual crea una > > > pequeño calendario que permite al usuario la selección de la fecha. > > > Simplemente navegan en el calendario, seleccionan la fecha y el script > > > automáticamente escribe la fecha en la caja de texto. > > > > > > ¿Cuál de estas (u otras) opciones consideran la mejor desde el punto > > > de vista de usabilidad y accesibilidad? > > > > > > Gracias! > > > > > > ________________________________ > > > > > > Gabriel H. Porras R. > > > Ingeniero de Desarrollo > > > Intergrupo S.A. - Medellín > > > [EMAIL PROTECTED] > > > Blog: User Experience en Español <http://uxespanol.blogspot.com/> > > > > > > Visite nuestro sitio: www.intergrupo.com <http://www.intergrupo.com/> > > > > > > > > > > > > > > > > > > Este mensaje ( incluidos sus anexos) puede contener información > > > privilegiada y confidencial. Si usted no es el destinatario del mismo, > > > informe de ello a quien lo envía y destrúyalo. Está prohibida su > > > retención, grabación, utilización o divulgación. Este mensaje ha sido > > > verificado con software antivirus, el remitente de éste no se hace > > > responsable por la presencia de algún virus que pueda generar daños en > > > los equipos o programas. > > > > > > This message (including all attachments) may contain information that > > > is private, confidential and privileged. If you have received this > > > communication in error; please notify the sender, and delete this > > > communication. Any use, dissemination, distribution, copying or > > > disclosure of this message and any attachment is prohibited. This > > > message has been checked with antivirus software, the sender is not > > > liable for the presence of any virus in it or attachments that may > > > cause damage to the equipment or software. > > > _______________________________________________ > > > altas, bajas y modificaciones: > > > http://www.cadius.org/lista/opciones.html > > > > > > > > _______________________________________________ > > altas, bajas y modificaciones: > > http://www.cadius.org/lista/opciones.html > > > > > > > > Este mensaje ( incluidos sus anexos) puede contener información > > privilegiada y confidencial. Si usted no es el destinatario del > > mismo, informe de ello a quien lo envía y destrúyalo. Está prohibida > > su retención, grabación, utilización o divulgación. Este mensaje ha > > sido verificado con software antivirus, el remitente de éste no se > > hace responsable por la presencia de algún virus que pueda generar > > daños en los equipos o programas. > > > > This message (including all attachments) may contain information that > > is private, confidential and privileged. If you have received this > > communication in error; please notify the sender, and delete this > > communication. Any use, dissemination, distribution, copying or > > disclosure of this message and any attachment is prohibited. This > > message has been checked with antivirus software, the sender is not > > liable for the presence of any virus in it or attachments that may > > cause damage to the equipment or software. > > _______________________________________________ > > altas, bajas y modificaciones: > > http://www.cadius.org/lista/opciones.html > > > _______________________________________________ > altas, bajas y modificaciones: > http://www.cadius.org/lista/opciones.html > _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
