Create a new page for each finished artboard

[erasmus]

When user clicks finish button under artboard, a page with a unique URL is created with:

• the generated Cloudinary image
• buttons to share on FB, Twitter, Tumblr or download

[avorio]

We need to further specify what parameters are available in this context.

I've implemented a basic view based on version_id, image_id and image_extension (84528cb3f29441c164dec10fcaaa3b4b2e425c32).

Example URL:

http://127.0.0.1:8000/artboard/v1469062806/ukurrogkmnr29udbfdo4.jpg/

Replace the values above according to the background image uploaded to Cloudinary.

The URL is not exactly pretty though :(

This gets me the background image, but not the cutout nor the text. Should we pass those variables via the URL? Those values could be query strings, for example. Hack-y, but it should work for now. I'd prefer to store those values a priori and permanently in the Artboard model object, but I'm not exactly sure how to achieve that yet. I'd need to review your integration with the upload engine.

While I do that, shall we move forward with the query strings? Replacing those would be easy later on; and these values are necessary for the Cloudinary URL construction anyway (#29).

[erasmus]

URL prettiness: not a problem for now. We can prettify at a later stage if needed.

Upload engine: the bg img upload UI is still very much WIP. Basically, does the same as your upload.html example.

Now, when the additional variables (text string, cutout overlay url) should be sent to Cloudinary is when user clicks the "Finish" btn.

(When the button is clicked, user is taken to the Artboard page which presents final image with social media sharing btns).

Onclick, I extract the values for 3 items on the artboard via JS:

// WIP
  $('.finish').click(function() {
    var bg = $('#artboard').css("background-image").replace('url(','').replace(')','');
    var cutout = $('img#artboardCutout').attr('src');
    var text = $('p#userCoverTextEditable').text();
    alert("BackgroundURL: " + bg + "\nCutout img: " + cutout + "\nEdited text: " + text);
  });

We now have the 3 variables and can parse them to wherever we want. Does it make sense to do this with JS?

Query strings: yes, let's generate the artboard via query strings for now. The way I saw this was the following:

1. When user clicks "finish", an image generated via Cloudinary's GET request (with user variables in the URL ... e.g. uploaded img URL, text string, and chosen overlay).
2. That Cloudinary generated image is fetched as a complete image and stored somewhere (not necessarily Cloudinary).
3. Complete image is shown on our "Share Artboard" page.
4. User can share that complete image on social media.

Does that make sense to do? My point is that we avoid the constant GET requests to Cloudinary

[avorio]

As I mentioned in #29:

Here's how the Cloudinary URL is constructed:

http://res.cloudinary.com/geist/image/upload/l_<overlay_image_id>.png/l_text:helvetica_40_bold:<text_escaped>,g_south,y_100,co_rgb:FFFF0080/<background_image_id>.jpg

Example:

http://res.cloudinary.com/geist/image/upload/l_guys_ujyh0m.png/l_text:helvetica_40_bold:User-generated%0Atext%20goes%20here,g_south,y_100,co_rgb:FFFF0080/bg-1_ybsxie.jpg

http://res.cloudinary.com/geist/image/upload/l_dp-cutout4.png/l_text:helvetica_40_bold:User-generated%0Atext%20goes%20there,g_south,y_100,co_rgb:FFFF0080/bg-1.jpg

[avorio]

Alright, I have just implemented support for query strings. See 7d4bb86d0b0241290255f7bd7bbb11abd926e03b.

An example URL could look like this:

http://127.0.0.1:8000/artboard/v1469065298/bcv1vxkhzbvcici2ksyj.png/?cutout=dp-cutout3.png&text=go+crazy

You should be able to construct this URL with the variables available in your click function.

The parameter cutout should refer to an image already hosted in Cloudinary. I've uploaded the four cutouts that were already in GitHub, so you can use any one of them:

dp-cutout4.png
dp-cutout3.png
dp-cutout2.png
dp-cutout1.png

The parameter text must be URL encoded.

And finally, we have to figure out the sizing and cropping settings. I've tried a couple of parameters but my brain froze. I suck at cropping images, for some reason. Here's a link to the documentation:

http://cloudinary.com/documentation/image_transformations#resizing_and_cropping_images

Could you have a look at this, please? I remember struggling with cropping in the past and you walking straight into it and nailing it. Remember that? We were sitting at the back of a cafe in Berwick St., SOHO. Anyway. We have to consider that users will upload images of various sizes and ratios. How do we handle them? Do we crop? Resize? Scale up/down?

Also, the "Dan & Phil" bit — I reckon the easiest solution would be to embed it in the cutout image files. If you're in agreement, update the images and I'll re-upload them to Cloudinary. Or you can do that yourself. I'll email you the credentials to the Cloudinary web console.

[erasmus]

Cutouts: so I take it that Cloudinary only allows for one overlay image, correct?

Cropping: It's all about the fill, baby. But don't worry, I'll deal with all those image manipulation parameters. I can construct that no problem. (tracked in #42)

Dan & Phil bit: Including them in the cutouts files is really hackaroundy and prone to error. But I guess if we can only incl 1 overlay image, there's no other option. I'll talk to client about this, as they may not want the funky "Dan & Phil" anyway.

Storage question: So In my previous comment, I asked about letting Cloudinary do the image manipulation and then store the finished image somewhere else. That was to save on the plan with CLoudinary. Do you know if each crop / text-overlay/ etc. is counted as a transformation? Because in that case, we're limited to only 75k per month. And if so, we need to fetch the finished image from Cloudinary and store somewhere else (as I assume each call for the image, will count as another transformation...).

Am I misunderstanding something here?

[erasmus]

Oh, another thing. There are some pre-existing backgrounds that user can choose. So we need to upload them to Cloudinary too. They're not available yet, however.

[erasmus]

Also, can't get this working locally. Do I need to run any updates/migrations?

[avorio]

Cutouts: so I take it that Cloudinary only allows for one overlay image, correct?

That is my understanding too.

Cropping: It's all about the fill, baby. But don't worry, I'll deal with all those image manipulation parameters. I can construct that no problem. (tracked in #42)

Thank you! :)

Dan & Phil bit: Including them in the cutouts files is really hackaroundy and prone to error. But I guess if we can only incl 1 overlay image, there's no other option. I'll talk to client about this, as they may not want the funky "Dan & Phil" anyway.

Ok.

Storage question: So In my previous comment, I asked about letting Cloudinary do the image manipulation and then store the finished image somewhere else. That was to save on the plan with Cloudinary. Do you know if each crop / text-overlay/ etc. is counted as a transformation?

When you apply overlay, crop, fill, or whatever, then yes, that is counted as a transformation.

Am I misunderstanding something here?

Yes, I think so. See below.

Because in that case, we're limited to only 75k per month. And if so, we need to fetch the finished image from Cloudinary and store somewhere else (as I assume each call for the image, will count as another transformation...).

No, no. You're right regarding the 75k per month. But that's for transformations. Ultimately, with this implementation, we require one transformation for each artboard created. But then the delivery of the artboard created does not count as another transformation. That's just an image delivery. And that we have plenty of. Remember: Cloudinary is a CDN service; these image manipulations are just a beautiful cherry on top of the cake.

I don't see the need to store the image elsewhere, given that Cloudinary is indeed an image hosting service. If extra redundancy is needed, we could backup things to S3. But not for image delivery. Cloudinary has some pretty good caching and delivery networks.

[avorio]

Oh, another thing. There are some pre-existing backgrounds that user can choose. So we need to upload them to Cloudinary too. They're not available yet, however.

I just emailed you the credentials. Feel free to browse around and upload those when ready.

[avorio]

Also, can't get this working locally. Do I need to run any updates/migrations?

Nope. But you do need to have that artboard you're trying to access stored in your database, which you don't because I uploaded it to my local server. Hehehe.

That was an example URL. You should upload something in your local server and then load the URL following the same structure (see it here). The file name should be returned by the AJAX call, and it should look like something like this: v1469065298/bcv1vxkhzbvcici2ksyj.png.

[erasmus]

I just uploaded an image and tried hitting the URL. Still nada...

[avorio]

What branch are you in? You should be in artboard-view.