Thoughts on the IAB updating HTML5 display guidelines

Bring me up to speed on what you are talking about?

As per this article in The Drum:

The IAB have released a document for comments on new guidelines for HTML5 display advertising.

Why do I care?

Non-important Flash content will be paused in Chrome as of September. In our tests with the Chrome Beta, this generally means display ad content. Flash content already does not work on mobile/tablet devices, in their place  are banners created out of HTML, the same stuff webpages are made from. Flash banners are made out of this crusty crap from 15 years ago which while nearly ubiquitous across internet connected PC’s and Mac desktop devices also produce significant power usage issues and, more importantly, significant security issues. The industry will be moving to HTML5 banners as standard, which is a wonderful new thing for client services to sell in (dare I say it, maybe with a slightly higher margin??? I dream too much)

So what does this document say about the only thing I care about: permitted file sizes?

In a nutshell:

  • 200KB for the max initial file load size for standard desktop display creative sizes
  • 50KB for max initial file load size for standard mobile display creative sizes

This makes a huge difference to what we can deliver, how we deliver it and the timelines to delivery.

If you are still receiving old specs of 40kb for Flash you MUST to push back on this like a motherfudger. If you don’t push back on it I will be pushing you down the stairs whilst calling you a motherfudger.

Further to this Double-click announced in a blog post that they would be allowing “HTML5 ads by offering unlimited file sizes…for free” (, up from their previous creative file size of 1mb (

What does this mean for HTML 5 banners going forward?

There is still a lot of flux in this document (commenting closes 18 September) so things will change after this commenting period however the important thing is that we are still receiving ad specs from networks saying 40kb limit as you would for Flash. This is not acceptable. For example as per IAB documentation published prior to this new document (emphasis mine)

“HTML5 did not become an official recommendation until December 2012, nearly a year after the IAB Display Advertising Guidelines: The New 2012 Portfolio was released. As such file size limitations were not taken into account for ads developed using HTML5. Current file size limits for ads developed with Flash are sufficient because Flash files can be compiled, compressed, and packaged to accommodate smaller file sizes.

However HTML5 doesn’t have the compression and packaging capabilities and with high-density displays permeating the market, larger creative assets are necessary in HTML5 to produce crisp visuals.


(see section 2.2

40kb file sizes are unacceptable for HTML5 content, the IAB has made this clear… in 2013.

With Flash-ggeddon rapidly approaching this conversation is going to happen a lot. We have squandered an opportunity to be thought leaders in this arena a year ago when we first started discussing HTML5 banners internally due to both a lack of understanding and also a willingness to understand. What we do have is here is a greater opportunity here to better service clients and be seen as forward-thinking, thought leaders with a great understanding of the problem and solution to people outside of our industry whilst making lives easer for team members on both creative and client service teams.

Blow this opportunity and a set of stairs await you.

Wrap it up mate

This updated document from the IAB does not mean the end of the conversation or that implementation details for HTML5 display banners have been finalised by ourselves or by the greater industry. The conversation about what is creative’s remit and what is dev’s remit and what is the most efficient method of creation is ongoing. Best practice conversations are developing and ongoing. Technology and software conversations are ongoing. With all these headaches and heartaches to come having a coherent standing on the file size issue will be incredibly important.

Action before Information

I was just watching this video of a demo Tesla app and it made me realise something that I have been subconsciously thinking about since getting the Apple Watch. A big shift in thinking for these sort of apps should be giving the user access to actions before information. I feel far less friction about being given options to do things and then having to swipe to get information than I do when it’s information and then I get to my actions. In this context, menus can also be considered information.

More than that, I tend to use the Watch to do, rather than view. Quick access to functionality is key.

When marketing gets in the way of UX #1

This is ridiculous. On a desktop site, past the 960 cut off, you have to be a special kind of dumb to put “offer exclusive to mobile” in a big roundel on your banners. For anyone wondering, it’s pushing to a m. site, no one on mobile sees these banners.

I love the journey here so much. What you want me to get my mobile out, look up that desktop url, tap that into my mobile and then sign up???? Seamless. I know we have handoff on Mac/iOS devices but this reeks of sheer marketing department stupidity.

Worse than that, you are cutting off two audiences. The mobile users that will never see this and the desktop users that can see the offer and can’t use it as it’s exclusive to mobile.

Screen Shot 2015-04-28 at 11.38.42

To the designer who inevitably argued against this in vain, I salute you; you were right, What they asked for made zero sense and they were all being incredibly dim. If I had my way they’d be fired out of a cannon into the sea for crimes against UX.

Hey Mark, from your expert design perspective what would you suggest to invigorate/give some more depth/texture/syle to our email template?

Hi anonymous question asker. Bad news for the designers out there: not much.

Emails have the digital capability of a sausage. They are literally stuck in the past as vast swathes of the market are still stuck on old versions of Outlook which uses a version of Word to render rather than a browser. As such only basics really work easily.

Adding for example a gradient background means that any text over that area would need to be exported as an image rather than as live text, obscuring it from view on email clients which require you to turn on images to view and also makes this a design job each time for any changes to the email rather than simple html text changes
Background images don’t work. Extending things 100% width to section it out doesn’t work (as evidenced by your current emails which have horizontal scroll bars on Outlook[1])
Whilst you could argue that certain styles like a drop shadow could be applied to the foot of each section only to more capable email clients. With a responsive email design you are adding in a far greater margin for error with how the email handles in the hundreds of email clients available. Increasing QA and build times exponentially.
After having tried all these things previously I know from previous results that they have little effect to CTR, they generally just create headaches.
Animated gifs may add a bit of pizazz but again Outlook won’t render the animation showing only a static of the first frame so any essential messaging/CTA needs to be on the first frame, also Outlook will probably initially block images. Apart from this, support is actually pretty good for animated gifs and may be the clever way of adding in a differentiation that can be handled at design stage without adding to much time at build. Asos are using this technique quite a bit for their product emails but I can see this being more appropriate to their needs as it allows you to see different shots of  products without increasing length. I haven’t any stats to show the effectiveness of this techniques yet. Here is a url about it though with words written by someone probably cleverer than me:
As always, for me it’s more about about a compelling subject line, offer copy and simple postcard style email with less distraction anyways to not waste the users precious time & push the users to the conversion goal with all of this verified via A/B testing
[1] As you may have guessed, this is a response to an email that came in at work. Having concluded writing it I obviously thought these opinions may be useful later on.


I’m as guilty of doing this as anyone else that claims to be a UX designer:

That little asterix, usually accompanied by some little text. If you’re real lucky it appears at the top of the form, if you’re medium lucky it’s at the bottom but it is there. Unlucky users will get nothing.

Why is this important?

It’s just one of those esoteric symbols that we that work in the tech world take for granted. “They’ll know that fields required, it’s got a red asterix” and yeah, potentially for the relatively internet savvy that is true.

Unfortunately the world is not full of the relatively internet savvy and that little red asterix has got to the point of an afterthought nowadays. We add it as a check to ourselves, “yep that form is clear and simple now” but for so many people it’s really not. As anyone who has wrestled with bad forms before knows It adds friction to a journey and can be a conversion killer. Couple it with non-existent live in-line validation & the user may not know until the end of the process that they missed a required field. As much as we may slave over that form, no one wants to fill in forms; they are boring, they are a means to an end and your asterix may be stopping me from getting to that end, or buying stuff, whatever your goal is.


This is a simple one, just write (required) after the field label.

If you want you can set it in small text, you can italicise it, you can colour it red.

Whatever. It doesn’t matter (actually, all of those things will probably help the user notice it). The easiest way to let a new visitor know that that field is required is to simply tell them with a word.

Designing for Apple Watch

I don’t imagine we’ll get a request in for anything to do with the Apple Watch within the next 2 years at my place of work but interesting information on some of the constraints of designing
for the watch can be found here.
If anyones curious about what you can do within the constraints, attached is a UI I’ve done (not connected up at the moment though). Notifications in the infographic illustrate what it’s like to design for. Elements are full width (there is a special grouped element that allows you to add to elements into a line) and limited in styles.
Screen Shot 2015-03-17 at 12.53.32
Custom fonts are supported but not massively recommended at this time as I understand. A lot of black is recommended (the OLED screen saves power by not powering pixels when set to  black which apparently makes for far deeper and richer colours).
Modal/scroll view and hierarchical views are about all the view methods you have but seem the most appropriate. Of course all code is ran on the phone rather than the device but this is something I expect to change when Apple rolls out the next version of watchKit at WWDC
Update 04/05/15

This bad boy is up and running on my watch right now. Really pleasantly surprised how quick it was to get this up and running (I wired up the mock up from here in less than an hour before I went to a dinner party)
Update 05/05/15
Apple yesterday released/updated/it only just came to my attention their Human Interface Guidelines. Interesting read (especially the UI elements section which lays down the sort of restrictions in terms of visual design for these things), even if we won’t EVER do one of these at my work. Some good templates, fonts and mock up shizzle in the last section if you’ve got any inclination to start mocking something up

A UX’y ecommerce cta thing

I was reading this article today:

TLDR: the way our eyes look at things, users see the terminal area or the bottom right corner of a rectangle/square the most. The diagram attached shows how we do this. It’s a familiar pattern; I instantly remember it from my DM days. That was where we put CTA’s on 2 page spreads an’ that as it converted better.
Anyways, was just perusing the apple site and noticed their product pages now have a persistent window footer with the CTA in the terminal area. I assume the CTA would be appropriately coloured in blue or similar if the button was clickable. At this time the page is a kind of a marquee landing page, the other Macs don’t seem to share the same style product page according to my quick few clicks around.
Screen Shot 2015-03-11 at 21.18.35
Interesting idea and wouldn’t have thought twice about it if I hadn’t just read that article this morning. This could be a very good UX pattern to nick. We did a persistent top bar CTA for the last two commerce things I’ve done but that was at the top of the page and I can’t remember whether they made it past my wires. But it is true for me. I do see that CTA down there more than I look back up at the top of the page.