Graceful Degradation Spanish

 

Consejos Web de Dan:

Degradación Gradual

SUGERENCIA: No hay nada de malo en usar todos los accesorios más novedosos para permitir la compatibilidad con las elegantes características de los nuevos navegadores, pero hay que procurar hacerlo de una manera que les permita a los usuarios que no reconocen (o que desactivan intencionalmente) dichas características, acceder a tu contenido básico. Afortunadamente, esto es fácil de lograr en la Web, siempre que estés de acuerdo con la voluntad de los lenguajes y protocolos en lugar de combatirla.

La Degradación Gradual es un principio importante en el diseño web. Esto significa que cuando se implementan funciones diseñadas para aprovechar las mejores y más recientes características de los navegadores más actuales, hay que hacerlo de manera que los navegadores antiguos, además de aquéllos que permiten a los usuarios desactivar funciones particulares, puedan “retroceder” a un método que no impida el acceso al contenido básico del sitio, aunque quizás sin una apariencia tan elegante.

Casi todas las características nuevas que se añaden a la web han sido diseñadas de una manera que permitan la degradación gradual, comenzando con la incorporación de la etiqueta <IMG> para añadir gráficos a una web que previamente estaba construida en su totalidad por textos, que contiene un atributo ALT que permite ofrecer una alternativa de texto para los navegadores sin gráficos.

NOTA: Hubiera sido aún más refinado que la etiqueta IMG se hubiese definido como un elemento contenedor, con el contenido alternativo entre <IMG> y </IMG>. Esto habría permitido que el contenido alternativo se utilizase de forma automática en navegadores antiguos que no reconocen IMG, además de que permitiría que dicho contenido incluyera etiquetas de marcado, algo que no es posible en el atributo ALT. Pero a lo hecho, pecho.

Las construcciones más recientes como <APPLET> y <OBJECT> permiten ofrecer degradación gradual usando contenido alternativo entre las etiquetas de apertura y cierre del elemento. Todo lo que vaya entre <APPLET> y </APPLET> (aparte de los parámetros del applet en sí) será ignorado por un navegador compatible con Java, con Java habilitado, pero un navegador que no reconoce Java o en el que está desactivado, lo usará en lugar del applet. Esto permite que el desarrollador del sitio proporcione alternativas a imágenes estáticas, textos o vínculos para reemplazar la información presentada en forma de applet a los usuarios con compatibilidad.

He aquí un ejemplo de un applet codificado para una degradación gradual:

<APPLET CODE=”WaveEffect” align=center border=0 codebase=”http://www.example.net/applets/” width=200 height=200″>
<PARAM NAME=image VALUE=”enternow.gif”>
<PARAM NAME=HREF VALUE=”home.html”>
<A HREF=”home.html”><IMG SRC=”enternow.gif” width=200 height=200 alt=”Entra a mi sitio.”></A>
</APPLET>

Los usuarios con compatibilidad con Java observarán el resultado de un applet “WaveEffect”, que probablemente mostraría un gráfico con efectos de onda animados, y proporcionaría una manera de ingresar a la URL enlazada, indicada en el parámetro “HREF”. Pero los usuarios sin compatibilidad con Java no tendrían forma de observar eso, ni de entrar en el sitio si ésta fuese la única técnica de navegación, todo lo que podrían observar sería el contenido alternativo. Este contenido consiste en una etiqueta estática IMG normal que presenta el mismo gráfico pero sin animación, con hipervínculos a la página a la que el applet permite ingresar. Y para el caso de los navegadores de texto, el texto ALT con la imagen ofrece un nivel más de degradación gradual.

En algunos casos, cuando hay varias maneras distintas de ejecutar un mismo efecto, y el conjunto de navegadores compatibles con una u otra de ellas es ligeramente heterogéneo, la mayor compatibilidad se logra a través de varios niveles de construcciones anidadas que puedan degradarse gradualmente, como un APPLET dentro de un EMBED dentro de un OBJECT.

También existen algunas etiquetas especiales que permiten incluir contenido que sólo se utiliza cuando no están disponibles o se desactivan funciones específicas. Por ejemplo, los elementos NOSCRIPT se muestran sólo cuando no existe compatibilidad con JavaScript o éste está desactivado. Esto puede ser útil para proporcionar una alternativa de navegación en sitios donde los controles principales están implementados en JavaScript. Del mismo modo, los elementos NOEMBED sólo se utilizan cuando no existe compatibilidad con EMBED.

Para realizar esto correctamente sólo se requiere de un poco más de empeño, lo cual hace una gran diferencia en la accesibilidad, la flexibilidad y la indexabilidad en motores de búsqueda de tus páginas.

Degradación Gradual de Elementos Emergentes con JavaScript

Un efecto común usado en muchas páginas es un documento vinculado que aparece como una pequeña ventana emergente creada por JavaScript. Al usar este efecto, se debe ser lo más moderado posible, ya que puede llegar a ser molesto para muchos usuarios. Aunque hay ocasiones en las que es útil, como por ejemplo al mostrar materiales de referencia para ayudar a alguien a llenar un formulario web, sin tener que salir de la página del formulario (lo cual posiblemente imposibilitaría volver a él si expira en la caché del usuario, perdiendo así los datos que ya hayan sido introducidos).

A menudo, los desarrolladores hacen esto con javascript: URL. Esto deja mucho que desear en términos de degradación gradual, ya que los navegadores que no son compatibles con JavaScript no sabrán qué hacer con un enlace de dicha naturaleza, por lo tanto, o no harán nada o producirán un error. Además, javascript: URL realmente no está estandarizado; en lo personal, no conozco ninguna especificación formal para esta construcción, y a menudo contienen caracteres que está prohibido incluir (unescaped) en las URL, de acuerdo con las especificaciones (tales como espacios).

Afortunadamente, existe una mejor manera. En lugar de <A HREF=”javascript:YourPopupFunction(‘unarchivo.html’)”>, utiliza <A HREF=”somefile.html” onClick=”YourPopupFunction(‘unarchivo.html’); return false”> (suponiendo que ya has definido la función de JavaScript YourPopupFunction en algún lugar de tu documento). El atributo onClick contiene un código que se ejecuta (en los navegadores compatibles) al hacer clic en el enlace, y el término return false hace que el navegador se detenga tras hacer eso (en lugar de seguir el hipervínculo normal). Por lo tanto, tiene el mismo efecto que javascript: link (ten en cuenta que el código en onClick no inicia con “javascript:”, ya que no tiene la forma de una dirección URL). Pero en los navegadores que no son compatibles con JavaScript, onClick es ignorado y se abre el enlace normal. Así que todos los usuarios pueden ver el documento al que estás enlazando.

NOTA: Después de haber escrito lo anterior descubrí que algunos navegadores antiguos con las primeras implementaciones de JavaScript no muestran compatibilidad correcta con return false y terminan ejecutando tanto la ventana emergente como el enlace “directo”. Esto se puede evitar usando <A HREF=”unarchivo.html” target=”algunnombre” onClick=”newwin = window.open(”, ‘algunnombre’, ‘width=150,height=150,resizable=1’);”>, que abre una ventana vacía denominada “algunnombre” y permite destinarla al enlace normal. Los navegadores que no aceptan JavaScript simplemente abrirán una nueva ventana normal denominada “algunnombre”, o bien ignorarán el destino y abrirán la nueva página en la ventana original. Sin embargo, incluso más recientemente, me he dado cuenta que el navegador Mozilla, cuando se configura para ignorar los intentos de abrir nuevas ventanas, en este caso, abren la ventana emergente, pero después abren el destino del enlace en la ventana original, dejando la ventana emergente abierta inútilmente. Por lo tanto, considerándolo todo, el código de ejemplo anterior probablemente sea el mejor.

Estas técnicas también se pueden utilizar en otras instancias donde se desee que un enlace ejecute el código JavaScript, tal como un enlace simulando el botón “Atrás” del navegador con history.back(). Pero considera detenidamente si realmente es necesario usar esta función, ya que es probable que a los usuarios los confundan los enlaces que hacen cosas como retroceder en su historial en lugar de avanzar hacia otra página, como lo hacen normalmente los vínculos.

SUGERENCIA: Siempre usa un atributo HREF útil en tus enlaces, y no uno “ficticio”, incluso si el propósito principal del vínculo es activar un script.

No utilices nunca la lamentable y rampante técnica de hacer que los hipervínculos se dirijan al valor HREF “ficticio” de “#”; no estoy seguro de quién inventó esto, pero parece que se ha implementado así en algunas herramientas de creación que generan enlaces con un sofisticado uso de JavaScript, y a partir de ello se ha imitado en todo tipo de sitios, incluso algunos que están codificados manualmente. Es una mala idea —como lo demostré arriba, se debe hacer que el hipervínculo haga referencia a algo útil que funcione incluso cuando JavaScript esté deshabilitado— y, además, dado que “#” está indefinido como una referencia de URL, es interpretado por varias versiones de navegadores de manera inconsistente, y podría causar un salto a la parte superior o inferior de la página, o agregar una referencia de página extra e inútil al historial de la sesión del navegador. Al menos, si es necesario que uses un HREF ficticio así, asegúrate de terminar tu cadena de comandos JavaScript con “return false” para impedir que el navegador trate de seguir el enlace ficticio.

Degradación Gradual de los Rollovers en los Menús

Otro efecto popular es que el menú de navegación gráfica haga “efectos de rollover (imágenes de sustitución)” cuando el usuario mueve su puntero sobre los elementos del menú, efectos tales como “encender” o “apretar” el botón donde se sitúa el puntero, o mostrar más información sobre el elemento seleccionado para ayudar al usuario a decidir si desea abrir el vínculo.

Hay maneras “graduales” y “no graduales” de hacer esto. Las maneras “no graduales” pueden hacer que la navegación sea un fracaso completamente para los usuarios que no cuentan con compatibilidad, o que han desactivado Java, JavaScript o Shockwave (dependiendo de cómo se implemente el rollover). Por otro lado, una implementación “gradual” hace que el sitio sea totalmente navegable incluso en navegadores de “menor común denominador “, a la vez que agrega mejoras adicionales para quienes cuentan con compatibilidad.

Más abajo se muestra un ejemplo de un código para un efecto rollover de degradación gradual. Sin embargo, más que aprender un código específico, se requiere aprender el concepto general detrás de éste, además de otras técnicas de degradación gradual en el desarrollo web. Es decir: utilizar una estructura lógica y adecuada con construcciones HTML sencillas y ampliamente compatibles, y agregar “accesorios adicionales” como complementos opcionales que puedan ser ignorados por los navegadores no compatibles. La actitud contraria —el crear sitios inaccesibles— ocurre si se evita la etapa de crear una estructura “adecuada, lógica y simple” y se implementan los efectos deseados directamente en algún lenguaje avanzado (Java, Shockwave, etc.), terminando con un código que incluso ni siquiera contienen un enlace HTML “simple” que los navegadores puedan abrir sin ejecutar un “applet”, un “script” o un “plug-in”. Y si estos autores deciden posteriormente que necesitan volverse compatibles con navegadores “más simples”, terminan aglutinando un grotesco conjunto de vínculos “alternativos” en texto debajo de la “elegante” navegación, lo que no sería necesario si desde un principio diseñaran el sitio de una manera gradual.

Este es el código rollover “gradual” (nota: en este ejemplo, las versiones “normales” de los botones de navegación deben colocarse en item1_reg.gif, item2_reg.gif, mientras que las versiones “mouseover” son item1_over.gif, etc. Todas las imágenes se van a colocar en un subdirectorio llamado gfx/ debajo del directorio en el que se encuentra la página, y el tamaño de todas las imágenes es de 250 x 50 píxeles. Por supuesto, puedes modificar todo esto en función de las necesidades de tu sitio):


<html>
<head>
<title>Ejemplo de Página Rollover</title>
<script language=”JavaScript” type=”text/javascript”>
<!– hide this script from non-javascript-enabled browsers
if (document.images) {
item1_reg = new Image(250, 50); item1_reg.src = ‘gfx/item1_reg.gif’;
item1_over = new Image(250, 50); item1_over.src = ‘gfx/item1_over.gif’;
item2_reg = new Image(250, 50); item2_reg.src = ‘gfx/item2_reg.gif’;
item2_over = new Image(250, 50); item2_over.src = ‘gfx/item2_over.gif’;
item3_reg = new Image(250, 50); item3_reg.src = ‘gfx/item3_reg.gif’;
item3_over = new Image(250, 50); item3_over.src = ‘gfx/item3_over.gif’;
item4_reg = new Image(250, 50); item4_reg.src = ‘gfx/item4_reg.gif’;
item4_over = new Image(250, 50); item4_over.src = ‘gfx/item4_over.gif’;
}
function rollover(id,name){
if (document.images) {document.images[id].src=eval(name+”.src”); }
}
// stop hiding –>
</script>
<META http-equiv=”Content-Script-Type” content=”text/javascript”>
</head>

<body>

<P ALIGN=CENTER>
<a href=”item1/” onmouseout=”rollover(‘item1′,’item1_reg’);return false;” onmouseover=”rollover(‘item1′,’item1_over’);return false;”><img name=”item1″ src=”gfx/item1_reg.gif” width=”250″ height=”50″ border=”0″ alt=”[Item 1]”></a>
<a href=”item2/” onmouseout=”rollover(‘item2′,’item2_reg’);return false;” onmouseover=”rollover(‘item2′,’item2_over’);return false;”><img name=”item2″ src=”gfx/item2_reg.gif” width=”250″ height=”50″ border=”0″ alt=”[Item 2]”></a>
<a href=”item3/” onmouseout=”rollover(‘item3′,’item3_reg’);return false;” onmouseover=”rollover(‘item3′,’item3_over’);return false;”><img name=”item3″ src=”gfx/item3_reg.gif” width=”250″ height=”50″ border=”0″ alt=”[Item 3]”></a>
<a href=”item4/” onmouseout=”rollover(‘item4′,’item4_reg’);return false;” onmouseover=”rollover(‘item4′,’item4_over’);return false;”><img name=”item4″ src=”gfx/item4_reg.gif” width=”250″ height=”50″ border=”0″ alt=”[Item 4]”></a>
</P>

</body>
</html>

Observemos que el “if (document.images)” garantiza que sólo harán el intento los navegadores que usen versiones de JavaScript compatibles con imágenes (las primeras implementaciones posiblemente no), lo cual evitará errores. Y observa que las imágenes de navegación tienen atributos ALT que contienen el texto del elemento del menú (reemplaza “Item 1”, “Item 2”, etc., con nombres más útiles de acuerdo con las secciones de tu sitio), por lo que el usuario puede seguir navegando incluso en navegadores compatibles sólo con texto. Y sí, lo sé, puedes hacer efectos rollover aún más graduales usando hojas de estilo en cascada, pero esta es una página bastante antigua; y mientras no reescriba todo este sitio, contendrá algunos datos bastante anticuados.

Si estás dejando que un editor o programa utilitario genere los “efectos de rollover“, asegúrate de que use una técnica de degradación gradual como esta, y asegúrate de colocar los atributos ALT adecuados en las imágenes (a mano, de ser necesario, si el programa no ofrece una manera de hacerlo).

Formularios del lado del cliente y del servidor

Si tienes un formulario que realiza tareas útiles por medio de funciones JavaScript, también es posible permitir degradaciones graduales para los usuarios que no tienen JavaScript, si te aseguras de que envíe datos a un formulario del lado del servidor que realice las mismas funciones, aunque no tan eficientemente como lo podría hacer del lado del cliente. Por ejemplo, con JavaScript puede crearse una página web en que el usuario escriba su cantidad de ahorros por año y el interés esperado o el rendimiento de la tasa de dividendos, para saber cuánto ahorrará hasta su jubilación (realiza un cálculo rápido sin necesidad de enviar nada a un servidor, pero no funciona para usuarios que han desactivado JavaScript). Eso se puede remediar fácilmente haciendo que la acción del envío de datos (en ausencia de JavaScript) vaya a un script de servidor que realice los mismos cálculos. Para evitar que el script de servidor se active cuando no sea necesario, la función de JavaScript “onsubmit” debe terminar en “return false”.

Si tu formulario tiene el propósito de hacer envíos de datos a un servidor pero quisieras seguir usando las funciones de JavaScript, como para validar o corregir la información antes de enviarla, debes duplicar los mismos pasos de validación y corrección en el script de servidor para que no sean ignorados si JavaScript no está activado o disponible. De todos modos, esto es importante para propósitos de seguridad, ya que un hacker malintencionado podría crear una versión de tu formulario que salte la validación de JavaScript para intentar ingresar datos fraudulentos en tu programa, por lo que debes prepararlo para filtrar eventos así. Algunas personas en los grupos informativos hacen la pregunta equivocada: ¿Cómo obligo a mi formulario a no aparecer o no enviar información para los usuarios que tienen desactivado JavaScript, ya que la validación en JavaScript es esencial para su correcto funcionamiento? Intenta hacerlo modificando el botón Enviar, o todo el formulario, para que sean mostrados a través de JavaScript en lugar de HTML normal, de modo que no se muestren en absoluto sin scripts del lado del cliente. Los hackers malintencionados pueden frustrar fácilmente esto; podrían acceder a tu fuente y reconstruir un formulario con un botón de envío que no use JavaScript, aunque ello plantearía un problema de accesibilidad para los usuarios más comunes. Es mejor diseñar tus scripts de servidor para que funcionen correctamente con o sin la ayuda de JavaScript.

Conceptos Erróneos

Si participas en discusiones sobre HTML en grupos informativos, probablemente verás a alguien afirmar que la “degradación gradual” realmente significa hacer que los sitios sean modestos, aburridos y “del más bajo común denominador”. Esto se encuentra lejos de la verdad. Las personas que lo mencionan no comprenden realmente la degradación gradual, o simplemente están tratando de argumentar pobremente contra los llamados “puristas” en lugar de discutir de una manera racional la creación de páginas web. En realidad, la degradación gradual no exige renunciar a lo elegante o atractivo, o que tengas que realizar “desarrollos sólo para navegadores anticuados”. Simplemente requiere que entiendas la estructura de todos los elementos que usas y no pases por alto las funciones integradas que permiten la inserción de contenido alternativo, accesible para los usuarios que no quieren o no pueden usar tus características elegantes.

Degradación Gradual vs. Mejoramiento Progresivo

Últimamente ha surgido una discusión en los sitios de desarrollo web sobre la diferencia en los conceptos de “degradación gradual” y “mejoramiento progresivo”, que en realidad son conceptos bastante similares, pero observados desde diferentes perspectivas. Wikipedia tiene un artículo sobre mejoramiento progresivo y se han realizado ensayos sobre el tema. La diferencia básica es que en el “mejoramiento progresivo” se comienza con un conjunto simple, lógico y compatible de contenido marcado y después, encima, se colocan, en capas, las funciones mejoradas para los navegadores modernos, mientras que la “degradación gradual” comienza con un sitio avanzado, con todas sus características, lleno de accesorios, y uno se asegura de que también contenga contenido accesible si las características elegantes no funcionan para un usuario en particular. De acuerdo a esto, la actitud que yo promuevo encaja más en mejoramiento progresivo que en degradación gradual, aunque yo usé la terminología de degradación gradual porque el otro término no se había inventado en ese momento. En cualquier caso, si se practican eficaz, hábil y cuidadosamente, ambas técnicas deben dar lugar a sitios muy similares.

Salón de la Infamia

Haz que tu sitio sea mejor analizando otros sitios que muestren, digamos, ¡lo qué no se debe hacer!

NOTA: Que yo incluya un sitio en los enlaces de mi “Salón de la Infamia” no debe interpretarse como un tipo de ataque personal contra el creador del sitio, quien podría ser una muy buena persona, ni como un ataque contra el sitio web en cuestión en su conjunto, que bien podría ser una fuente de información o entretenimiento realmente sobresaliente. Más bien, simplemente sirve para destacar las características específicas (intencionales o accidentales) de los sitios en cuestión, que causan problemas que podrían haberse evitado con un mejor diseño. Si encuentras uno de tus sitios en estos vínculos, no te ofendas; ¡mejora tu sitio para que quite el enlace!

  • La Leicestershire & Rutland Chess Association desarrolló su sitio de manera que la página principal está sumergida más profundamente que el índice predeterminado, que redirige a la ubicación real de la página inicial. Solían hacer esto con un meta-redireccionamiento y un enlace HTML de repliegue simple, pero después de un rediseño (¿por qué los rediseños casi siempre degradan la accesibilidad en comparación con lo que estaba establecido?) están utilizando un índice predeterminado que consiste únicamente en un redireccionamiento JavaScript, de modo que los usuarios que no usan Javascript sólo observan una página en blanco.
  • Hira solía ofrecer una versión Flash y otra sin Flash en su página inicial, ¡pero la versión sin Flash aún contenía Flash! Se saltaba a una página “intro” adicional que contiene aún más Flash. Ya han eliminado esa idiotez, pero todavía tienen un intro con Flash, donde la opción para omitirlo está integrado en el propio Flash, lo que significa que los navegadores incompatibles con Flash sólo observarán una página vacía, sin ninguna forma de navegar por el sitio. El intro reproduce una fastidiosa melodía continuamente, sin ninguna manera de detenerla.

John Miller
Follow us

John Miller

John has worked in investment banking for 10 years and is the main author at 7 Binary Options. He holds a Master's degree in Economics.
John Miller
Follow us

Leave a Reply

Your email address will not be published. Required fields are marked *