Un tip rápido para aquellos que añaden cosas de Facebook a sus blogs, en este caso el Share con el globito que cuenta la cantidad de veces que fue compartido un enlace.

Si lo intentaste hacer, ya sabés que el tutorial oficial es muy simple de seguir, un copy/paste y sale con fritas…
Pero si todo fuese taaaaaan facil, entonces no habrías llegado a esta web, ya que existe un problema por el que necesitás hacer click en el share para que te aparezca el globito. Los programadores de Facebook implementaron el hecho de que muestre el globito con la cantidad de shares sólo cuando se haya compartido, como mínimo, tres veces.
Eso quiere decir que hasta que alguien no haga click y lo comparta con sus amigos (y esto, tres veces…) no se va a ver ese diseño tan lindo que querías poner. Entonces, tenés que hacer trampa, y te digo cómo:
1) Parche facil, pero no elegante: el javascript de Facebook hace la cuenta de cuántas veces compartieron tu enlace, y si el resultado es menor a tres, entonces añade la siguiente class al span que hará al gobito:
.fb_share_no_count{
display:none;
}
Entonces la solución es sobreescribir el display none. Si al botón lo colocamos dentro de un div con id share, entonces:
#share .fb_share_no_count{
display:block;
}
Esto sólo mostrará el globito, dentro de él no habrá ningún número, aunque se haya compartido una o dos veces, eso no se mostrará.
2) Parche copado, pero de tiempo limitado: para implementar esta utilidad, copiaste un código javascript, el cual es:
<a name=”fb_share”></a>
<script src=”http://static.ak.fbcdn.net/connect.php/js/FB.Share”
type=”text/javascript”>
</script>
Si en vez de llamar externamente a ese javascript, hay que bajarlo y editarlo, más específicamente hay que buscar la siguiente línea:
this.displayBox(a,3);
¿Ya se imaginan que quiere decir ese 3? Entonces, hay que cambiar al 3 por un 0, guardar, subir el .js a nuestro servidor, y hacer la llamada localmente. Esta solución está publicada en Patrick M. Kelly’s Bulletin Board.
Cuál es el problema de esto? que la semana que viene, o dentro de un mes, o cuando sea, Facebook va a cambiar la programación del Share. Cuando eso suceda, tu programación editada puede llegar a no funcionar.
Estará en cada uno evaluar qué camino seguir.
Esta etapa de trabajo freelance en la que me embarqué ya se ha extendido por 9 meses. Tiempo durante el cual la vengo pasando muy bien. Sin moverme demasiado, trabajo no me está faltando, lo que es muy bueno. Es por la no falta de trabajo que en este sitio aún no figura mi portfolio con mis últimos trabajos. Esto no quiere decir que si pongo el portfolio online es porque no tengo trabajo, no sean literales. Sólo quiere decir que pude tomarme todo este tiempo para pensar bien cómo quiero que se muestre todo.
Hablando exclusivamente de trabajo freelance, me voy a permitir escribir unas líneas sobre el armado de presupuestos. Tal como dije en el post anterior, guías para ser freelance hay muchisimas, estos posteos no pretenden ser otra cosa que mi visión sobre temas muy puntuales.
Un trabajo freelance empieza por el contacto con el cliente, donde se transmitió una necesidad, y uno puede satisfacerla. Uno empieza entonces a bosquejar en mente varias ideas, de diseño, desarrollo, usabilidad, publicidad, etc. Pero más importante aún, tiempos, costos y equipo de trabajo. Estas obligado a presupuestar, no interesa si sos estudiante y estas leyendo esto porque tenés curiosidad sobre el trabajo freelance, necesitas hacer un presupuesto. Con el correr de los trabajos, los documentos que hago con presupuestos empiezan a ocupar más y más carillas. Los primeros fueron de tres, ahora son 4 o 5… por supuesto que depende del trabajo en sí, ya me van a entender.
Órden de trabajo: suelen ser uno o dos renglones. Muy simple, “Se requiere hacer un sitio web” es perfectamente viable.
Breve detalle: sirve para explayarse en el trabajo. Por ejemplo, si el sitio tendrá administrador, usuarios, carritos, blog, etc. Se intenta nombrar los ítems que habrá (si existe ya un árbol de navegación, va acá), pero no cómo van a funcionar.
Detalle técnico: En este espacio sí se dice como va a funcionar todo lo que se mencionó antes. No hace falta decir detalles de cómo se va a programar o maquetar, pero sí que hará en x lenguaje, o siguiendo estándares, que validará en tales navegadores, etc.
Requerimientos: fácil, que necesitamos que nos dé el cliente para poder hacer todo lo que dijimos que sabemos hacer.
Alcance: es el espacio donde se pone en claro dónde termina mi responsabilidad y empieza la del cliente o la de terceros. Por ejemplo, si preveo que puede existir un problema legal porque el cliente insiste en copiar, este es el espacio en donde pongo de preaviso al cliente. Si el trabajo requiere SEO, suelo aclarar que mi servicio es (precisamente) SEO y no posicionamiento, ya que para primeras posiciones se requiere otro tipo de trabajo.
Tiempo de trabajo: cuánto me va a llevar. Esto va de la mano con algunos puntos de requerimientos y alcances. Entonces, siempre vale la aclaración de que si el cliente no entrega el material, uno también lo hace.
Valor: cuánto cuesta, porcentajes a cobrar, y formas de pago.
Documentación: para hacer un presupuesto, seguro que el cliente nos mostró una web (o lo hicimos nosotros para graficar algo), o nos pasó algún .doc o .jpg, etc. Todo lo que nos haya pasado y que se usó para presupuestar, va acá.
Otras cosas que se pueden añadir pueden las relativas al contrato de terceros, desde fotografías hasta el servidor. Otro punto puede ser sobre la propiedad intelectual.
El que estoy evaluando agregar, pero depende muchísimo del cliente y proyecto, es qué sucede cuando se extiende el período de bocetos de diseño, lo cual va de la mano con que se supone que alguien te contrata no para ejecutar el diseño que él tiene en la cabeza, sino para que uno pueda traducir una necesidad en la mejor resolución visual.
Es un poco más complicado, porque básicamente se trata de decir que la persona idónea soy yo, y no el cliente. Y al menos por ahora, no se me ocurre una forma de decirlo sin que lleve a un malentendido.
Escucho sugerencias…
Thunderbird es el cliente de email compañero de aventuras de Firefox. Thunderbird tiene cosas que claramente debe mejorar en cuanto a usabilidad, especialmente el lector de blogs, dar de alta un feed es muy complicado. Más allá de esto, les doy una guía de pasos para crear una firma con imagen embebida, cosa que si bien no es dificil, tampoco está facil.
Lo importante a entender, es que una firma en Thunderbird siempre es un archivo aparte, que el programa lee y añade al final de nuestro email. O sea, si yo hago un archivo llamado firma.txt, cuyo contenido es “Nicolás Flores”, ya tengo mi firma. Entonces, para setear este archivo como firma, Herramientas/Configuración de cuentas:

Si yo quiero poner en mi firma una imagen, entonces no me sirve setear un archivo .txt como firma. Para hacer esto necesito un archivo .html, y configurar una etiqueta de imagen, con la ruta correspondiente al archivo. No es necesario que el archivo se encuentre en un servidor web, puede estar en una carpeta en mi PC.
Para hacer un archivo html necesitamos un notepad común y corriente, en donde ponemos:
<img moz-do-not-send="false" src="file:///C:/turu.jpg" alt="Turu">
Editamos la ruta con el nombre del archivo correcto, y listo!
Es importante utilizar el parámetro alt, ya que si el receptor del email tiene bloqueado el codigo html que hace posible ver una imagen, en su lugar colocará el texto que pongamos allí.
Cuando enviemos un email, es probable que nos pregunte si deseamos enviar el email en formato html o texto. Elegir html por razones obvias…
Hace unas semanas me encontraba leyendo sobre este truco de css para escalar imágenes en Internet Explorer sin que se vean pixeladas. Quedó como una curiosidad, pero no le ví un uso práctico.
Hoy se lo encontré. Estas semana estuve arreglando un back office y un front, y hoy notaron que las imágenes de los productos subidos por BO tienen un tamaño distinto al utilizado en el front. Como las subidas eran más grandes, bastó con esa simple línea de css:
img{
-ms-interpolation-mode: bicubic;
}
y listo.
En los últimos meses me preguntaron en distintas ocaciones sobre SEO y SEM. No es precisamente algo en lo que me especializo, o sobre lo que esté leyendo constantemente. Lo que sí me interesa en relación a SEO es la web semántica, escribir bien para que se guarde un sitio correctamente.
Luego de esta introducción, les cuento brevemente de qué se tratan. Entonces, qué es SEO y SEM?
SEO: Search Engine Optimization. Es preparar un sitio web para que los buscadores (soy generoso con el plural… google) puedan “ver” una página correctamente. O sea, que todo el contenido sea guardado correctamente en la base de datos del buscador. Esto es para que cuando alguien hace una búsqueda, con tus páginas bien guardadas, te puedan encontrar en los primeros resultados de la búsqueda.
Tareas SEO: correcta maquetación del sitio, keywords apropiados, titles apropiados, contenido acorde a esas keywords y títulos, sitemap.xml.
SEM: Search Engine Marketing. Cuando hacés una búsqueda, en google por ejemplo, aparecen sobre el costado derecho links con otro color de fondo, y a veces entre los primeros resultados. Esas posiciones y keywords fueron pagas. Yo pago para que con la palabra “xxxxx” mi sitio web aparezca primero de todo, pero siempre será con otro color de fondo, para indicarle al usuario que esa no es una posición natural.
Para SEO se le debe pagar al diseñador, si es que no lo ofrece como parte de la calidad de su trabajo (debería!). Para SEM, se le paga al buscador que ofrece este servicio (google, yahoo…).
Lo que queda un poco entre medio es lo que se conoce como “ruido”.
Ruido: cuántas y qué páginas están hablando de mi sitio. Si yo tengo un sitio web correctamente hecho, indexado en google, etc. pero no me conoce nadie, entonces nunca voy a figurar en las primeras posiciones… quitemos el buscar la url de tu sitio, ahí siempre vas a estar primero.
Cualquier agregado y corrección, adelante…
En el tiempo en que llevo trabajando en Interactive, aprendí que algo a lo que hay que prestarle un poco más de atención en la etapa de test es a los e-mails marketing. Debido a la ausencia de estándares, y que corporativamente se utilizan clientes de email como lotus o outlook pero el público en general utiliza webmails, uno se ve obligado a reducir las piezas html a una serie de reglas para performar correctamente en todos los medios.
Como no suelo encontrar guías en la web sobre este tema, comparto la que uso diariamente. Agreguen o corrijan lo que crean necesario:
<font face=”arial, helvetica, sans-serif” size=”1″ color=”#666666″ style=”font: normal 10px arial, helvetica, sans-serif; color:#666666;”>Lorem ipsum dolor sit amet</font>
De esta forma se asegura que el texto tenga el formato deseado, ya sea por “style”, o por los antiguos parámetros. Lotus usará face=”arial, helvetica, sans-serif” size=”1″ color=”#666666″, los webmails style=”font: normal 10px arial, helvetica, sans-serif; color:#666666;”.
La equivalencia en tamaños de tipografía sería:
- 10-11 = size 1
- 12-13 = size 2
- 14+ = size 3
Notar el retraso importante que se tiene en materia de email. No conozco a nivel mundial la eficacia que tiene un email marketing. Sí sé la eficacia que tienen en los sitios que maneja la agencia, porcentaje alto cuando el email se convierte en una pieza de comunicación y deja de ser un “correo no deseado”.
Más sobre eficacia de email marketing en Dossiernet.
Para los que como yo quieren poner tildes en los alertas de javascript:
Durante estos años, 9 para ser precisos, he ido aprendiendo todo lo que sé sobre diseño web. Al principio html, diseñando con FrontPage. Después conocí la suite Macromedia, con Flash y Dreamweaver 4, y el primer lenguaje de programación web más fácil de aprender, ASP. Conexiones a bases Access, muy simples de hacer.
Luego aprendí PHP y MySQL. Toda esta introducción es porque nunca jamás volví a usar ASP, hasta ahora que por trabajo me veo obligado a actualizarme.
Aquellos que quieran programar páginas web, sabrán (o aprenderán) que necesitan un servidor local (o sea, en sus máquinas) para hacer las pruebas.
Uno puede instalar para Windows el IIS (está en el disco de instalación, busquen
), pero por supuesto me gusta complicarme, entonces uso Apache. Que está muy bien, salvo por el hecho que sirve para PHP.
Como no quiero tener dos servidores corriendo en paralelo, busqué el camino para instalar ASP en un servidor Apache. Y por supuesto, lo comparto. Sugerencias, configuraciones, mejores pasos a seguir, etc, añadirlos en los comentarios.
Para ser sincero, no creí que me fuese tomar poco tiempo. Me imaginaba peleando contra configuraciones. Pero al googlear: "asp net apache" inmediatamente dí con el post del blog de Ohad How to make Apache run ASP.NET / ASP.NET 2.0, de donde obtuve casi todos los pasos.
La guía es muuuuuy clara, salvo en un detalle. Antes de ponerte a instalar y configurar Apache, se debe instalar el .NET. Por lo que los pasos son:
Luego seguir con los pasos de la guía:
Y eso es todo. Dejen preguntas, comentarios, cómo mejorar la guía, otros pasos, etc.
Cumpliendo promesas, inauguro los tutoriales para aprender diseño web desde cero.
A quién le puede interesar?
A estos últimos les digo que si bien mis palabras pueden sonar soberbias, la idea es más bien que se lo tomen como un desafío profesional, tal vez personal.
O si prefieren destruirme, los invito a que encuentren los miles de errores que seguro existen y me los hagan saber, así añado sus correcciones para ir perfeccionando las técnicas de todos (no olviden de dónde aprendieron lo que saben, y que está bueno devolver algo de lo mismo).
Antes de entrar de lleno en el armado y diseño de páginas web, hagamos una breve reseña de aquellos conceptos que a lo largo del curso se van a ir mencionando, y que pasarán a formar parte de un lenguaje común:

El lenguaje que interpretan los navegadores web es el html. Por lo que para hacer una página web necesitamos conocerlo.
Un documento html es un archivo de texto. La diferencia entre un archivo .txt y uno .html radica en las etiquetas presentes en este último. Las etiquetas sirven para orientar al navegador en la forma de estructurar el contenido (títulos, subtítulos, párrafos, listas, etc). En este punto profundizaremos más adelante. Por ahora debemos tener presente que para crear un archivo .htm o .html sólo nos hace falta un editor de texto, desde un simple bloc de notas a alguno más complejo. Recomiendo el Notepad++, aparte de ser el bloc de notas que todos conocemos, trae incorporados otros lenguajes de programación que nos permite una mejor visualización por medio de colores, aparte de ser gratuito y Open Source.
En un futuro veremos que el principal problema que econtraremos es la falta de compromiso de algunas empresas de software al momento de diseñar navegadores que respondan a los estándares divulgados para la correcta interpretación del lenguaje empleado en un documento html. Esto implica un trabajo extra del diseñador al no sólo diseñar una página, sino a corroborar la correcta interpretación de la misma por diferentes navegadores.
La base de la sintaxis de este código es la etiqueta. Por ejemplo:
<etiqueta>texto de prueba</etiqueta>
La primera etiqueta activa una orden que afecta a nuestro contenido, siendo la segunda etiqueta con el signo “/” por delante la que pone fin a la misma.
Veamos un ejemplo práctico. Para obtener un texto con negrita, la etiqueta es <b>. Por lo que si queremos lograr:
texto de prueba
El código html será:
texto de <b>prueba</b>
Un documento html cuenta con una estructura a respetar para la correcta visualización por parte de los navegadores. Una estructura básica es:
Lo que vemos es que todo el documento está contenido en la etiqueta <html>, luego contamos con un encabezado, y finalmente un cuerpo. Con esto en mente, crearemos nuestra primera página. Si en un editor de texto escribimos el siguiente código:
Lo guardamos como ejemplo_1.htm y lo abrimos en nuestro navegador:

Ya empezamos a escribir en lenguaje html.
Algunas consideraciones en el manejo de archivos:
Pueden ver el ejemplo_1.htm.