« Herramienta para evaluar tu página | Inicio | Contra Lorem Ipsum »

martes, agosto 15, 2006

Comentarios

Vaya, me ha encantado. Pienso igual y es raro, incluso "a estas alturas", encontrarse con trabajos (prototipos, maquetas, desarrollos) que incluyan todos los caminos.

Gracias por dejarlo tan bien escrito :)

Al final, lo que provoca no contemplar los caminos alternativos es que se produzcan varias iteraciones sobre una misma pantalla, con la consiguiente pérdida de tiempo, o que tomemos decisiones los programadores (que somos los que nos enfrentamos a esta falta de previsión) cuando en realidad no nos corresponde a nosotros (no por no hacerlo, sino que hay otros perfiles mejor preparados y que lo harán mejor).

En fin, como siempre supongo que es cuestión de llegar a un equilibrio entre lo fidedignos que han de llegar a ser los prototipos y que no se puede perder mucho tiempo en ellos y que hay que dárselos enseguida a los diseñadores.

Sentido común al diseñar y al programar, recordar las experiencias anteriores (y si no hay pues preguntar por ellas) y sobre todo hablar, hablar y hablar.
Los compartimentos estancos eran lo que iba a salvar al Titanic del hundimiento y ahí anda.

Esa es la diferencia de tener solo "programadores" y no analistas o Analistas/Programadores, o alguien con experiencia en desarrollo de software. Los programadores "descubren" el iceberg con la experiencia (con la pErdida de tiempo que implica), los analistas/programadores conocen el tamaño de antemano o lo advierten a la distancia.

Aunque en desarrollo web (y mas en estos tiempos) la velocidad de desarrollo es muy importante, no hay que olvidar que casi todo esta estudiado en ingeniería de software: no es necesario re-descubrir los problemas. Y, creo, es posible combinar la velocidad/rapidez de desarrollo con un software escalable y funcional.

Este es mi primer comentario en tu blog. Aprovecho para felicitarte. Es muy interesante.

Los errores se ven como algo necesario pero no importante, aunque sean tan importantes como las pantallas principales.

En el esquema mental de mucha gente se da poca importancia a los errores, les parece que los errores hacen que una interfaz parezca complicada o que está mal programada. Se prefiere ver que todo está bonito (bonito como lo entiende cada uno), que todo funciona (que no haya errores ni los previstos ni los no previstos).

Hay veces que para una correcta gestión de los errores se debe modificar la pantalla principal. Esto hace que los errores sean tan importantes como las pantallas de las que provienen, además de que su corrección asegura una correcta experiencia del usuario.

Ahora se está tomando conciencia de que es importante una buena experiencia por parte del usuario, hasta ahora se entendía que un diseño gráfico atractivo y unos controles efectistas era casi suficiente. Aún así los errores o los supuestos rocambolescos se ven como algo secundario, cuando es algo de primer orden.

Estupendo post: poco que añadir, tan sólo recomendar el libro "Defensive Design for the Web" si alguien está interesado en leer sobre este tema. Es un libro muy ligero y muy barato (el formato es pelín cutre) en el que he encontrado algunas ideas muy útiles.

Hola, Jesús

Desgraciadamente la filosofía predominante en el desarrollo de software actualmente es el "cheap & dirty".

Aunque la ingeniería del software no es aún demasiado madura sí que hay mucho conocimiento acumulado y útil, aunque se utiliza poco.

Una técnica muy interesante para plantear la funcionalidad y tratarla junto a los usuarios y cliente son los casos de uso. En donde además de definir un caso de uso se defininen también variaciones al escenario o camino principal y posibles excepciones que puedan aparecer.

http://en.wikipedia.org/wiki/Use_case
(mucho más completa que la versión española)

idealista.com me ha sido muy útil infinidad de veces, gracias!

Los comentarios de esta entrada están cerrados.