Cómo usar el teclado de su ordenador para tocar música en Cakewalk Music Creator 6 Touch

¿Alguna vez ha querido tocar música utilizando el teclado de su ordenador, en esas ocasiones en que no tiene un teclado de música MIDI disponible? Componer canciones añadiendo notas con las pulsaciones de su teclad es una característica de la que disponen la mayor parte de programas de creación de música. Pero por desgracia, esta característica no está disponible en Cakewalk Music Creator 6 Touch, más pensado para las pantallas táctiles o los teclados MIDI reales.


Por ello, parecía interesante y necesario encontrar una forma de utilizar el teclado de su ordenador como teclado MIDI que pudiera ser reconocido por Music Creator 6, como una forma de componer borradores de canciones incluso en su ordenador portátil u otras situaciones en que no tuviera un teclado MIDI a mano.

Usar teclado de ordenador como teclado de música

Cómo hacer que Cakewalk Music Creator 6 Touch reconozca el teclado de su ordenador como una entrada MIDI

El procedimiento necesario para que, en general, cualquier aplicación de creación musical reconozca el teclado de su ordenador como un teclado MIDI, debería seguir los siguientes pasos:

  • Un teclado MIDI virtual debería capturar las pulsaciones de teclas del teclado de su ordenador, interpretándolas como MIDI.
  • Esta información MIDI debería ser redirigida de la salida del teclado virtual a la entrada MIDI de su programa de creación musical.
Usar teclado de ordenador como MIDI

Así pues, hacer que su teclado funcione con Music Creator es más sencillo de lo que parece, una vez que dispone de los siguientes programas gratuitos instalados:

  • VMPK. Se trata de un proyecto de código abierto, cuyo nombre significa Teclado de Piano MIDI Virtual (Virtual MIDI Piano Keyboard). VMPK reconocerá las pulsaciones de tecla que se produzcan en el teclado de su ordenador como si fuesen una entrada MIDI. Este programa puede descargarse en este enlace, habiendo también otras descripciones avanzadas de su uso y configuración en su propia página oficial.
  • loopMIDI. Este programa, creado por Tobias Erichsen, proporciona una forma fiable y extremadamente sencilla para redirigir sus cables MIDI virtuales entre sus programas y dispositivos. A diferencia de otros programas populares pero actualmente desactualizados, como MIDIYoke, loopMidi funcionará con sistemas que van desde Windows XP a Windows 8, con soporte para versiones de 32 y de 64 bits. El programa puede descargarse de la página web del autor, en este enlace.

Pasos detallados para utilizar el teclado de su ordenador como un dispositivo de entrada MIDI en Music Creator 6 Touch

Una vez que tenga Cakewalk Music Creator 6 Touch instalado en su ordenador, junto con las otras dos utilidades de software previamente mencionadas, sólo tendrá que seguir los pasos que se mencionan a continuación para poder tocar y grabar música utilizando el teclado de su ordenador.


En primer lugar, ejecute loopMIDI arrancando el archivo loopMIDI.exe. La primera vez que lo arranque deberá crear un nuevo puerto de redirección MIDI. Para ello, pulse el botón con el símbolo de más (+) para crear este nuevo puerto MIDI. En el ejemplo, utilizamos el nombre por defecto para el puerto de redirección, loopMIDI Port.


Añadir un nuevo puerto MIDI

Tenga en cuenta que no debe cerrar loopMIDI, ya que este programa tiene que seguir ejecutándose para que el redireccionamiento MIDI surta efecto.


El siguiente paso consiste en ejecutar VMPK.exe para arrancar el software que actúa como el teclado MIDI virtual. Desde ese momento, VPMK comenzará a capturar las pulsaciones del teclado de su ordenador como si se tratase de una entrada MIDI, siempre y cuando su ventana se encuentre seleccionada como la ventana activa actual de Windows. Seleccione Edit > MIDI Connections (editar conexiones MIDI) para configurar la salida MIDI de este programa en cuestión.


editar conexiones MIDI virtuales

Necesitamos que la salida de este teclado virtual vaya hacia el puerto de redirección MIDI que acabamos de crear. Por ello, dentro del menú de configuración MIDI de VMPK seleccionaremos el nombre del nuevo puerto de loopMIDI como Output MIDI Connection (conexión de salida MIDI). En este ejemplo, seleccionaremos el puerto de redirección recién creado, de nombre “loopMIDI Port”, y pulsaremos OK.


conexión MIDI de salida

He aquí cuando llegamos a Cakewalk Music Creator 6 Touch. En este punto, reconocemos las pulsaciones del teclado, y las enviamos a un puerto MIDI que las redirecciona como una nueva entrada MIDI. Así que el próximo paso consiste en configurar Music Creator 6 para que utilice este puerto virtual como su entrada MIDI. Dentro de Music Creator, abra el menú de preferencias seleccionando Edit > Preferences.


editar las preferencias de Music Creator

Dentro de la ventana de preferencias de Music Creator, seleccioneDevices (dispositivos) dentro de la categoría Inputs (entradas). Busque el nombre del puerto MIDI virtual que acabase de crear - en nuestro ejemplo, su nombre es loopMIDI Port. Seleccione este puerto marcando la casilla a la izquierda de su nombre en la categoría de entradas MIDI, y pulse OK.


Dispositivos MIDI de entrada en Cakewalk Music Creator


¡Y eso es todo! Cakewalk Music Creator reconocerá las pulsaciones en el teclado como una entrada MIDI (siempre y cuando la ventana del teclado virtual VMPK sea la ventana activa de Windows, y siempre que el software de loopMIDI siga ejecutándose) permitiéndole grabar las notas (e incluso grabaciones nota a nota) de sus canciones, introducidas directamente desde el teclado de su ordenador.


Incluso cuando no hay nada más adecuado que un teclado de música MIDI completo, esta solución es bastante efectiva para ahorrar tiempo si no tiene un teclado MIDI a mano, o si está creando música con su portátil mientras viaja.

Vídeo 3D Frikimusical.

De la mano de uno de nuestros redactores y diseñadores Rael del Fraile, nos llega este vídeo 3D del pequeño robot cabezudo de Star Wars, bailando al Rey del Pop:



Bien, ya podéis comentar por ahí que vosotros habéis visto a R2D2 bailando a Michael Jackson.

¿Qué Auriculares / Cascos comprar?

Vamos a simplificar todo lo de los Ohm (Ohmios), dB (Decibelios) y Hz (Hertzios). Hay mucha información técnica por internet explicando qué son, pero no responde a la pregunta rápida de ¿qué necesito valorar a la hora de comprar unos auriculares?, TripleClic pretende hacer la vida más sencilla, así que vamos a simplificar todo eso a un lenguaje más humano:

¿Qué son, para qué sirven y qué importancia tienen los Ohm, dB y Hz?

  • Ohm: Los Ohmios son la Impedancia de los cascos, o en castellano: la resistencia que ofrecen al paso de la corriente, esto determina la potencia que llega con respecto a la que se le envía. A más Ohms más potencia necesita para funcionar. Si la resistencia es muy alta, necesita de un amplificador. En las características técnicas suelen venir en valor nominal, 16, 24 o 32 es lo habitual y para nuestros propósitos está bien.

  • dB: Los Decibelios son el Nivel de presión de sonido (SPL), o la potencia de volumen. Valores de dB más altos hacen que el auricular se escuche más alto, pero también que distorsione antes, a más volumen más cerca de la distorsión.

  • Hz: Hertzios son la Frecuencia de audio, y realmente es el dato importante a tener en cuenta a la hora de determinar la calidad. Es el rango de frecuencias que reproduce el auricular, para escuchar más los agudos y graves, suele venir en valores de mínimo y máximo, mejor a rangos más grandes con el mínimo más bajo y el máximo más alto. El oído humano capta rangos entre 20 a 20.000 Hz.

Conclusión, ¿qué necesito?.


Pues si eres un técnico de sonido, o un entendido y tienes un equipo de sonido considerable, probablemente no necesites leer esto, e incluso discrepes con algunos puntos, pero si eres un usuario de ordenadores, un jugón o un diseñador, y lo que quieres son unos cascos para el PC o el portátil, lo único que necesitas valorar es:
  • A mayor dB más volumen. Entorno a 112 dB/mW es lo habitual.

  • A mayor Ohm más resistencia y requiere más potencia o menos volumen alcanza, 16, 24 o 32 nominal es lo habitual.

  • A mayor rango de Hz capta más frecuencias de sonido y es más calidad. Este es el dato a valorar 20-20.000 Hz está bien, a partir de ahí, mayor rango (12-28.000 Hz, por ejemplo) da más calidad, y menor rango (21-18.000 Hz, por ejemplo) da menos.

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

Botón de acceso rápido al diccionario de la R.A.E.

Si queremos tener un diccionario rápido en nuestro navegador, podemos crear un botón en la barra de marcadores o favoritos, que al clicar nos muestra una ventana emergente (Pop-Up), en la que podemos escribir rápidamente una palabra y dar a buscar en el diccionario de la Real Academia Española de la Lengua, sin necesidad de ir a su página, ir al buscador, etc... Nos carga directamente la página con la definición de la palabra que queremos.

Tan sólo hay que crear un marcador/favorito cualquiera, con el nombre que deseemos, y editar el contenido del enlace con el siguiente código:


javascript:Qr='';if(!Qr){void(Qr=prompt('Diccionario :',''))}if(Qr)location.href='http://lema.rae.es/drae/?val='+escape(Qr)+' '