Tripix.net

De todos muchos es sabido que uno de los grandes problemas que supone el desarrollo de sitios web en Flash es la imposibilidad dificultad de implementar el sistema de estadísticas web de Google (Analytics).

Hasta ahora, lo que se podía hacer era ir haciendo llamadas a funciones Javascript de la librería de Google Analytics desde el propio Flash tal y como se describía en este único documento oficial de ayuda.

Sin embargo, en el blog oficial de Google Analytics anuncian la publicación de Google Analytics Tracking For Adobe Flash, una librería realizada en ActionScript 3 que facilitará la integración de este sistema de estadísticas en nuestras aplicaciones Flash y Flex.

La creatividad de los buenos programadores flash es sobradamente conocida y personalmente he visto implementaciones de Google Analytics en Flash que funcionan perfectamente, pero esta librería seguro que ayudará a miles de desarrolladores flash con menos experiencia y facilitará la vida a los experimentados.

Aunque de lo que estoy seguro es de que la gran mayoría de sitios flash, es decir, mini sites, macro sites, pseudo sites y demás realizados por agencias desde una interpretación de la web como médio para colocar anuncios de escasa calidad, seguirán sin implementar este tipo de cosas principalmente, por que no dan la suficiente importancia a este tipo de datos ni se preocupan demasiado por ellos.

Por último, personalmente sigo echando de menos una explicación más detallada y clara de si se puede implementar, y en ese caso, cual es el método ideal, el seguimiento de comercio electrónico desde Flash.

la W3C aloja dos nuevos documentos sobre HTML5 que destacan, al contrario de lo que suele ser habitual, por su claridad y por estar orientados a que los desarrolladores entendamos la especificación y aprendamos a usarla.

El primero de ellos, HTML: The Markup Language, extrae y se centra en los aspectos de marcado y modelo de contenidos del HTML5 y se convierte en la referencia a la hora de conocer cada una de las etiquetas y atributos de este lenguaje de marcado.

El segundo, The Web Developer’s Guide to HTML 5 (Guía de HTML5 para desarrolladores web), es un trabajo muy didáctico cuyo objetivo es enseñarnos a escribir HTML5 de una forma simple y con aplicaciones prácticas.

Una respuesta rápida: es genial. Acelera el desarrollo, pueden usarlos desarrolladores no expertos en programación, aseguramos la interoperabilidad entre navegadores.

Pero en el taller de Peter-Paul Koch en Fundamentos Web salió el tema y de hecho yo le pregunté sobre ello. Su reflexión creo que es muy lógica y que no debe dejar de tenerse en cuenta.

Cito libremente (no recuerdo sus palabras exactas)

Usa los frameworks, tienen muchas ventajas, pero ojo, si quieres tener buenos programadores javascript éstos deben hacer al menos un projecto importante sin usar ningún framework. A pelo.

Estoy totalmente de acuerdo con él. Los frameworks de javascript son maravillosos pero pueden estar creando una generación de programadores JavaSript que no saben JavaScript.

¿Qué opináis?

[Vía Ajaxian]

Jops… Anieto lo ha publicado hace poco y yo convencido de que había hablado de esto hace tiempo. Si, lo había hecho, pero se me quedó como Draf! lo publico ahora.

En ocasiones incluímos en nuestras web algún framework Javascript solamente para poder usar los selectores DOM de elementos CSS3 que éstos nos ofrecen para trabajar con ese lenguaje. Cuando hago eso siempre pienso que estoy matando moscas a cañonazos.

Para arreglar esto James Donaghue ha publicado, en versión Beta, un motor para hacer estas selecciones que se caracteríza por dedicarse solamente a eso y hacerlo muy rápidamente y a través de un JS con 10kb:

Para demostrarlo nos ofrece este test, aunque ciertamente en su propio test Sizzle, un sistema similar diseñado por John Resig, parece que va a la par o más rápido… y encima en solo 4Kb.

La especificación WCAG 2 pasa también al estado de “propuesta de recomendación”. Esta especificación es realmente imporante ya que es la que se encarga de establecer las pautas y líneas guía para hacer el contenido web accesible.

The Web Content Accessibility Guidelines (WCAG) documents explain how to make Web content accessible to people with disabilities. Web “content” generally refers to the information in a Web page or Web application, including text, images, forms, sounds, and such. (More specific definitions are available in the WCAG documents.)

La versión anterior de este estándar (versión 1) es del año 1999 y parece que esta nueva edición estará terminada en breve (término que para la W3C puede ser desde unos meses a 15 años).

Estoy seguro de que mucho de los que leeis este blog tenéis claro de que va el tema, pero a los que no lo tengáis os recomiendo, insisto y vuelvo a insistir en que conozcáis esas pautas y las apliquéis en lo posible (no siempre lo es)… no nos limitemos a poner el sellito de marras por favor.

Aprovecho para comentar también las otras especificaciones que la W3C edita en torno a la accesibilidad:

1. WAI-ARIA (Rich Applications): pautas para implementar accesibilidad en las RIAs.: en la pasada edición de Fundamentos Web tuve el placer de asistir a la presentación de este estándar por su responsable y todos quedamos gratamente impresionados por lo bien pensada que está la especificación.
2. Authoring Tool (ATAG): Líneas guía de accesibilidad para los desarrolladores de software para hacer webs.
3. User Agent (UAAG): lineas guía de accesibildidad para desarrolladores de navegadores, reproductores multimedia y tecnologías asistivas relacionadas

Todas estas especificaciones y algunas más forman parte de la iniciativa WAI, que cualquiera que se haya tenido que enfrentar al tema de la accesibilidad habrá oído nombrar.

La W3C acaba de pasar al estado de “Candidatos para recomendación” dos especificaciones importantes: mobileOK Basic Tests y WCAG 2

En este post comenzaré la primera:

mobileOK Basic Tests

Se trata de un documento, una guía, con recomendaciones muy genéricas que sirven de referencia a la hora de crear webs para dispositivos móviles. La idea base es la de establecer una serie de “buenas prácticas”  para la generación de contenidos para móviles, sin especificar modelos concretos.

Aunque es espesa, creo que cualquiera que vaya a afrontar un proyecto web orientado a móviles debería repasar el documento. En él se hace una descripción inicial, muy interesante, sobre las limitaciones y ventajas que imponen estos dispositivos.

Pero lo realmente interesante es la lista buenas prácticas. Es cierto que son consejos muy generales y que pueden parecerle obvios a un experto, pero aquí las tenemos todas recopiladas y siempre conviene tener un referente al que ajustarse cuando tenemos que defender una determinada forma de hacer las cosas

Algunos ejemplos de las recomendaciones:

1. [TESTING] Carry out testing on actual devices as well as emulators.

2. [URIS] Keep the URIs of site entry points short.

3. [NAVBAR] Provide only minimal navigation at the top of the page.

4. [BALANCE] Take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.