Posts Tagged ‘IBM’


Apple acaba de aprobar SuperComics v2 para iOS con lo que completo las 3 principales plataformas de aplicaciones: Android, Windows Phone y iOS. Finalmente, cumplo con entregar una aplicación que soporta casi todo lo que hay en el mercado con una sola base de código. Aún en el horno está la versión para Windows 10 y para cuando le encuentre la forma de monetizarlo, la versión Web.

La motivación tras este proyecto fue la de realmente darle una mano al mundo Cómic en Perú, pues esta muy bien que salgan muchos a publicar pero para el coleccionista, hace falta un orden y saber, al menos, que hay para comprar en el kiosco, así que inicialmente este proyecto es un catálogo. Y el segundo punto es que sea realmente una aplicación móvil que demuestre que se puede hacer una aplicación multiplataforma con soporte de datos fuera de línea y todo que funcione con recursos limitados. Hasta ahora, me parece que se han cumplido los objetivos y aún hay espacio para mejoras.

Sobre el tema del catálogo de cómics: no soy un experto en el mundo editorial pero por lo poco que me han ido contando las personas que si están en este mundo, me doy cuenta que el detalle común es el super esfuerzo que hacen muchos para publicar, incluso yo diría que lo hacen por un tema de orgullo personal, o simplemente decir que sacaron un cómic por lo tanto, no se les puede pedir planificación ni estrategias de distribución ni de marketing. La suerte es que hay mucho compromiso de gente fanática que ayuda, como por ejemplo las tiendas de cómic que cada día son mas donde los dueños son los más fanáticos. A todos los que piensan publicar o ya están publicando cómics localmente yo les recomendaría estos tips:

  • Creen un roadmap: Si van a sacar un cómic, piensen primero en cuantos cómics serán y el formato, 5 grapas o 2 libros o lo que quieran, y establezcan un cronograma de publicación, cada 15 días, cada mes. Con esto podrán distribuir mejor sus recursos, y por sobre todo, podrán dedicar a alguien a la difusión. ¿Que tan grande debe ser el roadmap? dependerá de cuantas publicaciones quieran hacer: el cielo es el límite.
  • Comuniquen: la idea de comunicar es la de dar a conocer el roadmap al público objetivo con una doble intención: que la gente se entere y lo más importante: MEDIR. Crear un grupo de Facebook no es suficiente, tienen que estar al tanto de que artículo, foto o video ha sido el más visto, o cuantos Likes obtienen o corazones en Twitter, o reproducciones en Vine. Medir les permite establecer el tamaño de su público objetivo y determinar el tiraje de su cómic. Mientras mas tiempo comuniquen y mas tiempo midan, podrán determinar mejor el tamaño de su mercado.
  • Presenten: Si son un cómic nuevo, lo mejor es dar avances. A SpiderMan ya lo conozco, pero si me dicen “Capitan Guachiman” no tendré idea de lo que encontraré al abrir la revista. Otro punto importante es la impresión, no soy fan de las que se imprimen en papel couché y tienen el acabado de fotocopia, prefiero el acabado simple y opaco tipo Frank Miller, lo mismo aplica con los colores, si no coloreas bien, o no tienes plata para la imprenta, ve por los dibujos a tinta china y listo.

Como Bonus: las portadas. SuperComics se basa en mostrar portadas porque es la forma más fácil de identificar un cómic, pero lo principal es saber que números hay, desde cuando están disponibles y todo lo demás. En algunos casos, hay celos de parte de la editora en sacar las portadas antes de la publicación y es comprensible, pero la realidad es que si hablamos de Cómics gringos, todas las portadas ya están en Internet desde hace tiempo. Es mejor salir a comunicar con las portadas, como lo hacía Comics21 al principio, pues te hace más fácil la búsqueda de números atrasados y eso lo digo por experiencia: casí le he hecho aprender Inglés a la señora del Kiosco en Jesús maría donde compro mis revistas, pues yo le pedía “SpiderMan: One More Day issue 2” y la señora se echaba a bucear en la pila de revistas que tenía y pues fácil no resultaba. Ahora sólo le enseño la imagen y ya me saca la revista. Si la editora no quiere soltar las portadas, no hay problema mientras suelte el cronograma, aunque lo ideal es que suelte los dos.

Sobre la aplicación: Cuando decides coleccionar cómics es como cuando juntabas las figuritas de tu álbum, necesitas saber cuantos son, cuáles y cuando los puedes encontrar en tienda. Yo comencé con los cómics de Perú 21 y la cosa no era muy fácil pues no había gente que supiera vender cómics así que encontrabas cómics doblados o escondidos cuando ibas al kiosco, o peor aún, una semana había, y la otra no, fatal. Ahora el tema es más ordenado y si vas a una de las tiendas especializadas, hasta sales con tu bolsicartón gratis. A pesar de la mejora, sigue siendo necesario saber, cuantos, cuáles y donde encontrar tus cómics.

SuperComics utiliza el concepto “Off-line first” para mantener la base de datos de cómics en tu celular para que puedas consultarlos hasta en un sótano o en algún centro comercial caleta bien al fondo. Incluye tanto la portada como la información general del cómic. Además, podrás marcar dos cosas:

  • Nola/Yala: tal cual era con las figuritas, marcas si ya tienes el cómic y te evites de comprar repetidos.
  • Lista de compras: cuando te das el tiempo de revisar tu colección, sueles encontrar que por alguna razón te falta alguno y lo marcas en un papelito que luego se pierde. Ya no más, si lo marcas en compras, tendrás una sección donde verás los cómics que te faltan comprar y de esa manera vayas confiado a la tienda o a la reunión de coleccionistas para hacer tu intercambio.

Finalmente, si tienes la portada te gustaría pasársela a alguien, ya sea porque la quieres cambiar, o simplemente para sacarle cachita a alguien, así que también es posible que compartas la carátula por redes sociales. No todas las redes sociales dejan compartir la misma información, por ahora Twitter es mi favorito, pero si te gusta, también puedes compartir por Whatsapp.

Además de eso, existe un catálogo de Editores, los que pude conseguir hasta ahora, donde encontrarás las colecciones publicadas todas ordenadas para que las busques como te de la gana.

Y como no podía ser de otra manera, incluí una sección con las tiendas especializadas en cómics y su mapa para que las encuentres fácil.

Ahora bien, todo esto no valdría mucho si es que no estuviera al día. Actualmente la base de cómics en la aplicación es de aprox 400 cómics publicados desde el 2012 en adelante, lo que quiere decir que hay como 300 cómics más publicados desde el 2008 que aún no están registrados, aunque es sólo cuestión de tiempo. Para los que ya instalaron el App habrán notado que la primera vez se toma algo de tiempo y esto es porque se indexan todos los cómics localmente. Esto es para que no tengan que estar descargando la info desde Internet a cada rato, así que se les agradece la paciencia.

Sobre las actualizaciones estás son automáticas y van de dos tipos:

  • Mayores: Si son actualizaciones muy grandes (Principalmente cuando suba cómics antiguos) sacaré otra versión del app con toda la información incluida. Es por esto que el instalador debe rondar los 20 mb.
  • Menores: Lo nuevo es pequeño y se va actualizando automáticamente en tu app cada vez que tengas Internet. Para que se hagan una idea, cada cómic nuevo pesa unos 24Kb y en promedio salen 2 por semana, así que casi no te cuesta, y si gorreas Wifi de StarBucks te sale gratis.

Lo que se viene: 

  • Creo que la dinámica que mueve todo el tema de cómics es el intercambio, por lo que estoy trabajando en algún método para que puedas publicar tus repetidos y que los que estén a tu alrededor vean y puedan interactuar.
  • Ahora ya puedes marcar los cómics que ya tienes, pero deberías poder respaldar esos datos. O deberías poder reinstalar el app y recuperar todos tus cómics marcados. Técnicamente, esto ya es posible en la versión actual, pero supone un costo que no puedo asumir, así que sigo trabajando para bajar ese costo,o ver la forma que la gente interesada pague por el servicio.

La decepción:

  • Los códigos de barras: Hubiera sido genial que estos códigos nos ayuden a identificar los cómics, pero la verdad es que no sirven por una simple razón: no son únicos. En el caso de Comics de Perú21, suelen poner un mismo código a toda una colección, o sea hay 4 o 6 cómics con el mismo código, incluso han llegado a poner el mismo código de barras en más de una colección, plop. En Editora Vuk, han sido más cuidadosos y si tienen código único, en realidad tienen dos: un código para la colección y otro más para identificar el cómic. Otros simplemente no lo usan y ya. En conclusión, el código de barras es inútil para identificar el cómic, así que olvídate. Sería genial que todas las editoras usaran un sólo formato de código de barras, mientras tanto no será posible aprovecharlos en el app.

Download_on_the_App_Store_Badge_ES_135x40Spanish_wstore_black_258x67en_generic_rgb_wo_60


Esta es una continuación de la serie sobre desarrollo en móviles que comencé aquí. Les recomiendo comenzar a escribir el código fuente desde la parte 1 ya que no se publica el código para descarga.

Con la parte 10, podríamos decir que comienza una nueva etapa del código así que debemos empezar con las cosas interesantes. Primero planifiquemos las siguientes funciones:

  • Alertas ante nuevas noticias. Esto ya me lo habían pedido, y recién ahora tiene sentido incluirlo pues ya tenemos todas las herramientas. Según lo que hemos visto, al activar la replicación estamos controlando el evento ‘paused’ para indicar que la sincronización terminó y no hay nada nuevo por el momento, pero no nos dice nada si hubieron noticias nuevas. Para eso debemos controlar otro evento llamado ‘change’ que se genera por cada cambio en la base de datos local, aquí simplemente ubicamos cuando se trate de una nueva noticia y podríamos ya lanzar la notificación, teniendo cuidado pues durante la primera ejecución del programa todas serán noticias nuevas y no queremos una avalancha de alertas.
  • Agregar un mecanismo para registrar las noticias más leídas. Esto supondrá que grabemos en algún lado que hemos leído la noticia. Recordemos que este documento será sincronizado hacia el servidor y a todos los usuarios con la versión actual, lo cual no queremos así que veremos como hacer para que la sincronización sea controlada: que los registros generados por el usuario sean sincronizados con el servidor pero que a los demás usuarios solamente lleguen los documentos con las estadísticas. Igual funcionaría para un mecanismo para registrar “Likes” tipo Facebook.

Comencemos con las alertas para nuevas noticias, para eso necesitamos un plugin para Ionic que nos ayude a manejar las notificaciones locales. Esto se refiere a las mismas alertas que reciben cuando tienen un correo o algún otro cambio relevante. Hay que recalcar que son locales, puesto que los datos ya están en la base de datos; en las apps normalmente se da todo lo contrario, primero llega la notificación y luego se descarga la información, pero como nuestro modelo es “off-line first” no podemos confiarnos en la red.

Para hacer la cosa aún más fácil, instalemos el componente Ng-Cordova que encapsula el código necesario para manejar plugins, mediante el siguiente comando:


bower install ng-Cordova --save

El parámetro –save es para agregar este componente a la lista de dependencias.

Seguidamente, instalemos el plugin:

ionic plugin add https://github.com/katzer/cordova-plugin-local-notifications.git

Y listo, ahora hay que ver donde es el mejor lugar para detectar que se ha insertado una nueva noticia y ese lugar puede ser al detectar un cambio. Recordemos que al momento de replicar ya se genera un evento al detectar el fin de la replicación. Veamos el archivo services.js


db.replicate.from(remote,
{live:true,
retry:true})
.on('paused',changed);

Es bueno recordar aquí como es esto de los eventos de replicación:

  • Paused: indica solamente que la replicación ha parado. Como hemos establecido el parámetro live en true, significa que ya no hay mas cambios que sincronizar. Esto también significa que la replicación no ha recibido mas registros en un rato largo, lo que sucede a cada rato cuando la velocidad del internet es bastante lenta.
  • Complete: Si es que establecemos live en false, significa que la replicación se hará una sola vez y al terminar se generará el evento Complete.

Noten que si queremos asegurar que la base local está al día, quizá haya que hacer un mecanismo de control como establecer un registro con la fecha de ultima actualización. Además, la replicación manual puede servir si sabemos que los cambios son poco frecuentes o si queremos que sea el usuario final quien controle la actualización.

Bien, entonces regresando al código, cuando la replicación se completa o se para, se ejecuta la función “changed” que está definida así:


function changed(){
console.log('cambios en la base de datos');
if (!initiated)
{
initiated=true;
db.changes({live: true, since: 'now', include_docs: true})
.on('change', newNews);
};

};

Aquí lo que hacemos es verificar que la base de datos está inicializada y usamos una variable “initiated” para controlar que solamente una vez llamemos  a la función db.changes. Con db.changes lo que hacemos es verificar un evento mas: cuando se ha modificado algún registro en la base de datos. Cuando se detecte este cambio se ejecuta la función “newNews”.

NOTA: fijense bien la secuencia, primero se replica y luego se monitorea el evento cambios. Por lo tanto, la secuencia de datos será así: inicias la aplicación, sincronizas, cuando se completa, cada registro nuevo o modificado generará una alerta. De esta manera, las noticias antiguas no generarán alertas.

Ahora veamos la funcion newNews:


function newNews(change){
if (!change.deleted){
if (change.doc.tipo=="news")
$rootScope.$broadcast('db:newNews',{newsId:change.id,
newsTitle:change.doc.titular});
}
}; function newNews(change){
if (!change.deleted){
if (change.doc.tipo=="news")
$rootScope.$broadcast('db:newNews',{newsId:change.id,
newsTitle:change.doc.titular});
}
};

Bien, notarán que esta función toma un parámetro llamado change que es el documento que ha sido afectado. El documento puede haber sido borrado, creado o modificado. Si es borrado la propiedad change.deleted será verdadera. Si el documento es creado o modificado por ahora los trataremos como iguales pues tendríamos que revisar la fecha de creación en alguna propiedad.

En la línea 10 verificamos que no se trate de un documento borrado y seguidamente verificamos que el documento sea del tipo news, porque también hay documentos del tipo cat y esos no queremos que manden notificaciones. Si todo se cumple, mandamos un broadcast para que se genere el evento de generación de la notificacion. Para ver eso vamos al archivo app.js.


.run(function($rootScope,$state,$cordovaLocalNotification){
$rootScope.$on('db:newNews',function(event,args){
var id = new Date().getMilliseconds();
$cordovaLocalNotification.schedule({
id: id,
title: 'Super Datos',
text: args.newsTitle,
data: {
newsId: args.newsId,
newsTitle: args.newstitle
}
}).then(function (result) {
console.log('Notificación registrada');
});

$rootScope.$on('$cordovaLocalNotification:click', function (
event,
notification,
state) {
var datos = JSON.parse(notification.data);
$state.go('app.detail',{id:datos.newsId});
});
});
})

Aquí notarán que hemos agregado una sección .run() para manejar dos eventos en la aplicación: el primero el evento que generamos anteriormente para avisar que hay una nueva noticia y otro mas para el evento $cordovaLocalNotification:click, este último evento es el que se genera cuando un usuario hace click encima de la notificación, es decir, que cuando llegue la notificación, el usuario vera el aviso en su teléfono y al hacer click se abrirá la aplicación y se abrirá en el estado detalle para que pueda leer el contenido. Creo que estamos de acuerdo que mas complicado ha sido encontrar y fijar el evento que lanza la notificación que programarla, pero lo hago así por una razón: trato que todos los eventos sean manejados en el app.js para no tener problema luego para mantenerlos y gestionarlos, incluso trato que los broadcast estén aquí en la medida de lo posible, o en su defecto en el archivo services.js, nunca en un controlador.

Y listo, ya pueden probar su nuevo lector de noticias, y cada vez que tengan una nueva noticia o una noticia antigua ha sido actualizada, recibirán una notificación que les permitirá enterarse e ir directamente al nuevo contenido.

Recalco que esto no es una notificación tradicional, pues el contenido ya está en el teléfono y es la misma aplicación la que genera la notificación. Las apps conectadas que son las mas comunes, mandan la notificación por la red y recién hacen la recuperación de los datos, todo depende de como quieren que su app se comporte.

Finalmente, pueden jugar con más opciones de las notificaciones locales, como agregar un botón para que el app te recuerde leer una noticia dentro de 15 minutos, o poner una notificación cuando el app esté sincronizando y demás cosas. Todo queda en ustedes.


En la semana he recibido un par de consultas que me parecen super importantes y que trataré de responder en un par de post y de pasada repasar los fundamentos.

La segunda pregunta que recibí creo que es mejor tratarla primero: ¿Ionic con PouchDB y Cloudant es más rápido que usar MySQL y websql? Veamos, desde mi punto de vista por más que parece lo mismo, no lo son.

Antes debemos revisar un par de puntos:

Primero, PouchDB es además una capa de abstracción de datos porque puede utilizar varios tipos de archivos para almacenar los datos (Adaptadores), principalmente puede usar IndexedDB, WebSQL y otros menos usados. La recomendación es que le indiquemos a PouchDB que utilice WebSQL si queremos que sea más rápido. En alguna eventualidad, PouchDB nos libra del problema pues puede elegir automáticamente cual es el mejor almacenamiento para nuestros datos.

Segundo, WebSQL, sqlite o como lo quieran llamar, es un estándar que ya está “depreciado”. El consorcio que maneja los estándares de Internet ya ha fijado que IndexedDB sea el estándar. Los navegadores siguen teniendo soporte para WebSQL pero no se sabe exactamente hasta cuando, mas bien IndexedDB es una obligación para todos.

Ahora comparemos:

PouchDB y Cloudant (o CouchDB en general) es realmente una solución de gestión de datos de extremo a extremo que parte del concepto denominado “offline first” donde la aplicación cliente, luego de una sincronización inicial, está preparada para trabajar sin conectarse al Servidor. Incluso, hay otro movimiento más radical denominada “No Backend”, pero no lleguemos a extremos, de alguna manera la base de datos es el backend y, si fuera necesario, se puede colocar una capa de lógica intermedia. Para resumir, PouchDB – CouchDB incluye, gestión de datos, sincronización y segmentación de datos. Un aspecto adicional es que, dado que no hay esquemas, es necesario “transformar” los datos del modelo relacional para que cuadre en el modelo “documental” de CouchDB y para esto pensaremos en la estructura que mejor nos acomode en la aplicación cliente lo que significa que vamos a “limpiar” el modelo para tener solamente lo que nos interesa.

MySQL y WebSQL (o sqlite para los amigos) es en el sentido estricto solamente un gestor de datos. Pasar datos desde MySQL a la base local en WebSQL es algo que tenemos que hacer nosotros, al igual de la segmentación de datos. Además, dado que en sqlite tenemos tablas y un dialecto de SQL, nuestra primera tentación será la de repetir el modelo de datos que tenemos en el backend.

Entonces, para comparar papas con papas, hablemos del aspecto de gestión de datos solamente de ambas soluciones. La verdad dura y simple es que consultar datos con sqlite es más rápido que consultar datos con PouchDB. Hay un documento que explica el rendimiento comparado de las bases de datos en el lado del cliente que pueden consultar Comparación datos móviles

Ahora bien, esto no me parece determinante porque, dependiendo del modelo de datos que tengamos, es muy probable que con el modelo relacional de sqlite tengamos que hacer más consultas que con PouchDB. Esto no tengo como sustentarlo en números, pero en los proyectos que he realizado es algo evidente que si modelas bien, consultas menos y dado que en un “Documento” de CouchDB puedes organizar los datos en más de 1 nivel, puedes traer más datos en una sola consulta.

Otro punto importante es la cantidad de datos. Mientras más datos tengas, será más claro el tema de la velocidad. En mi caso, tengo apps donde guardo mas de 300 documentos en el móvil y la velocidad es aceptable. Debemos considerar que los documentos no son tan simples, incluso la gran mayoría contiene BLOBs de 20K en promedio de tamaño con un tamaño total de 12 MB de la base de datos, lo que sería una locura en un entorno sqlite. Si el volumen de datos que vas a manejar es menor a mi ejemplo, entonces la diferencia de performance no la vas a sentir.

Guardo el tema de índices para el final porque es muy importante. Con Sqlite podemos crear índices donde y cuando nos dé la gana lo cual casi no tiene costo en procesamiento ni en almacenamiento. En el caso de PouchDB, los índices no se hacen por nada: Existe un índice por defecto que solamente contiene el campo _id de todos los documentos en la base de datos, y como no hay tablas pues estamos hablamos de absolutamente todos los registros. Suena a limitación, pero significa que recuperar un registro es super mega extra rápido y recuerden que un registro puede tener mucha información que en Sqlite podría tomar más de una consulta, además, si usamos el ID correcto nuestras consultas pueden beneficiarse de este super índice: la clave es crear los IDs manualmente incluyendo los criterios de búsqueda que necesitemos. Por ejemplo, si queremos guardar un documento para el Comic 1 de la editorial DC que salió en 01 de febrero del 2015, el ID que nos convendría sería com_dc_2015-02-01_01, de esta manera podremos hacer consultas muy rápidas con el método allDocs de PouchDB:

– Todos los comics: startkey: ‘com_’, endkey: ‘com_\uffff’;

– Todos los comics de la editorial DC: startkey: ‘com_dc_’, endkey:’com_dc_\uffff’

– Todos los comics de DC que salieron el 2015: startkey: ‘com_dc_2015_’, endkey: ‘com_dc_2015_\uffff’

La mala palabra en PouchDB es ‘Joins’ al estilo sql. No existe, así de simple, pero no desesperen pues existen muy buenas alternativas. Aquí van dos: Podemos crear vistas que son parecidas a las del mundo relacional pero que siguen el modelo Map/Reduce que es lo mejor en lo referido a escalabilidad, igual la recomendación es usarla solamente en condiciones extremas tal como se explica en este artículo. La segunda opción se llama Mango y es una forma de indexar toda la base de datos de la forma que nos de la gana y podrán encontrar información aquí.

Finalmente, y creo que es la razón definitiva por la cual se debería usar el modelo con PouchDB, es que tenemos que valorar que estamos usando una solución completa para el manejo de datos, no es solamente un modo de tener una base local, es una solución de sincronización. En un modelo Sqlite, la sincronización es un proceso que tiene que ocurrir de modo secuencial, es decir: ingresas datos, modificas datos, parar para sincronizar, lees datos, modificas datos. Con PouchDB, la sincronización es un proceso que se ejecuta en una tarea paralela, por lo que podremos ingresar, leer, modificar datos sin parar.

Si realmente necesitan velocidad, Sqlite no va a estar en el vecindario por mucho tiempo, así que mi recomendación está en mejorar el modelo.


HP anunció hoy que empezará a evaluar todo su negocio de computación personal que incluye laptops, pcs y periféricos. Además, también incluye la tan mentada línea de móviles basados en WebOS que estaban en etapa de lanzamiento.

Esto quiere decir que la campaña “La computadora es personal de nuevo” no tuvo los resultados esperados y ahora se buscará un comprador para que explote ese negocio fuera del paraguas HP. HP ha perdido justamente la línea de negocio que la llevó a ser el fabricante mas grande del mundo en hardware.

El segmento corporativo es aún sostenible, pero si vemos el antecedente de IBM, que vendió su linea de computación personal a Lenovo, el futuro no es muy prometedor, es decir, para nosotros los consumidores.

El problema es simple para las empresas como HP e IBM, los negocios de computación personal generan un gran volumen de ventas pero significan un margen de ganancias muy pequeño. Pongamos la comparación extrema, Angry birds es más productiva que la división de computación personal de HP, teniendo en cuenta que la inversión ha sido mínima porque no estamos hablando de ningún super juego de 3D y de plataforma como los que se hacen para xbox o playstation.

¿ Cuál es la causa de esta crisis? en mi opinión es la anomalía en el mercado generada por los smartphones y tablets que han alterado la percepción de los consumidores para mal. Esto puede comprobarse fácilmente, es cuestión de revisar el teléfono celular que utilizamos y ver cuál es su valor de mercado. Por ejemplo, un Samsung Galaxy S está alrededor de los USD 600, con ese mismo dinero podríamos comprar un Xbox y un Playstation para nuestra sala, o una laptop muy decente, o todo un sistema de home teather. Con esta comparación, ¿valdría la pena comprar un Samsung Galaxy S? Yo creo que no porque lo que podemos conseguir a cambio es muchisimo mas en funcionalidad y ventajas a excepción de la movilidad. Y si hacemos ahora la evaluación con un Apple iPhone la respuesta se vuelve mas obvia porque el precio de mercado es aún mayor.

En un post muy antiguo, yo dije que esta anomalía se iba a corregir en un par de años y que se iba a manifestar con la vuelta de los celulares básicos concentrados en la función de voz y con servicios modulares de tal forma que podamos crecer en funcionalidades según nuestras necesidades (https://vpease.wordpress.com/2010/07/21/cuanto-pagar-por-un-smartphone/)

El problema al que nos enfrentamos se llama Marketing y ha sido tan bueno que ya tenemos en la cabeza que debemos estar pendientes en el nuevo teléfono y si es de Apple, mejor. Que un teléfono de ese tipo debe costarnos mas de USD 600 y que es mucho mejor que tener una PC o cualquier otro electrónico. Comunicarse, hablar por teléfono o navegar por internet ya pasó a un segundo plano. Ahora la cuestión es “ser cool”, o como lo llaman los marketeros, la voz es hacer un producto “aspiracional”.

WebOs es un buen sistema operativo, y el diseño de sus teléfonos copiaba algo realmente bueno del mejor del momento que es Apple, tenía un solo diseño básico de hardware, con lo que evitaba la fragmentación de Android y Windows Phone 7.

Además, contaba con su famoso Synergy para la sincronización de datos que juntaba sin problemas ni enredos, la información corporativa con la información personal. Técnicamente, ignoro si se trataba de un buen teléfono, pero asumamos que esos detalles son cosas que pueden solucionarse fácilmente. Todo esto lo tenía sin perder la facilidad de uso.

De todo el tiempo que vengo trabajando en el tema de móviles, puedo decir que la tendencia es clara en el mercado: consumidores y corporativos. El objetivo de todos los fabricantes es conquistar el mercado de consumidores pues es ahí donde está la masa. El corporativo es reducido, pero de alto margen y de mayores servicios. En el segmento de consumidores tenemos a todos los iPhones, Android, Blackberry, WP7, Bada, Nokia, LG y todos los demás teléfonos menos famosos. En el sergmento corporativo tenemos a uno solo: Blackberry. Ciertamente en el corporativo podemos encontrar otras marcas, pero se trata de soluciones que han sido forzadas a trabajar en el corporativo y que carecen de los controles de seguridad y de gestión que tiene Blackberry.

Ahora, si HP es líder en el segmento de computación corporativa y además tiene un buen producto móvil, para mi es obvio que lo mejor es hacerlo pelear en el mercado donde hay menos participantes: el corporativo. Obviamente que al inicio tendrá menos capacidades de Blackberry, pero la fuerza de la marca, un mejor servicio al cliente y sobre todo un buen form factor (que ya lo tiene) pudo haberle dado una oportunidad de conquistar un buen pedazo del mercado corporativo. Razones hay de sobra pero aquí van las mas obvias:

  • En el corporativo los gerentes eligen, los empleados no. Así que basta con convencer a una persona para colocar 50 o 100 unidades de un teléfono en la empresa
  • Recambio. Si mi teléfono corporativo se malogra, debo poder acceder a un servicio que me reemplace el equipo, y que este modelo dure en el tiempo lo suficiente para que el usuario no sufra con el cambio.  HP Pre es casi el mismo desde que salió y el servicio corporativo de garantías de HP es insuperable.
  • Mensajería y form factor. HP no tendrá toda la infraestructura de RIM, pero las empresas ya tienen Microsoft Exchange y para muchas es suficiente. Por lo tanto, con Activesync se puede ofrecer un nivel de servicio de mensajería muy parecido, y como el diseño de la línea Pre siempre ha considerado un teclado, se hace bastante simple leer y contestar los correos.
  • Un solo proveedor, que mejor para una empresa que tener un solo proveedor para las computadoras, servidores y también celulares?
Nadie mas que HP tenía todo esto y ahora ya no lo tiene. La alternativa mas consistente para reemplazar a Blackberry en el segmento corporativo ha desaparecido.
Hay empresas que han forzado la figura utilizando equipos como el iPhone y Androides como equipo corporativo pero adolecen ante la principal aplicación corporativa: el correo electrónico pues un teclado es mandatorio.
La tarea para los nuevos marketeros es la de reeducar al mercado sobre el verdadero valor de los electrónicos. Alguien dijo que se trataba del fin de la computación personal o del PC, pero no lo creo porque por mas eficiente que sea un tablet o un teléfono, aún no puede hacer todo lo que una persona hace con una PC. Alguién podrá decir que incluso ya existe una versión de Photoshop para móviles, o que ya puedo editar una película en un iPhone, pero una vez que pasemos de hacer trivialidades, nos daremos cuenta que nos hace falta el poder de un PC y su versatilidad para acomodarnos a hacer cualquier tarea mediante la instalación de un programa nuevo.




%d bloggers like this: