mi desconferencia
Ayer tuvimos la primera desconferencia, y creo que todos salimos de alli pensando que fue todo un éxito.
Lo pasamos muy bien, hablamos, debatimos, todos los desconferenciantes tenÃan temas muy interesantes y fue un dÃa en el que todos, poco o mucho aprendimos de los demás…
Mi desconferencia salió fatal, los nervios me jugaron una mala pasada y me quede totalmente en blanco, conté menos de un 25% de lo que tenÃa preparado desde hacÃa un par de semanas…. asi que como dijimos que ibamos a postear nuestras desconferencias, ahi va la mÃa, la de verdad :)
prototipando en html: desarrollo ágil
Para ciertos proyectos con unas caracterÃsticas muy determinadas creo que no es necesario trabajar demasiado la documentación de los prototipos, se deberÃa pasar más rápido la primera fase de prototipado y prototipar directamente en html.
La documentación es necesaria, no hay que saltarse este paso sino centrarnos en la adecuada.
Para que esto sea posible es necesario que el equipo de trabajo sea reducido, y por supuesto que se lleve a cabo todo el desarrollo en una misma empresa, ya que uno de los puntos más importantes y más beneficiosos de esta forma de trabajo es la comunicación estrecha entre los miembros del equipo.
Esta forma de trabajo, requiere un mayor esfuerzo al principio pero supone menos trabajo después.
La interfaz de un usuario NO es sólo lo que se ve en una pantalla, es la experiencia completa de navegación.
Uno de los principales beneficios de prototipar en html es la tangilbilidad: el cliente entiende cómo funciona, puede clicar, escribir e interactuar por lo que se pierde mucho menos tiempo en cambios absurdos, ya que visualiza y entiende lo que está haciendo.
Otro beneficio muy importante es la comunicación.
Por una parte la comunicación con el cliente porque no se sobreentiende ni malinterpreta nada por lo que se emplea el tiempo en resolver problemas reales.
No se ignoran factores como estados, seguridad, mensajes de error, navegación y otros elementos dinámicos.
Y por otra la comunicación directa entre las personas que forman el equipo, personas con distintos perfiles que pueden aportar y enriquecer mucho el proyecto con diferentes puntos de vista obteniendose asà mejores resultados.
el debate:
Debatimos y se dieron diferentes puntos de vista, algunas personas habÃan probado esta forma de trabajar en proyectos complejos y habÃa sido un fracaso, habÃan tenido que tirar muchas horas de trabajo a la basura.
Por supuesto depende muchÃsimo del tipo de proyecto y visualmente un prototipo en html deberÃa ser tan sencillo como los prototipos en png.
A parte de esto, una de las cosas más importantes es que si el código está hecho correctamente y hay algún cambio que afecta a toda el site con css podemos hacer el cambio de una vez en todas partes y no hay que realizar el cambio png a png, ahorrando muchÃsimo tiempo en mantenimiento de documentos.
Y claro está, estas horas de trabajo prototipando en html es trabajo avanzado a la hora de comenzar con el desarrollo.
Es el planteamiento de una forma de trabajar que si el proyecto fuese el “proyecto ideal” es ágil y muy enriquecedora tanto para el proyecto como para las personas que trabajan en él.
SÃ, lo sé, muy pocos proyectos son “ideales”.
¿qué opinas?
Funcionar, funciona, de eso no hay duda ;)
Cierto que no todos los proyectos son adecuados, o al menos no hemos dado aún con el método flexible que se adapte a las necesidades de todo proyecto, pero debemos seguir intentándolo porque las mejoras trabajo/tiempo son notables.
Deseando ver esos videos! :)
jorge - 02/07/06 (5:22 pm)
hombre, nosotros lo hemos probado y nos ha ido bastante bien no?
también entiendo que ahora mismo es para proyectos muy concretos, pero no creo que haya que desechar esta forma de trabajo, si no como tu dices mejorarla para que sea más flexible y se adapte a más proyectos.
maria - 02/07/06 (5:28 pm)
Mi experiencia con los prototipos en html es nefasta, con lo que me hace falta algo más que un acto de fe para volver a intentarlo :-)
torresburriel - 02/07/06 (6:11 pm)
Hombre… está claro que no hay técnicas válidas para todo, pero en mi experiencia prototipar en HTML tiene tan mala prensa porque se prototipa en HTML, cuando es infinÃtamente más flexible prototipar en PHP o Rails :D
Creo que el tema es lo suficientemente interesante como para llenar un dÃa entero hablando de él (idealmente sacando algo en claro, por ejemplo una herramienta de prototipado rápido : )
Un par de enlaces interesantes:
http://mnteractive.com/archive/rapid-prototyping-with-ruby-on-rails/
http://justaddwater.dk/2006/06/01/my-talk-at-reboot8-prototyping/
a!e - 03/07/06 (1:25 am)
Yo creo que el secreto está en el grupo de trabajo: grupo reducido, en el que haya “feeling” y espÃritu de equipo, y que además requiere que el diseñador sepa maquetar para que no esté liberando PNGs imposibles.
Es decir, bastante difÃcil que se dé, por eso tiene tanto mérito lo vuestro.
Fernando - 03/07/06 (1:47 am)
muchas gracias a todos por vuestros comentarios.
por si a alguien le interesa, mi desconferencia se basó en este artÃculo http://www.digital-web.com/articles/just_build_it_html_prototyping_and_agile_development/
y en una idea de blat ;)
maria - 03/07/06 (3:10 am)
Siempre he trabajado haciendo prototipos en HTML y la verdad me ha ido bien… muy bien. Claro que yo comencé en esto de la web haciendo HTMLs varios.
Creo que el PPT desvritúa en muchos casos el resultado final… todo encuadrado a un ratio de 3/4. Y asà salen esos espantosos sitios llenos de scrolls internos.
Creo que hay varios dependes, tantos como experiencias personales:
1. Grado de avance del proyecto: pà ra eso están los Wireframes, Low Fidelity y High Fidelity no? Personalmente creo que el PPT puede ser MUY perjudicial porque está muy alejado del resultado final.
2. Equipo que lo hace: si están bien “tuneados” se pueden hacer maravillas. Y yo, lo que describe MarÃa, es la forma de trabajo ideal. (Insisto… depende del tipo de perfil que trabaje… )
3. Grado de definición del producto: una cosa es estar haciendo garabatos, otra cosa es haber comenzado a dar forma al diseño.
4. Ãmbito: no concibo muchas aplicaciones “industrialzadas” en otro material que no sea HTML. Hay repositorio de componentes, documentación… todo permite agilizar procesos de diseño etc.
Insisto… todo depende del equipo, de sus competencias y compenetración. Lo que dice MarÃa es el Santo Grial de los Constructores de Interfaces Web. Y a veces te lo encuentras… el caso es identificar que elementos y habilidades permiten que esa magia suceda. ;-)
Luis Villa - 03/07/06 (1:12 pm)
Ya estamos con la paralelización de Fases: *vÃsteme despacio que tengo prisa*, que dicen
Desde el momento que se requiere una labor creativa, no creo que iniciar dicho diseño *maquetando diréctamente* sea ni ágil ni se gane tiempo, de hecho puede perderse y mucho. También necesitas de un perfil mucho mas cross para ello y con mas conocimientos ;)
Los pasos tradicionales son:
Análisis y prototipado a bajo nivel: PPT, Lapiz y papel, Excel,…
Análisis Diseño alto nivel: Pantallazos para el cliente, presentaciones impresas
Documentación de diseño: Guia de estilo, Manual de Imagen Corporativo,…
Maquetación y prototipado
Saltarse el segundo paso y paralelizar con el tercero la fase de maquetación, da lugar a lo que nos es muy cotidiano:
Maquetaciones con un gran grado de libertad de interpretación para el desarrollador (con el consiguiente riesgo de ir a dar con el de la frase *a mi que la raya sea azul o verde me da igual mientras el POST mande lo que tiene que mandar*)
Interpretaciones a conveniencia del cliente (estas son las peores porque acabas discutiendo y mercadeando con cambios).
Riesgo de cambios de cierto empaque, incluso de su totalidad una vez cerradas pantallas completas (por ejemplo, un reordenamiento de contenidos)
Dependencia del maquetador (la documentación aporta liberta de recursos a la hora de construir/maquetar)
Creo que el error radica en hacer pantallazos y mas pantallazos de todo un site, llegando a crear pantallas con una estructura estandar, de las cuales no aporta nada, que acaba considerandose *la documentación del proyecto”. Ni lo es ni deberÃa de serlo, pero debe de estar cerrada por todos los implicados para ser todos responsables del resultado final (incluyendo al cliente/usuario final/peticionario).
Quizá lo deficil sea acotar y saber decir *basta* y cerrar unos mÃnimos.
Como bien dices, ningún proyecto es ideal y partiendo de la base que eso es una realidad, ¿no es mejor contar con ello y evitar/gestionar todas esas incidencias?
Es optar por la realidad antes que por los sueños ( que más bien acaban siendo pesadillas).
Como no, es una opinión (mas bien una vivencia diaria)
Lizzard
Lizzard - 03/07/06 (1:14 pm)
Yo creo que la decisión depende mucho del cliente al que te enfrentes, su capacidad de poder trabajara con elemento abstractos y o conceptuales, y la experiencia que tenga en trabajar con prototipos, y sobre todo cuanto se fien de la empresa.
Desde luego como te pille un cliente cambia, cambia, se puede convertir en una pesadilla.
Ignacio - 03/07/06 (1:38 pm)
Estoy ahora mismo oyendo las réplicas a tu desconferencia y creo que hay algo que no ha quedado claro: creo que lo que MarÃa proponÃa es prototipar en HTML sobre un diseño ya cerrado.
Está claro que a un cliente no le puedes llevar las n propuestas de diseño en HTML, porque te va a costar semanas y seguro que n-1 se van a tirar a la basura y la que gane sufrirá muchas modificaciones.
Pero si el diseño ya está cerrado, y las plantillas básicas ya están desarrolladas en PNG, ¿qué tiene de malo desarrollar el resto en HTML? No tiene porqué haber pérdidas de tiempo.
Fernando - 04/07/06 (7:10 am)
[…] Siguiendo el curso de la desconferencia, María Martínez, ella hablaba de prototipar directamente en XHTML. Entiendo que a lo que ella se refiere es a, una vez cerrada una interfaz gráfica con el cliente… creado el libro de estilo, las pantallas del sitio… se trabaje con estos prototipos. Para los que cualquier cambio suele ser muy sencillo trabajando sobre la css. Para así una vez cerrada la interacción del sitio pasar estos prototipos (que el cliente ya ha usado y al que se le pueden hacer test de usuario) a la siguiente fase de desarrollo. […]
» Prototipado y clientes » inquiettudes.com | weblog sobre accesibilidad, usabilidad, estándares, diseño de interacción, css, xhtml, internet y algo más - 23/07/06 (10:49 pm)
vtnkoqkbz
rkdtknixvo - 31/01/07 (7:55 pm)