Entradas etiquetadas como mobile apps

Más sobre el desarrollo de apps móviles

Desarrollo de Aplicaciones Web MóvilesEn un post anterior comentaba un poco acerca de las diferencias del desarrollo para móviles entre la estrategia de desarrollar con tecnologías Web (HTML+CSS+Javascript) versus la estrategia de desarrolla de manera nativa. En dicho post mencionamos algunos productos, interesantes todos, para el desarrollo de aplicaciones móviles multiplataforma (apps que funcionan en cualquier dispositivo móvil con el mismo código de programación). En concreto comentamos de 3 casos específicos: Appcelerator Titanium, Phonegap y Rhomobile Rhodes.

La verdad son tres casos muy interesantes de analizar en profundidad. Los tres lanzan la promesa del desarrollo multiplataforma. El mensaje básico de todos ellos es: “No desarrolle para una sola plataforma. Desarrolle para todas con un solo código”. Y lo cumplen. Y precisamente porque lo cumplen es que las comunidades de desarrollo de esas alternativas están bastante conformes con su solución. Sin tratar de ser extenso en mi planteamiento, he aquí lo que en esencia hace cada una de esas herramientas:

1) Appcelerator Titanium: Básicamente provee un medio ambiente de trabajo de desarrollo muy poderoso y flexible, incluye un IDE completo, el cual genera código nativo del móvil. El código nativo funciona en cualquiera de los dispositivos compatibles (en teoría, muchos, pero de manera relevante en iOS de Apple, y en Android) prácticamente sin ningún cambio entre cada plataforma.

Sin embargo la estrategia parece técnicamente compleja y el desarrollador Web se “casa” con este ambiente de trabajo en lugar de utilizar tecnologías más estándares. Además, las aplicaciones no quedan optimizadas para cada plataforma. Me parece algo inmanejable para aplicaciones complejas y no aprovecha las especificidades del dispositivo.

2) Phonegap: Este producto asume que uno desarrolla su aplicación con tecnologías Web tradicionales (HTML5, CSS y javascript) pero que quiere “envolver” dicha aplicación en una capa que le permite poder ser publicada en las App Store como si fuera codificada de modo nativo. Esto me parece una solución bastante elegante aunque quizá es una estrategia débil si el app debe utilizar muchas capacidades gráficas o específicas del dispositivo.

3) Rhomobile Rhodes: Utiliza una estrategia muy similar a Titanium, con la diferencia que el desarrollo utiliza el patrón Model-View-Controller (MVC) directamente en el móvil. Además, a diferencia de Titanium, Rhodes ejecuta el código sobre una máquina virtual que queda funcionando en el móvil. A la manera como lo hace Java con su máquina virtual en ambientes desktop. Sólo que en lugar de Java se utiliza el lenguaje de programación Ruby.

Sin embargo, desde la óptica de una aplicación Web móvil, ni Titanium, ni Rhodes será superior a una estrategia directa como por ejemplo jQuery Mobile. Una aplicación Web con tecnologías estándares tiene no sólo la ventaja de funcionar multiplataforma sino también de ser estándar. Es decir, el developer no se “casa” con tecnologías o frameworks propietarios sino que se trabaja directamente con HTML y CSS, tal como otras aplicaciones Web.

Por otro lado, la promesa de Titanium y Rhodes de ofrecer un medio ambiente de trabajo cuyos productos de software funcionen en cada plataforma suena bastante complejo; sobre todo, dada la enorme fragmentación entre plataformas inclusive del mismo sistema operativo o fabricante. Pienso que si la estratagia de desarrollo nativo es forzosa (por razones de manejo complejo de funcionalidades del dispositivo) quizá lo mejor es desarrollar directamente en la plataforma. O sea, usar COCOA para iOS, y el medio ambiente de desarrollo Java para Android, etc. Esto pareciera ser más eficiente que pasarlos por un filtro de compilación o de máquina virtual.

Mi recomendación sería:
1) Desarrollar la aplicación móvil con un approach de Tecnologías Web Estándares: HTML5+CSS+javascript. (jQuery Mobile y Sencha Touch son alternativas sólidas). Luego, si es necesario colocar estas apps en las App Stores y App Markets, “envolverlas” con Phonegap para hacerlas parecer nativas.

2) Si no es posible o conveniente desarrollar una aplicación Web (de hecho, no siempre se debe seguir la estrategia de desarrollo Web para el móvil), entonces utilizar el enfoque de desarrollo múltiple: COCOA para iOS, Java Android SDK para Android, etc. De esa manera aseguramos buen desempeño, y aprovechamiento total de las capacidades del dispositivo.

, , , ,

Deja un comentario

Apps móviles Web o Nativas [Incluye video comparativo]

¿Aplicaciones Móviles nativas o basadas en tecnologías Web (HTML y Javascript)? Ha habido un debate importante en el mundo del desarrollo de aplicaciones móviles (para celulares y tabletas) sobre si es mejor desarrollar en modo nativo o en modo Web. Por modo nativo o aplicación nativa nos referimos a aquella aplicación que funciona directamente para el sistema operativo del dispositivo y posibilitando el acceso completo a las características y el hardware del móvil. Por el contrario, por aplicación móvil Web nos referimos a las apps que utilizan básicamente las tecnologías Web típicas: HTML, hojas de estilo (CSS) y Javascript. ¿Qué es mejor? Depende.

Mi posición es la siguiente: Si tú quieres desarrollar un app que hace uso de las características completas de hardware y del sistema operativo (ya sea iOS, Android o cualquier otro) del móvil entonces lo mejor será programar una aplicación nativa. De esta manera, si tu app hará uso intensivo, por ejemplo, del GPS ó de la cámara ó de las capacidades de sonido o pantalla del móvil, entonces creo que vale la pena que desarrolles en Objective-C y Cocoa (en caso del iOS) ó en Java y con el Android SDK (para el caso de aplicaciones para Android). Un ejemplo típico de este tipo de apps son los juegos y muchos impresionantes ejemplos descargables hoy día desde las App Stores o App Markets.

Otro escenario es cuando tu aplicación está más orientada a la automatización de un proceso empresarial y que está muy basada en datos. Por ejemplo, apps de CRM, de Recursos Humanos o de soporte a cualquier otro proceso organizacional. Aunque en estas apps, la interfaz también es importante (y por eso el gran momentum que vive Javascript y frameworks como jQuery), lo más importante es que la aplicación funcione en la nube (en la Web). En este caso yo seleccionaría desarrollar la aplicación móvil vía las tecnologías Web tradicionales pero de última generación: HTML5 + CSS3 + Javascript.

Ventajas de la tecnologías nativas: Mejor experiencia del usuario (en la interfaz del móvil) y mejor uso de las características de hardware del mismo. Desventajas: Incompatibilidad de plataformas por lo que el app debe desarrollarse varias veces, una por cada plataforma que se quiera (Android, iOS, Blackberry, Windows Phone, etc.) utilizar.

Ventajas de tecnologías Web: Un desarrollo que funcionará para cualquier plataforma. Sólida integración con aplicaciones basadas en servidores empresariales (aplicaciones Web y de bases de datos). Desventajas: Una interfaz de usuario móvil comparativamente débil y poca capacidad de interactuar con el móvil (sonido, pantalla, GPS, cámara, etc.). Además, no se pueden publicar en los App Stores y Markets para distribuirse y ser descargadas.

Hoy día existen muchos frameworks y tecnologías basadas en HTML5 y Javascript que permiten programar interfaces de uso en los móviles que casi igualan la experiencia de usuario de aplicaciones nativas. No son apps nativas sino Web pero como hacen uso intensivo de Javascript en el móvil pues entonces logran una experiencia similar (ver el video). Los frameworks más conocidos son Sencha Touch, jQuery Mobile y jQTouch.

HTML5 Sencha App vs. native iPhone App side by side

On the left, Sencha version of touchNOC Manager app. On the right, native.

Por otro lado, existen tecnologías que permiten construir aplicación híbridas; es decir, apps móviles que son construidas en tecnologías Web (HTML5 / CSS / Javascript) pero que son envueltas para parecer y comportarse como nativas. Las más reconocidas y con más tracción de mercado son PhoneGap, Titanium Mobile y Rhodes. Las diferencias técnicas entre ellas son importantes y mercerían otro post completo. PhoneGap (recientemente comprada por Adobe) es un “wrapper” de aplicaciones móviles Web para hacerlas parecer y funcionar de manera nativa. Titanium Mobile es un compilador de Javascript propietario de tal manera que genera código nativo del móvil. Y Rhodes hace funcionar de manera nativa aplicaciones Web móviles utilizando una máquina virtual (servidor Web más Intérprete de bytecode) en el móvil

¿Qué es mejor? Pues sí; la respuesta sigue siendo “Depende”. Porque dependiendo del contexto del app es que se debe diseñar la estrategia tecnológica correcta a seguir. En principio, ninguna ruta debe ser descartada. Personalmente me inclino más por una aplicación Sencha Touch o jQuery Mobile, pero es una preferencia que debe evaluarse dependiendo de lo que se quiera.

Buen día y ¡mucha suerte!

, , , , , ,

1 comentario

Más de monetización para dispositivos móviles

Long TailEn post anterior describía de manera general algunas alternativas para monetizar (o generar ingresos) de aplicaciones para dispositivos móviles (smartphones y tabletas). Si no lo han leído los invito a hacerlo ahora antes de leer el presente post. En este, me enfocaré principalmente en el modelo de ingresos de vender la aplicación por un precio muy bajo, típicamente entre 1 y 5 dólares, aunque esto puede variar alrededor de esas cifras. Por cierto, una aclaración muy importante es que este post se refiere a aplicaciones móviles que son descargadas desde un servidor Web e instaladas en los móviles. No se refiere a aplicaciones de Nube que son accedidas desde dispositivos móviles. Ambas realidades son bien distintas como mencionaba aquí: Aplicaciones para móviles.

Anteriormente cuando uno quería comprar un software, uno acudía al proveedor y compraba una licencia de dicho software. Dependiendo de la naturaleza y complejidad de la aplicación, el software podía costar desde una cantidad relativamente pequeña (50 dólares, por ejemplo, los antivirus) hasta cientos de miles de dólares tales como las licencias de los programas de ERP (Enterprise Resource Planning) corporativos. En el caso de latinoamérica una empresa podría invertir en el desarrollo de un software y con un poco de suerte lograr colocarlo en el mercado por precios mínimos de unos 500 dólares (como algunos paquetes contables básicos).

Sin embargo, este modelo sería completamente inadecuado para el mercado de aplicaciones para smartphones (iPhone, Android) y tabletas (iPad, Motorola Xoom, Samsung Galaxy) ya que a esos precios las aplicaciones difícilmente serían vendidas. Pero, los costos de desarrollo de software son bastante equivalentes al desarrollo de software para Desktop. Es decir, también para desarrollar software para móviles las empresas requerimos uno o más desarrolladores Web, e idealmente diseñadores, analistas, mercadólogos, etc. Toda una infraestructura de desarrollo y venta de las aplicaciones. ¿Cómo podemos cubrir esos costos si el mercado no paga en licencias de software lo mismo que para aplicaciones Desktop o empresariales?

La respuesta es la Long Tail. Esta “teoría” nos sugiere que el número total de las ventas de una industria está dividida en dos: los artículos populares que todo distribuidor quiere vender porque alcanzan una gran masa de población en poco tiempo, y aquellos artículos muy raros que gustan a pocas personas (o requieren pocas empresas) y que, por tanto, casi ningún distribuidor quiere vender. Sin querer detallar mucho el concepto de Long Tail (les sugiero leer el fascinante artículo de Chris Anderson que popularizó el concepto), esta teoría indica que, sorprendentemente, el volumen más grande de ventas está en los artículos raros pero clásicos o de gustos particulares (p.ej, “Rapsodia Bohemia” de Queen versus la última canción de Shakira) dado que se sostienen por mayor tiempo.

Para querer acceder a dichos mercados, sin embargo, es necesario que la distribución de este tipo de artículos o productos tenga dos características: se sostenga disponible a la venta durante mucho tiempo pero sin elevar los costos de distribución iniciales; y que sea altamente disponible (“encontrable”). Y es entonces cuando observamos que los productos digitales son ideales para aprovechar el Long Tail ya que los costos de distribución durante el tiempo son realmente mínimos. Únicamente se coloca el archivo digital (de música, de software, libros digitales, etc.) en un servidor de Internet y listo. A esperar las descargas de los clientes.

La disponibilidad debe hacerse vía un sitio Web que sea fácilmente encontrable por los usuarios en todo el mundo. Mientras más específico (o especial o raro) sea nuestro producto digital (por ejemplo la canción de Rapsodia Bohemia de Queen en el último cocierto de Freddie Mercury) más fácil será que el usuario llegue a nuestro sitio Web a descargarlo.

Todo lo anterior nos lleva al mercado de las aplicaciones para dispositivos móviles. Si queremos tener éxito con la comercialización de una aplicación en particular, además de la calidad y de la suerte (que también es un factor esencial en el éxito que podamos tener), debemos tener en cuenta que nuestra aplicación sea:

1) Altamente disponible. Muy bien descrita y ubicable en el App Store, Android Market, Blackberry App store, Nokia Ovi store, etc. donde quiera que hayamos decidido distribuirla (incluyendo, cuando sea posible, en un servidor Web propio; en este caso usando técnicas de SEO -Search Engine Optimization- para que sea fácilmente encontrable por los buscadores)

2) En extensión al punto anterior, la aplicación debería ser descargable a nivel mundial. Es decir, altamente disponible a nivel global para acceder a un mercado muy grande

3) Muy barata. El precio no debería disuadir a ningún fanático de la aplicación para comprarla, a veces hasta por impulso dado que la inversión le debe representar casi cero

4) Que resuelva una necesidad muy específica. Mientras más específica (particular o rara), mejor pues será difícil encontrar aplicaciones competidoras.

Ante un escenario así, resulta mucho más atractivo el mercado de desarrollo de software para dispositivos móviles y mucho más atractivo invertir en desarrollarlas. Gracias al concepto de Long Tail, las apps para móviles pueden tener un nicho de mercado muy bueno y resultar ser rentables aún a precios excesivamente bajos.

, , , , , ,

1 comentario

Monetización en aplicaciones para móviles

En un anterior post intenté definir, de manera muy breve e introductoria, a qué me estoy refiriendo cuando hablo de aplicaciones para móviles (o celulares). Al final, comentaba que me parecía importante distinguirlas de las aplicaciones Web accedidas vía móviles debido a que el modelo de ingresos (o modelo de entrega del servicio) así como la tecnología subyacente podrían ser distintos.Monetizacion de aplicaciones para moviles

Entonces, voy a comentar un poco sobre el modelo de ingresos, también llamado el modelo de monetización. Es decir, la manera en cómo se accede a la aplicación y cómo se usa esta; y de acuerdo a ello, cómo podría el creador obtener un beneficio económico de ella. Cabe aclarar que una Mobile App no necesariamente siempre tiene la intención de sacar un beneficio económico. Tal es el caso de las mobile apps empresariales construidas internamente dentro de la organización (o externamente, pero para la organización) para apoyar las operaciones de la empresa. En este caso el beneficio es para la empresa que creó, o que contrató el desarrollo de, la mobile app.

Sin embargo, voy a centrarme en el caso de que el creador o empresa proveedora de la aplicación sí intenta obtener ganancias de su desarrollo. Quizá lo más importante de mencionar es que cuando una empresa desarrolladora crea una aplicación móvil su éxito depende básicamente de su uso masivo ya que su precio es bastante bajo. Sólo un uso masivo podría justificar la inversión en desarrollo de una mobile app.

Los modelos de ingresos básicos (no son excluyentes por lo que podrían mezclarse) son:

1. Suscripción o membresía. Es decir, el usuario de la aplicación móvil la obtiene y la instala en su celular o tableta pero para poder hacer uso de las capacidades completas del app tendrá que suscribir una membresía pagando una cuota periódica al proveedor del app. En ocasiones el modelo de suscripción tiene variantes donde no se paga cada cierto tiempo sino basado en cuotas de uso (megabytes de disco, transferencia de datos; uso de procesador; horas de uso; etc.) pero donde el modelo básico es el mismo: pago periódico o eventual vía suscripción.

2. Comisión por transacción. Es decir, cuando el usuario al usar el app realiza una transacción monetaria (un pago o transferencia). El app puede automáticamente descontar de una cuenta de débito que el cliente mantenga, un pequeño porcentaje a manera de comisión. Lógicamente es prácticamente obligatorio que la empresa desarrolladora del app realice alguna especie de convenio con los procesadores financieros de pagos (tarjetas, bancos, etc.) para que esto sea viable.

Estos dos primeros modelos han sido poco explorados en el ámbito de las mobile apps aunque son ya ampliamente conocidos en los servicios en la Nube. En cambio, en el ámbito puro de las mobile apps hay dos modelos que resaltan. Uno de ellos, basado en publicidad, que es bastante conocido también; y el de compra de la aplicación, que en el caso de las mobile apps resulta llamativo porque es un modelo muy basado en escala (descarga masiva del app).

3. En el caso del modelo de publicidad lo usual es que la aplicación móvil puede ser descargada desde Internet e instalada en el dispostivo móvil (celular o tableta); luego, la aplicación es usada de manera gratuita pero dentro de la aplicación aparecerán de vez en cuando algunos anuncios publicitarios. Son precisamente estos anuncios los que mantienen el desarrollo del app vía el pago que los anunciantes hacen a la empresa o persona que desarrolló el app.

Una variante del modelo es cuando el creador del app ofrece la opción al usuario de que quite los anuncios (Ads) de su aplicación vía un pago, ya sea de cuota única o periódica. De esa manera, el creador del app mantiene una mezcla de ingresos entre publicitarios y de pago de los usuarios.

Este modelo es bastante prometedor en el mundo de las aplicaciones móviles y, como modelo de ingresos, es bien conocido en el ámbito de los servicios que muchos sitios Web ofrecen hoy día. Simplemente que se hereda al mundo de las mobile apps.

4. Vendiendo la aplicación móvil por un precio bajo. Este cuarto modelo de ingresos es el que personalmente me resulta más llamativo, así que ahondaré en detalle en él en un siguiente post. En este momento simplemente mencionar que el modelo funciona porque la aplicación puede ser descargada desde Internet, a un precio muy bajo (típicamente entre 1 y 5 dólares) de manera masiva y a escala mundial. Siendo así, el creador del app sólo tiene que ponerla en Internet y esperar a que el efecto de Longtail haga su labor; es decir, que poco a poco el app vaya generándole ingresos desde unos pocos dólares hasta cantidades ya nada despreciables. Esto lo comentaré en un post posterior.

Y ahora, ¿alguna idea de cómo rentabilizar o monetizar esa aplicación para móviles que estás ideando? Good luck..!

, , , , , , ,

2 comentarios

Aplicaciones para móviles – mobile apps

Mobile Apps

Esta vez quiero escribir un poco más acerca del mundo de las Aplicaciones para Móviles. Esta es una de las tendencias más importantes en el desarrollo de software para esta segunda década del milenio. Pienso que si alguien está interesado en entrar al mundo de los Mobile apps developers está en el camino correcto. El mercado demanda y está ávido de este tipo de aplicaciones. No obstante, tenemos que hacer algunas apreciaciones que me parecen importantes para especificar bien de qué estamos hablando cuando hablamos de mobile apps y en que se diferencia este enfoque de desarrollo en comparación al desarrollo de software tradicional para Web.

Cuando un usuario utiliza su teléfono celular o su tableta electrónica para navegar en Internet porque ahí encuentra muchos servicios útiles (la mayoría basados en la Nube) lo que está haciendo en realidad es “reemplazar” su computadora de escritorio o su Laptop por un celular o tableta que, aunque físicamente más pequeños, no hacen en este caso específico otra cosa que navegar en Internet.

De esa manera si yo accedo a un sistema de información de mi empresa, vía un usuario/contraseña, y vía un browser (navegador Web) probablemente a dicho sistema le es prácticamente indiferente (salvo alguna pequeñas cuestiones técnicas que no abordaremos en este post) si estoy accediendo a él con mi teléfono celular o con mi computadora de escritorio. Después de todo lo único que hago es acceder a un sistema que está en un servidor Web.

Claro, puede ser que dicho sistema sea completamente innovador, tecnológicamente muy avanzado y sumamente útil pero también es cierto que el Web developer que lo desarrolló se debió preocupar “relativamente poco” por el hecho de que el sistema sería accedido vía celular o vía una computadora de escritorio. Lo más importante para el developer era que el sistema sería accesado vía un navegador Web en Internet. El usuario no necesita instalar nada, ni en su teléfono, ni en su computadora, para poder acceder al sistema. Ejemplos de esto son por ejemplo cualquier de las aplicaciones de Salesforce las cuales pueden ser accedidas vía móviles también.

Siendo así, técnicamente hablando dicho Web developer no está desarrollando ninguna Aplicación Móvil, a pesar de que quizá a un usuario específico sólo le guste acceder a ella vía solo su celular. Lo que hizo el desarrollador fue realizar Desarrollo Web.

En cambio si el usuario tiene que bajar una app desde Internet, instalarla en su dispositivo móvil y luego usarla, entonces sí se trata de una aplicación móvil. Por ejemplo, como las aplicaciones de la Apple App Store. De hecho, estrictamente hablando podría ser que una Mobile app ni siquiera necesite Internet para funcionar. Por ejemplo, un app para celular de calculadora científica avanzada; o un app para tomar fotos y manipularlas en el celular. Ese tipo de apps comunmente no depende de que haya o no acceso a Internet.

Y listo; existen dos mundos: el desarrollo Web (que podría considerar aprovechar su acceso desde móviles), y el desarrollo de apps móviles (que podría considerar aprovechar el acceso a Internet). De hecho, existen también sistemas que son construidos pensando en ambas alternativas a la vez; lo cual, en mi opinión, es genial.

Una aclaración muy importante es que no pretendo hacer ningún juicio de valor en cuanto a qué tipo de desarrollo es mejor. Creo que ambos son excelentes rutas que un Developer puede tomar; ambas son muy valoradas en el mercado. Y ambos son mundos tecnológicamente interesantes, modernos y retadores. La otra importante aclaración es que en ambos casos el uso “en movilidad” puede ser fundamental. Es decir, podemos crear aplicaciones, en ambas alternativas, donde el usuario final (que es en realidad el que importa) use su aplicación de manera muy portatil vía sus dispositivos móviles (celular, tableta o laptop).

Viéndolo desde el punto de vista usuario, ambas podrían considerarse móviles (de hecho, lo son). Sin embargo, esta diferencia, aunque es introductoria y quizá algo obvia, me pareció muy importante hacerla como un primer post en este blog debido a que hay dos elementos que son fundamentalmente distintos en cada alternativa, y que iremos abordando poco a poco en este blog:

  • El modelo de ingresos que está detrás de las aplicaciones de cada caso
  • La tecnología subyacente y los conceptos técnicos deben conocerse para cada alternativa

Bien, entonces, manos a la obra; ¡a desarrollar tecnología pensando en movilidad!

, , ,

2 comentarios