Gerry McGovern da en el clavo. En su artículo Search optimization, not search engine optimization lo resume del siguiente modo:

Search optimization focuses on how people search. Search engine optimization focuses on how search engines work. Search optimization sees quality web content as its foundation stone.

http://www.gerrymcgovern.com/nt/2005/…

Si bien search engine optimization o SEO es un asunto relevante para la evolución de los propios buscadores y la optimización del servicio, frecuentemente se confunde la terminología y se utiliza este concepto para hablar de la optimización del contenido para mejorar la puntuación o ranking en los resultados de búsqueda. Normalmente los blancos de esto son buscadores grandes como Google, Yahoo! o MSN. Podemos encontrar innumerables sitios y hasta libros dedicados al tema, como Google Guide y el Google Ranking Factors – SEO List.

Es cierto que se pueden usar trucos para obtener una mejor posición en los resultados, pero lo mejor que podemos hacer es optimizar el contenido. El uso apropiado de términos clave en ubicaciones precisas, como los títulos (h1..h6), son una clara señal de que el documento trata sobre aquelos temas. La repetición de las palabras más relevantes, el uso de términos alternativos, destacar apropiadamente mediante em o strong y la referencia a otros sitios relacionados mediante vínculos cuidadosamente seleccionados. Es clave plantearse de qué forma los usuarios buscarán la información para establecer tanto los términos más importantes y las formas alternativas para ofrecer resultados.

Por ejemplo, esta nota está titulada Optimización de Búsqueda, No de Motores de Búsqueda, lo que seguramente hará pensar a Google, Yahoo! o MSN que esta página en particular trata sobre el tema de buscadores. La palabra Búsqueda está dos veces en el título y eso no es coincidencia. Luego, hasta este punto he repetido la palabra búsquedacuatro veces más en el contenido de este post. Eso cuenta, pero también he usado variaciones como buscador o buscadores. Para reforzar el concepto menciono al principio a tres de los buscadores más importantes que por los logs del servidor me consta visitarán esta página minutos después de ser publicada: Google, Yahoo! y MSN (aquí los estoy repitiendo nuevamente). junto con todo esto, he utilizado HTML (cite, strong, em) para destacar ciertas palabras e indicar así que son relevantes.

Y finalmente, hay una serie de vínculos, no demasiados, que refuerzan el tema que estoy tratando. Creo que si revisamos en unos días, esta página debería tener una buena posición en resultados de búsqueda para términos como búsqueda, buscador, e incluso Google.

Existen algunas herramientas que pueden ser utilizadas para analizar las palabras clave dentro de un documento, su ocurrencia y relevancia. Por ejemplo, puedes analizar este mismo post en seokeywordanalysis.com o www.webmaster-toolkit.com, que fueron dos resultados que obtuve rápidamente buscando en Google.

Y para concluir, ¿Por qué estoy haciendo esto? En realidad es para probar un punto y para aprovechar la oportunidad de hacer un experimiento interesante. Si ustedes comentan en esta nota, más posibilidades tendrá de mejorar su posición. Pero esta parte es un juego, planteemos una situación mucho más seria: ¿cómo garantizar que el contenido dentro de una intranet esté correctamente indexado, y que los funcionarios o empleados encuentren lo que necesitan rápida y efectivamente? Con estas mismas técnicas. Los buscadores no son muy diferentes unos de otros, y las herramientas de búsqueda de los sistemas de publicación comerciales operan de modo similar. Finalmente, la forma en que planifiquemos, organicemos y escribamos el contenido es muy relevante y beneficiará a los usuarios, permitiéndoles encontrar la información de un modo más eficiente.

Desde hace un par de días he estado trabajando en la plantilla de WordPress para EFH, y la referencia obvia para esto es el tema por defecto de WP, Kubrick. De hecho la mayoría de los temas disponibles son básicamente modificaciones de kubrick. Sin embargo mientras estoy revisando el CSS noto algunas cosas que me molestan y son básicamente la razón por la que he partido casi desde cero con mi nuevo tema. Se trata del uso nombres de clases que se refieren a la presentación, a características de diseño, antes que a describir la lógica o estructura del contenido.

He hablado antes sobre la importancia del uso semántico de HTML, es decir, de utilizarlo como un descriptor de la estructura del contenido. El código HTML de un documento debe hablar sobre su estructura interna, debe dar pistas del tema tratado. Su estructura de títulos debe ser una pauta de la jerarquía del contenido y cada uno de los demás elementos debería utilizarse de modo que su significado aporte sentido al contenido.

Del mismo modo, las clases o atributo class no deberían referirse a características de comportamiento o presentación. Es así como lo han entendido quienes están detrás del interesante proyecto de microformatos, Tantek Çelik y Eric Meyer, que básicamente utiliza el atributo class para dar significado nuevo al contenido.

El nombre de una clase debería ser neutro respecto a factores de presentación, por ejemplo, div class="alignleft" no es mejor que div align="left". Es cierto, valida, pero ése no es el objetivo detrás de la separación de contenido y presentación que permite CSS. Es mucho más lógico utilizar algo como div class="plantilla-bloque-a" que no determina la forma en que los elementos que declaren la clase plantilla-bloque-a serán presentados. ¿Qué sucede si en un rediseño decidimos cambiar todos aquellos elementos que antes, usando la clase alignleft, estaban alineados a la izquierda y ahora los centramos? Quedaremos con una incongruencia en que el HTML dice div class="alignleft" pero el elemento aparece centrado.

Para finalizar, les propongo algunas pautas para revisar los nombres de las clases que creemos en CSS/HTML:

• Comprobar que el nombre no describa una característica visual, como color, tamaño o posición
• Comprobar que el nombre no describa una función o comportamiento
• Verificar que el nombre describa el significado o tipo de contenido que describe
• Asegurarse de que el nombre es lo suficientemente específico y no crea confusiones con otros nombres similares
• Asegurarse de que el nombre es lo suficientemente claro como para que otros leyendo el HTML entiendan su significado y propósito
• Asegurarse de que el nombre será apropiado en el futuro, previendo en lo posible la forma en que el documento y el contenido puedan evolucionar

Una pauta clásica de las evaluaciones heurísticas de usabilidad se refiere al uso inapropiado de signos de exclamación en los mensajes del sistema a los usuarios. Se trata básicamente de no generar alarma innecesaria o de no utilizar un tono inapropiado que pueda intimidar al usuario generándole inseguridad.

Do error messages avoid the use of exclamation points?

Los signos de exclamación son elementos de puntuación con un significado específico: crean énfasis, destacando una palabra o frase. Por lo mismo, lo podemos aplicar adecuadamente para destacar situaciones riesgosas o que merezcan notarse especialmente, por ejemplo en:

¡Atención! ¿Está seguro de que desea eliminar el mensaje?

Pero si se trata de una alerta normal para indicar al usuario que faltan datos obligatorios en un formulario, no es necesario alarmarlo:

Faltan datos!!!!!

Esto puede parecer evidente, pero lo he observado con bastente frecuencia en varias evaluaciones. No olvidemos que los mensajes, instrucciones y la ayuda son parte de la interfaz de un sitio, aplicación o un sistema.

En casos extremos, esto puede llevar a situaciones peligrosas, como la potencial carencia global de pixeles negros provocada por el uso indiscriminado de signos de exclamación 🙂

Y para compensar la licencia humorística, un par de datos:

• El sitio de IBM tiene una interesante guía para el manejo de mensajes y errores
• Nielsen publicó un alertbox sobre el tema hace tiempo atrás, Error Message Guidelines