Qué alquien me explique la necesidad de obligar al usuario a meter dos caracteres obligatoriamente para el mes y el día. Si usas máscaras del tipo dd-mm-aaaa le estás diciendo al usuario que meta 08 en vez de 8 para Agosto.
Ya que te hay que parsear los datos de todos modos yo me inclinaría por 3 cajas de texto para tener los datos facilmente. Además metería un control que haga saltar automaticamente el cursor de un campo al siguiente cuando se rellene el primero. Es algo muy sencillo que agiliza mucho la introducción de fechas, pero que solo tiene sentido si es una aplicacion web en la que se introduzcan muchas fechas, si es para una web con un buscador, metería un calendario que es lo más intuitivo. On 6/7/06, Maria Rosa <[EMAIL PROTECTED]> wrote: > > Sin embargo yo pienso que es más sencillo para el usuario el formato > dd/mm/yy que el de los números. > > Motivo? Si se pone en números, hace pensar. En cambio con el formato > dd/mm/yy es intuitivo. > > Y una de las reglas de usabilidad es "No me hagas pensar." Gran libro, > por cierto. > > Un saludo, > > María Rosa > > Directora de Factoría de Internet www.FactoriaDeInternet.com > > Nuestras Webs: > http://www.WebTaller.com > http://www.Todo-Photoshop.com > http://www.Todo-Dreamweaver.com > http://www.I-Cursos.com > http://www.Seo-Google.com > http://www.SoyLaLeche.com > > > -----Mensaje original----- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre > de oscar reales > Enviado el: miércoles, 07 de junio de 2006 12:03 > Para: Lista de Cadius > Asunto: Re: [cadius] Selección de fechas... > > 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 > _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
