KS3
Coding a Search Bar Functionality In An Email
My email team is asking for us to incorporate a serach bar functionality in our marketing emails. They mentioned that "a long time ago" it was pretty common to see this search functionality in email. Although I cannot remember seeing it recently I am wondering if any of you have done this before and what the support is like from a variety of email clients. Can it be done?
What exactly is the purpose / strategy / intent? What is the user searching? What are the possible results? Where do the results display? Is it simply a target into a site (like href="URL+[?search="search-string-parameter-here"]")?
If your email needs a search bar, doesn't that suggest you have too much content in a single email? :-) (Unless the search bar is connected to your website's search function.) Email design is definitely trending toward fast, simple, and skimming-friendly, so if you're providing a good UX, your readers probably shouldn't need a search bar.
Hey KC - we used to do this around 10 (!) years ago, before Outlook 2007. There was good support then everywhere except hotmail, though granted that was pre-mobile too.
I think these days obviously Outlook is a problem, but you could use mso code to do something else for those users. I had a brief chat with Mark Robbins about this (he's got some concepts with this stuff) and he mentioned Android can be a pain with this, but again, you could hide on android to a degree. One approach could be to accept it as mobile/tablet/yahoo only and use media queries to show the form (tho would need testing)...
Hi Elliot. Thank you for response. Would you happen to have any snippets available for testing?
I suppose it could be done, but I am sort of on the "Don't do overly complicated things in an email". I don't think you can bring up the keyboard while viewing an email in iOS so that would be a non-starter for me.
If you know a ton about your customers you could segment / personalize the email and give the customer CTAs that are better than search. I know NewEgg is really really good at putting my abandoned shopping cart stuff in my daily emails.
As Elliot said, they used to exist. We tested out of them at least a year ago and we thought we were late to the party in regards to getting rid of them. Support is quite low and the css defaults for every client are different, so there's very little consistency. Things like placeholder text work in many clients but gmail doesn't support it. Outlook doesn't support the form at all but will render correctly in 2011...but 2007-10 will destroy the form elements all together. Mobile clients are a little more forgiving and will function properly after you do the proper os-specific overrides (like the -webkit corrections for ios), but as Elliot said it would require testing to pick and choose the right clients. Best solution would be to offer a dummy form in pure html for desktop clients and then display an actual form for mobile clients. That's probably the most effective, in the end.