El diseño importa (a veces)

A menudo mi mujer me dice que mejoremos el diseño de la página web, que incluyamos animaciones, nuevos gráficos, mejores tipos de letra, etc…

Llevo muchos años en esto, y el diseño importa, claro que importa, pero tambien hay algo mucho más importante que muchos olvidan: Marketing

Vender por internet, es muy parecido a vender puerta a puerta, y os pongo un ejemplo.

Vais a comprar un piso, y vais a una inmobiliaria ¿como tiene que ser esta inmobiliaria?

• Limplia, amplia, espacio bien organizado.
• Sala de espera, secretaría amable.
• La persona que te atiende debe estar bien vestida.
• Debe proporcionar información clara y concisa.
• Tiene que inspirar confianza.

Ahora pensemos en como están algunas páginas web:

•  Local de diseño, tardas 15 minutos en encontrar la puerta, camuflada con el dibujo de un árbol
• Entras un sala que tiene 3 monitores, uno con información, en otro videos musicales y otro hay una persona que te saluda y te dice hola.
• Después de un rato, te recibe una persona vestida de gala, y empieza a contarte las características del piso al mismo tiempo que canta un rap.
• Te vas de local, y ni si quiera te has enterado el precio.

No estoy exhagerando, en absoluto, algunas páginas web son tan “WEB 2.0″, que no se pueden usar.

¿Por que subrayo usar? Pues es la clave:

• Una web tiene que ser usable, en 5 clicks he comprado.
• Una web tiene que inspirar confianza.
• Tiene que estar organizada.
• Tiene que funcionar!!!!!!, el uso de AJAX hace que muchas webs no funcionen correctamente.

En conclusión, mi consejo es que no olvidemos nuestro objetivo, vender, y para vender tenemos que abrir el camino al comprador.

Las mayores tiendan, son las más simples (www.amazon.com), los mayores portales, son los más simples (www.google.es)

El éxito de Ruby on Rails

Ruby on Rails (RoR) está teniendo un éxito increible en internet, clasificado como una de las tecnologías de futuro, millones de programadores abandonan java, php y se aventura a un nuevo lenguaje.

Curioso, por que ya se decía que era imposible que un nuevo lenguaje entrara en juego, pero … ¿que tiene Ruby on Rails que no tenga los demas lenguajes?

Vamos a la filosofía de Ruby on Rails, hacer las cosas una sóla vez, y hacer las cosas fáciles.

¿Pero esto no existía ya?

Mientras otros framesworks y lenguajes se didacan a filosofar y teorizar, RoR ha sido extramademente práctico y ha encontrado la forma de mezclar framework con generador de código de forma fácil. En 5 minutos tienes el mantenimiento de una tabla, en menos de 500 líneas de código un foro.

El principal “culpable” de que esto no se halla hecho antes son los propios programadores. Si, parece mentira, y veamos por que.

El primero que empezó con tecnologías similares fué Microsoft, cuando apareción .NET te hacías un mantenimiento sin líneas de código, pero claro,hay mucho Geek antimicrosoft, y lo mejor es Java……

Java tiene una filosofía estupenda, pero es eso, filosofía, le falta un gran porcentaje de práctica. Por eso, muchos programadores se pasaron a PHP, un lenguage mucho más práctico, más fácil de utilizar (aunque un poco caotico).

Al final, los programadores han descartado .NET por que es de Microsoft, Java por que no es práctico, y PHP por que es poco mantenible….

¿Entonces es el futuro?

Yo no me aventuraría a decirlo, en el 2006 han nacido 4 grandes proyectos para llevar RoR a php, llegando a ser casi similar, y para decir la verdad, llevo con un framework parecido desde el 2004 (pero sólo para aplicaciones clientes)

Es decir, la tecnología es buena, pero facilmente copiable y trasladable a otros lenguajes.

Yo personalmente no apostaría al 100% por este lenguaje, aunque tampoco lo dejaría escapar……

Mi visión 

Yo utilizo mi propio framework, llevo con él desde 1992 cuando lo empezé en ADA.

En el 2004 hacía todo lo que actualmente hace RoR, de hecho las aplicaciones realizadas, no tenían practicamente código, y por consiguiente no tiene errores, pero me dí cuenta, que cuando tenía que hacer algo que se saliera de la normal, tenía un coste altisimo, así que desactive la generación automática de formularios, y pasé a un modelo un poco más sencillo, en el que las ventanas se “pintan” con NetBeans, y el código es casi inexistente:

Os paso el código para hacer un mantenimiento de la tabla clientes, la ventaja de RoR es que tiene un generador de código, pero el código en sí, es muy similar.

Clase de Negocios:

public class NegocioCliente extends GenericBusiness{
public NegocioCliente() {
super(“cliente”); }
}

Controlador (hace al mismo tiempo de listado):

public class ControladorClientes extends GenericList {

//inicializamos la clase
public ControladorClientes() {
init();
botoneraListado.setGenericList(this);
this.setEditForm(“EditaCliente”);
this.setBusiness(“clientes”);

}
}

Ventana de edición de clientes:

public class EditaCliente extends GenericEdit {

public EditaCliente() {
init();}

private void cancelPerformed(java.awt.event.ActionEvent evt) {
cancel();
}

private void aceptPerformed(java.awt.event.ActionEvent evt) {
accept();
}

}

Quiero un portalito

El otro día, un amigo me dijo que quería un portal, le pregunté que era lo que quería exactamente y me dijo que el joomla.

La verdad es que me puse un poco prepotente…. (se me escapó), pero el dije que estaba totalmente equivocado, había caido en el fallo de mucha gente. En lugar de pensar en el contenido que quiero poner el portal, empiezan mirando primero la tecnología, olvidando que lo importante de un portal es el contenido, los usuarios, y el refresco del contenido.

En este sentido, antes de comenzar un portal, yo me haría una tablita, con algunos datos como estos:

Nombre del contenido:

Atractivo para el usuario (Mucho, Normal,Poco) :

Frecuencia de refresco:

¿Quien crea el contenido? (Automático, usuarios, administradores):

Coste de crear el contenido:

Una vez que tengamos indenticado todos los contenidos, nos hacemos nuestras cuentas y vemos si el portal es mantenible o no, si nos va a costar mucho trabajo.

Debemos tener en cuenta que no tendremos muchas visitas si el contenido no de refresca a menudo.