Nueva idea agregada


([N3] krear) #1

Hola a todos!

Viendo que hasta la fecha no hay ninguna solución para que podamos controlar el comportamiento del botón de scroll del mouse cuando se pasa sobre campos numéricos, fechas, combobox y alfabéticos con enlace a maestros, cambiando los valores sin tener foco, he decidido agregar una nueva idea.

Este tema ya lo hemos hablado anteriormente en el foro (http://velneo.es/foros/topic/scroll-del-raton-cambia-valores-sin-hacer-click-en-el-objeto/), pero aun no tenemos forma de controlarlo.

También sería interesante que podamos decidir nosotros (como programadores) si queremos que las flechas del teclado arriba/abajo modifique valores en campos de edición numéricos, fechas o enlaces a maestros.

¿Cómo me afecta esto a los formularios en su diseño, programación y la introducción de datos por parte del usuario? Aquí os dejo una pantallas de lo que era antes y de como ha quedado ahora el mismo formulario para evitar que sin querer se cambien los valores con sólo mover la rueda de scroll. Todo blindado y muy poca usabilidad para el usuario a la hora de introducir datos, pero eso si, estamos seguros de que no cambiará nada sin querer.

Podeis votar la idea si os parece interesante en:

https://velneo.zendesk.com/entries/93103548-Controlar-comportamiento-rueda-de-scroll-y-flechas-del-teclado-en-los-campos-Numericos-fechas-combob




([N3] blanyi) #2

Buenos días.
A mi particularmente me ha afectado en gran manera el comportamiento del scroll que cambia el valor de algun control en tiempo de diseño sin tener el enfoco.

Apoyo esta idea, de hecho ya la vota, invito a los demás para que votemos masivamente esta idea para que pueda ser tenida en cuenta. Lastimosamente es la única manera de que en Velneo le preste a atención a fallas que no deberían presentarse, que hacen parte del mantenimiento que deberían hacerle a la herramienta sin tener que esperar a que se proponga como idea, pues realmente es una carencia que presenta y que por lo tanto es algo que requiere solución inmediata. Lo digo no solo por este caso sino por otras fallas que se presentan pero que no son solucionadas sino se proponen como idea y alcanzan el número de votos suficientes para ser tenida en cuenta.


([N1] wikan) #3

Buenas, sin querer crear polémica.
Y si en el momento de aceptar los cambios de la ficha hacen una comprobación advirtiendo que han habido cambios y así el usuario podría darse cuenta que ha cambiado algo.

O como he visto en otras aplicaciones, tener el formulario bloqueado y con un botón activar la edición mediante la condición de activo.

Lo digo por que usar la rueda de ratón para cambiar valores si lo pensamos es includo ágil.


([N3] krear) #4

@blanyi muchas gracias por el apoyo, estoy contigo en todo lo que comentas, de hecho esto lo comenté en soporte el 22 de julio de 2013 y me propusieron agregarlo como idea y también me plantearon una media-solución como lo que propone @wikan al aceptar mostrar un mensaje de que ha cambiado la ficha.

Por qué digo media-solución? Porque esta solución no sirve del todo, imagina que tienes 20 campos en el formulario de edición, haces cambios en 2 de ellos pero al moverte y usar el scroll sin querer cambias otros, el cartel le informará que hay cambios y de hecho el usuario aceptará, pero seguimos en lo mismo, cambio el valor de combobox o aumentó el valor en un campo numérico sin darse cuenta.

En la otra opción de tener el form bloqueado ocurre lo mismo! Lo desbloquea y cambia cosas y debemos confiar nosotros como programador que al hacer este cambio no usó la rueda del ratón sin querer en otros campos que no quería cambiar. Es por eso que he tenido que poner candados y bloquear todos los campos sensibles, es la única forma que tengo de asegurarme.

Cuando hablo de que el usuario hace cambios sin querer me refiero a que el hecho de mover la rueda sobre un campo no significa que tiene que cambiar sus valores. Distinto es que hagas click sobre el campo y luego utilices la rueda del ratón para cambiar sus valores. Y esto es lo que más fastidia al usuario y a nosotros. Lo normal es que si quiero cambiar algo hago click en el objeto y a partir de allí uso la rueda o el teclado da igual, pero suponer que por estar encima ya significa cambiar algo no me parece muy normal, por lo menos en el 99% de las aplicaciones de introducción de datos esto no funciona así.

Tienes razón Manuel que es muy cómodo cambiar los valores con la rueda, eso no lo discuto, pero si quiero tener la seguridad de que antes se ha hecho foco sobre el objeto y esta seguridad actualmente no la tenemos.

Este comportamiento empezó desde la 7.10, es decir que si en tu aplicación contabas con 30 formularios de alta/modificación funcionando correctamente tienes que volver a re-diseñar todos los formularios con alguna de las media-soluciones propuestas, “Life is soft”??? De haber sabido que este comportamiento era así desde el principio igual te lo planteas antes, no cuando ya tienes todo funcionando y los usuarios adaptados a la forma de trabajar con tu aplicación. Luego tienes que ir a tu cliente y decirle “Tengo actualizaciones!” ellos muy contentos porque siempre llevas mejoras, pero en vez de ofrecerles cosas nuevas resulta que le tienes que complicar con checkbox o mensajes cuando nunca lo necesitaron y les dices “Es por seguridad”, seguridad de que? si hasta el momento todo funcionaba ok, si pero ahora moviendo la rueda del ratón puedes cambiar cosas sin querer, y te dicen “Ahh, pero esto antes no pasaba y en mis otros programas no funciona así, y si tu eres el programador porque no me lo dejas como antes?” A partir de aquí ya puedes empezar a inventarte alguna buena excusa y que te crean, cuando tu internamente ya sabes que esto ni lo puedes controlar, ni es un comportamiento normal y que con mucha suerte en alguna actualización volverá a comportarse como lo esperado y tendrás que volver a tocar todos los formularios nuevamente debido a que en una “Actualización” se decidió arbitrariamente cambiar este comportamiento.


([N1] wikan) #5

@krear en el último apartado te doy toda la razón. Que hagas una actualización y pase algo que no podemos controlar uuuff… Yo al final siempre digo lo mismo, aunque muchas veces ni lo entienden. Han cambiado las librerías y no depende de nosotros.

Supongo que a Velneo le pasará lo mismo, aunque ellos si tienen más control sobre esto que nosotros.

Lo único que se me ocurre para ayudarte un poco, es mostrar el mensaje que han habido cambios y además muestres que ha cambiado. Con un bucle en javascript comprobando el valor anterior y el valor nuevo lo puedes sacar.


([N3] krear) #6

Muchísimas gracias Manuel!! de corazón te lo digo! Siempre estás al pie del cañon ayudando a todo el mundo en este foro y eso es algo que hay que agradecer y MUCHO! No cualquiera dedica su tiempo libre a ayudar a los demás y hacer su vida +LifeIsSoft.

Con respecto a lo que comentas de las actualizaciones estoy 100% de acuerdo contigo, de hecho otra de las ideas que había propuesto en 2014 era la posibilidad de “Poder volver a versiones anteriores” para que cuando ocurra algo inesperado y no estamos utilizando ninguna de las “Mejoras” de la nueva versión podamos dejar todo como estaba y no tener que esperar a que algún día salga la actualización que corrija posibles fallos. https://velneo.zendesk.com/entries/71543546-Poder-volver-a-versiones-anteriores-el-vServer-en-cloud

En mi caso particular me he quedado en la 7.12.1 porque no he necesitado casi ninguna de las nuevas mejoras y si pudiera volver atrás te aseguro que me quedaba en la 7.9 aun perdiendo funcionalidades pero garantizando a mi cliente que los datos introducidos en el sistema son correctos.

Como bien dices yo también espero que algún día el equipo de desarrollo nos entienda y entienda que la prioridad en las actualizaciones sea mantener todo lo anterior igual y si hay nuevas funcionalidad mejor aun! Pero que no nos obligue a tener que tocar todo lo que está funcionando bien por algo que no hemos pedido. Esto al final lo único que genera tanto a nosotros como a nuestros clientes es MIEDO a actualizar.


([N4] ns) #7

+1