Developing for simplicity when cleverness is the enemy
This blog post comes from one of Dwolla’s Lead Developers, Jared Dellitt. To hear more from Jared, follow him on Twitter at @jareddellitt.
As part of our continued evolution of Dwolla’s White Label solution, we needed to provide our customers an easy & secure way for them to onboard their customers without the need to capture bank credentials or account & routing numbers.
We first released dwolla.js with Dwolla’s default IAV experience for a few customers knowing full well that a customized experience was needed if we wanted it to be considered a valuable tool.
Our first idea was ambitious. It revolved around sniffing the styles on the page by creating elements in a hidden div, reading the style properties that the browser applied, then relaying those styles to the iframe via postMessage and finally appending them as a stylesheet. We figured this would provide enough of a “custom” experience and that the amount of effort required on the partner’s side would be minimal.
As a partner, you would just need to provide rules for the most common html elements in your own stylesheets, wouldn’t have to maintain separate stylesheets/rules just for IAV and as you change the look & feel of your site, IAV updates as well. Great idea, right? In theory — yes, in practice — not so much.
After a few days, we were able to get a working version to the point where we could embed it on a few popular websites and see how the iframe responded to the styles from the parent page. Websites that used pretty basic styles & fonts actually looked pretty good, but anywhere custom fonts or pseudo classes used made the iframe feel out of place and a bit awkward.
We were bummed because we thought it was a clever idea, with a simple developer experience. In reality we were hamstringing our partners by not allowing them to provide the best experience possible to their end users.
We then started brainstorming. We thought maybe the font-face definitions could be just defined in the JavaScript, but this would be a real pain for sites using a font provider like Google Fonts, where you just include a link to a CSS file. This also didn’t satisfy the ability to add behavior by styling things on hover, focus, etc.
So we pivoted and went with our next idea; allow these trusted partners to just specify their own stylesheets. They have to do a bit more work, but they get more control of the overall experience. We provide a base set of selectors to be implemented that will apply to certain elements within the iframe and they provide us a list of URLs to their stylesheets.
Still, this raised additional questions within the team:
What happens if they override styles we have deemed “styleable”?
We can’t guarantee this won’t happen — but we also can’t guarantee that we won’t change those elements in the future. The skeleton stylesheet we provide will be the things we can ensure will always be applied.
Our first set of styles is probably not going to be enough for certain partners, so we’ll need to work with them to determine what they’d like to be able to change and get those classes into the views and skeleton stylesheet.
Shouldn’t we be concerned about load times & performance impacts of linking to a bunch of external assets?
Ultimately, these partners are providing the end-user experience to their own customers so it’d be to their own detriment to include numerous heavy stylesheets that could slow down the experience.
We’ll strongly encourage partners to adhere to best practices when it comes to web development & assets (concatenation, minification, compression, caching).
We’re still learning and getting feedback about our current approach. We’re betting on the fact our partners want to provide their end users a great experience, just as we do. Looking back on our first idea, maybe we were trying to be too clever. Dwolla.js for IAV is just one tool in the toolbelt that Dwolla White Label provides to developers and we want to let those developers & designers do their thing. Feel free to demo the tool here.
