Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.


En octubre del año pasado Mozilla anunció el Proyecto Quantum – nuestra iniciativa para crear un motor de navegación web de nueva generación. Ya estamos en marcha con el proyecto. De hecho liberamos nuestra primera pieza significativa de Quantum con Firefox 53.

Pero sabemos que para personas que no construyen navegadores web (¡y eso es la mayoría de la gente!), puede ser difícil ver por qué algunos de los cambios que estamos realizando en Firefox son tan importantes. Después de todo, muchos de los cambios que estamos haciendo serán invisibles para los usuarios.

Con esto en mente, estamos lanzando una serie de publicaciones para proporcionar una visión más profunda de lo que estamos haciendo con el proyecto Quantum. Esperamos que esta serie de publicaciones te brinde una mejor comprensión de cómo funciona Firefox y las formas en que Firefox está construyendo un motor de navegación web de nueva generación para mejor aprovechar el hardware de los ordenadores modernos.

Para comenzar esta serie de publicaciones, creemos que es mejor comenzar por explicar el aspecto fundamental que Quantum está cambiando.

¿Qué es un motor de navegación web y cómo funciona?

Si vamos a empezar por algún lado, debemos empezar desde el principio.

Un navegador web es una pieza de software que carga archivos (normalmente de un servidor remoto) y los muestra localmente, permitiendo la interacción del usuario.

Quantum es el nombre clave para un proyecto que hemos emprendido en Mozilla para actualizar masivamente la parte de Firefox que calcula qué mostrar a los usuarios basándose en esos archivos remotos. El término que utiliza la industria para esta parte es “motor web”, y sin uno, estarías leyendo código fuente en lugar de ver realmente un sitio web. El motor web de Firefox se llama Gecko.

Es bastante fácil ver al motor web como una caja negra, algo así como una TV: los datos entran, y la caja negra calcula qué mostrar en la pantalla para representar esos datos. La pregunta de hoy es: ¿cómo? ¿Cuáles son los pasos que convierten los datos en las páginas web que vemos?

Los datos que componen una página web son muchas cosas, pero se desglosan principalmente en 3 partes:

  • código que representa la estructura de una página web
  • código que proporciona estilo: el aspecto visual de la estructura
  • código que actúa como un script de acciones que el navegador puede tomar: computación, reaccionar a las acciones del usuario, y modificar la estructura y el estilo más allá de lo que se cargó inicialmente.

El motor del navegador web combina la estructura y el estilo para dibujar la página web en tu pantalla y averiguar qué partes son interactivas.

Todo comienza con la estructura. Cuando se le pide a un navegador web que cargue un sitio web, se le da una dirección. En esta dirección se encuentra otra computadora que, cuando es contactada, enviará los datos de vuelta al navegador web. Los detalles de cómo esto ocurre es un artículo completo en sí mismo, pero al final el navegador tiene los datos. Estos datos son enviados en un formato denominado HTML, y este describe la estructura de la página web. ¿Cómo entiende un navegador web HTML?

El motor del navegador web contiene fragmentos especiales de código llamados parsers que convierten los datos de un formato en otro que el navegador web mantiene en su memoria. El parser de HTML toma el HTML, algo así como:

<section>
 <h1 class="main-title">Hello!</h1>
 <img src="http://example.com/image.png">
</section>

Y lo analiza, entendiendo:

Bien, hay una sección. Dentro de la sección se encuentra un título de nivel 1, que contiene el texto: “Hello!”. También hay una imagen dentro de la sección. Puedo encontrar los datos de la imagen en la ubicación: http://example.com/image.png

La estructura almacenada en memoria de la página web se denomina Modelo de Objeto de Documento o DOM (Document Object Model). A diferencia de un texto largo, el DOM representa un árbol de elementos de la página web final: las propiedades de los elementos individuales y qué elementos están dentro de otros elementos.

Además de describir la estructura de la página, el HTML también incluye direcciones donde se pueden encontrar estilos y scripts. Cuando el navegador los encuentra, se pone en contacto con esas direcciones y carga sus datos. Esos datos alimentan a otros parsers que están especializados en esos tipos de datos. Si se encuentran scripts, pueden modificar la estructura y el estilo de la página antes de que haya finalizado el parseo del archivo. El formato de estilo, CSS, juega el siguiente papel en nuestro motor del navegador web.

Con estilo

CSS es un lenguaje de programación que permite a los desarrolladores describir la apariencia de elementos particulares en una página. CSS significa “hojas de estilo en cascada”, denominado así porque permite múltiples conjuntos de instrucciones de estilo, donde las instrucciones pueden sobreescribir las instrucciones anteriores o más generales (llamado cascada). Un poco de CSS podría tener el siguiente aspecto:

section {
  font-size: 15px;
  color: #333;
  border: 1px solid blue;
}
h1 {
  font-size: 2em;
}
.main-title {
  font-size: 3em; 
}
img {
  width: 100%;
}

CSS se divide en gran parte en agrupaciones llamadas reglas, que constan de dos partes. La primera parte son los selectores. Los selectores describen los elementos del DOM (¿recuerdas los de arriba?) a los que se les está aplicando los estilos y una lista de declaraciones que especifican los estilos que se aplicarán a los elementos que coincidan con el selector. El motor del navegador web contiene un subsistema llamado motor de estilos cuyo trabajo es tomar el código CSS y aplicarlo al DOM que fue creado por el parser HTML.

Por ejemplo, en el CSS anterior, tenemos una regla que hace referencia al selector “section”, que coincidirá con cualquier elemento en el DOM con ese nombre. Entonces se hacen anotaciones de estilo para cada elemento en el DOM. Eventualmente, cada elemento en el DOM termina teniendo un estilo y llamamos a este estado el estilo computado para ese elemento. Cuando se aplican múltiples estilos que compiten sobre el mismo elemento, los que vienen después o son más específicos ganan. Piensa en las hojas de estilo como en el papel de trazado fino; cada capa puede cubrir las capas anteriores, pero también permite que se muestren las capas inferiores.

Una vez el motor del navegador web ha computado los estilos, ¡es hora de ponerlo en uso! El DOM y los estilos computados son introducidos en un motor de diseño que tiene en cuenta el tamaño de la ventana que se est´ dibujando. El motor de diseño utiliza varios algoritmos para tomar cada elemento y dibujar una caja que incluya su contenido y tenga en cuenta todos los estilos que se le aplican.

Cuando el diseño esta completo, es el momento de convertir el esquema de la página en la parte que tú ves. Este proceso se conoce como dibujado, y es la combinación final de todos los pasos previos. Cada caja definida se dibuja, llena del contenido del DOM y con los estilos del CSS. Ahora el usuario ve la página, reconstruida a partir del código que la define.

¡Esto solía ser todo lo que sucedía!

Cuando el usuario desplaza la página, volveremos a dibujar, para mostrar las partes nuevas de la página que estaban anteriormente fuera de la ventana. ¡Resulta, sin embargo, que a los usuarios les encanta desplazar la página! El motor del navegador web sabe con bastante seguridad que se le pedirá que muestre contenido fuera de la ventana inicial que ha dibujado (llamada ventana de visualización o viewport). Los navegadores más modernos aprovechan este hecho y dibujan más página de la que está visible inicialmente. Cuando el usuario se desplaza, las partes de la página que quiere ver ya están dibujadas y listas. Como resultado, el desplazamiento es más rápido y fluido. Esta técnica es la base de la composición, que es un término para las técnicas que reducen la cantidad de pintados requeridos.

Además, algunas veces necesitamos volver a dibujar partes de la pantalla. Tal vez el usuario esté viendo un vídeo que se reproduce a 60 cuadros por segundo. O tal vez hay una presentación de diapositivas o una lista animada en la página. Los navegadores pueden detectar qué partes de la página se moverán o actualizarán, y en lugar de pintar toda la página, crean una capa para contenerlo. Una página puede estar formada por muchas capas que se superponen entre sí. Una capa puede cambiar de posición, desplazamiento, transparencia o moverse detrás o delante de otras capas, ¡sin tener que volver a pintar nada! Bastante conveniente.

A veces, un script o una animación cambia el estilo de un elemento. Cuando esto ocurre, el motor de estilo necesita volver a calcular el estilo del elemento (y potencialmente el estilo de muchos más elementos de la página), recalcular el diseño y volver a dibujar la página. Esto lleva mucho tiempo en términos de velocidad de computadora, pero siempre que ocurra de manera ocasional, el proceso no afectará negativamente la experiencia del usuario.

En las aplicaciones web modernas, la estructura del documento en sí misma es modificada frecuentemente por los scripts. Esto podría requerir que todo el proceso de diseño comience más o menos desde cero, con el HTML siendo analizado en el DOM, computar el estilo, reflujo y dibujado.

Estándares

No todos los navegadores web interpretan HTML, CSS y JavaScript de la misma forma. El efecto puede variar: desde pequeñas diferencias visuales hasta el sitio web ocasional que funciona en una navegador y en no en otro. Actualmente, en la Web moderna, la mayoría de los sitios web parecen funcionar independientemente del navegador que elija. ¿Cómo logran los navegadores este nivel de consistencia?

Los formatos del código de sitios web, así como las reglas que rigen la forma en que el código se interpreta y se convierte en una página visual interactiva, se definen mediante documentos mutuamente acordados denominados estándares. Estos documentos son desarrollados por comités que constan de representantes de los fabricantes de los navegadores web, desarrolladores web, diseñadores y otros miembros de la industria. Juntos determinan el comportamiento preciso que el motor del navegador web debería exhibir dada una pieza especifica de código. Existen estándares para HTML, CSS y JavaScript, así como los formatos de datos de imágenes, vídeo, audio y más.

¿Por qué es esto importante? Es posible crear un motor para el navegador web completamente nuevo, y siempre que se asegure de que el motor cumpla los estándares, dibujará las páginas web de una manera que coincida con el resto de navegadores web, para las miles de millones de páginas web. Esto significa que la “salsa secreta” para hacer que los sitios web funcionen no es un secreto perteneciente a un navegador. Los estándares permiten a los usuarios elegir el navegador web que satisfaga sus necesidades.

No más ley de Moore

Cuando los dinosaurios vagaban por la tierra y las personas solo tenían ordenadores de escritorio, era una suposición relativamente segura de que las computadoras se volverían más rápidas y potentes. Esta idea se baso en la Ley de Moore, una observación en la cual la cantidad de componentes (y por lo tanto la miniaturización / eficiencia de los chips de silicio) se duplicaría aproximadamente cada dos años. Increíblemente, esta observación fue válida hasta bien entrado el siglo XXI, y algunos argumentarán que sigue siendo válida en la vanguardia de la investigación actual. Entonces, ¿por qué la velocidad de un ordenador medio parece haberse estabilizado en los últimos 10 años?

La velocidad no es la única característica que los clientes buscan cuando compran un ordenador. Los ordenadores rápidos suelen consumir mucha energía, calentarse mucho y ser muy costosos. A veces, la gente quiere un ordenador portátil que tenga una buena duración de la batería. A veces, quieren un pequeño ordenador con pantalla táctil, con una cámara que quepa en el bolsillo y ¡que dure todo el día sin cargar! Los avances en informática lo han hecho posible (¡lo cual es increíble!), pero a costa de la velocidad bruta. Del mismo modo que no es eficiente (ni seguro) conducir tu coche lo más rápido posible, no es eficiente conducir tu ordenador lo más rápido posible. La solución ha sido tener múltiples “ordenadores” (núcleos) en un chip de CPU. No es raro ver teléfonos inteligentes con 4 núcleos más pequeños y menos potentes.

Lamentablemente, el diseño histórico del navegador web asumió esta trayectoria ascendente de velocidad. Además, escribir código que sea bueno usando múltiples núcleos de la CPU al mismo tiempo puede ser extremadamente complicado. Entonces, ¿cómo hacemos un navegador rápido y eficiente en la era de muchos ordenadores pequeños?

¡Tenemos algunas ideas!

En los próximos meses, analizaremos más detenidamente algunos de los cambios que llegarán a Firefox y cómo aprovecharán mejor el hardware moderno para ofrecer un navegador más rápido y estable que haga brillar los sitios web.

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Uriel Jurado.

Agilizar nuestro proceso de entrega y llevar rápidamente nuevas características a la versión estable para usuarios y desarrolladores es una prioridad para Firefox.  Mirando de cerca y de forma crítica nuestros canales de entrega, quedó en claro que Aurora no reunía nuestras expectativas como primer canal de estabilización.

El 18 de Abril (del 2017), el canal Aurora de Firefox dejó de actualizarse, y durante los siguientes meses, Aurora fue removido del ciclo de entrega. La edición para desarrolladores ahora está basada en la versión Beta. Los usuarios de la edición para desarrolladores mantienen sus temas, herramientas y preferencias. Siguen manejando su perfil actual y no tendrían que experimentar ningún inconveniente.

Este cambio beneficia a los desarrolladores de muchas formas:

  • Elecciones más simples sobre los canales de pre-lanzamiento: Nightly para características experimentales y la versión para desarrolladores/beta para estabilidad.
  • Mayor calidad y un entorno más estable para los usuarios de la versión para desarrolladores.
  • Un ciclo de entrega más rápido de nuevas características. (¡Beneficiándonos a todos!)

Aquí está la línea del tiempo: el 18 de abril, el código de Firefox 54 se cambió de Aurora a Beta como siempre, mientras Firefox 55 se mantuvo en Nightly para un segundo ciclo seguido (un total de 14 semanas). En el siguiente día de actualización, junio 12, Firefox 55 se movió directamente desde Nightly a Beta. Entre abril y junio, Firefox Aurora para escritorio (54) siguió recibiendo actualizaciones críticas de seguridad, y los usuarios de Aurora y de la versión para Desarrolladores fueron migrados al canal Beta. En Android, los usuarios de Aurora fueron migrados a Nightly.

Aurora fue originalmente creado en 2011 para brindar una mayor retroalimentación por parte de los usuarios después de que Firefox se actualizara de la versión 5 a un ciclo de entregas de alta velocidad. Hoy, en 2017, tenemos procesos más modernos sosteniendo nuestro modelo de trenes, y creemos que podemos entregar productos estables y ricos en características sin la fase adicional de 6-8 semanas de Aurora.

Un proceso de despliegue escalonado, similar a lo que hacemos actualmente con la versión estable, será utilizado para las primeras semanas de Beta. Nuestro flujo de trabajo de entrega e ingeniería continuará teniendo revisiones adicionales y ajustes para asegurarnos que entregamos una versión de alta calidad. Una nueva característica se añadirá de Nightly a Beta solo cuando sea considerada lista, basados en criterios preestablecidos determinados por nuestros equipo de ingeniería, producto y de integridad de producto. Si las nuevas características no están listas, no serán migradas de Nightly a Beta.

Las nuevas herramientas y procesos incluyen:

  • La integración de analizadores fijos como parte del flujo de trabajo, para detectar fallas durante la fase de revisión. Estos serán capaces de identificar defectos potenciales, minimizando la deuda técnica.
  • Los resultados de la cobertura de código serán usados para analizar la calidad de la plataforma de pruebas y el riesgo de realizar el cambio.
  • La habilidad de identificar riesgos potenciales producidos por cambios incluso antes de ser realizados, relacionando datos de varias fuentes (VCS, Bugzilla, etc.) Esto para identificar funciones en donde una modificación seguramente conllevaría a una regresión.
  • Monitoreando la cantidad de fallas, control de calidad, datos de telemetría y nuevas regresiones, para determinar la calidad en general de Nightly y la preparación de características para ser agregadas a Beta.

Para saber un poco más respecto a los detalles de esta transición, por favor visita el blog de Administración de Versiones de Mozilla, donde encontrarás respuestas más profundas respecto a las preguntas más frecuentes relacionadas a este cambio.

Visto en: Mozilla-hispano

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Con el lanzamiento de Firefox 49 se incluyo Control de cache: características inmutables que permite a las páginas web adivinar los recursos HTTP que nunca van a cambiar. Casi al mismo tiempo, Facebook empezó a implementar ampliamente esta tecnología desde el lado del servidor. Utilizan un modelo de desarrollo de versionamiento de la URI  que funciona muy bien con inmutables. Esto ha tenido gran impacto en el rendimiento de las recargas de Facebook con Firefox. Ademas parece que otros sitios lo implementarán también.

Los beneficios de los inmutables permiten que cuando una página sea refrescada, lo cual es una tarea muy común en el escenario de los medios sociales, los elementos que fueron marcados como inmutables en la cabecera de una respuesta HTTP, no tienen que ser revalidados con el servidor. Si no se hace esto, el navegador necesita saber cuales objectos han cambiados o no en la recarga, gastando tiempo por un lado o arriesgando incompatibilidad por el otro lado.

Para objetos pequeños, el trabajo de esta revalidación a través del código de respuesta HTTP 304 puede llevar tanto trabajo como transferir la totalidad de la respuesta.

Resulta que esto puede ahorrar mucho trabajo. Los recursos de la página tales como los archivos de javascript, tipografías, y hojas de estilo; no cambian entre recargas. Mas importante aún son las docenas de imágenes que no cambian – distintas imágenes pueden ser incluidas en el HTML, pero el contenido de cada una de ellas no cambia. De hecho, la única cosa que puede cambiar el la estructura del HTML.

Para los usuarios de Firefox recargar el contenido de Facebook ha sido un gran cambio – la petición mas rápida es aquella que nunca se hace, y es exactamente lo que está pasando todo el tiempo que se recarga una página de Facebook. En pruebas, la página principal típica puede estar inicialmente compuesta de 150 recursos. Al presionar refrescar en Firefox 49 se generan solo 25 peticiones.

Como puedes imaginarte, las cosas son rápidas. En pruebas, se puede reducir el tiempo de carga de una página a la mitad. Facebook también ha sido uno de los primeros en adoptar la compresión de codificación brotli. Lo usan para reducir el ancho de banda de la estructura HTML dinámica, la cual no puede ser almacenada en cache, permitiendo ahorrar 20% de los bytes transferidos cuando se compara con el antiguo estándar gzip. Brotli está disponible en Firefox desde Firefox 44.

Los servidores de Facebook también son beneficiados – una petición que nunca se hace permite ahorrar ancho de banda y uso de CPU, lo cual se puede usar para hacer el sitio mas rápido para otras peticiones.

“Este cambio cambia efectivamente la eliminación de peticiones de  revalidación de nosotros para las versiones actualizadas de Firefox las cuales, en muchos casos, pueden mejorar los tiempos de carga en segundos.” – Nathan Schloss, Ingeniero de Software, Facebook

Estamos creciendo

Facebook ha sido un gran socio en este esfuerzo. Últimamente ha estado promoviendo los inmutable y otros desarrolladores también lo están adoptando.

La BBC lo ha utilizado para pruebas:

Como anécdota, la BBC observa mejoras en los tiempos de respuestas de cargas hasta un 50%, y expresa que un 90% de las peticiones están optimizadas para ser inmutables.

Implementaciones futuristas como el  as sistema de archivos InterPlanetary también son interesantes:

También se benefician productos como el venerable proxy Squid:

Esta tecnología ha tenido suficientes pruebas en producción y realmente recomendamos su uso. Para asegurar la documentación adecuada, también se han adaptados a los estándares de la IETF. Solo necesitas es tener una cabecera de cache para empezar con tu desarrollo.

Hace pocas horas Mozilla ha liberado una nueva versión de Firefox en la que destacan la integración con GTK3 en Linux, mejoras en las seguridad del compilador JS en tiempo real, cambios en WebRTC y nuevas funcionalidades para Android e iOS.

Después de varios meses de pruebas y desarrollo, finalmente GTK3 ha sido incluido para la versión en Linux. Esto permitirá reducir la dependencia de las versiones antiguas del servidor X11, compatibilidad mejorada con HiDPI y sobre todo una mejor integración con los temas.

 El nuevo navegador también mejora la seguridad del compilador de JavaScript Just in Time (JIT) de SpiderMonkey. La idea es influir en el código RWX (lectura – escritura – ejecución), que a veces provoca un riesgo. Inicialmente representa una excepción a las reglas del sistema operativo, especialmente el almacenamiento de datos en un área de memoria donde pueden ser ejecutados (leer), pero no escribirse.

Para remediar este problema, Mozilla he empleado un mecanismo denominado W^X. Su función es la de prohibir la escritura de JavaScript en áreas de memoria que contienen el código JIT. Este cambio será a expensas de un ligero descenso en el rendimiento, que se calcula de acuerdo con el editor en un rango de 1% a 4%. Por otra parte, se invita a los creadores de algunas extensiones para probar la compatibilidad de su código de tratar con este mecanismo.

También se ha mejorado el rendimiento y la fiabilidad de las conexiones de WebRTC, y permite el uso del módulo de descifrado de contenido para el contenido H.264 y AAC cuando sea posible. Mientras tanto, para los desarrolladores contamos con nuevas herramientas que ahora pueden emplear en sus trabajos, en este artículo publicado en el blog de Labs podrás conocer más al respecto.

Novedades en Android

  • El Historial y los Marcadores se han añadido al menú.
  • La instalación de complementos no verificados será cancelada.
  • Las página almacenadas en la caché ahora son mostradas cuando estamos sin conexión.
  • Las notificaciones sobre las pestañas abiertas en segundo plano ahora muestran la URL.
  • Firefox pedirá permisos para acceder a ciertos permisos en tiempo de ejecución y no al instalar la aplicación (Android 6.0 o superiores).
  • Durante el autocompletamiento mientras escribes una dirección ahora se incluye el dominio para hacer más fácil tu navegación.

Firefox para iOS

  • Añadida la localización en danés [da].
  • Los sitios sugeridos por defecto ahora pueden ser eliminados.
  • Los 5 primeros sitios del ranking de Alexa son mostrados a los nuevos usuarios.
  • Mejorado el manejo por parte del navegador de vínculos a Apple Maps y otras aplicaciones de terceros como Twitter.

Si prefieres ver la lista completa de novedades, puedes llegarte hasta las notas de lanzamiento (en inglés).

En estos momentos ya debes haber recibido esta actualización, pero si todavía no te ha aparecido la advertencia, puedes ir al menú “Acerca de” y hacer clic en el botón “Buscar actualizaciones”. Mientras que Firefox para Android puedes instalarlo desde Google Play.

Visto en Mozilla hispano.

Hoy en día el cuello de botella a nivel de comunicación son los discos duros. con largos tiempos de búsqueda, escritura y lectura son excesivamente lentos si lo comparamos con las velocidades de RAM. Hace unos años era un lujo montar discos virtuales en RAM y se usaban temporalmente y para cosas puntuales como cuando en gentoo se hacia un emerge -e world y montaba /var/tmp/portage en RAM.

Para usuarios que el principal uso de su computadora es navegar en Internet bien sea por trabajo (nagios por ejemplo), escribir artículos o simplemente trolear este tip les puede ser útil si poseen suficiente RAM.

En Fedora podemos mover el cache de Google Chrome y de Firefox a RAM creando un ramdisk y montándolo, luego configuramos los exploradores para que usen estos directorios. Lo primero es editar el archivo /boot/grub/grub.conf y agrega ramdisk_size=512000 justo antes de quiet splash en la linea de kernel que este usando.

 title Fedora ramdisk (2.6.37.i686)
 root (hd1,0)
 kernel /boot/vmlinuz-2.6.37.i686 ro root=UUID=f91d2720-7838-43d3-a3a4-5c993533d0 rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us rhgb ramdisk_size=512000 quiet
initrd /boot/initramfs-2.6.37.img``

Luego edita tu /etc/rc.local y agrega estas lineas para formatear el ramdisk, montarlo, crear los directorios necesarios para FireFox y Chrome y darle la permisologia necesaria.

# RAM disck para cache de browsers
mke2fs -m 0 /dev/ram0
mount /dev/ram0 /tmp/ram/
mkdir -p /tmp/ram/firefox
mkdir -p /tmp/ram/chrome
chmod 777 /tmp/ram/ -R

Estos comandos me funcionan con Fedora (estoy seguro que en cualquier otra distro funcionaria). Para hacer que FireFox guarde su cache allí debes agregar o modificar su conflagración específicamente la llave browser.cache.disk.parent_directory con el valor /tmp/ram/firefox, Para Google Chrome es un poco mas fácil, simplemente pasale el parámetro –disk-cache-dir=”/tmp/ram/” al arranque.

[gallery link="file"]

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } Antes que nada, para quienes no sepan que es Elluminate:

¿Que es Elluminate Live!?

Elluminate Live™ es la solución ideal desarrollado en Java para aprendizajes, capacitaciones, adiestramientos, tutorías y reuniones. Elluminate Live™ ahorra tiempo y dinero al suprimir viajes innecesarios, sin dejar de mantener la eficacia de una reunión cara a cara. Elluminate Live™ permite impartir enseñanza en línea, capacitación, adiestramiento, tutoría y reuniones en vivo – ¡en equipos Mac o PC! El proceso de aprendizaje se acelera a medida que los participantes se interconectan a través de la mejor tecnología de Voz sobre IP que hay en el mercado (comunicación completa en audio en 2 direcciones, ¡con ancho de banda a baja velocidad!), charlas, pizarra virtual interactiva, y video. Puede incluso compartir aplicaciones en una sola interfaz gráfica. Bien sea que el aula virtual se encuentre alojada por Elluminate, los fabricantes del software, o instalada en su servidor, es fácil de instalar, fácil de usar y personalizada de manera que usted puede incorporar su propio software didáctico.

Cabe destacar que hay un modulo para incorporar Elluminate Live en Moodle.

Caracteristicas

  • Voz sobre IP de calidad superior – ¡puede servir con un módem de 28.8 Kbps de velocidad.

  • Pizarra virtual interactiva compartida – ¡importa o crea presentaciones!

  • Aplicaciones compartidas – ¡control remoto de la computadora de escritorio!

  • Direct Messaging™ – ¡mensajes privados o públicos!

  • AppSnap™ – ¡capta imágenes o instantáneas de pantallas!

  • Web Tour – ¡recorre sitios Web con los participantes!

  • Cámara Web y de video – ¡cámara Web y de video a baja velocidad!

  • Grabación y reproducción – ¡guarda sesiones como objetos de aprendizaje!

  • Control completo por parte del instructor – gestión y sondeo de avance.

  • Compatible con el sistema operativo Mac – ¡acceso sin problemas para

    todos los usuarios!

Para poder iniciarlo, solo debemos instalar el paquete sun-java6-plugin y todas sus dependencias. En el caso de Debian o Ubuntu seria con el comando:

#aptitude install sun-java6-plugin



Interfaz de Elluminate Live!




Luego de instalado el plugin java, la forma de iniciarlo desde el navegador es como se presenta en el video: