When designing desktop apps, websites, and mobile applications, more than once I have tried using an application like mockingbird or Pencil Project. On one hand, mockingbird, is a web application that can be accessed from any browser and allows you to design multiple pages with different elements. On the other hand, Pencil Project, initially born as a Firefox extension, now has a multiplatform desktop application that allows you to mockup easily.
The drawback I see on these two applications is that for some reason, I always end up making simple mockups with a simple pen and paper. This way I can organize my ideas faster than using these applications. I guess the main reason for this is that I’m not a designer, so to me it is the same doing a shitty design in paper, than a shitty design with an application. Moreover, usually using a computer app for this task I end up spending more time to do the same…
Anyway, the other day I discovered Wireframe.cc, and the truth is that I was quite impressed by the UI. It is super-easy and fast to use. You just drag the mouse while clicking and voila, you have an item of the size of your selection. You click on the type of item you want and you are done with the item. Even if you want to change attributes, you just have to double click on it, and select the attributes you want to change.
Actually, it is the first time I feel that I do not waste my time doing mockups with an application of this kind. From what I’ve seen, this application is starting, and it still lacks of some functionalities and needs some polishment, but I suppose that those will be added in the future. Even I think this lack of complexity and lack of tons of box types is what makes you go faster.
I think choosing the right tool for a job is a matter of personal preferences and personal needs, but I would recommend trying wireframe.cc and taking a look at the other apps I pointed out at the beginning of the post.
Feel free to share any other tool you find useful in the comments 😉
Español
16/01/2009 at 2:52 am Permalink
ahi mi dilema a la hora de hacer estimaciones, cuanto dedicar a testeo. hay cosas sencillas con pocos flujos de trabajo, pero una migracion de base de datos o un upgrade del lenguaje, supone que deberias de testearlo todo! y en las aplicaciones en las que suelo trabajar…. habria que contratar a un tercio de china para hacerlo en tiempo razonable xD
16/01/2009 at 10:03 am Permalink
Testeo y “tiempo razonable” no se suelen llevar bien xD
Normalmente cuanto más tiempo, más tests y mejor covertura de todo.
Yo la verdad es que la regla que suelo aplicar es que si algo es crítico o que va a ser usado por otros módulos, entonces debe tener unit tests sí o sí.
En cualquier caso, mirgrar una base de datos es otra de esas cosas, que aunque se vaya a hacer una vez, sí debe testearse bien. Pero lo más importante en este caso, es guardarse la base de datos original, no vaya a ser que luego falte algo por migrar 😉
19/01/2009 at 12:04 pm Permalink
Yo he estado usando TDD durante el último año y si bien he de decir que desarrollar tu código en base a test es una gran técnica y robustece enormemente el código, sigue siendo necesario disponer de un buen tester en el equipo.
El problema es que desarrollando a partir de test nos centramos inconscientemente en cómo deben funcionar las cosas, y por tanto en muchas ocasiones dejamos de escribir test para determinados escenarios (que a la larga son los que fallan)
En fin, no me enrollo.
Genial el blog!
20/01/2009 at 5:24 am Permalink
CaDs: totalmente de acuerdo. No sólo es que uno se centre en los tests prácticos, es que yo creo que debe hacerlo. Uno no puede pretender hacer tests de caja blanca, porque el desarollo duraría una eternidad, claro está, si no está desarrollando un sistema crítico para lanzar misiles, manejar plantas nucleares, etc…. entonces cualquier test es bienvenido 🙂
Mi opinión (al menos es lo que yo hago) es que hay que ir haciendo tests para probar las cosas conforme se desarrolle (por pequeño que sea el test que se haga, es preferible tener 1 test que testea el 2% de la funcionalidad, que no tener ninguno; además se queda todo preparado para seguir añadiendo tests, que eso siempre da pereza).
Una vez el producto tiene ya sus tests, cuando se prueba manualmente y se encuentra un bug (o bien por uno mismo, o por un usuario), mi punto de vista es que hay que añadir un test-case que lo reproduzca y finalmente solucionarlo y verificarlo no sólo en el test que se acaba de hacer, si no en el sitio donde originariamene apareció el bug.
22/01/2009 at 11:38 pm Permalink
http://www.youtube.com/watch?v=6LdsIVvxISU
y…. viva Dijkstra!!!! Pero el gran Oluwaseun Akinmade tampoco se queda atras ehh!! 🙂
22/01/2009 at 11:39 pm Permalink
http://www.youtube.com/watch?v=6LdsIVvxISU
y el gran Oluwaseun Akinmade tambien nos da su opinion al respecto!
Un abrazo,
Fer
27/01/2009 at 2:53 pm Permalink
Gracias por el enlace.
La verdad que el video tiene muy buena pinta. A ver si saco un rato estos días y le echo un vistazo.
Por cierto, eso de poner el enlace del video al principio del comentario se ve que no le ha gustado a Askimet, ha bloqueado ambos comentarios.
Un saludo!
04/02/2009 at 8:20 am Permalink
Si habeis trabajado con desarrollo en base a tests no entiendo el comentario de que porque se llevan mal con el tiempo, la verdad.
Los tests ahorran muuuucho tiempo, tanto en la fase de depuración y estabilización de un proyecto como a la hora de añadir funcionalidad.
Y otro punto que los hacen críticos, los tests unitarios salvan proyectos que sin ellos estarían abocados al fracaso.
Haz tests hasta para cuando tires un par de líneas de javascript.
Saludos,
Gonzalo
05/02/2009 at 12:17 pm Permalink
Hola Gonzalo,
He escrito un post con el objetivo de aclarar un poco eso de testeo vs tiempo razonable:
Testeo y tiempo razonable no se llevan bien ¿o si?
Un saludo!