Abreviaturas (abbr) VS. Acrónimos (acronym)

En la vieja escuela estábamos acostumbrados a identificar y definir cada abreviatura y acrónimo con intención de aportar más semántica a nuestro contenido.
Usamos el atributo title con la versión textual completa, dentro de las etiquetas abbr y acronym, para explicar el término sin interrumpir el flujo del documento.

Ejemplo de abreviatura – abbr

<p><abbr title="Teléfono">Tel</abbr></p>

Ejemplo de acrónimo – acronym

<p><acronym title="Real Academia Española">RAE</acronym></p>

Abreviaturas o acrónimos en otro idioma

Si el idioma de la abreviatura o el acrónimo es diferente al del documento, se debería indicar con los atributos lang y/o xml:lang.

Por ejemplo en el caso del documento siguiente en XHTML Strict en Inglés:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en" xml:lang="en" >

El marcado de la abreviatura sería:

<p><acronym title="Real Academia Española" lang="es" xml:lang="es">RAE</acronym></p>

Y ahora viene lo bueno…

Según la nueva escuela todo es abreviatura

  • Se llama acrónimo a la palabra que se forma a partir de las letras iniciales de un nombre compuesto y a veces por más letras. Por ejemplo: RADAR (RAdio-Detection And Ranging).
  • Se llama sigla al término que se forma a partir de la inicial de las palabras claves que forman el título o el nombre completo de algo. Por ejemplo: RAE (Real Academia Española).

Ambos casos (acrónimos y siglas) son considerados abreviaturas y por ello en la práctica se permite usar abbr para todo tipo de formas abreviadas.

Además, en las especificaciones HTML5 y XHTML2 queda eliminado el elemento acronym a favor de estándarizar únicamente abbr.

Me parece bueno todo lo que sea ahorrar confusiones y malos usos, por eso me gusta la interpretación de la nueva escuela :)

* A tener en cuenta: Como no podía ser de otra forma las versiones anteriores a Internet Explorer 7 no reconocen abbr.

Los colores olvidados

Hace ya un buen tiempo descubrí de forma totalmente fortuita la página web de Los colores olvidados, cuyo diseño e ilustraciones me llamaron la atención. Navegaba y babeaba al mismo tiempo. Otro claro ejemplo de que el diseño no esta reñido con la usabilidad.

Read more »

¿El diseño aburrido es usabilidad?

Retomando a Lev Manovich, descubro que habló sobre la usabilidad en una entrevista publicada por ArtNodes de UOC: Definitivamente, creo que estamos en el principio.

En una de las preguntas Manovich comenta que no le gustan los defensores de la usabilidad web, pues cree que no tienen ningún criterio estético y están proponiendo algo que resulta extremadamente aburrido.

En mi opinión, no puedo estar más en desacuerdo con esta postura.
El primer pensamiento que puede tener tanto un diseñador como un usuario es que la usabilidad puede mermar la creatividad y que las convenciones de diseño que a su vez favorecen al campo de la usabilidad van en detrimento de las posibilidades creativas. Se puede llegar a pensar que incluso si seguimos todas las convenciones favorables en usabilidad acabaríamos con un diseño global homogéneo y aburrido.

Nada más lejos de la realidad. Los diseñadores siempre han estado expuestos a convenciones y también a restricciones en todos los medios de expresión, desde la pintura en lienzo al diseño web. De hecho el diseño web es diseño de interacción por lo tanto estamos expuestos a tener en cuenta la conducta humana en este medio.

Las convenciones de usabilidad y las restricciones impuestas por el diseño de interacción más que minar nuestra creatividad la agudiza, haciendo que sigamos siendo creativos pero teniendo en cuenta dichos factores.

Recuerdo una cita que lo ilustra perfectamente:
Diseño es arte optimizado para conseguir objetivos Shimon Shmueli

La socialización, nueva revolución mediática

Inclasificable, aunque interesante lo que voy a escribir en este post sobre mis interpretaciones de Lev Manovich y la relevancia que tienen en la actualidad la socialización en internet.

Read more »

Comentarios condicionales de Internet Explorer

Son como su propio nombre indica comentarios interpretados únicamente por Internet Explorer e incrustados en el código HTML, generalmente en el apartado HEAD y realizan su función únicamente si la condicional se cumple atendiendo al navegador y su versión.

Este mecanismo fue “un invento” de Microsoft (Internet Explorer), que en númerosas ocasiones no han seguido los estándares y pautas marcadas por la W3C. Mediante los comentarios condicionales podremos crear estilos propios atendiendo a las diferentes versiones de este navegador.

Las condicionales llevan un operador: “!” (negación), “lt” (menor que), “lte” (menor o igual que), “gt” (mayor que), “gte” (mayor o igual que). Con los operadores y las diferentes versiones del navegador ya podemos definir estilos atendiendo a las diferencias de cada caso.

Ejemplos

<!--[if !IE]> Cualquier navegador pero NO (!) Internet Explorer <![endif]-->
<!--[if lt IE 6]> Solo versiones MENORES de la 6 <![endif]-->
<!--[if lte IE 6]> Solo versiones MENORES o IGUAL a la 6 <![endif]-->;
<!--[if gt IE 5.5]> Solo versiones MAYORES a la 5.5  <![endif]-->
<!--[if gte IE 5.5]> Solo versiones MAYORES o IGUAL a la 5.5  <![endif]-->

Tablas más semánticas y accesibles

CAPTION y TITLE

La etiqueta caption proporciona información sobre el contenido de la tabla al igual que el atributo <table title="">.

La única diferencia es que title no se muestra en los navegadores de pantalla (a excepción de mostrarse como tooltip o mensaje emergente). Por contra caption aparece como un texto centrado en la parte superior de la tabla.

Resulta innecesario usar ambos puesto que con uno de ellos ya aportamos la información sobre el contenido de la tabla.

SUMMARY

Podemos optar libremente por usar caption o title pero si es necesario (sobre todo por razones de accesibilidad) complementar la información con un resumen a través del atributo <table summary="">

Como resumen se debería de indicar la función informativa de la tabla, de una forma más ampliada que el caso de caption. También se puede indicar de forma muy resumida las relaciones entre las celdas.

TH

La etiqueta th sirve para identificar los grupos de encabezamiento. Las cabeceras que sirven de referencia, tanto si se trata de una disposición en columna como en filas.

SCOPE y HEADERS

Su función consiste en relacionar las celdas de los encabezados con las celdas que contienen los datos.

  • El atributo scope podemos usarlo especialmente en tablas sencillas y en los encabezamientos th.
  • El atributo headers cumple la misma misión pero de una forma más especifica, por ello es mejor reservarlo para tablas complejas.

Más información detallada de estos atributos en scope y headers en tablas para mejorar la accesibilidad.

En conclusión, con el uso de caption, th, thead, tbody, tfoot, colgroup, col, scope, headers, axis mejoramos sustancialmente la accesibilidad de nuestras tablas.

Diseño centrado en el usuario, una propuesta

Hace alrededor de 2 años publique en este blog: La pirámide del diseño web, con mi idea sobre los elementos más relevantes en el proceso.

Ahora expongo una revisión de esta idea pero intentando tomar como base las premisas del DCU .

He elaborado un esquema en el siguiente documento: Diseño centrado en el usuario, una propuesta. (PDF – 188Kb)

Básicamente divido el proceso en 5 etapas:

  1. Arquitectura de la información
    1. Análisis (información, objetivos, usuarios)
    2. Diseño conceptual (blueprints, wireframes)
  2. Diseño
    1. Diseñó visual (mockups)
  3. Desarrollo
    1. Front-end (web estática)
    2. Back-end (web dinámica)
  4. Publicación
  5. Mantenimiento

En la propuesta, la evaluación de interfaz/usuarios deber correr desde su inicio y en paralelo al proyecto.
Se harían interacciones de evaluación constante con los usuarios a través de: Blueprints (prototipo de baja fidelidad) > Wireframes (prototipo de media fidelidad) > Mockup (prototipo de alta fidelidad) > Web estática > Web dinámica.

Optimizar CSS, 12 consejos y 4 herramientas

Expongo a continuación algunos consejos para la optimización de nuestras hojas de estilos CSS.

1. Selectores ID, Classes, Tags

#logo { margin-top: 1em; }
.ico { margin-left: 1em; }
a { text-decoration:none; }

Los Selectores ID es la forma más eficiente y rápida que hay en CSS para otorgar estilo. Por contra no podemos sobrecargar nuestro CSS usándolos para cada elemento que requiera un mínimo de diseño. En este punto tenemos que pensar de forma creativa y global para usar los selectores de clase, las propias etiquetas y los principios de la cascada.

2. Un identificador no necesita más

h1 #logo { margin: 1em; }

Las etiquetas con un atributo de identificador son irrepetibles, solamente hay uno por página, por tanto es redundante añadir cualquier referencia adicional.
El ejemplo anterior más optimo sería:

#logo { margin: 1em; }

3. Agrupar selectores con mismas propiedades

En vez de:

h2 { font-weight: 700; }
h3 {  font-weight: 700; }
.bold { font-weight: 700; }

Mejor usar:

h2, h3, .bold { font-weight: 700; }

Este es un ejemplo muy obvio pero puede ser más complejo dependiendo del tamaño de la hoja de estilos.

4. Escribir el CSS de formas abreviada

Las llamadas Shorthand es una forma de escribir las reglas de forma abreviada, lo cual repercute directamente en la optimización (siguiendo el principio menos es más).
Este asunto lo he tratado en un post anterior llamado “Formas abreviadas para optimizar CSS“.

5. Más restrictivo a la derecha

ul li span.linklist a { border: 1px solid red; }

Ante un ejemplo como este podemos pensar que el navegador interpreta de izquierda a derecha los selectores, cuando en realidad es justamente a la inversa. Primero analiza A, luego mira que se su padre sea SPAN.linklist, su abuelo LI y su bisabuelo UL, si esto se cumple se pone la propiedad de estilo border: 1px solid red;.

El problema es que pueden existir muchas etiquetas de enlace en una página y la cantidad de proceso será mayor, por lo tanto tendríamos que poner el selector más restrictivo más a la derecha. Ante esto se me ocurren dos soluciones:

  • Disminuir las descendencias, por ejemplo: span.linklist a
  • Otorgar una clase a.linklist y prescindir del resto

6. Menos descendencia y más herencia

Es aconsejable no recurrir a selectores con descendencias, hijos, hermanos, etc. Siempre que sea posible usar únicamente Selectores ID, clases y etiquetas.

En cambio si es positivo heredar (inherit) el mayor número de propiedades posibles entre diferentes elementos. Tengamos en cuenta también la herencia por defecto para no escribir reglas redundantes.

7. Poner el CSS en HEAD

El situar los estilos en el HEAD hace posible que la página muestre el contenido-estilo de forma progresiva, lo que mejora la experiencia de uso.

Por otro lado la especificación HTML también recomienda la etiqueta LINK dentro del HEAD para incorporar nuestras hojas de estilo.

8. CSS como fichero externo (style.css)

Esto hace que la cache pueda hacer su trabajo, de lo contrario si incorporamos el CSS en linea, será descargado una y otra vez con la página.

Otra ventaja es la mejora en la escalabilidad pudiendo gestionar todos los estilos y el diseño de una forma más centralizada.

9. LINK mejor que @import

En algunas versiones de IE usar @import es parecido a usar LINK fuera de HEAD, por esta razón y teniendo en cuanta lo dicho anteriormente, es recomendable usar un enlace al fichero y no importarlo.

Más información en Don’t use @import.

10. Minimizar el número de peticiones LINK

Supongamos el siguiente ejemplo:

<link rel="stylesheet" href="style1.css" type="text/css" media="screen" />
<link rel="stylesheet" href="style2.css" type="text/css" media="screen" />

En el fichero style2.css a penas hay unas pocas lineas de código y su gestión no lleva a confusiones, entonces es mejor tener un solo fichero style.css con todas las reflas CSS, reduciendo el número de peticiones LINK al servidor.

En este sentido tener en cuanta también la modularidad, pueden existir ficheros CSS que por esta razón es mejor mantenerlos bien separados y organizados.

11. Evitar las “CSS Expressions”

No son estándares y se procesan repetidas veces para establecer sus propiedades dinámicas.
En No me gustan las CSS Expressions planteo algunos problemas que derivan en la falta de optimización.

12. Evitar filtros

Siempre que sea posible evitar el uso de filtros como por ejemplo “AlphaImageLoader“, estos filtros consumen una gran cantidad de memoria para su funcionamiento.

Herramientas para la optimización y compresión

Existen muchas, pero las que más uso son:

Las dos primeras te ayudarán a chequear y encontrar mejores formas de optimización, la tercera se encarga de comprimir el fichero CSS.

La experiencia hace que en cada proyecto tengamos menos trabajo que optimizar e invertir menos tiempo delante de estas herramientas.

Por cierto, ¿se os ocurren más formas para optimizar CSS?

No me gustan las “CSS Expressions”

Las CSS Expressions son usadas para establecer propiedades dinámicas. Fue un invento más de Microsoft para Internet Explorer.

Los problemas que veo en las “CSS Expressions” son:

  • No es un estándar web, con todo lo que ello implica…
  • Se diluye la abstracción: contenido > estilo > comportamiento.
  • A excepción de IE todos los navegadores tendrán que tragar estos bytes de más sin tener soporte para ello.
  • Y lo peor de todo, las “CSS Expressions” se procesan muchísimas veces, no solo cuando se carga el CSS sino también cuando realizamos múltiples tareas como por ejemplo desplazar el scrooll vertical. Esto genera una cantidad de proceso enorme para el navegador y una deficiencia en la optimización del sitio web.

En la mayoría de los casos se usan las “CSS Expressions” para solucionar problemas de incompatibilidad (cross-browsing) o carencia/deficiencia de soporte para los estándares web por parte del software de Microsoft. Osea que al final para solucionar un problema de este navegador ponemos un parche que afecta al resto de navegadores e incluso le puede sentar indigesto al propio Internet Explorer.

En fin, el parche puede infectar más la herida :(

Post – Thumbnail en WordPress; Mostrar 5 últimos posts con thumbnails

La semana pasada implemente una funcionalidad en la que puede aprovechar los nuevos post-thumbnails de la versión 2.9 de WordPress.

¿Qué es un post-thumbnail?

Es una imagen en miniatura que puedes asociar a cada post.

Esta nueva característica es muy interesante puesto que te ahorras códigos y métodos un tanto rebuscados si lo único que quieres es asociar a un post una imagen.
Por ejemplo en el apartado portfolio de este sitio web veis que aparecen un thumbnail por cada proyecto. Para lograrlo he subido el thumbnail como una imagen más y a través de “query y el menu-order” cojo la primera imagen del post, luego en la ficha del proyecto me salto la primera y coloco el resto.
Otra formula para establecer thumbnails es usar algún plugin disponible.

Y ahora por fin en WordPress ya tenemos incorporada de base esta característica.

Método de empleo

Dando soporte a post-thumbnails en nuestro theme activo

Lo primero es indicar a WordPress que deseamos usar esta funcionalidad. Para ello usamos la siguiente instrucción que debemos incorporar al fichero function.php de nuestro theme.

add_theme_support( 'post-thumbnails' );

Incluir el thumbnail en un post

Se hace a través de la interfaz del panel de control, facilitando así la tarea para los editores del blog.
Cuando escribamos un post o lo editemos en el panel de control de WordPress, veremos al margen derecho un nuevo bloque llamado “Post Thumbnail”, en el podemos incluir la imagen en miniatura.

Mostrar los últimos 5 posts (con thumbnails)

function related_posts() {
	global $wpdb, $post;
 
	$category = get_the_category(); 	
 
	$last_posts = $wpdb->get_results("
		select $wpdb->posts.ID, $wpdb->posts.post_title, $wpdb->posts.guid, date_format($wpdb->posts.post_date, '%e-%m-%Y') as post_date
		from $wpdb->posts
		join $wpdb->term_relationships
			on $wpdb->posts.ID = $wpdb->term_relationships.object_id  
		where 
			$wpdb->term_relationships.term_taxonomy_id = ".$category[0]->cat_ID." and
			$wpdb->posts.post_type = 'post' and 
			$wpdb->posts.post_status = 'publish' and 
			$wpdb->posts.ID != ".$post->ID."
		group by $wpdb->posts.ID 
		order by $wpdb->posts.ID desc
		limit 5");
 
	echo '<ul>';
		foreach ($last_posts as $last_post_current) {
			echo '<li>';
				echo '<a href="'.$last_post_current->guid.'" rel="bookmark">';
					if (has_post_thumbnail($last_post_current->ID)) { 
						echo get_the_post_thumbnail($last_post_current->ID, array(40,40)); 
					}
					echo $last_post_current->post_title;
				echo '</a>'; 
				echo '<span class="date">'.$last_post_current->post_date.'</span>';
			echo '</li>';
		}
	echo '</ul>';		
}

A partir de un query se obtienen los últimos 5 posts publicados de la categoría activa get_the_category();.
Luego en el bucle que recorre cada post, se muestra el titulo, thumbnail y el enlace correspondiente a cada post.

Fijémonos en fragmento de código que nos interesa:

if (has_post_thumbnail($last_post_current->ID)) { 
	echo get_the_post_thumbnail($last_post_current->ID, array(40,40)); 
}

La función has_post_thumbnail(); a la que le pasamos como parámetro el post_id nos devuelve true si ese post contiene un thumbnail asociado. En ese caso se ejecuta la función get_the_post_thumbnail(); a la que se le pasa como primer parámetro el post_id y como segundo un tamaño para la imagen en miniatura (en forma de array), en este caso 40*40 pixel.

Podéis ver más información detallada sobre post-thumbnails en New in WordPress 2.9: Post Thumbnail Images.