Nosotros en la banca electrónica de Caja de Avila<http://www.cajadeavila.es/> hemos optado por la solución intermedia. Tenemos los combos para dia mes y año seleccionables y al lado el calendario por si el usuario no sabe la fecha exacta, pero no es necesario que utilicen el calendario si se saben las fechas ya que los combos también son utilizables de manera directa. Lo más trabajoso es implementar los scripts de control de fechas válidas y demás validaciones, pero hay que codificarlo igualmente aunque no se pongan los calendarios. El calendario simplemente es una ayuda más. Un saludo
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<http://www.factoriadeinternet.com/> Nuestras Webs: http://www.WebTaller.com <http://www.webtaller.com/> http://www.Todo-Photoshop.com <http://www.todo-photoshop.com/> http://www.Todo-Dreamweaver.com <http://www.todo-dreamweaver.com/> http://www.I-Cursos.com <http://www.i-cursos.com/> http://www.Seo-Google.com <http://www.seo-google.com/> http://www.SoyLaLeche.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
-- Daniel Moya Jiménez
combofechas.gif
Description: GIF image
_______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
