Map Implementation for Travel Site
Being a developer and a profound user of Goibibo, we always push ourselves to develop nextGen features for the site. Features which eases the pain of a user of making the best itinerary for their travel plans.
Once, while searching for a suitable hotel at the site, i noticed myself copying the address of the Hotel from the site and pasting them on google map to get the distance of it from the famous/tourist places. As i knew the site code, i wrote a quick script which started telling me the distance from the fixed few places from each hotel i visit on the site, in the developer console.
It got me thinking, how many people face this problem? I asked a few, and eventually they all happen to do so when they search for a hotel in a city. Be it for business purpose or leisure, mostly everyone was google-mapping the address.
Enhancing the MAP
Now that the problem was known, we started on the solution. The site already had a map implementation where location of the hotel was plotted. With use of the Google Map Autocomplete & Google Map Distance Matrix API map was all-set to ease user’s life.
With the right blend of integrations and UI, map was up and ready. The only thing missing was “That Spark”. That charm which makes the product stand way ahead of others. As the tools used were open-to-public hence this was something easy to build. And as they say “Great things never came from comfort zones”. Hence, we started to dig-in more.
Eliminating the Unwanted
The first thing we grabbed was the zoom level. We made a zoom-adjuster. Map auto adjusts to such a zoom level where all your places searched are in view. That eases user’s pain of adjusting the zoom level every time they search.
As the Matrix API return the whole route information and route map (in words step-by-step), we thought this information will not be useful for the user. Showing just the time estimation and distance would work. Hover to glow the marker, easy-click to close tabs etc… were few enhancements done to complete the product.
User Behaviour Study
The product was integrated with the site and was launched. Response was tremendous. Around 10% of the people were using the feature. Numbers kept growing day by day, and the team moved on to the next task.
After a few days, we noticed, users were searching for the same place multiple times. We were surprised, and couldn’t think of a reason why! Few hours gone, and we realised while searching for hotel, users would be searching for tourist places at each hotels map, by going to each hotel they shortlisted. What’s next;
We analysed the situation and drove a solution immediately. Localstorage. As soon as a user searches for a place on map, we store it in the localstorage. The data is stored city wise, which means, all the places searched over the map of a hotel in “ X “ city will be automatically shown to all the MAPs of hotels in city “ X ”. Hence, a user just have to search once, and can see the distance for those places from any hotel at their respective product page.
These bits and pieces completed the product and was widely used by the users. Although there is still a good number of users who are doing same place search multiple times. Turned out that they open multiple product pages from the product listing page hence, the localstorage sync couldn’t work.
Up next, we will implement the sync in-between tabs by listening to the localstorage events. This will benefit in a lot other ways too, say, syncing dates / room configurations between the open tabs. Moreover, we have formatted our data in such a way that we know what people search fromwhich area. Say, if we have more searches for TAJ MAHAL (place) from a particular area in agra (city) we will provide that as a pre-filled data in the map for that area/city.
This exercise taught us about how to mould the technology and resources according to the user’s behaviour.
Click to see the product in action : goo.gl/71Bpdz (open as desktop page)