Throughout my time as a front-end developer, I felt that I was never given a straight explanation of how DOM events work. My aim here is to give you a clear overview of the subject, to get you up to speed more quickly than I did.

I will introduce the basics of working with DOM events, then delve into their inner workings, explaining how we can make use of them to solve common problems.

Listening For Events

In the past, browsers have had major inconsistencies in the way they attach event listeners to DOM nodes. Libraries such as jQuery have been invaluable in abstracting away these oddities.

As we move ever closer to standardized browser environments, we can more safely use the APIs from the official specification. To keep it simple, I will describe how to manage events for the modern Web. If you are writing JavaScript for Internet Explorer (IE) 8 or below, I would advise using a polyfill or framework (such as jQuery) to manage event listeners.

In JavaScript, we can listen to events using this:

element.addEventListener(<event-name>, <callback>, <use-capture>);

• event-name (string)
  This is the name or type of event that you would like to listen to. It could be any of the standard DOM events (click, mousedown, touchstart,transitionEnd, etc.) or even your own custom event name (we’ll touch on custom events later).
• callback (function)
  This function gets called when the event happens. The event object, containing data about the event, is passed as the first argument.
• use-capture (boolean)
  This declares whether the callback should be fired in the “capture” phase. (Don’t worry: We’ll explain what that means a little later.)

var element = document.getElementById('element');

function callback() {
  alert('Hello');
}

// Add listener
element.addEventListener('click', callback);

Demo: addEventListener

Removing Listeners

Removing event listeners once they are no longer needed is a best practice (especially in long-running Web applications). To do this, use theelement.removeEventListener() method:

element.removeEventListener(<event-name>, <callback>, <use-capture>);

But removeEventListener has one catch: You must have a reference to the callback function that was originally bound. Simply callingelement.removeEventListener('click'); will not work.

Essentially, if we have any interest in removing event listeners (which we should in “long-lived” applications), then we need to keep a handle on our callbacks. This means we cannot use anonymous functions.

var element = document.getElementById('element');

function callback() {
  alert('Hello once');
  element.removeEventListener('click', callback);
}

// Add listener
element.addEventListener('click', callback);

Demo: removeEventListener

Maintaining Callback Context

An easy gotcha is callbacks being called with the incorrect context. Let’s explain with an example.

var element = document.getElementById('element');

var user = {
 firstname: 'Wilson',
 greeting: function(){
   alert('My name is ' + this.firstname);
 }
};

// Attach user.greeting as a callback
element.addEventListener('click', user.greeting);

// alert => 'My name is undefined'

Demo: Incorrect callback context

USING ANONYMOUS FUNCTIONS

We expected the callback to correctly alert us with My name is Wilson. In fact, it alerts us with My name is undefined. In order for this.firstName to returnWilson, user.greeting must be called within the context (i.e. whatever is left of the dot when called) of user.

When we pass the greeting function to the addEventListener method, we are only passing a reference to the function; the context of user is not passed with it. Internally, the callback is called in the context of element, which means thatthis refers to element, not to user. Therefore, this.firstname is undefined.

There are two ways to prevent this context mismatch. First, we can calluser.greeting() with the correct context inside an anonymous function.

element.addEventListener('click', function() {
  user.greeting();
  // alert => 'My name is Wilson'
});

Demo: Anonymous functions

FUNCTION.PROTOTYPE.BIND

The last method isn’t so good because now we don’t have a handle on the function when we want to remove it with .removeEventListener(). Plus, it’s pretty ugly. I prefer to use the .bind() method (built into all functions, as of ECMAScript 5) to generate a new function (bound) that will always run in the given context. We then pass that function as the callback to.addEventListener().

// Overwrite the original function with
// one bound to the context of 'user'
user.greeting = user.greeting.bind(user);

// Attach the bound user.greeting as a callback
button.addEventListener('click', user.greeting);

We also have a reference to the callback at hand, which we can use to unbind the listener if need be.

button.removeEventListener('click', user.greeting);

Demo: Function.prototype.bind

• Check the support page for Function.prototype.bind and polyfill if you need it.

The Event Object

The event object is created when the event first happens; it travels with the event on its journey through the DOM. The function that we assign as a callback to an event listener is passed the event object as its first argument. We can use this object to access a wealth of information about the event that has occurred:

• type (string)
  This is the name of the event.
• target (node)
  This is the DOM node where the event originated.
• currentTarget (node)
  This is the DOM node that the event callback is currently firing on.
• bubbles (boolean)
  This indicates whether this is a “bubbling” event (which we’ll explain later).
• preventDefault (function)
  This prevents any default behaviour from occurring that the user agent (i.e. browser) might carry out in relation to the event (for example, preventing a click event on an <a> element from loading a new page).
• stopPropagation (function)
  This prevents any callbacks from being fired on any nodes further along the event chain, but it does not prevent any additional callbacks of the same event name from being fired on the current node. (We’ll talk about that later.)
• stopImmediatePropagation (function)
  This prevents any callbacks from being fired on any nodes further along the event chain, including any additional callbacks of the same event name on the current node.
• cancelable (boolean)
  This indicates whether the default behaviour of this event can be prevented by calling the event.preventDefault method.
• defaultPrevented (boolean)
  This states whether the preventDefault method has been called on the event object.
• isTrusted (boolean)
  An event is said to be “trusted” when it originates from the device itself, not synthesized from within JavaScript.
• eventPhase (number)
  This number represents the phase that the event is currently in: none (0), capture (1), target (2) or bubbling (3). We’ll go over event phasesnext.
• timestamp (number)
  This is the date on which the event occurred.

Many other properties can be found on the event object, but they are specific to the type of event in question. For example, mouse events will includeclientX and clientY properties on the event object to indicate the location of the pointer in the viewport.

It’s best to use your favorite browser’s debugger or a console.log to look more closely at the event object and its properties.

Event Phases

When a DOM event fires in your app, it doesn’t just fire once where the event originated; it embarks on a journey of three phases. In short, the event flows from the document’s root to the target (i.e. capture phase), then fires on the event target (target phase), then flows back to the document’s root (bubbling phase).

(Image source: W3C)

Demo: Slow motion event path

CAPTURE PHASE

The first phase is the capture phase. The event starts its journey at the root of the document, working its way down through each layer of the DOM, firing on each node until it reaches the event target. The job of the capture phase is to build the propagation path, which the event will travel back through in the bubbling phase.

As mentioned, you can listen to events in the capture phase by setting the third argument of addEventListener to true. I have not found many use cases for capture phase listeners, but you could potentially prevent any clicks from firing in a certain element if the event is handled in the capture phase.

var form = document.querySelector('form');

form.addEventListener('click', function(event) {
  event.stopPropagation();
}, true); // Note: 'true'

If you’re unsure, listen for events in the bubbling phase by setting theuseCapture flag to false or undefined.

Video on the Web has improved quite a bit since that first jittery low-res commercial I watched on my Quadra 605 back in 7th grade. But for the most part, videos are still separate from the Web, cordoned off by iframes and Flash and bottled up in little windows in the center of the page. They’re a missed opportunity for Web designers everywhere.

But how do you integrate video into an app or a marketing page? What would it look like, and how do you implement it? In this article, you will find inspiration, how-tos and a few technical goodies to get you started with modern video on the Web.

When Video Leaves Its Cage

Video combined with animation is a powerful tool for innovative and compelling user experiences. Imagine interactive screencasts and tutorials in which DOM elements flow and move around the page in sync with the instructor. Why not combine video with animation to walk new users through your app? Or what about including videos of your product on your marketing page, instead of static JPEGs? Getting carried away is easy — video can become little more than sophisticated blink tags if you’re not careful. But there are plenty of beautiful, inspiring examples of video tightly integrated in a design.

Apple’s new marketing page for the Mac Pro is a stunning example of video reaching out from its cage into the surrounding content. The new Mac Pro is featured in the center of the page, and as you scroll, it swoops and spins and disassembles itself. Supporting copy fades in to describe what you are seeing.

A static screenshot of the new landing page doesn’t do the new Mac Pro justice. (larger view)

Another great example of interactive video is Adrian Holovaty’s Soundslice. Soundslice is filled with YouTube videos of music sliced and diced into tablature (or tabs), which is notation that guitar players use to learn music.

The musical bars at the bottom stay in sync with the video. (larger view)

When you watch a music video, the tabs are animated at the bottom in time with the music, so that you can play along with your guitar. You can even slow down the video or loop selections to practice difficult sections, and the tab animation will stay in sync.

How Do You Add Video To A Design?

If you venture into video and animation in your next project, you won’t have many resources to lean on for implementation. No canonical, easy-to-use, open-source library for syncing video with animation exists, so every implementation is a bit different. Should you use a JavaScript animation library or pure CSS keyframes and transitions? Should you host the videos yourself and take advantage of HTML5’s video tag events or use YouTube or Vimeo? And then how exactly do you tie animations to a video?

Together, we will explore answers to the above-mentioned questions and more as we build our own micro JavaScript framework. Charlie.js provides an easy-to-use API for building pages with synchronized video and CSS3 animation.

Charlie.js, named in honor of Charlie Chaplin. (Image source)

The best way to learn is by doing, so let’s dive in.

I’ve detailed some of the common errors that give responsive websites problems in search results in an article on Search Engine Land earlier this year, so it’s nice to be able to do a more in-depth SEO audit of a responsive website here on Smashing Magazine.

I know not everyone’s definition of SEO is the same, so for those of you who don’t know my work, it should be emphasized that fixing all of these issues with SEO will improve the user experience in general; and like most credible SEOs these days, I don’t believe in manipulating search engine algorithms for short term ranking benefits.

The website I’d like to audit today is the US version of Disney Junior. I’ve chosen this website for three reasons: it’s not run by a client or a partner; it exhibits a lot of the SEO issues of many responsive websites; and my two and four year olds are huge fans of the brand and often use my smartphone or our family iPad to visit it. Hopefully, Disney can use this free advice to make its website better for my kids and kids like them who search.

It’s worth noting that because Disney Junior is not a client or partner, there may be information about business requirements that I am not privy to. In these cases the recommendations might not be helpful to Disney Junior, but should at least be valuable as SEO best practices for responsive sites.

This audit of Disney’s beautiful but often frustrating website shows that mobile SEO doesn’t end once you’ve made a website responsive, and it gives Disney a framework to make its website more usable and findable on search engines.

Is The Website Indexed?

Disney Junior doesn’t seem to have any real issues with indexing; many of its pages have been indexed by Google. See for yourself with a simplesite:domain.com search, or verify it in Google’s Webmaster Tools if you use it.

Google has indexed approximately 1,630 pages of Disney Junior. However, the descriptions indicate that we might have problems with content parity.

Obviously a website that isn’t in a search engine’s index will be invisiblewhen people search for it. This is true for responsive websites as well as for websites that use dynamic serving or dedicated mobile URLs. That being said, this tends to be more of a problem with mobile URLs because of the common practice of intentionally nofollow’ing mobile websites in the robots.txt file in order to prevent the mobile pages from competing with the “canonical” pages for link equity.

This practice is misguided because bidirectional annotations (or switchboard tags) can harness that link equity and bring mobile URLs into search results, but that’s neither here nor there when it comes to responsive websites.

While Disney Junior is indexed, some responsive websites, such as Idis are not so lucky. Idis is responsive and innovative, yet only one page of the website has been indexed by Google. Because the website is dynamic and because_escaped_fragment_ hasn’t been used, the URL does not change when a user clicks on different website elements, thus depriving search engines of deep links to include in their indices. If anyone searches for text on any of these pages, they won’t find this interactive, award-winning website.

This could happen to any website that doesn’t have static URLs, of course, but mobile SEO isn’t done once the developer has decided whether to make their website responsive or use dynamic serving or use dedicated mobile URLs.

Is The Website Crawlable?

In order for any website, responsive or not, to be indexed, Google must be able to crawl the website — that is, to follow a link to every unique piece of content and then store that new URL.

To check this, run any website crawler, such as Xenu or Screaming Frog. I prefer Rob Hammond’s SEO Crawler for mobile SEO audits because it allows you to set the smartphone Googlebot as your preferred crawler. The number of URLs is limited but enough to give you a pretty good idea of any crawlability issues. If you own the website, verifying it with Google and with Bing is imperative. Both search engines have tools for developers that specify the crawl errors they encounter, and Google even lets you tell it to ignore certain parameters that might be causing problems. If you don’t own the website or can’t verify it, you can still identify most problems by crawling the website as described above.

When I crawled Disney Junior, it quickly became apparent that the content is hosted on several URLs: DisneyJunior.com, DisneyJunior.Disney.com,WatchDisneyJunior.Go.com and Disney.Go.com/DisneyJunior. This could hinder a search engine from assigning page authority, because a search engine’s spider has a limited crawl budget for every website, based on that website’s PageRank, so if you’re splitting your PageRank between four URLs and three domains, then you’re possibly presenting to Google a website architecture that is less than optimal. More on this later in the section about duplicate content.

Disney’s URLs themselves don’t seem to have any major issues with crawlability because they are mainly static URLs, which search engines have an easier time with. However, the site map could certainly be improved upon. Search engines jointly announced Sitemaps a few years ago as the convention for finding content on websites to index. DisneyJunior.Disney.com does have a site map, but there are a few problems with it, the biggest being that it’s a video site map that contains more than just videos.

Site maps are a way for site owners to communicate directly with search engines, so making the information as accurate as possible and not confusing search engines are imperative. Google has site maps for the many different kinds of content included on Disney Junior, so presenting separate maps for images, videos, HTML documents and so on would be best.

Crawlability is not a mobile-specific problem, but getting it wrong can harm a website intended for mobile users just as easily as it can harm a traditional website, and it needs to be done right regardless.

RECOMMENDATION

• Disney should consider hosting all content on a single subdomain to ensure that search engines can properly identify page authority and to ensure that all relevant URLs are crawled efficiently.
• Disney should also consider breaking down its single video site map, which contains all types of content, into individual site maps for HTML content, image content, video content, etc.

Is The Website Readable Without Images, Flash Or JavaScript Enabled?

A search engine cannot factor what it can’t see into the overall relevance of a page. And while Google can do some amazing things with optical character recognition in Google Glass, Google Drive and Google Goggles, it still only reads text for Google Search. As it says in its “Webmaster Guidelines”:

• Create a useful, information-rich website, and write pages that clearly and accurately describe your content.
• Think about the words users would type to find your pages, and make sure that your website actually includes those words within it.
• Try to use text instead of images to display important names, content, or links. The Google crawler doesn’t recognize text contained in images. If you must use images for textual content, consider using the “ALT” attribute to include a few words of descriptive text.

Is Disney’s responsive website text-based and information-rich, and does it include terms that people would actually use when searching? Not really. If we look at the website through a simple text browser, like SEO-Browser.com, to get a better sense of how a search engine sees the website, then we get a much different picture than accessing it in a browser:

Unlike websites that embed keywords in images or in Flash, search engines aren’t blocked from seeing relevant content here — there’s just not a lot of relevant content to see. The website isn’t readable in this case because there are no words to read.

If we look at a deeper-level page, we’d see some graphic text that search engines would have a hard time accurately processing.

The text beginning with “Watch Sam Sandwich…” is accessible, but the words in the logo “The Bite-Sized Adventures of Sam Sandwich” are not because they are embedded as a graphic.

RECOMMENDATION

• At the very least, Disney should make embedded text accessible as alttext.
• When the text is substantial, the developer should consider making it accessible in a Web font, rather than as an embedded graphic.
• Furthermore, the volume of relevant keywords, such as “games for kids” and other non-brand words, should be increased. This could be done by slightly expanding the text block on each page or, ideally, by designing the page to include some scannable text, keeping progressive enhancement in mind.

Is The Website Easy To Link To And Share?

Many websites, both responsive and not, have URLs that don’t seem to be intended for human consumption. This is detrimental to SEO, of course, mostly because the URLs aren’t memorable and are difficult to share. Given how important search engines view sharing and linking when ranking pages, the more we can do to facilitate linking and sharing, the better off we’ll be in search results.

The print and video URLs for Disney Junior fall into this category, adding random characters to otherwise memorable paths (http://disneyjunior.com/print/stethoscope-4e4e43e2e8368d71cf2086da). For the most part, though, the URLs include keywords and are easy for users and search engines to understand.

The website could go one step further and include social bookmarklets toenable users to share content on social networks. Disney Junior has an active presence on Facebook, Twitter and YouTube, so its creators must understand the value of social media. But they might not understand that leveraging social media is becoming important to organic discovery and search. And given that 78% of Facebook’s user base is mobile and that mobile users spend more time on social networks than PC users, then helping mobile searchers share content whenever they’d like makes sense. Of course, the Children’s Online Privacy Protection Act (COPPA) prohibits this for sites intended for children, but Disney Junior for Grown-Ups is fair game.

This isn’t a tutorial on how to make social buttons work on a responsive website, but Facebook’s mobile “Like” button works on responsive websites. However, for performance considerations, it’s a good idea to use social sharing buttons or SocialCount that use lazy loading to load the actual social scripts on click. If you use a third-party plugin, such as AddThis, there are ways to make those compatible with a responsive website as well.

RECOMMENDATION

To increase referrals from social networks and to facilitate content discovery, Disney Junior for Grown-Ups should incorporate social-sharing buttons that are responsive, that add to the overall experience but that don’t significantly increase page-loading time.

Does The Website Display Content For Users’ Needs, Regardless Of The Device Used?

Those who champion “content parity” have a worthy cause in making websites accessible to everyone, regardless of device. Unfortunately, the issue is a little complicated. Making content available on all platforms is sometimes good for users, other times not.

Disney Junior is fairly representative. It deprives users of relevant content, fails to connect relevant content to users who need it, and gives users content that they have no chance in the world of ever using. Unfortunately, in my experience this is fairly typical of responsive websites, many of which don’t go far enough to make all content accessible, regardless of device, and which provide content that’s unusable on mobile devices.

Google sees one weakness so often on mobile websites that it has threatened to penalize for it in smartphone search results: unplayable videos. In June 2013,Google said this:

“We recommend using HTML5 standard tags to include videos and avoid content in formats, such as Flash, that are not supported by all mobile devices. Regardless, try your best to offer smartphone users the best experience possible to make sure that the videos are playable on as many devices as possible.”

So, when I encounter many screens like the following when trying to play Disney Junior videos, I get a little concerned:

Not supporting a piece of content for mobile users could lower your ranking in smartphone search results.

In some cases, though, Disney Junior goes too far with content parity. The four main sections of the website are games, videos, printables and a live feed. The problem is that unless a user is not only aware of Google Cloud Print but is one of the handful of people who has it installed on their device, they won’t have any way to print the coloring pages or other printables.

Brainstorming is often the method of choice for ideation, but it is fraught with problems that range from participants’ fear of evaluation to the serial nature of the process — only one idea at a time. Brainwriting is an easy alternative or a complement to face-to-face brainstorming, and it often yields more ideas in less time than traditional group brainstorming.

What Is Brainwriting?

When I teach my graduate course in “Prototyping and Interaction Design,” I start with a class on ways to generate ideas. Because brainstorming is a well-known and popular technique, I generally begin with a discussion on how to do good brainstorming, something that is very hard, and then introduce brainwriting as a worthy, and sometimes preferred, alternative to brainstorming. The term “brainwriting” often brings forth smiles and quiet laughter because it is a strange word.

Brainwriting is simple. Rather than ask participants to yell out ideas (a serial process), you ask them to write down their ideas about a particular question or problem on sheets of paper for a few minutes; then, you have each participant pass their ideas on to someone else, who reads the ideas and adds new ideas. After a few minutes, you ask the participants to pass their papers to others, and the process repeats. After 10 to 15 minutes, you collect the sheets and post them for immediate discussion.

In my experience, the number of ideas generated from brainwriting often exceeds what you’d expect from face-to-face brainstorming because you’ve reduced anxiety somewhat, followed a parallel process in which a dozen people may add items simultaneously, and reduced the amount of extraneous talk that happens during brainstorming, which takes time away from idea generation.

Instead of getting one idea at a time, lots of ideas can emerge simultaneously, if you let your participants “brainwrite” them. (Image credits: opensourceway)

When To Use Brainwriting

Brainwriting can be used in the following situations:

• You have too large a group for effective brainstorming. You could conduct brainwriting at a conference of 500 people simply by leaving a large card on each seat, asking a question, and then having each audience member pass a card to someone else, and then repeat three times for a minute of writing.
• You have quiet people in your group who are intimidated by traditional brainstorming.
• You are working in a culture in which brainstorming about “wild ideas” or expressing ideas that diverge from those of senior management is not accepted.
• Your time is limited. I’ve used brainwriting to brainstorm questions for a website visit when I had only 10 minutes to get feedback from the product team. I ended up with more than 50 different questions, without the fuss of having to set up a formal brainstorming session.
• You don’t have an experienced moderator. Brainstorming, contrary to what many blog posts claim, is difficult to do well. Brainwriting, in contrast, requires that you be able to ask a question, read a clock and collect answers.
• You are worried about loud or forceful individuals influencing others, as they might in traditional brainstorming.

Brainwriting can be used to understand how different groups view an issue. You might try to conduct separate brainwriting sessions with different internal groups. For example, if you asked groups to brainwrite about “What are the most important problems faced by our customers?” you might find that developers have a different perspective from the UX team, who have a different perspective from product managers. In my experience, the differences emerge more strongly through brainwriting than through face-to-face brainstorming.

Source: smashingmagazine.com

The motivation for the project came from my own speaking engagements in the tech industry. I wanted to see how many people in the audience actually agreed or disagreed with what I was saying. I also wanted to leverage their experience and knowledge to create a better learning environment.

Presentations today are mostly unidirectional, with a single presenter giving information to the audience. But it doesn’t have to be that way. Now, with the ubiquity of mobile devices, everyone in the room can contribute to the conversation and make it better. Many books have been written on the topic of collective wisdom. In The Wisdom of Crowds, James Surowiecki states:

“… a diverse collection of independently deciding individuals is likely to make certain types of decisions and predictions better than individuals or even experts.”

For the past year, I have been putting this thesis to the test, enabling people to interact with and change the content that I deliver. It’s been a lot of fun and work, and now you get to see the result.

Ratings And Feedback

When we look at current systems of rating and feedback at conferences, most of them are reactive, meaning that participants rate the session after it’s over. This is why most people don’t even rate sessions, unless they are asked or forced to by the doorkeeper. Those who do rate sessions might not care to be accurate (giving all 5s or 4s and then hurrying to the coffee line). Other attendees might have enjoyed the majority of the talk, but then got upset by the last slide or by the way the speaker ended the talk.

If these people decided to rate the presentation, how many stars do you think they would give? Perhaps 3 or 4 stars because of their anger at the end, but who really knows? Without context, a low rating doesn’t tell the speaker which part of the talk an attendee didn’t like.

Real-time feedback gives context to a rating, making traditional feedback unnecessary. Conference organizers and speakers no longer have to rely solely on Twitter hash tags and reactive ratings to see how well things went. We can now visualize exactly how the audience felt at any millisecond of a presentation.

REAL-TIME RATINGS WITH ONSLYDE

Giving a presentation that allows for real-time feedback is like riding a bicycle down a really steep hill for the first time. You have no idea whether you will crash and burn or come out with an adrenaline-filled scream at the other end. And it’s just as much fun for the audience.

With Onslyde, you get an accurate measure from the audience while you’re speaking. If you see that a lot of people are disagreeing with what you’re saying, you can adapt: Ask audience members for their thoughts, or maybe move on to another topic. When you’re presenting, actually seeing how the audience collectively feels in real time and then responding accordingly is a very cool experience.

The worst thing a presenter can do is tell the audience something it already knows or say something totally wrong. The audience wants to be intrigued and entertained by you. But too many speakers seem to think this requires GIFs of cats. Well, I don’t want to spoil anyone’s fun but I’m an adult now, and I don’t go to thousand-dollar conferences to look at funny pictures of cats. I do want to be able to challenge you, engage with the content and tell you when you’re wrong.

So, let’s talk about how the audience indicates whether you’re right or wrong. Onslyde’s remote control gives audience members between two and four ways to interact, depending on the type of session. It works for both normal presentations and panel discussions.

For presentations:

• Any slide can be agreed or disagreed with.
• Presenters can poll the audience by asking a question and giving two answers to choose from.
• Remote devices are updated with content for each slide.