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
