What's next

[jon]

This is RAD. 100% support this, thanks for doing the work.

 

Quick question. Would you allow users to go back and fix their TRs with proper peak names and locations? I for one would gladly fix my TR locations if this would help with the mapping.

 

Thoughts?

 

 

Yes.

[jon]

You can now right click to add a peak or area. This will have a moderated approval process.

 

[JasonG]

I've waited 10 years for this location! Oh the humanity!

[Tyson.g]

I've waited 10 years for this location! Oh the humanity!

Let's blow off work and Flash Mob the Renton Granite!

 

[BootsandPants]

What I plan on doing is having check boxes for each month, with select all clear all option. Choosing a range between Nov and Feb with two sliders would be confusing.

 

Check boxes are good.

 

What about a date range where the user could enter specific dates? So if I wanted to find all of the Rainier TRs for 2009, I'd just type that range in the specific fields. Something like that is kind of there in the "search" feature already on the site, although you'd have to translate how many weeks/months etc ago your range was. It's not an option on the TR search though.

 

I don't know if this would be hard to implement, I know very little about this internetz stuff.

[jon]

I'll look into adding by year into the current TR system as well as the map based system, it shouldn't be hard at all.

[jon]

I'm still working through the process of assigning past TRs to a correct location. As I stated previously we have close to 7000 TRs, so getting them all indexed correctly is a major undertaking. The automatic way I'm doing it is rather flawed at the moment, so I'm trying to figure out quick methods so that only correct locations are assigned.

 

One thing I was curious about is in the current implementation how many TRs from each of the top users are getting indexed, regardless of whether it is correct or not. I can't get the data to past in here correctly, but Ivan gets the award for the most not indexed and danhelmstadter gets the award for the most that do. Congrats.

 

I'm also starting to build out the interface for allowing a "crowdsourced" review of TRs that are not in the index to be indexed, as well as flagging ones that are not correct. Along the same lines, I'm thinking about a rudimentary nomination process for "hidden gems" that can be listed somewhere. I'm not a fan of rating TRs, but nominating hidden gems seems appropriate.

[jon]

3 weeks sure fly by.

 

I'm curious what people's mobile usage is like for TRs, and whether I need to make this as mobile friendly as possible. Thanks again for any input.

[Pete_H]

Looks like a great resource Jon. Thanks. I'd use a mobile app but I don't think my 10-year-old flip phone would support it.

[BootsandPants]

A mobile site would be sweet. Is the process involved or is there some slick converter out there?

 

Seems like lately I get most of my browsing time done on my phone during meetings

[jon]

Making an application like this mobile is a bit more involved, not so much the code but designing a good user experience. Mobile use on cc.com has increased dramatically to 10% of traffic (this includes iPad which accounts for 31% of mobile), the question is are people actually trying to find info on the road or are they like you in a meeting, on the bus, which you can't really answer without flat out asking like I did above. If it's the later then I'd be less inclined to make a mobile friendly version.

[JosephH]

I went through this exercise two years ago and likewise found the peak data to be the biggest issue. Also, doing a native iPxxx app is one thing, doing a cross-phone app is another and I'd go with phonegap, sencha, or mono if I were going down that road as native android apps are kind of nasty.

[jon]

I've got this partially implemented, more info below.

 

http://cascadeclimbers.com/forum/ubbthreads.php/topics/1076927/Re_New_Trip_Report_Tool_It_s_B#Post1076927