Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Tim Jaramillo

Members
  • Posts

    9
  • Joined

  • Last visited

Blog Post Comments posted by Tim Jaramillo

  1. For those of you using canvas/Animate CC for banners, have you run into any issues with ad servers/publishers? For example, do all ad servers/publishers exclude the EaselJS library from file-size count? The info under the "Retina ready" heading is interesting, but it seems that using 2X images for all assets could be problematic in terms of hitting the standard 200k file size limit? For my standard DOM div banners, I've been using regular size images for most imagery- the blurring is not very noticeable when most images scale on hi-res displays. Blurring is much more noticeable on text, so I use SVG for text whenever possible, though file size can be prohibitively high on SVG text. (And of course SVG is not available in canvas, though you could potentially use EaselJS’ DOMElement Class to add an SVG on top of the canvas). Does anyone have thoughts on pros/cons of using Animate CC versus hand coding banners using the DOM? I'm wondering if Adobe is positioning AnimateCC for banners for users who maybe don't want to hand code animations as much? On one hand the AnimateCC seems to simplify the workflow, by offering easy positioning of objects using the WYSIWYG interface, but on the other hand it seems to introduce additional complexities: 1) you have to open a hefty program to edit, 2) anyone else who works on it needs to be familiar with the particular Animate CC setup (how the FLA relates to the output HTML/JS), 3) when handing off source files to clients or 3rd party devs, they may not have AnimateCC installed in case they need to modify the ads, etc. I’m definitely not trying to bash using AnimateCC for banners, just curious about others’ experiences!
  2. @hhdev: yes, when reusing the SVG outlined-text elements across banners, we have been using the same text layouts across banner sizes (luckily). If the text layout was different across banners, then yep- we'd have to save out unique SVG outlined-text elements for each different layout (have the banner's designer do this for you!).
  3. @ Wiplash: our current workflow for displaying text in html5 banners is to convert all text to SVG (create outlines of the text in Illustrator first). We embed the SVG into the html with a standard image tag. We then use CSS to set the width and height of the text for each ad (you can reuse the same SVG text element and just resize for each different ad, since it's vector!). In my experience, using SVG for text results in a bit larger file size than the alternative of using pngs for images, but png image texts appear blurry on retina displays. I definitely wouldn't want to deal with all the hassles of embedding fonts, legal issues, etc. If you do use SVG, you do need to make sure that whoever is hosting your ads has the SVG mime type added to their server.
  4. Jack, this article should be recognized as the official manifesto for html5 banner ads moving forward. Everything in this post is absolutely spot on. I'd like to add that finding a good png compressor (I use Pngyu combined with ImageOptim), and getting comfortable with Photoshop's Save for Web feature, are absolutely critical in terms of hitting the low file size specs for an html5 banner ad. On a side note, some ad networks offer different price points for various file-size tiers If you're lucky, your clients will be willing to pay the extra amount to run larger file size ads. I'm currently involved with a campaign that has a 110k file-size spec. As Jack mentioned, our ad network is not counting external JS loads against us, so even with the 110k file size spec, I'm able to build all the standard sized units using TimelineMax, which is an extreme time saver. Thanks again for you and your team's great work on GSAP Jack, it keeps me in the game!
×