Posting on behalf of a Mountaineer Leader.

The location of the "Request Leader's Permission" link is very confusing because it looks as if permission is required to be a leader of the trip rather than a participant.

What's more confusing is that the screenshot is from this trip to Lila Lake<https://www.mountaineers.org/explore/activities/backpack-lila-lake-1>, which is not set up to have any any assistant leaders, so one wonders why "leader prerequisites" are shown at all. I thought I might be seeing a different screen because I am a backpack leader, but the screen looks the same when viewed in incognito mode (i.e. not logged in to the Mountaineers site).

I'm posting this on behalf of friend who had set a timer to be able to sign up for this trip when it opened, and had looked at the page many times and concluded that the "Leader's Permission" link did not apply to them. They were surprised when they were unable to register when registration finally opened.

One possible improvement would be to consider "Leader's Permission to be a prerequisite, and to list it at the top of the "prerequisites" section instead of at the bottom. The fact that is says "Prerequisites: None" is confusing in cases where there is in fact a prerequisite to get permission. I know that's not a "prerequisite" in the sense intended by the website (which of course means prerequisite badges) but may be confusing to people who are unfamiliar with website internals.

Redesign our website header so it is better for mid-size mobile devices and re-organize our site map so that it better includes features we've added since launch (e.g. selling books, find volunteers, lodges), etc. This will involve UX design and some graphic design work.

Add "Locations" to the top level and move Branches, Outdoor Centers and Program Centers there.

Selling eBooks, ability to use promo codes currently in use on mountaineersbooks.org (e.g. buy one get one free) and content migration (pages, blogs, calendars, etc.) are the key considerations. Integrating our two websites will eliminate confusion of where to purchase books, make us look more like the one organization that we are, and allow members and guests to engage with our entire organization more easily. This can happen over time, so in this project, we will build the structure need to make that happen.

On the "My Activities" page there's a "Review Participation Notes" blue button. When I click on that and scroll all the way to the bottom it shows when my badges were added and when they expire. This table of dates is super handy, but having it located here is really klunky.

It seems like all this badge date info should be at the bottom of the "My Profile" page. It would also be nice to list along with the Expire date if it has expired but it's still in the grace period.

I know you already added a date tooltips when you hover over a badge, but that isn't intuitive and it can go away if the entire date table is added below the badges.

The Branch landing page presents a newsfeed (blog) over which the branch has little control and does not make a very useful "home' or "welcoming" page for branch.

Ideally,branches should be able to design/manage landing pages to their liking, but that's another story.

Short of that, I request a better way to prioritize the blogs that appear on that page. As it stands, the page intermixes blogs submitted by the branch with blogs submitted by staff and others. The problem is that the volume of blogs originating from others overwhelms those originating from the branch, causing them to scroll off the page too quickly. The result is that most of the time the preponderance of blog entries have little branch relevance, while the ones that the Branch wants there have scrolled off.

A couple of ideas come to mind. First, procedurally, staff could stop using the branch tags except for unusually important cases. The blogs so-affected do appear on the Mountaineers home page, after all (and it's sort of branch-diminishing to also usurp the branch blog with that stuff).

A more sophisticated approach would be to programmatically give branch-originated blogs priority, at least until their expiration dates.