¿Que es lo que tiene la mayoria de la gente al lado del telefono de casa o de la oficina? Un calendario que nuestra uno o dos meses con hojas para cada mes. cuando tienes que poner una cita, simplemente haces un circulo en el dia correspondiente y pones una nota al lado, y si no está en esa hoja pasas páginas hasta llegar al mes indicado.
¿Porque no hacer eso mismo? Se ponen dos calendarios con botones para pasar al mes anterior y posterior y un combo para el año con un margen razonable, por ejemplo 10 años por arriba y por abajo (depende del objetivo de esas fechas). y que los dias sean seleccionables. Pinchas sobre el el 3 de Enero y se queda marcado con un borde, por ejemplo, o un fondo de otro color. Y ya está, tan sencillo como eso. Lo literales de los dias de la semana y los meses los pasas por xml o formulario. On 6/8/06, Daniel Moya <[EMAIL PROTECTED]> wrote:
Si pones solo los dos calendarios, ¿Cómo lo haces? ¿Cómo sabe el usuario si ha seleccionado las dos fechas? ¿Cómo se comportan los calendarios para consultar estos datos? Si además de ser consultables, son modificables estas fechas, ¿también lo harás con calendarios? No termino de verlo claro. No sé si no te he entendido bien o no sé a que te refieres con lo de calendarios. Podrías poner un ejemplo o enviar a la lista una pantallazo de un sistema que lo esté utilizando como tu sugieres? Te lo agradecería mucho porque no entiendo bien como pretendes que se comporte la aplicación. Gracias de antemano. Un saludo 2006/6/8, Agustín Casado Ruiz < [EMAIL PROTECTED]>: > > 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 > -- Daniel Moya Jiménez _______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
calendario.png
Description: PNG image
_______________________________________________ altas, bajas y modificaciones: http://www.cadius.org/lista/opciones.html
