RiddleFox are huge fans of JHipster, a code-generation tool that produces production-quality prototypes incredibly quickly. This post describes how James used it to produce an MVP (minimum viable product) and generate feedback on an idea. We managed to get the basic walkplanner site up and running in under two days – including carrying out our research for the site’s copy.
We wanted to produce a quick MVP for a hiking website. Wikipedia defines an MVP as a release of a product “with just enough features to satisfy early customers, and to provide feedback for future product development“. This is a better way to approach a project than a big-bang launch as you’re soon producing feedback from actual users. Further development can then be based on genuine user behaviour rather than guesses.
The product here is a planner for multi-day hikes. We have lots of ideas where we could take it, but there’s still significant value in a simple planner for a single route – none of the existing resources online allow you to schedule a trip on the South Downs Way interactively. Whenever James plans a multi-day walk, he ends up using a pen and paper to test out different options. This simple feature seemed like something that would work well for an online application.
The first stage in a project, even a small one, is checking to see what is already out there. There are a number of good sites that can help plan a South Downs way tour:
- The national trail website has a map-based distance calculator.
- The same organisation also has a planner map showing filtered items as pinpoints
- The long-distance walking association has a more focussed map of accomodation
- There is also a useful PDF distance calculator on the national trail website
- The sherpavan.com has a simple itinerary builder that works through multiple requests.
- There are also some great static overviews of the trail, the best of which is the rambling man site, which has a good summary of the stages.
- The south downs national park has a leaflet about public transport to different points on the trail. This would be useful information to include in a later version.
Since none of these are interactive, simple planners the MVP here provides a clear benefit, which will hopefully encourage people to use the site.
Before embarking on the site build, there were a number of things we needed to do in preparation.
Integrating a mapping framework
In the past, James has worked with the OpenLayers mapping framework, but this has proved sometimes difficult. Having read a comparison between Leaflet and Openlayers, James decided to build this site using the Leaflet library. A little time was spent confirming that Leaflet and JHipster worked well together based on a useful guide to Angular/Leaflet integration.
There were two Leaflet generators available for JHipster, which promised to produce the neccessary integration code. Since neither of these were up-to-date it was decided to adapt the basic Angular integration in the tutorial.
Producing an angular prototype
The core of the new site was a simple angular component that would allow users to experiment with building up a route. This would be an array of stopping points, along with a list of upcoming places on the trail. Doing this as a simple angular application allowed this component to be worked on in isolation.
Researching the trail
We also needed to gather geographic locations for the stopping points as well as their distance from the start of the trail. The site also needed some copy, which James actually wrote before doing any of the technical work. We also produced a detailed about page.
Writing the copy early was an experiment to see if it worked well to focus on the site’s appearance to a new user. Prototypes are a useful time for this sort of experimentation
Before integrating any technical elements, we used JHipster to produce a simple homepage and worked on making a welcoming, usable layout. JHipster uses bootstrap swatch which enables a rich, customisable layout. There is a risk to such sites that they can look similar, so it’s good to adapt things a little. We also added in some photographs to make the site more engaging to users. This work was done up front to make sure the look and feel would not be constrained by technical decisions.
Putting together the project itself was relativelty simple at this point. James has written on his personal blog about deploying a prototype with JHipster, and followed this method. More time was spent on researching the content for the site than doing the actual development and deployment – JHipster makes things nice and simple. So, early on our second day of development, we could send out link and get some initial responses.
It’s worth emphasising that, while JHipster is fast, it produces a standard Spring/Angular site. All the code produced is scaleable and production-quality, meaning we do not need to rewrite the project if it becomes successful – these are the same tools used by massive companies around the world. In addition, JHipster in unobtrusive, meaning no knowledge of this is needed to be able to contribute to the site. If, for some reason, we wanted to stop using JHipster, it would not require any changes to the code that has been produced.
Another advantage of using JHipster is that even this basic site includes a lot of admin features, such as logging, metrics and user management. There is also a user-friendly admin page for adding new locations to the site. This is included with no extra work required.
As stated above, the intention for this stage of the project was gathering “feedback for future product development“. Judging by the responses so far, people have already said they are going to use this to plan their adventures; and suggested a number of things they might find useful.
Among the suggestions we received were:
- Allowing people to choose the direction of the walk, and to add new stops to an existing itinerary. These were both things we had considered, but it’s good to get them endorsed by
- More information on public transport, helping people get to and from the trail from their houses if they are bnreaking it into a series of hikes.
- There was also a request for map overlays, such as “pubs within a mile of the route“.
- The responsive layout is not working perfectly on some devices. It was also suggested that the map took up more space on a desktop
The MVP is obviously not perfect. There are a few things we definitely need to fix and improve (no-one’s yet noticed the location errors introduced due to mapping projections!) but the site is a useful resopurce, and one we’re planning to maintain and improve. By getting such early response, we’re seeing what people find useful about the site, and have proved that there is a value to it, proving that it is worth continuing with.