A little over ten years ago, I had the opportunity to attend a lecture Phil Brown delivered about his then-newly published collection of letters and essays by Bob Marshall, one of the Adirondacks’ three original 46ers and founders of the modern wilderness preservation movement. One detail of the presentation that left a lasting impression was Marshall’s slides – color photographs he had taken in the early twentieth century long before color film technology had become popular or widely available. Bob Marshall may be celebrated as a wilderness advocate, but he was also apparently a tinkerer and technologist in his day.
In the 1930s, Paul Schaeffer organized dozens of volunteers to construct a topographic model of the Adirondack Park. They used the tools at their disposal – USGS maps and aerial photography to accurately lay out the location of thousands of lakes, summits, and transition points between forest and summit.
Technology was also a vital part of Adirondack Wilderness Advocates’ early organizing efforts, such as when we reached out across social media networks to rally support for a wilder Boreas Ponds.
Good visitor use management requires better visitor data than we have today.
As we engage in discussions today about how to deal with surging interest in wilderness recreation throughout the Adirondack Park, and the attendant issues of access and public safety, it seems an appropriate time to consider what role technology should play in supporting those discussions.
We have been talking for some time about adopting the National Park Service’s Visitor Use Management Framework (VUMF) as a model for the Adirondacks, especially the most popular destinations within the park. At the heart of VUMF is an assumption that detailed information about visitors can be collected and monitored continuously to manage visit quality and impacts.
However, the park is quite different from the places that framework was created to support. There are no gates to the Adirondack Park. There are no use fees. So far, very few activities have required permits or reservations at all. The only visitor data systemically collected for public use is the detail visitors self-report at trailheads and boat launches – the ubiquitous trail register.
Today’s monitoring practices tell us little about levels of use at specific sites and how that use is changing day-to-day, week-to-week. I think there is an opportunity to improve the quality and usability of data collected at these entry points. In this wild thought, I want to analyze the current registration process, offer a vision of how that process could be improved, and lay out our roadmap for getting to that improved state.
The current registration process has a lot of paper, but very little data.
Anyone who has visited the Forest Preserve is familiar with the brown trail register boxes distributed throughout the park. Painted with the words “Register Here” in bright yellow, each contains a ledger where a trip leader is instructed to provide basic information about the party: date of trip, name of leader, address, phone, number of people, destination, number of days, and a checkbox to sign out after.
The registers are used sometimes to locate people in emergencies, and some logbooks are periodically tallied to provide monthly counts of visitors before being discarded. Anecdotally, we know many visitors fill out at least some information; however, we know many also walk by without giving the devices any notice. No effort, so far as we can tell, is made to calibrate registration data with actual visitor numbers.
The current registration process is a missed opportunity to understand visitors’ use of the preserve.
First, consider what managers of the preserve might want to know about people visiting each destination in the park: How many are there? Where are they coming from? How well have they prepared for their visits? When do they arrive? How long does it take to reach their destination? How much parking do they use?
Consider some of the questions a visitor might want to know at the outset of their trip: Will there be space for me to park? How crowded will it be? What special conditions should I know about? Are there rules specific to the place or season that I may not know? What equipment should I bring? What if English is not my primary language?
This is all before we consider other stakeholders who might have an interest in visitor activities: Local guides and businesses might find visitor information helpful in determining what to stock, where to sell it, and how to market it. Resource managers need to know where people are going, what trails, lean-tos, campsites, etc. they are using. Enforcement staff need to know where crowding issues are most acute, so they can provision limited resources. Charitable and educational organizations need to know where the gaps are so they can cultivate and advocate for innovative solutions.
What does it mean to build an app around wilderness values?
Visitors to the park already use many apps such as Instagram, Facebook, Twitter, and AllTrails. These tools offer a lot of value, but they are not designed around — nor do they cater to — local needs and interests. What would an app built around knowledge, education, enjoyment, and preservation of the forest preserve look like?
Provide a better registration experience for visitors.
We decided to start a proof-of-concept application to illustrate what the visitor experience could be if registration were a digital process rather than the current paper-based one.
First, a person could register before they depart for the trailhead. As part of that registration they would be able to see how crowded the parking will be, how many other parties will be on the trail, and any special conditions or regulations in effect. These are things that for most visitors today can ascertain only when they reach the trailhead, by which time it is often too late to change plans and preparations.
Second, the person would only need to provide information specific to the visit: where they are going, what they are doing, how many are in their party, and such. The information about the visitors themselves – where they come from, how to contact them, how prepared they are – could be maintained as a separate user profile they only have to submit on their first registration.
Third, visitors can review prompts and notices in their primary language or using assistive technology in their mobile device. A visitor who speaks a different language or is visually impaired could readily access the same level of detailed information that is today only available to those who are fluent in English.
Fourth, the check-in/check-out process is automated. If the visitor registers using their mobile phone, the application can detect when they first reach the trailhead, and log not just that they came in but the time they came in. When they return to the trailhead, it can log their departure.
Educate visitors about the places they are visiting and their responsibilities.
Based on the information provided, the app would steer visitors toward information in their primary language, notifying them of a number of different things:
- It would alert them to key regulations and practices that address the most common management issues – minimizing their impact and mitigating risks that can lead to costly rescue operations.
- It might offer an interpretive tool to help them find some of the most notable features on their route and provide tips on how to best enjoy them – from both an appreciation and a preservation angle.
- It could recruit them to be citizen scientists – reporting environmental conditions, hazards, or infrastructure issues that are difficult for park personnel to monitor in the backcountry.
- It could steer them to brick-and-mortar resources, like guides, interpretive centers, and museums where they can go to learn more.
- If weather conditions or other special events create unique hazards, those locations could be tagged, allowing DEC to push notices to visitors in those areas as they are completing registration. For example, the app might warn a visitor, “A storm has caused significant damage to trails where you plan to hike, and routes may be impassable. Consider choosing a different destination.”
Provide complete, detailed, accurate, and timely data to resource managers.
The tool stores all of this accumulating data in a common database that DEC can then use to support other management objectives. If a person is missing, the application can generate a list or even push a notice with a picture of the missing person and a hotline number to everyone who visited the same places in the timeframe the person went missing. “Have you seen this person on your hike today? If so, please call us…”
DEC might be able, especially as detailed data accrue over time, to accurately predict where parking lots will fill, which trailheads will be most crowded, and where the least experienced visitors are likely to get in the most trouble. Such data could be invaluable to direct precious and limited resources to the times and places where they will be most effective.
Shape the development and priorities of other technologies visitors use.
An online registration tool might also be tightly integrated with other technology visitors are already using. Many visitors to the park use apps like AllTrails to maintain very detailed information about their visits in the park. A public, well-documented API in the registration application might enable those applications to automate visitor registration, and as part of that integration increase their developers’ and users’ awareness of needs these tools do not address well today like visitor preparedness and education.
For example, the registration app might have some basic features to predict crowding, but third-party developers with access to the same data might devise more sophisticated algorithms or invest in assembling data from different sources and companies to build better models. Having the actual registration data in one common place would provide a shared framework for building such tools and assure the most important information remains a public resource.
How we are developing this application.
We envision this application as a starting point for a much wider array of online services that can scale for wider use across the state. Indeed the same information needs that are driving today’s conversation about management of the High Peaks Wilderness are relevant to managers of open preserves large and small across the state. No doubt, there are places in other parts of the Adirondack Park, Catskill Park, etc. today that face the same challenges.
What we pilot here could ultimately become a shared tool for widespread use by other DEC regions, state parks, and land trust managers. It might even be useful in other jurisdictions outside of New York State.
We have decided to develop this tool open source, using agile methods that we hope will allow it to grow and evolve with the needs it is intended to meet and our understanding of those needs.
Ways to contribute
Is this tool the only way to get better visitor data? Certainly not. Is it the best way? Perhaps. My hope for this project is that at the very least it will help everyone with a stake in the management of the Forest Preserve to better understand the opportunities and challenges of improving our understanding of visitor use in the park. And it may produce a novel tool that delivers real progress.
Here are some ways you can help:
- Try out the tool. It is running in a demonstration instance here. The tool is far from complete, but you can get a sense of its current state. We are updating it frequently as we add features to the application’s source code.
- Offer ideas. We are managing development on GitHub, a social media platform for software development. You can register for a free account and comment on issues or raise new issues of your own.
- Prepare translations. Are you proficient in one of the 6 languages most commonly spoken in New York households where English is not the primary language (Spanish, Chinese, Russian, Haitian Creole, Bengali, and Korean)? We would love to have your help translating prompts into these languages.
- Contribute code. Are you experienced in developing modern web applications with NodeJS and ReactJS? We would love to receive your contributions to the application.
- Advise on user experience and evaluation. Do you have a background in UX or web application design? We are looking for help to assure the tool we develop follows user experience best practices and that we are capturing the information we need to properly evaluate usability.
- Donate. Scaling up development and use of this software will require investments in infrastructure. Your donations can help us meet these needs in the near term. See the “Donate” link at the top of this page to learn more.
