Puede que al leer el título muchos de vosotros (espero que la mayoría) hayáis tenido el reflejo de mirar al calendario para comprobar que no estamos en 1999 (o alrededores). Para la mayoría de desarrolladores web es algo más que obvio: No debes usar frames.
No obstante, cada día hay muchas personas introduciéndose en el mundo del desarrollo web y, por desgracia, muchos de ellos acuden a los tan manidos tutoriales y manuales que llevan siglos rodando por la red, cayendo en esos errores que tantos años nos costó a los demás evitar. Sin ir más lejos, ayer mismo, en un foro (siento no recordar cual) vi una pregunta del tipo ¿Cómo creo una web con frames? y yo pensé ¿por qué iba nadie a querer crear una web con frames? ¿Quizá porque desconoce todos los inconvenientes que conllevan?
De ahí estas 9 razones por las que no debes utilizar frames:
Y, en caso de necesitarlos, crea frames más accesibles y usables
El equipo de desarrollo de WeCreate ha hecho un listado de aspectos que debemos recordar a la hora de crear aplicaciones y sitios web: 10 rules to code by.
A continuación os dejo una traducción muy resumida, para la explicación exhaustiva ojead el artículo en inglés.
- Asume que todos los usuarios son el demonio. A pesar de que la mayoría de los usuarios son buena gente, corremos el riesgo de que alguno no lo sea por lo que ninguna medida de seguridad que tomemos es poca.
- Diseña para tus usuarios, no para programadores
- Sólo debes utilizar Javascript para mejorar los interfaces de usuario. Por muy 2.0 que sea tu sitio debe seguir siendo usable sin Javascript
- Haz una separación clara entre la lógica, la presentación y el interface
- Los estándares importan
- La semántica importa
- Documenta o muere
- Asegurar un sitio ocultando cosas no es seguridad
- KISS: Empieza simple y mejora después
- Aprovecha a tu equipo, están en tu mismo bando
En Digital Web Magazine hacen una interesante analogía entre el proceso de compra de un objeto físico con el proceso de registro de un nuevo usuario en un servicio web.
Se trata de un enfoque interesante que nos habla, en resumen, de lo importante de crear un sitio que proporcione a nuestros usuarios y potenciales clientes una experiencia agradable, desde la primera impresión del sitio ,que será nuestra cara delantera del envase, hasta las instrucciones de uso, asociadas con la parte trasera del envase, pasando por el proceso de desembalaje del sitio, equiparado con el proceso de registro.
Seguro que, en estos términos, en el departamento de Marketing entienden mucho mejor la necesidad de crear sitios web bonitos, accesibles y usables.
Desde hace mucho tiempo venimos tomando como correcto el cálculo de que 7 segundos es el máximo de tiempo que puede tardar nuestro sitio en cargar, no obstante, temblad fanáticos del Javascript por doquier, hace unos días en Akamai publicaban:
Akamai and JupiterResearch Identify ‘4 Seconds’ as the New Threshold of Acceptability for Retail Web Page Response Times
Si señores, recientes estudios demuestran que los usuarios, potenciales compradores, consideran incomodo e incluso inaceptable esperar tiempos de carga prolongados al visitar una tienda online (y por extensión casi cualquier sitio) y que, si esta tarda más, pueden llegar a abandonarla para no volver jamás.
El informe completo en ingles en www.akamai.com/4seconds.
El otro día, en SEOmoz se indicaban algunas formas de explicar a alguien por qué un sitio no debe tener música de fondo, hoy le toca el turno a las «splash screens».
Durante un tiempo estuvieron de moda estas páginas de introducción, sin contenido, sólo con una imágen o peor, una animación en Flash o un applet Java. A pesar de que, pronto, se mostraron inútiles y molestas, pervive entre algunos sectores la idea de que son «cool».
Supongo que todos tenemos claro que los usuarios realmente no disfrutan de esas animaciones espectaculares y que, casi siempre, se las saltan o incluso abandonan la página al no encontrar inmediatamente lo que buscan. Para los que aún necesitéis cargaros más de razones:
How to Convince a Client They Don’t Need a Splash Page
Supongo que la mayoría de los que visitáis este blog ya sabréis lo incómoda que resulta la musiquilla de fondo de algunas páginas y las muchas desventajas que tiene. No obstante, cuando trabajamos para otros, podemos vernos ante peticiones de este tipo o peores.
En SEOmoz han recopilado un conjunto de 9 razones que podremos esgrimir para disuadir a posibles clientes:
- Es obstrusiva
- Se corta cuando navegas por el sitio
- No todos los navegadores y Sistemas Operativos lo soportan
- Ralentiza las cosas
- Queda poco profesional
- Si otros sitios no la utilizan es por algo
- No a todo el mundo le gusta tu música
- Preguntales si han visitado MySpace
- Consume ancho de banda
El artículo, completo en inglés: How to convince a client their site doesn’t need music
Más allá del debate acerca de si es o no momento de empezar a pensar en resoluciones de pantalla mayores existe un amplio grupo de diseñadores que ya implementan diseños optimizados para 1024×768.
Llevamos mucho tiempo creando sitios que se vean correctamente a 800×600 y sabemos que podemos extender nuestro diseño hasta los 760px sin miedo de que aparezcan barras de desplazamiento pero ¿Hasta qué tamaño podemos diseñar para una resolución horizontal de 1024?
Cameron Moll nos responde y parece que 960px podría ser lo más parecido a la anchura ideal.
Seguro que en alguna ocasión os habéis visto forzados a «improvisar» un acuerdo legal para un sitio web. No es algo que nos ataña a los desarrolladores pero es algo que solemos hacer, no tiene nada de malo siempre y cuando tengamos en cuenta que se trata de un documento legal.
A través de Error500 encuentro el que sin duda es el post más esclarecedor al respecto de los acuerdos legales y la LSSI: Cómo hacer un aviso legal por el abogado Javier Prenafeta.
Imprescindible para los que trabajamos en España.
De un tiempo a esta parte están apareciendo multitud de frameworks para todos los lenguajes de programación imaginables. Una práctica que, en principio, parece destinada a ahorrarnos tiempo a los desarrolladores.
Via Barrapunto descubro Why I Hate Frameworks, una sátira sobre lo contraproducente que puede llegar a ser utilizar frameworks para determinados trabajos.
El autor compara la programación con el bricolaje y nos pone ante una situación surrealista ¿Qué pasaría si en la ferretería en lugar de vender martillos vendiesen máquinas de fabricar máquinas de fabricar martillos?
El otro día hablabamos de lo importante que es saber exactamente lo que necesitamos antes de salir a buscar un proveedor de alojamiento web.
Ahora que lo tenemos claro, lo normal es comenzar a buscar y recopilar unos cuantos candidatos. Después tendremos que ir descartando.
(más…)
Webmaster Libre es un blog de Alma Fernández Página alojada en Redcoruna