Interacción hombre máquina, en resumen, viene a ser el momento en que los hombres y las máquinas hacen por comprenderse.
Algunos hacen click, otros 'sudo's.
A veces nos olvidamos, en todo esto de la experiencia del usuario, que quienes tienen que entenderse con las máquinas para hacerlas hablar y complicar o simplificar las cosas, son los desarrolladores. Amplio sensu.
Entonces: Cuando se genera un método de comuniación con las máquinas, natural y fácil, la experiencia es satisfactoria, los resultados ágiles y el producto final, seguro precioso y mimado.
Eso va por dentro y se nota por fuera.
Bueno, además, creo haber aprendido de una exquisita charla el otro día, que incluso hay helpers capaces de (con poco esfuerzo al susurrarle a una máquina), calcular plazos de tiempo entre una acción y otra.
Osea que, en pocas líneas de código bonito (que si me aplico, leo hasta yo), le puedes decir a las máquinas que calculen los plazos y traduzca: "Esto ocurrió hace un rato", "Esto está a punto de pasar", "Olvídalo, ya ha pasado". Por ejemplo.
Oye, que estas cosas, a los que diseñamos pantallas, nos vienen muy bien. Conocer los límites y los permisos de la tecnología , nos ayuda a hacer cosas reales, con perspectiva y más rápido.
Seguramente, yo no haya entendido nada.
Extrae tus conclusiones. En directo, desde la Conferencia Rails Hispana.
Por qué no lo mandas a Cadius?
Efectivamente, el mayor logro de esa tecnología , por lo que he visto hasta ahora, es la mejora de la experiencia del programador (como usuario).
Y que para el programador todo sea más rápido, más fácil, y "más mejor", pues repercutirá fuera.
Yo, sin embargo, le tengo cierto miedo a apresurar demasiado el proceso de desarrollo, filosofías de desarrollo ágil y tal (quizá sólo son prejuicios).
Porque quizá esa forma de trabajar, y el llegar a confundir interfaz con producto, pueda dar como resultado experiencias de usuario frustrantes, principalmente debido a arquitecturas de informacion improvisadas y de imposible comprensión.
A mí me da que sí que lo has entendido muy bien, lo que quizá no esté tan claro que se tenga que llegar tal nivel de conocimiento que se sabe que exista un helper que hace tal o cuál, sino quedarse más bien en las metodologías que el framework permite, las posibilidades del mismo y poco más.
Yusef: no todo en Rails ha de ser desarrollo ágil, ni todo desarrollo ágil se tiene porqué realizar como la teoría dice. Así que se puede tener cuidado y validar navegación, arquitectura e incluso interfaces con el cliente antes de empezar a desarrollar. Hecho esto, el desarrollo puede ser ágil igualmente, a la hora de mejorar lo existente, o ir validando y corriengiendo lo que se va implementando, o incluso utilizar dicha metodología para realizar un rápido prototipo de funcionalidad no contemplada y validarlo sobre algo funciona, valga la redundancia.