No hay una solución mágica para un proyecto, solo hay decisiones. Decisiones bien tomadas o mal tomadas, y al final solo el tiempo te dice si han sido de las primeras o han sido de las segundas, por tanto que nadie os venga con frases del tipo esta solución es la buena sin tan siquiera evaluarla para el proyecto concreto porque puede que en ese caso, esa solución no sea la adecuada. Hay muchos factores a tener en cuenta a la hora de elegir qué camino tomar:

1. El tipo de contenidos: ¿Solo es texto? ¿Hay muchas imágenes? ¿Son muy pesadas? ¿Hay mucho contenido multimedia? ¿Se trata de vídeos? ¿Es contenido consumible durante mucho tiempo?

2. A quién va enfocada: Crucial. Aquí va a decir mucho el diseño y la UX. Y además tendremos respuesta a preguntas como el tipo de visita, ¿Va a permanecer mucho en la web? ¿Es posible educarle? ¿Aceptará todos los cambios?

3. Si es de venta o no: Si lo es, el diseño en pantallas pequeñas puede complicarse bastante y hay que dedicarle aún más estudio, otra vez: diseño y UX.

4. Velocidad: Aquí puede haber respuestas técnicas, como si podemos tirar hacia un mobile first. Hacer cargas por AJAX en función de la interactuación del usuario y la pantalla. Poder tener en cuenta el tema de las imágenes, si tiene muchas, pocas, pesadas, ligeras… Este punto va muy vinculado al punto 1, teniendo las respuestas del 1, obtendremos muchas del 4.

5. Actualizaciones: Va a ser puesta en producción y no va a someterse a mucho cambio o por lo contrario debe haber un equipo trabajando en ella a diario, con cambios constantes… Este punto va más orientado al equipo de desarrollo, pero también incide en el precio y en cómo se le deja el proyecto al cliente, o a quien lo vaya a mantener, o sea que es importante sí o sí.

Y muchos otros factores, aunque esos para mi son determinantes. El resumen es que la elección siempre depende del proyecto, y que no os convenzan de lo contrario: No silver bullet.

Bien, una vez aclarado este tema, ahora sí me enfoco en el título del post, ¿Cómo decantarse por una Web o una App nativa?.

Desde que se utilizan tantos dispositivos como smartphones, tablets e híbridos entre ambos (hay tamaños que ya no sabes si llamarlo móvil o tableta) es una verdadera odisea explicar a los clientes que hay infinidad de posibilidades de afrontar el desarrollo de un proyecto. Muchos de ellos piden una APP para smartphone, o directamente te dicen la plataforma, sin ser demasiado conscientes de que hay diferentes sistemas operativos en los móviles y por ende, diferentes APPs nativas. Además, hay que explicarles que una cosa es una web y otra una APP, cosa que no siempre resulta sencillo.

Está claro que todo depende del cliente y de su proyecto pero debo reconocer que con muchos de ellos me ha costado horrores que entendieran la situación, porque venían con ideas preconcebidas y a la hora de explicarle las posibilidades intentamos acotar mucho reduciendo las preguntas a una ,y lo que ella engloba. Hay que ampliar las miras. como mínimo dando respuesta a los puntos iniciales de este post.

¿Es una web? Con esta pregunta lo que quiero decir es que a veces es más que obvio que lo que te están pidiendo es una aplicación, que no se trata de las funcionalidades que tiene una web normalmente, si no algo totalmente encaminado a ser una aplicación móvil. Es decir. ¿es acceder a información e interactuar con ella?, ¿necesitas datos del smartphone?, ¿necesitas trackear la movilidad?, ¿necesitas que esté offline durante mucho tiempo sin perder funcionalidad? Etc… Y ojo, porque con el API de HTML5 se puede acceder a mucho más de los que pensamos en los dispositivos (aquí os dejo las 15 APIs más populares, y aquí las especificaciones de la W3C sobre HTML5 webapp API).

Si la respuesta es que sí, que hay una información (presumiblemente en una base de datos) y desde la web accedes para consultar, navegar… y que te puedes (o no) registrar, comentar, interactuar, y que en principio no se van a necesitar datos o funcionalidades del smartphone con el que se acceda (que no puedas acceder a ellos mediante tecnología web): Basta con una web (utilizando responsive design, o no, porque esta decisión corresponde a los puntos que mencioné arriba del post).

Si por contra, además de eso necesitas acceder a determinados datos del smartphone y/o utilizar funcionalidades del mismo, etc, entonces sí vas a necesitar una APP nativa, y muy posiblemente para todos los sistemas, a no ser que el proyecto esté enfocado a una plataforma concreta por alguna razón. A este respecto me gustaría añadir que en muchas ocasiones me he encontrado con que la decisión de desarrollar una APP venía directamente del departamento de marketing de la empresa/proyecto (no voy a hacer ningún comentario al respecto, para poder seguir escribiendo tranquilamente y sin alterarme).

¿Es siempre viable la elección con esta pregunta y respuesta? No. Todos sabemos que esta decisión se basa en más datos que en estos, pero es un comienzo… Y dependiendo del proyecto, puede que ya sea suficiente.

Nosotros siempre que podemos apostamos por hacerlo todo desde web, porque pensamos que es mucho más universal y fácil de mantener, además explorar el API de HTML5 es realmente interesante, y como está en constante cambio, siempre salen cosas nuevas con las que entretenerse a probar, lo cual siempre hace el trabajo algo más atractivo. Personalmente creo que para que haga falta una APP nativa debe haber argumentos de peso para ello, de no ser así te verás en la tesitura de tener varias APPs para diferentes plataformas y tener que mantenerlas. Y esto último puede ser un verdadero infierno.

Como se puede apreciar nuestra decisión también gira en torno a lo que creemos que es más eficiente tanto para la web como para el equipo, sabiendo que luego vas a tener que mantenerlo vemos más viable que todo sea un código, con sus excepciones o cambios en javascript, css, o incluso en el servidor, si queremos hacer un RESS (responsive desde el lado del servidor) bien hecho, pero al fin y al cabo: una web.

Ah, algo que no me quiero quedar con las ganas de explicar es que cuando alguien menciona la palabra Responsive parece que está hablando de una solución mágica, de algo casi esotérico y no, no es así. Y tampoco es algo trivial. Quizá es porque se usa mal el término responsive y se confunde con el adaptive (que también da para muchos posts), pero el caso es que hacer un sitio que respete todas las pantallas y dispositivos, que sea mobile first, que tenga una buena experiencia de usuario, etc, no es nada fácil, que no os convenzan de lo contrario, que es lo que suele pasar cuando una palabra se pone muy de moda… que se estruja hasta que pierde su sentido, porque pasa a ser utilizada simplemente como argumento de venta… ¿os suena? A mi sí…

Extra

Además, como muchos de vosotros sabéis, hay algunas formas de lograr encapsular la aplicación en lo que se llama webapp, os dejo algunos enlaces con información:

También hay algunas opciones para no tener que programar una APP para cada plataforma, y así ahorrar algo de trabajo. La que más gracia me ha hecho es Xamarin, que me la recomendaron Alcides y Asier, de este modo programas una vez, y puedes exportar al resto de sistemas. Le falta aún, y hay que explorarla bien, pero es una posibilidad cuando no tienes más remedio que montar todas las APPs.

Aún y con todo, sigo pensando que la mejor opción (habiendo dicho ya que no existe la solución perfecta)… es la de la WebApp.

Escribiendo este post me he dado cuenta que para completarlo bien deberíamos escribir otro del tipo: ¿Cómo decantarse por una Web Responsive o una Web Mobile (o una por dispositivo)?

Entradas relacionadas y que pueden ayudar a entender mejor el post o las ideas vertidas en él

Comparte… ¡o no!
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *