Presentando Minchador en el Vinalab

Hace unas semanas que Daniel Twal me propuso ir al Vinalab para hablar acerca de Minchador a comerciantes locales de Vinaròs. Cosa que hice el martes pasado.

Para mi era interesante el plantarme por fin a hacer una presentación pública sobre mi nuevo producto, pero la verdad que no me apetecía hacerlo en el típico sarao de presentación de proyectos de emprendedores o inversores, a día de hoy no me interesa invertir las pocas energías que le puedo dedicar a Minchador en preparar ese tipo de eventos; pero me atraía muchísimo la posibilidad de plantarme a presentar delante un pequeño grupo de posibles potenciales clientes y otros comerciantes tradicionales para ver si era capaz de comunicar las bondades del producto.

Como se enmarcaba en un evento especial de comercio y tenía 45 minutos de presentación, no le veía sentido a limitarme hacer una presentación de producto en plan comercial, y tampoco es mi estilo.

Por eso preferí empezar hablando sobre plataformas que, como Minchador, ayudan a vender o convertir de alguna forma las visitas a clientes poniendo ejemplos de algunas de ellas por un lado, y mostrando y haciendo hincapié sobre casos reales que conozco por otro: Taller deDos, las cenas de Movember y Milán Dopico.

Después continué presentado Minchador como producto y qué problemas soluciona, así como comentando el roadmap con algunas de las cosas que se pueden esperar para el futuro. Aproveché para comentar los 2 casos más llamativos que a día de hoy están utilizándolo: Brasería Les Caves y La Jamonería.

Y para terminar aproveché el momento para comentar por encima algunos de los tópicos más habituales que se ven por ahí sobre vender por internet.

Dejo la presentación aquí:

La verdad que estuvo interesante hacerlo, me llevé algunos contactos y, un poco de rebote, la posibilidad de que nuevos restaurantes entren a probar la beta cerrada.

Rediseño de la home

Me complace presentar, por fin, el rediseño de mi web profesional/portfolio. Algo que me propuse hacer hace ya unos meses por ver que debería cambiar mi forma de comunicar para que se perciba mejor qué tipo de servicios doy.

Mi web profesional empezó simplemente mostrando el logo y mi dirección de email de contacto, varios meses después amplió a a ser una pequeña presentación indicando conocimientos tecnológicos que tenía.

Casi 3 años teniéndola totalmente olvidada, y tras muchos trabajos hechos, decidí darle la mayor parte del protagonismo a mi portfolio, para que quien llegue a mi web pueda conocer mis trabajos anteriores (los públicos nada más, claro).

Lo que hice fue buscar un template html que encajara con los bocetos en papel que me había estado haciendo, trabajar en el contenido y en adaptar el template. Aún cubriendo aceptablemente el objetivo que tenía, pero visualmente el resultado era entre mediocre y feo, principalmente por mi nula capacidad para retocar los logos que mostraba de los proyectos.

Y es que aunque uno no venda diseño en sí mismo, para mi es algo importante. Por un lado porque a veces me buscan para desarrollar proyectos/productos desde 0, donde también hay que conceptualizar y, por supuesto, diseñar; y por otro para tratar que se perciba mayor calidad también cuando me requieren sólo para programar.

Una de las mejores cosas de compartir espacio de trabajo con gente que trabaja en el mismo sector y/o con la que te complementas, es la posibilidad de colaboración. En el caso del diseño de mi web, tuve la suerte de que José Luis Lizano tuvo una temporada relajada de trabajo y pudo dedicar un tiempo para darle una vuelta a lo que había hecho yo, con un resultado visual que a mi me encantó.

Sea dicho que yo, aún tocando sin miedo CSS y HTML para hacer detallitos de frontend consiguiendo no romper nada, soy totalmente incapaz de maquetar PSD a HTML. Por eso tenía hablado con Guillermo Latorre (que no, no somos familia :)) que nos juntaríamos un día para hacerlo y así yo aprender un poco de cómo hace él ese trabajo. El problema fue que, con el diseño en PSD ya hecho desde Octubre, el trabajo del día a día fue haciéndome posponer el plantearme maquetarlo, o incluso olvidarme un poco de ello. En fin, ya se sabe que en casa del herrero…

Pero por fin pudimos juntarnos un par horas el viernes, y otro par el lunes para maquetarlo. No es que aprendiera lo suficiente para poder pasar el PSD a HTML en mi próximo proyecto, pero aprendí algunas cositas interesantes.

Utilizamos Initializr para generar un template basado en HTML5 boilerplate, la tipografía Open Sans, un poco de jQuery, LESS compilado a CSS. También estuve viendo por mi cuenta el protocolo Open Graph, añadiéndole los tags de metadatos a la web, para hacer las comprobaciones resulta útil la herramienta de facebook para hacer debug.

Ahora la cosa será adaptar ese diseño para este blog e implementarlo como tema de wordpress, a ver si no pasan meses :P

Minchador.com en beta cerrada

No es ninguna noticia, ya hace un par de meses que empecé a enviar invitaciones a los pre-registrados a minchador y a lo que le di un poquito de bombo por twitter pero sobre lo que no había escrito.

La fase alpha

Previamente a darles acceso a los primeros usuarios me dediqué a hacer algunas demos de la versión pre-alpha y más entrevistas a un par de hosteleros de confianza, para escuchar sus ideas y propuestas. Mi idea nunca ha sido hacer una aplicación a medida para un restaurante en concreto, pero algunas de esas propuestas y necesidades me hiceron pensar en soluciones algo más genéricas para resolver ciertos escenarios y problemáticas.

Pienso que es una práctica muy recomendable mostrar una versión temprana de tu producto a tus potenciales clientes y recoger su feedback, pero ojo con confundirlo con hacer una solución ad hoc a las necesidades de esos potenciales clientes.

La fase beta cerrada

Hablando ya sobre la beta cerrada, la mayoría de los usuarios que hicieron caso al email de registro (a día de hoy 24 de 94, una cuarta parte) hicieron lo que esperaba: se dieron de alta, entraron, navegaron un poco por la aplicación web, como mucho alguna reserva de prueba y se fueron.

Algunos por suerte me dejaron feedback de errores y gazapos que no tenía controlados, no hay nada mejor que gente usando tu software para darte cuenta de lo descuidado que has sido, además me ayudó a darme cuenta de un par de pequeñas funcionalidades necesarias en las que no había caído. También algunos amigos que saben mucho de esto de crear productos en internet, me dieron algunos consejos y opiniones de esos que siempre son bienvenidos.

Además, unos pocos de los usuarios dados de alta son restaurantes, de los cuales un par de ellos ya lo están usando y recibiendo reservas: Brasería Les Caves en Calella y Letras de Laurel de Logroño. Eso ha significado mucho y muy buen feedback que ha ayudado a madurar y mejorar el producto al haber surgido algunos problemas en situaciones reales con clientes reales.

La situación actual es que es un producto que ya hace su función en un contexto real, pero posiblemente la beta cerrada todavía se alargue unos meses más. Podría decir que la razón es que necesito algunos restaurantes más para ver si necesita más mejoras y terminar de cerrar el pricing, pero la realidad es que es más una cuestión de que ando con otros proyectos entre manos, y esto no me permiten darle la dedicación necesaria para terminar de lanzarlo en condiciones. Vamos, la misma razón por la que me ha costado tanto tiempo conseguir tenerlo en este punto :P.

SpotyWhere, nuestro proyecto en el Grails48

El segundo fin de semana de Noviembre, se celebró el primer Grails48, un hackathon a nivel mundial en el que se debía desarrollar una aplicación web hecha con Grails en el transcurso de un fin de semana.

Pues bien, yo participé en un equipo junto a Raúl Gracia (desde Londres), Fernando Val (desde Dublín), Rafael Ramos (desde Zaragoza) y Alberto Vilches (desde Madrid); lo que viene siendo un equipazo, que además del evidente handicap de que supone la deslocalización tenía alguno más. Salvo Raúl y yo, el resto no habíamos trabajado nunca juntos (o no más que en proyectos pequeños por amor al arte). También sabíamos que no íbamos a pegarnos todo el fin de semana programando (por ejemplo, yo mismo me fui con Rafa de concierto el sábado, con su posterior resaca :P) y que la dedicación de algunos iba a ser bastante limitada por tener otro tipo de obligaciones. Pero, con el equipo que montamos, tenía claro que del fin de semana saldría un resultado interesante de todas formas.

La idea a desarrollar era de Raúl, una aplicación web donde localizar canciones en un mapa, que era la idea que más nos convenció de las que barajamos. Terminamos decidiendo centrarnos únicamente en Spotify y su API, y a partir de ahí empezó la gestación de SpotyWhere.

Spotywhere

El día antes hicimos algunos bocetos y wireframes, para intentar tener todos una idea lo más común posible de lo que iba a ser lo que íbamos a hacer y ponernos más o menos de acuerdo. Aunque al final las decisiones de la interfaz eran principalmente criterio de Fernando.

Para organizarnos y comunicarnos usamos varias herramientas: en una sala de HipChat procurábamos llevar el grueso de la comunicación, un poco de Skype para aclarar algunos puntos, Trello para gestionar nuestras historias de usuario y tareas, y un repositorio git privado en GitHub que ponía la organización.

La aplicación está desplegada en AppFog, que proponía de nuevo la organización, y decidimos utilizar MongoDB (en MongoHQ) como base de datos. Una base de datos documental encajaba bien con nuestras necesidades, además de permitir hacer búsquedas geo-espaciales (aunque ahora no las usamos) y el plugin de MongoDB GORM que lo deja muy facilón.

Decidimos habilitar el login/registro de usuarios con Facebook y Twitter, así dejábamos el registro más fácil a los usuarios y no teníamos que preocuparnos de montar todo el sistema de gestión de usuarios. Para esto y para la integración con la búsqueda de canciones de Spotify tiramos del plugin REST client facilities y HTTPBuilder.

Mientras que para la parte de front se usa Foundation, Google Maps junto a MarkerClusterer en los mapas y jQuery para algunos detalles de interacción.

Yo creo que nos quedó un resultado más que presentable, pero algunas mejoras y funcionalidades se tuvieron que quedar fuera. Cosas como un mapa en los perfiles de usuario o que pueda funcionar bien en terminales móviles son cosas bastante evidentes. También a nivel de código hay parches nada elegantes, como controladores con más código de la cuenta, no hay un miserable test, bastante javascript guarro y mezclado con el html… Lo típico en un hackathon de estas características, vamos :D.

En fin, el tema es que el domingo conseguimos terminar (no sin nervios en las últimas horas) y hicimos el despliegue, otro entregable era un video donde se explicara el proyecto. No había un tipo de video establecido, y el marrón recayó en Raúl, os lo dejo aquí :P.

Al final resultó que en el podio terminaron 3 equipos hispanos (2 españoles y 1 mexicano). Mientras que nosotros nos llevamos una de las 3 menciones especiales, cosa que no ha estado nada mal :).

Una cosa que también me llamó la atención es que, al parecer, la organización contaba (¿cuenta?) con mentores y partners que en su momento podrían ayudar de algún modo a evolucionar a algo más serio a los proyectos participantes.
Veremos si alguno de los proyectos lo hace, en nuestro caso no creo que tuviera sentido. No deja de ser un proyecto bonito y que puede ir creciendo, pero muy complicado de hacer algo monetizable alrededor, o ganar dinero con él, que decimos los de pueblo.

Bueno… siempre nos podría comprar spotify XD.

VandalArt, ¿arte o vandalismo?

Los últimos meses he andado trabajando en proyectos de esos en los que no se luce, que bien son más empresariales, que se ha retrasado su salida al público y/o es trabajo alejado de la interfaz de usuario.

Quizás sea por eso que desde este verano ande un tanto disperso entre proyectos personales, tanto arreglando pequeñas cosas de algunos existentes, como trabajando en algunos nuevos. Tema aparte es el auto-enmarronamiento de la coordinación del grupo de trabajo de CachiruloHub, pero ese es otro tema.

Pues bien, uno de los pequeños experimentos a los que le he ido dedicando algunas horas es VandalArt.org. Una aplicación web que extrae referencias a fotos en instagram que se hayan etiquetado con ciertos hashtags (en este caso varios relacionados con arte urbano).

¿Por qué?

Por un lado porque instagram es uno de esos servicios que consulto y uso a diario, me gusta. Por otro, porque me gusta caminar por la calle y sorprenderme encontrando graffitis u otro tipo de obras que no conocía, o quedarme mirando de vez en cuando alguna que ya conozco.

Y al final se me pasó por la cabeza mezclar ambas cosas para poder ver arte urbano de cualquier parte del mundo.

¿Cómo?

La verdad que es una aplicación bastante simple. Desarrollada con Grails (el look and feel de la web lo delata ;)), utilizando el plugin de Quartz para hacer peticiones al API de instagram cada 30 minutos, de donde extrae la información de la foto y sus enlaces, pero las fotos siguen estando en instagram, por supuesto.

Como una cosa que me parecía muy curiosa era ver fotos sobre un mapa, implementé esa funcionalidad para las últimas 50 fotos subidas (y geolocalizadas). Se muestran usando la librería leaflet para interactuar con mapas, y los tiles son de cloudmade. Realmente no es gran cosa, pero creo que queda resultón.

El código está publicado en github con licencia MIT.

Be like a panda

¿Roadmap?

Tengo varias funcionalidades en mente, que supongo que haré poco a poco, principalmente:

  • Que te puedas registrar para guardar fotos como favoritas, simplemente porque te gusten o te puedan servir como forma de inspiración o por lo que sea…
  • Que funcione en tiempo real. Para este caso pienso que quedaría muy molón ver como aparecen nuevas fotos, y me apetece bastante jugar con el API Real-Time.

Y por cierto, que el proyecto ya tiene su primer fork. Para la Semana del Cine y de la Imagen de Fuentes de Ebro estaban organizando un concurso de instagram, tomando unas cervezas les comenté que posiblemente podrían aprovechar el código para hacer la web del concurso.

Y vaya si lo han hecho! Me encanta como les ha quedado la web del concurso de instagram de SCIFE :)

Grails tip: Importar direcciones de email de LaunchRock

Sigo trabajando en minchador, no al ritmo que hubiera querido (espero escribir sobre ello), pero sigo dándole.

Estoy ya preparando el lanzamiento de la beta cerrada arreglando detalles: mejorando textos, ajustando cositas de la UI, dándole vueltas al email de bienvenida, importando los mails de los que se han ido registrando en la landing hecha con LaunchRock

Pues bien, para sacar las direcciones de LaunchRock dejan a tu disposición la posibilidad de descargar los datos en un fichero en formato CSV con la siguiente estructura:

“timestamp”,”email”,”domain”,”user_clicks”,”user_signups”,”referred_by”,”ref_url”

Entonces lo que hice fue prepararme un sencillo Service de grails para importar tan sólo las direcciones, el código es el siguiente:
 

class LaunchRockService {
def emails
    def getEmailsFromCSV(csv) {
     def emails = []
     def lines = csv.split(‘\n’)
     lines.each{
     def email = it.split(‘,’)[1]
     emails << email.replaceAll(‘”‘,”)
     }
     return emails
    }
    def getEmailsFromFile(file){
     def lines = file.text.split(‘\n’)
     def total = lines.size()-1
     lines = lines[1..total]
     emails = getEmailsFromCSV(lines.join(‘\n’))
    }
    def emailIsForBeta(email){
     return emails.contains(email)
    }
}

 

Lo que hago es pasarle una instancia de File del csv de LaunchRock a getEmailsFromFile y recuperar todas las direcciones de email. En mi caso ejecuto ese método en el BootStrap de grails para tenerlas cargadas en memoria y acceder a launchRockService.emails desde otras partes de mi aplicación.

Ya puestos dejo el código junto a los tests los hice con especificaciones de Spock en un gist, por si a alguien le interesa.

Como se hizo elDisparate.de, en BetaBeers Zaragoza

Este viernes estuvimos Mamen Pradel y yo hablando en el 2º BetaBeers Zaragoza. Presentamos como hicimos elDisparate.de durante el desafío AbreDatos 2011.

En la presentación explicamos rápidamente el proyecto, los principales retos y problemas que surgieron durante el fin de semana y dimos algunas pinceladas de como cada miembro del equipo ejecutó su trabajo.

Sólo teníamos 15 minutos, pero creo que fue suficiente para poder hacerse una idea de qué hicimos en márketing, diseño, video y programación; y las limitaciones del resultado no haber tenido datos abiertos.

En fin, os dejo aquí el clásico video:

Y un post del año pasado en el que expliqué un poco lo que fue la parte de obtención de datos y programación.

El no-diseño de minchador

Algo que se me ha criticado en múltiples ocasiones, tanto delante de una cerveza como por mundos interneteriles, desde que hice público mi nuevo proyecto: minchador, es lo fea de la foto de la página de pre-registro a la beta.

No es que no sea fea, que lo es. Pero era la única foto que tenía mía que no sale gente en estado ebrio (o de camino) o parece que por la mesa han pasado una panda de cavernícolas.

Pero como dijo un tal Reid Hoffman, co fundador de LinkedIn:

“Si no te da vergüenza la primera versión de tu producto, es que esperaste demasiado para lanzar.”

Bien, esta cita de un tipo de los que podríamos llamar exitoso en esto del internet. Que no es un producto lo que lancé, pero me sirve un poco de defensa :D.

Por supuesto hay que coger con pinzas esta cita, como muchas otras, no volverse loco y salir a lo bruto; que es lo que seguramente da la sensación que he hecho yo. Pero realmente el publicar un launchrock así, en pelotas, para mi tenía su sentido por 2 cosas principalmente:

  • 1 – Comprobar el interés que puede haber en un producto así antes de empezar a invertir mucho tiempo y dinero. Principalmente de restaurantes o de posibles distribuidores/revendedores del producto.
  • 2 – Darme presión social para obligarme a dedicar tiempo para lanzarlo en poco tiempo. Aunque debo reconocer que, por razones varias, en el pasado no me resultó efectivo

La verdad que sí he encontrado cierto interés, como es obvio no muchos restaurantes para la beta inicial, pero sí un puñado de posibles revendedores. Y, cosa que no me esperaba tan inicialmente, posibles integraciones con sitios de terceros.

También he empezado a recibir esa presión de ¿cómo lo llevas?, como era de esperar :).

Por otro lado me ha servido para conocer un poco más el sector, a posibles aliados y a nueva competencia de productos que hacen cosas similares.

En realidad, no sólo de funcionalidad similar, sino de muchas más funcionalidades; cosa que espero que a la larga juegue a mi favor: Al tener un producto más simple, que sólo hace un par de cosas, tratar de ser el que mejor las hace.

En fin, que por ahora no sigue siendo más que un producto en fase de desarrollo que poco a poco ya va teniendo cara y ojos, del que estoy deseando tener entre manos ya el logo ;)

Nuevo producto: Minchador, sistema de reservas para restaurantes

Algunos ya lo sabéis. Aunque no le haya dado mucho bombo, no es ningún secreto que estoy trabajando en sacar un producto propio. Y a raíz de ello he pensado darle un poco más de vida al blog escribiendo sobre esta nueva aventurilla; principalmente porque me obligará a ordenar mis pensamientos, a hacer retrospectiva de aciertos y errores, vete a saber si también a alguien le puede servir de algún modo de aprendizaje (aunque las hostias propias enseñan más y mejor)… y si alguien me da algún tipo de feedback, ya perfecto :P.

El producto en cuestión se llama minchador. Y es una idea muy sencilla y poco original: un sistema de reservas para restaurantes.

Sí, sé que existe competencia, incluso creo que han habido proyectos/empresas con ideas muy similares que han cerrado… como en cualquier otro sector, supongo. Por supuesto que no se puede entrar a competir con proyectos con muchos más recursos con sus mismas armas, como pueden ser los directorios de restaurantes.com, eltenedor, pidemesa… que con mucha más financiación que la que yo puedo tener, parecen estar en una lucha por captar mucho tráfico, hacer más fuerza comercial llamando a restaurantes y hacer desarrollos más completos (¿complejos?).

Con este panorama (y que mi financiación es entre escasa e inexistente), está claro que hay que enfocarlo desde ya en aportar valor como para que clientes paguen por ello y salir a vender. Y no es por ir del palo Lean, buzzword con tanto hype en los últimos tiempos, es por pura necesidad.

La intención es que sea un producto diferenciado, a grandes rasgos y por orden de prioridad (totalmente subjetivo, por supuesto):

  • Simplicidad de uso tanto para los restaurantes como para sus clientes.
  • Widgets webs de los restaurantes y aplicación para páginas de facebook.
  • API para integraciones propias y de terceros.

Ahora mismo, son las 3 cosas en las que estoy trabajando, teniendo en cuenta también como se va a comercializar. Como podéis ver, pretende ser un servicio casi invisible para los clientes finales, y para los restaurantes un canal nuevo por el que recibir reservas, tratando de ser lo menos intrusivo posible a sus procesos actuales de gestión de reservas.
Por eso más a futuras me planteo cosas como desarrollar plugins para CMSs y demás hierbas, integraciones con servicios externos, posibilidad de crear webs tipo marca blanca para los restaurantes…

Hasta el momento tan sólo existe online una landing para registrarse a la beta, hecha con launchrock y una (mala) foto mía de una cena en un japonés hace la tira de tiempo; ya que por no tener, todavía no tengo logo, pero está de camino :).

Espero en un par de semanas tener una landing en condiciones y empezar la beta cerrada trabajando con muy pocos restaurantes, y poder ver así si el producto está correctamente enfocado o hay que cambiar ciertas cosas.

Por otro lado espero poder terminar de afinar el pricing (ya adelanto que, salvo giro inesperado, se cobrará por reserva) y empezar a hablar con algunos posibles distribuidores, porque ambas cosas están totalmente relacionadas.
Y cuando tenga estas dos cosas más cerradas, también escribiré sobre ello, por supuesto! :)

Elecciones al Congreso en Arredol

Como publiqué en twitter el mismo domingo del 20-N (el día de las elecciones, vamos :P), colaboré con Arredol, un pequeño diario online publicado en aragonés, desarrollando las gráficas de los resultados electorales a las elecciones del congreso español.

Fue un desarrollo exprés, ya que tenía otros compromisos que no podía dejar de lado. Fueron unas 6 o 7 horas de trabajo a tope ese mismo fin de semana, pero me apetecía colaborar por fin con algún medio, aunque fuera tan pequeñito como lo es arredol :).

Herramientas utilizadas:

  • El API que puso a disposición El País. Que básicamente hizo el trabajo que según los que defendemos el OpenData debería ser responsabilidad del Ministerio del Interior, poner a disposición de cualquier persona o entidad esos datos de forma estructurada para poder procesarlos.
  • El API de Google Charts para las representaciones gráficas. No pude adaptar los colores por partido por las limitaciones que tiene, o al menos no logré dar con la solución.
  • En el lado del servidor PHP y simplexml para procesar la información de El País. Básicamente por que el hosting de arredol sólo soporta php, no por otra cosa en especial.

Elecciones en arredol.com

Como podréis comprender, por haber sido un pequeño desarrollo hecho a toda prisa, el código en general es muy mejorable; pero el resultado cara al usuario creo que no está del todo mal.

Seguramente fuera una solución muy alejada de las herramientas de visualización de algunos grandes medios de comunicación, con una posibilidad de interacción mucho mayor. Pero en Aragón quizás fuera de lo mejor, cosa que casi me entristece.

No vi que tuviera mucho que envidiar a lo que vi que hicieron por ejemplo en la web de Heraldo, y no digamos de El Periódico de Aragón donde no vi nada especial para la ocasión… Supongo que no dedicarían muchos esfuerzos…