+34 93 302 74 45 hello@qrcode.es

Desde que iniciamos la publicación de este blog en Julio del 2007 hemos seguido atentamente la evolución de los lectores de QR-Codes.  La falta de lectores compatibles ha sido uno de los principales frenos al desarrollo de los códigos 2D junto con la disponibilidad de terminales preparados, la competitividad de las tarifas de conexión a internet móvil, la falta de cultura de instalación de aplicaciones y la movilización de los contenidos (en breve publicaremos un post sobre estos “frenos” y el estado actual).

No hace falta decir que el panorama ha cambiado en lo referente a la disponibilidad de aplicaciones y calidad de las mismas. Actualmente hemos contabilizado más de 250 Apps de lectores entre la Apple Store y Android Market Place de calidad y prestaciones distintas, pero todas ellas leen correctamente QR-Codes.

Leer un QR-Code… YA NO ES UN PROBLEMA!

qr-code readers

Mención especial merece el lector i-nigma de 3GVision que aparte de ser de los primeros en aparecer mantienen y ofrecen el  lector muy competitivo para infinidad de dispositivos, fabricantes y mayor número de plataformas de forma gratuita.

Después de analizar varias de ellas hemos desistido del intento de hacer una comparativa, que habría sido una tarea tan aburrida como inútil. En su lugar, hoy vamos a realizar un esfuerzo de eclecticismo e imaginación a vamos a “dibujar” el lector del futuro y escribir una wishlist.

Lector+Cámara o Cámara+Lector

Creemos en la convergencia entre el lector y la cámara del dispositivo, y es algo que ya defendíamos en noviembre 2007 en “Del plug-in al melt-in” . La cámara es el ojo del smartphone y una aplicación  para cada uso tiende a no ser eficiente.

Los lectores actuales resuelven la necesidad pero vayamos más allá. La siguiente maqueta (a modo de ejemplo, la hemos basado en un iphone) muestra la opción de activar o desactivar el reconocimiento de los códigos (pudiendo estar por defecto activado) que estén siendo recogidos por la cámara del teléfono. Es una forma de hacerlo de las muchas que hay, pero el concepto es la fusión, el “melt-in”.

qr_ultimate.jpg

Estas son las características básicas que creemos debería tener (en lo posible de serie) el software de cámara del futuro de un smartphone:

  • Tomar fotos
  • Crear videos
  • Detectar e interpretar códigos (detactarlos sin necesidad de hacer una foto y procesar)
  • Integración con el sistema de archivos/álbumes de fotos, etc.

Estas características se podrían mejorar con plugins, actualizaciones o mediante otras aplicaciones.

Por otro lado, en la sección de configuración de la cámara se deberían poder específicar los siguientes parámetros (quizá se nos pasa alguno):

  • Tipos de códigos: QR-Codes/Datamatrix
  • Acceder a la URL automáticamente o mostrar destino y pedir confirmación
  • Abrir el archivo directamente o solicitar si se desea descargar el archivo y el destino.
  • Llamar automáticamente  o mostar número y pedir confirmación
  • Enviar SMS automáticamente  o mostar contenido y pedir confirmación
  • Almacenar histórico/log de capturas

Con el tiempo puede no hacer falta al switch en la interface de la cámara, pero para crear la mecánica de uso y presentar el recurso creemos que sería un recurso interesante.

Wishlist

Este blog no está vinculado al MC2, a la OMA ni al W3C pero por lo que conocemos (quizás estamos equivocados) no existe todavía un documento que estandarice la información que se puede inscrustar en los códigos. Alguien sabe algo?

Información simple como las URL da pocos problemas, pero si entramos en el terreno de las vCards, MECARD, .ics, Geocoordenadas, etc… se vuelve más complejo. Si alguna de estas organizaciones, que entendemos deberían tomar el liderazgo en estas cuestiones, no lo hacen acabará haciéndolo Google (para variar).

La aparición de lectores exclusivos para funciones aisladas (ex. capturar contactos de MECARDS/vCard) que no reconozcan el resto de posiblidades que ofrece un código hace que el lector sea un “me-too” que no aporta valor añadido.

Actualmente el proyecto Zxing ofrece la posibilidad de generar códigos con mucha variedad de funciones, pero no todas ellas son interpretadas por los lectores.

  • URL
  • Evento de calendario
  • MECARD
  • Corodenadas de geolocalización
  • SMS
  • Teléfono
  • Texto
  • Info red WIFI

Quién desarrollará el lector del futuro? Se abren las apuestas!

Comparte este post

Share this post with your friends!