Hey-o,

I've got a branch with a grid picker component all setup and passing the grid assets to tagmanager.

This "works" but but after some discussions with @paperboyo it's very clear that for it to work in the wider context we'll need integration across more tooling.

I'll break down the problems on a per-component basis...

Grid:

Currently people are using the S3 uploader which is very fast, but very dumb. Moving editorial people to using the grid will increase the amount of time it takes to upload an image and add all the appropriate metadata from maybe 10 seconds to maybe 2 minutes. Particularly with byline images, this could easily become quite a tedious deduction in productivity for very little benefit.

Ideally tagmanager would have a special path to upload the image and provide additional metadata (name, description, etc). This would maybe be a useful addition to the grid more generally allowing us to enforce certain properties depending on the tool. For example MAM should only allow landscape aspect ratios. Tagmanager has certain requirements regarding transparency on the large and regular byline images.

There's currently no separate area for contributor photos to live. We'd rather contributor images were not used in articles. It makes sense that tagmanager would bring up the iframe in a special way that would only display contributor images. Other tools (composer, MAM, etc) shouldn't be able to access the images.

Consumers (CAPI, MAPI, etc)

Currently the bylineImage field is passed to CAPI and from there is cropped by imgix on the frontend, but we need to make sure this is done everywhere before we can start sending out masters. If any of our consumers just present the raw image then sending a 30MB master would be problematic.

Tagmanager

More of an enhancement than "problem"... In my branch I've retro-fitted the old byline image model which is not as fully featured as the Grids. If we're going to do work in other tools to make sure this works then it's probably worth modifying this model to allow other tools to select which asset quality they want. This shouldn't be much work for tagmanager.

@currysoup @paperboyo My response...

Grid issues -> Don't agree about adding more information/validation for images, all this validation can be done by the tools that are receiving the images... if they need a certain aspect ratio... they can validate.

It takes more time, but I wouldn't argue it's 10 seconds to 2 mins, I'd also argue that the s3 uploader was a hack and shouldn't be compared against.

I don't see why we need to enforce the no contributor images in other media, photos are being selected by humans, I don't see the issue if they determine that it's the most appropriate image. It might actually be, it's not a special image... it's an image.

Consumers --> We can't change the representation of bylineImage to be anything other than a single url, could we model a seperate byline image field containing alot of grid information including the master size, then just intelligently select a reasonable sized image to go in the existing location. We have the information to do this.

@clloyd

adding more information/validation for images, all this validation can be done by the tools that are receiving the images...

Metadata requirements are different to validation. Extra information and e.g a crop is compulsory in Grid world, not so in s3-uploader. This adds a lot of work. If the image could be dropped into TagManager and would automagically end up in a special Collection in Grid with metadata drawn from the tag and with an automatic full-frame crop created - that would actually speed up the current workflow. Anything else will be slower than how it currently is.

When it comes to validation: currently, it’s not there. But both these types have very tigtht spec and 1st party consumers expect them like that. We may not add any extra validation. But if we would like to do this, TagManager seems better fit than expecting it to be added to all clients separately.

It takes more time, but I wouldn't argue it's 10 seconds to 2 mins, I'd also argue that the s3 uploader was a hack and shouldn't be compared against.

Oh, easily. Can show you. S3-uploader is the current way, so that’s the only thing anything new can be compared against. Before, it was Batch uploader which was quicker than s3-uploader 😆.

photos are being selected by humans

That’s the whole point and a weak link. If 3000 crappy bylineImages end up in Grid - all hell will brake loose. This is an operator mistake bylineImage-destined image uploaded to largeByline field: