Expand on photo tour abilities (general gallery UX)

[brendanheywood]

Basically the logic is sweet I just want to sex it up.

eg take a photo like this:

http://www.thecrag.com/photo/25014967

It effectively has 5 'streams'. You can tour along one of those streams but you don't get any context when doing so. Specifically I want to know:

• which stream I am on
• where I am in that stream

Flickr does a reall good job of this:

Take a random photo:

http://www.flickr.com/photos/frcornelissen/6107929569/

This photo is available in various ways, like someones fav's, a couple sets, a few groups etc. This same photo is also available at various urls to represent these streams:

http://www.flickr.com/photos/frcornelissen/6107929569/in/photostream/ http://www.flickr.com/photos/frcornelissen/6107929569/in/pool-1461473@N20/ http://www.flickr.com/photos/frcornelissen/6107929569/in/set-72157627407064883/

Depending on what context you are in you see a widget for moving forward and backword in that stream but you can jump across to any other stream at any point.

So translating this to thecrag:

http://www.thecrag.com/photo/25014967 http://www.thecrag.com/photo/25014967/uploaded-by/brendanheywood - photos by Brendan http://www.thecrag.com/photo/25014967/taken-by/brendanheywood - photos by Brendan http://www.thecrag.com/photo/25014967/of/brendanheywood - photos of brendan climbing http://www.thecrag.com/photo/25014967/at/12345 - photos at an area http://www.thecrag.com/photo/25014967/on-trip/12345 - photos on a trip

The templates already work with arbitrary crap appended to them so all this is done in dev:

http://dev.thecrag.com/photo/25042726/at/11742859

What I need now is some api data to know how many photos there are in each stream and where this photo lies in the stream.

streams: { uploaded-by: { total: 72 position: 12 }, taken-by: { total: 133 position: 31 }, of: { total: 122 position: 42 } ... etc. }

This would probably need to be template api data. But then I'd also need to access the stream via ajax on demand to pull more thumbnails on adjacent photos in each stream when the user wants like flickr.

This also enables me to perhaps customise the template depending on the context. If I am in the taken-by, uploaded-by, or 'of' stream it could look like part of that persons account. but if it is the node stream then be part of the index.

I'm not sure about priority. The photo upload feature seem to be almost dead and we may be better off trying to integrate with flickr/facebook/google rather than emulating them.

[brendanheywood]

This should also interface with:

http://dev.thecrag.com/climber/10461469/photos

It is ambiguous wether this is all photos 'by' this person, or 'of' this person or perhaps the union of these two sets?

Similarly with: http://dev.thecrag.com/area/11742859/photos

This isn't ambiguous but could be when streaming along a cliff inside an area, which are two separate streams. In fact there is a stream for every ancestor level.

[scd]

Good point about integration with flickr, etc. Maybe it is better that we get that done first then look at how we want to present the photos.

BTW, I like your ideas.

[cgome]

we may be better off trying to integrate with flickr/facebook/google rather than emulating them.

That's definitely an important part of the solution (also youtube and vimeo).

If we can make it easy for people to easily associate their photos/videos with the right node in the index it's a win win.

[brendanheywood]

I'm kinda thinking we need a generic 'resource' item which more or less works exactly like the existing photo object which can be attached to a route or area node and inherits down. It would sit everywhere a photo could be and be used interchangeably but the only difference is the resource be be a url instead of a local photo. The url could be a link to a blog post write up of a trip or a facebook gallery or a flickr set or an individual photo somewhere. If the url happens to match a set of url's then we can us eth oembed spec to pull them into the site with a bit of metadata.

In this way we can still link foreign objects to the local metadata so we can say this video or blog post is still about this node, has this person or these people in it, and was uploaded by X so we can still traverse the streams as described above, so I still think the work above is useful and valid (and besides it is easy quick job).

The real challenge which I'm not sure if it is even possible depending on the system, is some sort of automatic or semi automatic linking on the foreign site. So on flickr and easy but nerdy system which I used on the old Gara gore guide was to tag a photo with 'bouldering' 'gara' and 'N14' and it would automatically turn up in the guide using the flickr api. So on flickr it could be as simple as 'thecrag' a a tag and '1234567' as the node ID. To really make this work I think we'd have a process which listened each day to any new items which had 'thecrag' as a tag, match those to the flickr account and then possible to a thecrag account (people would have to add that linkage to their profile) and away it goes. At the moment there are 1500 photos tagged with 'thecrag' so perhaps 'thecrag.com' would be better. Flickr has a concept of tagging people in photos which we could also leverage but it doesn't have a lot of uptake, and would mean we also need to know those people locally (we can just list the name without a link).

Picasa is a lot more locked down and less social but has a good api. Youtube and vimeo are also good on the api side but don't have any social aspects to them. The big one is facebook which doesn't have a good api but would be the real one to crack. You can't tag non-human people in photos. I'd love to be able to just tag a route directly in a photo, and have each route represented in FB land using the opengraph protocol but it just doesn't do it (yet). The next best hack might be to have a 'thecrag' user who you can friend and tag in a photo. We then have a nightly crawler which doesn't as much metadata scraping as it can (only with public images). It could match at least to the area level based on geo data if present in both systems.

[cgome]

I like the idea of the 'resource' I had thought as far as 'media' but this is even better.

We then have a nightly crawler which doesn't as much metadata scraping as it can (only with public images). It could match at least to the area level based on geo data if present in both systems.

Once we get something in to the site and matched as closely as possible to right node automatically (using geo data, tags whatever), we should make it as easy as possible for users to locate it more accurately.

eg. From Flickr we automatically import/link to 10 new photos at Arapiles.

Someone recognises that one of the photos is Pilot Error so they can easily assign it to Pilot Error's route page.

[brendanheywood]

The area tours are going to be a little tricky. If I go to a route, I should be able to see all photos for that route:

/route/12345/photos

if I click on photo then I should then see that photo in the context of that route

/photo/34567/in/12345

It should show all the various 'tours' but the highlighted one should be the tour by that route, so you click next a couple time and then keep going through the photos attached to that route. All this is just template side logic I can do.

The fun starts when we consider that we can also view the same photo through an area tour for each of its ancestor nodes. So you could tour the same photo from an area photo page, or a region photo page. This has to be server side as it needs to understand the url suffix and give different data to the template:

/photo/34567/in/12345 photo in route /photo/34567/in/12346 photo in cliff /photo/34567/in/12347 photo in area /photo/34567/in/12348 photo in crag

Another thing that I found a bit non-transparent is the concept of a persons photos:

/climber/scd/photos

I assume this shows all photos that have anything to do with that person, whether taken by them, uploaded by them, or they are in it. That url is fine but we also need to be able to access the subset of each, something like this:

/climber/scd/photos/taken-by /climber/scd/photos/submitted-by /climber/scd/photos/climbing

(I'm not super happy with these urls, it would read better if it was the other way around like:

/photos/taken-by/scd /photos/submitted-by/scd /photos/of/scd

but I can live with it as is)

So if you are on a photo page, like:

/photo/12345

and then tour to the next photo taken by the same person you should go to

/photo/12456/taken-by/scd

and then next again to

/photo/12457/taken-by/scd

and then can zoom out to all photos 'taken-by' that person (not all photos related to them)

/climber/scd/photos/taken-by/

Also while we're on the topic, can a photo have more than one person tagged as climbing in it?

[scd]

There are a number of issues going on here but I have made some inroads into streaming. Once we are happy with the photo page streaming we can close this issue and open separate issues for anything remaining. The photo page now has a streams variable:

data->{streams} = { 'at' => route/area 'at-area' => rolled up area for photos which are downloaded to a descendant area or route 'on' => # trip 'uploaded-by' => 'taken-by' => 'of' => # climber }

each stream has the following information: id: the id of the stream entity total: number of photos in stream position: starting at 1 stream: array of up to 7 photos, the reference photo plus 3 previous and following photos in the stream. This means that you can include thumbnails of the nearby stream images without using the api area: (only for the at-area stream).

The 'at-area' needs special comment because a photo can be at a route and at a rolled up area at the same time (ie photo uploaded to route but part of a rolled up to the area stream for each of it's ancestors). If the at-area parameter is specified then the at-area stream is included as well and also includes the 'area' node details. Maybe it should be called at-ancestor?

I have not done the API yet, as we can hack through some experimental screens to work out exactly what I want.

Due to an internal hassle I have made the stream specification a parameter rather than part of the url (fixing this can be logged as a separate issue). So you would call the stream: /photo/1234?at-area=456

In repo.

[scd]

BTW, I'm interested in how we solve this because we will probably end up solving the ascent streams in a similar way, eg

ascent/1234?on=5678

For ascents we have the following streams: by: on: at: at-area: (although I might abandon this one because of the shear number of ascents at some areas).

Campbell got excited the other day at my house about ascent tours because it is something which works in really nicely with trips and could be something people would post on their facebook page.

[brendanheywood]

Yeah we are almost building up a domain language for searching

/photos/uploaded-by/scd /photos/of/brendan /photos/in/12345

could be added to become:

/photos/uploaded-by/scd/of/brendan/in12345

A few other minor bits of url syntax and we'll have just about everything we need for a full faceted search:

/ascents/by/scd+cgome+brendan /ascents/on-trip/12345

/ascents/by/scd+cgome+brendan/on-trip/12345

/ascents/by/brendan/harder-than/V2/easier-than/V7

or perhaps more succinctly:

/ascents/by/brendan/graded-between/V2-V7

/ascents/in/12345/harder-than/V6/before/2009 /ascents/in/arapiles/harder-than/V6/before/2009

/routes/in/buffalo/with-style/trad/higher-than/100m

/climbers/in/australia/interested-in/sport/can-climb/21

[scd]

it looks like we edited simultaneously. I did not read your comments until after I had finished my write up.

I think we should log the 'climber/scd/photos/submitted-by' as a separate issue. It means you cannot have a see all on some tours until this has been solved.

[scd]

cool ideas about domain language for searching, it links in a few to-do ideas.

[scd]

btw, only one climber per photo at the moment. If we need to expand that then I have to change database structure.

[scd]

ok you inspired me to do a photo implementation of your query language as a test - yup I think it is cool. pull from repo and try

http://dev.thecrag.com/photos/at/11740915/uploaded-by/165201489+11183449/json

The json is optional, but I have not done the template code so there is no point in looking at it without the json. This should return some photos.

At the moment it is restricted to ID's only, so /photos/of/SCD will not work.

There are a couple of configuration, but I have done very limited testing. The + should work with all the following.

• uploaded-by
• taken-by
• on
• of
• at (rollup search)
• at-route (direct node search)

Certainly no rush for this release. There are some other significant issues I have to overcome to solve the routes, ascents and climbers. I think we will work through each as separate issues.

[brendanheywood]

gold! pure gold

Only data tweak I can see needing is swap out the id's for the basic record data:

at: '12345'

becomes:

at : { id: 12345, name: 'gara gorge', ... }

or for multiples

at: [{ id: 12455, ... }, {id:23456, ...}]

I'll show in the left menu what the current filters are and add controls to add facets etc

If we want full facets we'll also need a summary for each facet. I'll spec that after festivus

On Sat, Mar 31, 2012 at 3:38 PM, scd < reply@reply.github.com

wrote:

ok you inspired me to do a photo implementation of your query language as a test - yup I think it is cool. pull from repo and try

http://dev.thecrag.com/photos/at/11740915/uploaded-by/165201489+11183449/json

The json is optional, but I have not done the template code so there is no point in looking at it without the json. This should return some photos.

At the moment it is restricted to ID's only, so /photos/of/SCD will not work.

There are a couple of configuration, but I have done very limited testing. The + should work with all the following.

• uploaded-by
• taken-by
• on
• of
• at (rollup search)
• at-route (direct node search)

Certainly no rush for this release. There are some other significant issues I have to overcome to solve the routes, ascents and climbers. I think we will work through each as separate issues.

---

Reply to this email directly or view it on GitHub: https://github.com/theCrag/website/issues/288#issuecomment-4856154

cheers Brendan

http://thecrag.com/ http://github.com/brendanheywood

[scd]

I have played around with a simple ascents query as well to test a new back end table (in repo)

https://dev.thecrag.com/ascents/at/11740915/by/9068185/json

It's out of scope at the moment to do all the nice queries that Brendan suggested for ascents, but what I have implemented is:

• by
• on
• at similar to the photos language.

The main reason why I wanted to test this before the release is that we have a new Ancestor Collector table which links any node with all it's decandants - yup a massive table of about 8x200000 records.

If this table works ok then this solves a whole lot of problems in the backend and I can simplify a huge amount of backend code, from stats, feeds, favourites, and activity. This will be a massive enabler for me to quickly resolve many outstanding issues. I wanted to get the change into prod this release so I can get it stabilised before committing a whole lot of code to it. I guess the two issues I want to see working is the performance of a big mysql table (seems good) and make sure reparenting works ok (if you reparent a country or big region then there are heaps of records which need to change).

I have tested both issues and they seem to be fine.

[scd]

What about using this technique for resolving part of issue #54 ?

eg

https://dev.thecrag.com/favorites/by/9068185 https://dev.thecrag.com/favorites/at/11740915

Now that I have this new table this should be about an hours work to implement.

[brendanheywood]

sounds great

getting stats, favs, users etc summaries for any node I think will be critical for making the site more transparent and easier to understand.

On Tue, Apr 17, 2012 at 11:06 AM, scd < reply@reply.github.com

wrote:

I have played around with a simple ascents query as well to test a new back end table (in repo)

https://dev.thecrag.com/ascents/at/11740915/by/9068185/json

It's out of scope at the moment to do all the nice queries that Brendan suggested for ascents, but what I have implemented is:

• by
• on
• at similar to the photos language.

The main reason why I wanted to test this before the release is that we have a new Ancestor Collector table which links any node with all it's decandants - yup a massive table of about 8x200000 records.

If this table works ok then this solves a whole lot of problems in the backend and I can simplify a huge amount of backend code, from stats, feeds, favourites, and activity. This will be a massive enabler for me to quickly resolve many outstanding issues. I wanted to get the change into prod this release so I can get it stabilised before committing a whole lot of code to it. I guess the two issues I want to see working is the performance of a big mysql table (seems good) and make sure reparenting works ok (if you reparent a country or big region then there are heaps of records which need to change).

I have tested both issues and they seem to be fine.

---

Reply to this email directly or view it on GitHub: https://github.com/theCrag/website/issues/288#issuecomment-5166296

cheers Brendan

http://thecrag.com/ http://github.com/brendanheywood

[brendanheywood]

Yeah #54 is exactly what I had in mind when you mentioned the collector table.

I also want to see something similar with users, ie the new 'climber' tab. For any node see who edits it, whos climbed there, who's sponsored it, all in one place.

[scd]

It sounds like we are both pretty happy with this new framework for general queries - sometimes there is a reason why we take so long to implement.

The user thing you mentioned is probably just using activity as the query entity. Or are you getting at a creating a summary page with all the interesting stuff combined. Quite possibly there is a bit more to think about here, but we can almost definitely leverage this new framework.

[brendanheywood]

continued in #507

[brendanheywood]

note for later http://photoswipe.com/

[brendanheywood]

+1 from supporter

[killakalle]

Not sure if this is the right thread. But I'd already be happy if there was a way to conveniently browse the photos in their large version of an area or route. Currently:

• view all photos
• click on photo to see large version of photo
• go back to all photos
• click on next photo to see large version of photo
• go back to all photos ... and so one. Quite cumbersome.