Conferencia Rails Hispana 2006. Un modelo para otras conferencias
November 18th, 2006 | Published in desarrollo, diseño de interacción, eventos, general, software, web2.0 | 4 Comments
¿Puede influir la selección de una plataforma en la calidad del diseño de un producto?
Trabajar con Ruby On Rails ha cambiado mi enfoque de lo que es un proyecto web. De verdad.
Durante años, hemos tenido que justificar la parte de trabajo de los equipos de interfaz de usuario a base de regateos en jornadas y precios para dar mayor protagonismo al verdadero producto que se estaba vendiendo: tecnología, con sus horas de desarrollo de perfiles técnicos. Si a esto le añadimos el precio de licencias, está claro que nuestro perfil tenía complicada su existencia, y de ahí las contínuas argumentaciones sobre los beneficios de la usabilidad: jugábamos fuera de casa, entre máquinas y sus guardianes.
Lo curioso: cuando muestras referencias de un proyecto, no lo haces con capturas de líneas de código, sino con capturas de pantalla. Cuando muestras un proyecto envías una URL y unas pantallas que el potencial cliente o colaborador navega, no le das un paseo por los componentes, líneas de código o arquitectura, cosas importantes a todas luces, pero no son el producto.
Con Rails, quizá la influencia de 37 Signals haya sido definitiva, el interfaz es el comienzo del producto, y no un residuo de un proceso viciado por la toma de decisiones a espaldas del usuario y basada en problemas puramente tecnológicos. Y aquí está la gran diferencia: si comienzas por el resultado final, el desarrollo está alineado entre diseñadores de interacción, diseñadores visuales y desarrolladores. La forma de trabajo es más flexible. Se acabaron los compartimentos estancos y se pone el esfuerzo en el producto.
Y es que a veces, lo que se denomina plataforma no es más que una losa que corta cualquier iniciativa.
Hablemos de esto: la Conferencia Rails Hispana 2006
La Conferencia Rails es el comienzo de algo y resume la filosofía que hay detrás de esta plataforma: apasionada, pujante. Pero esa filosofía no significa que no haya negocio y posibilidades. Rails no es un juguete, pero tiene la virtud de que trabajar en ello es lo más cercano a jugar. Jugar lo más cercano a aprender e innovar…
La Conferencia Rails Hispana 2006, tiene un poco de “kedada”, de “Desconferencia”, de Congreso… ha sido organizada al más puro estilo grassroots, por los propios ponentes y patrocinadores con el objetivo de que todos los que trabajamos alrededor de la plataforma (como desarrolladores, arquitectos, consultores, diseñadores, vendedores, gestores…) nos conozcamos e intercambiemos experiencias.
El objetivo: promocionar Rails como entorno de desarrollo y mostrar al mundo que hay una comunidad activa en el mundo hispano (hasta David se va a asomar por una ventana a hablar con nosotros).
- La conferencia es autoorganizada con cariño y mucha ilusión, todo a base de sacar horas del tiempo propio. Gracias Joaquín y demás por vuestro esfuerzo.
- Colaboran universidad y empresas en perfecta sintonía… ¡al fin! Si es que la pasión y tener los objetivos claros funciona en cualquier ámbito, y en este caso si no fuera por el equipo de la E.T.S.I. de Telecomunicación de la Universidad Politécnica de Madrid, no habría evento.
- Cero beneficio. El cálculo de las tarifas de asistentes se ha hecho para que se cubran gastos.
- Los ponentes son también asistentes, por tanto… pagan, con su dinero, y “con su sudor”.
- Si hubiera beneficio, iría al “bote” para la Conferencia del 2007.
A mí me toca ponencia. La “Intro a Rails” junto a Agustín Cuenca. Mi parte será explicar lo dicho antes: ¿es un producto hecho en Rails más usable que otro hecho en otra plataforma? Como diseñador de producto o consultor ¿en qué ha cambiado Rails mi forma de trabajo?
La Conferencia Rails es además la prueba de un modelo de evento. En el año de las Conferencias, en que todo el mundo busca su negocio a base de mover “estrellas de rock” por el mundo, aprenderemos algo: las claves para crear otros modelos de conferencia, más abiertos, asequibles y cercanos. Para conocerse y aprender. De nosotros para nosotros.
Es que Rails, es especial. :-)
Quedan muy pocas plazas ¿te vienes?
November 19th, 2006 at 13:06 (#)
Pero creo que esto no es un invento de 37 señales, ni tampoco ha surgido del uso de Rails, JAD es una metodología de recolección de requisitos de software orientada precisamente a esas mismas cosas, y existe desde 1970. Yo no soy un experto en empresas grandes, supongo que en muchas no se hacen prototipos ligeros, pero sí tengo un compañero trabajando en una consultora bastante grande y por lo que me ha dicho allí sí se hacen prototipos antes de empezar el desarrollo (independientemente de que luego trabajen con Java, C#, LAMP…)
En todo lo demás estoy totalmente de acuerdo, verdades como puños escribes :-D
November 19th, 2006 at 15:10 (#)
Si David, tienes toda la razón.
37 Signals no ha inventado esto. Lo que quiero decir, es que creo que el enfoque de Rails ha venido dado por la conciencia de User Experience de 37 Signals (eran -¿son?- una consultora de Usabilidad y Diseño Web). Al final, según su enfoque, un proyecto Rails es un prototipo puesto en producción tras un número suficiente de iteraciones. (Luego viene la evolución y escalamiento…)
Respecto a lo que comentas… Me explico. Mi experiencia en consultoras y equipos de tecnología es que se trabaja en interfaces pero no en la Experiencia del Usuario (no tienen porque ser equivalentes). Quiero decir, que los interfaces se “diseñan” o más bien se “deciden” como una capa sobre la funcionalidad, pero no incopora criterios reales de Experiencia de Usuario (habla de combos = tablas, campos de entrada y extensiones en caracteres de los mismos, pero es más una manera “pre-usabilidad” de documentar un análisis funcional…).
¿Qué opinas?
November 20th, 2006 at 03:31 (#)
Yo tu charla no me la pierdo!!
November 20th, 2006 at 05:04 (#)
Tengo que darte la razón :-D, ya te digo que mi experiencia aquí se limita a lo que me dicen mis compañeros, te puedo decir que ellos son consultores tecnológicos, no tienen ni idea de usabilidad y tal.
Me quedo con lo que comentas de que es muy diferente trabajar con interfaces de trabajar en experiencia de usuario, creo que es la diferencia a tener en cuenta.