"Aplicaciones" Web: Ni el foco pueden controlar!

Esto no ha sido un verdadero problema porque la gente usa el mouse para todo. Esto ha sido una limitante de HTML desde el principio, porque no estaba pensado para eso. Javascript, AJAX, etc son parches que se han puesto encima de HTML para poder hacer aplicaciones más dinámicas en web sin tener que recargar páginas completas para todo y también sirven para poder hacer algo de validación del lado del cliente, agregar algunos adornos, etc pero no vas a tener la misma funcionalidad que en una aplicación de escritorio.

Supongo que ya revisaste ZK y otros frameworks de AJAX que presumen de darte la misma funcionalidad que una app de escritorio (y tienen algunos demos bastante impresionantes). Hace poco vi esta demo de HTML5 que es básicamente un programa para dibujar. No sé cómo se puede hacer todo y eso y no se puede controlar el foco de los campos... Tapestry 5 tiene un scriptsito para encontrar si hay algun campo de texto en una página y de ser así, selecciona el primero que se encuentra, lo cual es muy útil para páginas por ejemplo con un campo de búsqueda o de login, etc para que ya tengas el foco en el campo donde vas a teclear algo.

Y por cierto, no estás dándole en la torre a la usabilidad con eso de cambiar el TAB por ENTER? El estándar es que ENTER es para causar una acción y TAB para cambiar de foco.

Si, yo se que estándar es que ENTER es para causar una acción y TAB para cambiar de foco. Pero el problema es que los que le vendieron otras chorromil aplicaciones a este cliente no lo saben... asi que sus usuarios ya estan acostumbrados a usar al ENTER de este modo, asi que adentro de la organizacion, el ENTER es para cambiar de foco y para causar acciones (si esta sobre, por ejemplo un boton, aunque a veces es medio incosistente y ocurre cuando por ejemplo,se esta en el ultimo inputtext de una linea en una tabla) es el estandar.

Si, frameworks AJAX mas elaborados com ZK, Echo, OpenLaszlo, etc ofrecen mejores manejo en muchos sentidos (no se si en este), el problema es que también te obligan a construir toda la aplicación a su manera y lo mas comun en las empresas hoy en dia es encontrarte personas que manejan algo de javascript, hacen sus interfaces en Dreamweaver y usan Java para guardar en la base de datos... si les dices que ahora ya no van a poder usar Dreamweaver y que ZK, Echo, etc no tienen nada que se le compare... pues no le entran aunque acabe saliendoles mas caro el final por las horas de desarrollo perdidas (o quien sabe, por que la curva de aprendizaje tal ves resultaria demasiado empinada... y tal vez al final de cuentas el Browser esta tan limitado que ni con ZK o Echo se puede controlar el foco en tal o cual situacion... y seria gacho descubrir eso después haber invertido tiempo en aprender...)... lo ideal seria un plugin de jQuery que resolviera estos problemas... pero no encuentro ni uno :'(

Has visto esto? No es precisamente lo que buscas, pero pues es una idea alternativa para lo del cambio de foco, usando varios estilos, aunque no abarca lo del ENTER:

Esto es muy similar:

Con que HTML5 tuviera un KeyboardNavigationMode como el de XAML... jajaja.... sueños guajiros....
Me pregunto si es posible calcular el numero de horas hombre perdidas reinventando un manejo decente de interfaz dentro del browser.... supongo que no... no es algo que, por ejemplo, se pueda ver en un plan de trabajo en diagrama de gantt hecho al inicio de un proyecto: "XXX horas en implementar manejo de foco decente"o "XXX horas manejando el foco manualmente control por control en todas las pantallas".
Y todavía nos sorprendemos cuando se retrasan los proyectos ;-)

Si, jQuery ayuda a aligerar la carga del desmedido uso del browser en estos tiempos... pero al final, también se queda corto... (no parece haber ningun jQuery plugin que resuelva definitivamente lo planteado en este blog post... tal ves por que simplemente va mas alla de las capacidades de la plataforma?)

Lo triste es que el mito de que el browser es suficiente para cualquier aplicación crece dia a dia, en van apareciendo mitos derivados, que engañan a las personas haciéndoles creer que lo que sirve para Google, sirve para una aplicación empresarial.... y no es asi, son problemas completamente distintos, que requieren herramientas y enfoques bien diferentes.

Al final el problema sigue siendo el mismo: especificaciones irracionales. El control de foco en tu aplicación web es un curita que le quieren poner al problema de que ya se rompió la usabilidad y la van a seguir rompiendo en esa organización. Cuando entra gente nueva a ese lugar, tiene que recapacitarse en el uso de la computadora si ya está acostumbrada a usar TAB para cambiar de campo y ENTER para causar una acción; y cuando se vaya de ahí, nuevamente tendrá que usar el estándar y olvidar la manera en que se usaba en ese lugar.

Eso causa como dices una pérdida de tiempo, porque aunque al final encuentres la solución, tuviste que invertir mucho tiempo en un requerimiento que honestamente es superfluo. El cliente debe entender que está pidiendo cosas superfluas y que las debe pagar y con mucho gusto se le hacen.

Pues, si en el caso del primer ejemplo, es superfluo, pero en el segundo caso y tercer caso (falta de FocusTraversalPolicy y falta de tab scopes/focus cycle root) no hay disculpa que valga...

Es el costo de querer emular las aplicaciones de escritorio, cuando las aplicaciones web no surgieron por los mismos motivos ni objetivos.

Como dices, se pudo haber aprovechado la versión 5 para darle solución de fondo a este problema, creo que hubiera sido una nimiedad si se lo hubieran planteado, al igual que ezamudio yo también vi el "paint" que hicieron con HTML5 y si se diseñó HTML5 para crear eso sin necesidad de Flash el remodelar la navegación de los sitios web hubiera sido cosa fácil, IMHO, al fin el W3C solo tiene que hacer la especificación y los navegadores seguirla.

Claro que también veo un problema que no es tecnológico, sino administrativo en tu(s) caso(s). Se me figura que tus usuarios son de aquellos que utilizaban terminales en C en donde no había ratón y todo lo solucionaban con el teclado, y ya hasta ágiles eran y a huevo quisieron que el nuevo sistema sea así, resistiéndose al cambio y a que las nuevas tecnologías se manejan diferente, como dije en el título, es el costo de querer emular lo legacy y no resistirse a adoptar las nuevas formas y tecnologías.

Saludos.

Javier Ramírez Jr.

Exacto, es el costo de querer emular lo legacy, el problema es que es un costo dificil de hacer visible y de justificar:
Primero por que: ¿Como le explicas al usuario que tu nueva super-plataforma-web-maravillosa no puede controlar el foco? y segundo por que muy probablemente ni te esperas que falle de este modo tan patético ¿Como es posible que te vendan las caracteristicas para hacer componentes (en Facelets, o en JSF 2.0 o en Tapestry) sin la capacidad para manejar el foco coherentemente? ¿Que no se dan cuenta de que el resultado es algo inutil? En otra industria, casi se le podria llamar a esto fraude...

Aun si no hubieran pedido la traduccion del Enter a Tab, de todas forma hubieran salido mal las cosas por la falta de "tab scopes/focus cycle root" algo que es es posible hacer con Swing (y facilisimo de hacer con XAML). El problema como yo lo veo, no es solo que los usuario se resistan a modernizarse, sino que los desarrolladores en nuestro deseo de modernizar, nos olvidamos de verificar que lo nuevo de verdad sea mejor para los requerimientos... en este caso, las aplicaciones web, se desarrollan por todo y para todo, muy por encima de sus capacidades, como si fueran lo mismo que las aplicaciones de escritorio "solo que mejor por que no hay instalar, no mas hay que tener el browser"... y eso es mentira... pero esta tan extendido que tratar de vender una aplicacion "no web" es muy dificil, los clientes "esperan que sea web" por que "web es lo ultimo y lo mejor" aunque no tengan ni idea de lo que estan diciendo... supongo que el karma de fomentar el web como una panacea esta alcanzando a industria una ves mas...

Dependiendo el framework que uses, tal vez podrías buscar la forma de llevar un contador a nivel página al momento de hacer el render de la misma, para que todos los elementos que tengan un tabindex, se vaya incrementando segun este contador (tomando en cuenta obviamente el tabindex que indican dentro de cada componente).

De esta forma si tu componente1 tiene dos elementos con tabindex 1 y 2, y el componente2 tiene elementos con tabindex 2 y 1, si los incluyes varias veces dentro de la misma página (incluso dentro de un loop), vas incrementando ese tabindex según el contador global pero respetando los tabindex internos (sumándole el valor que indican al contador global)

Es decir, tu tabindex global (TIG) comienza en 1 y si encuentras elementos en la página que lo necesitan, se los vas poniendo. Cuando encuentras un componente le sumas lo que ya lleva el TIG al entrar al componente a cada tabindex, y al final incrementas el TIG por el número de elementos que traía el componente.

Pero igual es muy engorroso y lo pudieron haber hecho los diseñadores del framework...

Jajaja. Te entiendo. Donde trabajo hay algunos usuarios que pidieron que se usara Enter para moverse entre campos en una aplicación Swing. Y al cliente, lo que mande. Por supuesto, es salirse de los estándares de HCI de Windows (y la mayoría de los otros SO también), pero qué le vamos a hacer.

Yo opino que los reeduques. Déjales el Tab.

Sí, la mayoría de la gente usa sólo el mouse para moverse entre controles, ya sea en aplicaciones de escritorio o Web. Sin embargo, habemos usuarios que preferimos el teclado. No somos power-users ni nada, pero se nos hace más cómodo. Una de mis usuarias tiene levantadas varias peticiones en un sistema para que mejoremos esa parte. A sí que, al menos ya somos 2 =). Además, por usabilidad, es necesario permitir usar sólo el teclado. Las human interface guidelines de varios SO lo especifican.

Nosotros hicimos un sistema donde losarchivos HTML los programaban diversas personas. Lo que hicimos fue definir rangos para los tabindex: del 0 al 99 el menu. Del 101 al 200 el header. Del 201 en adelante el body. Y dentro del body, hubo más rangos. Espero te sirva.

Si, algo asi estaba yo pensando hace algun tiempo, crear un plugin the jQuery que, cuando le pasaras algo como:

detectara a los elementos con la style class tabscope y entonces buscara que elementos tiene adentro del dom,y modificara el tab index para producir algo como (basicamente combina el tabindex del div dentro de los inputText):

pero pues ya cuando lo combinas con otros efectos AJAX que puedas llegar a necesitar y con varios niveles anidados de scope... sobretodo si es necesario alterar el DOM para agregar o quitar elementos... pues podria llegar a complicarse bastante...
Lo que no me explico es por que JSF 2.0 no incluye nada asi.... ni Tapestry... por que si no, ya lo hubieras presumido ;-)

No sé si Tapestry lo trae o no lo trae. Como no he tenido ese problema la verdad ni me he metido a ver si hace algo así. No puedo afirmarlo ni negarlo, ni tengo tiempo de investigarlo por el momento.

Bueno, el hecho de que no sepas si Tapestry lo trae o no lo trae ya dice mucho... esto es algo que debería ser parte de los tutoriales mas básicos para crear componentes... asi que si no lo conoces, yo apostaría a que no lo tiene ;-)

Si, la idea de los rangos es la solucion mas simple, y la que generalmente termina uno usando... solo que cuando lo ves en retrospectiva... que caso tiene tener tecnologías de componentes como Facelets, JSF 2.0, Tapesty, etc, etc, si uno tiene que estarse preocupando por estos rangos... diera la impresion de que los que crean todas estas tecnologias no tienen mucha experiencia trabajando "en campo", "en el mundo real", "aqui afuera", donde ese necesario implementar super parches como este de los rango para hacer funcionar una tecnologia de componentes que deberia de resolver estos problemas de forma intrinseca

Claro que eso suena un poco injusto, al final si resuelven otro monton de cosas comunes... o no? Supongo que lo que me molesta es lo dificil que es predecir cuando la abstraccion del framework fallara y me hundira en interminables horas perdidas resolviendo un problema que ni siquiera debiera existir...

No sé quiénes sean los autores de los otros frameworks pero Howard Lewis Ship (el autor de Tapestry) fue mucho tiempo empleado de una empresa llamada Formos y ahora es consultor independiente, tiene clientes "aquí afuera", "en el mundo real" o como le quieras llamar. Podrían subcontratarlo y aventarle ese problema para que lo solucione incluyendo algo en el framework... o esperar a que se tope un día con un cliente que quiere exactamente lo mismo que tu cliente.

Lo que quiero decir es que no todos los proyectos de aplicaciones web se topan con este problema que estás teniendo. En la mayoría de los casos muy probablemente porque el usuario no lo considera un problema, o no es prioritario. Pero pues si fuera algo realmente tan grave en todos los proyectos web creo que habría miles de foros donde mucha gente pregunta lo mismo que tú y ya muchos tendrían distintas respuestas y maneras de resolver el problema.

Ya varios estamos de acuerdo contigo en que es un problema hasta de diseño, ya sea de los frameworks o hasta de HTML. Puedes enviar una petición a la W3C, describiendo el problema para ver si lo meten a la spec de HTML6 o lo que sea. O contactar a los autores del framework que estás usando actualmente, para ver si tienen idea cómo resolver ese problema, y luego avisarle a los autores de los otros frameworks para que no se queden atrás porque el que usas ahorita ya tendrá esa solución en algún momento (en el peor de los casos que te incluyan en el proyecto del framework que usas ahorita, si te ayudan a saber dónde hay que moverle y tú modificas lo necesario para que ya funcione como quieres, les mandas el parche o haces commit y ya que el siguiente release incluya las mejoras que le hiciste).

yo tambien me he topado con usuarios que quiren hacer el cambio del foco con el enter.. y a quienes requerian aplicaciones por ejemplo vb pues si se los hacia claro que por un costo extra (la flojera cuesta) y pero donde no habia una manera facil de hacerlo o no la conocia simplemente se les daba una clase del porque deberia de hacerlo asi y algunos entendian algunos no pero al final acaban acostumbrandose..

Ok Chochos, supongo que no puede hacer daño escribirles a los de whatwg y ver que dicen... ya les contare... ;-)

Tal vez soy de los pocos que piensan "NO a todo lo que pida el cliente".

Una vez también me tope con un cliente que estaba acostumbrado a trabajar en un sistema de ms-dos, donde todo se controlaba con el teclado y las acciones se hacian con enter,si era campo de texto brincaba al siguiente campo, si era "boton" hacia la chamba. Despues se le migró a una aplicacion bajo windows y queria tambien utilizar el Enter como antes por "rapides".

En realidad te digo, que a veces tienes que decirle a tu cliente, NO, pero un no disfrazado. Le lavas el coco diciendole que los estandares de manejo de sistemas graficos dicen que la navegacion es con el tab, que no es lo mas conveniente por que a la larga en TODOs lados del SO asi aplica y al usuario probablemente le llegue a molestar, etc. En realidad que picar una tecla con el dedo meñique de la mano derecha para el enter o con el de la mano izquierda para el tab es indiferente para saltar de campo, a final de cuentas la navegacion por tecladoo existe y es igual de rapida y eficiente, solo hay que decirle al usuario que se tomen un par de dias en asimilarlo.

Independientemente de si se desarrolla un super-estándar con sus muchas implementaciones para atacar este asunto, ¿Por qué crees que los varios frmeworks aún no lo implementan?, lo primero que se me viene a la mente es que es demasiado trivial y pudiera caer en lo tonto. Así como el usuario se acostumbro a usar el ratón, así se puede acostumbrar a utilizar la mano izquierda para saltar de campo, el chiste es mi buen, que no por que el cliente lo pida significa que está en lo correcto. Tu además de ser el programador eres el que conoce esto, así que es tu trabajo hacer ver al cliente lo que realmente necesita y lo que le sirve a un futuro.

Estoy de acuerdo en lo de enseñarle al usar el tab... pero a veces se encuentra uno con usuarios que de plano se niegan... es irracional... pero asi somos los humanos... al fin de cuentas tambien es irracional hacer aplicaciones en HTML siendo que es una plataforma que no es para eso, y ahi esta la mayor parte del mundo haciendo sus aplicaciones en HTML... como quien dice, que el que que este libre de irracionalidades lance la primera piedra ;-).

Por que creo que los varios frameworks todavia no lo implementan? bueno, Swing lo implementa... WPF lo implementa... la verdad es que casi cualquier framework que en verdad fue diseñado para este tipo de aplicaciones "de escritorio" lo implementa. Demasiado trivial? Mas bien el problema, creo yo, es que estamos acostumbrados a hacer aplicaciones con pantallas de captura super simples (casi de juguete) en donde no importa la velocidad de captura... es un tipico ejemplo de "el que tiene un martillo piensa que todos los problemas son un clavo" , en este caso, el martillo son las tecnologias web, como Html y Javascript, y el clavo, cualquier aplicacion que pida el usuario...

HTML simplemente no tiene concepto de tab scopes/focus cycle root.

Hay varios elementos HTML/XHTML que podrían serte de utilidad: button, fieldset (grupa controles y etiquetas relacionados entre sí), legend, label, optgroup, tabindex (especifica la posición de un elemento en el orden de tabulación en un documento), accesskey, (asigna una tecla de acceso a un elemento).

Al migrar aplicaciones de AS/400 a web en más de un ocasión me he topado con esa situación. Invariablemente los refiero al estándar en W3C. Hay un link para enviar comentarios y sugerencias.

Navegar con Enter no es un problema técnico ("hard skills"), es un problema que requiere para su solución "soft skills": "Señores, el mundo no es como ustedes quieren, sobrepónganse a eso."

Saludos

Javier Castañón

Navegar con Enter no es un problema técnico ("hard skills"), es un problema que requiere para su solución "soft skills": "Señores, el mundo no es como ustedes quieren, sobrepónganse a eso."

Mi cliente contestaría algo como: "Yo les pago para que hagan lo que yo quiero, si no pueden, buscare otro que si este dispuesto, señores, sobrepónganse a eso"