Desarrollar una app de Metro de Madrid y otras desventuras

A cualquiera que viva en Madrid no le resultara extraño que cuando le hablan de las apps de transporte de la capital uno ponga cierta cara de poker. He probado muchisimas y no he encontrado una que fuera redonda en todos los sentidos. Algo que se hace aun más patente cuando comparamos con apps de otras ciudades, en mi caso conozco bien las apps de Seul y la diferencia es abismal. Sus apps de metro son ejemplares con una interfaz muy cuidada y una usabilidad tremenda.

Primera piedra en el camino, CRTM y Metro

Pero seriamos muy injustos si achacaramos toda la culpa de esto a los desarrolladores. Cuando uno se plantea desarrollar una app de Metro de Madrid el primer escollo que se encuentra son las herramientas e información que proveé el Consorcio Regional de Transportes de Madrid asi como el propio Metro.

El primer problema es que no hay una API abierta con la que poder consultar tiempos de las rutas que queramos tomar, algo que por ejemplo en Seul existe y todas las apps usan. Lo más sangrante de esta situación es que ese API existe y metro de Madrid la usa en exclusiva en su página web y app sin dar acceso público. Y por desgracia ambas, web y app, son bastante deficientes en cuanto a usabilidad e interfaz.

Asi que nos encontramos en una situación en la que al desarrollador se le ventan las herramientas adecuadas mientras las entidades de transporte no crean aplicaciones a la altura de una ciudad como Madrid.

La otra fuente de datos de la que disponemos a la hora de desarrollar la app son los datos abiertos del Consorcio, son una buena iniciativa pero no dejan de ser insuficientes, para empezar porque son datos estáticos que no tienen en cuenta las incidencias del sistema como obras o accidentes, como porque la información es a veces insuficiente se carece de tiempos de transbordo en estaciones entre diferentes lineas por ejemplo.

Ante esa situación la primera decisión que uno debe tomar es usar los datos estáticos que proporciona la CRTM y calcular por uno mismo las rutas, u optar por parsear las llamadas al API que hace la página de metro de Madrid . Al final la mejor solución es usar ambas combinadas. Pero si uno decide usar el API de esa forma tiene que tener en cuenta que no esta haciendo un uso “permitido” y que ante cualquier cambio o veto a su app no podra utilizarla. Y todo por no tener una API pública como deberia ser.

¿Que interfaz creamos?

Tras tomar todas las decisiones pertinentes con las limitaciones de los datos disponibles se nos presenta otra duda, que interfaz elegir para nuestra aplicación. Por regla general se esta tendiendo a una interfaz mixta con un buscador como entrada para encontrar el origen y destino de nuestras rutas, asi como una presentación de la ruta en dos posibles formatos, uno sobre el mapa real de la ciudad y el otro en una linea vertical con las estaciones y transbordos ordenados de arriba a abajo.

Si bien para apps que integran más medios de transporte y tienen una ambición mayor, como Moovit, el uso del mapa esta completamente justificado me parece un error en aquellas que se encargan de una red concreta como en este caso del metro de Madrid. Existiendo mapas esquematicos mucho más limpios con los que el usuario del medio de trasporte esta más familiarizado me parece un error no emplear este mapa, ya no para la representación de la ruta si no para la entrada del origen y el destino.

El buscador como entrada tiene un problema muy grande, y son los usuarios nuevos que no conocen bien la situación y nombre de las estaciones asi como usuarios más habituales que tiene que hacer un viaje fuera de la zona que usualmente transitan. Es muy raro que alguien conozca el nombre y situación de todas las paradas de metro. Aparte de que realmente una vez estas en el metro no te importa tanto que la representación sea 100% exacta a nivel de distancias si no conocer cuanto tiempo vas a tardar de A a B.

Por esa razón veo mucho más adecuada como interfaz para una app de Metro un plano esquematico sobre el que con un toque podamos seleccionar el origen y destino de la ruta, asi como datos adicionales de la estación que marcamos. Apoyado con un buscador que no estorbe pero permita encontrar las estaciones sobre el mapa por su nombre y marcarlas.

Y despues a la hora de representarlas hacerlo sobre ese mapa esquematico con la posibilidad de alternar con la vista en linea vertical. Creo que esta interfaz, que usa app de Seul que reseño, es mucho más intuitiva y con una mayor usabilidad que las actuales, tanto las oficiales como als que no lo son.

Y ahora toca desarrollar

Y en eso estamos, desarrollando la app que nacio como un proyecto académico y tratando de subsanar los problemas que surgen por las dificultades ya explicadas. Lo que llevo desarrollado a día de hoy funciona realmente bien, pero tengo la espina clavada de no poder dar datos más precisos por todas las deficiencias de la administración de Metro de Madrid. En este desarrollo he visto tanto lo mejor como peor del metro de nuestra ciudad, y como CRTM tiene muchisima culpa de la falta de avances en este sentido que nos pongan a la altura de ciudades similares. En muchas ocasiones parece que retrocedemos en vez de avanzar.

Tuve que tomar muchas decisiones de caracter técnico como que modelo usar para calcular las rutas con datos estáticos, Dijkstra, o que libreria que permitiera una imagen del mapa del metro con un zoom adecuado usar. En estos momento tenia un poco parado el desarrollo pero espero que antes de que acabe este año tan loco pueda estar en la tienda de Android disponible para todo el mundo.

Si bien la experiencia esta siendo fustrante en algunos aspectos en otros muchos es un reto muy edificante y del que espero adquirir más experiencia como desarrollador.

Publicado por

My punto geek

Apasionado de la tecnología y la cultura oriental