Improve logic around artworks / artist rail ordering (client-side)

[mennenia]

Currently, we display an artist rail after every 2 artwork rails without taking into consideration what the artwork and artist rails are.

We have improved our ordering of artwork rails, but it does not change where the artist rails are being injected.

Questions:

• Should this be more sophisticated?
• Should this done server side, as it takes into account what rails to display to this type of user?

[broskoski]

So, in looking at this a little bit I have a few rough thoughts, not sure how helpful they will ultimately be.

In terms of the level of sophistication with what we have available now, I understand the tactic of just injecting artist rails after every two artwork rails feels weird, (esp from a developer standpoint). But from the point of view of a user, it actually feels pretty good. I (embarrassingly) don't use the Artsy app that often but when I pulled it up again to look at this, seeing the variety actually feels pretty natural.

That said, you do bring up a good point that we could personalize this a bit more, if we thought of a few different types of artist rails (after the Figurative Painting rail show artists in the Figurative Painting gene, or after works by recommended artist show other artists based on that recommended artist). I'm sure this is what you are getting at here.

If this is indeed where we are going, there's a few things to figure out:

1. What types of artist rails could we show (artists in gene, artists related to followed artists, etc)
2. big one Will we mirror these rails on Force ( cc @briansw ) or do we want to continue diverging in terms of presentation?

I'm basically thinking (and feel free to offer an alternative, this is mostly coming from a lack of experience with the emission) it might be nicer to offload this logic entirely to metaphysics. Ideally we query all rails, not artist and artwork, and then switch the component on the client based on the type of rail returned.

The alternative (I can't tell if this is lazy or the better approach), is to make another node on metaphysics that gives you an artist rail pairing for an artwork rail. This would mean more asynchronous fetching, but seems like you guys are doing that anyway.

[mennenia]

But from the point of view of a user, it actually feels pretty good. I (embarrassingly) don't use the Artsy app that often but when I pulled it up again to look at this, seeing the variety actually feels pretty natural.

Personally I also agree, which is why it's been fine like this for now - the user experience hasn't been compromised much. The primary reason we're looking into this is because it currently differs from the design spec, where you could have 4 artwork rails before viewing an artist one for instance.

What types of artist rails could we show (artists in gene, artists related to followed artists, etc)

What I can gather from @katarinabatina's preferred ordering is that there are actually only three types of artist rails:

• Recommended artists to follow (and hence personalised to the user)
• Trending artists to follow (the same for everyone I assume)
• Iconic artists to follow (the same for everyone I assume)

I too think it makes sense to offload all of this to metaphysics, because the ordering will depend on what other artwork rails are being displayed for this particular user with their personalisations and so on. Originally, Katarina had made this, which shows what rails people will see depending on how many artists and artworks they followed.

Would it be easy to port that logic into metaphysics you think? (e.g. if the user has followed a gallery, an artist, and favourited a work, show them this order)

big one Will we mirror these rails on Force ( cc @briansw ) or do we want to continue diverging in terms of presentation?

Very good point. cc'ing @katarinabatina and @alloy as well.

[alloy]

Yeah there’s really only 3 types of artist rails for now and that’s going to remain pretty static afaik.

big one Will we mirror these rails on Force ( cc @briansw ) or do we want to continue diverging in terms of presentation?

That I’m unsure of. If that is going to happen it would make things simpler and offloading to MP is totally what should happen.

This difference between Force and Eigen was mainly the reason why I decided to do it client-side for now.

it might be nicer to offload this logic entirely to metaphysics. Ideally we query all rails, not artist and artwork, and then switch the component on the client based on the type of rail returned.

Yup, agreed, that would be very nice. It could then tie into this existing re-ordering logic so that the artist rails get injected in the right locations based on type grouping, rather than indices.

[alloy]

Regarding Force taking a more iOS like approach to laying out the rails, @briansw said they might consider that, so we should probably hold off until that decision is made.

• https://artsy.slack.com/archives/collector-gmv/p1480625579001910
• https://artsy.slack.com/archives/collector-gmv/p1480625920001919

[katarinabatina]

@alloy @briansw I think we won't know if force and ios will take a similar form for some time so I would say lets hold off on making any changes.