Mostrando entradas con la etiqueta programacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta programacion. Mostrar todas las entradas

Cómo optimizar la versión móvil de un sitio web

Hace algunos años, los teléfonos móviles eran accesorios comunes, pero sólo usados para realizar llamadas telefónicas. Pero a día de hoy, el tráfico que nuestras páginas web reciben de los teléfonos móviles no deja de incrementar, encontrándose ya a un nivel en que su importancia no puede pasarse por alto. Y con nuevas oportunidades surgen también nuevos desafíos – y preguntas.


Para facilitar las cosas, incluimos a continuación una lista de preguntas frecuentes, junto con sus respuestas, acerca de cómo optimizar las versiones sólo para móviles de sus páginas web, teniendo en cuenta tanto factores técnicos como de optimización en buscadores y experiencia de usuario.


¿Por qué puede tener sentido redirigir a una versión sólo para móviles?

El diseño web adaptativo presenta ciertas ventajas en comparación con crear una versión independiente y alternativa sólo para sus usuarios móviles:


  • El mantenimiento se simplifica. Incluso cuando la programación de páginas web adaptativas puede incrementar el nivel de complejidad, sólo sería necesario realizar modificaciones en un único sitio web. En cuanto a los contenidos se refiere, todos sus contenidos se encontrarían en un solo lugar, haciendo que fuera más sencillo expandir y actualizar su página simultáneamente para todo tipo de usuarios (tanto móviles como regulares.)

  • El SEO puede simplificarse. Presentar una única versión de su página web a todos sus usuarios, con los mismos contenidos (en general), evita tener que gestionar cómo se notifican ambas versiones a los motores de búsqueda, dejando bien claro cuál es la versión principal y cuál es aquella optimizada para móviles.

Diseño web adaptativo

No obstante, incluso cuando el diseño web adaptativo será probablemente la única tendencia que sobreviva en un futuro no muy lejano, crear una página web adaptativa en lugar de una página web alternativa optimizada sólo para móviles podría no ser la mejor opción si se dan unas circunstancias determinadas:


  • Presupuesto ajustado. Los diseños web adaptativos requieren un grado adicional de planificación previa, así como una fase de pruebas en la que se deben tener en cuenta múltiples dispositivos y resoluciones de pantalla, para todas las clases de contenido.

  • Teléfonos móviles antiguos. Si la mayor parte de sus usuarios aún utilizan smartphones de cierta antigüedad, pero quieren navegar en su página web en una versión móvil, entonces lo mejor será que dicha versión optimizada para móviles sea muy rápida y ligera, específicamente diseñada con la simplicidad y la velocidad como objetivos principales.

  • Compatibilidad con código antiguo. Si su página web ya disponía de una versión móvil, o si su página web sería difícilmente convertible en una página web adaptativa, entonces trabajar con la versión móvil existente tendría bastante sentido.

  • Consideraciones del contexto. Los objetivos de sus usuarios, mientras se desplazan y utilizan sus teléfonos móviles, pueden ser bastante distintos de los objetivos de otros usuarios que accedan a su página web desde un ordenador de sobremesa. Hay algunas restricciones adicionales acerca de la interfaz y del contexto en que están utilizando sus navegadores que también influirán en lo que debería mostrárseles: escribir en una pequeña pantalla táctil mientras se anda por la calle es francamente complicado, con lo que sus formularios online resultarían bastante inútiles; leer en una pequeña pantalla móvil puede hacer que sus páginas, largas y detalladas, se conviertan en abrumadores chorros de texto inmanejables en un dispositivo móvil.

Si su situación es la contemplada en uno de los escenarios anteriormente mencionados, entonces lo más recomendable es que utilice una versión para móviles, separada de las páginas web de su sitio principal, y que optimice esta versión móvil tanto como sea posible. Esto quiere decir que:


  • Siempre mostrará contenido fácil de navegar a sus usuarios.

  • Sus páginas serán fácilmente indexables para los motores de búsqueda.

  • Su versión móvil no competirá con su página web principal, canibalizando sus resultados de búsqueda.

A continuación se presentan otras preguntas frecuentes acerca de cómo optimizar el rendimiento de la versión móvil de una página web.


¿Debería mostrar contenidos originales y optimizados para móviles en la misma URL, o redirigirlos a una URL distinta, sólo para móviles?

Existen dos enfoques para servir contenido optimizado para móviles a los usuarios de su página web: mantenerlos en la URL original, pero ofreciéndoles un contenido distinto, optimizado para móviles, o bien redirigirlos a una URL distinta en que podrían acceder a contenidos optimizados para móviles.


Redirección URL móvil

El primer enfoque tiene una ventaja desde el punto de vista de la optimización en buscadores: todos los enlaces que apuntasen a una de sus versiones móviles también apuntarían a su versión principal, pasando directamente su ranking a las URLs principales, puesto que ambas serían coincidentes.


No obstante, este enfoque también conlleva algunos riesgos mayores. En caso de tener problemas con esta configuración, como no identificar claramente cuáles son sus contenidos móviles y cuáles sus contenidos originales (en general, más completos) de cara a los buscadores, puede llevar a los motores de búsqueda a pensar que está enviando únicamente contenido muy resumido a todos sus usuarios, o que está utilizando tácticas de optimización reprobables como la ocultación de contenidos o enmascaramiento de URL.


También podrían presentarse problemas de cara a cómo sus usuarios móviles interactuarían con su página web. Si la URL no proporcionara información adicional a sus usuarios acerca de en qué versión de su página web se encuentran, algunos de sus usuarios podrían pensar que ésa es la única versión de su página web (sobre todo, si careciera de un enlace de "visitar la versión original" o si este no fuera lo bastante visible.)


Ése es el motivo de que redirigir a una versión optimizada sólo para móviles tenga sentido, ya que puede resultar más sencillo trabajar con ella, resultando esta muy clara y bien organizada. Pero para ello tiene que asegurarse de que esa URL queda identificada como sólo para usuarios móviles de cara a los motores de búsqueda de Internet, marcada como una versión alternativa, que no compita con sus URLs principales en los resultados de búsqueda.


¿Debería crear versiones distintas para teléfonos móviles antiguos y smartphones de última generación?

Mientras que los smartphones de última generación vienen equipados con pantallas táctiles que ya no son tan pequeñas y con potentes procesadores, los teléfonos móviles tradicionales y los smartphones más antiguos pueden carecer de suficiente espacio en su pantalla, o de potencia suficiente en sus procesadores como para ofrecer una buena experiencia de navegación como para que navegar con ellos sea una experiencia lo bastante cómoda en la mayoría de sitios web.


La respuesta a esta pregunta depende de su negocio en particular. Sus estadísticas de navegación resultarán de gran ayuda a la hora de dar con la respuesta adecuada para su caso concreto. Las estadísticas de su servidor deberían darle detalles acerca de los dispositivos que los usuarios de su página web estén utilizando para acceder a ella. Si esa lista contuviera un porcentaje nada despreciable de usuarios utilizando teléfonos móviles antiguos, entonces crear una versión móvil específicamente optimizada para ellos tendría bastante sentido.


Sin embargo, los teléfonos móviles se encuentran en rápida evolución. Dependerá mucho de su mercado objetivo, y del país con el que esté haciendo la mayor parte de sus negocios, pero lo más probable es que los modelos obsoletos desaparezcan rápidamente, quedando sólo una generación de smartphones bastante más potentes, que se asemejarán bastante a pequeños ordenadores de sobremesa en cuanto a su capacidad de proceso se refiere. A causa de lo anterior, en el medio o no tan largo plazo, debería contemplar desarrollar su página web con ese tipo de smartphones en mente.


Móviles vs smartphones

Después de todo, esto es a lo que apunta la tendencia actual del diseño web adaptativo: en un futuro no tan lejano, las versiones móviles y las versiones pensadas para ordenadores de sobremesa sólo se diferenciarán en la forma en que coloquen en pantalla la información. Mientras tanto, disponer de una única versión alternativa para teléfonos móviles, que sea concisa, rápida de cargar y fácil de navegar, debería satisfacer sin problema las necesidades de sus usuarios móviles.


¿Cómo se marca una URL como una versión alternativa sólo para móviles?

etiquetar la versión móvil

Google recomienda etiquetar páginas que sean versiones alternativas para móviles siguiendo el planteamiento que se muestra a continuación:


  • La página original debería señalar que existe una versión optimizada para móviles en la que se puede acceder a contenido similar.

  • Las versiones optimizadas para móviles deberían apuntar a sus páginas web originales relacionadas, marcándolas como las páginas principales, como las URL canónicas.

El tamaño de pantalla se utiliza para distinguir a los dispositivos móviles, mientras que el tipo handheld se aplica para hacer referencia a modelos de teléfono móvil más antiguos. En el escenario más frecuente en que sólo se tiene una versión optimizada para móviles, estos indicadores serán etiquetas de enlaces alternativos que debería incluir en su versión original:


 <link rel="alternate" media="only screen and (max-width: 640px)" href="http://www.URLmovil" />
<link rel="alternate" media="handheld" href="http://www.URLmovil" />

Y este es el enlace canónico que debería incluir en su versión móvil:


<link rel="canonical" href="http://www.URLoriginal" />

También puede etiquetar las versiones para móviles dentro de su sitemap.xml, marcándolas como versiones alternativas de una página principal. Cada versión alternativa para móviles debería ser asociada con la página web original con la que se encuentra relacionada. Con lo que el sitemap de su sitio quedaría algo así:


<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>http://www.URLoriginal</loc>
<xhtml:link
    rel="alternate"
    media="only screen and (max-width: 640px)"
    href="http://www.URLmovil" />
</url>
</urlset>

Es importante asegurarse de que esté redirigiendo exactamente a la URL especificada en estas etiquetas alternativas, o podría estar enviando información confusa a los motores de búsqueda, con lo que podría arriesgarse de que marcasen a su página web como spam.


Si no hubiera una página web original que se correspondiese con una página específica de la versión móvil, ¿a dónde debería apuntar su etiqueta canónica?

Si su sitio web móvil no fuera un reflejo exacto de su sitio web original (es decir, si no tuviera una página web optimizada para móviles por cada una de las páginas web originales de su sitio web principal) entonces el enfoque más rápido sería también el más seguro: los sitios web móviles pequeños pueden redirigir todas sus páginas a la URL principal de la versión original de su página web, asegurándose de este modo de que todas las páginas web móviles de su sitio web ayudan a pasar pagerank a su página web principal.


URL canónica

Tenga en cuenta que, en un escenario ideal, todas y cada una de las páginas web de su sitio web se correspondería con una página web optimizada para móviles. Si no fuera así, se correría cierto riesgo de que marcadores de página guardados en un dispositivo concreto no llevasen al contenido esperado en otros dispositivos, o a otro casos que, en palabras de Google, serían redirecciones no relevantes — a menos que su página web ofrezca una solución muy concreta pensada en el contexto y segmento de mercado de sus usuarios móviles.


Actualización: en este artículo publicado por Google en su blog oficial, Changes in rankings of smartphone search results (cambios en los ranking de los resultados de búsqueda de los smartphones), Google actualizó lo que consideraría como una redirección no relevante. Según este informe, las páginas a las que se accediera desde un dispositivo móvil, y para las que no hubiera una versión específica optimizada para móvil, no deberían redireccionar a la página principal de su versión móvil, ya que eso sería considerado una redirección irrelevante a partir de ahora.


El enfoque recomendado para páginas que carecieran de versiones móviles consistiría en dejar al usuario acceder directamente a la versión original de la página, aunque no estuviera optimizada para móviles. El formato podría no estar optimizado, pero se garantizaría que el contenido al que el usuario accediera siguiera siendo tan relevante como fuera posible de acuerdo con su consulta de búsqueda original.


Aparte de esto, el enfoque subóptimo recomendado por Google consiste en tener una versión optimizada para móviles de todas y cada una de las páginas de su sitio web (lo que elimina por completo el riesgo de una redirección hacia contenido irrelevante). Mientras que el enfoque óptimo consistiría en utilizar un diseño web adaptativo en todo su sitio web, con una única versión que se vería de una forma adecuada en todo dispositivo posible.


¿Cómo puede detectar a los usuarios que acceden desde móviles para enviarles contenidos distintos?

Los navegadores de los móviles se identifican a sí mismos mediante sus user agents cuando solicitan la carga de una página. Discriminando según sus user agent puede enviarles contenidos distintos, o redirigirlos a una página web apropiada.


No necesita crear un listado completo de user agents desde cero. Ya existen fragmentos de código que se encargarán de eso por usted. Detectmobilebrowsers.com es un conjunto de programas de código abierto que se encarga precisamente de eso, ofreciendo fragmentos de código que funcionan en muy diversos lenguajes de programación (código para servidores Apache, Javascript, ASP, PHP, etc.)


Detectar dispositivos móviles

Tenga cuidado con esta táctica, puesto que en el futuro pueden surgir nuevos dispositivos móviles. Existe una posibilidad de que el código que utilice para detectar dispositivos móviles se quede desactualizado y que no clasifique ciertos dispositivos dentro de la categoría correcta. Así que, asegúrese de que mantiene actualizadas sus reglas de detección.


¿Debería redirigir al rastreador móvil de Google considerándolo específicamente en su código de redirección?

Aparte del indexador de páginas web convencional, Google también tiene un rastreador web para webs móviles, Googlebot-mobile, independiente del Googlebot tradicional. Así que tendría sentido que este rastreador móvil accediese a la versión optimizada para móviles de su página web.


Rastreador para indexar versión móvil

Sin embargo, Googlebot-mobile se presenta a sí mismo usando el user agent de smartphones populares. No tiene que considerar a Googlebot-mobile como un caso de redirección específico en el código de detección de navegador que esté usando. Google advierte que discriminar específicamente el rastreador móvil puede considerarse ocultación de URLs, lo que le podría acarrear una penalización a su rendimiento en los motores de búsqueda.


¿Redirección en el servidor o redirección mediante Javascript?

Existen un par de enfoques distintos a la hora de redireccionar a sus usuarios móviles hacia la versión optimizada para móviles. Puede realizar las comprobaciones apropiadas del user agent dentro del propio navegador web de su usuario utilizando una redirección Javascript. O puede utilizar en su lugar redirección en el propio servidor web, de manera que sería este servidor quien comprobase el user agent del dispositivo que le solicita una página web (directamente en el código del servidor utilizando reglas .htaccess en el caso de Apache, o en un lenguaje de programación que se ejecute en el servidor, como .NET, PHP, Ruby o similares).


Redirección Javascript Redirección desde el servidor

El problema con una redirección Javascript es que parte de su página web original debería cargarse antes de que su usuario móvil fuera redirigido a la versión adecuada. Por otra parte, una redirección que tuviera lugar en el propio servidor dejaría para el servidor las comprobaciones y proceso relacionado con la redirección, evitando además la carga de contenido innecesario por parte de su usuario móvil.


Teniendo en cuenta que los usuarios móviles disponen de escaso ancho de banda y de capacidad de proceso limitada, las redirecciones que se realizan en el servidor son el enfoque más adecuado puesto que resultarán bastante más rápidas para sus usuarios.


¿Redirección permanente 301 o redirección temporal 302?

Existen dos tipos principales distintos de redirecciones que se envían como respuesta del servidor a modo de cabeceras HTTP específicas:


  • Una redirección 301 es una redirección permanente, que indica que la URL original ya no estará activa, con lo que todas las consultas deberían redirigirse ya a la nueva URL especificada.

  • Una redirección 302 es una redirección temporal, la cual simplemente señaliza que las visitas a la URL original deben dirigirse de momento a la URL especificada, pero que se trata sólo de una situación temporal que se devolverá a su estado original en el futuro.

Si utiliza cabeceras de repuesta para redirigir a sus usuarios móviles hacia la versión móvil adecuada, en las propias palabras de Google:


Para este propósito, no importa si el servidor redirige con un código de estado HTTP 301 o con un código de estado 302.

Así que no importa qué tipo de redirección se utilice para enviar a sus usuarios móviles hacia su versión optimizada para móviles.


Redirección temporal 302

Sin embargo, consideremos un escenario correspondiente al caso peor. Si hubiera alguna configuración inadecuada o problema en el proceso, según el cual los motores de búsqueda no entendieran adecuadamente cuál es la versión principal de su página web, y cuál es la versión optimizada para móviles, entonces utilizar redirecciones permanentes 301 desde su versión original hacia su versión móvil enviaría la mayor parte de su pagerank, tráfico o, en definitiva, usuarios, hacia una versión diseñada como alternativa, más sencilla, optimizada sólo para móviles. Un escenario como tal podría tener consecuencias desastrosas para su versión principal, y por tanto, para su estrategia de optimización en buscadores.


Ese es el motivo de que utilizar una redirección temporal 302 que apunte hacia su versión móvil sea una estrategia más adecuada en términos de prevención de posibles riesgos.


¿Debería inclur una cabecera HTTP Vary en sus URL móviles?

Google menciona como parte de sus directrices para móviles que, en caso de que use cualquier tipo de redirección, cualquier página que esté redirigiendo hacia otra debería incluir una cabecera HTTP Vary para notificar a potenciales rastreadores móviles que explorar esas páginas simulando ser un dispositivo móvil tendría sentido, puesto que distintos dispositivos verían resultados distintos. De ese modo, Google indexaría todas sus páginas móviles, entendiendo mejor la estructura de su página web.


Esto es también cierto para las páginas web que utilizan la misma URL para enviar tanto contenido optimizado para móviles como el contenido principal pensado para el resto de sus usuarios (lo que normalmente se conoce como dynamic serving o envío dinámico). En este caso, utilizar la cabecera Vary se convierte en algo incluso más importante, puesto que los buscadores no dispondrían de ninguna otra forma de saber si existe una versión móvil para la página actual (al encontrarse todas las versiones bajo la misma URL.) También debería asegurarse de que la versión optimizada para móviles no fuera considerada como contenido oculto o enmascarado, o que el contenido de la versión móvil fuera confundido con el contenido de su versión principal. Anunciar diferencias de contenido según el navegador del usuario le vendría muy bien para aclarar estos posibles escenarios.


Cabecera Vary

La cabecera Vary debería enviarse indicando que los contenidos de esa página pueden variar dependiendo del user-agent, con lo que ése debería ser precisamente su valor:


Vary: User-Agent

¿Debería incluir en su versión móvil un enlace que apuntase a su versión principal?

Definitivamente. Algunos de sus usuarios aún querrán acceder a los contenidos completos de su versión principal si tienen la sensación de que no están viendo todos los contenidos de que podrían, y de que su smartphone de última generación podría ser lo bastante potente como para navegar sin problema en la versión principal de su página web.


Si su versión optimizada para móviles fuera lo bastante corta y sencilla (como debería ser), entonces debería incluirse un enlace que apuntase al artículo original relacionado de la versión principal, hacia el final de la página: no habría necesidad de ir hacia la versión regular de la página web si la versión móvil ya facilitase suficiente información por sí misma. No es habitual que un usuario móvil decida ir a la versión principal de una página web nada más aterrizar en dicha versión móvil.


Enlace normal

Sin embargo, asegúrese de mostrar este enlace de una forma fácil de ver para sus usuarios. Es verdaderamente importante que haga saber a sus usuarios que existe una versión distinta, potencialmente más completa y vistosa, que también podrían visitar si así lo quisieran.


Esto se vuelve especialmente crítico si sus contenidos optimizados para móviles se proporcionan desde la misma URL que utilizaría para mostrar sus contenidos originales, ya que en este caso ni siquiera la URL daría alguna pista acerca de la existencia de otra versión normal, no optimizada para móviles.


¿A qué punto concreto de la versión normal debería enlazar cada página de la versión móvil?

En un escenario ideal en que cada página de la versión original tuviera asociada una página optimizada para móviles, los enlaces que llevasen a la versión original desde las páginas móviles deberían precisamente apuntar a la página relacionada correspondiente, la cual hablará de un tema similar y presentará también un contenido similar.


Ahora bien: la situación puede ser algo más delicada si la parte de su sitio web optimizada para móviles sólo comprendiera un subconjunto del contenido total de la versión original. Este escenario puede tener sentido si lo que busca es ofrecer a sus usuarios una versión móvil simplificada y directa, que fuera adecuada para el segmento de mercado representado por sus usuarios móviles.


Si no hubiera una página web asociada, entonces el modo más adecuado de enlazar a la versión completa original sería apuntar a la página de inicio de su sitio web. Puesto que esta página de inicio resulta el punto de entrada más adecuado para cualquier otra sección de su sitio web, esto debería facilitar las cosas a la hora de encontrar información relevante o ampliada acerca de lo que se estaba consultando.


Enlace móvil

Sin embargo, eso no sería suficiente. Tenga en cuenta el caso siguiente: un usuario realiza una búsqueda utilizando su teléfono móvil, pulsa en un resultado de búsqueda concreto, y es entonces redirigido a la página principal de su versión móvil, en lugar de ir a la página concreta de la versión original que inicialmente eligió. Puede que no haya ningún problema con esto si su usuario móvil aprecia la facilidad y velocidad de navegación en su versión móvil, asumiendo también que encuentre información relacionada con sus intereses y objetivos iniciales. Pero, ¿qué sucede cuando este usuario no encuentra la respuesta que buscaba a su consulta inicial, y pensase que su smartphone sí sería capaz de navegar en la versión completa original de su página web, en lugar de tener que verse restringido a los contenidos de la versión para móviles? Enviarlo de vuelta a la página de inicio de la versión original sería una barrera de uso para él, actuando como un paso intermedio innecesario.


Por eso debería ofrecer también como parte de su versión móvil un enlace a la página que sus usuarios intentaban visitar inicialmente, y desde la que fueron redirigidos a la versión móvil de su sitio web.


Técnicamente, esto se consigue anotando la dirección de la página donde comenzó el proceso de redirección (por ejemplo, utilizando un parámetro, una cookie o una variable de sesión). Los usuarios móviles que prefieran la facilidad de uso de la versión optimizada para móviles permanecerán ahí sin problema alguno. Y los usuarios móviles que quieran consultar los contenidos originales, hacia los que debería haber dirigido su clic inicial, aún tendrían la opción de consultar exactamente lo que captó su atención en los resultados de búsqueda, sin más que pulsar este enlace adicional.


¿Cómo se puede permitir navegar la versión normal a los usuarios móviles si se está redirigiendo

Los usuarios móviles deberían ser redirigidos hacia la versión optimizada para móviles de su página web. Por lo tanto, cuando uno de sus usuarios móviles prefiera navegar la versión completa de su página web en lugar de la versión optimizada para móviles, porque considere que su smartphone será lo bastante potente como para manejarla sin problema, y pulse sobre un enlace que lleve a su versión original, ¿cómo puede prevenirse que sea redireccionado de nuevo desde la versión original a la versión optimizada para móviles, en un bucle infinito?


Uno de los enfoques más directos para resolver este problema consiste en añadir un parámetro adicional para que no se lleve a cabo esta redirección en el caso de estos usuarios que explícitamente solicitan visitar la versión original desde su teléfono móvil. Añadir un simple parámetro en la URL destino debería bastar. La página web objetivo, parte de la versión original de su sitio web, debería comprobar si la petición original contuviera este parámetro adicional. En caso de encontrarse este parámetro, no se llevaría a cabo redirección alguna, permitiendo a su usuario móvil navegar la versión original de la página.


Guardar preferencias móviles

No obstante, eso puede no ser suficiente. Ese mismo usuario podría querer seguir navegando a otras secciones dentro de la versión original de su página web. Por ello guardar el parámetro que actúa como indicador de que las redirecciones a la versión móvil deben ignorarse en este caso se convierte en algo esencial. Si no se mantuviera ese parámetro, cuando su usuario móvil pulsase un enlace dentro de la versión original, podría se redirigido de nuevo a la versión móvil, que ya había decidido explícitamente no usar.


Así que una vez que se solicite navegar la versión original de la página desde un dispositivo móvil mediante la inclusión de un parámetro adicional como parte de la URL, esta preferencia del usuario debería ser guardada dentro de una cookie, por ejemplo, o incluso dentro de una variable de sesión. Con lo que ése usuario concreto no tendrá que preocuparse acerca de ser redireccionado a la versión móvil de nuevo - al menos, durante esa sesión de navegación.


Estableciendo así una cookie o variable de sesión para ese usuario se evitaría que cualquier página redirigiera en modo alguno a ese usuario móvil.


Por lo tanto, este usuario aún podría volver a la versión móvil siempre que quisiera - no a través de una redirección automática, sino pulsado el botón “atrás” de su navegador web. Este escenario no es muy habitual, pero aún puede darse si el usuario móvil se da cuenta de que su versión original no resulta cómoda de navegar en su teléfono móvil, después de todo. Pero incluso tratándose de un caso no habitual, también conviene estar cubierto para garantizar una experiencia de usuario óptima en todo caso.


¿Se debe redirigir hacia la versión normal a los usuarios de ordenadores de sobremesa que intenten entrar en la versión móvil?

Este es el caso que Google llama redirecciones bidireccionales. La ventaja de este enfoque es que impediría que sus usuarios de ordenadores de sobremesa acabasen por error en una página optimizada para móviles, la cual, dentro de sus pantallas más grandes, podría parecer bastante limitada o vacía, y por lo tanto, podría no causar una primera impresión adecuada.


Si está seguro de que la detección de los navegadores móviles que realiza su sitio web está actualizada y no comete errores, entonces estas redirecciones bidireccionales pueden tener sentido. Resultaría muy extraño que un usuario de un ordenador de sobremesa prefiriera ver una versión móvil, más limitada o incompleta, en lugar de navegar en la versión completa y original de su página web.


Redirigir usuarios de PC

Por otra parte, algunos usuarios de teléfonos móviles aún podrían estar interesados en navegar la versión completa de su sitio web. Y es aquí donde ese enlace desde la versión móvil hacia la versión original resultaría de utilidad, quedando todo posible caso cubierto.


El único inconveniente de las redirecciones bidireccionales es que resulta de vital importancia asegurarse de que la redirección funciona perfectamente. En caso contrario, podría dejar a sus usuarios bloqueados dentro de un bucle de redirecciones.


¿Se deben considerar los navegadores de las tabletas como navegadores móviles?

Las tabletas tienen unos cuantos puntos en común con los móviles: proporcionan cierta movilidad a sus usuarios, disponen de pantallas táctiles que no tienen por qué ser demasiado grandes, y tienen menos capacidad de proceso que los ordenadores de sobremesa.


Dicho esto, lo cierto es que la mayor parte de tabletas modernas ya permiten navegar en páginas web normales sin ningún tipo de problema. Su capacidad de proceso es suficiente como para poder manejar páginas web normales, y sus pantallas (incluso las menores, de unas 7 pulgadas) ya son lo bastante grandes como para proporcionar un nivel decente de legibilidad en cualquier página web.


Usuarios de tabletas

Es por ello que sugiero no tratar a las tabletas como si fueran teléfonos móviles, y por tanto, excluirlas del código de detección de user agent móviles.


No obstante, sí que es posible dirigir a los usuarios de tabletas a su versión optimizada para móviles. Esto puede tener sentido en el caso de que su versión original no ofrezca una experiencia demasiado optimizada para tabletas (si tardase mucho en cargar, si tuviera contenido en Flash que no funcionaría en los iPad, o si estuviera principalmente dirigida a un segmento de mercado en que no englobaría a los usuarios de tabletas).


Si está usando el código de detección de navegadores previamente mencionado, detectmobilebrowsers.com, sólo tendría que añadir el siguiente código a la primera expresión regular para tratar a los iPads, Kindle Fire, Playbooks y tabletas Android como si fueran parte del conjunto de dispositivos móviles:


|android|ipad|playbook|silk

¿Cómo cerrar varios procesos a la vez de manera automática con un .BAT?

Antes, unas aclaraciones básicas acerca de cerrar procesos, para los nuevos en la materia. Como ya adelantamos en el post de Cerrar y eliminar procesos, de TripleClic.

Si queremos saber qué es cada proceso, podemos consultar infoprocesos.com (español) o liutilities.com (inglés).


Cerrar procesos en Windows XP.



Para cerrar procesos accedemos al Administrador de Tareas, pulsando Control+Alt+Suprimir, o Clic con el Botón Derecho del Ratón sobre la Barra de Tareas de Windows / Administrador de Tareas.

Ahí tenemos varias pestañas, las que nos interesan son:

- Aplicaciones: Son las que tenemos abiertas y "normalmente" se están mostrando en la Barra de Tareas. Para cerrar una, Clic en "Finalizar Tarea" y Sí/Aceptar.

- Procesos: Estos son los procesos que el sistema tiene cargados, tanto los visibles como los no visibles o en segundo plano, inclusive los iconos de "Systray" (abajo a la derecha, donde el relojito y el altavoz). Para cerrar uno, seleccionarlo y Clic en "Terminar proceso" Y Sí/Aceptar.

Si queremos reabrir un proceso que hemos terminado manualmente, sin necesidad de reiniciar, podemos acceder al Administrador de Tareas, y hacer Clic en Archivo / Nueva Tarea (Ejecutar...) , si el proceso es de sistema y está en la carpeta system32 de Windows, vale con volver a poner su nombre sin necesidad del .exe Si no lo abre o es un proceso ubicado en otro sitio, damos a Examinar, y lo buscamos manualmente. Sino, pues reiniciamos.

Los procesos son cerrados sólo hasta que reiniciemos el ordenador, después se volverán a cargar automáticamente. Si queremos cerrarlos para siempre, leer el siguiente punto.


Cerrar procesos permanentemente / desactivar cargar al inicio.



Para deshabilitar permanentemente un proceso y que no vuelva a ser cargado al reiniciar (como algunos molestos e innecesarios iconos en la barra "Systray"), hacemos lo siguiente (tal y como muestra esta imagen):

- En Inicio / Ejecutar (o el atajo de teclado "Windows+R"). Escribimos msconfig , eso nos abrirá la Utilidad de Configuración de Sistema.
- En la pestaña inicio de esta ventana, tenemos un listado de los procesos que cargarían al iniciar el sistema, marcados con una V los que cargarán. Desmarcamos los que deseamos que no vuelvan a cargar, Aceptamos y Reiniciamos el ordenador.
- Al reiniciar nos aparecerá este mensaje. Marcamos la casilla "No volver a mostrar este mensaje", y aceptamos.




Cerrar automáticamente procesos mediante un .BAT.



En ocasiones queremos cerrar muchos programas/procesos pero no queremos hacerlo permanentemente, ni manualmente uno a uno cada vez que queremos cerrarlo. Como por ejemplo puede ser una serie de programas que utilizamos ocasionalmente, y requieren sus procesos en sistema abiertos permanentemente, pero que cuando iniciamos el ordenador para otras cosas no los queremos tener ahí consumiendo recursos.

Para ello podemos crear un archivo .BAT que con sólo hacer doble clic en él, nos cierre aquellos que deseemos.

Abrimos el Bloc de Notas (Atajos: "Inicio/Ejecutar/notepad" o "Windows+R / notepad") y en él escribimos:


TASKKILL /IM "nombre del proceso" /F


Ejemplo:
TASKKILL /IM MSPAINT.EXE /F


"IM" es para determinar el nombre del proceso a cerrar, y "/F" es para forzarle a hacerlo.

Si queremos hacer un grupo de programas a cerrar, no tenemos más que repetir la línea con cada proceso, dentro del mismo archivo.


Ejemplo:
TASKKILL /IM MSPAINT.EXE /F
TASKKILL /IM NOTEPAD.EXE /F
TASKKILL /IM CALC.EXE /F


Cuando lo tengamos, damos a Archivo / Guardar como...

Y al final del nombre que le pongamos, añadimos la extensión .bat
Así creamos un archivo de Batman... no, así creamos un .BAT

En "Tipo", que por defecto viene Documentos de Texto (*.txt), seleccionamos Todos los Archivos, esto es muy importante, de lo contrario estaríamos simplemente creando un documento de texto llamado "loquesea.bat.txt", y eso no sirve.

Seleccionamos la codificación ANSI.

Damos a Guardar.




Por defecto nos crearía un archivo con un icono como este, dependiendo de la configuración de iconos de cada uno.

Ahora, cada vez que queramos cerrar todos esos procesos que hemos añadido, no tenemos más que hacer doble clic sobre ese archivo, y lo hace él sólo.

También podemos obtener un listado completo y detallado de los valores que se pueden añadir detrás de "TASKKILL" yendo a Inicio / Ejecutar (Windows+R), escribiendo cmd, y en la ventana que aparece, escribir: TASKKILL/?



Abrir procesos con .BAT


Si queremos reabrir todos los procesos que habíamos cerrado con el .BAT , sin necesidad de reiniciar, podemos hacer la operación inversa, que es crear otro .BAT (mismo proceso anterior) así:


START "Nombre" "C:\...ruta.exe"
START "Nombre" "C:\...ruta.exe"
START "Nombre" "C:\...ruta.exe"


En la ubicación del programa, no acepta nombres de carpeta con acentos.

Ejemplo:

START "Paint" "C:\WINDOWS\System32\mspaint.exe"
START "Bloc de Notas" "C:\WINDOWS\notepad.exe"
START "Calculadora" "C:\WINDOWS\System32\calc.exe"



NOTA: Este método también nos sirve para crearnos un .BAT para abrir de golpe las aplicaciones que más utilicemos (con el de "START"), y otro .BAT para cerrarlas (el de TASKKILL).

Experimentos Javascript en Google Chrome


Cuando se combina un navegador web que maneja Javascript rápidamente (como Chrome) con las nuevas capacidades que ofrecen las últimas versiones de HTML y CSS, más bibliotecas Javascript de código abierto y funciones avanzadas, entonces se obtienen páginas web basadas en Javascript que parecen programadas en Flash y ActionScript.


¿No se lo cree? Entonces eche un vistazo a esta página web de experimentos de Javascript en Chrome. A mí me ha sorprendido este experimento de pelotas en Javascript.

Cómo reordenar los campos de una tabla MySQL


La estructura de datos de cualquier aplicación es la parte más difícil de cambiar. Sin embargo, puesto que las nuevas necesidades surgen continuamente, añadir nuevas columnas a una base de datos MySQL existente es una tarea habitual.


Pero, ¿cómo reordenar las columnas de una tabla MySQL una vez que dichas nuevas columnas ya han sido creadas y añadidas a una tabla existente? Recolocar las columnas es una práctica recomendable para mantener visualmente juntos aquellos campos de la tabla MySQL que se encuentren fuertemente relacionados.


Normalmente prefiero realizar todas las tareas de gestión de bases de datos MySQL utilizando herramientas tales como phpMyAdmin. Sin embargo, no he encontrado ninguna opción de phpMyAdmin que permita cambiar el orden de las columnas existentes dentro de la estructura de la tabla.


Por suerte, sólo hay que ejecutar una instrucción MySQL muy fácil para especificar un nuevo orden de columnas:

ALTER table `nombre_tabla`
       MODIFY COLUMN `nombre_columna` tipo_datos
       AFTER `otra_columna`

Sólo hay que reemplazar los campos siguientes por los datos reales de la tabla MySQL reordenada:

  • nombre_tabla: el nombre de la tabla MySQL cuyo orden de campos modificar.

  • nombre_columna: el nombre de la columna de la tabla MySQL que se desea recolocar.

  • tipo_datos: el tipo de datos MySQL de la columna movida, como int, varchar(longitud), text, etc.

  • otra_columna: el nombre de la columna que estará justo antes de la nueva posición de la columna reordenada.


Ejemplo de cómo reordenar columnas en una tabla MySQL


He aquí un ejemplo con una consulta MySQL real para cambiar el orden de las columnas de una tabla. Supongamos que se desea mover la columna llamada "user_password" para que se coloque justo detrás de la columna llamada "user_name" y mantener así agrupadas estas columnas estrechamente relacionadas:


reordenar campos en mysql

ALTER table `registered_users`
       MODIFY COLUMN `user_password` varchar(25)
       AFTER `user_name`

Esto reordenará las columnas en la estructura actual de la tabla MySQL. No obstante, no alterará el orden de las filas (es decir, de los registros de datos actualmente almacenados en la tabla). Así pues, el orden de los datos contenidos en la base de datos no cambiará.


Es útil reordenar columnas de una tabla MySQL para mantener campos relacionados visualmente cerca y agrupados lógicamente. Sin embargo, recolocar la posición de las columnas en la estructura de la tabla apenas modificará las prestaciones o la velocidad de búsqueda en la base de datos MySQL.


Por otra parte, reordenar los datos almacenados (esto es, cambiar el orden de las filas o registros guardados en una tabla) es una tarea completamente distinta, la cual sí que puede optimizar (o impactar negativamente) en el rendimiento de las búsquedas en MySQL.

Cómo establecer auto incremento en SQL con phpMyAdmin


Una práctica habitual en la creación de bases de datos es establecer claves primarias (o Primary Keys, PKs) con la opción de auto incremento. De esta manera, no hay que preocuparse por especificar un valor numérico único de clave primaria cada vez que se inserte una nueva fila en la tabla.


Pese a que phpMyAdmin es una herramienta de gestión de bases de datos muy útil y fácil de usar, muchas verces oigo la pregunta de dónde especificar el auto incremento en phpMyAdmin. He aquí la solución:


En las últimas versiones de phpMyAdmin hay una nueva casilla llamada A_I. No hay más que marcar esta opción al crear o editar la columna de la tabla que contendrá la clave primaria, y ese campo numérico incrementará automáticamente su valor cada vez que se inserte una nueva fila.


Auto incremento en phpMyAdmin

Para comprobar que la propiedad de auto incremento se configuró correctamente, no hay más que mirar en la columna EXTRA dentro de las propiedades de la columna de la clave primaria de la tabla (tras haber seleccionado la tabla, y dentro de la sección de estructura, Structure). Si en extra aparece el texto auto_increment, la configuración del incremento automático fue exitosa.


Sin embargo, en versiones más antiguas de phpMyAdmin, el auto incremento se configuraba de forma diferente, editando directamente estas propiedades extra de la columna. La opción de auto_increment se encontraba dentro de un menú desplegable en la categoría EXTRA (la última columna en el menú de creación de campos).


Para poder acceder a este menú de edición de columnas de la tabla no hay más que hacer clic en el icono del lápiz en la fila de la estructura (dentro de la solapa Structure) que se corresponde con la columna de la tabla que se desea editar.


En cualquier caso, siempre se puede ejecutar una sencilla consulta SQL para actualizar el estado de la columna y habilitar el auto incremento. Desde phpMyAdmin sólo hay que seleccionar la solapa marcada como SQL y escribir una sentencia SQL como la siguiente:

ALTER TABLE `nombre_tabla`
    CHANGE `nombre_columna_pk` `nombre_columna_pk`
           INT(longitud_clave) NOT NULL AUTO_INCREMENT

Sólo hay que reemplazar "nombre_tabla" por el nombre de la tabla que se está editando, "nombre_columna_pk" por el nombre de la columna que contiene la clave primaria, y "longitud_clave" por la longitud del número usado como clave primaria (el valor por defecto para un entero, int, es la longitud 11).


Si necesita asegurarse de que el campo que se está auto-incrementando es de hecho la clave primaria de la tabla actual, se puede volver a asignar la clave primaria de la tabla pulsando en el icono de llave correspondiente a la fila del campo deseado.


Hay que tener en cuenta que sólo puede especificarse un campo con auto incremento por cada tabla en MySQL. Por otra parte, el incremento automático sólo tiene sentido con claves primarias numéricas, y sólo puede haber una clave primaria en cada tabla MySQL.


Por último, si lo que desea es cambiar el valor del auto incremento en phpMyAdmin (por ejemplo, para que el campo de auto incremento comience en un número concreto), sólo hay que seleccionar la solapa Operations (operaciones) en phpMyAdmin, y escribir en el campo llamado AUTO_INCREMENT el nuevo valor inicial del campo con auto incremento y guardar los cambios.

El problema de MySQL desactivado en XAMPP


Instalar XAMPP es una forma rápida de tener configurado y funcionando un servidor Apache con PHP y bases de datos MySQL.


Pero en ocasiones, debido a algún tipo de problema de configuración de MySQL, XAMPP da un error y no es posible arrancar el servicio MySQL. Si se comprueba el estado de las bases de datos utilizando el panel de control de XAMPP (status), se observará un mensaje de advertencia como el siguiente: "MySQL database DEACTIVATED" (base de datos MySQL DESACTIVADA).


Cómo activar MySQL en XAMPP en 2 pasos


Aunque no estoy seguro de las causas exactas de este error, hay un truco para repararlo rápidamente y activar MySQL en XAMPP con 2 pasos sencillos:

  • En primer lugar, no instale MySQL como un servicio de Windows que se arrancaría por defecto junto con el sistema operativo. Ésta es una opción durante la instalación de XAMPP: simplemente hay que dejar sin marcar la casilla de instalar las bases de datos MySQL como un servicio del sistema.

  • Finalmente, cree un archivo de configuración MySQL para la nueva instalación de MySQL (lo cual puede hacerse automáticamente con Win MySQL admin).

En efecto, existe una forma automática de generar un archivo de configuración MySQL básico usando las herramientas instaladas por defecto en XAMPP. Sólo hay que ir a la [carpeta de instalación de XAMPP] / mysql / bin y ejecutar winmysqladmin.exe. En el cuadro de diálogo habría que escribir un nuevo nombre de usuario y contraseña, y dejar que el programa de gestión de MySQL genere automáticamente el archivo de inicialización MySQL por defecto.


¡Y eso es todo! Con desactivar el arranque inicial de MySQL como servicio de Windows por defecto, y crearle un archivo de configuración MySQL por defecto, con un nombre de usuario y contraseña definidos, debería bastar para cambiar el estado de "MySQL database deactivated" a MySQL database ACTIVATED (base de datos MySQL ACTIVA).


Cómo comprobar el estado activo de MySQL


El estado de las bases de datos MySQL puede comprobarse abriendo el panel de control de XAMPP: el servicio de MySQL debería tener ahora una etiqueta verde al lado con el mensaje running (en ejecución).


Aunque Win MySQL Admin resultó útil para crear un archivo .ini básico, no es necesario seguir utilizando el programa una vez que el servicio MySQL está activo. Win MySQL Admin es una aplicación antigua y no actualizada, que además lanza a veces errores de Windows aleatorios.


Pero no hay problema: basta con cerrar la ventana de ese gestor de MySQL, y usar la aplicación phpMyAdmin que viene instalada por defecto dentro de XAMPP.


La prueba final consiste en abrir phpMyAdmin para comprobar el estado activo de las bases de datos MySQL.


Puede accederse a phpMyAdmin a través del menú principal del servidor Apache instalado con XAMPP. Es necesario arrancar el servidor Apache, abrir la página principal del servidor usando el navegador web (basta con escribir "localchost" en la barra de direcciones y con la configuración por defecto de XAMPP) y pulsar en el enlace a phpMyAdmin para comprobar que las bases de datos MySQL han pasado a estado activo.


Espero que estos trucos sean de ayuda para activar sus bases de datos MySQL en XAMPP, de modo que pueda aprovechar las ventajas que este paquete ofrece para programar y probar en local MySQL y PHP.

Correo en HTML con CSS: lista de compatibilidad


Es posible que alguna vez se haya visto en esta situación: después de diseñar y enviar un email maquetado con las técnicas más avanzadas de HTML y CSS ha podido comprobar que el cliente de correo de su destinatario rompe completamente el diseño del email.


Bien es cierto que enviar correos en texto plano no daría ningún problema. Pero, a día de hoy, no tiene sentido prescindir de todo elemento HTML dentro de un email sólo porque algunos clientes de correo dan problemas a la hora de representar cierto código HTML o CSS. La clave es saber qué HTML y CSS funciona en los principales clientes de correo.


Esta lista de compatibilidad de email es un recurso muy útil, especialmente porque propociona ejemplos gráficos con capturas de pantalla de cómo se vería un email de ejemplo en los principales clientes de correo. Además, la página se mantiene actualizada, de manera que tendrá en cuenta las últimas actualizaciones y mejoras de compatibilidad de dichos clientes de correo.


A día de hoy pueden verse unas cuantas conclusiones interesantes en esta lista, como por ejemplo que el cliente de correo de Gmail sólo lee estilos CSS inline: Gmail ignora el CSS incluido dentro de la cabecera (head), y elimina las clases CSS, así como los identificadores (ID) del contenido HTML original del correo.


Por cierto, si busca un cliente de correo fiable y gratuito para descargar sus email, me decantaría por Mozilla Thunderbird.


¿Existe HTML o CSS que funcione en todo cliente de correo?


La pregunta es: ¿cómo crear emails vistosos que funcionen en cualquier cliente de correo? Lo cierto es que, actualmente, los principales programas de lectura de email representan sin ningún problema tablas HTML, que incluso pueden tener un color de fondo definido inline.


Hasta sería posible incluir imágenes de fondo en muchos clientes de correo. Las imágenes tienen un gran potencial para mejorar el diseño del cuerpo principal del email. Sin embargo, no se debe depender por completo de las imágenes: la idea es diseñar correos que, en caso de ser mostrados con algún error, fallen de forma controlada. De esta manera, el email HTML seguiría siendo legible en cualquier cliente de correo.


Sin duda, CSS es el futuro del diseño web por sus virtudes de fácil mantenimiento del código, y flexibilidad para posicionar elementos HTML. No obstante, a la hora de enviar emails con HTML, puede ser mejor limitarse a un diseño más sencillo (aunque efectivo) en que el contenido del email sean tablas HTML


Email basados en tablas HTML

Mi consejo es utilizar tablas HTML en emails: la mayoría de los clientes de correo mostrarán un contenido basado en tablas HTML sin problema. Y no hay que perder de vista esta lista de compatibilidad de CSS en clientes de correo: puede que el día de email totalmente basados en CSS esté cerca.

Convertir vídeos de YouTube en alta calidad en 1 solo paso


¿Sabía que con sólo añadir &fmt=18 al final de una URL de un vídeo de YouTube podrá ver ese vídeo de YouTube en Alta Calidad?


He aquí un ejemplo de cómo sería una URL de un vídeo de YouTube en alta calidad:



http://www.youtube.com/watch?v=W6nppcKOYGo&fmt=18

¡Y eso es todo! Es así de fácil.


Análisis en detalle de la calidad del vídeo de Youtube: comparación de calidad de vídeo


Echemos un vistazo en detalle a cada uno de los 2 formatos de vídeo de YouTube, para comprobar cuánto mejora la calidad del vídeo de YouTube con sólo añadir &fmt=18:


Vídeo de YouTube de calidad normal:

  • Formato de Vídeo: Vídeo Flash (.flv).

  • Códec de Vídeo: FLV1.

  • Frames por segundo: 15 fps.

  • Resolución de vídeo: 320 x 240 píxels.

  • Audio del vídeo: MP3 a 22050 Hz

Vídeos de Alta Calidad en YouTube:

  • Formato de Vídeo: MPEG-4 (.mp4).

  • Códec de Vídeo: AVC1.

  • Frames por segundo: 29.97 fps (como en NTSC).

  • Resolución de vídeo: 480 x 360 píxels (¡un 50% mayor!).

  • Audio del vídeo: MP3 a 44100 Hz, 2 canales, 1411 kbps.

El vídeo de YouTube de alta calidad pesa aproximadamente el doble que el vídeo de calidad normal. Sin embargo, la mejora de la calidad final del vídeo merece la pena: las dimensiones reales de pantalla del vídeo son mucho mayores, la tasa de bits del vídeo es mucho más elevada, y visualmente, se observan muchos menos artefactos de compresión.


El formato de vídeo de Flash es probablemente el mejor formato de vídeo para optimizar consumo de ancho de banda. Sin embargo, el códec de vídeo MPEG-4 utilizado por YouTube hace un trabajo magnífico preservando la calidad del vídeo original.


¡Compruébelo usted mismo! He aquí un vídeo de YouTube en calidad normal, y aquí el mismo vídeo de YouTube en alta calidad.


Por desgracia, este truco aún no funciona para incrustar un vídeo de YouTube en alta resolución en un sitio web externo. Las buenas noticias son que nuestros viejos trucos para incrustar vídeo Flash de alta calidad siguen funcionando.


En definitiva, parece que YouTube ya está comenzando a aprovechar las ventajas de las rápidas redes modernas, y este &fmt=18 es un gran paso hacia un YouTube con vídeos en alta definición. ¡Quizá estemos muy cerca de un YouTube en Alta Calidad!.

Más que compresión: vídeo Flash con ancho de banda optimizado


Incluir vídeos Flash de alta calidad en su sitio web es una gran idea. Pero hay que tener en cuenta que, cada vez que un vídeo de alta calidad se reproduce por completo, consume bastante ancho de banda del servidor. Si no se tiene cuidado, se puede llegar a obtener un molesto mensaje de bandwidth limit exceeded (límite de ancho de banda rebasado), que desembocaría en un corte de la página durante el resto del mes, o incluso en un cargo monetario adicional según el ancho de banda excedido.


Así pues, la clave es conseguir un equilibrio adecuado entre calidad de vídeo (la cantidad de compresión aplicada al vídeo) y el tamaño total del archivo de vídeo en bytes (es decir, la cantidad de ancho de banda total consumida tras descargar por completo el vídeo).


El truco es crear un archivo de vídeo Flash con un bitrate moderado y un tamaño de vídeo pequeño (en cuanto a dimensiones en pantalla del archivo de vídeo .FLV). Luego sólo habría que aumentar el tamaño de vídeo a la hora de incrustar el vídeo Flash en el sitio web.


Cambiar el tamaño de vídeo Flash


Estos son los pasos que debería seguir para ahorrar ancho de banda de vídeo Flash sin que la calidad del vídeo se resienta:

  • Convierta el vídeo a Flash Video (.FLV) especificando un ancho de banda de vídeo alrededor de 400 kbps.

  • Necesita reducir el tamaño de vídeo del nuevo archivo .FLV. Las dimensiones en pantalla del archivo de vídeo .FLV pueden ser tan pequeñas como el tamaño deseado final dividido entre 1,25.

  • Configure el tamaño de vídeo Flash deseado (no el tamaño real del archivo de vídeo FLV) como las dimensiones del vídeo especificadas en los controles de reproducción de vídeo a la hora de incrustar el vídeo en la página web. Si necesita algunos consejos para configurar los controles de reproducción de vídeo Flash, he aquí algunos trucos para incrustar vídeos Flash de alta calidad.

Y eso es todo. Las dos ideas principales de este truco de vídeo son así de sencillas y eficaces:

  • Utilizar un ancho de banda de vídeo moderado con un archivo de vídeo de tamaño en pantalla pequeño para obtener una buena calidad de compresión.

  • Cambiar el tamaño de vídeo, aumentando el vídeo Flash al incrustarlo, configurando el reproductor para que el vídeo se muestre al tamaño deseado.

Las redes modernas pueden reproducir un vídeo de 400 kbps en streaming a tiempo real, o con un tiempo de precarga muy pequeño. La calidad del vídeo Flash será alta puesto que las dimensiones del archivo de vídeo original son pequeñas. Con una compresión de vídeo configurada para alta calidad se tendrán pocos artefactos de compresión en el vídeo Flash. Incluso los subtítulos del vídeo, y cualquier otro texto incluido en el vídeo, serán fácilmente legibles.


Por otro lado, la distorsión causada por aumentar el tamaño de vídeo resulta menos molesta a la vista que los artefactos introducidos por la compresión. La clave es nunca cambiar el tamaño de vídeo a más de un 125% del tamaño real del archivo de vídeo, o podrían aparecer efectos excesivos de pixelación en el vídeo.


El resultado final es un vídeo Flash que en pantalla tendrá el tamaño deseado con escasos artefactos de compresión: un vídeo de alta calidad con un consumo de ancho de banda optimizado.

Incluir vídeo en Blogger: vídeos FLV con controles Flash


Resulta muy interesante introducir contenidos de vídeo en un blog. De hecho, incrustar vídeos de YouTube en Blogger es muy sencillo. Sin embargo, utilizar vídeos de YouTube presenta ciertos inconvenientes:

  • La resolución real de los vídeos de YouTube está limitada a 320 x 240 píxels.

  • El vídeo sufre una fuerte compresión (está limitado a 250 kbps).

  • La marca de agua de YouTube puede superponerse al vídeo.

  • La personalización de los controles de reproducción del vídeo es limitada.

El formato de vídeo FLV (Flash Video) proporciona una magnífica relación entre compresión y calidad, dando lugar a vídeos de alta calidad que ocupan muy poco. Por ello, recomendaría crear vídeos en formato FLV, almacenar estos vídeos en su propio servidor web, e incluir vídeo FLV en Blogger. Siga estos pasos para incrustar vídeo de alta calidad en su blog:


Esquema de incluir vídeos FLV en Blogger


Paso 1 - Convertir el vídeo en FLV


El primer paso es convertir el vídeo a FLV. El entorno de edición de Adobe Flash posee una función de Importar Vídeo que permite convertir rápidamente un archivo original de vídeo en FLV. Sin embargo, el entorno de desarrollo de Flash es una aplicación cara. Por ello mi consejo es utilizar un conversor de vídeo gratuito que permita convertir el archivo de vídeo original (.avi, .mpg, .mov, ...) en un archivo de vídeo Flash (.flv).


SUPER es el conversor de vídeo gratuito que yo elegiría para convertir el vídeo a FLV.


No tiene más que pasar su vídeo a formato FLV y subir el archivo .FLV resultante a su servidor web. Sólo hay que tener cierto cuidado con el consumo del ancho de banda, puesto que el contenido en forma de vídeo suele ocupar bastante.



Paso 2 - Crear los controles de reproducción


Una vez que se dispone de un vídeo en formato FLV es necesario crear los controles de reproducción, necesarios para arrancar el vídeo, pausarlo, detenerlo, comprobar cuánto vídeo se ha precargado, controlar el volumen, etc.


El entorno de desarrollo de Flash permite incluir controles de vídeo predefinidos, pero esto no resultará de gran utilidad para incluir el vídeo en Blogger: Flash no permite incluir una ruta absoluta al archivo SWF que contiene los controles del vídeo, el cual se encontrará en su propio servidor web (y no en el servidor de Blogger, con lo que no valdrán las rutas relativas).


La solución consiste en utilizar un reproductor de vídeo FLV de código abierto que pueda incrustarse dentro del código HTML del blog. El reproductor de vídeos FLV que recomiendo es OS FLV Player, el cual es completamente código abierto, personalizable, fiable y permite la incrustación en el blog. Y ni siquiera hace falta tener el editor de Flash para utilizar este programa: sólo es necesario subir el archivo precompilado que incluye los controles de reproducción a su servidor (player.swf).


En los próximos pasos le enseñaré a configurar OS FLV Player para que pueda incluir vídeo Flash en Blogger de forma sencilla.



Paso 3 - Incrustar vídeo Flash en Blogger


OS FLV Player proporciona código PHP que genera automáticamente el código HTML necesario para incrustar el vídeo FLV en una página web.


Pero, puesto que tendremos que almacenar los controles de reproducción en un servidor web diferente del de Blogger, necesitaremos escribir el código para incluir el vídeo en el blog a mano. He aquí el código HTML que deberá incluirse en el post del blog para incrustar el vídeo en el blog:



<object width="[Ancho del vídeo]" height="[Alto del vídeo]" id="flvPlayer">

   <param name="movie" value="[Ruta absoluta de player.swf]" />

   <param name="FlashVars" value="&movie=[Ruta absoluta al vídeo .FLV]">

   <embed src="[Ruta absoluta de player.swf]" flashvars="&movie=[Ruta absoluta al vídeo .FLV]" width="[Ancho del vídeo]" height="[Alto del vídeo]" type="application/x-shockwave-flash">
   </embed>

</object>


Sólo hay que sustituir los parámetros señalados:

  • Usar el mismo alto y ancho que tenga el vídeo .FLV original.

  • Usar la ruta absoluta al archivo SWF que tenga los controles de reproducción de OS FLV (ejemplo: http://www.midominio.com/player.swf).

  • Usar la ruta absoluta al archivo de vídeo FLV (ejemplo: http://www.midominio.com/miVideo.flv).


Paso 4 - Personalizar el aspecto del vídeo en el blog


En este punto, puede ser necesario personalizar el aspecto de los controles de reproducción, de manera que el archivo de vídeo Flash incluido en el blog haga juego con la plantilla de Blogger seleccionada.


Puesto que OS FLV Player es un reproductor de código abierto, se permite editar el archivo de código fuente .FLA (player.fla), de manera que pueda crear unos controles de reproducción con el aspecto que prefiera. No obstante, para editar el archivo fuente .FLA es necesario tener el editor de Flash.


Por otra parte, hay una forma muy sencilla de personalizar los colores de la interfaz del vídeo, sin más que cambiar los valores de un par de parámetros. He aquí el código fuente de ejemplo:



<object width="640" height="480" id="flvPlayer">

   <param name="movie" value="http://www.midominio.com/player.swf" />

   <param name="FlashVars" value="&movie=http://mydomain.com/miVideo.flv&fgcolor=0x333333&bgcolor=0x999999">

   <embed src="http://www.midominio.com/player.swf" flashvars="&movie=http://mydomain.com/miVideo.flv&fgcolor=0x333333&bgcolor=0x999999" width="640" height="480" type="application/x-shockwave-flash">
   </embed>

</object>


Los parámetros que debería ajustar son los siguientes:

  • El color principal (fgcolor, puesto a 333333 en el ejemplo).

  • El color de fondo (bgcolor, puesto a 999999 en el ejemplo).


Conclusiones


Incluir vídeos FLV en Blogger no es difícil. Sólo necesita convertir sus archivos de vídeo originales a FLV e incrustarlos en un reproductor de vídeos FLV dentro del blog. Este procedimiento ofrece múltiples ventajas:

  • Puede incluir vídeo de alta resolución en su blog.

  • Puede controlar la compresión del vídeo, con lo que puede incluir vídeos Flash de alta calidad.

  • Puede evitar que aparezcan marcas de agua de terceras partes en sus vídeos FLV.

  • El aspecto de los controles de reproducción es totalmente personalizable, de manera que puede adaptarlo al aspecto de su blog.

¡Aproveche estos trucos y comience hoy mismo a incluir vídeo FLV de alta calidad en su blog!