Trip report gating

[BillMiddlebrook]

Ha!
I'll continue to keep it simple. If they can't understand some basic formatting stuff, like most of use for our jobs, oh well.

Honestly, I think my mother could enter a trip report here as long as she did it from her phone and didn't have to figure out how to transfer photos to her 15yo laptop.

[supranihilest]

...

Agreed with this. There's already obvious confusion from some users as to what type of content constitutes what type of report, so the less the user has to think about it the better. Introducing additional complexity would just exacerbate the problem. I don't know how you'd do that in an automated way that's invisible to the user, but as a Jira administrator in my "real life" job who has users who drive him up the wall on a daily basis, complexity is the enemy IMO. I don't like holding my user's hands, I just simplify everything to the point where they can't possibly mess things up.

Yeah, I certainly have to make any additional choices in the Add/Edit TR process simple and clear. And when they change the status to "Active" and hit "Save," run through some checks/thresholds and provide suggestions or not.

One idea I had is combine all the different types of reports to one page for the submitter ("Publish a conditions, trailhead, or trip report here") and have checkboxes that dynamically load different sections or something so the user only sees one page for a report but can choose to input data into one or more sections of the all-in-one report page. Then once submitted let the backend separate and post each selected section to the respective report page and tab. I can't quite reconcile how you'd combine trip reports with conditions+trailhead reports on one page, because the former is slow (takes days to months to write, not important to publish immediately) and the latter fast (hours to days to write, important to publish immediately). Users could possibly use the same pool of photos for both a TR and CR too, just select 15 photos from the former to use in the latter, to avoid duplication uploading the same photos to separate TRs and CRs. Presumably whatever storage you're using deduplicates already though. I'm sure there are better ways to do it, that's just one that came to me today.

I think I've been convinced that the Dislike button should go and that Likes should be good enough.

And what about another type of External - "Full report, but hosted elsewhere." If the author selects "External," I could provide information/examples of minimal information to be included in the .com report, in additional to the external link. And we'd be able to filter to external reports, show icons on the Recent Activity area, etc.

So far, that would include these possible types:
Full - A detailed account of a hike/climb and should be helpful for years to come, with helpful photos and formatting.
External - A detailed account of a hike/climb, but hosted elsewhere.
Mini - A short write-up, with or without photos.

I think it's great - sounds really complicated, so probably discourage newbies to post at all. Mission accomplished!

[BillMiddlebrook]

One idea I had is combine all the different types of reports to one page for the submitter ("Publish a conditions, trailhead, or trip report here") and have checkboxes that dynamically load different sections or something so the user only sees one page for a report but can choose to input data into one or more sections of the all-in-one report page. Then once submitted let the backend separate and post each selected section to the respective report page and tab. I can't quite reconcile how you'd combine trip reports with conditions+trailhead reports on one page, because the former is slow (takes days to months to write, not important to publish immediately) and the latter fast (hours to days to write, important to publish immediately). Users could possibly use the same pool of photos for both a TR and CR too, just select 15 photos from the former to use in the latter, to avoid duplication uploading the same photos to separate TRs and CRs. Presumably whatever storage you're using deduplicates already though. I'm sure there are better ways to do it, that's just one that came to me today.

No way SnowAlien will use this!
But I do like the idea of encouraging people to also add Peak Condition and Trailhead Updates whenever they add a TR from a recent hike.

[Boggy B]

Supra pretty much nailed what I was thinking: If you want to go nuts the type of TR could be totally abstracted from the business of creating one, which very much streamlines the process (no more click-throughs or warnings). If you want to give control over the type (Mini, Full, External, whatever else you want to add) you can provide a way to change the selection from default, which automatically sets the type based on the report content when it's activated.

Having (expandable) sections for TH Status, Peak/Trail conditions, and the report content should do a decent job of preventing accidental submission of things as the wrong type. People who are working on a full TR can still post CRs/TH updates ahead of time (leaving the TR section blank, or just going through the existing menus--Peak Conditions Update could link to this form with just that section expanded, likewise for Post a TH Status Update and Add a Trip Report).

Anyway that's enough design by committee from me.

Natalie, the people just want a way to tell you how rad their weekend was.

[seannunn]

Why do we need a TR Mini? CRs already allow up to 15(!) photos and the story can be as long as TRs. I don't think we need another TR "type". If you add GPX functionality to CRs, here is your TR "mini".
And I enjoy slapping that Dislike button. Used to be a "no-no", now it's more mainstream. For the most part, newbie posters don't even notice. I think it's actually useful and works as a "flag" button for the moderator to take the post down.

I don't care too much about short vs. long TR's one way or the other, but there is definitely a difference between a CR and a short TR. Any trip report should contain beta that is relatively long term (don't miss this turn, look for this rock formation, the left side of this gully has the best rock, etc.). CR's should be more about how much snow is where, what stream crossings are like, what shape is the road to the TH in, etc. Personally I look at both before a climb, but they have different functions.

Sean Nunn

[MaryinColorado]

I'm all about discussing ideas for improvement, but the depth of this thread boggles me a bit. If something ain't truly broke - which it seems like current TR mechanisms aren't - no need to go all Tonya Harding on it.

Simplicity does a lot to drive approachability which does a lot to create equity across a spectrum. Make something more complex, it will appear to only be intended for the select few willing to put up with it.

[BillMiddlebrook]

Supra pretty much nailed what I was thinking: If you want to go nuts the type of TR could be totally abstracted from the business of creating one, which very much streamlines the process (no more click-throughs or warnings). If you want to give control over the type (Mini, Full, External, whatever else you want to add) you can provide a way to change the selection from default, which automatically sets the type based on the report content when it's activated.

Having (expandable) sections for TH Status, Peak/Trail conditions, and the report content should do a decent job of preventing accidental submission of things as the wrong type. People who are working on a full TR can still post CRs/TH updates ahead of time (leaving the TR section blank, or just going through the existing menus--Peak Conditions Update could link to this form with just that section expanded, likewise for Post a TH Status Update and Add a Trip Report).

Anyway that's enough design by committee from me.

Natalie, the people just want a way to tell you how rad their weekend was.

Good stuff. Thanks!

[BillMiddlebrook]

So, in review, so far:

• Ditch dislikes
• Update the TR Add gateway to provide more information on styles, with example links and ditch the "Stop, Are you sure you know what the hell you are doing?!?" portion
• Keep the TR Add/Edit process simple
• Based on thresholds, links, content, etc... set a trip report type if it doesn't fit the default (which will probably be FULL)
• Provide a way for the user to enter Peak or Trailhead Condition info on or from the TR Edit process, or at least suggest they post separately
• Add more filtering to the Main TR list page so we can filter reports based on the "type"
• Go fishing...

Oh, and fix the following:

• Problem with multiple peak selection on TR main list page
• Convert older, V1 trip reports to the new format so they can be updated using the same editor

[daway8]

[*]Keep the TR process simple

Yes, this should be tantamount

• Ditch dislikes

Absolutely

[*]Provide a way for the user to enter Peak or Trailhead Condition info on or from the TR Edit process, or at least suggest they post separately

I would be hesitant on this one since, as others have stated, the CR and TH updates are generally more of a seasonal thing. In summer they're mostly just a way for people to advertise that they climbed something and are frequently far less useful than when there's snow on the ground. Obviously exceptions to this but my CR's generally get less frequent in summer due to this.

The other items look good.

[BillMiddlebrook]

^True, I could make the suggestion for Peak or TH condition update to be seasonal, too.

[angry]

Go fishing

Now you’re talking!

[speth]

For a full report versus a mini report, you could just have a cutoff character limit or word count that does the work for you; I think this is smarter than leaving it as an option, and would just clean up the process automatically.

Less than 500 words? That’s a mini report.