I Wanted to Cycle Around Mount Fuji, So I Built a Tool to Help Plan My Trip

I really want to go cycling around Mount Fuji.

That wish made me want to understand the road conditions and what to watch for along the route. What would a line on a map look like on the ground? Where would the climbs fall during a day’s ride, and how should we arrange breaks and transfers?

I brought those questions into the planning process and built a Fuji cycling itinerary page. Later, I also built Field Brief, an outdoor trip preparation tool, hoping to help the people coming with me and others who might want to go in the future.

Several language model updates arrived while I was working on it. This itinerary tool became a concrete project through which I could experience changes in what the models could do.

Helping people understand the trip

An itinerary can tell you where you are going each day. But a list of places and times still leaves you to piece the trip together. For someone unfamiliar with the area, the gap between one place name and the next also involves distance, terrain, and a sense of the physical effort required.

The page therefore puts three days of cycling routes on an animated map. You can switch between dates, play through a route, and compare it with the distance and elevation profile. The display also shows the next stop and the direction of Mount Fuji. Together, these details help people understand a day’s movement before setting off.

I hope the people traveling with me can point to the same map and discuss a particular climb or a place to rest, using it as a shared reference for the itinerary. I also hope they can point out anything they do not understand or want to check. That is where I want the interface to help.

The animated map shows how the trip fits together, while the itinerary and notes alongside it provide the details. Readers can look at the route first, then find the information they need further down the page, without having to read everything at once.

Experiencing model updates within one project

If you asked me which revision mattered most during the build, I would struggle to pick just one.

What stayed with me was how quickly the models were evolving, and how directly I could feel that while working on the page.

In particular, updating the route animation and integrating music into the opening felt very smooth. Even asking a model to help me find GPX route data went smoothly. Changes in model capability showed up in these individual, practical tasks.

Elsewhere on my site, I have also put together a model frontier dashboard, looking at model choices through factors such as the task and cost. If you are interested in which models suit different kinds of work, that is another place to start.

Keeping unanswered questions visible

The more complete an itinerary tool looks, the more likely readers are to trust what is on the screen. That is something the design needs to address when a tool is intended for use outdoors.

A route can be drawn on a map while still needing confirmation that it is passable on the ground. An elevation profile can help explain the terrain, but its data source and estimation method also need to be clear. When a number affects how someone plans their effort or time, they should know how much they can reasonably infer from it.

The current Fuji cycling page retains labels for candidate routes, a revision history, and items still awaiting confirmation from the Japanese side. It also states that elevations are estimated from a terrain model. These notes sit on the same page as the animated map, so people can see the itinerary’s limitations while reading it.

I want the tool to help make the questions clearer. Some things can be understood from the available data, some need to be checked with the people helping locally, and some will need to be reassessed on the ground. Each has its place. Even as model capabilities improve, someone still needs to take responsibility for those checks.

From my itinerary to yours

The Fuji cycling page is designed for this particular trip. I also hope it can help people who want to go later. That led me to build a separate tool: Field Brief for outdoor trip preparation.

Tool website: paulkuo.tw/tools/field-brief/.

When someone else becomes the user, the tool needs room for different requirements. The destination may be different, dates will change, and while some people already have a route file, others are still figuring out where to go.

Field Brief’s public interface divides the process into entering an itinerary, choosing a place and dates, checking the weather and confirming details, and downloading a brief. No login is required, and you can get started without a GPX route file. It aims to bring the route, weather, and items to confirm into a set of trip notes you can take with you.

Not having a GPX file may simply mean the trip is still taking shape. Letting people enter an itinerary and choose a place and dates before working through the weather and open questions means they do not need every piece of information at the first step. That is closer to how I want the tool to support them.

The brief also needs to retain its data sources and the dates they apply to. This is especially true of weather: looking at an example and checking a forecast for your own departure date are different stages. Field Brief labels its example as a demonstration snapshot. Users preparing their own trips still need to look up the information again and confirm it.

Try it with your own questions

As I write this, the Fuji cycling trip has yet to begin. Whether the tool helps during the actual trip still needs to be tested through use.

Which parts of the design will remain useful in other places and on other routes, and which will need adjusting, are also questions for people to explore with their own needs in mind.

If you have a trip in preparation, you can first look at the animated Fuji cycling route, then bring your own itinerary into Field Brief. You do not need to wait until everything is settled. Start with the question you most want answered.