Un carnicero estaba abriendo su tienda una mañana cuando de pronto un conejo asoma la cabeza por la puerta. El carnicero se sorprendió cuando el conejo le preguntó “¿Tienes repollo?” El carnicero le dijo “Esta es una carnicería – vendemos carne, no vegetales.” El conejo se retiro saltando.
Al día siguiente el carnicero abría su tienda y al mismo tiempo el conejo asomó su cabeza y dijo “¿Tienes repollo? El carnicero ya irritado dice “Escúchame pequeño roedor te dije ayer que vendemos carne, que no vendemos vegetales y la próxima vez que vengas aquí te voy a coger del pescuezo y voy a clavar tus orejas aguadas al piso.” El conejo desapareció rápidamente y nada pasó por una semana.
Entonces una mañana el conejo asomó su cabeza desde la esquina y dijo “¿Tienes clavos?” El carnicero le dijo “No.” El conejo dijo “Ok. ¿Tienes repollo?”
¿Moraleja?
Hoy no entendía porqué mi llave API para Google Maps no funcionaba, lo único que recibía de Google era el error:
The Google Maps API key used on this web site was registered for a different web site. You can generate a new key for this web site at http://code.google.com/apis/maps .
Que raro… seguí la recomendación y volví a generar mi llave y pues nada, recibía el mismo error no importaba que hiciera.
El gotcha está en que ya es obligatorio agregar el parámetro “sensor” al URL de donde llamamos el javascript de Google.
Entonces debe quedar así:
<script src="http://www.google.com/jsapi?key=GOOGLE_MAPS_KEY&sensor=false" type="text/javascript"></script>
El valor de sensor puede ser false o true, dependiendo de la aplicación que estés desarrollando. Esto está perfectamente explicado en la documentación de Google Maps.
Que difícil corregir un error cuando el mismo error es un error ¿no?
DeJuarez.com a sus cortos 3 meses de estar operando empezó a recibir su generosa dotación de spam en los comentarios. A pesar de que implementé un sistema muy rudimentario antispam esté dejó de ser eficiente en manos de los expertos spammers.
Una solución puede ser diseñar un sistema mas robusto para impedir el spam, pero ¿para qué reinventar la rueda si ya existe reCAPTACHA?
Hacerlo funcionar en una aplicación de Ruby on Rails es muy simple usando un plugin:
script/plugin install git://github.com/ambethia/recaptcha.git
<%= recaptcha_tags if session[:recaptcha_verified].nil? %>
if verify_recaptcha # ya validado, no hay porque seguir molestando al usuario session[:recaptcha_verified] = true @comment.save! redirect_to article_path(@comment.article) else flash[:error] = "Vuelve a escribir el reCAPTCHA." render :new end rescue ActiveRecord::RecordInvalid flash[:error] = "Corrige los errores marcados en rojo." render :new
El espacio recomendado entre elementos va a variar dependiendo del estilo de sus formas. Lo recomendable es entre el 50 y 75% de la altura de sus cajas. En este caso la altura es de 26px, por lo cual se asigna 13px (50%) de distancia entre la etiqueta y la caja, y 19px (75% de 26px) entre caja y caja.
Esta es un “heat map” que muestra lo que los usuarios están enfocando al llenar una forma web.
En la imagen anterior claramente se puede observar como se marca una fuerte línea vertical que va recorriendo todos los elementos cuidadosamente acomodados en una estructura lineal. Esto facilita al usuario escanear la información que se le presenta en pantalla.
En este par de imágenes a continuación podemos ver un antes y después, noten que la información es la misma, solo se ha modificado la alineación y el orden de los elementos.
Para escanear esta imagen hay que dirigir la vista en un patrón de zig-zag.
En esta otra forma podemos escanear la información en una línea vertical.
Esta y mas información la pueden obtener del libro que mencioné en este post.
Juan Pablo segundo, Carlos quinto y Benedicto ¿décimo sexto o dieciséis? La explicación es esta: Para designar siglos, reyes o papas se usa el ordinal hasta el diez. De esta manera Pío X es décimo y Pío XII es doce. La misma regla aplica para dinastías egipcias. Ahora ya saben.
Todo sitio web invariablemente va a necesitar de una forma o formulario, ya sea para dejar tus datos al comprar algo online, para escribir en un blog y hasta para dejar un comentario. Llenar formularios es un asco, a nadie le gusta, es por esto que hay que hacerlo lo mas práctico y sencillo posible.
Estoy leyendo un libro que está íntegramente dedicado al tema de los formularios, se llama Web Form Design - Filling in the Blanks escríto por Luke Wroblewski. He leído al momento hasta el capítulo 2 y me ha confirmado algunas cosas que por lógica suponía eran las correctas, y de paso he aprendido otras mas que nunca me había puesto a pensar.
Al final de este capítulo viene una liste de “Best Practices” que he traducido para compartirlas con ustedes.
Si diseñan sitios web no pueden dejar de leer este libro.
The bird image is from Twitterrific by Iconfactory | The bird's hat is from ~LoafNinja
Uso WordPress para gestionar las anotaciones