Allow members to access The Mountaineers website off of a browser, and instead on a mobile app. The app could have additional features added to it in the feature, but at present it could perform just the same as the website.

Hello, I just wanted to check in on this old topic. Has there been any more thought on this? I know this is no easy task and I would be willing to volunteer my professional services as a software engineer to at least do a feasibility analysis. I run the Foothills Wilderness Navigation course and a lot of my work is highly repetitive. Being able programmatically manage large rosters and post courses with many activities would be amazing!

I don't see a way to edit a comment but I wanted to add that Adam, if the API gets created shoot me a message, would love to help with the app. I also have experience with Android and came here to ask for something similar.

Hey Eric,

Not sure if this is still an ongoing interest, but had some thoughts:

- Are these third party contributions, or are they something different?

Different. It's more about exposing an API that serves up certain data and then letting developers use that data to build cool things with it.

- How do we safeguard Mountaineers information, such as private member information?

It's up to you what you expose. I would suggest going simple at first and only publishing public info (like the class schedule, and maybe how many slots are open). Once you feel comfortable with that up and running and solve the challenges that come with it you can figure out authentication and private information with things like OAuth.

- How do we support things that look and feel like Mountaineers apps (i.e. when people send a ticket in for an app built by someone else)?
Might make sense to read the answer below. But basically, you put it in the terms and conditions that mimicking the branding of the Mountaineers is not allowed and that you offer API access at your discretion. As for tickets for external apps, I had this problem at a previous job and it wasn't that bad. It's a bit annoying but we basically said "Sorry, we are not the developers of that app, please contact them at ...@....com" and that was that.

- How do we say yes? When do we say no?
Typically you set up the API to require a developer key on every request. You are the sourcing authority for developer keys, so you can make the registration process ask for information such as how the API will be used, and you can layo out what the terms and conditions are. You can also use this to track usage per key so you can figure out if someone is abusing the API and block them if necessary.

- Do we need to have a set of expectations for developers? NDAs?

Mostly just terms and conditions of how your API may or may not be used. An example of one can be found here:
http://www.brewerydb.com/developers/docs-terms

- How can we enforce quality control? Do we need to?

Not sure I have an answer because it's a tough question. I don't think you need to, unless the application claims affiliation with the Mountaineers (which you should put in your terms of condition under the You Shall Not category). Problems that could come of it include potential damage to your brand and the customer service for other apps issue, but I think you gain more than you lose by not trying to control it tightly.

- How do we not break what we have?
It's impossible for me to answer this question. It depends how scalable your current technology stack is. One thing you can do is do "load testing" where you hit your internal APIs with multiples of the requests you currently get (i.e. what happens if I hit my server with 5x the peak traffic I normally get) and seeing what happens. If you do this at night when not many people are using the site it minimizes impact.

There's more to not breaking what you have than just load though, in exposing the data in the first place you may have to make changes to how your data systems work to make it more friendly to outside developers, which introduces risk in bugs. Again, I think it's still worth it, but it is important to consider if you have the team to do any changes needed at the moment.

- What policies do we need in place to make this work?”

Not sure what this means.

Hope that helps, would love to see an API for Mountaineers data out there.

This is an awesome idea! As the chair of our Tech Advisory Cmte, it's a question we're actively trying to allow for. With the broad level of expertise and interest in doing so, the question is "how".

However, that poses lots of questions, such as:
- Are these third party contributions, or are they something different?
- How do we safeguard Mountaineers information, such as private member information?
- How do we support things that look and feel like Mountaineers apps (i.e. when people send a ticket in for an app built by someone else)?
- How do we say yes? When do we say no?
- Do we need to have a set of expectations for developers? NDAs?
- How can we enforce quality control? Do we need to?
- How do we not break what we have?
- What policies do we need in place to make this work?”

If any of you who like this idea are willing to help us determine what approaches we can take, please contact me directly. We really want to support this!

Thanks,
Eric Linxweiler

It sounds like Adam might be a great expert among our volunteers to help with the development of our mobile functionality!!

Joe,

You might also want to add similar comments to these two ideas:

Improve Trip Reports - https://mountaineers.uservoice.com/forums/273688-general-feedback/suggestions/6763358-improve-trip-reports-sd22

Activity and Routes & Places Map Search - https://mountaineers.uservoice.com/forums/273688-general-feedback/suggestions/6732775-add-activities-and-routes-places-to-a-map-sd184

Jeff

A++ It would be great for trip reports to. If there was a way to search for trip reports (via API) by date and lat/long, it would be amazing

I fully support this idea and would like to add that our branch and committee websites could be made more functional if we could "pull" info from the club website through a published API. As it stands, we can only do it by "screen scraping" html responses which is a horrible proposition for our volunteer webmasters.