jQuery 2.0 ya está disponible… pero no corras a descargarlo todavía

Post original en JASoft.org: http://www.jasoft.org/Blog/post/jQuery-20-ya-esta-disponible-pero-no-corras-a-descargarlo-todavia.aspx

jqueryHace dos días se liberó la versión 2.0 de jQuery, el plugin más conocido y el más utilizado por todos los desarrolladores web del mundo.

Por regla general una nueva versión de cualquier cosa siempre es bien recibida, ya que aporta soluciones a bugs y nuevas características, y generalmente siendo compatible hacia atrás. Así que todos corremos a descargarla y probarla en nuestros sistemas. En este caso va a ser mejor que te lo pienses dos veces…

La versión 2.0 de jQuery NO ofrece características nuevas, y soluciona un mínimo número de bugs. Sus desarrolladores se han centrado en una cosa fundamentalmente: eliminar código de compatibilidad con Internet Explorer 6, 7 y 8 que les complicaba mucho la vida y hacía que perdiera un poco de rendimiento. Así que la única novedad real de jQuery 2.0 es que no ofrece soporte para IE 6, 7 y 8.

Al mismo tiempo han liberado la versión 1.9.1 que ofrece exactamente lo mismo pero sigue siendo compatible con estas versiones antiguas de Internet Explorer.

De esto modo se mantendrán dos ramas de jQuery en paralelo al menos durante unos años: la rama 1.x (con la versión 1.10 que aparecerá dentro de dos meses) que seguirá teniendo soporte para IE6/6/8,  y la rama 2.x sin dicho soporte.

La justificación es que, aunque sean compatibles, con la versión 2.0 podrás tener una descarga de menor tamaño y se ejecutará un poco más rápido y con menos complicación en navegadores compatibles.

Hay algunas situaciones en las que esto sabemos seguro que se va a dar: cuando programamos una aplicación móvil basada en HTML 5 usando PhoneGap o Apache Cordova. Éstas se ejecutarán siempre en un teléfono móvil que tendrá un navegador moderno soportado, por lo que nos podemos despreocupar.

En el resto de los casos creo que sería un error utilizarla.

El motivo es que, a pesar de que esos navegadores son muy viejos, lo cierto es que siguen teniendo a día de hoy un 31% del mercado en sistemas de escritorio. El que más cuota sigue teniendo es Internet Explorer 8, con un 23,23%. Aunque estas cifras varían ligeramente según la fuente que consultes, sigue siendo una cuota tremendamente alta.

El motivo de estas cifras lo debemos buscar en que muchísima gente (y empresas) siguen utilizando Windows XP como sistema operativo, y en él la mayor versión de IE que puedes instalar es la 8, que se actualiza automáticamente en sistemas originales desde Windows Update. Esto explica que haya una gran mayoría de estos usuarios con IE8, casi nadie con IE7 y muchos aún (más del 6%) con IE6: los primeros siguen con XP original, y los últimos son los que tienen Windows XP pirata y no lo pueden actualizar.

Además, y esto es importante, si usas Internet Explorer 9 o 10, pero tus páginas se muestran en versión de compatibilidad, tampoco estarán soportadas por jQuery 2.x.

Aprende jQuery rápido, online, paso a paso, con tutorías para resolver tus dudas.
más información…

Yo soy el primero al que le gustaría olvidarse para siempre de estas reliquias de un tiempo pero, al menos hay que dar soporte a Internet Explorer 8 si tu aplicación va a estar abierta a todo el mundo en Internet y quieres llegar a la mayor parte de la gente.

La nueva versión 2.x de jQuery ahorra más bien poco (3,6 Kb menos en la versión minimizada y descargada a través de una conexión gzip), el rendimiento no es mucho mejor seguro (o lo habrían cuantificado de algún modo), pero ponerlo inadvertidamente en tu aplicación te puede causar muchos dolores de cabeza.

Puedes incluir las dos versiones en tu página si quieres usando el siguiente truco con regiones condicionales de IE, que los propios programadores de jQuery recomiendan:

   1: <!--[if lt IE 9]>

   2:     <script src="jquery-1.9.1.js"></script>

   3: <![endif]-->
   1:  

   2: <!--[if gte IE 9]><!-->

   3:     <script src="jquery-2.0.0b2.js">

</script>

   4: <!--<![endif]-->

Pero ¿realmente merece la pena?

Yo, por el momento, usaré solamente las versiones 1.x, dejando las 2.x para dentro de un tiempo, cuando con un poco de suerte borremos a IE6/7/8 de la faz de la tierra.

Esperemos que sea pronto. Microsoft dejará de dar soporte a XP el 8 de abril de 2014. Esperemos que mucho antes de eso las empresas inmovilistas y los usuarios que todavía están con XP se migren todos a versiones más modernas y veamos una cuota de mercado de IE 6/7/8 prácticamente nula.

Tu estilo gana a mi estilo: Especificidad en reglas CSS

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Tu-estilo-gana-a-mi-estilo-Especificidad-en-reglas-CSS.aspx

CSSLos selectores CSS nos permiten definir con mucha precisión el aspecto (¡y comportamiento!) que van a tener los elementos HTML en nuestras páginas. Así, utilizamos: estilos embebidos, identificadores, clases, pseudo-clases, etiquetas y atributos para definir exactamente cómo ha de funcionar cada elemento.

Las hojas de estilo .css suelen tener decenas o cientos de estilos que el navegador debe aplicar a cada elemento. Muchos de estos estilos entran en conflicto, por lo que ¿cómo decide el navegador qué estilo o estilos concretos debe aplicar a un determinado elemento de la página?

Pongamos un ejemplo sencillo y consideremos el siguiente fragmento de HTML:

   1: <ul id="menu">

   2:     <li>Menu 001</li>

   3:     <li class="destacado">Menu 002</li>

   4:     <li>Menu 003</li>

   5: </ul>

Al cual se le aplican los siguientes dos estilos:

   1: ul#menu li {

   2:     font-weight:normal;

   3:     font-size:14px;

   4:     color: blue;

   5: }

   6:  

   7: .destacado {

   8:     font-weight:bold;

   9:     color:red;

  10:     text-decoration: underline;

  11: }

Si leemos los selectores vemos que el primero se aplica a los elementos de lista (li) que se encuentran dentro de listas sin ordenar (ul) cuyo identificador es “menu”, es decir afecta a todos los nuestros. En ese caso se les aplica un tamaño de letra de 14px y el color azul para el texto. El segundo selector indica que los elementos que lleven la clase “destacado” aplicada, deberán mostrarse en negrita, con letra de color rojo y con una línea de subrayado.

Según esto, aparentemente, el aspecto que debería mostrar el HTML una vez renderizado en el navegador sería este:

CSSEspecificidad_1

Sin embargo, el verdadero aspecto que muestra es este otro:

CSSEspecificidad_2

Es decir, el selector CSS para la clase “destacado” no se está aplicando en su totalidad, sino que solamente aplica la parte del subrayado, pero no la negrita ni el color rojo para el texto.

¿A qué es debido esto?

La especificidad de los selectores CSS

Como decía, en una página típica hay decenas o cientos de selectores CSS y a un mismo elemento se le pueden aplicar varios de ellos. El navegador debe elegir en cada momento cuál es el apropiado, ya que en muchas ocasiones estos selectores pueden tener valores contradictorios. En el ejemplo anterior, a pesar de su sencillez, ya lo hemos experimentado. Ambos estilos se aplican a nuestro elemento destacado y tienen indicaciones contrarias para el peso del texto y su color, así que ¿cuál debe aplicar el navegador?

Para decidirlo los navegadores utilizan las reglas de la especificidad de los selectores. Es decir, cuanto mas específico es un selector mayor fuerza tiene y es el que prevalece.

Para calcular la especificidad se genera un número que dota de peso diferente a cada elemento, de acuerdo con el siguiente esquema de cálculo:

CSS Especificidad

En este gráfico los elementos situados más a la izquierda se consideran más específicos que los de la derecha, por lo que tendrán más peso a la hora de decidir qué estilos aplicar a un determinado elemento cuando haya conflicto.

Así, los estilos que se especifiquen directamente en la etiqueta HTML siempre tendrán la mayor precedencia y se aplicarán siempre. Si hubiésemos escrito:

   1: <li style="color:red;font-weight:bold;">Menu 002</li>

Da igual lo que indiquen el resto de selectores CSS incluidos en la cabecera o en un .css externo: se aplicará el estilo in-line que hemos indicado.

Para el resto de selectores se deben contar los elementos de cada tipo que haya en dicho selector y colocar el número resultante en cada uno de los recuadros que hay en la figura de arriba. El número resultante será la especificidad del selector, y cuanto mayor sea mayor precedencia tendrá.

Por ejemplo, para nuestro selector “.destacado” la especificidad es simplemente 0,0,1,0 (o, si lo pasamos a un número decimal normal (aunque no lo sea, OJO), sería simplemente un 10). ¿Por qué? Pues porque tiene simplemente una clase, es decir, un elemento para el tercer recuadro, en el que se deben sumar las clases, pseudo-clases y atributos.

Para el otro selector “ul#menu li”, la especificidad es 0,1,0,2 (o lo que es lo mismo, el número 102), ya que especifica un identificador (@menu) y dos elementos HTML (ul y li).

Dado que 102 es mayor que 10, el primero de los selectores es más específico y por lo tanto cuando haya reglas que entren en conflicto son las de éste las que aplican.

Es por eso que sale el texto con color azul, sin negrita,pero sin embargo sí que se aplica el subrayado también, ya que para esta regla no existe conflicto alguno.

Si abrimos las Developer Tools de Internet Explorer o de Chrome y seleccionamos el elemento destacado, podemos ver los estilos resultantes y comprobaremos que efectivamente se aplican ambos estilos pero uno prevalece sobre el otro (lo he marcado aquí en Chrome):

CSSEspecificidad_Chrome

¿Como haríamos entonces para que se aplique realmente el estilo que deseábamos en nuestro elemento destacado?

Pues siendo más específicos, por ejemplo con este selector:

   1: ul#menu li.destacado {

   2:     font-weight:bold;

   3:     color:red;

   4:     text-decoration: underline;

   5: }

En este caso la especificidad es 0,1,1,2 (1 identificador, 1 clase y dos elementos HTML), es decir, 112, que es mayor que 102 y por lo tanto se aplicaría con mayor prioridad, consiguiendo el resultado que buscábamos.

Algunas cosas a tener en cuenta

La regla es bastante sencilla, pero además debemos tener en cuenta algunas reglas adicionales:

  • A igualdad de especificidad siempre gana el selector que esté definido más tarde en la página. Por ejemplo, si tenemos un elemento al que se le aplican las clases “menu destacado” y tenemos dos selectores “.menu” y “.destacado” (ambos aplican exactamente igual al elemento), con estilos que entran en conflicto, ganará el último de los dos que esté definido en la página.
  • Un elemento de mayor especificidad siempre gana a cualquier número de elementos de menor especificidad. Por ejemplo, imaginemos un selector muy loco que contiene una clase y mete 12 etiquetas HTML en la definición. La clase gana a los elementos HTML aunque si lo convirtiésemos en un número sería 1,12, y en decimal, al pasar de 10, habría que sumarlo a las decenas. Por eso decía que no debe considerarse como un número decimal, sino que se debe ver cuál de los elementos es superior empezando por la izquierda. Lo de convertirlo en un valor decimal sólo sirve como abstracción, para hacerlo más sencillo de comprender, y sirve para casi todos los casos porque realmente es muy raro que haya más de 9 elementos de un tipo especificados. Si los hay seguramente es que la CSS está bastante mal definida.
  • El selector universal (*) no tiene especificidad, o para ser más exactos, su especificidad es 0,0,0,0, por lo que no aporta nada a la especificidad.
  • El modificador “!important” aplicado a un atributo de estilo siempre gana. Lo podemos usar para cuando realmente sea muy importante que un estilo se aplique a un elemento o clase y nos queramos saltar las reglas de especificidad. No deberíamos usarlo más que en casos muy especiales, y desde luego no deberíamos abusar de él.

Calculadoras de especificidad

Aunque el cálculo es bastante fácil y además podemos usar las Developer Tools de los navegadores para cuando haya dudas sobre qué estilos prevalecen, puede ser útil tener a mano una calculadora de especificidad de selectores, que nos saque de dudas en algunas ocasiones.

Las dos más conocidas son:

  • Specificity Calculator de Keegan Street: permite comparar de manera muy visual y atractiva dos selectores cualesquiera.
  • CSS Specificity Calculator de Nicholas Bannister-Andrews: es mucho más espartana que la anterior, pero tiene la ventaja de que nos permite calcular la especificidad de muchos selectores de un solo golpe, por lo que es muy rápido si necesitamos muchos cálculos.

Ambos explican los resultados de sus cálculos para ayudarnos a entenderlos.

Este post está basado en material extraído de mi curso online de HTML(5) y CSS(3) en campusMVP. Si quieres aprender de verdad este tema y tenerme como tutor para contestar tus dudas empieza hoy mismo.

 

Fácil, ¿no?. Pues la especificidad es tal vez el concepto más importante que debes conocer y tener claro sobre CSS. Te evitará muchas sorpresas y te ayudará a saber porqué fallan los estilos de tus páginas.

¡Espero que te sea útil!

Zen-Coding: escribiendo HTML a la velocidad de la luz

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Zen-Coding-escribiendo-HTML-a-la-velocidad-de-la-luz.aspx

ZenCodingJMAlarconEscribir HTML para dar forma a un documento Web es un absoluto aburrimiento. Al menos a mi me lo parece. Por ello trato de reducir el tiempo que paso haciéndolo al máximo posible. Gracias a entornos avanzados de edición como WebStorm, Expression Web, Sublime o el propio Visual Studio, la velocidad puede aumentar mucho ya que estos entornos se encargan automáticamente de cerrar etiquetas, indentar el código, etc… Sin embargo yo quiero más. Quiero reducir a la mínima expresión el código que debo escribir. Y es ahí precisamente en donde entra en juego Zen-Coding, una gran idea que cada vez se utiliza más.

Zen-Coding es un tipo de sintaxis especial para generar HTML y otros lenguajes estructurados (XML y similares) que es muy similar a los selectores que usamos para CSS, pero que nos permite generar de manera rápida y concisa código HTML.

Gracias a Zen-Coding podrás crear complejas estructuras HTML con una sola línea de código y sin tener que preocuparte de generar correctamente el código, indentarlo, ordenarlo, etc…

Por ejemplo, una expresión como esta en Zen-Coding:

   1: #content>#header.Main>ul>li*3>a.menu{Menu $$}

Nos genera este código HTML equivalente:

   1: <div id="content">

   2:     <div id="header" class="Main">

   3:         <ul>

   4:             <li><a href="" class="menu">Menu 01</a></li>

   5:             <li><a href="" class="menu">Menu 02</a></li>

   6:             <li><a href="" class="menu">Menu 03</a></li>

   7:         </ul>

   8:     </div>

   9: </div>

La sintaxis de Zen-Coding, aunque pueda parecer compleja a simple vista, es realmente sencilla y la podemos aprender en unos pocos minutos, ganando mucha productividad en el futuro.

La sintaxis de Zen-Coding está soportada por multitud de editores de HTML, y si no existen plugins para la mayor parte de los editores del mercado. En su página puedes encontrarlos.

Este post va a ser fundamentalmente práctico y enseñaré mediante el siguiente vídeo (del estilo de los que hay en los cursos de campusMVP, los cuales combinan teoría y prácticas cortas en vídeo como esta), cómo utilizar Zen-Coding con Visual Studio. Lo aprendido en el vídeo es válido para cualquier otro editor que soporte Zen-Coding, pero he usado Visual Studio por ser el más utilizado por los visitantes de este blog.

Antes de nada te va a venir bien esta tabla resumen que he elaborado con los diferentes caracteres utilizados en Zen-Coding y su significado:

Carácter Propósito
#
Atributo "id"
. Atributo "class"
> Elemento hijo
+ Elemento hermano (mismo nivel)
[] Atributo personalizado
{} Texto personalizado en el elemento
* Múltiples elementos
$ Numeración incremental
$$$ Numeración incremental con relleno
^ Subir en la jerarquía de elementos
() Agrupación de elementos
lorem Generador de textos "Lorem ipsum"
html Genera etiquetas y cabeceras HTML, como por ejemplo: html:5 para generar todas las cabeceras de HTML5, o html:xml para XHTML.

Con esta tabla delante y el vídeo que te enseño a continuación podrás estar generando código HTML a toda velocidad dentro de 15 minutos 🙂

¡Espero que te sea útil!

Nota: Por cierto, existe una evolución de Zen-Coding, llamada a sustituirlo, llamada Emmet que se usa de la misma forma pero añade algunas características más. De momento no tiene soporte explícito en Visual Studio, pero la extensión de Zen-Coding de Web Essentials que muestro en el vídeo en realidad soporta ya la mayoría de las mejoras de Emmet para HTML, como el poder subir niveles con ^, la generación de “Lorem Ipsum” o diversos tipos de HTML. Hay algunas cosas que seguramente le irán añadiendo en el futuro, pero prácticamente todo lo importante está ahí ya. No se soporta de momento la sintaxis para generar CSS, aunque en VS esto es poco importante dado el soporte que ofrece de serie. Otros editores, como Sublime, NOtepad++ o WebStorm, por citar unos pocos, tienen soporte para Emmet.

Nota 2: Me dicen los amigos de JetBrains que con Resharper tienes Zen-Coding incluido de serie también, algo que desconocía, pero dada lo extendido que está este producto y lo potente que es me parece interesante resaltarlo aquí.

Déjà vu: Blink es IE5/6 y Google es la nueva Microsoft

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Deja-vu-Blink-es-IE56-y-Google-es-la-nueva-Microsoft.aspx

Browsers4Los que tenemos ya unos cuantos años a nuestras espaldas y somos además bilingües digitales, recordamos lo que fue la tremenda guerra de los navegadores de finales de los años ‘90 y principios de los ‘00. Todavía sentimos punzadas de dolor al recordar lo que ello supuso para los desarrolladores web de entonces. Si crees que ahora es complicado programar una aplicación web y que funcione para todos los dispositivos y navegadores, tendrías que haber visto lo que era eso en el año 2.000 :-S

Cuando Internet apareció en nuestras vidas a principios de los años ‘90 muchas empresas subestimaron su importancia. Y quizá la que más se confundió entonces fue Microsoft, por aquella época ya líder del mercado de sistemas operativos para el escritorio. No supo ver el potencial que suponía la Red de redes, y se dejó llevar. para cuando quiso darse cuenta una pequeña empresa llamada Netscape se había hecho con el 80% del mercado de navegadores de Internet, dejando a Microsoft sin posibilidades (aparentemente) de obtener el control de la navegación por el nuevo medio.

Microsoft reaccionó tarde pero tenía su favor dos cosas de las que no disponía la pequeña Netscape: dinero a espuertas, y una cuota de mercado brutal en los sistemas operativos, de más del 95%. Así que puso a los mejores a trabajar en su propio navegador de Internet y en unos pocos años alcanzó a Netscape. Desde agosto de 1995 en que se lanzó Internet Explorer 1.0 poco a poco fue comiendo terreno al competidor, hasta que en 2002, en el máximo apogeo de su poderío, Internet Explorer 6.0 llegó a tener un 96% de cuota de mercado de uso de navegadores. Esos 7 años es en los que se suele acotar la duración de la primigenia guerra de los navegadores.

Para tratar de competir entre ellos, tanto Netscape como Internet Explorer añadían constantemente características a los navegadores, las cuales eran incompatibles entre sí. Una gran parte de la confusión que existe hoy en día con el DOM (Document Object Model) de los navegadores, y la necesidad de estandarizarlo usando “parches” (como por ejemplo que en el procesamiento de eventos tengas que especificar en qué dirección se notifican éstos por el árbol de elementos de una página), provienen de esta época oscura. En aquel entonces, en la práctica, lo que había que hacer era crear dos versiones de tus páginas o aplicaciones web: una para Internet Explorer y la otra para Netscape. Salvo en los casos más simples, era casi imposible hacer algo complejo que fuera fácil de poner a andar en ambas plataformas.

El que más hizo uso de su poder para imponer su punto de vista sobre cómo debían hacerse las páginas Web fue Microsoft, y cuando el World Wide Web Consortium (W3C) se empezó a poner las pilas y promovió estándares para tratar de buscar un común denominador, Internet Explorer no los implementaba. De hecho hasta Internet Explorer 8 (marzo de 2009), cuando ya la nueva competencia de Firefox y Chrome empezaba a hacerles daño de verdad, Microsoft no empezó a tomarse en serio la necesidad de seguir los estándares. De hecho no fue hasta Internet Explorer 9 cuando empezó a conseguir una buena compatibilidad. Ahora con IE10 la implementación de HTML 5 y CSS 3 es muy alta, pero todavía le queda bastante camino que recorrer, si bien el futuro Internet Explorer 11 incorporará algunas características (como WebGL y WebRTC) con las que no estaban de acuerdo y se resistían a incluir en su navegador.

La situación llegó a tal punto que hasta la propia Microsoft hizo campaña contra su propio navegador, muchos años más tarde, y promovió un sitio web para que la gente dejara de utilizar Internet Explorer 6 (aunque aún tiene más de un 5% de cuota a día de hoy). Y no fueron los únicos.

Distintos corazones para la misma Web

Hasta hace muy poco existían cuatro motores de renderizado, que son el corazón de los principales navegadores del mercado:

  • Trident: es el motor de renderizado de Internet Explorer. Creado y controlado por Microsoft en los años ‘90 y evolucionado hasta llegar a su actual encarnación, muy compatible con los últimos estándares del W3C. Es de código cerrado. Aunque es totalmente multi-platoforma (corre bajo Windows en plataformas Wintel, pero también en la versión para ARM de Windows y en Windows Phone, con arquitecturas diferentes), Microsoft sólo lo utiliza en sus propios productos, por lo que no podemos usarlo en Mac, por ejemplo (algo que hace años sí era posible gracias a los acuerdos entre Microsoft y Apple).
  • Gecko: es el motor de Firefox. Es el heredero de Netscape ya que parte del código que esta empresa liberó como Open Source en 1998 con el nombre de Mozilla. El motor del Netscape original era muy inferior en características y potencia al de Internet Explorer, por lo que liberaron Mozilla y se desarrolló en paralelo en modo abierto para lograr un producto nuevo más competitivo. En 2000 salió Netscape 6 que llevaba Gecko en su corazón, pero en 2003 el entonces dueño de Netsape se deshizo del proyecto. A partir de ese momento los ex-empleados de Mozilla cogieron el proyecto bajo su mano y empezaron con Firefox.
  • Webkit: es el motor de renderizado de Apple Safari y de Google Chrome entre otros muchos navegadores, entre los que se incluyen la mayoría de los navegadores para móviles (iOS, Android, Blackberry…). Hoy en día es el que mayor cuota de mercado conjunta tiene si se suman los de todos los navegadores que lo utilizan. Nació como un “fork” del motor de render KHTML para el entorno de escritorio de Linux KDE. Esta nueva rama la inició Apple en el año 2001, portando el código a Mac OS X con ayuda de adaptadores. En un momento dado se llegó a la conclusión de que la base de código era tan diferente debido a las modificaciones de Apple que era extremadamente complejo mantener el intercambio de código entre KHTML y Webkit, y además la relación entre ambos equipos empezó a ser muy tensa, así que éste último se convirtió en un proyecto independiente. Hoy en día KHTML sigue su propio camino pero apenas es utilizado y de hecho desde 2007 KDE usa también Webkit en el navegador de su escritorio. Aunque Chrome usa Webkit para renderizar las páginas, el motor de JavaScript que utiliza es propio, se denomina V8 y también dota de su potencia a lenguajes de servidor como Node.js.
  • Presto: es el motor de renderizado de Opera. Lanzado en el año 2003 con Opera 7, la gente de Opera Software lo ha abandonado en favor de Webkit, por lo que las próximas versiones de Opera estarán basadas también en el motor que originó Apple.

Dado que Opera ha abandonado Presto, quedan en la práctica 3 motores de render de HTML: Trident, Gecko y Webkit, todos ellos muy parecidos en cuanto a características, confluyendo hacia los estándares del W3C.

Sin embargo Google acaba de anunciar que se separa del proyecto WebKit para crear una nueva variante del motor denominada Blink. Google alega para este movimiento que, dado que su navegador tiene una arquitectura muti-proceso muy diferente a la de los demás navegadores que también usan Webkit, se agrega mucha complejidad al proyecto, así que a partir de ahora irán por libre. Dice que van a deshacerse de 7 sistemas de “build” y a eliminar más de 7.000 archivos (con más de 4,5 millones de líneas de código) para aligerar el programa.

Sin embargo a mi me gusta mucho este FAQ alternativo que ha escrito Rob Isaac traduciendo al cristiano la cháchara del FAQ original de Google sobre el movimiento a Blink. Creo que es bastante esclarecedor sobre las intenciones de Google con Blink.

Una nueva guerra de los navegadores

Ahora mismo nos encontramos en el amanecer de una nueva guerra de los navegadores. Y no me refiero a una guerra comercial por ver quién acapara más usuarios de su navegador, sino a una guerra sucia de estrategias inmovilizadoras en la que el que saldrá perdiendo será sin duda el usuario y sobre todo los programadores.

En el mundo de los navegadores existen dos fuerzas opuestas en cuyo equilibro se basa la felicidad de los habitantes de Internet. Por un lado está la competencia, que es muy importante para asegurar que se avanza y que ninguna empresa impone su propio punto de vista. Por otro tenemos la necesidad de un marco común sobre el que programar y que sea compartido por todos los navegadores.

¿Cómo se aúnan esas dos fuerzas opuestas? Por un lado gracias a la estandarización de las tecnologías web, cometido que le corresponde al W3C. Y por otro tratando de que no haya demasiada desigualdad en las cuotas de mercado de los competidores. Que uno de ellos domine ampliamente a los demás no es bueno para nadie como nos demuestra la historia reciente.

Hasta hace poco nos encontrábamos cerca de esta situación ideal. Disponíamos de 3 motores de renderizado principales en el mercado con unas cuotas de reparto de usuarios bastante equilibradas ya que no había ninguno con un trozo exageradamente mayor que los demás (aunque depende de a quién le preguntes y quién proporcione las estadísticas). Existe un consenso acerca de que HTML 5 y CSS 3 deben ser los caminos a seguir, y todos los navegadores en mayor o menor medida cumplen con el borrador actual de esos estándares, y la confluencia hacia ello es innegable. Si bien todavía existen algunas diferencias entre los navegadores, excepto para aplicaciones avanzadas o especiales que usen algunas características específicas de algún navegador, la programación es muy parecida (lástima de WebRTC y WebGL en IE, pero hacia ello va también). También existen discrepancias acerca de los formatos multimedia a utilizar en cada navegador (con otra pequeña guerra abierta entre Google con su formato WebM y los demás por ver cuál es el que predomina). Ya digo: todavía con diferencias, discrepancias y luchas, pero todo el entorno web confluyendo en la misma dirección.

Sin embargo WebKit especialmente (y en particular por parte de Google) comenzó a añadir extensiones a este motor de renderizado que hacían que ciertas características sólo funcionasen en éste, dejando de lado los estándares y a los demás navegadores. Mozilla también tiene lo suyo en este aspecto, pero su poder cada vez es menor. Internet Explorer incluye algunas extensiones propias pero están pensadas únicamente para ser utilizadas en aplicaciones “Metro” (o Windows Store, como se dice ahora) y no en la Web.

El poder de Webkit se ha extendido enormemente debido no sólo a la popularidad de Google Chrome en el escritorio (con una cuota global estimada que anda de cerca del 40% si no lo ha superado), sino sobre todo a su absoluto dominio dentro del mundo móvil ya que lo incorpora la versión móvil de Safari para iOS (iPhone y iPad) y la versión móvil de Chrome en Android. Este poder rompe el equilibrio y Google sobre todo lo sabe. Así que hace ya tiempo que se dedican a incluir sus propias extensiones al navegador, siendo cada vez más frecuente encontrarse con páginas “optimizadas para Chrome” o que directamente sólo funcionan en este navegador, algo que no pasaba desde los años de IE6 y su 96% de cuota de mercado.

Muchos detractores están haciendo campaña para luchar en contra de este efecto y que vuelva una nueva guerra de navegadores. El más significativo es quizá este artículo que escribió hace un año Daniel Glazman, co-presidente del grupo de trabajo para CSS del W3C:

CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*

En este artículo es una llamada a la acción a todos los desarrolladores web para que no se dejen llevar por la inercia y desarrollen solamente para WebKit, y que no admitan únicamente el uso de los prefijos propios de este motor de renderizado, para que no vuelva a pasar lo de hace una década. También apela a los usuarios para que protesten cuando lleguen a sitios así, y para que no sólo usen Chrome y navegadores con Webkit.

Él, claro está se centra en CSS que es lo suyo, pero esto mismo ocurre en otras partes de HTML, como por ejemplo el sistema de notificaciones, o la implementación específica de algunas APIs.

Con la decisión de Google de moverse de Webkit y empezar su propia versión, Blink, las cosas empezarán a ser mucho peores en los próximos meses. Sobre todo teniendo en cuenta que actualizarán al nuevo motor a sus millones de usuarios de manera silenciosa, sin avisar, y poco a poco tendremos un nuevo motor diferente y con cosas particulares, pero con un poder de mercado enorme con el que competir para quitar a sus competidores del medio.

Además hemos de tener en cuenta que Apple ahora se queda sin la mitad aproximadamente del código que se contribuía a Webkit (era Google quién lo hacía), y Apple está centrado en iOS 7 y sus iDispositivos. Tener un navegador de vanguardia no creo que sea una de sus prioridades, más allá de como mucho mantenerse a un nivel parecido al de los demás navegadores, o sea, como Microsoft no hace tanto. Por otro lado Microsoft no puede liberar alegremente nuevas versiones de su navegador tan a menudo como quisiera ya que, al contrario que Google, tiene cientos de millones de clientes corporativos en los que no puede simplemente actualizar su motor de renderizado y ya está. Si rompe la compatibilidad sin querer con alguna aplicación interna tendría un problema muy grave que ha partido, encima, de un producto gratuito, por no mencionar que los administradores de sistemas son muy conservadores (por la cuenta que les trae) y no actualizan así como así nada en sus redes. Google no tiene ese problema.

Google está libre para avanzar a la velocidad que crea conveniente con las características de su navegador, sin luchar con Apple, con una cuota de mercado muy elevada y con actualizaciones silenciosas y automáticas en segundo plano. No va a tardar en añadir decenas de características que sólo funcionarán en su navegador. Y la Web y todo lo que funciona desde ella son su prioridad absoluta. De ello depende su supervivencia, así que no dudará ni un ápice en hacer lo que sea para barrer a los demás del mercado. ¿Te suena la historia? A mi también.

Muchos pueden alegar que el hecho de que se añada innovación es positivo. Claro que lo es. Lo que NO es positivo es que lo hagan sin contar con los demás de modo que usen su poder para alcanzar mayores cuotas de mercado (qué pasa si GMail o Google Maps sólo funcionan con Chrome, por ejemplo, o si hay ciertas cosas que sólo funcionan en Android y no en los demás móviles), y sin consensuarlo con los demás actores del mercado.

Y la cosa sólo puede ir a peor. De hecho ya se están viendo movimientos en otros ámbitos que poco tienen que ver con decisiones que favorezcan a los usuarios y mucho con decisiones comerciales (eliminar Active Sync de Google Apps, cargarse Google Reader…).

Es cierto que el W3C es un organismo lento hasta la exasperación, que lleva muchísimos años para aprobar HTML 5 y todavía le falta bastante para hacerlo. Pero eso no es motivo para saltárselo a la torera y que cada uno tire por su lado. Lo que habría que hacer es consensuar y debatir sobre las nuevas características necesarias para los navegadores, innovando en las mismas sin importar de quién vengan, y llegar a acuerdos aunque algunos pierdan pequeñas parcelas de poder o no estén totalmente de acuerdo (esto pasaba en Webkit hasta ahora sin mayores tragedias que se sepa). Unas veces ganarán unos y otras otros, pero así ganaremos siempre los que importamos: los usuarios, y también los desarrolladores. También se puede agilizar el trabajo de la W3C. Es una cuestión de voluntad y de poner recursos y personas específicamente dedicadas a ello por parte de las empresas involucradas.

¿Te acuerdas de cuándo Microsoft introdujo VBScript en sus navegadores y sólo lo soportaban ellos? Pues tenlo en mente cuando dentro de unos meses tengas a Dart, el lenguaje de Script de Google, metido en Chrome y empiecen a aparecer sitios de la empresa (Gmail?), que sólo funcionen con ese navegador porque están escritos con Dart. Por no mencionar el poder que pueden tener para dotar de ventaja competitiva a su sistema operativo móvil, Android.

Lo dicho en el título: estoy teniendo un Déjà vu. En él Blink es el nuevo Internet Explorer 6 y Google hace exactamente lo mismo que hizo en su día Microsoft.

Me están entrando sudores fríos…

 

ACTUALIZACIÓN 10/4/2013

En esta sociedad de Internet, con sobrecarga de información y llena de artículos ligeros y superficiales, la gente se ha acostumbrado a no leer (aunque le marques en negrita lo importante). Incluso los que sí leen, en muchos casos no se paran ni medio segundo a meditar sobre lo que han leído. Así que quizá en este artículo debería haber sido menos didáctico y más directo al grano, al menos a tenor de algunas críticas que se han vertido sobre él en las redes sociales. En otros casos además confluye la circunstancia de que como contra-argumentos lo único que se hace es repetir clichés (disfrazados de aforismos) que mucha gente tiene grabados a fuego y nunca analizan de manera objetiva y con cierta perspectiva.

Uno de estos clichés es el de “Es Open Source, ergo es siempre bueno”.

A ver, mis conclusiones de este artículo de opinión no se ven influidas en modo alguno por el hecho de que Blink sea o no Open Source. Da exactamente igual que sea ese el caso. Lo importante aquí es que una determinada empresa tiene una posición predominante en el mercado y que va a utilizar esa posición para llevar a los usuarios hacia sus productos para tratar de acabar con su competencia, como ya hizo Microsoft en los ‘90. Para ello van a dotar a su navegador de características incompatibles con los demás navegadores para que debas utilizarlo para hacer uso de sus productos (correo, mapas, quizá buscador), de modo que pueda favorecer sobre todo a su sistema operativo para móviles, pero también para que uses Chrome y puedan saber más de ti y venderte mejor publicidad. No será en medio año ni en un año, pero seguro que sí en menos de dos.

¿Qué más da que el producto sea Open Source? ¿Los demás navegadores van a coger ese código Open Source y lo van adoptar? ¿Por qué no adoptan entonces directamente todos los navegadores Blink como futuro motor de render y así todos contentos? Quizá deberían hacerlo y así todos tendrían que ponerse de acuerdo.

Webkit ya es Open Source. No es necesario que hagan Blink para que el producto sea Open Source. La diferencia estriba en que ahora en WebKit las contribuciones al código son aproximadamente del 50% por parte de Google y Apple. Lo que contribuye el resto de la gente es casi testimonial. Esa situación obliga a Google a negociar con Apple sobre qué cosas se incorporan o no al navegador, y se mantiene un cierto equilibrio puesto que ambas empresas están en lucha con sus sistemas operativos móviles y, como en el chiste del dentista, la situación es “vamos a llevarnos bien”.

Ahora que Google va por libre y su navegador tiene una cuota de mercado tan amplia, nada les impide tomar medidas en el navegador para atarlo a sus tecnologías, productos y sistemas, como haría cualquier empresa privada en su situación y mientras las autoridades anti-monopolio no les metan mano como pasó con Microsoft.

Y es que, queridos niños y niñas, Google es una empresa privada, no una ONG, y (¡cuidado, spoiler!) los reyes magos no existen. Lo único que buscan es su beneficio y el de sus accionistas, al igual que Apple, Microsoft, Facebook, o cualquier otra empresa privada. Lo del “Don’t be evil” hace mucho que quedó en otro cliché. Por eso es necesario un W3C ágil y participativo.

El hecho de que el código de Blink vaya a ser Open Source no tiene absolutamente nada que ver con lo que yo estaba diciendo. en el artículo Es indiferente para lo que me preocupa y debería preocuparnos a todos los que estamos involucrados en Internet.

Sé que alguna gente que ha criticado mi punto de vista estaba en el instituto cuando se generó la primera guerra de los navegadores (¡qué viejo me hace sentir!) y no saben de lo que estoy hablando. Pero a nada que uno se pare a analizarlo es evidente. Lo negativo de la situación se cae por su propio peso.

En cualquier caso, el tiempo me dará o me quitará la razón. Todo esto es solo una opinión basada en la experiencia. Pero como no estamos hablando de religión ni de política, no hay motivos para la acritud ni las discusiones.

Simplemente espero haber aclarado un poco más mi punto de vista con este comentario adicional 🙂

Música en Windows Phone 8: suficiente, pero necesita mejorar

ATENCIÓN: Este artículo está obsoleto. Todo lo que se cuenta en él ya está muy superado por las nuevas versiones del sistema operativo y del software que se menciona. Lee la nueva versión de Septiembre de 2014 de este artículo: «Música en Windows Phone 8.1: sin ningún problema«.

Se deja este artículo antiguo aquí por histórico, pero ya no es válido.

¡No sigas leyendo! 🙂

Spotify-on-Lumia-920Para terminar con esta serie que he comenzado sobre mi cambio de iPhone a Windows Phone 8 voy a comentar mi experiencia personal respecto a la música con mi Nokia Lumia 920.

Una de las funciones principales para mi en un teléfono es la de poder oír música. Antes de nada he de comentar mis necesidades particulares en lo que a música en un móvil se refiere, que puede que no coincidan para nada con las tuyas, en cuyo caso tu experiencia puede variar sustancialmente respecto a la mía:

  • Música off-line: El motivo es que solo suelo escuchar música en mis ratos libres lejos del ordenador, y mientras estoy en transporte, es decir, de casa al trabajo en el coche, en los aviones, etc… En mis (escasas) vacaciones procuro no tener buena conexión cerca, sino no desconecto jamás (nunca mejor dicho). Por ello la necesidad de tener la música disponible mientras no tengo conexión es fundamental.
  • Spotify: soy fiel suscriptor de Spotify prácticamente desde que salió, así que llevo varios años pagando religiosamente los 9,99€ mensuales que cuesta. Lo malo es que si dejo de pagarlos me quedo sin música. Lo bueno es que en estos años he creado mis listas con cientos y cientos de canciones cuidadosamente seleccionadas, por lo que tener Spotify off-line en la plataforma móvil que utilice es indispensable.
  • Podcasts: para mi los podcast son también básicos. Aparte de escuchar música seleccionada por mi en Spotify, me gusta mucho descubrir nuevos temas cada semana siguiendo los podcast de algunos músicos o programas radiofónicos sobre todo americanos o europeos. También escucho programas hablados como el Vergecast, pero sobre todo música (si no, no desconecto nunca).

Entonces, la plataforma móvil que use debe darme unos mínimos en estos tres aspectos o no me servirá, y no estoy dispuesto a ir con dos aparatos encima: el móvil y uno para música.

Los dos primeros están relacionados, así que hablaré sobre ellos en un segundo, pero antes…

XBox Music y Nokia Music

Antes de nada he de decir que no me planteo XBox Music ni Nokia Music como una opción adecuada para mi ahora mismo. Y eso que ambos te permiten escuchar música gratuitamente en streaming, y en el caso de XBox Music se sincroniza con mis dispositivos de sobremesa y tableta con Windows 8. El precio mensual de XBox Music Pass es como el de Spotify pero además te permite descargar las canciones, lo cual es sensacional si más adelante decides dejar de pagar el servicio (o eso entiendo al leer las condiciones, pero no lo he probado. Que me corrija alguien si no es así). Yo con Spotify me quedo sin música si dejo de pagarlo, así que a priori me convendría pasarme a XBox Music Pass.

Si no lo hago es por dos cuestiones fundamentales:

  1. Me costaría mucho trabajo volver a replicar mis listas de Spotify en el nuevo servicio. Hoy por hoy ni me lo planteo.
  2. La interfaz de usuario del producto, tanto de la versión «Modern» como la versión para Windows Phone, es liosa, innecesariamente compleja y dificulta la creación de listas, la búsqueda ágil de canciones, grupos o álbumes. Me horroriza, vamos. A pesar de que la interfaz de Spotify para Windows Phone también deja mucho que desear, la prefiero sin duda.

Quizá cuando mejoren la interfaz ostensiblemente, me den más control sobre qué cosas exactamente quiero sincronizar y con qué calidad, y quizá si baja el precio me podría plantear usar XBox Music. Mientras tanto, lo siento pero no.

Es una lástima que se cargaran tan rápido Zune. La aplicación de escritorio le daba cien vueltas a la aplicación «Modern» y a pesar de sus muchos defectos era mucho más fácil de manejar y más efectiva para clasificar tu música.

Quizá si tú no tienes la misma «base instalada» de música que yo y partes más de cero lo puedas probar y te resulte útil. Hoy por hoy para mi no lo es. Hasta tal punto que lo quité de los Live Tiles de mi teléfono, hasta que más adelante me di cuenta de que la necesitaría quiera o no y la tuve que volver a colocar. En breve explico por qué…

En cuanto a Nokia Music, también te deja ecuchar música gratis en Streaming

Spotify para Windows Phone 8

Por suerte existe Spotify para Windows Phone 8. Es gratuito pero para poder sacarle partido off-line necesitas disponer de una cuenta premium (que es el motivo por el que yo la tengo). Esto no es algo de WP8, sino que es necesario en cualquier plataforma móvil que utilices Spotify: o pagas o no hay música sin conexión.

Cuando intenté pasarme a Windows Phone 7.5 «Mango» durante unos meses, uno de los motivos que me llevó a dejar el teléfono y volverme a iPhone en exclusiva fue precisamente la mala calidad de la aplicación de Spotify. Aparte de dejarte colgado muchas veces con las listas off-line, que en ocasiones decía que no podía reproducir, tenía un problema gordísimo con el Bluetooth del coche, que es donde más lo utilizo: cada vez que detenías el coche y se desconectaba no volvía a funcionar por Bluetooth nunca más. La única forma de solucionarlo era reiniciando el teléfono. Un desastre que al final hacía que lo dejase de usar.

La nueva versión para Windows Phone 8 no es que haya mejorado una barbaridad, pero al menos lo más gordo sí lo ha solucionado. Cumple su cometido de manera muy justa, sobre todo si la comparas con la versión para otras plataformas móviles y especialmente con la versión de iPhone, pero tienes a mano todas tus listas y puedes reproducirlas off-line.

La interfaz es mucho menos intuitiva que la de iOS. Para meter una canción en la cola debes pulsar sobre ella durante un segundo y elegir «Añadir a la cola» (en iOS basta con deslizar el dedo horizontalmente y ya tienes todas las opciones), el cambio entre una vista y otra es muy complicado y debes pulsar «atrás» repetidas veces o acertarle con el dedo a un enanísimo botón de «Now playing» que apenas se ve y cuesta acertar. Un desaguisado total. Encima mientras reproduces no puedes ver los datos relacionados con el grupo o la lista completa de canciones de ese álbum. Tiene menos ajustes que en la versión para iOS. Y sobre todo, lo que más me disgusta, es que no hay forma de adelantar o darle para atrás a una canción durante unos segundos. En iOS basta con arrastrar el dedo sobre la línea temporal de la canción para moverte a donde quieras. En Windows Phone ni siquiera existe la opción de dejar pulsado el botón «Siguiente» un segundo para conseguir un «Fast forward» 🙁

Finalmente para acabar de rematarlo, en muchas ocasiones se da el mismo problema que tenía la versión para Windows Phone 7.5: al entrar en las listas de música sin conexión te dice que no están sincronizadas y no te deja escucharlas, aunque en realidad sí que lo estén. Lo bueno en este caso es que es fácil de solucionar: basta con abandonar completamente la aplicación dándole a la flecha de «Atrás»  del teléfono hasta que salgas por completo de la app, y luego volver a entrar y generalmente se arreglan, así que no te quedas tirado en un viaje largo, como ya me pasó con WP7.5 (para gran disgusto y cabreo).

También consume en mi opinión mucha más batería de lo que debiera, sobre todo si lo comparas con el programa nativo de música que puedes usar durante bastante tiempo sin que apenas baje la batería nada.

He de decir que todo esto es culpa de Spotify, no del sistema operativo, y es una pena que no se tomen más en serio a los clientes de plataformas menos extendidas como WP8.

Aún así, al menos, no tengo grandes problemas para disfrutar de mi música favorita en el teléfono, por lo que le podemos dar un suficiente. Eso sí, la gente de Spotify debería ponerse las pilas y hacer un cabio radical en la calidad de sus desarrollos para Windows Phone 8 si valoran en algo a la gente que pagamos religiosamente sus servicios todos los meses.

Podcasts

Esta parte sí que me resulta especialmente surrealista.

El Nokia Lumia 920 que tengo actualmente lo estrené mientras estaba en EEUU. Una de las primeras cosas que hice fue suscribirme en XBox Music a los principales Podcasts que sigo. Estaba muy satisfecho porque estaban todos: no tuve que echar de menos ningún Podcast que tuviera en el iPhone y que no estuviese para Windows Phone 8, así que genial.

El problema es que en España no funcionan.

Al empezar a usar el móvil en España descubrí con desagrado que no se me sincronizaban nuevos números de los podcast a los que estaba suscrito. En algunos casos me decía que no había nuevos números cuando yo sabía perfectamente que no era así, y en otros casos se sincronizaban números antiquísimos, de hace más de un año y que obviamente no me interesaban nada. Lo más sorprendente es que además ya no tenía la categoría «Podcasts» en la tienda del teléfono, y no podía buscar nuevos a los que suscribirme como ya había hecho antes.

Al principio pensé que era un problema de mi configuración, que quizá había marcado mal alguna opción o algo. Pero luego descubrí que el problema era otro:

PodcastsOnlyUS

Según se indica en la propia página de Microsoft sobre cómo obtener podcasts, éstos sólo están disponibles en los EEUU 🙁

Pero ¿por qué? Imagino que será por algún problema de licencias, pero no me lo explico ya que el 99% de los podcasts son gratuitos y estoy seguro de que sus autores estarían encantados de que Microsoft te dejara suscribirte en cualquier lugar del mundo. Es más: es paradójico porque algunos de los podcast que escucho son europeos (por ejemplo de música electrónica de países nórdicos u Holanda) y en USA los puedo escuchar pero en Europa no 🙁

La primera solución que se me ocurrió fue, obviamente, buscar alguna aplicación para escuchar Podcasts en la AppStore. Olvídalo. Las he probado literalmente todas. Y no hay ni una que se salve. O son muy malas o no reproducen off-line. Y la mayoría fallan como una escopeta de feria, por lo que no he encontrado ninguna opción viable (menos mal que las de pago las dejan probar primero). Quizá la más decente pero que tampoco he conseguido que funcione apropiadamente sea «Podcasts!», pero no he conseguido que me guarde los podcasts para reproducción off-line. Una desgracia.

¿Cómo lo podemos solucionar?

La solución te la da la propia Microsoft, pero vas a flipar: ¡te arrojan directamente en los brazos de la competencia diciéndote que uses iTunes y sincronices!

WTF? Como lo oyes.

Lo más lamentable del asunto es que desde que con iOS 5 no era necesario iTunes para sincronizar el teléfono me libré con gran alegría de esa aberración del software que te imponía Apple. Y ahora, justo cuando llevaba años sin iTunes instalado, me veo obligado a instalarlo por culpa de Microsoft. Increíble.

Lo bueno es que la versión más reciente de iTunes es mucho mejor que las horribles versiones que tenían antes, y se la ve mucho más ligera.

Así que lo que tienes que hacer para disfrutar de tus Podcast favoritos en tu Windows Phone 8 es:

  1. Instalar Apple iTunes en tu equipo de sobremesa o portátil.
  2. Suscribirte en iTunes a tus podcast favoritos y mantenerlos sincronizados.
  3. Instalar el software de sincronización de Windows Phone 8 (que por cierto aún sigue en «Preview» cinco meses después de lanzar la plataforma. Microsoft, ¿a qué esperas para ponerte las pilas?).
  4. Elegir la opción de sincronizar con iTunes y marcar sincronización de los Podcast.
  5. Conectar el teléfono al ordenador de vez en cuando y ejecutar la aplicación anterior para que sincronice.
  6. Escucha los podcasts desde el apartado «Podcasts» de la aplicación de música nativa del teléfono.

La mayor pega es que ahora tengo que ser disciplinado y conectar de vez en cuando el teléfono al ordenador para sincronizarlo, en lugar de recibir los nuevos podcast directamente por Wifi. Si estoy de viaje y no tengo mi ordenador a mano, me quedo sin actualizaciones.

Además hay otra pega menor: no se visualizan las carátulas de los podcast, por lo que todos tienen el mismo aspecto, que es un rectángulo gris, y cuesta distinguirlos de un golpe de vista cuando los abres rápido. Además en la app de podcasts de iOS los podcast podían ir cambiando la carátula a medida que avanzaban, mostrando por ejemplo la canción actual o información adicional sobre ésta, algo que de lo que carece la aplicación de música de WP8, ni siquiera cuando estás en EEUU y te bajas los podcast por wifi (que si muestran la carátula, pero no cambia).

En resumen: se pueden escuchar los podcast sin problema, pero no es sencillo ni directo. Una verdadera lástima que la hayan fastidiado en un detalles como este.

Radio FM

Los teléfonos con Windows Phone 7 tenían obligatoriamente que llevar un chip para radio FM de modo que con los cascos puestos se podía escuchar la radio fácilmente. En Windows Phone 8 el sistema operativo no soporta los sintonizadores de radio, así que da igual que tu teléfono lo tenga: es como si no existiera.

De hecho es curioso pero por lo visto los Lumia llevan todos integrado un sintonizador de radio, pero hoy por hoy da igual porque no está soportado. Sin embargo se ha revelado hace poco que Microsoft y Nokia están trabajando en una actualización que devolverá esta capacidad a los terminales.

A mi personalmente me da igual pues jamás he utilizado la radio en el móvil y de hecho, salvo para despertarme por las mañanas, nunca escucho la radio comercial. Pero me consta que para mucha gente sí es algo importante (sobre todo en páises en donde el 3G no es muy barato y además es lento por lo que escuchar música en streaming es prohibitivo), así que por eso lo comento aquí.

Detallitos tontos que molestan

Para terminar, y dado que estoy «rajando» de lo lindo sobre este aspecto del teléfono, voy a comentar algunas cosas relacionadas que me molestan bastante y que se deberían mejorar:

  • Volumen con el control integrado de los auriculares: Tengo unos auriculares (de los de introducir en el oído) muy buenos Sennheiser que llevan integrados los controles de reproducción en el cable. Desde ese control puedo pausar o retomar la reproducción, moverme hacia adelante o hacia atrás, coger una llamada y hablar si me llaman o incluso lanzar un reto vocal para hacer una llamada. Es súper útil cuando vas por la calle caminando ya que así no tienes que sacar el teléfono para nada. Todo esto funciona muy bien con el Lumia 920. Sin embargo a pesar de que los auriculares tienen dos botones específicos para controlar el volumen, el Lumia hace caso omiso de ellos por lo que siempre debes recurrir a los botones hardware para cambiarlo. En iPhone funcionan perfectamente, así que entiendo que el sistema operativo de Microsoft es el que no recoge la señal apropiada y actúa en consecuencia. Parece algo muy fácil de hacer, así que imagino que o bien se les ha «escapado» el detalle o hay por el medio algún tipo de patente o licencia y no pueden hacerlo. En cualquier caso  es un detalle molesto.
  • Whatsapp como aplicación musical: cada vez que abres Whatsapp para ver un mensaje considera que el servicio de mensajería es un programa multimedia y te pone en la aplicación «Musica» a Whatsapp como canción actualmente en reproducción («Now paying». WTF?
  • Pérdida de punto actual al cabo de un rato: si estás escuchando música y detienes la reproducción cerrando la aplicación, al cabo de un rato (no sé decir cuánto, dependerá supongo de la memoria libre y cosas por el estilo) el sistema operativo lo cierra y no puedes simplemente darle al volumen para que salgan los controles multimedia y pulsar el «Play». Ello te obliga a abrir de nuevo el programa y reanudar desde él la reproducción. Si elprograma está mal hecho como es el caso de Spotify significa que además pierdes la lista de reproducción que tuvieras y vuelves a empezar con una nueva 🙁
  • No poder usar los altavoces para iPhone: esto no es culpa de MIcrosoft, sino de Apple. Yo ya tenía una cierta inversión hecha en altavoces base para iPhone, de modo que llegaba a casa y ponía el teléfono en la base y podía escuchar música con una altísima calidad, y al mismo tiempo se me cargaba el móvil. Sensacional. El caso es que como todos estos aparatos llevan el conector alargado de iPohne y están pensados para este teléfono, ahora no puedo sacarles el mismo partido y tengo que pinchar el teléfono con un cable de audio normal, al auxiliar. En uno de los dos que tengo (un Phillips de menor calidad) no puedo conseguir un volumen tan alto como con el iPhone y en el otro (un JBL bueno y bastante caro), no puedo usar el mando a distancia para controlar la reproducción, teniendo que ir y hacerlo con el teléfono. En ninguno de los dos casos puedo cargar el móvil con la base. Claro que si me hubiera cambiado a un iPhone 5 me pasaría lo mismo puesto que le han cambiado el conector (ahí los de Apple la han fastidiado pero bien). Insisto, no es culpa del teléfono, pero es algo que ha cambiado para peor al cambiarme al Lumia 920.

Una par de cosas buenas a destacar

No todas van a ser cosas malas. También las hay buenas:

  • Los altavoces: los altavoces integrados del Lumia 920 están muy bien. Evidentemente no son como los de un equipo Hi-Fi, pero hacen muy bien su función. Desde luego infinitamente mejor que los de un iPhone. Para empezar son estéreo (en iPhone es un único altavoz mono) pero es que además son capaces de dar una potencia sonora decente. De hecho, por ejemplo, los puedes llevar puestos con el teléfono en el salpicadero del coche para escuchar música por la autopista sin que te moleste el ruido y puedas tener una experiencia decente aunque no tengas bluetooth. Con el iPhone eso es imposible pues el ruido de los neumáticos en el asfalto a alta velocidad o la lluvia no te dejan oír casi nada. En eso he ganado mucho pues en mi coche «grande» de salir de la ciudad no tengo Bluetooth y no podía escuchar música con el iPhone.´
  • Actúa como disco duro externo: cuando pinchas el iPhone al ordenador lo único que puedes hacer es leer las fotos que tengas dentro, pero nada más y mucho menos copiar algo al teléfono. Con Windows Phone 8 el teléfono actúa como un disco duro USB normal por lo que si quieres copiar en él música directamente en un formato soportado (MP3, WMA) sólo tienes que arrastrarlo. De hecho puedes arrastar cualquier tipo de archivo, incluso de Office, para verlo con la aplicación apropiada. Esto es una gran ventaja.

En resumen

Aunque estoy muy contento con Windows Phone 8 en el apartado de la música se limita a cumplir mis requisitos por los pelos y es la parte que menos contento me tiene. Necesita mejorar sustancialmente, aunque no todo depende de Microsoft (Spotify, ¿me estás oyendo?).

Con el Lumia 920 no tengo problema para escuchar la música de la manera a la que estaba acostumbrado, pero me da más trabajo (sobre todo con los Podcasts) y tiene algunos inconvenientes respecto al iPhone. Todavía tienen que mejorar bastante y esperemos que lo hagan en los próximos meses.

¡Espero que te resulte útil!

MVP por décimo año consecutivo

Post original en JASoft.org: http://www.jasoft.org/Blog/post/MVP-por-decimo-ano-consecutivo.aspx

mvpBueno, generalmente no suelo poner estas cosas, pero esta vez me hace especial ilusión: por décimo año consecutivo Microsoft Corporation me ha reconocido como Most valuable Professional (MVP) en tecnologías Web.

Me hace especial ilusión porque llevo 10 años siéndolo (desde 2004), y ya se ha convertido casi en un estilo de vida. Ser MVP me ayuda a tener un aliciente para mantenerme al día, para escribir este blog y para crecer profesionalmente. Me ha dado oportunidad de viajar a muchos sitios y de conocer a gente estupenda.

Y es que ya sé que suena a tópico, pero realmente si me he de quedar con algo de estos diez años es la cantidad de gente extraordinaria que he tenido la oportunidad de conocer:

  • Otros MVP: y es que, hay de todo, pero la mayoría son gente verdaderamente excepcional tanto en lo técnico (por supuesto) como en lo personal, ya que ambas cosas suelen ir unidas de manera indisociable.
  • Gente de Microsoft: otro grupo de gente sensacional. La mayoría son también unos fenómenos en lo suyo y además buena gente, tanto en España como algunos españoles que están en EEUU.

No quiero nombrar a nadie más de ninguno de los dos grupos porque no quiero cometer el desliz de olvidarme de alguno, y es que ¡son muchos! Pero ellos lo saben perfectamente.

Eso sí, no quiero dejar la oportunidad de agradecer públicamente de manera especial a Cristina González Herrero su constante apoyo y dedicación. Cristina es la MVP Lead de España y Portugal, es decir, la persona encargada de relacionarse con los (pocos) MVPs que estamos en la península, la que nos sufre, nos escucha, nos lleva de un sitio a otro, organiza los "saraos", nos ayuda con cualquier cosa que nos pase… Y es que además de ser una "fenómena" profesionalmente y hablar no sé ya ni cuantos idiomas, es un amor de persona que está siempre ahí para lo que la necesites con una sonrisa.

¡Muchas gracias Cristina! Sin ti no seríamos lo mismo.