« Artículos « BlogTutorialesDownloads

Aquí va un listado de 10 malas prácticas que, sin ser especialmente graves, perjudican al desarrollador Web en su tiempo de desarrollo, en la limpieza del código que desarrolla, en su mantenibilidad a futuro, en el trabajo colaborativo con otros desarrolladores o en errores exóticos que después uno no sabe de dónde salieron.

Estas mañas suelen ser fruto de la inexperiencia y sí, alguna vez las cometí todas. En especial para quienes están empezando en esto del desarrollo Web, les va a servir de mucho.

Este post está dividido en dos partes, en forma de ranking, así que aquí les va desde el error 10 hasta el 6. ¡Mantente atento a la parte II para conocer los próximos 5 errores!

10 -Usar Espacios o Acentos en Nombres de Carpetas y Archivos

Este es un clásico, como por ejemplo “portada web 5.html” o “imagenes para la web/”. El problema que tiene esto es que los espacios, las eñes, los acentos y otros caracteres no estándares, al no ser parte de una URL, necesitan ser escapados, es decir, convertidos a un código equivalente. Esto de por sí, afea  las direcciones, además de que ciertos servidores definitivamente no los toleran.

9 - Usar Nombres Exóticos Para Cosas Comunes

“imagenesweb”, “imagenes layout”, “imágenes para la interfaz” y otros semejantes han sido usados por mí y otras personas que conozco :) para denominar la carpeta que comúnmente llamamos “images”.

Lo mismo con la portada del sitio, error que ya vimos en otra ocasión. En vez de sencillamente usar “index”, los desarrolladores vuelcan la creatividad (que debiera irse al diseño) en los nombres, como “portada”, “homepage”, “portal”, “inicio”, y otros.

Lo mismo con los nombres de clases y IDs en CSS. No es necesario usar “menu-principal-de-arriba” si podemos usar “menu”. No es necesario complicarse con “pie-de-pagina”  o “columna-derecha-delgada” si podemos usar “sidebar”.

En general, usar convenciones para los nombres de cosas hace que tengamos que pensar menos, permite que otros puedan entender los archivos más rápidamente, tiene ventajas con los servidores y otro software que suelen intuir los nombres de archivos, y nos permite trabajar en proyectos antiguos u olvidados más rápidamente, sin perder tiempo en descifrar qué poéticos nombres habremos usado esta vez.

Usa seguido los siguientes nombres:

• index
• logo
• style
• menu
• footer
• header
• sidebar
• images
• swf
• (etc.)

8 - Dejar que Dreamweaver Cree Automáticamente los Estilos

¿Tu CSS está plagado de nombres tales como “Estilo1”, “Estilo2”, “Estilo36”, “Estilo389”? Probablemente estás intentando crear páginas en Dreamweaver como si crearas un documento en Word. Si quieres marcar algo como rojo, claro, Dreamweaver hará su mejor esfuerzo, creando una clase “Estilo1” con color rojo y lo aplicará a tu selección.

Pero ya que estamos hablando de sitios Web, y no de presentaciones con diapositivas, necesitamos más disciplina y orden a la hora de crear los estilos. Lo primero, y lo insinuamos en el punto anterior, está en ponerle nombres relevantes a las clases que creemos. Sólo de esta manera aprovecharemos el poder de las clases, que es reutilizarlas una y otra vez, sin confundirnos ni perder tiempo intentando entender lo que creó Dreamweaver.

Lo segundo es planificar la creación de clases. Si necesitamos texto marcado como rojo, asumo que no es por una inspiración de último minuto, sino por una decisión de diseño ya previamente pensada. Por lo mismo, las clases que usemos en el sitio deberán reflejar dichos criterios. Es mejor crear las clases primero en CSS y usarlas después en el HTML.

De la misma manera, hay que evitar caer en algo que podríamos llamar “desesperación CSS”. Consiste en crear compulsivamente IDs y clases CSS para cada elemento gráfico nuevo que surja, sin preocuparse de optimizar o de tener un sistema de clases ordenado que nos ahorre tiempo en el futuro. Para más ideas sobre un buen sistema de clases CSS, lee este artículo: Las ventajas de usar CSS contextual.

7 - Hacer Maquetas sin Pensar en la Factibilidad Técnica

Esto suele pasar cuando uno recién empieza en el desarrollo Web y viene con un gran ímpetu por hacer los sitios más ricos y estéticamente producidos que se pueda. En este afán, es muy común comenzar a jugar con efectos, superponer degradados y transparencias complejas y “volarse” creando, sin tener claro los problemas que dichos recursos nos pueden traer a la hora de traducir la maqueta gráfica en HTML.

Fireworks (o Photoshop, o Freehand, o lo que sea) aguantan mucho en materia de creatividad, pero el límite tiene que ponerlo el diseñador, basado en su experiencia y en sus habilidades. Si superponer tres gradientes con transparencia nos significará una semana más de trabajo e investigación intentando llevarlo a cabo en la página real, y realmente para el cliente no es vital y tampoco añade tanto valor al sitio, ¿para qué complicarse?

El criterio que sugiero es: al momento de diseñar o maquetear, piensa siempre: ¿cómo haré realidad esto en HTML?

6 - No Conocer el Soporte Sobre el Cual se Trabaja

Este punto está muy ligado al anterior. Los diseñadores que se apoyan en un desarrollador HTML y por tanto, creen que pueden desentenderse de las limitaciones propias de la Web, no tienen excusa.

Es el equivalente a diseñar un libro, sin pensar en el soporte (papel) sobre el que se trabaja, y planificar páginas rellenas de agua o enchapadas en oro, dejándole a otro la tarea de concretar dichas ideas en el impreso en papel. Suena descriteriado, ¿no? Pues es lo mismo en la Web.

Un diseñador, aunque no le toque escribir código directamente, tiene la responsabilidad de saber qué se puede, qué no se puede hacer, y dentro de lo que se puede, qué es fácil y qué toma mucho trabajo a la hora de desarrollar Web. Limitaciones como formatos de imagen, uso de efectos, plugins, problemas de compatibilidad CSS, uso de fuentes y otros deben ser siempre tenidos en mente a la hora de diseñar.

Mantente atento a la segunda parte de este artículo. ¿Tienes dudas, aportes, tus propias ideas sobre errores comunes? Hazte parte en los comentarios.