¿La mejora progresiva es un problema actual?

Question

Hay un par de cosas que escucho en defensa de la mejora progresiva.

Javascript no está activado o no está disponible. De acuerdo con W3School's Javascript statistics, el 95% tenía Javascript activado en enero de 2008 (hace 2,5 años). La tendencia, basada en esas estadísticas, parece ser que los navegadores habilitados para Javascript están en aumento. La fuerte adopción de AJAX probablemente haya impulsado a los usuarios a habilitar aún más rápido. Soportar solo texto o accesibilidad no tiene mucho sentido desde el punto de vista comercial ya que probablemente representan menos del < 1% del tráfico.

Los navegadores móviles no funcionarán. De cualquier forma crearía una versión móvil del sitio debido al tamaño de pantalla limitado y una experiencia de navegación completamente diferente en los dispositivos móviles. Se podría argumentar que se usan CSS diferentes para lectores de pantalla/dispositivos móviles, pero no se podrá generar tanta información en un dispositivo móvil sin importar qué tan ordenado se vea.

La declaración original ni siquiera es cierto para los dispositivos móviles de nueva generación, como el Android y el iPhone, que tienen un total de> 200.000 tasa de activación diaria combinada. Además, la mayor parte de Javascript-eye-candy (como jQuery UI) no tiene mucho sentido porque la experiencia del sitio web en el dispositivo móvil es muy diferente (sin mouse hover, etc.). Considero que los dispositivos móviles son una plataforma propia que necesita una versión personalizada del sitio web. Otra tendencia ha sido crear una versión de "aplicación nativa" del sitio web/servicio.

Las arañas no podrán rastrear. Esto tampoco es cierto. Es posible usar el DOM como contenedor de datos para Javascript (rellenar etiquetas div/input con sus entidades). Además, Google ha hecho esfuerzos para hacer AJAX websites crawlable.

hilos similares:

• How important do you think Progressive Enhancement is?
• JavaScript Detection/Browser Statistics

Enlaces de Interés:

• Mobile compatibility tables
• Making AJAX Applications Crawlable

Answer 1

Javascript está apagado o no está disponible

y el uso de complementos tales como NoScript también va en aumento (sorprendente, ya que las vulnerabilidades JS han sido un vector de ataque popular, y que no necesita una vulnerabilidad para una bomba de alerta bucle() para estropear su tarde)

navegadores móviles no funcionarán.

y entonces tenemos navegadores como Opera Mini, que no maneja JS bien pero no maneja bien grandes diseños de pantalla.

arañas no serán capaces de rastrear

Así se puede evitar cierta dependencia de JS en algunos motores de búsqueda por el gasto de tiempo que proporciona instrucciones sobre cómo ejecutar el JS, y la construcción de ésta de una manera particular en primer lugar. Esto a menudo es un mantenimiento más alto que simplemente construir con una mejora progresiva.

Answer 2

¿Sigue IE6? Sí. Entonces todavía necesitas soluciones. Si PE es mejor que los otros se puede discutir.

En cuanto a JavaScript: El nuevo gran agujero de seguridad puede hacer creer a la opinión pública que "JS == Satanás", por lo que todos lo apagarán y lincharán a los que lo propongan.

Finalmente, cada pequeño problema con su sitio le costará clientes. entonces que debería ser? ¿Desea un sitio que sea fácil de crear (pero que rechace a la mayoría de las personas, especialmente aquellos con influencia) o un sitio que se esfuerza por brillar en cualquier navegador (y atraiga más visitas)?

Answer 3

• Google está intentando, pero bueno ¿es eso? ¿Afecta el rango del sitio? ¿Qué pasa con otros rastreadores?
• Los dispositivos móviles son importantes y van a ser aún más. Puede crear un sitio móvil independiente, pero ¿no sería más fácil crear un sitio en lugar de dos?
• Aunque solo sea un 5%, ¿puede permitirse perderlas?
• ¿Qué se requiere para admitir navegadores sin javascript? Simplemente haga un enlace de cada objeto interactivo y deje que el script lo maneje si puede. Puede que no sea perfecto, y no puedes hacer todo de esa manera, pero puede hacerse utilizable.

Answer 4

Con los atributos WAI-ARIA, puede crear aplicaciones Ajax que sean accesibles. Claro ... Todavía hay algunos problemas con arrastrar y soltar, etc., pero no usa estadísticas para demostrar que la accesibilidad no vale la pena.

Answer 5

Depende de lo que esté construyendo.

Para las aplicaciones web, PE a menudo no es ideal. El esfuerzo que implica PE para aplicaciones web sin comprometer la interfaz de usuario de cualquiera de las plataformas es tan grande que la creación de múltiples interfaces es, en la mayoría de los casos, más barata y más efectiva para los usuarios. Una IU móvil bien diseñada a menudo es funcionalmente diferente de su primo de escritorio por necesidad. Los motores de búsqueda generalmente no importan mucho para las aplicaciones web porque el contenido en sí no debe ser indexado. Como ejemplo, consulte gmail, que implementa varios front-ends diferentes, y simplemente redirecciona a los usuarios al apropiado.

Para los sitios web, las cosas son muy diferentes. El contenido es más estático y necesita ser indexado. En ese caso, PE es casi un hecho.

Por lo tanto, tendrá que ver sus proyectos específicos y evaluar los pros y los contras para cada uno individualmente.

Answer 6

Recientemente tuvimos un proyecto para crear widgets de interfaz de usuario accesibles. Exploramos la mejora progresiva y encontramos pocas razones para usarla (incluso después de leer el libro Filament). Usamos jQuery y WAI-ARIA. La mejora progresiva puede ser valiosa si su producto debe funcionar absolutamente en cualquier tipo de navegador. Sin embargo, la mayoría de las empresas no necesitan admitir esa amplia gama de dispositivos/navegadores.

La mejora progresiva esencialmente le hace más del doble de su esfuerzo porque debe crear el widget moderno que funciona con AJAX y un estilo sofisticado. También debe hacer una versión escueta que use publicaciones en formularios tradicionales. Si tiene un widget complejo que hace algo así como un asistente in-page o una edición de cuadrícula usando AJAX, debe desarrollar eso además de que debe hacer páginas separadas para cada paso para admitir navegadores sin capacidad AJAX. La sobrecarga se vuelve enorme.

Es una gran metodología para maximizar las capacidades, sin embargo, no es muy práctica en iniciativas a gran escala con limitaciones de tiempo y presupuesto. Esta fue la decisión que tomamos para nuestro proyecto. Sentimos que tomamos la decisión correcta.