Uno de los errores más comunes y que todavía se pueden apreciar en la Web. Me deleita un montón ver ejemplo como 2advanced, que no ofrecen su contenido siquiera en una versión alternativa, por ejemplo saber que puedo ver sus producciones de video (ya tengo quicktime instalado) o por ejemplo leer sus noticias, y así no tengo que instalar otro programa más.
Puede que sea un poco cerrado el pensamiento, pero la idea es poner (aunque sea) un acceso a algo un “saltar introducción", Kursor.tv parece no importarle y todo su negocio depende de una película en Flash, basta que alguien no tenga Flash instalado para que se vaya a otra Web de su competencia. Pueden ver que en la página Kursor.tv no hay indicios de accesos a versiones en HTML, tampoco hay teléfonos a mano…
Si utilizan Flash, hay que pensar por la gente que no lo tiene instalado, puede que esa misma gente incluso no tenga javascript o no tenga la versión correcta del plug-in de Flash, suele ocurrir que todo funciona mal o no se esperan los resultados, los plugins de detección no averiguan a la perfección que tipo de plugin versión 00000000.000000222 tenías instalada…
Otra de las cosas es utilizar Flash y no ofrecer una réplica de tu sitio indexable y navegable para personas con discapacidad motora por ejemplo (usan el teclado para moverse en un sitio…) es otro error tirando a crimen.
No abuse del Javascript, amigo desarrollador, estoy realmente agotado de ver como funcionan los scripts en los navegadores, que si tengo que usar Internet Explorer para ver un menú importante, para acceder a mi cuenta bancaria… basta ya de abusar de Javascript.
No quiero decir que dejes de utilizarlo, sino haz las cosas con precaución y por favor, examina los resultados en otro ordenador que no sea tu mega-ordenador con Internet Explorer build 6.001324, por que con mi Portátil PC Asus y Windows 2000 con Internet Explorer 5.993888 no puedo usarlo correctamente, y mi amigo Juan con su Internet Explorer 5.5 (5.789000) tampoco puede… Javascript no es idéntico entre navegadores, menos entre Internetes Exploretes, de hecho he podido comprobarlo utilizando 6 PCs distintas con diferentes Explorers y notar diferencias que entre algunas eran abismales.
Ni hablar de usar otra cosa que no sea el alabado Internet Explorer, pongamos Opera, Netscape 7 o Mozilla, no… ¿para qué?… Tampoco hablar de utilizar Internet Explorer para Mac, no… ¿para qué?
Javascript no es un lenguaje perfecto para ser el esqueleto de un website, ni mucho menos para controlar la interacción entre documentos, os digo algo, si desactivo Javascript en mi navegador el sitio de Correos de España se navegable en un 20%, no llego siquiera a enviar una postal desde la página de “Envíe una postal por Internet", desepcionante.
Por eso, fuera de chistes e ironías y sin ánimos de ofender a nadie, abusar de esa forma de Javascript, no es ideal.
Algo que cuesta de entender, es que, HTML no es un lenguaje de moldeo de páginas, de hecho el HTML no tiene estética alguna, solo significado, es un lenguaje para clasificar contenidos, que luego con otra tecnología se editarán los factores visuales, es por eso, que es estúpido utilizarlo para desarrollar layouts, colorear páginas, posicionar elementos… para esas cosas se ha creado CSS.
Podremos ver que el gran porcentaje de sitios utilizan tablas para hacer layouts, esto no está bien, pueden ver el ejemplo del Error 8, las tablas son elementos que fueron creados para representar datos, no para crear esquemas o maquetar un sitio entero, es como si utilizáramos gasolina de avión en nuestro coche, la gasolina quizás haga que nuestro motor funcione, pero tarde o temprano funcionará mal, por que la gasolina de avión tiene más octanos y está diseñada para motores grandes, motores de aviones.
He visto cosas aberrantes, pero hay cosas que no se pueden creer, por ejemplo, es común en desarrollos comentar ciertas partes de un código, en programación puede incluso ahorrar mucho tiempo por que cuando se comenta no se borran cosas, o simplemente se comentan para probar cosas… pero en HTML, cuando se comenta una línea, el servidor Web procesa la página, y el código comentado, enviándolo al ordenador cliente, de modo que el mismo navegador es el que no procesa este código comentado.
Un error básico es utilizar los comentarios de HTML para comentar largas porciones de código HTML, los comentarios de HTML están hechos para realizar ayudas, o para hacer anotaciones.
El problema comienza cuando se comenta 10 líneas de código en HTML éste sigue apareciendo y siendo procesador por el servidor, debería comentar esto con otro tipo de lenguaje, de modo que sea procesado directamente en el servidor Web y no en el navegador.
Ejemplo de una porción de código encontrada en la web de correos:
<!--<tr> <!-- 4-->
<!–<td height="24″ valign="bottom"> <a href="/01/02/0102_b.asp” onclick="javascript:pulseExt(’men01′);” class="TitSeccionBold">
Cartas Certificadas</a> </td>
</tr>
<tr>
<td height="6″ valign="top"><img src="/comun/img/lin_g_sep.gif” width="310″ height="1″></td>
</tr>
<tr>
<td class="txtNormal” height="25″ valign="top">Para enviar con total tranquilidad sus comunicaciones especialmente importantes, con entrega bajo firma.</td>
</tr>
<tr>
<td height="5″><img src="/comun/img/pix_fondo.gif” width="1″ height="1″></td>
</tr>–>
<!– 5–>
<!–<tr>
<td height="24″ valign="bottom"> <a href="/00/04/0004.asp” class="TitSeccionBold">
Acceso a Internet</a> </td>
</tr>
<tr>
<td height="6″ valign="top"><img src="/comun/img/lin_g_sep.gif” width="310″ height="1″></td>
</tr>
<tr>
<td class="txtNormal” height="25″ valign="top">Acceda a internet mediante
línea de alta velocidad. Disponible en más de 35 oficinas
distribuidas por todo el territorio.</td>
</tr>–>
Esto nos ahorrar tener que enviarle al ordenador cliente, código que nunca procesará e utilizará, unos cuantos KB menos de peso en cada página. Esto se logra no utilizando los comentarios normales de HTML <!-- --> sino utilizando algún lenguaje de scripting normal como PHP o ASP.
Otra de las cosas que recomiendo es no comentar largas porciones de código, sino directamente borrarlas o extraerlas a otro documento de repositorio.
Un factor importante en los documentos Web debe ser la separación del contenido de la presentación, de modo que el HTML sea para contener y el CSS para presentar, por eso, utilizar hojas de estilos embebidas en el mismo documento no es sano.
En muchas páginas institucionales vemos como embeben el código de las hojas de estilos en la cabecera, en vez de tener 1 hoja de estilos externa con la información para la estructura y posicionamiento de los elementos principales, y otra hoja de estilos que varía de sección en sección, 1 para todas las páginas, con la información mínima, y la otra es una información unica para realizar un posicionamiento de un elemento o algo que se encuentre en 2 o 3 páginas, aquí estamos dividiendo recursos, y economizando trabajo. Algo cómun que vemos en la Web de Correos de España y el diario El País:
<head>
<style>
.TA
{
scrollbar-3dlight-color:#666666;
scrollbar-arrow-color:#666666;
scrollbar-base-color:#666666;
scrollbar-darkshadow-color:#666666;
scrollbar-face-color:#e2e2e2;
scrollbar-highlight-color:#e2e2e2;
scrollbar-shadow-color:#c0bebe
}
</style>
</head>
Nótese que esta estupidez solo hace que un documento de HTML contenga caracteres que no se puedan cachear de ninguna forma tradicional, de hecho cada vez que el usuario recurra a esta página, tendrá que descargarse y procesar esta porción de código, que es poca si, pero cuenten unos 70 documentos, y hagan el cálculo de cuantos KiloBytes llevan sumando.
En la Web de Correos, se pueden observar cosas como porciones masivas de código CSS en todos los documentos, no sólo ubicada entre los elementos sino en el medio del documento mismo, cosa que no está permitido, ni es una práctica muy sana…
Tampoco es sano ver que un tag bold tiene estilos en línea, por ejemplo, observamos en la página del diario El País:
<div id="lClipping" class="TA" style="overflow: auto; position: absolute; left: 0px; top: 0px; width: 187px; height: 208px; z-index: 5; visibility: hidden;"></div>
Algo bien hecho hubiera sido como esto (aprovechando que utilizan el id “lClipping")
<div id="lClipping" class="TA"></div>
Esto es código de HTML que se procesa una y otra vez, se envía y se descargar cada vez que alguien requiere la página, ¿No es mejor asignarle una clase especial a ese tipo de módulos? ¿Y de esta manera se aprovecha todas las clases en múltiples páginas a tener que cargar en línea siempre la misma cantidad de código? Esto está mal.
Otro grave error parecido, al caso de las hojas de estilo es que no se modularíza el código Javascript, de ninguna forma, ni usando un lenguaje de scripting siquiera.
Esto es muy común cuando utilizan javascript para menús, que se repita siempre la misma historia de siempre, se repiten incansablemente porciones gigantes de código Javascript, ¿No es mejor modularizar esto de esta forma?
<script type="text/javascript" src="js/GestionaPestana_arrays.js"></script>
Si modularizas código de Javascript, éste se descargará una vez y será cacheado por el cliente y re-utilizado cada vez que se necesite.
Si hay algo que deben enterarse medio millón de desarrolladores es que, los elementos metas prácticamente son inservibles, de hecho los buscadores como Google ya no procesan ni indexan gracias a los elementos meta, dado que nadie los desarrolla bien, dado que los meta keywords y meta description no definen de forma correcta los contenidos principales de un sitio, Google los pasa por alto, y muchos buscadores también lo hacen así.
Las tecnologías de ahora permiten buscar mejor en el contenido, que fiarse en dos elementos creados por un departamento de marketing.
La solución es dejar los elementos meta que sirven a los navegadores, como los que especifican la codificación del archivos (si es UTF-8 u ISO-8859-1), los que controlan los robots de los buscadores, y nada más. El resto sobra.
La solución es implementar más los elementos <link> que realmente ayudan más distribuir contenidos de un sitio que los tags meta.
<meta name="generator" content="BBEdit 6.5.2">
<meta name="origen” content="EL PAÍS">
<meta name="description” content="El principal periódico europeo en español">
<meta name="author” content="El País S.L. - Prisacom S.A.">
<meta name="organization” content="El País S.L.">
<meta name="locality” content="Madrid, España">
<meta name="lang” content="es">
<meta http-equiv="Content-Type” content="text/html; charset=iso-8859-1″>
<meta name="keywords” content="El pais, diario, periodico, newspaper, prensa, press, noticia, news, internacional, international, world, nacional, national, nation, españa, spain, información general">
<meta content="900″ http-equiv="REFRESH">
<meta name="rating” content="safe for kids">
<meta name="Author” content="Filmac centre s.l.">
<meta name="Language” content="es">
<meta name="revisit-after” content="30 Days">
<meta name="audience” content="general">
<meta name="privacy” content="http://bancaja.es/legal/notalegal.asp">
¿Para qué hace falta una página con un millar de enlaces? ¿El usuario no puede encontrar lo que busca? Entonces eso sucede por 2 factores:
Esta claro, en el 100% de los casos noto que el mapa del sitio es algo inútil, no ayuda en nada, el usuario no tiene por qué mirar entre un millar de enlaces, no hace falta, tampoco le ofrece la solución instantánea.
La solución es un buen buscador, de modo que ni bien entro a un sitio, no tengo que estar 1 hora inspeccionando una página con 700 enlaces, hacer un mapa del sitio de un sitio de banco es prácticamente una salvajada, igualmente para aquellos sitios que poseen 3 secciones y su página Web consta de 50 documentos.
Nada mejor que un buen buscador y una buena arquitectura de la información.
No existe nada más inútil que un buscador que ¡no puede buscar!, de hecho, si entramos a un website normal como el diario El País y busco artículos, no sale nada útil, ni la categoría.
Para empresas que disponen de presupuestos grandes, no tener un buscador decente es un punto en contra.
El contenido esencial de minid.net está 100% indexado y se puede buscar a la perfección, usar grep patterns incluso.
Responsables de un sitio Web, Internet no es una televisión, es por eso, que entrar a un sitio es como el diario El Pais es para ver los titulares, no para encontrarse una pantalla negra, con una publicidad de Wanadoo ADSL de 700 píxeles por 700 píxeles, como si fuera un anuncio publicitario de televisión.
Lo que más me enerva de estos casos, es que uno no puede hacer nada, sólo tiene que esperar a que el comando redirect entre en acción.
Muy mal. ¿No basta con cobrar el servicio que tienen que poner este tipo de cosas todavía?
Los frames no son más que una molestia para el desarrollo, no una comodidad, habiendo 150 artículos dedicados a hablar sobre las desventajas de los frames, todavía se siguen utilizando, ¿Qué anda mal?
Si lo que desean es ahorrarse la carga de un documento, utilizad includes de algún lenguaje de scripting como lo es PHP, ASP, JSP, o Python, da igual que lenguaje, pero es mejor que utilizar un Frame que trae cientos de problemas a tus clientes, para imprimir son un parto, para desarrollar también, que si tengo que controlar lo que pasa en un lugar, y en otro frame, que si utilizo Javascript para colorear algo, no basta de frames, son una pérdida de dinero terrible.
Si quieren ver el primer problema de un frame, entonces vayan a cualquier página de Correos de España, y pongan vista preliminar, ya se darán cuenta de lo que hablo.
Un detalle normal, como si estuviéramos hablando de contaminación global, son los formularios inaccesibles. En muchos sitios se hacen formularios inaccesibles, de tal forma y color que se tornan inservibles, hace falta un ratón e Internet Explorer 6 para que funcionen.
Además algo muy común es ver cosas como que un botón no es un botón de formulario, sino una imagen o una tabla de HTML que tiene celdas que a su vez contienen imágenes y un pequeño código Javascript que envía los datos de ese formulario.
Ahora yo me pregunto. ¿Por qué tanta complejidad? ¿Qué hace el HTML para que se lo deje de lado? ¿Es Javascript la mejor opción para hacer formulario? Pues la respuesta es no. Primero por que sin Javascript activado, éste no tiene validez ya, o sea, no existe “degradación", si fuera posible que sin Javascript el formulario es procesable, vaya y pase… pero como esto no es posible, entonces no deberían utilizar Javascript para los formularios.
Otro punto importante es la accesibilidad de los formularios, que carecen de etiquetas esenciales como
No solo visualmente tienen una repercusión grande, sino que accesiblemente seas ciego, sordo, mudo o una persona sana y vibrante es una ayuda indispensable.
Si se dirigen al 95% de los sitios mencionados aquí en este tutorial y revisan los formularios notarán que son prácticamente inusables, como el caso del buscador de la web de Correos de España, que sin Javascript no se puede buscar en el sitio, desepcionante.
Una de las cosas que podemos notar es que, la gran mayoria de los desarrolladores no sabe como aplicar las tipografías en la Web. El primer problema es encontrarse ejemplos como Administración.es, que utiliza tipografías demasiado pequeñas para un portal donde el espectro de gente debe ser más amplio, recuerda que en este tipo de sitios, el 99% de la gente no será de 20 años con una salud espléndida.
El segundo problema es mala utilización de medidas, por ejemplo podemos notar que en muchos casos, utilizan medidas en puntos (pt) para tipografías que se visualizan en pantallas, cuando los (pt) son ideales para sistemas de impresión.
También una de las malas prácticas es utilizar medidas en píxeles, lo cual elimina a Internet Explorer (sea 3, 4, 5, 5.5 o 6) de que pueda controlar el tamaño de las tipografías, esto se resume que si un usuario quiere ver las tipografías un nivel más del normal, no puede, no pasa nada, con otros navegadores la cosa es diferente, pero hey… el 95% de los damnificados utilizan Internet Explorer… ¿Qué putada no :)?
Mejor es utilizar medidas aptas para pantallas. Como por ejemplo em, porcentajes o tamaños predefinidos por el navegador (xsmall, small, médium, etc.)
La mejor es utilizar em, ya que tiene menos problemas que los porcentajes, y también tiene menos problemas que los tamaños predefinidos, por que cada navegador sigue un cauce distinto a la hora de controlar las tipografías.
Otra de las locuras es abusar de los archivos multimedia para representar datos en la Web, es casi insano tener 400 PDFs en un sitio Web, cuando esos archivos pueden estar hechos en HTML, el PDF no fue hecho para reemplazar al HTML, no se mezquinen con estas tecnologías.
Antes de presentar un PDF, asegurarse de que ese documento está hecho en HTML, si no tiene nada que ver con la información avisarle al usuario que se le va a servir un archivo PDF, utilizad íconos y enlaces de texto, y proporcionarle al usuario un medio para llegar a la instalación del Adobe Acrobat en caso de que el no posea el plug-in.
He visto cosas, en la Web de Correos de España por ejemplo, como utilizan muchos frames, algunos PDFs se cargan en los frames interiores, logrando así una compleja lectura, ya es una pesadilla que el PDF se cargue en la misma ventana.
Articulo original de: Minid.net
Usuarios que han visto este tema también han visto...
- Estudiar cómo posiciona la competencia.
- Cultura electronica
- Consejos para diseñar con Flash
- Cómo usar las fuentes en la Web
- Derechos de autor, Copyright y propiedad intelectual
- Versión imprimible de este documento
- Enviar por e-mail este documento
Información legal | Política de Privacidad | Contacte con nosotros
Otro proyecto de Factoría de Internet. Copyright© 2003-2008 Factoría de Internet S.L.. Todos los derechos reservados.