Ir al contenido principal

Review: Mockups, una buena tool para diseño de WebForms

Un amigo hace un tiempo me mandó un link a un producto que me terminó entusiasmando, basicamente es un diseñador de formularios (principalmente Web) pero en lugar de "sofisticado y preciso" es "simple e inexacto".

Me pareció un producto divertido y eventualmente útil para algunos como yo que no nos llevamos con las herramientas de diseño y si no fuera por mi hermana creo que me hubiera llevado dibujo a Febrero todos los años. En mi caso quería explicarle a alguien que no estaba conmigo la idea de hacer una aplicación para catalogar KBs "preferidas"que pudieran estar en diferentes GXservers

Así que hice este dibujo "básico":

mockups1.jpg

La parte de arriba es la toolbar donde se pueden elegir diferentes "figuras" (combos, grillas, tablas, botones, tabs, etc) y la parte de abajo es lo que yo dibujé.
Nada sofisticado, un combo, una grilla y poco explicaba el comportamiento que esperaba, obviamente la X es para eliminar el + para agregar un server/kbs, etc. Me llevó 5 minutos hacerlo y es la primera vez que lo uso.

¿Qué me gustó?

1. Simple

2. Divertido

3. Usé la versión desktop pero también la probé "online" y piensan comercializarla por suscripción, lo que facilita compartir los diagramas, usar N máquinas (como yo tengo 2 me vendría bien), etc.

4. Esquema comercial interesante de donde extraigo:

"If you are a technical/software blogger or journalist willing to write us up (honest reviews are the most useful to us) email us a short blurb with the link to your blog and we'll send you a license, FREE of charge, so that you can evaluate Mockups properly." (¡capaz aplico para esta!)

Sino en la charla del Encuentro hablo del tema y capaz aplica esta:

"If you are willing to demo Mockups to an audience of at least 15 people (at a user group, a conference, a BarCamp), email us your info and we'll give you two licenses, one for you to keep and one to give away at the event, FREE of charge. "

Claro que abajo dice:

"IMPORTANT: due to the large volume of requests we have been receiving lately, we cannot promise we'll answer every email. We try our best, but please be understanding if you don't hear back from us." 

La yapa

Ahora que tenía el dibujito me puse hacerlo yo en GX a ver cuanto me llevaba y lo "curioso" del tema es que el "dibujito" me llevó 5 minutos hacerlo y la aplicación totalmente funcional usando GX Evolution 1 me llevo 5 minutos también! 

Luego, en lugar de mandar el JPG, la subí a un server (30 segundos) y mandé el mail con la URL de exactamente lo que quiero, de ahí se puede usar como sample o extender la misma KB, por ejemplo, integrandola con la solución global y yo puedo seguir ajustandola en el mismo server si algo no me gusta como quedó.

¿Qué tecnología hay atrás? Ajax, HTML, JS, ADO.NET, SQL Server y algunas más que ni el nombre conozco y en el fondo no me importa mucho, una vez que supe lo que quería fue simplemente hacerlo.

¿Sobre el dibujo? sigo siendo pésimo pero ya no preciso hacerlos porque mejor que un dibujito es una aplicación funcionando :)

Comentarios

Publicar un comentario

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en