1. Páginas más comprensibles y mejor estructuradas
   Hasta la llegada de HTML5, los desarrolladores hacían un uso intensivo de las etiquetas <div> dentro del código HTML para deilimitar las diferentes secciones o partes de nuestro sitio web. Con la inclusión de nuevas etiquetas dentro de HTML5, como section, article, header, footer, nav, hgroup, aside, article, etc., daremos un valor semántico añadido a la distribución del contenido para que sea fácilmente localizable desde los diferentes buscadores y pueda ser mejor entendida por los navegadores y aplicaciones que accedan a ella.
2. Vídeo nativo sin instalaciones adicionales
   La reproducción de vídeos en la web iba ligada hasta hace bien poco a la instalación de Flash en nuestro navegador. HTML5 proporciona un estándar común que permitirá la reproducción de vídeos unificando así formatos y codificaciones sin tener que instalar elementos adicionales para disfrutar de cualquier media.
3. Geolocalización
   Cada vez más presente en las redes sociales y aplicaciones móviles, la geolocalización también ha sido contemplada por el estándar HTML5. A través de esta característica, las aplicaciones web pueden tener acceso a la latitud y longitud donde se encuentre el usuario que accede a un site, independientemente del sistema de georeferenciación utilizado por nuestro navegador (GPS, WiFi, 3G, etc.)
4. Aplicaciones offline
   El uso de aplicaciones web se ha enfrentado desde sus comienzos con una importante desventaja en comparación con las aplicaciones de escritorio, y era la posibilidad de estas últimas de trabajar en entornos desconectados. Además, con la utilización de dispositivos móviles, es habitual no disponer siempre de una conexión de alta velocidad de calidad para el uso de aplicaciones web. HTML5 aporta una importante mejora en este aspecto para permitir la utilización de todas las funcionalidades de las aplicaciones web “sin conexión” a través de APIs, que sincronizan sus datos cuando la conexión entre el dispositivo y la red se restablece.
5. Dibujos, animaciones y videojuegos
   Con la incoporación de la etiqueta <canvas>, HTML5 abre por fin la posibilidad de representación y dibujado de formas sobre un lienzo o canvas. Esta nueva funcionalidad aparentemente complementaria abre la web al mercado del videojuego, diseño y la animación nativa, que anteriormente dependía de otras plataformas propietarias como Flash.

¿Qué opinas de estas ventajas?

Héctor Gomis Hidalgo

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

Por ello, desde el departamento de Informática de Taller Digital hemos apostado desde hace algún tiempo por la filosofía “renovarse o morir” y nos hemos especializado en desarrollo web siguiendo las nuevas tendencias tecnológicas del mercado.

En este aspecto podemos destacar metodologías y frameworks como Grails (Groovy/Java), ASP.NET MVC (.NET) y Symfony (PHP) que permiten seguir metodologías de desarrollo actuales de una forma estructurada, sencilla y eficaz:

• Desarrollo ágil: promoviendo iteraciones cortas en el desarrollo a lo largo de todo el ciclo de vida del producto (SCRUM).
• Participación de los clientes en la construcción de su producto: el rápido prototipado de aplicaciones (Scaffolding) nos permite poder desarrollar primeras versiones de las aplicaciones de forma más rápida, permitiendo ajustarnos en mayor medida a los requerimientos y deseos de nuestros clientes, y disminuyendo así los riesgos potenciales.
• Mayor calidad en el producto: la fiabilidad y calidad de los desarrollos son premisas indispensables en nuestros equipos de desarrollo. Estos frameworks nos proporcionan herramientas automáticas de testeo que permiten detectar errores en cualquier etapa del desarrollo.
• Mayor satisfacción por parte de nuestros clientes: en la medida en que los clientes participan de forma activa en el desarrollo del producto obtenemos un producto de calidad y ajustado a sus necesidades.

En resumen, desde hace algún tiempo estamos apostando por nuevas metodologías y herramientas y creemos en la idea de crear un clima de proactividad, que, si bien no puede garantizar un éxito de forma segura, sí puede encaminarte hacia él.

Raúl Gomis

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

La respuesta a la necesidad de gestionar volúmenes masivos de información surge de la base de datos NoSQL, término acuñado a finales de los 90 y que engloba todas las tecnologías de almacenamiento estructurado que no cumplen el esquema relacional.

La cantidad de información manejada por comunidades, redes sociales, buscadores, y muchos otros proyectos en el ámbito de la Web 2.0 es abrumadora, lo que ha hecho que surjan nuevas arquitecturas de almacenamiento de información, que deben ser de alto rendimiento, escalables y distribuidas.

Dentro de las plataformas NoSQL encontramos varios grupos:

• Basadas en clave/valor. Se almacenan valores asociados a una clave. Son sencillas y las de mayor rendimiento.
• Basadas en documento. Son una particularización de las clave/valor, en las que el valor puede ser un documento. Permiten consultas complejas.
• Basadas en columna. Los valores se almacenan en columnas en lugar de filas. Son útiles cuando se gestionan datos agregados.
• Basadas en grafo. Las relaciones se tratan como un dato más.
• Basadas en objetos. Los datos son objetos y las relaciones punteros entre ellos. Permiten operaciones muy complejas pero suelen tener bajo rendimiento.
• Otras. Cubren necesidades muy específicas y tienen escasa implantación: basadas en tupla, multivaluadas, jerárquicas, etc.

Algunas de las bases de datos NoSQL más usadas son:

• Basadas en documento:
  • Apache CouchDB (http://couchdb.apache.org/).
  • MongoDB (http://www.mongodb.org/).
• Basadas en clave/valor:
  • Apache Cassandra (http://cassandra.apache.org/).
  • MemcacheDB (http://memcachedb.org/).
  • Redis (http://redis.io).
  • Google BigTable (http://labs.google.com/papers/bigtable.html).

Aunque esta tecnología surgió de unas necesidades muy concretas, su difusión y algunos proyectos para encapsular sus funcionalidades y hacerlas más amigables a desarrolladores acostumbrados a SQL está provocando que también se usen en proyectos de pequeño tamaño, con lo que todo indica que a medio plazo convivirán con las bases de datos tradicionales independientemente del volumen de datos a gestionar.

Juan Carlos García Candela

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

Basta con mirar la estructura de los registros MARC para tener claro que este sistema de metadatos fue desarrollado en los albores de la informática, cuando los discos duros todavía no existían y la información se almacenaba en cintas magnéticas enrolladas en bobinas. La capacidad de una bobina estándar era de 20-40 MB y los tamaños máximos sólo alcanzaban en algunos mecanismos de gama alta con una densidad de grabación de 243 bits/mm., lo que permitía escribir 140 MB en 730 metros de cinta.

Un catálogo MARC es una pila de registros guardados uno detrás de otro, y cada registro contiene toda la información completa. De esta forma la información se duplica en los registros que tienen los mismos datos. Aunque parece que un registro MARC es pequeño, el tamaño de un catálogo completo es enorme, comparado con el tamaño que puede tener el mismo catálogo guardado en una base de datos relacional. En una base de datos con múltiples tablas, la información está repartida entre ellas, lo que permite evitar la duplicidad de datos. Pero un registro MARC debe tener toda la información en él mismo, y como resultado, los datos se repiten constantemente. De esta forma, un catalogo de registros MARC tiene mucha información duplicada. Por ejemplo, en una base de datos que contiene 100 libros de un autor, el nombre del autor está duplicado 100 veces.

La necesidad de tener toda la información en un registro MARC produce otro problema a la hora de catalogar: hay que controlar que la misma información siempre se escribe igual. De no ser así, en el catálogo pueden aparecer diferentes valores para la misma información. Esto puede provocar problemas a la hora de buscar o cuando se necesita agrupar registros por un campo.

La difusión del formato MARC ha marcado un nuevo dilema: el de la compatibilidad entre catálogos. Al mismo tiempo que programadores de la Biblioteca del Congreso de EE.UU. trabajaban en el proyecto MARC, Gran Bretaña estaba trabajando en su propio proyecto similar, al que nombraron British National Bibliography o BNB MARC. A pesar de que en ambos países utilizan el inglés, las diferencias nacionales en las normas de catalogación fueron tan notables que la versión de MARC inglesa y americana resultaron incompatibles. Para superar este inconveniente, en 1968 los dos grupos iniciaron un proyecto conjunto: MARC II, que debería tener en cuenta las normas nacionales de catalogación.

Pero el problema no ha sido superado y como resultado en los años 70 aparecen cerca de 20 versiones diferentes del formato MARC: UKMARC, USMARC, AUSMARC, CANMARC, IBERMARC, DANMARC, NORMARC, etc. La tendencia continuó en los años siguientes. En la actualidad existen cerca de 50 formatos MARC. El problema de compatibilidad se agravó por el hecho de que no todas las bibliotecas eligieron el formato MARC como base; por ejemplo en Alemania desarrollaron el formato MAB, muy diferente de los demás.

Las dificultades surgieron cuando las bibliotecas intentaron hacer intercambio de datos. Incluso las bibliotecas que tomaron como base el formato MARC no podían comunicarse, puesto que tenían criterios diferentes a la hora de hacer la especificación de sus catálogos digitales.

Para superar la incompatibilidad de los formatos, en 1977 la Federación Internacional de Asociaciones de Bibliotecarios (IFLA) comenzó a trabajar en la realización de un formato MARC universal (UNIMARC), que debería garantizar el intercambio entre las diferentes versiones de MARC. En 1987 IFLA publicó directrices para el formato UNIMARC y en los 90 UNIMARC se extendió bastante en Europa. En el año 1999 EE.UU. y Canadá unieron sus formatos USMARC y CANMARC, apareciendo como resultado el formato MARC 21.

Sergiy Bukuyemskyy

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

El fuerte aumento de los recursos electrónicos ha empujado el desarrollo de esquemas de metadatos para clasificarlos. La inmensa cantidad de información disponible a través de Internet ha creado la necesidad de motores de búsqueda que permitan encontrar la información necesaria de una forma rápida y correcta. Estos buscadores han creado una seria competencia para los catálogos bibliotecarios.

Comparado con el rápido desarrollo de las tecnologías de Internet, el desarrollo de las bibliotecas tradicionales no es tan dinámico. A día de hoy el mundo bibliotecario en muchos aspectos sigue siendo bastante cerrado. Los catálogos y bases de datos de las bibliotecas en muchos casos no están accesibles para las aplicaciones web, los buscadores no pueden indexar sus contenidos, a pesar de que los catálogos pueden estar abiertos para los usuarios. Esto lleva al hecho de que las bibliotecas están perdiendo su papel tradicional como el principal custodio y proveedor de la información.

Las primeras reglas para componer un catálogo bibliográfico impreso las hizo el americano Charles Ammi Cutre en 1876. Según él el primer objetivo de un sistema bibliográfico es ayudar a una persona a encontrar un libro por nombre de autor, título, tema o categoría. El segundo objetivo es mostrar todos los contenidos de la biblioteca para un autor, un tema o tipo de obra dado. Y finalmente, ayudar a la elección de una obra teniendo en cuenta distintos criterios como su tipo de edición o su carácter.

El catálogo de fichas de papel ha sido familiar para los usuarios de bibliotecas a través de varias generaciones. Pero a principios de los años 60 empezaron a pensar en un catálogo que pudiera ser procesado por un ordenador (machine-readable).

Sergiy Bukuyemskyy

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

El futuro del desarrollo web está bien claro y se basa en el principio de «reutilización de código para aumentar la productividad y disminuir los riesgos de desarrollo«. En la mayoría de desarrollos web reutilizamos código de alguna forma (funciones o clases que copiamos de otros proyectos propios, frameworks o librerías incluidas, etc.). No obstante, el futuro del desarrollo software va más allá: lo ideal sería que definiendo el dominio a tratar y una serie de restricciones sobre éste, nos permitiera generar código tanto de las vistas como de las controladoras que operan sobre esas vistas. En este sentido Grails es uno de los pocos frameworks que nos permite llegar hasta este nivel de reutilización: habiendo definido el dominio y las restricciones sobre el mismo, con un golpe de ratón vamos a poder generar una primera versión de una aplicación web totalmente operativa. Incluso mejor aún, vamos a poder personalizar dicha generación para, en todos los proyectos, generar nuestros propios desarrollos totalmente personalizados.

Por lo tanto, si se invierte un poco de tiempo al principio unificando los patrones comunes de diseño y desarrollo que van a tener todas nuestras aplicaciones empresariales, vamos a poder generar las primeras versiones de las aplicaciones de forma muy rápida. Esto nos va a permitir verificar los requerimientos con el cliente en una etapa temprana de desarrollo para poder disminuir los posibles riesgos del proyecto.

Además, Grails se basa en un principio clave, que podríamos denominar «mejoremos la rueda, no la reinventemos«. Es decir, Grails está basado en una serie de tecnologías (como son Spring, Hibernate, etc.) que llevan mucho tiempo funcionando, han sido probadas y se ha demostrado su correcto funcionamiento. Por lo tanto, de manos de su creador Graeme Rocher, Grails nació como una combinación de otros frameworks y un potente lenguaje de programación llamado Groovy, que permite realizar gran cantidad de acciones en pocas líneas de código. Además, Grails permite aprovechar toda la potencia de Java como lenguaje permitiendo a los desarrolladores programar en código Java nativo, o incluso entremezclarlo con Groovy. Por lo tanto, brinda una alta flexibilidad que permite que la curva de aprendizaje no sea muy elevada para el grupo de desarrollo si ya conoce el lenguaje Java.

Grails es, por tanto, una primera aproximación hacia la nueva forma de programación del futuro: una programación más industrializada y modular, que mejorará la productividad de los grupos de desarrollo software.

Raúl Gomis Hidalgo

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

Para ello, una solución ampliamente extendida es la utilización de Frameworks de desarrollo.

Podríamos definir un Frameworks como una estructura conceptual y tecnológica, formada por un conjunto de bloques predefinidos de software, cuya utilización permite la organización y el desarrollo de proyectos software de forma mucho más ágil.

Los desarrolladores pueden utilizar, extender o personalizar estos bloques con el fin de ajustarlos a las necesidades de su proyecto. De esta forma los Frameworks actúan como mecanismos de reutilización permitiendo al programador emplear menos tiempo en la escritura de código de bajo nivel.

Los Frameworks se basan en el Modelo Vista Controlador (MVC), un patrón de diseño que separa las aplicaciones en tres componentes:

• Modelo: son los datos o la información que se manejan en la aplicación.
• Vista: normalmente representada por una interfaz de usuario, presenta el modelo en un formato elegido.
• Controlador: es la capa intermedia. Se encarga de gestionar las peticiones recibidas desde la vista, interactuando con la capa de modelo.

Existen Frameworks para la gran mayoría de lenguajes utilizados en el desarrollo de aplicaciones. Algunos de los Frameworks más conocidos son Spring o Struts para aplicaciones en Java; ASP.NET para C# o Zend para PHP.

Ventajas:

• Los Frameworks utilizan patrones de diseño, lo cual permite que el código resultante sea limpio y extensible para futuras ampliaciones. Entre ellos destaca el Modelo Vista Controlador que comentamos anteriormente.
• Facilitan servicios genéricos necesarios en la mayoría de proyectos. De esta forma, también se utiliza código ya testeado, evitando así en el futuro la repetición de errores.
• Favorecen la reutilización de código, simplificando el proceso de desarrollo. Ello provoca una amplia ganancia de tiempo en cuanto a la programación y el diseño.
• Aumenta la facilidad de depuración del código gracias al MVC.

Desventajas:

• Posibilidad de generación de código innecesario para nuestra aplicación, ya que los Frameworks tienden a generalizar la funcionalidad de los componentes, provocando una demanda de recursos computacionales innecesaria.
• Aprendizaje costoso. El tiempo que se gana en dejar de programar puede perderse en aprender el Frameworks si no se va a utilizar para otros proyectos.
• Existe una alta dependencia del código fuente de la aplicación con respecto al Framework. Además, cada Frameworks tiene su propia convención de código, por lo que no resulta sencillo cambiar de Frameworks.
• Si una librería falla, la depuración es más complicada al no conocer el programador el código. Por eso es importante utilizar Frameworks y módulos en versiones avanzadas.

Por lo tanto, se debe determinar si se va a rentabilizar el uso de un Frameworks, ya sea porque se va a utilizar en varios proyectos o porque se adapta perfectamente a los requisitos de un proyecto específico. En este estudio se deberá tener en cuenta el estado de madurez del Frameworks, así como la documentación disponible acerca de éste.

Lo que resulta innegable es que el uso de Frameworks bajo unas premisas adecuadas mejorará ampliamente la productividad.

Eduardo Morcillo

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

Parece ser que los principales «pesos pesados» de esta lucha entre HTML5 y Flash, son Apple, Adobe, Google y Microsoft.

Por un lado, Apple como férreo defensor de HTML5, contra Adobe, Google y Microsoft (que parece que tiene poco que hacer con su «Silverlight»).

Hasta ahora, los algoritmos de procesamiento vectoriales de Flash siguen siendo una ventaja competitiva en el mercado y, por ello, su código sigue siendo «propietario» y guardado como la fórmula de la Coca-Cola. Por otro lado, HTML5 promete ser el nuevo estándar para la web ya que permite que el vídeo y otros contenidos interactivos que hasta ahora han sido cubiertos por Flash, sean distribuidos sin tener que recurrir a Adobe.

Desde Apple (Steve Jobs) se acusa a Flash de disminuir el rendimiento de los procesadores, pero hay estudios que afirman (y no digo «demuestran» con toda la intención del mundo…) que eso no es cierto, ya que depende de la plataforma sobre la que se ejecute y de si ésta permite o no que Flash acceda a la aceleración por hardware.

Pero seamos prácticos, lo cierto es que hoy por hoy hay muchas empresas que sólo tienen homologado el uso de Internet Explorer, por lo que desarrollar aplicaciones que no funcionen en el Explorer de Microsoft implicaría renunciar a una gran cuota de mercado. Aunque también es cierto que en la nueva versión del Explorer (ver. 9) se soportará HTML5.
Otro factor a tener en cuenta es que, parte de esta lucha de titanes se librará entre aquellos que quieran llevarse su trozo de pastel en el terreno móvil.

Conclusión: ni Flash es lo peor en cuanto a rendimiento y funcionalidades se refiere, ni HTML5 es la solución a todos los problemas. Se trata más bien de una guerra entre imperios que al final se resolverá a favor de uno y otro… ¿Cuándo?, probablemente no en el 2010, habrá que esperar, un poco más.

Mar Santos

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

XML es un lenguaje que define la sintaxis de otros lenguajes de marcación estructurados; un lenguaje de etiquetas extensible que define la estructura de los documentos y, al mismo tiempo, un lenguaje de descripción de datos.

Una característica básica que lo diferencia y lo hace novedoso, pese a su «antigüedad» (su nacimiento oficial fue en febrero de 1998), es su capacidad de compartir datos a cualquier nivel, por todas las aplicaciones y sistemas, dando la posibilidad de compartir información de una forma fácil y segura.

Cada lenguaje basado en XML contiene su propia gramática y sus propias reglas de uso y sólo tiene que cumplir una serie de requisitos imprescindibles para no salirse de la norma, para ser «bien formado»:

• Debe expresar la información de manera estructurada.
• Cada parte de esa estructura debe estar bien definida en sí misma y en su relación con el resto de componentes.

El nacimiento de XML está muy vinculado a la creación de SGML (Standard Generalized Markup Language), otro tipo de estándar internacional capaz de definir la estructura y los contenidos de documentos electrónicos de muy diferente tipología. De hecho, XML surgió de la necesidad de simplificar y optimizar SGML, resultando ser no sólo una versión abreviada del mismo, sino que consiguió superarlo, pues los lenguajes que surgían a partir de XML resultaban más concretos y más cercanos a los programadores.

La difusión que ha tenido XML ha sido en buena parte por el impulso que le ha dado Internet y la necesidad de crear, transmitir y procesar información adecuadamente en distintos campos. No es un lenguaje propietario y su uso está muy extendido en ambientes tecnológicos, lo cual facilita la distribución y utilización de los documentos, así como la aplicación de múltiples herramientas de procesamiento estándar.

Son muchas las ventajas que proporciona:

• Información más asequible y reutilizable.
• Mayor precisión en la utilización de buscadores.
• Reciclaje del formato según las necesidades.
• Facilita el desarrollo de aplicaciones informáticas.
• Son posibles usos simultáneos de los documentos.
• Presentación de la información en múltiples dispositivos, como libros electrónicos o teléfonos móviles.
• La navegación es más rápida y eficaz.

Es simple, flexible y fácil de utilizar. Frente a HTML, que sólo se centra en la visualización de la información, que mezcla contenidos y estilo, y que resulta un lenguaje caótico para navegadores y programadores; XML se abre camino cada vez con más fuerza como un lenguaje de lenguajes que describe estructuras de datos que se autodefinen.

En el terreno de las bibliotecas digitales, donde se procesan múltiples tipos de textos y metadatos bibliográficos, XML ofrece un gran abanico de posibilidades, pues se puede marcar de manera más amplia o precisando hasta el más mínimo detalle: desde un capítulo o un encabezado, a una nota marginal de un historiador meticuloso o una palabra tachada de una edición facsímil. Pero XML llega más allá, cambiando la percepción de publicación y edición digital, pues no hablamos de unos documentos con una entrada y una salida, sino que hablamos de crear unos documentos desde los que crear otros, y según las necesidades o intereses de los usuarios y/o clientes darles una transformación determinada, mediante hojas de estilo, para su presentación en Internet. Es más, los documentos XML están preparados incluso para salir del ámbito web y ser eficaces incluso en la impresión de los mismos. Quizás su única desventaja sea el tamaño de los archivos, pero seguro que es una dificultad que podremos ir salvando sobre la marcha.

Sonia Jover

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.

Actualmente, la inmensa mayoría de los problemas que históricamente planteaba esta tecnología para la navegación web, como el no ser correctamente indexado por los buscadores, el ser completamente no accesible o la pérdida de parte de la usabilidad del navegador web, han sido resueltos en mayor o menor medida. Además, aunque Flash no es un estándar web, está tan extendido que casi se podría considerar como tal. El reproductor de Flash tiene unas cifras de penetración impresionantes: 98% de usuarios de Internet lo tienen instalado, y de ellos, más de un 92%, la última versión: Flash Player 10. La unión de estos dos factores ha supuesto que hoy en día se vea en la web una proliferación de contenidos hechos en Flash, incluso páginas web full flash, es decir, donde toda la estructura del sitio esté integrado en la película flash, sustituyendo por tanto al HTML. Sin embargo, la tecnología Flash no surge para reemplazar a las webs «tradicionales» basadas en hipertexto, sino como plataforma interactiva multimedia para extender las posibilidades de la web.

Para una mayoría de sitios web, el usuario va a querer acceder a cierta información, por lo que quiere que se cargue rápido, encontrar lo que busca (ya sea un contacto, un producto, una noticia, etc.) y salir. Un mensaje de «cargando» es una barrera entre el usuario y la información a la que quiere acceder. Una intro, por muy espectacular que sea, también. Animaciones, música y efectos de sonido son mayoritariamente distracciones en el camino. Esto no quiere decir, claro, que un sitio puramente informativo tiene que ser feo o seguir a pies juntillas una estética Jakob Nielsen. Un buen diseño estético y funcional hace un sitio web más intuitivo (y, por lo tanto, más rápido y sencillo de utilizar), pero es importante tener cuidado de no abusar del efecto eye candy: el tratar de atraer la atención del usuario con algo que impacte a primera vista. Demasiadas veces Flash es utilizado para este propósito en sitios para los que no aporta absolutamente nada. Hay que tener en cuenta que la carga de texto básico con imágenes en una película flash es mucho más lenta que con HTML puro, por lo que debe de haber una buena justificación para su uso, más allá del de «llamar la atención». Así que muchas de las posibilidades para las que Flash brilla como tecnología son inútiles o, peor aún, pueden redundar negativamente en la visita a un website meramente informativo.

Es una máxima universal que para toda tarea debe elegirse la mejor herramienta disponible, y la programación web no constituye en ningún caso una excepción. No debemos caer en el error de utilizar las enormes capacidades de Flash cuando no es apropiado, ni necesario. Algunos de los posibles usos donde se puede aprovechar toda la potencia de Flash son:

• Webs «escaparate» donde se requiera ofrecer relativamente poca información textual y por el contrario sea clave una visualización más impactante o que se ofrezca al usuario la posibilidad de interactuar para adquirir una experiencia más rica sobre lo que se expone. Un ejemplo serían vistas detalladas con zoom o incluso en 360º de productos tales como obras de arte, coches, vestidos, etc.
• Portfolios de artistas como por ejemplo músicos o pintores, donde se pueden aprovechar las características multimedia de Flash para integrar las obras en la web.
• Presentación de contenidos interactivos. Ejemplos de esto podrían ser websites educacionales o que presenten planos interactivos o visitas virtuales a viviendas en venta, galerías de arte, museos, etc.
• Siempre que la reproducción de vídeo constituya una parte integral o importante de la web. Hablar de vídeo en la web hoy en día (y me atrevo a decir que en un futuro a un corto y medio plazo también) es hablar de Flash, simple y llanamente.
• Interacciones complejas tales como presentaciones multimedia, vídeos o incluso pequeños videojuegos que cumplan el propósito de enganchar y entretener al usuario para que alargue la estancia en nuestra web, que normalmente se incluirán como secciones independientes al margen del contenido «principal» del sitio.

Estos son tan sólo algunos ejemplos, ya que las posibilidades son casi infinitas, aunque siempre debe tenerse en cuenta el objetivo final: el proporcionar al usuario final una experiencia interactiva y visual única y memorable.

Daniel García Nebot

Se permite la reproducción de este artículo manteniendo la integridad del mismo, y siempre que se incluya el enlace a esta página como fuente de referencia.

Si ústed es su autor/a y considera que no debe estar aquí notifíquenoslo para que lo eliminemos.