Tag Archives: introduction

Getting Started With The Web MIDI API

As the web continues to evolve and new browser technologies continue to emerge, the line between native and web development becomes more and more blurred. New APIs are unlocking the ability to code entirely new categories of software in the browser.

Until recently, the ability to interact with digital musical instruments has been limited to native, desktop applications. The Web MIDI API is here to change that.

In this article, we’ll cover the basics of MIDI and the Web MIDI API to see how simple it can be to create a web app that responds to musical input using JavaScript.

What Is MIDI?

MIDI has been around for a long time but has only recently made its debut in the browser. MIDI (Musical Instrument Digital Interface) is a technical standard that was first published in 1983 and created the means for digital instruments, synthesizers, computers, and various audio devices to communicate with each other. MIDI messages relay musical and time-based information back and forth between devices.

A typical MIDI setup might consist of a digital piano keyboard which can send messages relaying information such as pitch, velocity (how loudly or softly a note is played), vibrato, volume, panning, modulation, and more to a sound synthesizer which converts that into audible sound. The keyboard could also send its signals to desktop music scoring software or a digital audio workstation (DAW) which could then convert the signals into written notation, save them as a sound file, and more.

MIDI is a fairly versatile protocol, too. In addition to playing and recording music, it has become a standard protocol in stage and theater applications, as well, where it is often used to relay cue information or control lighting equipment.


A performer plays a digital piano onstage


MIDI lets digital instruments, synthesizers, and software talk to each other and is frequently used in live shows and theatrical productions. Photo by Puk Khantho on Unsplash.

MIDI In The Browser

The WebMIDI API brings all the utility of MIDI to the browser with some pretty simple JavaScript. We only need to learn about a few new methods and objects.

Introduction

First, there’s the navigator.requestMIDIAccess() method. It does exactly what it sounds like—it will request access to any MIDI devices (inputs or outputs) connected to your computer. You can confirm the browser supports the API by checking for the existence of this method.

if (navigator.requestMIDIAccess) 
    console.log('This browser supports WebMIDI!');
 else 
    console.log('WebMIDI is not supported in this browser.');

Second, there’s the MIDIAccess object which contains references to all available inputs (such as piano keyboards) and outputs (such as synthesizers). The requestMIDIAccess() method returns a promise, so we need to establish success and failure callbacks. And if the browser is successful in connecting to your MIDI devices, it will return a MIDIAccess object as an argument to the success callback.

navigator.requestMIDIAccess()
    .then(onMIDISuccess, onMIDIFailure);

function onMIDISuccess(midiAccess) 
    console.log(midiAccess);

    var inputs = midi.inputs;
    var outputs = midi.outputs;


function onMIDIFailure() 
    console.log('Could not access your MIDI devices.');

Third, MIDI messages are conveyed back and forth between inputs and outputs with a MIDIMessageEvent object. These messages contain information about the MIDI event such as pitch, velocity (how softly or loudly a note is played), timing, and more. We can start collecting these messages by adding simple callback functions (listeners) to our inputs and outputs.

Going Deeper

Let’s dig in. To send MIDI messages from our MIDI devices to the browser, we’ll start by adding an onmidimessage listener to each input. This callback will be triggered whenever a message is sent by the input device, such as the press of a key on the piano.

We can loop through our inputs and assign the listener like this:

function onMIDISuccess(midiAccess) 
    for (var input of midiAccess.inputs.values())
        input.onmidimessage = getMIDIMessage;
    
}

function getMIDIMessage(midiMessage) 
    console.log(midiMessage);

The MIDIMessageEvent object we get back contains a lot of information, but what we’re most interested in is the data array. This array typically contains three values (e.g. [144, 72, 64]). The first value tells us what type of command was sent, the second is the note value, and the third is velocity. The command type could be either “note on,” “note off,” controller (such as pitch bend or piano pedal), or some other kind of system exclusive (“sysex”) event unique to that device/manufacturer.

For the purposes of this article, we’ll just focus on properly identifying “note on” and “note off” messages. Here are the basics:

  • A command value of 144 signifies a “note on” event, and 128 typically signifies a “note off” event.
  • Note values are on a range from 0–127, lowest to highest. For example, the lowest note on an 88-key piano has a value of 21, and the highest note is 108. A “middle C” is 60.
  • Velocity values are also given on a range from 0–127 (softest to loudest). The softest possible “note on” velocity is 1.
  • A velocity of 0 is sometimes used in conjunction with a command value of 144 (which typically represents “note on”) to indicate a “note off” message, so it’s helpful to check if the given velocity is 0 as an alternate way of interpreting a “note off” message.

Given this knowledge, we can expand our getMIDIMessage handler example above by intelligently parsing our MIDI messages coming from our inputs and passing them along to additional handler functions.

function getMIDIMessage(message) 
    var command = message.data[0];
    var note = message.data[1];
    var velocity = (message.data.length > 2) ? message.data[2] : 0; // a velocity value might not be included with a noteOff command

    switch (command) 
        case 144: // noteOn
            if (velocity > 0) 
                noteOn(note, velocity);
             else 
                noteOff(note);
            
            break;
        case 128: // noteOff
            noteOff(note);
            break;
        // we could easily expand this switch statement to cover other types of commands such as controllers or sysex
    }
}

Browser Compatibility And Polyfill

As of the writing of this article, the Web MIDI API is only available natively in Chrome, Opera, and Android WebView.


Browser support for Web MIDI API from caniuse.com


The Web MIDI API is only available natively in Chrome, Opera, and Android WebView.

For all other browsers that don’t support it natively, Chris Wilson’s WebMIDIAPIShim library is a polyfill for the Web MIDI API, of which Chris is a co-author. Simply including the shim script on your page will enable everything we’ve covered so far.

<script src="WebMIDIAPI.min.js"></script>    
<script>
if (navigator.requestMIDIAccess)  //... returns true
</script>

This shim also requires Jazz-Soft.net’s Jazz-Plugin to work, unfortunately, which means it’s an OK option for developers who want the flexibility to work in multiple browsers, but an extra barrier to mainstream adoption. Hopefully, within time, other browsers will adopt the Web MIDI API natively.

Making Our Job Easier With WebMIDI.js

We’ve only really scratched the surface of what’s possible with the WebMIDI API. Adding support for additional functionality besides basic “note on” and “note off” messages starts to get much more complex.

If you’re looking for a great JavaScript library to radically simplify your code, check out WebMidi.js by Jean-Philippe Côté on Github. This library does a great job of abstracting all the parsing of MIDIAccess and MIDIMessageEvent objects and lets you listen for specific events and add or remove listeners in a much simpler way.

WebMidi.enable(function () 

    // Viewing available inputs and outputs
    console.log(WebMidi.inputs);
    console.log(WebMidi.outputs);

    // Retrieve an input by name, id or index
    var input = WebMidi.getInputByName("My Awesome Keyboard");
    // OR...
    // input = WebMidi.getInputById("1809568182");
    // input = WebMidi.inputs[0];

    // Listen for a 'note on' message on all channels
    input.addListener('noteon', 'all',
        function (e) 
            console.log("Received 'noteon' message (" + e.note.name + e.note.octave + ").");
        
    );

    // Listen to pitch bend message on channel 3
    input.addListener('pitchbend', 3,
        function (e) 
            console.log("Received 'pitchbend' message.", e);
        
    );

    // Listen to control change message on all channels
    input.addListener('controlchange', "all",
        function (e) 
            console.log("Received 'controlchange' message.", e);
        
    );

    // Remove all listeners for 'noteoff' on all channels
    input.removeListener('noteoff');

    // Remove all listeners on the input
    input.removeListener();

});

Real-World Scenario: Building A Breakout Room Controlled By A Piano Keyboard

A few months ago, my wife and I decided to build a “breakout room” experience in our house to entertain our friends and family. We wanted the game to include some kind of special effect to help elevate the experience. Unfortunately, neither of us have mad engineering skills, so building complex locks or special effects with magnets, lasers, or electrical wiring was outside the realm of our expertise. I do, however, know my way around the browser pretty well. And we have a digital piano.

Thus, an idea was born. We decided that the centerpiece of the game would be a series of passcode locks on a computer that players would have to “unlock” by playing certain note sequences on our piano, a la Willy Wonka.

This is a musical lock
This is a musical lock

Sound cool? Here’s how I did it.

Setup

We’ll begin by requesting WebMIDI access, identifying our keyboard, attaching the appropriate event listeners, and creating a few variables and functions to help us step through the various stages of the game.

// Variable which tell us what step of the game we're on. 
// We'll use this later when we parse noteOn/Off messages
var currentStep = 0;

// Request MIDI access
if (navigator.requestMIDIAccess) 
    console.log('This browser supports WebMIDI!');

    navigator.requestMIDIAccess().then(onMIDISuccess, onMIDIFailure);

 else 
    console.log('WebMIDI is not supported in this browser.');


// Function to run when requestMIDIAccess is successful
function onMIDISuccess(midiAccess) 
    var inputs = midiAccess.inputs;
    var outputs = midiAccess.outputs;

    // Attach MIDI event "listeners" to each input
    for (var input of midiAccess.inputs.values()) 
        input.onmidimessage = getMIDIMessage;
    
}

// Function to run when requestMIDIAccess fails
function onMIDIFailure() 
    console.log('Error: Could not access MIDI devices.');


// Function to parse the MIDI messages we receive
// For this app, we're only concerned with the actual note value,
// but we can parse for other information, as well
function getMIDIMessage(message) 
    var command = message.data[0];
    var note = message.data[1];
    var velocity = (message.data.length > 2) ? message.data[2] : 0; // a velocity value might not be included with a noteOff command

    switch (command) 
        case 144: // note on
            if (velocity > 0) 
                noteOn(note);
             else 
                noteOff(note);
            
            break;
        case 128: // note off
            noteOffCallback(note);
            break;
        // we could easily expand this switch statement to cover other types of commands such as controllers or sysex
    }
}

// Function to handle noteOn messages (ie. key is pressed)
// Think of this like an 'onkeydown' event
function noteOn(note) 
    //...


// Function to handle noteOff messages (ie. key is released)
// Think of this like an 'onkeyup' event
function noteOff(note) 
    //...


// This function will trigger certain animations and advance gameplay 
// when certain criterion are identified by the noteOn/noteOff listeners
// For instance, a lock is unlocked, the timer expires, etc.
function runSequence(sequence) 
    //...

Step 1: Press Any Key To Begin

To kick off the game, let’s have the players press any key to begin. This is an easy first step which will clue them into how the game works and also start a countdown timer.

function noteOn(note) 
    switch(currentStep) 
        // If the game hasn't started yet.
        // The first noteOn message we get will run the first sequence
        case 0: 
            // Run our start up sequence
            runSequence('gamestart');

            // Increment the currentStep so this is only triggered once
            currentStep++;
            
            break;
    
}

function runSequence(sequence) 
    switch(sequence) 
        case 'gamestart':            
            // Now we'll start a countdown timer...
            startTimer();
            
            // code to trigger animations, give a clue for the first lock
            break;
    
}

Step 2: Play The Correct Note Sequence

For the first lock, the players must play a particular sequence of notes in the right order. I’ve actually seen this done in a real breakout room, only it was with an acoustic upright piano rigged to a lock box. Let’s re-create the effect with MIDI.

For every “note on” message received, we’ll append the numeric note value to an array and then check to see if that array matches a predefined array of note values.

We’ll assume some clues in the breakout room have told the players which notes to play. For this example, it will be the beginning of the tune to “Amazing Grace” in the key of F major. That note sequence would look like this.


A visual representation of the first nine notes of “Amazing Grace” on a piano


This is the correct sequence of notes that we’ll be listening for as the solution to the first lock.

The MIDI note values in array form would be: [60, 65, 69, 65, 69, 67, 65, 62, 60].

var correctNoteSequence = [60, 65, 69, 65, 69, 67, 65, 62, 60]; // Amazing Grace in F
var activeNoteSequence = [];

function noteOn(note) 
    switch(currentStep) 
        // ... (case 0)

        // The first lock - playing a correct sequence
        case 1:
            activeNoteSequence.push(note);

            // when the array is the same length as the correct sequence, compare the two
            if (activeNoteSequence.length == correctNoteSequence.length) 
                var match = true;
                for (var index = 0; index < activeNoteSequence.length; index++) 
                    if (activeNoteSequence[index] != correctNoteSequence[index]) 
                        match = false;
                        break;
                    
                }

                if (match) 
                    // Run the next sequence and increment the current step
                    runSequence('lock1');
                    currentStep++;
                 else 
                    // Clear the array and start over
                    activeNoteSequence = [];
                
            }
            break;
    }
}

function runSequence(sequence) 
    switch(sequence) 
        // ...

        case 'lock1':
            // code to trigger animations and give clue for the next lock
            break;
    
}

Step 3: Play The Correct Chord

The next lock requires the players to play a combination of notes at the same time. This is where our “note off” listener comes in. For every “note on” message received, we’ll add that note value to an array; for every “note off” message received, we’ll remove that note value from the array. Therefore, this array will reflect which notes are currently being pressed at any time. Then, it’s a matter of checking that array every time a note value is added to see if it matches a master array with the correct values.

For this clue, we’ll make the correct answer a C7 chord in root position starting on middle C. That looks like this.


A visual representation of a C7 chord on a piano


These are the four notes that we’ll be listening for as the solution to the second lock.

The correct MIDI note values for this chord are: [60, 64, 67, 70].

var correctChord = [60, 64, 67, 70]; // C7 chord starting on middle C
var activeChord = [];

function noteOn(note) 
    switch(currentStep) 
        // ... (case 0, 1)

        case 2:
            // add the note to the active chord array
            activeChord.push(note);

            // If the array is the same length as the correct chord, compare
            if (activeChord.length == correctChord.length) 
                var match = true;
                for (var index = 0; index < activeChord.length; index++) 
                    if (correctChord.indexOf(activeChord[index]) < 0) 
                        match = false;
                        break;
                    
                }

                if (match) 
                    runSequence('lock2');
                    currentStep++;
                
            }
            break;
    }

function noteOff(note) 
    switch(currentStep) 
        case 2:
            // Remove the note value from the active chord array
            activeChord.splice(activeChord.indexOf(note), 1);
            break;
    
}

function runSequence(sequence) 
    switch(sequence) 
        // ...

        case 'lock2':
            // code to trigger animations, stop clock, end game
            stopTimer();

            break;
    
}

Now all that’s left to do is to add some additional UI elements and animations and we have ourselves a working game!

Here’s a video of the entire gameplay sequence from start to finish. This is running in Google Chrome. Also shown is a virtual MIDI keyboard to help visualize which notes are currently being played. For a normal breakout room scenario, this can run in full-screen mode and with no other inputs in the room (such as a mouse or computer keyboard) to prevent users from closing the window.

WebMIDI Breakout Game Demo (watch in Youtube)

If you don’t have a physical MIDI device laying around and you still want to try it out, there are a number of virtual MIDI keyboard apps out there that will let you use your computer keyboard as a musical input, such as VMPK. Also, if you’d like to further dissect everything that’s going on here, check out the complete prototype on CodePen.

See the Pen WebMIDI Breakout Room Demo by Peter Anglea (@peteranglea) on CodePen.

Conclusion

MIDI.org says that “Web MIDI has the potential to be one of the most disruptive music [technologies] in a long time, maybe as disruptive as MIDI was originally back in 1983.” That’s a tall order and some seriously high praise.

I hope this article and sample app has gotten you excited about the potential that this API has to spur the development of new and exciting kinds of browser-based music applications. In the coming years, hopefully, we’ll start to see more online music notation software, digital audio workstations, audio visualizers, instrument tutorials, and more.

If you want to read more about Web MIDI and its capabilities, I recommend the following:

And for further inspiration, here are some other examples of the Web MIDI API in action:

Smashing Editorial
(rb, ra, hj, il)

Read More:

Getting Started With The Web MIDI API

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

Web Development Reading List #187: Webpack 3, Assisted Writing, And Automated Chrome Testing

This week, we’ll explore some rather new concepts: What happens if we apply artificial intelligence to text software, for example? And why would a phone manufacturer want its business model to be stolen by competitors? We’ll also take a look at how we can use the new headless Chrome browser for automated testing and learn to build smarter JavaScript bundles with Webpack 3’s new scope hoisting. Sometimes it’s easy to be excited about all the improvements and new things our industry has to offer.

See the article here: 

Web Development Reading List #187: Webpack 3, Assisted Writing, And Automated Chrome Testing

How To Develop An Interactive Command Line Application Using Node.js

Over the last five years, Node.js has helped to bring uniformity to software development. You can do anything in Node.js, whether it be front-end development, server-side scripting, cross-platform desktop applications, cross-platform mobile applications, Internet of Things, you name it. Writing command line tools has also become easier than ever before because of Node.js — not just any command line tools, but tools that are interactive, useful and less time-consuming to develop.

How To Develop An Interactive Command Line Application Using Node.js

If you are a front-end developer, then you must have heard of or worked on Gulp, Angular CLI, Cordova, Yeoman and others. Have you ever wondered how they work?

The post How To Develop An Interactive Command Line Application Using Node.js appeared first on Smashing Magazine.

This article: 

How To Develop An Interactive Command Line Application Using Node.js

Web Development Reading List #168: Preload With Webpack, A Guide To Security Headers, And Service Worker Fallacies

With great power comes great responsibility. This week I found some resources that got me thinking: Service Workers that download 16MB of data on the user’s first visit? A Bluetooth API in the browser? Private browser windows that aren’t so private at all?
We have a lot of methods and strategies to fix these kinds of things. We can give the browser smarter hints, put security headers and HTTPS in place, serve web fonts locally, and build safer network protocols.

View post:

Web Development Reading List #168: Preload With Webpack, A Guide To Security Headers, And Service Worker Fallacies

Styled-Components: Enforcing Best Practices In Component-Based Systems

Building user interfaces on the web is hard, because the web and, thus, CSS were inherently made for documents. Some smart developers invented methodologies and conventions such as BEM, ITCSS, SMACSS and many more, which make building user interfaces easier and more maintainable by working with components.

Styled-Components: Enforcing Best Practices In Component-Based Systems

After this shift in mindset towards building component-based user interfaces, we are now in what we like to call the “component age.” The rise of JavaScript frameworks such as React, Ember and recently Angular 2, the effort of the W3C to standardize a web-native component system, pattern libraries and style guides being considered the “right way” to build web applications, and many other things have illuminated this revolution.

The post Styled-Components: Enforcing Best Practices In Component-Based Systems appeared first on Smashing Magazine.

Read More: 

Styled-Components: Enforcing Best Practices In Component-Based Systems

How Agencies Should Approach Conversion Optimization for eCommerce | An Interview with AWA Digital

Going ahead with our interview series, this time we are in conversation with Johann Van Tonder from AWA Digital.

Johann, is the COO at AWA Digital, a leading international Conversion Optimization (CRO) agency, specializing in eCommerce.

He is also the coauthor of the book E-commerce Optimization, out in January 2017. He speaks about how they practice conversion optimization for different verticals of their eCommerce clients.

After reading this post, agencies will learn the nuances of CRO when applied to different eCommerce verticals such as Fashion, Homeware, and Consumer Electronics. They’ll learn CRO strategies that will help them make a stronger case for adopting CRO for their prospective eCommerce clients.

Introduction

1) How important do you think Conversion Optimization (CRO) is for eCommerce enterprises? Why?

CRO is one of the best growth strategies available to eCommerce firms. Turnover is not something you influence directly. It is the outcome of activities performed in other areas. The rate at which people buy from you and how much they spend when they buy, are within your control. In turn, these will increase the revenue and ultimately profit. This is what CRO is about.

On average, for every £92 spent on getting traffic to UK websites, only £1 is spent on improving the conversion rate. If you improve the ability of your site to generate money, your acquisition dollars stretch further as more of the visitors are converted to buyers.

2) Is there a difference in your approach to CRO for different eCommerce verticals? If yes, how?

Not really. We always follow an evidence-led approach informed by research, data analysis, and testing. That said, our implementation will not be the same on two projects as we are guided by the opportunities specific to that particular website.

As long as you follow the scientific method, which we outline in our book E-commerce Optimization (Kogan Page), the same approach can generally be applied across different verticals. Broadly speaking, it’s a system of generating and prioritizing relevant ideas, and a mechanism by which to test those ideas.

3) Which are the major eCommerce verticals that you have worked with?

We have extensive experience in the fashion retail industry, having worked with top clothing and footwear brands from different countries. Furniture and homeware are two other categories we are well-known for.

Other big verticals for us include consumer electronics, flowers, gardening, gifting, health products, and outdoor travel gear. Our entire portfolio ranges from bathroom fittings to wearable technology.

Conversion Optimization for Different eCommerce Verticals

4) Do your CRO goals (micro and macro) differ for Fashion, Homeware and Consumer electronics based eCommerce businesses?

Our philosophy is to optimize for revenue, so in almost all cases, the primary metric is Revenue Per Visitor (RPV). If it’s an eCommerce business, Conversion Rate simply doesn’t give you the complete picture.

Secondary metrics, aligned with micro goals, vary widely. These are typically determined by the context of the experiment, rather than the vertical. For example, on a product detail page (PDP), you might want to track clicks on “add to basket” and engagement with product images. It helps to interpret the outcome of the test.

Sometimes we track key performance indicators (KPIs) outside of the testing environment. For example, experimenting with free delivery for a fashion client, we tracked product returns and married this data manually with test results.

5) What are the main “conversion funnels” for these different eCommerce websites? Do you see a difference in major traffic sources for the websites?

It’s not uncommon to see organic search being the major source of traffic for known brands. Often, the lion’s share of that is branded search terms, so in a way, it’s an extension of direct traffic. When a business is still establishing its brand, you’d expect to see more from paid search and other channels.

Many agencies limit optimization efforts to the website, which is a mistake. Social is an exciting area for some businesses, often rich with opportunities. Email consistently delivers good results for many of our clients and therefore, any gains in this arena can have a significant impact on overall business results.

Omni-channel, where we have a lot of experience, adds different dynamics. Not only do you see more direct traffic at the top of the funnel, but a large group of website visitors tend to browse with the intention to buy in-store. Or they may buy online, but only after visiting a store to “touch and feel” the product.

It’s important for the optimizer to take into consideration the entire journey, mapping out how the various touch points contribute to the purchase decision.

6)  Which persuasion principles (scarcity, social proof, reciprocity, etc.) do you use in optimizing different eCommerce vertical websites?

We regularly use social proof, liking, authority, and scarcity. It depends entirely on the situation. We don’t actively look for ways to plug them in. Instead, we examine the data and use a principle if it seems like a relevant solution. For example, one of our clients sells plants by catalogue and online. A common sales objection was whether the flowers would look as good in the customer’s garden as they are in the product images. This prompted us to invite customers to submit pictures of products in their gardens, invoking the social proof principle.

Once we’ve decided to use a principle, we may run a few tests to find the best implementation.

If a principle is already present on the website, there could be ways of making it more persuasive. In some cases, a message can be distracting in one part of the funnel yet very effective in another area of the site.

7) Which are the common conversion killers for these different eCommerce enterprises?

Some are universal, for example, delivery. Not only do consumers generally resist paying for shipping, but long waiting periods put them off. If you charge for it, you have to treat it like a product with its own compelling value proposition.

In the fashion industry, it’s size and fitting. Will these boots fit me? How will this shirt hang on me? Is your size 8 the same as another manufacturer’s size 8? These are the common themes. Typical concerns in the furniture and homeware space are material composition, dimensions, and perspective.

Sometimes we’re surprised by what we uncover. One of our clients, a gifting site, had a great returns policy. Obviously this was messaged clearly on the website. However, we discovered that it actually turned out to be a conversion killer for them. Why? Many of the buyers were grandparents who didn’t want to contemplate the prospect of their grandchildren returning their gifts.

8) The buying cycle for each eCommerce vertical website varies. Does your CRO strategy take this into account?

Definitely. The buying cycle is something we map out carefully.

For us, it is crucial to get under the skin of the customer. We want to understand exactly what goes into a sale being made or lost.

It can also inform our approach with testing. Normally we’d run an experiment for two weeks. However, if the purchase cycle is longer than that for the majority of customers, we may extend the test duration.

9) Does seasonality have an effect on your CRO strategy for different eCommerce verticals?

Clearly, some verticals are affected by it more than others. Seasonality is partly a reflection of customer needs. It is easier to deal with if you have a solid understanding of the core needs. In some verticals like gardening, it might be a good idea to conduct user research in low and high seasons.

Some clients are loath to run tests during peak trading periods like Christmas sales. Our view is that it is essential to optimize the site for those periods, especially if they contribute to annual turnover in any significant way.

10) On which eCommerce websites do you employ upsell/cross-sell strategies mostly?

Because our primary metric is usually Revenue Per Visitor rather than Conversion Rate, a driving question for us is how to increase Average Order Value. Upselling and cross-selling strategies are, therefore, almost always on our radar. We have had great success, for example, by optimizing the presentation and algorithms of popular product recommendation tools.

Upselling and cross-selling may be thought of as “tricking” the customer into spending more money. However, we’ve seen how frustrated customers become, having to hunt for items related to the one they are considering. It actually improves user experience, which is then reflected in an increase in revenue.

11) What CRO strategies do you apply on product pages of different eCommerce vertical websites (for instance, on product descriptions, product images, etc.)?

On most eCommerce sites, the product detail pages, or PDPs, have the highest drop-off rates on the site.

Exit rates in the region of 90%, and even higher are not uncommon. It is where the visitor is asked to make the decision. This is where questions about the product itself, as well as the buying process, are often most prominent.

We don’t have a checklist of tactics to apply to PDPs. Our test ideas emerge from research and analysis. If you understand the customer and what goes into the purchase decision, you’ll know what to test. Think of it as optimizing the sales conversation. It’s all about how you influence what plays out in the visitor’s mind.

  • Product description

If the visitors engage with product description, they may be closer to making a buying decision. Often this decision is based on the image, and reading the copy serves only to rationalize the purchase. Perhaps they are checking a few details or looking to answer a question about the product. The starting point for writing a good copy is knowing the customers and understanding their motivations and sales objections in relation to the product.

  • Product images

Likely to be the focus of most attention on the PDP. Often a substitute for reading product descriptions, so make sure you have a good selection of images that will answer key questions. On a lantern page, customers might wonder about the light patterns on their wall. Show them! Images appeal to System 1 thinking, which means purchase decisions are made instantly without thinking it over. Good images help the customer imagine themselves using the item, which can be quite persuasive.

Over to You

Do you have anything to add or suggest to this interview? Share with us what you think in the comments below.

CTA CRO program

The post How Agencies Should Approach Conversion Optimization for eCommerce | An Interview with AWA Digital appeared first on VWO Blog.

This article is from: 

How Agencies Should Approach Conversion Optimization for eCommerce | An Interview with AWA Digital

Web Development Reading List #157: FlyWeb, Lying Charts, And Feedback Without Context

We all have visions and dreams. Whether it’s about our personal lives, our work, or about complex concepts that target issues which are hard to grasp. The important thing is to listen to your ideas, to write them down, and, if they wake strong feelings, to pursue them.
It can be easy to achieve this, yet sometimes it’s not. A nice technique is to start small and take small steps instead of going 100% all-in or do nothing at all.

Continued here – 

Web Development Reading List #157: FlyWeb, Lying Charts, And Feedback Without Context

Building A Real-Time Retrospective Board With Video Chat


If you’ve ever worked in an agile environment, chances are you’ve had your share of “retrospectives” — meetings where people write what made them “glad,” “mad” or “sad” onto different-colored notes, post them onto a board, arrange them in groups and — most importantly — talk about them.

How To Build A Real-Time Retrospective Board With Video Chat

These meetings are straightforward, as long as everyone is in the same room. But if you’re working with a locally distributed team, things can get a bit tricky. Let’s address this by creating a virtual version of our board to allow team members in different locations to hold their retrospective just as if they were in the same room.

The post Building A Real-Time Retrospective Board With Video Chat appeared first on Smashing Magazine.

View article: 

Building A Real-Time Retrospective Board With Video Chat

Write Your Next Web App With Ember CLI


When you start a fresh web project or start digging into an existing code base, chances are you’re trying to create or enhance a feature for your users. The last thing you want to do is spend time customizing build tools and creating infrastructure to develop your application. If you land a new client, you want to show them features today, not in a week after you’ve cobbled together a build pipeline.

Write Your Next Web App With Ember CLI

As you might already know, Ember is an “opinionated” JavaScript web framework focused on building ambitious, rich client web applications. Technologically, Ember has positioned itself as the antidote to hype fatigue. It’s a framework that just won’t die, but keeps pressing on with each innovation and with a commitment to backwards-compatibility.

The post Write Your Next Web App With Ember CLI appeared first on Smashing Magazine.

Link:

Write Your Next Web App With Ember CLI