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
