Nuevo diseño de etece.es


Hoy hemos subido a producción el nuevo diseño de etece.es. Con este rediseño no sólo queremos darle un lavado de cara a la web, que falta hacía, si no que perseguimos dos objetivos principales:

  1. mejorar la comprensión y experiencia de los nuevos usuarios que aterrizan en nuestra web
  2. mejorar el posicionamiento orgánico

diseño_etece

El primer objetivo, el de mejorar la comprensión de nuestro modelo y mejorar la experiencia de nuevos usuarios, estamos convencidos de alcanzarlo ya que el rediseño se ha hecho en base a los resultados de un test de usuarios que hicimos hace dos meses y donde aprendimos cómo usan nuestra web los nuevos usuarios, qué entienden de nuestro modelo y qué y dónde esperan encontrarlo.

El segundo objetivo, el de mejorar el posicionamiento orgánico, lo pretendemos conseguir mediante la inclusión de más contenido que trabaje de manera natural nuestras palabras clave. Este es más complicado porque nunca sabes a ciencia cierta si los cambios van a ser a mejor, pero estamos confiados de ver los resultados en un plazo de seis meses.

Espero que os guste el nuevo diseño y, como siempre, cualquier crítica constructiva es bienvenida.

El diseño responsive no siempre es lo mejor


Últimamente todo el mundo apuesta por el diseño responsive y tiene sentido. Con un único diseño que se adapta a los diferentes tamaños de pantalla estoy dando a mi usuario la mejor experiencia en mi web. Pero no siempre es la mejor alternativa si tenemos en cuenta las diferentes condiciones que rodean a la navegación desde diferentes dispositivos. Un smartphone puede acceder a Internet a través de WIFI o a través de la red móvil, mucho más lenta. Lo mismo pasa con las tablets aunque en este caso el porcentaje de accesos a través de WIFI es mucho mayor que a través de la red móvil. Esta sutil diferencia puede suponer que la experiencia de un usuario sea completamente diferente en función de cómo esté accediendo a Internet.

Veamos dos ejemplos diferentes:

  • etece.es
    • diseño responsive: no
    • versión web móvil: si
    • peso de la home de escritorio: 477,5 KB
    • peso de la home móvil: 140,2 KB
  • otogami.com (espero que los camaradas del metal no les importe que la coja como ejemplo)
    • diseño responsive: si
    • versión web móvil: no porque ya tienen el diseño responsive
    • peso de la home en tamaño escritorio: 478,5 KB
    • peso de la home en tamaño móvil: 473,5 KB

Como podéis ver, aunque lo esté viendo en un tamaño mucho más pequeño, el diseño responsive necesita cargar la mayoría de los elementos que existen en una versión web de escritorio y por tanto el peso de la home es prácticamente el mismo.

Si tenemos en cuenta que una conexión 3G media en España está en torno a los 1,5Mbps (fuente adslzone.net) , esto supone unos 192 KB por segundo. Es deir, la home de etece en un móvil por 3G se cargará en menos de un segundo mientras que la de otogami tardará 2,5 segundos. A lo mejor esa diferencia de tiempo no supone un cambio en la experiencia de usuario en algunos casos, aunque en algunos otros puede ser la diferencia entre que el usuario se quede en mi web y acabe convirtiendo o que el usuario abandone.

Además de las razones que tienen que ver con experiencia de usuario, hay otras razones técnicas por las cuales el diseño responsive no siempre es la mejor opción. Si consideramos que un hilo de Apache está ocupado durante todo el tiempo que dura la descarga de lo que esté subiendo, con diseño responsive estaré consumiendo 2,5 veces más tiempo que con una versión móvil específica. Eso supone recursos de mi servidor o lo que es lo mismo, podré soportar más usuarios concurrentes desde dispositivos móviles con el mismo hardware si uso una versión móvil específica frente a un diseño responsive.

Durante todo el post estoy diciendo que el diseño responsive no es siempre la mejor opción lo que quiere decir que hay veces que si que lo es. Cuando el peso de una página es bastante bajo, no merece la pena hacer una versión web y es mucho mejor tener un diseño responsive. Soy especialmente fan de los diseños responsive en webs de contenidos muy sencillas tipo wordpress y similar.

Me encantaría que este post abriera un debate y espero no quedarme solo defendiendo las versiones web móviles específicas.

¿Usarías un navegador desarrollado por Facebook?


Seguramente la respuesta fuera NO. En mi caso, sin duda, la respuesta sería no. No, porque siempre tendríamos la duda de qué uso haría Facebook de mis datos en su propio beneficio, como por ejemplo publicidad.  Igual que es la respuesta a la pregunta ¿usarías un navegador desarrollado por Google?

Vaya por delante que utilizo a diario muchos de los productos y servicios de Google. Uso Gmail tanto a nivel particular como a nivel personal, uso Drive y Gdocs, utilizo de vez en cuando Google+ para compartir contenido, tengo un móvil con sistema operativo Android, etc… Es decir, Google ya tiene muchísimos datos sobre mi vida. Pero, pudiendo elegir, no quiero que tengan mis datos de navegación. No porque esté permanentemente navegando por páginas porno o por sitios que no quiera que se sepa si no porque prefiero que esos datos estén en manos de una fundación como Mozilla que me despierta mucha más simpatía. Por eso uso Firefox, tanto en el móvil como en el PC tanto en Ubuntu como en Windows.

Está claro que hoy en día es imposible tener privacidad digital. Nuestros datos, emails, fotos, comentarios, etc… están en la red y es imposible que no lleguen a manos de las empresas. Después entramos en la disyuntiva de qué hacen esas empresas con los datos. Igual hacen como Google y firman un acuerdo con la NSA o igual los protegen como oro en paño, cosa que dudo.

Tengo la sensación de que el navegador más usado por la comunidad de profesionales técnicos y de Internet es Google Chrome. Esa misma comunidad cada vez usa menos Facebook y cada vez es más cuidadosa con lo que comparte de su vida personal en las redes sociales. No obstante, usa Chrome con la sesión de Gmail iniciada, para que no quede duda de quién es y Google pueda tener información de primera mano del uso que hace del que es, posiblemente, el software más usado en un PC, en navegador de Internet. Si Firefox no me gustara o fuera una mierda de navegador como lo es Internet Explorer, también usaría Chrome, igual que si la fundación Mozilla tuviera un webmail tan bueno o casi tan bueno como Gmail, también lo usaría en detrimentro de éste último.

Habrá mucha gente que diga que Chrome es el mejor navegador que hay, opinión que respeto y que llevaría a abrir un debate sin fin. No es el objetivo de este post. Símplemente, si no te importa, por favor, dime qué navegador utilizas y así podré confirmar o desmentir mi sensación de que los más técnicos son los que más datos de su vida le dan a Google:

Pacto de socios: estructura y cláusulas


Ayer leí un artículo interesante de Iñaki Arrola, no todo vale, donde comenta las prácticas que no son aceptables de un VC cuando invierte en una startup. Ese post tiene una serie de comentarios que merece la pena leer y donde se hace especial mención al hecho de que un emprendedor es responsable de lo que firma y en qué condiciones, con lo que estoy totalmente de acuerdo.

Tras leer y reflexionar sobre el artículo, me ha venido de nuevo a la mente lo importante que es tener un pacto de socios correcto, sencillo y que permita fácilmente que nuevos socios lo suscriban. No soy experto en pactos de socios y sólo he visto los de las empresas en los que soy fundador. Cualquier business angel tiene más experiencia y conocimiento que yo pero espero que pueda ser útil.

En etece tenemos un pacto bastante bueno y sencillo pero no tengo el visto bueno de los socios para publicarlo. No obstante, en tagUin también teníamos uno bastante bien atado y ese si que puedo, como poco, publicarlo sin datos concretos y comentar la estructura que sigue.

Como todo contrato, debe tener los diferentes apartados de primer nivel:

  1. Reunidos: donde se deben detallar todos los datos de los firmantes del pacto de socios. Si son particulares debe aparecer nombre y apellidos, domicilio, DNI y el estado civil. En caso de estar casado en régimen de gananciales, deben apareceder los datos del cónyuge. Si el firmante es una empresa, deben aparecer los datos fiscales como razón social, domicilio y CIF.
  2. Comparecen: es normal la frase “todos en su propio nombre y derecho” aunque en el caso de empresas, debe aparecer los datos del firmante representante de la empresa con nombre, apellidos y DNI. Es normal terminar este apartado con “Todos los comparecientes se reconocen mutuamente con capacidad jurídica necesaria para suscribir el presente documento. “.
  3. Manifiestan: en el caso de tagUin, aprovechamos este apartado para distinguir entre socios fundadores y socios inversores, ya que algunas cláusulas sólo aplicarán a los fundadores y así queda hecha la descripción de los grupos y a quién aplica.
  4. Condiciones: este es el punto clave. A continuación os detalle las condiciones que teníamos en nuestro pacto:
    1. Permanencia. En este puto regulamos la obligación de permanencia de los socios fundadores durante el tiempo pactado y el salario que percibirán.
    2. Competencia. Se acuerda que los socios fundadores no pueden trabajar para otras empresas del sector durante su periodo de trabajo en la empresa y durante un tiempo después. Se podría hacer extensivo, en parte, a los inversores aunque me parecería algo exagerado.
    3. Actividades paralelas. Se pretende regular cualquier tipo de actividad profesional, externa a la empresa y por la que los socios fundadores reciban remuneración. En este caso había compromiso de comunicación al resto de socios de dicha actividad y se dejaba a los socios no fundadores la posibilidad de vetar dicha actividad. Añadimos una excepción que correspondía al caso en que la empresa no pudiera pagar los salarios indicados en el punto de permanencia.
    4. Confidencialidad. Típica cláusula de no difusión de información tanto cualitativa como cuantivativa de la empresa.
    5. Salida forzada de la compañía. En caso de incumplimiento de los puntos 1,2,3 o 4 o en caso de despido procedente por causas objetivas, en este punto se regula cómo se debe proceder, cuántas particpaciones y a qué precio debe vender y a quién el despedido. A priori pensamos que todo va a ir bien pero hay que tener en cuenta que en la vida de una startup pueden pasar muchas cosas y a veces hay que tomar decisiones dolorosas.
    6. Salida acordada de la compañía. Es el caso en que todas las partes acuerdan la salida de un socio fundador. Es parecido al punto anterior aunque menos restrictivo ya que la salida es por acuerdo mutuo.
    7. Transmisión de participaciones. En este punto se acuerda que cuando hay una trasmisión de participaciones causada por el punto 5 o 6, los socios no fundadores renuncian a su derecho de adquisición preferente para que sean los socios fundadores quienes compren las participaciones de socio fundador saliente.
    8. Convocatorias. Se acuerda que las convocatorias y comunicaciones se harán por email, evitando así tener que convocar las juntas por correo certificado.
    9. Comunicación de venta. Obligación de comunicar al resto de socios cualquier intención u oferta para venta o compra de participaciones.
    10. Tag along. Este es uno de los puntos importantes del pacto. Este punto indica que, ante una oferta para adquirir participaciones, cualquier socio se puede unir a dicha operación, teniendo que comprar proporcionalmente a la oferta las participaciones a todos los que se hayan unido a la operación. Esto permite a socios minoritarios no quedarse “colgados” dentro de la empresa si hay una oferta para comprar parte de las participaciones.
    11. Drag along. Este es el otro punto importante. En él se indica la posibilidad por parte de los socios minoritarios de arrastrar al resto de socios a vender, siempre que haya una oferta para tomar el control de la compañía o por el 100%. Este punto permite a los socios inversores forzar una venta en contra de los fundadores siempre que la oferta cumpla unas condiciones. Está bien para el caso en que los fundadores están cómodos en la empresa, con buen sueldo, pero hay interés de los socios inversores, que no tiene el control de la compañía, en venderla. Nosotros en este punto pusimos dos escenarios: una oferta por el 51% o el control de la compañía; 100% de la compañía.
    12. Órgano de gobierno. Aunque es un punto que debe aparecer en las escrituras de la compañía, aquí se puede regular, en caso de haber un consejo de administración, cuántos cosejeros hay, quién los nombra y cómo se resuelven hipotéticos casos de empate.

Aquí os dejo un enlace al documento para que podáis ver la redacción exacta de cada punto.

Cualquier comentario o corrección es bienvenido, así podemos, entre todos, ir haciendo un modelo de pacto de socios que podamos reutilizar.

¿Convierte la web de Milanuncios?


El pasado jueves desayunábamos con la noticia de la venta de Milanuncios al grupo Schibsted Classified Media (SCM), dueño de los portales Fotocasa, Infojobs y SegundaMano. Es, sin duda, una de las mayores operaciones de compra-venta en el sector de Internet en España. En los pocos días que han transcurrido desde la noticias ya se ha escrito mucho en todos los medios digitales al respecto y yo no voy a aportar nada nuevo.

No obstante, quiero aprovechar para desarrollar un poco una breve conversación que tuve con Juan Macías en Twitter, iniciada por Aquilino Peña, al respecto de la conversión y el UX de Milanuncios.

Aquí os dejo la conversación completa.

Antes de nada os dejo un enlace al post que ha publicado Juan sobre Milanuncios, un ejemplo de cómo se debe argumentar una opinión. Ese es el camino que en este post defiendo a la hora de hablar sobre cosas tan objetivas como la conversión de una web.

Mi opinión es que, a pesar de las opiniones de muchos expertos, el UX de Milanuncios no es tan malo como quieren pensar. Lo importante cuando se habla de conversión son los números y en eso Milanuncios es impresionante. Estoy de acuerdo en que todo es mejorable y que no hay que quedarse sólo en el “si funciona, no lo toques”. Cuando hablamos de conversión y optimización de una web, hay que estar siempre buscando la excelencia, haciendo constantes cambios, midiendo y viendo si se ha mejorado o se ha vuelto atrás.

Pero en el caso de Milanuncios, mi TL se ha llenado de gente diciendo que la web era malísima y que no convertía. Lo decían sin datos y, sobre todo, sin haber hecho un estudio real y serio con usuarios para ver dónde falla y ver dónde y cómo se puede mejorar. Lo decían basándose en su opinión y experiencia de lo que supuestamente funciona pero sin conocer los datos de conversión de Milanuncios. Es la típica historia española: alguien tiene una historia de éxito y, en lugar de aprender al máximo de ella, buscamos sacar los puntos supuestamente malos para criticar.

Yo no soy experto en UX. Es más, apenas se nada de UX. Lo único que se es lo que los datos me demuestran y que, prácticamente simpre, me enseñan que mi primera opinión es erronea. Por ello, no voy a decir si Milanuncios convierte bien o mal, si el diseño es bueno o malo, etc… Sólo quiero decir que antes de emitir juicios de ese estilo, seamos serios y hagámoslo en base a datos reales y no sólo a opinones personales que, como todo lo subjetivo, tiene poco o nulo respaldo en datos reales.

¿Se basará el modelo de negocio de Milanuncios en la no conversión?

El health check del ELB de AWS y el contenido duplicado en Google


Como ya había comentado anteriormente, la infraestructura de etece está en la nube de Amazon. Uno de los servicios que tenemos contratados es el de balanceador de carga (ELB) para distribuir el tráfico entre diferentes frontales y así poder autoescalar cuando tenemos picos de tráfico.

Como parte de la configuración del ELB se debe definir el health check. Esto es, una petición que realiza el balanceador a cada una de las máquinas virtuales (EC2) que tiene detrás para determinar si la máquina está funcionando bien o por el contrario tiene algún problema y debe sacarla del balanceo. Este health check se configura mediante:
- protocolo
- puerto
- path de la petición
- timeout de la respuesta
- intervalo entre peticiones
- umbral no sano. Indica el número de veces seguidas en que tolera una respueta incorrecta y a partir de la cuál saca la máquina del balanceador
- umbral sano. Indica el número de veces seguidas en que recibe una respuesta correcta que espera antes de volver a meter una máquina en el balanceador

En el caso de etece tenemos configurado que pida una página cada seis segundos, con un umbral no sano de 2 y un umbral sano de 4. Esto significa que si una máquina no responde adecuadamente durante doce segundos (umbral inferior de 2 con una petición cada 6 segundos), el ELB saca dicha máquina del balanceo. Cuando esa máquina responde correctamente durante 24 segundos (umbral superior de 4 con una petición cada 6 segundos), el ELB la vuelve a incluir en el balanceo.

La petición configurada la hace el ELB a cada una de las EC2 haciendo uso de su DNS público. Esto es un nombre público que tiene cada EC2 durante su tiempo de vida. Si paras la máquina y la vuelves a levantar, cambia su DNS público por lo que no puedes ni debes hacer ninguna configuración mediante ese nombre ya que va a cambiar. Además, si tus frontales autoescalan, todos ellos serán iguales, con la misma configuración pero con diferente DNS público.
Es decir, si yo tengo un EC2 sirviendo peticiones para el dominio midominio.com y ese EC2 tiene un DNS público que es ec2-xx-xx-xx-xx.eu-west-x.compute.amazonaws.com, el ELB va a hacer la petición http configurada en el parámetro path de la petición (por ejemplo /index.html) a este nombre público. Va a pedir http://ec2-xx-xx-xx-xx.eu-west-x.compute.amazonaws.com/index.html. Lo que comprueba el health check es el código de respuesta, dándo únicamente por válida una respuesta 200. Cualquier otra respuesta es considerada respuesta erronea. Por tanto, no puede haber ninguna redirección en esa respuesta.

Hasta aquí no he contado nada nuevo y seguro que muchos ya estáis pensando que soy un poco pesado. Pero cuando empiezas a tirar de la cuerda es cuando ves que hay más tela que cortar y que hay que hilar fino.

Configuración del virtual host de Apache
Si quieres que tu web responda correctamente al health check del ELB evitando las redirecciones, debes tener configurados los virtual host de Apache para que respondan por midominio.com y para el DNS público, que es un valor dinámico. Se podría resolver muy facilmente haciendo que el virtual host de midominio.com sea el virtual host por defecto y todo resuelto. Si pero no. Aquí es donde entra nuestro colega Google.

Si alguna vez, por comprobar el funcionamiento de tu EC2 o porque tienes el EC2 fuera del ELB, haces una petición de tu web por el DNS público, se van a imprimir todos los pixels de analítica, remarketing, conversión etc… que tengas en tu web, pero con un nombre de servidor que no es el de dominio. Google es muy listo y se guarda esa info en algún lugar para luego volver a ella y lo normal es que te indexe varias páginas iguales respondiendo por midominio.com y el DNS público. Total, mismo contenido con dos URLs y eso es penalización segura. Hay que corregirlo en cuanto te das cuenta. En el caso de etece, no somos tan listos como para habernos dado cuenta nosotros solos. Ha sido nuestra amiga Noe la que nos ha avisado del percal. Gracias Noe!!!!

Solución
Después de darle varias vueltas a las diferentes alternativas, hemos decidido que la que más nos gustaba era configurar el virtual host de midominio.com para que redirija todas las peticiones que gestione a midominio.com excepto cuando el user-agent de la petición es el que usa ELB para hacer las peticiones de health check (ELB-HealthChecker/1.0). En ese caso responde por el DNS público y en cualquier otro caso, hace una 301 a midominio.com. De esta manera evitamos que se respondan peticiones por dos URLs distintas y el ELB puede hacer el health check correctamente. Para ello hemos recurrido a la directiva RedirectRule en base a algunas condiciones expecificadas en la directiva RewriteCond, ambas del mod_rewrite de Apache.

Nuestra configuración ha quedado así:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteCond %{SERVER_NAME} !midominio.com
RewriteRule /(.*) http://midominio.com/$1 [L,R=301]

 

– ACTUALIZACIÓN 11-07-2013

Si usas CloudFront como CDN usando subdominios de tu dominio, que son servidos por el mismo server, la configuración que había publicado no funciona correctamente ya que, al no ser una petición con el SERVER_NAME midominio.com, al venir desde CloudFront, la regla le hace una 301 a midominio.com y por tanto estaría sirviendo todo el contenido estático nuestro servidor, perdiendo las virtudes del CDN. Por tanto, hay que incluir una nueva condición para evitar la redirección si quien lo pide es CloudFront.

Nuestra nueva configuración ha quedado así:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteCond %{HTTP_USER_AGENT} !Amazon\ CloudFront
RewriteCond %{HTTP_HOST} !midominio.com
RewriteRule /(.*) http://midominio.com/$1 [L,R=301]

Para el que no esté muy suelto con las directivas de Apache, esto lo que significa es:

Activamos el motor de reescritura
Si el user-agent de la petición NO es ELB-HealthChecker/1.0 Y….  –> Si es ELB-HealthChecker/1.0 entonces no se hace nada
Si el user-agent de la petición NO es CloudFront Y….  –> Si quien hace la petición es CloudFront entonces no se hace nada
Si el nombre de dominio pedido NO es midominio.com entonces…  –> Si el nombre de dominio ya es midominio.com no se hace nada, de esta manera se evitan los bucles de redirecciones
Se hace una 301 a midominio.com

Espero que este breve artículo le sirva a más de uno para evitar un problema de duplicidad de URLs. Es cierto que lo podía haber explicado de manera más breve pero creo que así se entiende mejor. Como siempre, cualquier comentario o corrección es bienvenida.

Qué enseñar hoy a los niños ante un futuro profesional tan complicado


Esta noche estaba cenando en casa, con mi hijo de dos años y poco sentado a mi lado y con la cabeza llena de reflexiones varias. Me apetecía escribir un post para mi blog pero no tenía claro sobre qué escribir. Entonces puse un tweet pidiendo ideas y Rosa Poo, fundadora de emprendekids.com, me contestó sugiriéndome el título de este post. En ese momento me puse a darle vueltas a este tema intentado ordenar todas las ideas y, sobre todo, a pensar en qué me gustaría transmitir a mi hijo y a su generación en relación a este tema.

Cómo veo el futuro profesional
El entorno laboral está en continuo cambio. A temporadas el cambio es lento y otras veces es vertiginoso. Cómo era cuando nuestros padres eran jóvenes es muy diferente a cómo es ahora y a su vez es muy distinto a cómo será cuando mi hijo esté en edad de trabajar. Ya no habrá trabajos que duren toda una vida. El marco legal se habrá adaptado a contrataciones y despidos rápidos y baratos, no habrá cotizaciones para las pensiones porque no habrá. Los buenos profesionales y aquellos que tengan el mayor talento dominarán el mercado y serán el modelo a seguir. En resumen, será un entorno bastante hostil y complicado.

No todo ha cambiado y algo no cambiará
La vida me ha enseñado que las cosas te pueden salir bien o mal, puedes tener más o menos talento o facilidad para determinadas cosas e incluso puedes tener la suerte a favor o en contra pero el esfuerzo siempre tiene su recompensa. He visto a gente que ha suplido su mala suerte, falta de talento o pérdida de capacidad con esfuerzo y además se trata de una circunstancia prácticamente invariable con el tiempo.

Sin saber cómo va a ser la vida que va a vivir mi hijo, si tuviera que enseñarle una sola cosa que le fuera a valer profesionalmente en su vida sería a esforzarse. Esfuerzo constante y sincero. El esfuerzo sincero parte de la base de conocerse a uno mismo, saber hasta dónde se puede llegar con el mínimo esfuerzo y a trabajar diariamente para ir más allá de esa barrera del mínimo esfuerzo para conseguir los objetivos marcados. Ese esfuerzo, con el tiempo y el trabajo, se convierte en rutina y entonces es cuando se llega a un punto en el que se puede afrontar cualquier reto con garantías. Además, afrontar las cosas con este esfuerzo constante y sincero hace que se vivan los fracasos de otra manera, sabiendo que se ha hecho todo lo posible y asumiendo las limitaciones reales de uno mismo, pudiendo construir a partir de ahí.

Eso es muy fácil de decir pero muy difícil de hacer. No soy educador, tengo poca experiencia docente y soy padre primerizo por lo que, casi seguro, soy el menos indicado para decir cómo se debe inculcar la cultura del esfuerzo a los niños. No obstante me gustaría aportar mi granito de arena en la formación de una nueva generación que tenga entre uno de sus pilares el esfuerzo.

Hoy me he puesto bastante más reflexivo y profundo de lo que acostumbro, pero prometo volver a mis post de carácter más técnico en breve.