De acuerdo con la filosofia de Steve Krug "no me hagas pensar". Totalmente de acuerdo, si bien, dd/mm/yy va a hacer pensar un monton a los que no hablan ingles y desconocen que la Y viene de "Year". Puede parecer muy obvio a los ojos de nosotros, desarrolladores acostumbrados a los dos idiomas, pero no podemos generalizar que sera entendido. Numeros son numeros, y "2+2 = 4" no necesita traduccion, pero "two plus two equal four" si la necesita.
Además, el proceso mental que yo he descrito antes, ocurre muy rapidamente, es decir, la gente no se PARA a pensar a ver, esto es un día, esto es un mes.... es algo mucho más inmediato. El día 7/06/06, Maria Rosa <[EMAIL PROTECTED]> escribió: > > 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
