BCWhat do you consider an unreasonable spec for an email job?
Just want to get a general idea of what the common pain points are, and what the common education goals should be for our higher-ups/other departments/teammates.
I've once had a boss that requested background images in emails that both:
a) allowed replying/forwarding without the 'black reply' problem and
b) allowed the email to be printed in multiple pages from Outlook 2013.
This isn't possible, due to how Outlook 07/10/13 handles the bulletproof background's VML object; and it would only allow A consistently, since the VML object cannot print on multiple pages unless they were actually seperated per page. I tried explaining how differnet Microsoft's VML language was, even after I found an online resource on how to write to it, and how it quite simply wouldn't allow the multiple printing. The boss's response was "It's just code, you can figure it out".
"it breaks when we forward it" is something we come up against a lot, as are the usual pitfalls (responsive on gmail, degradation in Outlook, Lotus support). We're very careful to outline both what we can and can't do, and as a result what the email will and won't support, but occasionally it still causes problems later down the line.
A useful technique I found when working internally was to highlight that we're spending x amount of time catering to a minority y% of the list, often to the detriment of the z% majority.
often good but shipped is better than great when it comes to email.
that said, all image emails do suck.
That, all the way. I wish people understood by now that 100% support across clients is a pipe dream, and that it shouldn't be holding anyone back. As long as your emails are degrading gracefully in the terrible clients, ship it.
A year ago I hated everything a client asked me, how could they be so stupid?
Then it hit me. They're not stupid, they just aren't email developers or designers. If they knew all this technical stuff, we wouldn't have their contract.
It is my job as the person who handles their account to educate them on what we can and can't do. When they ask me to make the unsubscribe link small or remove a view in browser link I smile and explain as well as I can why we can't do this.
This has lead to many a healthy, trusting relationship with clients. In the end, we have the same goal as them - it's not us vs them.
This. I view it as: My job isn't to make the client happy by saying yes to everything they ask for. My job is to make the client happy by building them a quality product that delivers results. Part of that, and part of every quality designer's job, is the ability to succinctly deliver a convincing argument. A skill that's probably way more important than the ability to code a table or use Photoshop.
There's always going to be some give and take. Some of my clients are willing to jump off the deep end. Others are more conservative in the direction they can go and my exceptions have to adjust with theirs. And of course there are going to be stubborn people who want ridiculous things. If something's not possible or horrible practice (i.e. making an unsubscribe link that can barely be seen) stand your ground. Don't be a dick. Just make your case. It's alright to say no. If that's not allowed...then find a new client or a new job as that's probably not really a place or a person you want to be working for in the first place.
Overall, the business skills of designers and developers is fairly lacking. Not just in email but across the web. This leads to less influence, less pay, and is overall a bad thing for the industry as our craft becomes seen as black magic instead of expertise in a field. It's something all of us could stand to improve.
In the end, yes, dealing with clients is sometimes hell, but that comes with working in a service industry. Only truly fret on it if it's happening far more often than it should. And if that's the case, either work to change it or get the hell out of whatever position you're in. There are clients and jobs where you can build those trusting relationships that aren't confrontational.
For more on this type of stuff I definitely recommend Mike Monteiro's book Design is a Job
You worded that perfectly.
Excellent words. It's not really my intent to turn this discussion into a 'Clients from Hell'-esque venue; but instead to find out what the common pain points are; what the common unreasonable requests are and, hopefully, finding a way to create a learning resource to help us educate clients/bosses/teammates based off our shared experiences.
Yeah, that sounds frustrating. I've always found that educating clients and client-facing colleagues is tricky, but absolutely necessary. Email is such an arcane thing, that without educating clients about the realities of technology and rendering, you're bound to get requests like that. Hopefully the Litmus Community can help make educating everyone a lot easier.
Back when I did agency work, the major two requests were:
We had clients that literally insisted on making everything images—totally a slice and dice job, which sucked. Despite trying to educate them about how email clients block images and a lot of subscribers typically won't see their message, they forced emails to be entirely image-based to maintain brand consistency. We even had one client that sent their PDF newspaper ad in to be sliced. Not fun.
The Lotus Notes thing was a pain in the ass, too. One stakeholder used Lotus Notes, so we all know how that went... Despite being told that no consumer will be running their own Domino server, we had to jump through hoops and repeatedly bang our heads against the wall to try to get emails to render correctly in Notes.
I like this thread, curious to see what other designers have come up against and how they have handled the situation.
I like to go with the concept of "wow the majority, break safe for the minority".
Doing a 100% consistent experience across all platforms will ensure a pretty damn boring experience :D
Great question!
There are quite a few I can think of but the common ones would be:
The first one I always find interesting and i'm sure there are email clients that can provide this, just not the ones we use. No matter how often it's explained that the 'browser version is literally the email viewed on the web', we still get these requests that in the end force us to host the file ourselves.
The Outlook issue is the biggest pain I find normally because the emails are coded to be responsive and by sending via Outlook, it wastes all the time and effort put in to make it look good across as many devices as possible.
No description needed for the third one I think as i'm sure this one is a major contributor to every designers swear jar!
HA! i am in bullet point 2 mayhem currently. But just heard a possibility of good news. A director may make it known to send all designed emails via a real provider, not Outlook. Fingers crossed.
I oft find myself in OFT mode, making Templates for Outlook. We have a number of clients who want branded emails that they can supply to third parties to send to their outlook contacts.
In fact my No1 unreasonable spec would be when asked to build a responsive email, then told to deliver in OFT format.
With No2 being the same responsive build but then told there's a third party that will be adding their own header footer branding around the email, where they just remove all the responsive CSS.
Certain educational student bodies have their own spec documents that make responsive difficult - to - impossible. And many times clients have not been forthcoming with these spec requirements until after delivery.
What is usually your OFT workflow? How do you transform an HTML into OFT?
Ideal -
Construct and test as usual in Litmus, with an eye for the Outlook renders. Including 120 DPI fixes.
Building for non-responsive, and enforcing tables that we'd often comment out with MSO if clauses.
Then send via our internal EDM tool to a PC Outlook and from there save as OFT
Reopen the OFT and run an additional round of Checks in Litmus.
Rework any new issues and resend to the PC inbox.
Resave to OFT one last round of checks and provide this to client.
I have to say that the remove "view in browser" is a reasonable request. We handle this by adding some markup around the "view in browser" link and then removing the link via the module that displays the email. We also occasionally display a slightly different version than the emailed version in view in browser.
(Of course if the user clicks on the Outlook view in browser this will not work.)
Best one I've got is "why can't we just put forms in emails and use JavaScript to validate the fields" for Outlook.