Tag Archives: programming

Native And PWA: Choices, Not Challengers!

It’s hard to tell exactly where the rift between “native” and “web” really started. I feel like it’s one of those things that had been churning just below the surface since the early days of Flash, only to erupt more recently with the rise of mobile platforms. Regardless, developers have squared off across this “great chasm,” lobbing insults at one another in an attempt to bolster their own side.


Native And PWA: Choices, Not Challengers!

Documenting Components In Markdown With Shadow DOM

Some people hate writing documentation, and others just hate writing. I happen to love writing; otherwise, you wouldn’t be reading this. It helps that I love writing because, as a design consultant offering professional guidance, writing is a big part of what I do. But I hate, hate, hate word processors.

Documenting Components In Markdown With Shadow DOM

When writing technical web documentation (read: pattern libraries), word processors are not just disobedient, but inappropriate. Ideally, I want a mode of writing that allows me to include the components I’m documenting inline, and this isn’t possible unless the documentation itself is made of HTML, CSS and JavaScript. In this article, I’ll be sharing a method for easily including code demos in Markdown, with the help of shortcodes and shadow DOM encapsulation.

The post Documenting Components In Markdown With Shadow DOM appeared first on Smashing Magazine.

View article:  

Documenting Components In Markdown With Shadow DOM

Redux · An Introduction

Redux is one of the hottest libraries in front-end development these days. However, many people are confused about what it is and what its benefits are.
As the documentation states, Redux is a predictable state container for JavaScript apps. To rephrase that, it’s an application data-flow architecture, rather than a traditional library or a framework like Underscore.js and AngularJS.
Further Reading on SmashingMag Why You Should Consider React Native For Your Mobile App Test Automation For Apps, Games And The Mobile Web Server-Side Rendering With React, Node And Express Notes On Client-Rendered Accessibility Redux was created by Dan Abramov around June 2015.

More here: 

Redux · An Introduction

Tips and tactics for A/B testing on AngularJS apps

Reading Time: 8 minutes

Alright, folks, this week we’re getting technical.

This post is geared toward Web Developers who’re working in conversion optimization, specifically those who are testing on AngularJS (or who are trying to test on AngularJS).

Angular, while allowing for more dynamic web applications, presents a problem for optimization on the development side.

It basically throws a wrench in the whole “I’m trying to show you a variation instead of the original webpage without you knowing it’s a variation”-thing for reasons I’ll get into in a minute.

At WiderFunnel, our Dev team has to tackle technical obstacles daily: many different clients means many different frameworks and tools to master.

Recently, the topic of How the heck do you test on Angular came up and Tom Davis, WiderFunnel Front End Developer, was like, “I can help with that.”

So here we go. Here are the tips, tricks, and workarounds we use to test on AngularJS.

Let’s start with the basics:

What is AngularJS?

Angular acts as a Javascript extension to HTML, running in most cases on the client-side (through the browser). Because HTML isn’t a scripting language (it doesn’t run code), it’s limited. Angular allows for more functionality that HTML doesn’t have. It provides a framework to develop apps that are maintainable and extendable, while allowing for features such as single page navigation, rich content, and dynamic functionality.

Note: You can mimic Angular with plain Javascript, however, Angular provides a lot of functionality that a Developer would otherwise have to build themselves.

Why is AngularJS popular?

The real question here is why are JS front-end frameworks and libraries popular? Angular isn’t the only framework you can use, of course: there’s EmberJS, React.js, BackBone etc., and different Developers prefer different frameworks.

But frameworks, in general, are popular because they offer a means of providing a rich user experience that is both responsive and dynamic. Without Angular, a user clicks a button or submits a form on your site, the browser communicates with the server, and the server provides entirely new HTML content that then loads in the browser.

When you’re using Angular, however, a user clicks a button or submits a form and the browser is able to build that content itself, while simultaneously performing server tasks (like database submissions) in the background.

For example, let’s think about form validations.

No Angular:

A user submits a form to create an account on a site. The browser talks to the server and the server says, “There’s a problem. We can’t validate this form because this username already exists.” The server then has to serve up entirely new HTML content and the browser re-renders all of that new content.

This can lead to a laggy, cumbersome user experience, where changes only happen on full page reloads.

With Angular:

A user submits a form to create an account on a site. The browser talks to the server via JSON (a collection of data) and the server says, “There’s a problem. We can’t validate this form because this username already exists.” The browser has already loaded the necessary HTML (on the first load) and then simply fills in the blanks with the data it gets back from the server.

Disclaimer: If you don’t have a basic understanding of web development, the rest of this post may be tough to decipher. There is a Glossary at the end of this post, if you need a quick refresher on certain terms.

Why it can be tricky to test on Angular apps

As mentioned above, Angular acts as an HTML extension. This means that the normal behaviors of the DOM* are being manipulated.

Angular manipulates the DOM using two-way data binding. This means that the content in the DOM is bound to a model. Take a look at the example below:

Testing on Angular_2-way-data-binding

The class “ng-binding” indicates that the H1 element is bound to a model, in this case $scope.helloWorld. In Angular, model data is referred to in an object called $scope. Any changes to the input field value will change helloWorld in the $scope object. This value is then propagated down to the H1 text.

This means that, if you make any changes to the H1 element through jQuery or native JS, they will essentially be overridden by $scope. This is not good in a test environment: you cannot guarantee that your changes will show up when you intend them to, without breaking the original code.

Laymen’s terms: $scope.helloWorld is bound to the H1 tag, meaning if anything in the variable helloWorld changes, the H1 element will change and vice versa. That’s the power of Angular.

Typically, when you’re testing, you’re making changes to the DOM by injecting Javascript after all of the other content has already loaded.

A developer will wait until the page has loaded, hide the content, change elements in the background, and show everything to the user post-change. (Because the page is hidden while these changes are being made, the user is none-the-wiser.)


We’re trying to do this switcheroo without anyone seeing it.

– Thomas Davis, Front End Developer, WiderFunnel

In Angular apps, there’s no way to guarantee that all of the content has been rendered before that extra Javascript is injected. At this point, Angular has already initialized the app, meaning any code running after this is outside of Angular’s execution context. This makes it complicated to try to figure out when and how to run the changes that make up your test.

When you’re running a test, the changes that make up Variation A (or B or C) are loaded when the page loads. You can only manipulate what’s in the DOM already. If you can’t guarantee that the content is loaded, how do you ensure that your added Javascript runs at the right time and how do you do this without breaking the code and functionality?

Tom explained that, as a dev trying to do conversion optimization on an Angular application, you find yourself constantly trying to answer this question:

How can I make this change without directly affecting my (or my client’s) built-in functionality? In other words, how can I make sure I don’t break this app?

How to influence Angular through the DOM

Angular makes for a complicated testing environment, but there are ways to test on Angular. Here are a few that we use at WiderFunnel (straight from Tom’s mouth to your eyeballs).

Note: In the examples below, we are working in the Inspector. This is just to prove that the changes are happening outside the context of the app and, therefore, an external script would be able to render the same results.

1. Use CSS wherever possible

When you’re running a test on Angular, use CSS whenever possible to make styling changes.

CSS is simply a set of styling rules that the browser applies to matching elements. Styling will always be applied on repaints regardless of how the DOM is bound to Angular. Everytime something changes within the browser, the browser goes through its list of styling rules and reapplies them to the correct element.

Let’s say, in a variation, you want to hide a banner. You can find the element you want to hide and add a styling tag that has an attribute of display none. CSS will always apply this styling and that element will never be displayed.

Of course, you can’t rely on CSS all of the time. It isn’t a scripting language, so you can’t do logic. For instance, CSS can’t say “If [blank] is true, make the element color green. If [blank] is false, make the element color red.”

In other cases, you may want to try $apply.

2. Using $scope/$apply in the DOM

We’ve established that Angular’s two-way data binding makes it difficult to develop consistent page changes outside of the context of Angular. Difficult…but not impossible.

Say you want to change the value of $scope.helloWorld. You need a way to tell Angular, “Hey, a value has changed — you need to propagate this change throughout the app.”

Angular checks $scope variables for changes whenever an event happens. An event attribute like ng-click or ng-model will force Angular to run the Digest Loop*, where a process called dirty checking* is used to update the whole of the app with any new values.

If you want to change the value of $scope.helloWorld and have it propagated throughout the app, you need to trick Angular into thinking an event has occurred.

But, how?

First step: You’ll need to access the model in the $scope object. You can do this simply by querying it in the DOM.

Testing on Angular_$scope

In this example, you’re looking at the $scope object containing all models available to the H1 element. You’re looking at the helloWorld variable exposed.

Once you have access to helloWorld, you can reassign it. But wait! You’ve probably noticed that the text hasn’t changed in the window… That’s because your code is running outside the context of Angular — Angular doesn’t know that a change has actually been made. You need to tell Angular to run the digest loop, which will apply the change within it’s context.

Fortunately, Angular comes equipped with an $apply function, that can force a $digest, as shown below.

Testing on Angular_$apply

3. Watch for changes

This workaround is a little manual, but very important. If the source code changes a variable or calls a function bound to $scope, you’ll need to be able to detect this change in order to keep your test functional.

That’s where Angular’s $watch function comes in. You can use $watch to listen to $scope and provide a callback when changes happen.

In the example below, $watch is listening to $scope.helloWorld. If helloWorld changes, Angular will run a callback that provides the new value and the old value of helloWorld as parameters.

Testing on Angular_$watch

Custom directives and dependency injection

It’s important that you don’t default to writing jQuery when testing on Angular apps. Remember, you have access to all the functionality of Angular, so use it. For complex experiments, you can use custom directives to manage code structure and make it easy to debug.

To do this, you can implement an injector to apply components in the context of the app that you’re testing on. Here’s a simple example that will alert you if your helloWorld variable changes:

For more details on how to use an injector, click here.


These are just a few of the tactics that the WiderFunnel Dev team uses to run successful conversion optimization on Angular apps. That said, we would love to hear from all of you about how you do CRO on Angular!

Do you use the same tactics described here? Do you know of other workarounds not mentioned here? How do you test successfully on Angular apps? Let us know in the comments!


DOM: The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML, and XML documents

$scope: Scope is an object that refers to the application model. It is an execution context for expressions. Scopes are arranged in hierarchical structure which mimic the DOM structure of the application. Scopes can watch expressions and propagate events.

$apply: Apply is used to execute an expression in Angular from outside of the Angular framework. (For example from browser DOM events, setTimeout, XHR or third party libraries).

JSON: (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999

Two-way data binding: Data-binding in Angular apps is the automatic synchronization of data between the model and view components. The way that Angular implements data-binding allows you to treat the model as the single source of truth in your application.

Digest Loop: There is an internal cycle called $digest that runs through the application and executes watch expressions and compares the value returned with the previous value and if the values do not match then a listener is fired. This $digest cycle keeps looping until no more listeners are fired.

Dirty Checking: Dirty checking is a simple process that boils down to a very basic concept: It checks whether a value has changed that hasn’t yet been synchronized across the app

The post Tips and tactics for A/B testing on AngularJS apps appeared first on WiderFunnel Conversion Optimization.

Visit source: 

Tips and tactics for A/B testing on AngularJS apps

Is your biggest a/b testing barrier a technical one?

When you think of ‘conversion optimization’, what’s the first thing that pops into your head?

  • Testing buttons? Other design elements?
  • Using persuasion techniques and psychological triggers?
  • Landing page optimization?
  • Yes! I want more clicks!
  • Yes! I want more money!!

Okay, okay, we could do this for a while. Here’s the point…

When marketers talk about conversion optimization, we tend to talk about all of the factors that go into creating an experiment (and the expected return on investment, of course).

And, this makes sense. We’re all about online elements that you can see, read, engage with and how these elements motivate (or un-motivate) our users to click, follow and purchase.


There’s an often-ignored aspect to conversion optimization that can cut your testing velocity in half, or worse!

I’m talking about what goes on behind the scenes: the development side of an experiment. That phase where an idea, a wireframe, a design brief is transformed into a live experiment. It’s an unknown, and possibly scary, process for many marketers. Who really knows what those developers are up to anyway, right?

This integral part of conversion optimization doesn’t get much attention. But it’s so important. If your development process isn’t smooth, launching an experiment can take forever. You can get caught up in never-ending QA, which delays your experiment, which delays your results, which is frustrating to no end.

So, in this post, we’re revealing some of the most common technical difficulties associated with conversion optimization and how your team can conquer them.

Don’t let the following seven technical barriers kill your optimization program!

1. The Flicker

Probably the most common error in conversion rate optimization is known as the flicker or Flash of Original Content (FOOC).

An example of FOOC. This is not how you want to be a/b Testing.

I’ll offer a brief overview here, but if you really want to dig into FOOC, read “11 ways to stop FOOCing your A/B tests”.


When you’re a/b testing, you’re injecting code, meaning you’re making changes to a page in a browser once that page is loaded. You’re allowing the page to load its original content and then you’re adding script that changes that content into something else. If you haven’t accounted for FOOC, your visitors may be seeing that flicker or flash of original content before they see the proper variation.


There are several ways to combat FOOC. One is to ensure that the snippet for whatever testing tool you’re using is in the head of the document, preferably at the top, just after the metatags. Most people put this snippet in the body, but don’t make this mistake! This placement means that everything else loads before the snippet is detected.

The aforementioned post outlines 10 other ways to conquer conversion optimization-induced FOOC: if you’re struggling with flicker, it’s worth a serious look!

2. Troubled tracking

Without proper goal tracking, your a/b test may be DOA. Skewed tracking can result in a losing variation being declared a winner, or a winning variation being declared a loser. Goal tracking will make or break an experiment: an incorrect setup can lead to wasted developer time and traffic allocation.

There are two types of goals: visit goals and click goals. The former is assigned to a page URL, the latter to an interaction with a page. You want to make sure that you’re tracking the right goal at the right time. For example, if you want to track engagement with a call-to-action that directs visitors to a new page, you want to track how many people are actually clicking, rather than the page URL itself.

click goal vs. visit goal
Are you tracking a click or a URL?


When a visitor clicks something, a message (also known as an API call) is sent to your testing tool saying ‘hey, this got clicked’. However, if there is a page redirect occurring at the same time as the click, the redirect will override the tracking of the click. If you don’t allow enough time for the click goal to register before you send your visitor to a new page, you could lose that click.

What’s more, depending on a visitor’s computer speed or the browser they’re using, their click may be tracked, but this data in its entirety will be skewed. You’ll see clicks coming in, but you may only be capturing a fraction of the actual clicks.


The solution here is pretty simple: you’ve gotta allow time before you redirect the page. Standard practice at WiderFunnel is to count one second after the click goal has been sent before redirecting. This prevents the cancellation of the API call.

3. Confused selection

selector prefix
The ‘wf’ prefix allows us to properly identify selectors.

A selector is used to apply rules to certain elements within the document object model (DOM). The DOM contains the building blocks that tell a browser how to read HTML: it’s a whole bunch of text that forms the structure of a website.


Say you’re running an experiment on multiple pages. You’re trying to change the background color to blue on a certain area of a certain page. But, you find that on another page, where you don’t want the blue background, the blue background is appearing. They’re totally different areas, but they’re probably using the same selector.


It’s always a good idea to add prefixes to your selectors to 1) make them unique and 2) distinguish them from the selectors that belong to the source code. We add a handy ‘wf’ prefix to ours, to keep everything clear.

4. Garbage code quality

Good code is really important in testing in general. Because you’re injecting new code into an existing, fully-formed website, you have to make sure that whatever changes you make are as minimal as possible.


If your code is not on point, you risk slowing your site’s loading speed and creating extra bugs.


To avoid messing with your site’s load speed:

1) Cache your variables. Rather than asking the DOM to access a variable or selector multiple times, you can link these instances. This way, you’re only querying the DOM once vs. multiple times, which can substantially speed up load times.

image sprite
Load your icons in a sprite, like this!

2) Load your resources in sprites. According to our dev team, this is just good standard practice, but I thought I’d cover all the bases. Loading in a sprite means you’re loading multiple images one time into the DOM, as opposed to loading each image individually. If you did the latter, the DOM would have to load each image separately, slowing load time.

To avoid creating extra bugs on your site:

Make sure that the code you’re injecting doesn’t rely too heavily on the source code. If you bind your variation code too tightly to your source code, you could be creating cases that don’t exist in the source code. If you don’t take precautions, you might be sending something to the backend that could come back as an error because the source code hasn’t had to deal with that situation before.

5. Responsive confusion

If your site is responsive (as is most likely the case) and you decide to run a site-wide test (as often happens), you must keep an eye on dynamic elements.


responsive code
Does your code account for every scenario?

When there are dynamic elements on a site — like descriptions on a product page that can range in length — you will run into trouble if you don’t consider formatting. You can’t just build for that product description element on a single page, because there’s a chance that it’s totally different on another page. It might be three words long in one place and paragraphs long in another; you have to make sure that these differences won’t lead to a wonky display.


The best way to tackle this one is through due-diligence; this issue is really an issue because it’s easy to overlook. One of our developers, Thomas Davis, recommends switching pages every so often when you’re coding a variation (if the experiment is site-wide, that is). Build an element to work on multiple pages: start on one product page, continue on another product page. This way, you can ensure that the formatting doesn’t break from page to page.

6. Cross-browser code (aka The Internet Explorer conundrum)

Cross-browser code
Make sure your pages can cross browsers.

As simple as it seems, it’s really easy to overlook cross-browser compliance when you’re building a test. This can be a chore, particularly when you’re working with Internet Explorer.

*For an informative discussion on why Internet Explorer is such a thorn in most developers’ side, check out this Reddit thread.


When you’re busy and under pressure (to say, launch an experiment quickly), it can be easy to forget about testing your code across multiple browsers and devices. A variation can look completely normal in Chrome, but display incorrectly in IE.


You’ve gotta put in the time, as with ensuring your code is responsive, to be diligent about cross-browser testing. We test in all browsers and we test on both Mac and PC, all before our tests go to QA to ensure a seamless experience for our clients’ visitors. It’s important to account for all of the options, otherwise you risk revealing what’s behind the curtain (and that never ends well).

7. What’s the ‘Why’?

Tony Ta

In order to get good at conversion optimization, you need to know why you’re doing it.

Tony Ta, Lead Developer, WiderFunnel

This last one is less of a technical mistake, and more a cautionary suggestion.

Let’s say that your development resources are limited. Your organization relies on one development team for internal maintenance and improvement. They’re very busy and their time is expensive (those specialized skills, and all).

You’ve decided to venture into conversion optimization because, if all of the work your dev team is doing isn’t proven to increase conversions on your site…what’s the point?

But, your devs aren’t in the loop. Maybe they have some familiarity with CRO, but maybe they don’t. They’re not a part of your marketing team, their job is to code, to fix, to problem solve in a particular way. And now they’re coding experiments that they don’t really understand.

Don’t go this route. It’s particularly important to your optimization process that you let your developers in on the ‘why’ behind what you’re doing. It can be tough to take the time to explain, particularly if both departments are slammed (as is often the case).

But, without the ‘why’, mistakes will be made and problems will be missed.

Tabish Khan

A dev needs to know the end goal, the big picture as to why they are doing what they are doing. This allows them to see solutions that others may not see.

Tabish Khan, Front End Developer, WiderFunnel

When I first sat down to write this post, I sent a survey to our development team. I asked a bunch of questions about why conversion optimization is so difficult from a programming perspective.

Not only did I learn about the common technical difficulties outlined above, I also learned a little bit about what makes our team so great at what they do.

One word: focus. Conversion optimization coding isn’t simple. Our development team is good at what they do because it’s all they do.

Thomas Davis

We’ve done this 1,000 times. We know what to do when we face an issue. We understand conversion rate optimization. We know every tool and all of the hidden features. We know how to make a variation work without breaking the existing code.

Thomas Davis, Super Confident Front End Developer, WiderFunnel

If you’re considering CRO as a strategy, consider your development team. Consider their bandwidth, their focus, their time. If you want to implement a rapid and successful testing program, assemble a team that can give your strategy their full attention. Or bring in a partner with a specialized team at the ready.

For more information on how to create and implement a successful conversion rate optimization strategy, download the free guide below.

The post Is your biggest a/b testing barrier a technical one? appeared first on WiderFunnel.

Originally posted here: 

Is your biggest a/b testing barrier a technical one?

Declarative Programming And The Web

Like most web developers, I spend my days giving instructions to computers. These instructions generally involve some input (a request for a web page), some logic (get the right content from a database) and some output (send the content to the requesting browser). This process of telling a computer how to perform a task, such as generating a web page, is what we commonly call “programming,” but it’s only a subset of programming: imperative programming.

See the article here:  

Declarative Programming And The Web

Don’t Be Scared Of Functional Programming

Functional programming is the mustachioed hipster of programming paradigms. Originally relegated to the annals of computer science academia, functional programming has had a recent renaissance that is due largely to its utility in distributed systems (and probably also because “pure” functional languages like Haskell are difficult to grasp, which gives them a certain cachet).
Stricter functional programming languages are typically used when a system’s performance and integrity are both critical — i.

See original: 

Don’t Be Scared Of Functional Programming

How WordPress Came To Be – An Interviews With Matt Mullenweg And Mike Little

2013 was a busy year for me for conferences and travel. It was also the year I attended my first (and second) WordCamp. The first was WordCamp UK in July, where I met Mike Little, one of the two co-founders of WordPress. Three months later, I was honored to meet the other co-founder, Matt Mullenweg, twice in three weeks: at WordCamp Europe in Leiden, and at The Summit. I was lucky enough to have both Matt and Mike participate in interviews for this post about WordPress, including its history, community and future.

See original article: 

How WordPress Came To Be – An Interviews With Matt Mullenweg And Mike Little

The Future Of CSS: Embracing The Machine

Designers hold CSS close to their hearts. It’s just code, but it is also what makes our carefully crafted designs come to life. Thoughtful CSS is CSS that respects our designs, that is handcrafted with precision. The common conception among Web designers is that a good style sheet is created by hand, each curly bracket meticulously placed, each vendor prefix typed in manually.
But how does this tradition fit in a world where the websites and applications that we want to create are becoming increasingly complex?


The Future Of CSS: Embracing The Machine

27 Email Newsletters Worth Subscribing To

Staying on top of the most recent developments in your craft takes time, especially when you have to scan websites daily for articles and news worthy of your attention. Quality newsletters do the job for you. Just check your email inbox every couple of days to find a condensed and readily accessible selection of tidbits from a given website. We have selected here newsletters that deserve your attention.
A quality newsletter is not overloaded with articles, but rather features valuable insight and information, in addition to what the given website has featured during the week.


27 Email Newsletters Worth Subscribing To