Nuestro objetivo final es hacer más fácil la vida de esas personas que tienen unas necesidades básicas de facturación y que continúan haciendo sus facturas a mano, en word o en excel porque no encuentran una solución que les permita trabajar de forma simple y rápida.

Hoy estamos un poquito más cerca de llegar a ese objetivo, pudiendo llegar a muchos más autónomos que se beneficien de nuestra aplicación.

Desde hoy, tenemos una versión de FACTURAgem integrada en la aplicateca de movistar. Esto significa que todos los autónomos que utilicen la aplicateca, pueden contratar el servicio de facturación y utilizarlo de forma transparente con un login unificado y sin salir de su escritorio virtual bajo la marca comercial FacturClick.

Agradecemos desde aquí la confianza depositada por movistar, y el excelente trabajo de Dani, Quico y Jacobo que, con ayudas puntuales del resto del equipo, han hecho posible que este proyecto vea la luz.

Frente a la opción de los “botones voladores” siempre nos queda la del “diseño que se quita de en medio”: sólo los botones que hacen falta y en el momento que hacen falta, siempre siguiendo un patrón lógico. Lo ideal es que el proceso sea tan claro que ni siquiera se vea. Que el usuario simplemente ejecute, y no tenga que pensar “¿y ahora qué se supone que tengo que hacer con todos estos botones dando vueltas a mi alrededor?”

Volvemos a nuestro aforismo favorito: menos es más. Al fin y al cabo, las aplicaciones deberían están pensadas para hacer cosas concretas -las que el usuario necesita- y para hacerlas rápido y bien. ¿O no?

Desafortunadamente, muchas aplicaciones parecen pensadas para hacer “muchas cosas / todas las cosas / cualquier cosa”. Y esta puede ser la raíz del problema, también en el caso de los “botones voladores”.

• Posibilidad de embeber las presentaciones en cualquier website
• Importar diapositivas de otras presentaciones
• Inserción de imágenes mediante “Drag and drop”
• Cambiar el fondo
• Reordenamiento fácil de diapositivas

Los cambios acaban de llegar y, como siempre, han generado opiniones encontradas. Algunos creen que la apuesta se dejará sentir en slideshare.net, y que también obligará a Microsoft a mejorar sus aplicaciones de Office. Otros piden que se pueda insertar audio. Muchos creen que esto se podía hacer desde hace años con otros programas (Flash, etc.) y que resulta totalmente arcaico en un mundo donde priman los “vídeo contenidos”…

En cualquier caso, el tema que genera controversia no son las funcionalidades, sino el concepto de PRESENTACIÓN en sí mismo. En muchas ocasiones han sido -y siguen siendo- tan largas y pesadas, que han dado lugar a una amplia teoría de reglas. Merece la pena repasar algunas:

Regla 10/20/30
10 diapositivas
20 puntos en la fuente como mínimo
30 minutos de duración como máximo

Regla del 7×7
No más de 7 líneas de texto por diapositiva
No más de 7 palabras en cada línea

Regla del 3
No más de 3 partes:
(1) Introducción
(2) Discusión
(3) Conclusión

Regla del 20:
Según esta regla, a partir de los 20 minutos la atención de un adulto decae. Por eso, si la presentación no puede llevarse a cabo en 20 minutos, hay que intentar, cada cierto tiempo, cambiar un poco la forma y el fondo para mantener el interés.

Y un apunte que puede ser clave: si la audiencia se da cuenta de que estás leyendo el texto, dejará de hacerte caso, porque son capaces de leerlo antes de que tú lo pronuncies en voz alta. El resultado puede ser una preocupante falta de sintonía.

Como siempre, las reglas están para romperlas con inteligencia. Nunca deben convertirse en límites para lo que necesitamos contar. Nos sirven, eso sí, para reflexionar sobre nuestro trabajo; para localizar los puntos débiles de nuestra presentación y enfatizar los fuertes. Un ejemplo muy sencillo: aumentar el tamaño de la fuente -y, por lo tanto, reducir el contenido- no sólo reconfortará a los miopes del auditorio, sino que nos ayudará a realizar un ejercicio de síntesis. Nos quedaremos con lo más importante, le daremos más relevancia, y nos libraremos de ideas y conceptos prescindibles que no harían más que despistar a nuestro público.

Yo por mi parte me encargué de explicar porqué hemos elegido Ruby on Rails como nuestra herramienta favorita para este tipo de proyectos. Podeis ver a continuación la explicación -más o menos fidedigna- que realicé en los 4 minutos de presentación que me correspondían.

Ruby on Rails es un framework para desarrollo de aplicaciones web escrito en el lenguaje de programación Ruby.

En ASPgems, donde todo el equipo tenemos experiencia en otros entornos sobre todo en proyectos grandes en el mundo corporativo, utilizamos Ruby on Rails porque nos permite desarrollar proyectos web de calidad en tiempos muy competitivos y usando metodologías de programación ágiles. Esto nos permite empezar a desarrollar un proyecto con un número mínimo de requisitos que sabemos que van a cambiar mucho durante la vida del proyecto, y que podemos aceptar cambios incluso en los días previos a la salida a producción sin que tengan un impacto significativo en la mayoría de los casos.

Encontramos varias ventajas en Rails sobre algunos otros frameworks. Por un lado, el lenguaje sobre el que se desarrolla, Ruby, es un lenguaje muy orientado a objetos, potente, y muy expresivo. Con pocas líneas de código puedo conseguir muchas cosas, con lo que la legibilidad del código es mayor y la probabilidad de errores se reduce.

Ruby on Rails, es un framework con opinión que se basa en el principio de “Convención sobre Configuración”, de forma que si yo utilizo las convenciones que el framework espera, Rails es capaz de hacer gran parte del trabajo por mí. En rails no hay que mantener ningún fichero XML para configuración de filtros, mapeos, validaciones o nada parecido. Además, al trabajar todo el mundo siguiendo las mismas convenciones, se puede incorporar gente a un proyecto en marcha o rotarla con un coste mínimo.

Otra gran ventaja de Rails, es la filosofía misma del framework. Rails está creado a partir de un proyecto real puesto en producción. Se desarrolló un proyecto web con Ruby siguiendo patrones de diseño estándar como MVC, Inversión de Control, Persistencia de Datos… y se vio que el proyecto funcionaba bien y que había varias partes reusables. Ese código reusable se extrajo para hacer un proyecto Open Source. Además, se le añadió un mecanismo de plugins para poder ampliar o modificar el comportamiento del framework de forma simple.

Como el código del framework es fácil de entender, y es sencillo crear un plugin, en seguida se consigue una comunidad de desarrolladores muy activa. Cuando un plugin se usa mucho dentro de la comunidad, se acaba incorporándo al núcleo del framework; y al contario, si una parte del framework no la usa casi nadie, se acaba sacando como plugin. Se puede seguir usando, pero no se mantiene dentro del framework, con lo que no se convierte en un framework monstruo donde cabe todo.

Debido a esto, tenemos un framework que está vivo y que se va modificando según los proyectos y las necesidades reales de la comunidad que lo usa en sus proyectos en producción.

El resultado es que, para una persona acostumbrada al desarrollo web, se puede desarrollar una aplicación completa con muy poco código. Te puedes centrar en la lógica de negocio y dejar muchos detalles de implementación al framework.

Esto choca con otros frameworks que están pensados en abstracto para cubrir cualquier caso posible, y acaban teniendo una arquitectura tan compleja que en muchos casos te da la impresión de que, más que desarrollar, estás luchando contra el framework.

Está práctica es muy frecuente sobre todo en USA y también en el Reino Unido. En España es una práctica que no ha tenido demasiado éxito hasta ahora quizás porque las diferencias de coste no eran tan grandes. En España el “offshore development” ha sido tradicionalmente sustituido por las empresas de “body shopping”, no mencionaré ninguna porque igual se ofenden , que venden muy barato horas de programación sin tener muy en cuenta ni la experiencia ni la calidad de los programadores.

Con la subida salarial y la demanda de profesionales cualificados en España subiendo, algunas empresas se han acercado a esta modalidad de desarrollo contratando desarrollos fuera de España (países del este, India, Argentina, etc.)

Pues bien nosotros llevamos ya 3 clientes que se acercan a nosotros después de no haber tenido éxito con sus proyectos de “offshoring” con aplicaciones Rails. y yo creo que la razón fundamental es que en proyectos cortos, con especificaciones poco definidas, y en los que la capacidad de adaptación es imprescindible, las distancias se hacen enormes, y las diferencias horarias mas todavía.

En nuestros proyectos el uso de SCRUMgem nos hace competir con las compañías de “offshoring” en aquello que ellos no pueden hacer que es la proximidad con el cliente, la flexibilidad en los cambios, y la capacidad de negociación cara a cara con el cliente.

Además todo esto es posible cuando cuentas con un equipo de gente muy cualificada, que en la mayoría de los casos a anticipado los cambios que vas a pedir, y con una tecnología de desarrollo como Rails.

Es un proyecto que hemos desarrollado en ASPgems, es para nosotros un claro exponente de los principios y tecnologías de desarrollo de software que defendemos porque:

• Está hecho con Ruby on Rails.
• Ha sido un desarrollo ágil, y muy basado en SCRUMgem.
• Es “menos es mas” ha sido una dura lucha en el diseño y la concepción para no poner todo lo que se nos ocurría.
• El tiempo de desarrollo no ha sufrido desviaciones sobre el previsto.

Yo creo que es un claro ejemplo de las cosas que la tecnología hace hoy posible.

Mucha suerte para MiRubi.com.

Yo no sé muy bien por qué es, pero en mi experiencia es común que tendamos a generalizar, a añadir, a y además hace esto, a ortogonalizar. Pensar un funcional o una interfaz es todo un ejercicio de contención de esos impulsos.

Una vez asimilas el no como algo legítimo a la hora de diseñar, el siguiente paso, más difícil si cabe, consiste en decir que no a lo adecuado, equilibradamente, de forma que el resultado sea limitado por elección, pero armónico.

Me pregunto cuantos nos rodearon a la concepción del iPod.

“Te escribo esta carta tan larga porque no tengo tiempo de escribirte una mas larga”

o

el principio de la navaja de Ocham

Hoy en una reunión con un cliente estabamos intentando convencerle de que haga menos cosas, que los sites muy complejos son difíciles de utilizar. El discurso nos quedaba la mar de bien.

Pero ay amiigo, en nuestras aplicaciones nos esta costando un montón, y es qeu las funcionalidades y las opciones tienden a crecer, son como los gases, pero en los sitios web.

Un site lleno de funcionalidad es:

• Mas caro de hacer
• Mas caro de mantener
• Mas caro de explicar
• Mas fácil invertir en cosas no usadas
• El principio de Pareto se aplica también al uso que los usuarios hacen de las funcionalidades

Nosotros vamos a seguir luchando contra la complejidad. Nuestra obsesión es hacer las cosas sucintas, que la buscon de la RAE define como