Pues yo creo que para el caso de usuario genérico y sólo un par de fechas metería dos calendarios. Creo que es infinitamente más usable que poner cajas de texto y además elimina los posibles errores y por tanto la necesidad de validar la fecha.
On 6/7/06, Daniel Moya <[EMAIL PROTECTED]> wrote: > > Espero que no parecer pesado pero creo que el tema merece un comentario > más > extenso: > El motivo de dar varias posibilidades para hacer lo mismo es que hay > distintos tipos de usuarios y distintos "gustos". *El hecho de usar > combos*y no cajas de texto > *es para reducir la posibilidad de introducir una fecha errónea* y por > tanto > las posibilidades de que el usuario tenga que reintroducir la fecha > *varias > veces*. Si a pesar de tener una orientación u ejemplo que diga que "el > formato de fechas debe ser tal/cual/pascual", el usuario teclea > "45/12-2Oo6" > (es un ejemplo, no creo que este caso se dé a menudo), cuando reciba del > sistema un mensaje de error indicando que debe introducir una fecha > válida, > al posicionarse en el campo, debe reescribirla entera o utilizar los > cursores, borrar, reescribir etc y el resultado puede ser del tipo > "25/12/2oo6" o "45/12-2006" o "25/12-2006". *Aunque si ha recibido un > mensaje de error prestará más atención a lo que escribe, no reducimos > posibilidades de volver a cometer un error*. > Sin embargo, *si utilizamos combos* (doy por supuesto también para este > caso > que hay una o dos fechas, sino, también me inclino por el formato una sola > caja de texto), acotamos los errores. *No permitimos al usuario errar en > los > casos de mes fuera de rango* (todavía se podría introducir 31 de febrero) > y > además *damos una orientación de qué datos debe introducir* (el año minimo > es el actual, por lo que el usuario no podrá dar de alta una transferencia > periódica con fecha anterior al año actual). Además en nuestro caso las > transferencias periódicas deben producirse con fecha de primera > transferencia mayor a hoy por lógica de negocio, por lo que si ponemos en > los combos como fecha de inicio la de mañana, reducimos una vez más las > posibilidades de que alguien teclee la fecha de hoy (si lo hace recibirá > de > nuevo un mensaje de error aclarando este punto). > Por último comentar que *al ser una operación en la que hay dinero de por > medio, el usuario preferirá seguridad antes que velocidad* . Por muy > rápido > que quiera hacerlo, tenderá a asegurarse de que los datos introducidos son > los correctos incluso antes de llegar a la pantalla de confirmación y esto > es más sencillo si solo puede elegir valores de entre los correctos (la > sensación de seguridad aumenta). > *Si el numero de operaciones a realizar por el mismo usuario fuera muy > alto, > es probable que la opción elegida fuera una caja de texto.* De hecho, la > misma transacción, en el entorno de teleproceso que tenemos en la oficina > para el operador (empleado que conoce el entorno y el formato de las > fechas) > en vez de combos tiene cajas de texto en las que el operador debe > introducir > la fecha en formato DDMMAAAA y al saltar de campo el dato se valida y se > formatea a DD/MM/AAAA. > Por tanto *resumiendo creo que aunque dependerá de los usuarios de la > aplicación, si no hay muchas fechas y el perfil de usuarios es variado, > utilizar combos no ralentiza la entrada de datos lo suficiente como para > prescindir de las ventajas que nos presta* (reducción de errores, > orientacion por valor por defecto, imposibilidad de introducir ciertos > valores no válidos en ningún caso, obviedad de combo de día y mes al tener > valores alfanuméricos para los meses --> user-friendly). > *En cuanto a los ceros no significativos, si el control es una sola caja > de > texto y no es necesario introducir separadores, son necesarios para hacer > la > validación de fechas más sencilla. Si la opción elegida es 3 cajas de > texto > para una fecha, no debería ser necesario introducirlos*. > > 2006/6/7, alberto romero <[EMAIL PROTECTED]>: > > > > Hola > > > > On 6/7/06, Fernando Gutierrez <[EMAIL PROTECTED]> wrote: > > > > > > ersonalmente 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. > > > > > > Por poner otro par de ejemplos cercanos, en italiano día empieza por g, > y > > en > > francés por j. > > > > >On 6/7/06, Daniel Moya <[EMAIL PROTECTED]> wrote: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. > > > > Aunque sé que es bastante frecuente, nunca he entendido que se den > varias > > opciones para introducir una misma fecha. Entender y saber usar una es > > suficiente. > > > > Mi opción es, si el usuario disfruta de javascript, mostrar un > calendario > > directamente desplegado. Es fácil y rápido de usar (como siempre, > depende > > del rango de fechas), se reconoce internacionalmente y deja poco lugar > al > > error. > > > > Si no, prefiero campos de texto a desplegables. No resultan sencillos de > > manejar, sobre todo cuando puede haber 30 opciones, como el caso de los > > días. > > Para el texto explicativo me inclinaría por los números ("3/12/2004"). > Sea > > cual sea el "background" informático del usuario, el parecido entre > "2004" > > y > > "2006" es mucho mayor que entre "yyyy" y "2006". > > > > Lo de obligar al usuario a introducir ceros está claro: no. > > -- > > alberto romero | denegro.com > > _______________________________________________ > > altas, bajas y modificaciones: > > http://www.cadius.org/lista/opciones.html > > > > > > -- > Daniel Moya Jiménez > _______________________________________________ > altas, bajas y modificaciones: > http://www.cadius.org/lista/opciones.html > _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
