Ahora bien, ¿cómo sé efectuar el diseño de las aplicaciones web 2.0?

Bueno, yo creo que los diseños deberían hacerse siempre con CSS por varios motivos. ¿Cuáles? Bueno, lean el post a continuación que creo que va a darnos una idea de cuales son las ventajas de utilizar CSS en nuestros diseños. Obviamente, empezaremos por una introducción al tema.

¿Qué son los CSS?

Las Hojas de Estilo (o CSS, por Cascading StyleSheets) son un mecanismo que permiten aplicar formato a los documentos escritos en HTML (y en otros lenguajes estructurados, como XML) separando el contenido de las páginas de su apariencia. Para el diseñador, esto significa que la información estará contenida en la página HTML, pero este archivo no debe definir cómo será visualizada esa información. Las indicaciones acerca de la composición visual del documento estarán especificadas en el archivo de la CSS.

¿Cómo Funcionan los CSS?

Las Hoja de Estilo no utilizan el archivo de la página Web para especificar el formato de la página (en realidad, a veces pueden hacerlo, pero no es recomendable hacerlo de esa manera). En su lugar, usan un archivo de texto puro con extensión “.CSS” que luego se vincula a la página.

Este archivo contiene reglas que constan de un selector (en este ejemplo, H1) y una o más declaraciones (en el ejemplo tenemos cuatro declaraciones). Cada declaración tiene dos partes: una propiedad (por ejemplo, FONT SIZE) y un valor (en este caso, 19pt). Estas reglas son las que determinan cómo deberá mostrarse la página.

Nuevamente, si quisiéramos componer los encabezados H1 con tipografía Arial, de 19 puntos, en color azul y alineación central, el archivo CSS debería contener el siguiente texto:

H1 {

   font-family: Arial, Sans-serif;

   font-size: 19pt;

   color: #0000FF;

   text-align: center;

}

Luego, en cada página de nuestro sitio agregamos un link a la Hoja de Estilo:

<LINK REL="stylesheet" href="hoja_de_estilo.css" TYPE="text/css">

El elemento LINK especifica:

• el tipo de vínculo: a una hoja de estilo (”stylesheet”)
• la ubicación de la hoja de estilo a través del atributo “href”
• el tipo de hoja de estilo que se vincula: “text/css”

Ahora, todos los encabezado H1 de las páginas que contienen la referencia al archivo de la CSS tendrán el aspecto que hemos definido.

10 razones (o ventajas) para utilizar CSS

1.- Separación del contenido y presentación.

Las hojas de estilo generalmente se encuentran en archivos separados del código principal (html, por ejemplo). Esto nos va a permitir que en un equipo de trabajo, programador y diseñador puedan realizar sus tareas de forma independiente aunque paralela, sin correr el riesgo de que haya interferencias entre ambos, y ello no alterará el resultado final.

2.- Flexibilidad.

Podríamos comparar las hojas de estilo con la ropa que guardamos en nuestros cajones. Nosotros somos los mismos, pero dependiendo de la temporada variamos nuestra apariencia.

En el caso de las hojas de estilo sucede lo mismo: podemos cambiar en cualquier momento alguna parte o la totalidad del diseño de nuestras páginas con sólo modificar nuestra hoja de estilo, sin que ello suponga modificar el contenido.

3.- Unificación del diseño de las páginas del sitio.

Un sitio web, ya sea dinámico o estático, suele estar formado por unas cuantas páginas. Mantener una misma apariencia se puede volver una tarea pesada y tediosa si tenemos que copiar y pegar código cada vez que creemos una página nueva, o que deseemos modificar una misma cosa en todas.

Enlazando a cada una de nuestras páginas nuestras hojas de estilo, agilizamos este proceso y minimizamos el trabajo.

4.- Optimización de los tiempos de carga y de tráfico en el servidor.

Al haber dividido contenido y apariencia obtenemos archivos más ligeros, y esto nos reporta dos beneficios: por un lado, reducimos notablemente los tiempos de carga del sitio en el navegador. A esto debemos unir la capacidad de éste para mantener nuestra hoja de estilo en caché.

Por otro lado, reducimos el volumen de tráfico de nuestro servidor, que siempre es de agradecer, tanto si disfrutamos de servicios gratuitos en que solemos tener cuotas muy reducidas, como si pagamos por tener alojamiento propio.

5.- Precisión o elasticidad.

Desde el momento en que usemos CSS, el tamaño y posicionamiento de los elementos que formen nuestras páginas podrá ser exacto. Podremos indicarle al navegador en qué píxel debe colocar ésta o aquélla imagen, o qué alto y ancho deberá mostrar.

Pero al mismo tiempo, podremos emplear medidas variables o relativas que nos permitan expandir el contenido hasta ocupar la totalidad de la ventana de navegación a nuestro antojo, o contraerla a sólo una parte de la misma, con independencia de la resolución de pantalla del usuario.

6.- Accesibilidad y estructuración.

La combinación de CSS y marcadores descriptivos va a posibilitar que nuestra página se vea correctamente con o sin hoja de estilos, puesto que en cualquier caso, la información se mantendrá estructurada y ordenada.

Esto supone que podrá ser accesible sin ningún tipo de problemas tanto por navegadores antiguos o sin soporte para CSS, como para personas con algún tipo discapacidad.

7.- Limpieza del código fuente.

Si escribimos una hoja de estilo independiente, el código fuente de nuestra web va a resultar menos farragoso y agilizaremos las tareas de localización de las líneas que busquemos.

8.- Compatibilidad y continuidad.

Las reglas establecidas por la especificación CSS-1 fijaron los estándares del diseño, y se mantienen y respetan en la CSS-2. Es de prever que en el nivel 3 sucederá lo mismo con respecto a su predecesor.

Pero lo realmente interesante es que los navegadores que no soporten CSS-3 no tendrán problemas a la hora de asimilar el contenido CSS puesto que siempre les quedará la compatibilidad de CSS-2, o la CSS-1 en su caso. La compatibilidad de las especificaciones CSS anteriores estará siempre garantizada.

9.- Estandarización frente a especificaciones propietarias.

La adopción de estándares por la W3C ofrece la ventaja de la compatibilidad del código entre los diferentes navegadores web. El uso de “soluciones propietarias”, como es el caso de muchas etiquetas o patrones usadas por Microsoft.

En su interpretación de lo que es y no es CSS, dificulta la creación de páginas web, porque supone tener que escribir dos códigos distintos para obtener un mismo resultado, en función del tipo de navegador que use el visitante.

El uso del estándar CSS de la W3C evitará visualizaciones incorrectas de nuestras páginas en distintos navegadores.

10.- Permite la diferenciación de estilos para imprimir / visualizar en pantalla.

El uso de CSS nos va a permitir también maquetar separadamente el contenido de nuestra web para ser mostrado en pantalla o para ser impreso.

Tengamos en cuenta que las necesidades y propiedades de un folio de papel y de un monitor nunca van a ser las mismas, y gracias a CSS podremos determinar cómo queremos que se imprima lo que mostramos en la pantalla, manteniendo siempre una apariencia limpia, ordenada y agradable visualmente.

Espero que estas pequeñas reflexiones hayan servido para animarte a dar el gran salto y vestir a tu web con un bonito traje CSS hecho a medida. Y si aún no te animas a usar CSS en tu sitio, te invitamos a conocer CSS Reinicia, una iniciativa que busca que sitios web en nuestro idioma se reinventen gracias a esta tecnología.

Bien, en el blog tagschema.com de Nitin Borwankar explica bastante bien como hacerlo, y aquí voy a incluir un resumen traducido al castellano de lo que considero más importante de dicho blog.

He tenido la experiencia de hacer aplicaciones web 2.0 utilizando esquema de etiquetas, y es bastante sencillo de implementar si uno tiene los conceptos adecuados para hacerlo.

La Web 2.0 necesita Datos 2.0

Una de las principales características de muchas aplicaciones web 2.0 es que son folcsonomías, clasificando los contenidos por medio de palabras clave o “etiquetas” (tags) mnemotécnicas.

Normalmente estas aplicaciones a diferencia de las aplicaciones “1.0″, por llamarlas de alguna manera, relacionan a los usuarios con lo que denominaremos sus ítems (podrían ser bookmars, fotos, videos, música, o cualquier objeto de una aplicación). En las aplicaciones “2.0″ no solo se relacionan los usuarios con sus ítems, sino que también se relacionan con las etiquetas que les ponen a sus ítems.

Los nuevos modelos de datos, ahora, deberán tener en cuenta una nueva dimensión a la hora de actuar, y esa nueva dimensión son las etiquetas. Para lograr eso de una forma eficiente se debe hacer una especie de datawarehousing. Ese datawarehousing en tiempo real son nuestros Datos 2.0, los datos que utilizaremos por medio de nuestro esquema de etiquetas.

Entonces, el esquema de etiquetas (o tags) representa un datawarehouse de datos etiquetados (o tabeados), y esos serán nuestros Datos 2.0.

Datos 2.0 a fondo

Ahora que sabemos que un esquema de etiquetas (o esquema de tags) no es nada mas ni nada menos que un datawarehouse, para analizar estos esquemas de etiquetas vamos a tener que hacer un análisis de modelos multidimensionales.

Antes de interiorizarnos con profundidad en este tema vamos a darnos cuenta que para cualquier simple aplicación que utilice etiquetas vamos a necesitar tres dimensiones básicas: “Usuario”, “Etiqueta” y “Ítem”. A partir de esas tres dimensiones comenzaremos a hacer el análisis de un esquema de etiquetas.

Con esas tres principales dimensiones se genera lo que en datawarehousing se conoce como “fact table”, y eso es una tabla donde se asocian y convergen las 3 dimensiones. En esa tabla tendremos la información de cada ocurrencia de un evento, como por ejemplo “el usuario X ha puesto la etiqueta Y al ítem Z”. Esta situación se da para todas las etiquetas Y que le incluye el usuario X a todos los objetos Z que posea.

Entonces, si el usuario “pepe” utiliza las etiquetas “cine”, “música”, “literatura” y “ocio” de manera en la que a el le parece con algunos artículos de un sitio web que habla sobre hobbies, en un esquema de etiquetas podríamos llegar a encontrar las siguientes columnas en una “fact table”:

Usuario     Etiqueta        Ítem
----------------------------------------------------------------
'pepe'      'cine'          'http://algohobbies.com/articulo-1'
'pepe'      'cine'          'http://algohobbies.com/articulo-2'
'pepe'      'música'        'http://algohobbies.com/articulo-2'
'pepe'      'cine'          'http://algohobbies.com/articulo-3'
'pepe'      'literatura'    'http://algohobbies.com/articulo-3'
'pepe'      'ocio'          'http://algohobbies.com/articulo-4'

El usuario “juan” tendrá una cantidad similar de campos para todos sus objetos etiquetados, lo mismo para el usuario “laura”.

Las “fact tables” son tablas de asociaciones de múltiple entrada, donde se asocian todas las dimensiones posibles en un solo lugar. Estas tablas permiten una gran cantidad de consultas interesantes para correr, con probablemente, una de las mejores escalabilidades.

Creando un modelo de datos para navegar una folcsonomía

Además de la unión de los Usuarios, Etiquetas e Ítems hay una cantidad de relaciones que, junto con la relación base, forman el modelo de datos 2.0. Exploremos estas relaciones y sus consecuencias para la arquitectura de los datos.

Los Usuarios tienen Ítems (URL’s, fotos, música, etc.), pero un Usuario puede existir en la base de datos sin poseer ningún Ítem, como por ejemplo luego de haberse registrado. Por el lado del Ítem, este terminara siendo incluido en la base de datos solamente si esta relacionado al menos a un usuario (el que lo haya cargado). Entonces, un Usuario tiene quizás-ninguno-pero-posiblemente-muchos Ítems, y un Ítem tiene al-menos-uno-y-posiblemente-muchos Usuarios.

Similarmente, un Ítem puede existir sin ninguna Etiqueta, pero una Etiqueta existe solamente para asignar un valor a un Ítem. Adicionalmente, un Usuario puede no haber etiquetado nada por lo cual no tener ninguna Etiqueta, pero una Etiqueta siempre va a ser asignada por un Usuario.

Teniendo en cuenta esas tres relaciones cíclicas obtenemos lo siguiente:

Usuario  (1-muchos)  <---------> (0-muchos)  Ítems
Etiqueta (0- muchos) <---------> (1- muchos) Ítems
Etiqueta (0- muchos) <---------> (1- muchos) Usuario

Transcribiendo eso para una mejor comprensión podemos obtener este hermoso diagrama:

Aquí podemos ver que hay relaciones muchos-a-muchos entre cada par de entidades. Este modelo que vemos aquí arriba es la representación de un modelo lógico de datos, que al pasarlo a un modelo físico de datos va a requerir algunas modificaciones debido a las relaciones de muchos-a-muchos.

La idea no es dar una clase sobre bases de datos, pero como una breve explicación, la forma estándar de representar las relaciones muchos-a-muchos es crear una tabla de relación en la base de datos, que asocie ambos campos por medio de sus identificadotes.

Por ejemplo si queremos almacenar los Ítems que ha guardado un Usuario, al mismo tiempo que queremos saber los Usuarios que poseen cierto Ítem de una forma eficiente, crearemos una tabla que se podría llamar UsuarioÍtem para resolver la relación de muchos-a-muchos entre esas dos entidades donde cada columna tendrá el identificador del Usuario y el identificador del Ítem. Con la misma lógica tendremos una tabla UsuarioEtiqueta y una tabla ÍtemEtiqueta.

Habiendo creado las tablas de relaciones, el modelo nos quedara similar al siguiente:

Para completar nuestro modelo de datos, como vimos anteriormente, tenemos la famosa “fact table” donde se relacionan los Usuarios, Ítems y Etiquetas en una sola tabla, que puede ser representada de dicha manera:

Ahora bien, seguramente están pensando ¿todo esto para hacer una simple nube de etiquetas?

Bien, si estas pensando en hacer una arquitectura de una folcsonomía a gran escala va a ser necesario algo así, ya que en una primera instancia este modelo resuelve de forma muy simple las preguntas: “¿Cuáles son todos los Ítems de un Usuario?” O “¿Cuáles son todas las Etiquetas de este Ítem?”; pero yendo a un grado mayor de profundidad, nos podemos encontrar con preguntas como: “¿Cuáles son todos los Usuarios que tienen mas Ítems similares entre sí con otro Usuario?”. Usando este modelo, podemos responder muchas consultas sin hacer múltiples JOIN en una base de datos, y cuando hablamos de mas de 250.000.000 de columnas, es algo importante para la performance.

Entonces, como nuestro modelo no puede evitar nunca tener nuestra “fact table” ya que mantiene la coherencia entre los Usuarios, Ítems y Etiquetas, combinando estos dos modelos de datos obtendremos lo que se podría denominar la base de nuestro modelo de datos 2.0, nuestro famoso esquema de etiquetas:

Relacionando datos en una folcsonomía

Si bien SQL es un lenguaje perfectamente adecuado para hacer consultas de datos “tabulares”, no es particularmente elegante para representar las abstracciones que tenemos en mente a la hora de relacionar datos en una folcsonomía, como por ejemplo, relacionar Usuarios, Ítems o Etiquetas entre sí.

Vamos a usar una simple notación para hablar sobre las relaciones entre Usuario-Ítem-Etiqueta, para transformar momentáneamente SQL en un lenguaje un poco más descriptivo. Olvidémonos de SQL por un momento y vamos a seguir esta notación:

Las letras en minúscula “í”, “e” y “u” representaran a un “Ítem”, “Etiqueta” y “Usuario” respectivamente.

Las letras en mayúscula “Í”, “E” y “U” representaran una lista de “Ítems”, “Etiquetas” y “Usuarios”, como una búsqueda.

Veamos algunos ejemplos:

Al pedir U(í), estaremos pidiendo todos los Usuarios de un Ítem í.
(En SQL sería: select u.* from usuarios u, usuarios_ítems ui where u.id = ui.usuario_id and ui.item_id = algun_item_id; )

Al pedir U(e), estaremos pidiendo todos los Usuarios que tengan la Etiqueta e.
(En SQL sería: select u.* from usuarios u, usuarios_etiquetas ue where u.id = ue.usuario_id and ue.etiqueta_id = alguna_etiqueta_id; )

Similarmente obtendremos:

Í(u) serán todos los Ítems de un Usuario u.
Í(e) serán todos los Ítems que tengan una Etiqueta e.
E(í) serán todas las Etiquetas que estén asignadas a un Ítem í.
E(u) serán todas las Etiquetas que haya usado un Usuario u.

Ahora, si buscamos en un segundo grado de profundidad, podremos encontrar consultas un poco mas interesantes que las anteriores.

Por ejemplo, E(U(e)) es una colección de todas las Etiquetas que tienen todos los Usuarios que tienen una Etiqueta e.
(Su SQL sería: select e.* from etiquetas e, usuario_etiquetas ue, where ue.usuario_id in (select usuario_id from usuario_etiquetas where etiqueta_id = alguna_etiqueta_id))

Aquí podemos observar que es mucho mas sencillo decir lo que queremos, “Una colección de todas las Etiquetas que tienen todos los Usuarios que tienen una Etiqueta e”, que su representación en SQL que puede llegar a ser mas compleja de entender sin la explicación previa.

De esta manera, con la notación que hemos utilizado podemos encontrar varias consultas de segundo grado.

Estas consultas las veremos mas adelante en alguna otra publicación, creo que ya es demasiada información por una única entrada.