Page 2 of 3

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 12:47 am
by Josh Lewis
Good point. The threads themselves usually send to pick up at least a few folks who are opposed to a certain change. But polls are at least fun. :)

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 1:02 am
by Bob Sihler
Fred Spicker wrote:
Page Admins Should not be able to hijack pages


Can't understand why anyone would make someone an admin if they didn't trust them not to hijack.


Do you remember when someone wigged out and deleted a bunch of Bitterroot pages he hadn't created but had admin rights to? Sometimes you just can't tell when someone is going to catch the drama virus.

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 3:35 pm
by Bob Sihler
Although I realize it might create too much clutter, it might be cool to have at least a trial run with inserting a voting bar in the caption section below every picture displayed on a beta page.

This would do two things:

* Encourage more voting on pictures that actually enhance pages-- Many page readers don't want to bother clicking on an image just to vote on it.
* Encourage more use of captions-- Some page makers probably shy from including good captions on the main page because it takes away a key incentive for a viewer to click and vote on the picture.

Please consider at least a trial of this idea and see if it "uglifies" pages or is users really like it. I know that I would vote on a lot more pictures if we had such a feature.

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 3:44 pm
by mrchad9
Bob... If we did that, maybe to reduce the clutter instead of the page view allowing the full range of votes it just has the option to 'like' or thumbs up a photo. Then when registered it scores as a 10. All votes on pics are 10s anyway, since it doesn't really make sense to register something else on a non-text submission.

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 4:55 pm
by Bob Sihler
I like that idea, too, and it definitely would help with the clutter issue.

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 5:08 pm
by mrchad9
Over the next couple of days I'll see if I can think of some way to present it or lay it out. Unless Josh or Matt come up with an method first.

I certainly see benefits in the idea. Often I see new submissions and in addtion to voting on the page I would like to acknowledge 2-6 photos or more they may have featured on it, but I don't always take the time to actually flip though the photo pages themselves to do so.

Also this would help beta photos be more recognized, and photos providing content as opposed to scenery.

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 6:29 pm
by Bob Sihler
mrchad9 wrote:
I certainly see benefits in the idea. Often I see new submissions and in addtion to voting on the page I would like to acknowledge 2-6 photos or more they may have featured on it, but I don't always take the time to actually flip though the photo pages themselves to do so.

Also this would help beta photos be more recognized, and photos providing content as opposed to scenery.


My thinking exactly!

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 10:43 pm
by rgg
There is a standard list of countries according to ISO 3166-1. I suggest that SummitPost uses all those on the list that have the status of officially assigned.

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 10:52 pm
by Scott
There is a standard list of countries according to ISO 3166-1. I suggest that SummitPost uses all those on the list that have the status of officially assigned.


Agreed. When I have the time I'll go through the SP list and see which ones are missing.

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 11:02 pm
by Josh Lewis
Neat idea. I'd be in favor of it appearing on hover so that it wouldn't negatively effect the captions themselves. People would notice over time (plus an announcement of SPV4 will also help). I could draw a mock up of what it could look like (with FireBug it won't look choppy either) if there is interest in having it on hover. I could add a transition to it so that it appears smooth (or not).

Scott, when you have the list let me know. Glad we can get others involved with helping with SP V4. 8)

Re: SummitPost Version 4 in the Making

PostPosted: Tue Sep 24, 2013 11:20 pm
by mrchad9
I am picturing a sort of an icon in the lower right corner, that might be more noticible. Clicking on a photo should also still open the photo's main page so they can see the larger version. Wouldn't want to interfere with that.

Hovering over the icon would explain that clicking on it would vote for the photo, and a click would do just that (without navigating anywhere or changing the screen). And maybe once clicked the icon changes color. It'd also show with the new color if it had already been voted on before seeing the page.

And if the photo is yours or you are logged out then the icon simply doesn't appear.

Re: SummitPost Version 4 in the Making

PostPosted: Wed Sep 25, 2013 1:07 am
by Matt Lemke
Chad I really like that idea. Perhaps to reduce clutter make it possible to right click a photo to like it then the left click opens the photo's corresponding page

Re: SummitPost Version 4 in the Making

PostPosted: Wed Sep 25, 2013 1:36 pm
by rgg
Pictures have lots of additinal information captured in the EXIF data, unless it is expressly deleted before posting. I would like it if SP would automatically use the Date Taken and store that information in the database. Obviously, this would require an additional attribute in the database table where the image data is stored. Having this, it would be neat if it were possible to sort pictures on Date Taken. As an example of how this might help, well, it's nice to see pictures of a certain mountain, but if I want to climb it, it's useful to know how old it is and perhaps in what time of year it was taken.

Perhaps the Date Taken could even be an additinonal, optional field on the image creation/editing page. If the user enters it, fine, if not, check EXIF data and use the Date Taken from there, if available. In addition, I imagine it wouldn't even be too hard to write a script to go through all the existing images in the database, find the Date Taken in the EXIF data and insert it in the appropriate place.

For some modern cameras, the EXIF data can include the location where the photo was taken. As will all GPS-readings, this location isn't always 100% accurate, but in my experience it's pretty good, and it's usually a lot better than no data at all. Therefore, I suggest using this location when available, but only if the user hasn't already entered a location.

Re: SummitPost Version 4 in the Making

PostPosted: Wed Sep 25, 2013 2:31 pm
by rgg
On a different note: sometimes a user uploads the same image more than once. Obviously that's just a matter of hitting the submit button again (and again) when there appears to be no response. It would be nice if something could be done about this, and I can imagine a whole lot of possible solutions, basically along one of three different lines.

1) Make uploading so fast that this never happens again. However, I know this is wishful thinking, there are a myriad reasons why it can be slow occasionally, and I don't believe there is a simple solution that could cover all of them.

2) Upon hitting the submit button the first time, do something immediately on the client side. Disabling the submit button would be nice, and a bit of Javascript could surely accomplish that. This would be my preferred solution, since it works, the user can immediately see that his submit action has had some effect, and I reckon it should be easy to implement.

3) After hitting the submit button, check in the database if the information about to be stored is the same as the information that was most recently stored (by the same user, obviously). The tricky part about this is that I suppose that the name of the file being uploaded is probably not stored in the database. That means comparing the two files would have to be based on file attributes such as file dates and exact sizes. But together with title and, if entered, the image caption, that should be good enough.
While this would work, I don't see it as the ideal solution. It's not user friendly, for it still doesn't give the user an immediate response on the first submit action, and in addition I presume that it's more work to implement than the previous solution.

Re: SummitPost Version 4 in the Making

PostPosted: Wed Sep 25, 2013 3:08 pm
by Scott
One minor feature suggestion:

If it's not too complicated, it would be interesting to be able to arrange the mountains under the advanced tab by number of summit logs. It would be interesting to say compare the most popular mountains in Colorado or California.

Also, responses to summit logs shouldn't count in the number of summit logs (they do now).

These are really minor suggestions though and there are more pressing issues, but I thought it might be of interest.