Motivation

The best hitchhiking resource to anyone, be it a veteran or a beginner is the Hitchwiki. Among the countless articles, explaining the ways to hitchhike safely to surviving in gas stations, the best is the Hitchwiki map. Over the years, countless hitchhikers have contributed to this map with locations they’ve hitched from. It was a great resource while hitchhiking as it would show nearby spots, or spots in cities im planning to go to and thus I could get dropped near that; it can hours to cross a city by foot so being dropped near a high traffic exit would give me the greatest chance of hitching a ride out. However, over the years, the map lost a bit of functionality (being unable to add new spots) and even wasn’t loading for a few months. One day, while I was browsing the wiki, I found a page that had an export dump of their entire database, containing all 25k hitchhiking spots, which was just around the time I was trying to get into mobile development and I was fishing around for a project.

Why not make a mobile app for hitchwiki !

Research

I had dabbled a bit in React Native development with the Expo network. In retrospective, the framework felt slow to use and the load time for the software was terrible. The alternate choices I found were flutter and ionic. Making the choice for flutter was quite easy since the ionic framework simply renders JavaScript components meaning that the app would be really slow. On the other hand, Flutter is developed and maintained by Google and it rendered it's components to native components. This means that not only the app be faster but also there would be a ton of new support while learning this new framework

Why not kotolin or swift ?

In recent years I had heard more about these cross platform frameworks and I was really excited to try out them first. This was also my first time developing for the mobile platform, so I didn't want to over complicate the developing environment, when everything else was so new. Being able to code for both an iOS device and a Android device sounded really amazing and I wanted to learn how flutter had made this possible, which made is easier to overlook some of the fine tuning you're able to do when coding in the platform’s native languages.

Design

The entire design was inspired by Google Maps. I’ve been a huge fan of how google maps implements it’s review system and I wanted to emulate that. I took a few screenshots of google maps, copied it over to Figma and started work on how I wanted the layout to look. I spent most of my time here figuring out the information structure and tried to adhere to the Google Maps design as closely as possible. As a new designer, I wasn’t confident in making User Interfaces and so I figured I could replicate google maps and try to understand why it works.

Development

Having only had developed sample applications in flutter, this was my first time combining every thing I had learnt before to a single project. This is my favorite way of learning a project, since it requires you to creatively combine what you already have learnt and along the way, you discover unique problems that requires to be solved creatively. I started the development with the core functionalities in mind

1. Display a map with locations
2. Cluster locations together to reduce visual clutter
3. Add locations to the map
4. Add reviews to these locations.

Using Firebase as a back-end service, I didn’t have to write any code with databases or authentication. The 2nd party Firebase libraries would handle this for me, and I would write the logic around that, expressing how data was to be added and which pages were shown for authenticated users.

After the initial version, I shared it among a few users on the hitchhiking sub-reddit where they helped me discover some unique edge cases. As with developing for devices that have variable screen sizes, it turned out that some locations weren’t getting clustered properly. I fixed this by tweaking the numbers on the clustering algorithm such that only points within the screen were considered for clustering.

In the next step of development, I focused on enhancing user functionality. I added a login feature such that while all users could view locations, only users that were logged in could contribute. This step required me to design a login flow that would allow a user to login in via google and set a display name. Most hitchhikers do not want their public names to be showcased and I understood that it would be better to ask them for a display name than extract it from their google account.

To polish up the app, I started to implement in Material animations. This is a great moment to talk about the material design kit. Developing for flutter, google has made it super easy to work with material by providing pre-built components that would be rendered natively. As a new designer, material was a great toolkit to understand the principles behind design. It would explain how and why to use components that I rarely had any doubt when creating this UI. These animations would sit inbet

Finally, I introduced an on-boarding process to help new users understand the core features of this app.

DevOps

During the initial stages of development, I was using an emulator and my personal phone to side load the app. However, once I got to the initial alpha stage where I deployed it on the playstore, I soon understood how time consuming it was to assign the correct version no, build the app, upload it to the play store & finally publish it. To automate this entire step, i decided to use the power of github actions and fastlane to help automate these steps. With this, once I push my code to mainand fastlane takes care of building, signing and uploading the app to the playstore. It will also create a new release in the alpha track. This allows me to review the release and publish it. Once I test the alpha version on my test devices and alpha testers, I merely have to push it to the release track and it is available to the public. With this, I was able to automate a step that usually took me close to an hour down to a single line of git push.