Looks like I have been penciled in to present at the upcoming Google conference in Toronto to discuss Advanced Dynamic banners. Have to try to find some presentable work I've done in that area to show. That might actually be a challenge... Most of those kinds of banners Im not allowed to show because of NDAs for some reason. Hoping I can find something.
I know the argument for live fonts in banners. Easier to make client changes. Less file size. Crisp readabilty.
But unless specifically told to do so, I will never use live fonts for the following reasons:
1) Images are much faster to code. Live fonts require a while bunch of CSS to get it looking correct. Imagine a price point, with a small $, different size dollars and cents, and a few dividing lines for good measure. Not difficult CSS, but takes way longer that just saving an image in Photoshop. Just set up an action in Photoshop to turn a layer or selection into a transparent PNG, and thats your image. And as long as you keep the PSD, it's easy to make changes. The one thing I'll give live fonts in this area is its easier for a new developer to take over as you don't need to worry about passing along the PSD as well.
2) Images are much easier to QA. An image is an image in every modern browser and platform. No way can you say the same thing about live fonts. It will looks slightly different all over the place.
3) Unless you have a web font licensed, you will need to resort to Google fonts, or something else not quite what the AD wanted. And even if you do have a proper font to upload with the zip, it will never look exactly the same as the PSD. Sometimes very close, but never exact. And the AD worked hard at all those kerning and letting settings which will be tossed.
4) Custom fonts can be huge, thus offsetting the file size you saved from using fonts instead of images. Maybe even putting you over the file size limit. And you will usually have to load it from the cloud, which is still a grey area for many ad servers.
5) Using tinypng.com with retina sized PNGs is surprisingly efficient for file size and quality. Thus quality with images will not be compromised.
Overall, the thing about banners is that they are temporary venues for advertising. They will typically be handled by one dev only, and only be around for a limited time. There is no need for easy editing or ease of transfer. File size, image quality, and speed of development are the three key aspects. File size/quality is debatable depending on the design and fonts, but usually can be done with images no problem considering what banners are usually designed like. But speed of development, there is no argument at all. Images are way easier. And will always get you exactly what the AD (and client) is expecting without having to resort to "Well, it's HTML text so it will look a bit different than the PDF."
Every year I seem to think I have the timing of the busy banner season hammered down, and every year it throws me off. It seems logical that November would be the busy season, with clients all preparing for the holidays. Then I would assume December would tail off as everything is already done and prepared and ready for trafficking. 2014 was like that. But this year November was the same as October which was the same as December. 2013 had a dead November, and a killer December.
I guess for freelancers it's not so much about time of year, but more on the particular clients you are working with that year, and their overflow.
How is it that Tinypng.com compresses PNGs so much better than any other desktop based image compressor? Always thought ImageOptim was enough, but no. Always use TinyPNG.com as well.
Since SVGs don't animate well in older browsers (Specifically zooming), I've avoided using them in banners for a while, opting instead for retina sized PNGs. But Im warming up to them. Most clients are caring less and less about IE9, and I've found a few really good tools.
The first is something with Photoshop CC that I only recently discovered. It allows you to export SVGs from text layers without having to do any extra steps (except for converting to shape layers). Just turn on File>Generate>Image Assets. Then rename each layer xxxx.svg, and without any extra steps, wherever you have saved the PSD, a new folder will appear with a file for any layer named with a .svg extension. Explained much better here: https://www.youtube.com/watch?time_continue=206&v=6TRz-gNdQFg
Also, I found a really good tool for compression SVGs. Give it a go here: https://jakearchibald.github.io/svgomg/
In other words, it's going to be hand coding unless some sort of nasty animation is required. Then it's worth the fight to figure out if it can be used or not.
The whole switch has not been as bad as I was expecting. Takes more work. Takes more time testing. Takes some more effort to get specs. And a few things here and there that I have to explain can't be done within the file size we have (which really is the same as Flash banners, just different things that can't be done). But overall, a banner is a banner. And Im a banner guy! Onwards!
From a banner perspective, Flash was able to hang on for 5 years after officially being declared dead for the first time back in 2010.
And for 5 years, I kept having to explain to people that Flash Banners were here to stay until HTML5 could catch up, and ad agencies could justify the extra time, cost, and increased creative restrictions.
Well, with the Firefox security block, and Chrome's supposed click-to-play banner ads that started in September (Which I have yet to actually see happen), agencies finally freaked out back in August, and switched everything over to HTML5.
It's been a crazy few months. Especially finding media companies that truly understand what is going on and can provide accurate HTML5 specs. Considering they still had trouble with AS2 specs sometimes, I think it's going to be a challenge for a while. But Flash really now is officially done. Coming from a Flash guy, that means a lot.
I will truly miss it. It was my career for 10 years.
It had it's bumps - like the IDE's tendency to like some fonts but not others, or crashing at the worst possible time. But overall, it was a joy to code with, and made things that HTML5 has difficulty doing in small files sizes, like guide layers and non-square masks, much easier.
Rest in peace my friend.
Well finally, over a year after shooting, my episode is going to air on Monday! My brother Ryder and I saw a pre-release DVD yesterday, and were really happy with how it turned out!
For those who think reality TV is a sham, everything you see on the episode actually did happen. Of course a lot was cut out due to taking 2 days worth of film, and putting it into 45 minutes, but all the good parts are in there.
Hopefully everyone enjoys it!
In the midst of Toronto FITC. As usual, sessions are hit or miss. So far, only one has kept my attention throughout the full hour. Last year was very good, but I fear this year is following the lines of 2008's quality.
So far, the underlying theme that I'm noticing is that there finally is a real drive towards mobile apps. Even though everyone here seems to be pushing the "other mobile platforms" so you can develop with Flash ... I'm starting to realize that I'm going to have to start learning Objective C.
I was also able to talk to a couple of the FDT Developers today - specifically Michael Plank - and I brought up my problems with FDT not being able to change the format of the method params to include a $, and also that whenever I close and re-open my class folders in the Explorer, all the sub folders that were open become closed. He seemed genuinely surprised at that one, so hopefully will be able to fix it in a future release.