En términos generales, cuando es hora de construir un sitio, los diseñadores toman uno de dos caminos: hacerlo en XHTML/CSS/JS ó hacerlo enteramente en Flash. Es bastante claro que nosotros casi siempre optamos por el camino del XHTML/CSS/JS y usamos Flash sólo para agregar toques aquí y allá.

Una de nuestras reglas es una frase que leí hace tiempo en algún sitio: Flash jamás debería ser usado para hacer cosas que podés hacer con XHTML/CSS/JS. No recuerdo donde lo leí pero desde que lo hice ha sido mi arma de preferencia cuando un cliente insiste en utilizar Flash. Hay muchas cosas que XHTML/CSS/JS no pueden hacer y por eso es que tenemos Flash.

Esto nos lleva a preguntarnos cuáles son los tres errores más comunes que hacen los diesñadores Flash, según nuestra filosofía de trabajo.

1. Intros que no pueden ser saltadas

Esta es, sin duda, una de las cosas más molestas que le han pasado el diseño web. Los diseñadores Flash tardan mucho tiempo en hacer estas intros y están tan orgullosos de ellas que fuerzan al visitante a mirarla para mostrar su destreza con Flash.

Supongo que jamás se le ocurrió al diseñador que la gente no viene al sitio a mirar intros. Vienen a buscar información y la intro sólo se está interponiendo en el camino.

Ya es bastante malo que el sitio tenga una intro en Flash. No hay que empeorar las cosas al no proveer una manera de saltearla. Esta es una de las peores cosas que les puedes hacer a los visitantes. No permitir saltear la intro no le ayuda a nadie, ni siquiera al diseñador, aunque éste crea que la intro es tan buena que la gente TIENE que verla.

2. Música

Estamos en el 2009. Estoy bastante seguro que la mayoría de las personas tienen un reproductor de medios y varios Mp3s en su computadora y generalmente escuchan música cuando navegan por Internet. ¿Cuál es el sentido de interrumpir la música que ya eligieron por la musica que el diseñador eligió?

Es probable que si el visitante no está escuchando música es porque no puede o no quiere. Nosotros como diseñadores y desarrolladores deberíamos respetar ese deseo.

Las personas comparten espacios de trabajo con colegas y es molesto para todos cuando empieza a sonar música de la nada.  Para empeorar las cosas, algunos stios ni siquiera tienen la opción para apagar la música o la han escondido demasiado en su diseño.

A menos que seas Pandora, la gente no viene al sitio a escuchar música. Vienen a buscar información y la música se está metiendo en el medio del camino.

3. Navegación enigmática

Esta es, lejos, una de las cosas que más me llama la atención. Realmente no puedo encontrar una explicación lógica acerca de por qué alguien querría encriptar el menú de navegación. ¿Cuál es el sentido de que el visitante no pueda encontrar su camino fácilmente?

Imaginen que van a un zoológico para ver canguros y, al llegar, se dan cuenta de que todos los letreros están escritos en Klingon. Claro, esto está bien para algunos fans de Star Wars, pero para todos los demás es algo realmente molesto, especialmente si lo único que querés ver son los canguros y luego irte.

Este es un menú de navegación que vi esta mañana:

Este tipo de navegación no sirve para nada. Fuerza al visitante a hacer click en todo para encontrar lo que está buscando. Algunos diseñadores agregan un rollover, cosa que es bastante mejor que nada, pero lo principal es que la navegación es uno de los aspectos más importantes de un sitio y debería ser lo más claro posible, a menos que estés haciendo un sitio para fans serios de Lost.

A pesar de que estos errores pueden ser cometidos por diseñadores que no trabajen en Flash, casi siempre son encontrados en sitios basados en esta tecnología. No está mal construir sitios en Flash, pero en nuestra opinión, Flash sólo debería ser usado cuando necesites hacer cosas que XHTML/CSS/JS no puedan hacer.

El año pasado escribí una nota sobre la seguridad de los datos y cómo el hacer respaldos regularmente es crucial para cualquier proyecto.

También hablé sobre dos cosas que podrían pasar para que tu servidor y datos se perdieran del ciberespacio: redadas de la policía (The Pirate Bay) y combustión espontánea (incendios eléctricos). Bueno, no quiero sonar como un presumido pero el escenario de la redada policial se repitió, esta vez en Dallas.

El FBI hizo una redada a un datacenter entero y confiscó todo porque uno de los cientos de servidores estuvo involucrado en la distribución de una película pirata, dejando a muchos otros clientes inocentes sin sus sitios, servicios de email, etc. Los clientes de este datacenter incluyen varias compañías de telecomunicaciones y esta redada causó que el servicio del 911 no funcionara para algunos de ellos. Si al FBI no le importa algo tan crucial como el servicio de 911, ¿qué te hace pensar que les importan tus datos?

Lee más acerca de esta noticia acá.

La entrada de hoy tiene como tema algo muy importante: la seguridad de nuestros datos. Muchos clientes nos llaman y nos preguntan cuál el costo de “poner una página en Internet”.

Luego de explicarles que nosotros no ofrecemos “páginas”, sino “sitios web completos y complejos centrados en el usuario para mejorar la presencia online de la marca”, generalmente tenemos que empezar a detallar los costos relacionados con emprender el proyecto.

Una de las aclaraciones que hacemos de entrada es que, a diferencia de otros estudios, nosotros no ofrecemos servicios de hosting.

¿Por qué? Porque no somos ingenieros en sistemas ni administradores de servidores; somos diseñadores y desarrolladores de sitios y aplicaciones web. Somos expertos en eso y solamente en eso.

Esto básicamente quiere decir que nosotros no tenemos la experiencia o el know-how para garantizar a nuestros clientes la seguridad y continuidad de sus sitios web, bases de datos, emails y demás datos alojados en el servidor.

De hecho, prácticamente ningún estudio de diseño está en condiciones de hacerlo, a menos que también tengan administradores de servidores en su nómina. Por supuesto que para ser un administrador de sistemas se requiere mucho más que “manejarse con Linux y SSH”. Aún así, es muy probable que los servidores estén en otros países y sean suceptibles a fenómenos que en Uruguay no nos preocupan, como huracanes o terremotos. Lo peor de todo es que nadie, ni siquiera la compañía que tiene el servidor en sí en sus jaulas de servidores, puede garantizar que nada le pase al servidor.

Lo que sí podemos hacer en Ahlera es construir aplicaciones y sitios robustos que interactúen con el servidor para obtener resultados, siempre y cuando el servidor esté funcionando. Esa parte en negrita es la que nosotros no podemos garantizar. También podemos sugerir y asesorar cuál servicio seleccionar.

Hace seis años perdí un servidor con varios sitios míos porque se prendió fuego el datacenter inesperadamente gracias a un corto circuito. Mi proveedor era una de las principales compañías de servidores dedicados del momento y el datacenter tenía todo tipo de seguridad contra fuego, agua e intrusión, pero pasó.

En Mayo del 2006 la policía sueca hizo una redada al proveedor de hosting del polémico The Pirate Bay. Confiscaron todos los servidores, cables, switches y routers que habían ahí. El problema es que el proveedor de hosting no sólo ofrecía los servicios a The Pirate Bay, sino a otros clientes también. Por supuesto que las máquinas de clientes que no tenían nada que ver con The Pirate Bay también fueron confiscadas, por lo tanto sus sitios también quedaron offline.

Hay una cantidad de casos posibles por los cuales un servidor podría no estar funcionando. Acabo de mencionar dos casos extremos que se me vinieron a la mente. Piensen en los miles de casos más comunes que no contemplé.

En este momento estamos desarrollando una aplicación que necesita de dos servidores con configuraciones totalmente distintas y en lugares geográficos distintos. Nosotros planificamos las especificaciones de cada servidor en base a nuestra aplicación y ayudamos a seleccionar el proveedor final, pero nuestro cliente sabe que nuestra responsabilidad llega hasta donde llegue el funcionamiento de nuestra aplicación. Si el servidor se cae, se rompe o se prende fuego, sabe que tiene que contactar al proveedor de hosting. Por supuesto que lo ayudaremos en lo que podamos, pero es muy consciente de que estamos totalmente exentos de responsabilidad.

Si tenés un estudio de diseño que ofrece hosting, quizás debas hacerte las siguientes preguntas:

• ¿Sabe mi cliente hasta donde llega mi responsabilidad?
• ¿Tengo un documento firmado por mi cliente en donde se especifique que él es consciente de los límites de mi responsabilidad y operabilidad?
• ¿Hago backups remotos todas las noches de todos los emails, bases de datos, logs, documentos, etc. de mis clientes?
• ¿Estoy en condiciones de afrontar un juicio hecho por un cliente que perdió todos sus emails porque falló el RAID1?

Si sos un cliente que deja el alojamiento de su sitio a cargo del estudio de diseño quizás deberías llamarlos y preguntarles lo siguiente:

• ¿Tienen backups (respaldos) de mi sitio, emails, bases de datos y otros datos en un servidor distinto al mío? No tiene ningún sentido guardar un respaldo en la misma máquina.
• ¿Cada cuánto hacen estos backups?
• ¿Qué pasaría si le pasara algo grave hoy al servidor y se perdieran todos los datos? ¿Cuánto tardaría mi sitio en volver a estar online? ¿Y mi mail?

No importa el tamaño del sitio o el tamaño del cliente. Todos los datos son cruciales para su dueño y es necesario que se piense un poco más en la responsabilidad que viene con ofrecer un servicio de hosting. Sabemos que los resellers han existido desde que Internet vio la luz y jamás usaríamos uno para nuestro negocio ni recomendaríamos uno a un cliente. Por eso nos escandaliza cuando vemos las páginas de otros estudios en donde se habla de hosting como parte del trabajo de diseño.

La verdad es que el hosting y el desarrollo de sitios web son cosas totalmente distintas. Es casi la misma diferencia que existe entre el arroz y el mango, por ponerlo de alguna manera.

Esperamos que esto ayude tanto a clientes como a estudios de diseño a tomar conciencia de la importancia de los datos y por qué es mejor dejar que los ingenieros se encarguen de ellos.