Testing themes

Now and again, I hit the swimming pool. It’s a good way to exercise, but also to relax after a long day in front of my PC. I can do quite a few laps in my front crawl, but only because I don’t use my legs much. I kick steadily to ensure that my legs stay lifted and don’t slow me down. I don’t use my legs much for forward propulsion. An instructor once explained to me that legs can definitely help with propulsion in the front crawl, but only at the cost of much higher energy consumption.

He also explained that champions use their legs a lot. Their hearts are powerful, and they can happily sacrifice the extra effort for the small yet significant gain in speed. People with modest competitive ambitions are typically better off with moderate leg usage.

Does this relate to mobile Web development, responsive Web design and server-side device detection?

The analogy is a stretch, but yes, it does. As the inventor of WURFL, I used to live in a world where mobile devices were so limited in capabilities that there was no way a commercial website and its corresponding mobile website could be supported through a unique set of HTML pages without the support of some server-side logic. Strategies to detect and tweak content for mobile devices varied from simple detection scripts to the adoption of full-fledged device description repositories (DDR) such as WURFL.

Today, things have, to a large extent, changed. Many still have a feature phone, but the majority of users who care about accessing the Internet from their mobile devices will have a smartphone. A 2013 smartphone means the following: a fast connection, a great WebKit-based browser, a 320-pixel wide (or wider) touchscreen and a great operating system that allows for the installation of apps.

This evolution has turned the mobile Internet into a swimming pool available to every webmaster. Programming strategies such as progressive enhancement (PE) and responsive Web design (RWD) enable everyone to make their full websites usable enough on smartphones from a single set of HTML pages — i.e. with no need for server-side device detection. This is awesome. Webmasters can now make their websites more mobile-friendly without introducing a significant amount of extra complexity. Yet, just like in my initial analogy, the saving is only achieved at the cost of sacrificing certain aspects of the mobile UX that “champions” would not be OK with sacrificing.

In a previous article by Ronan Cremin and me, “Server-Side Device Detection: History, Benefits and How-To,” we explored the different aspects of client-side approaches versus server-side approaches, and we concluded that server-side strategies still offer a lot to mobile Web developers. I won’t repeat it here; rather, I will go one step further and explain how the two worlds can happily coexist for everyone’s benefit.

Client-Side Vs. Server-Side: A False Dichotomy

Most IT people are familiar with the saying, “When all you have is a hammer, every problem looks like a nail.” This is perfectly applicable to mobile development, where, in my experience, developers with a JavaScript and CSS background tend to favor client-side solutions to the problem of device diversity, while developers with traditional system development skills find server-side approaches more natural.

Unsurprisingly, there are pros and cons to both approaches, and, more importantly, the two approaches are not mutually exclusive and can be made to work together. After all, for any organization that offers a website, the ultimate purpose is to create the greatest user experience possible for its users within the constraints of the project’s timeline and budget.

Best Of Both Worlds

When it comes to building a strategy for a website that is friendly to mobile users, there is a whole range of possibilities. At one extreme, a designer might adopt a purely responsive website because they cannot afford to maintain a server-side detection component (or simply because they do not find enough value in the extra complexity). At the other extreme are large companies whose websites (and mobile websites) address particular quirks of popular devices. This approach requires an investment and dedicated team so large that typically only major Internet companies (think Facebook, Yahoo and Google) would go for it.

Most other companies will find the optimum point somewhere between the two extremes by segmenting the world of connected users in ways that make the most sense in their markets. Such segmentation will need to rely on some form of server-side detection.

One way to put it is that one should adopt a “best of both worlds” hybrid approach. In this article, I will show an example of this.

Every software project is one-off. The Web is no exception. Nor is mobile Web development, where the super-rapid progress of mobile devices is constantly turning best practices into moving targets. For this article, I figured that nothing could make the point better than a real example with real code.

My example is a cross-browser and cross-device slideshow. I will show how server-side and client-side detection can be made to work together to deliver a great UX on a variety of clients.

Segmentation (Good Ol’ Divide And Conquer)

The slideshow will be made available to the following classes of HTTP clients:

• non-smartphones (or feature phones),
• smartphones,
• tablets and desktops.

I have always called these “segments,” and I have referred to the splitting up into segments as “segmentation.” The key point is that each segment will be provided with a fundamentally different UI structure. Such segmentation will be supported through server-side detection.

Within each segment, there will still be space for further optimization of the UX. Such optimizations will happen with RWD and device detection. Notably, this approach will be used to obtain pictures in different sizes and to address the bandwidth problem, particularly for mobile devices.

Let’s start by sketching the different UIs for the different classes of HTTP clients (i.e. segments).

Non-Smartphones

Non-smartphones are commonly referred to as feature phones in the industry. There is no standard definition of what a smartphone is, but a device that possesses the following features would likely be called a smartphone by most:

• touchscreen;
• a screen that is 240-pixels wide or wider;
• Android 2.2, iOS, Windows Phone 7.5 or higher, RIM OS 7 or higher, Symbian Belle or higher, Nokia N9 WebKit-based browser;
• not a tablet.

This is a totally arbitrary definition, but good enough for the purpose of this article.

Devices that do not support one or more of the above features will be considered feature phones.

Because no assumption can be made for non-smartphones, we will assume a small screen, no touchscreen and limited bandwidth (which entails the need to minimize the number of HTTP requests required to download all of the content).

Please note that the lack of a touchscreen might require users to click the “down” button multiple times to get to the icon they wish to select.

The following wireframe nicely illustrates what we are getting at:

Feature phones (i.e. non-smartphones) have relatively small screens (typically narrower than 240 pixels). The presence of a touchscreen should not be assumed for devices in this segment.

Smartphones

Smartphones have a large screen, and users don’t have to click their way through icons to get to the one they want. They simply touch it. Because of this, a UI such as the following is better suited to them:

Smartphones have large screens (240 pixels or wider). The presence of a touchscreen and of basic media queries for changes in orientation may be safely assumed.

Tablets and Desktops

In the case of tablet and desktop browsers, we can safely assume that a large screen is available. In this case, consolidating the two views (i.e. the navigation and the actual picture) into a single screen makes sense:

A screen 700 pixels wide (or wider) may be assumed.

Of course, I created a single segment for tablets and desktops for illustrative purposes, but a real project might segment differently, based on the business model of the organization and the traffic it sees from different classes of devices.

Before delving into the code to implement this, I should discuss a few aspects of mobile development.

Important Note About Mobile Bandwidth: Speed Isn’t Everything

US carriers (i.e. network operators) boast in their advertising about their increasingly faster 4G networks and the blazing download speeds that their customers can get. My experience (and the experience of others) is that those figures are sometimes truthful under good network conditions, as in the case of a large single download or of video streaming. In practice, things are a bit more complicated. The overhead of establishing an HTTP connection in mobile is high.

Many browsers and devices open only one or two concurrent connections with the server (partly because of what the HTTP specification says, and partly because of hardware limitations). Keep-alives cannot be assumed to always work as one would expect in mobile, because of strategies that the devices follow to save battery power.

The problem is at the lower levels and is rooted in the fact that mobile networks and TCP/IP were not built to play well together to begin with.

Techniques such as “domain sharding” (i.e. fooling the browser into believing it’s talking to different servers) help to increase the number of concurrent connections. However, if you want to increase the download speed (both real and perceived) of a website, limiting the overall number of HTTP connections is your best bet.

May Your Days Be Merry And Your URLs Unique

People share links on Twitter, Facebook, Google+ and a lot of other services these days. This is good, but it has also exposed a shortcoming with a popular approach to managing the mobile channel — i.e. creating a separate mobile website (with separate URLs to the mobile view of the content). In short, a user will share http://m.coolsite.com on Twitter, and users on desktops and tablets will be offered a sucky UI. Having http://www.coolsite.com serve both the Web and mobile experience would effectively solve the problem.

As my last article explains, there are ways to have a single URL “multi-serve” content for different media. Of course, this requires a bit more design and work from the service architect as compared to purely client-side approaches.

In the case of PE and RWD, the “uniqueness” of the URL comes free of charge. In the case of server-side detection, a strategy to multi-serve content from a unique URL needs to be designed into the system. We will see one way to achieve this in the code discussed further down.

Content = Content + Presentation? A Little (But Important) Aside

Ethan Marcotte, arguably the inventor of RWD, correctly identifies the URL issue in his book Responsive Web Design:

“I do think fragmenting our content across different “device-optimized” experiences is a losing proposition, or at least an unsustainable one.”

This sentence has been quoted endlessly, and it seems hard to disagree with. Yet, it contains an ambiguity that makes it very debatable, to say the least. What Ethan calls “content” has historically been referred to as “presentation” by most. In fact, I could easily argue that separation of content and presentation is the foundation of a plethora of Web programming frameworks, such as model-view-controller (MVC), but also Windows DNA in the late ’90s.

While I am aware that designers will argue that the difference between content and presentation is blurry (advertising is the best example of this), such a differentiation has been very helpful to Web programmers in multiple ways over the past 15 years. In general, professionals are much better off preserving this separation, rather than blurring the difference between the two.

Software architects should obviously not fragment the content managed by their system. At the same time, they should be ready to multi-serve the presentation of the same data to users of different media and different devices in the name of an optimal UX. I would go so far as to argue that PE and RWD are also about providing multiple presentations of the same content, inasmuch as the clever use of grids and media queries allows developers to confine the “multi-serving framework” to a single page.

End of the aside.

Getting back to URL uniqueness, it is obvious that, in the case of server-side detection, a URL strategy must be designed with extra use of resources. Of course, webmasters have managed similar issues all their careers. Internationalizing a website presents the same challenges: one could have content served in multiple languages from the same URL (or even JSP or PHP page) or simply provide sibling websites, one for each supported language. Support for the potential lack of JavaScript presents a similar issue, as does the fact that an international content provider may wish to offer different (i.e. more relevant) content to visitors from different geographic regions, even where the language is the same. Supporting this means extra effort and cost. Typically, after the cost versus benefit equation is solved, some companies will go for the benefit in spite of the cost.

After so many words, let us see how the following code implements everything we’ve illustrated above.

The Code

Everything that has been discussed so far is illustrated in practice with a self-contained example that I built (along with my friend Steve Kamerman, COO at ScientiaMobile) to reinforce the points in this article. Be aware that, for the sake of clarity, the example hardwires many of the resources that would normally be isolated in separate databases or configuration elements.

Here is a list of the main components in the code:

• a DDR;
• an MVC framework;
• a controller with the segmentation logic;
• a server-side image-resizing framework;
• the views — feature phone, smartphone and tablet/desktop, in our case.

Let’s discuss each of them.

Device Description Repository

A DDR is a software framework that enables an application to associate an HTTP request with the properties of the client (Web browser, mobile device, Internet-enabled wristwatch, etc.). In our example, I will be using ScientiaMobile’s DDR, WURFL Cloud, because it’s the easiest to install on all platforms and also comes with a free offering for those who want to play around with it.

Of course, any other DDR could be used in place of WURFL Cloud, including AGPL-licensed WURFL or other open-source frameworks based on user-agent string analysis through regular expressions.

For the purpose of this article, here is the core bit of code that explains how to use the DDR (in the index.php file):

:
require_once dirname(__FILE__).'/lib/WurflCloudClient/Client/Client.php';
  :

// Disable caching for testing
$cache_enabled = false;

$wurfl_config = new WurflCloud_Client_Config();
$wurfl_config->api_key = 'XXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYY';
  :
if ($cache_enabled) {
	$wurfl = new WurflCloud_Client_Client($wurfl_config);
} else {
	$wurfl = new WurflCloud_Client_Client($wurfl_config, new WurflCloud_Cache_Null());
	header("Cache-Control: no-cache, must-revalidate");
	header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");
}
$wurfl->detectDevice();

Note: The cache is disabled because this is handy for testing purposes. But you’ll want to enable it on a production website, or else every HTTP request from your users will be a request to the cloud.

Once this code has run, you will be able to look up device capabilities on your server, without any need to interact with the client through JavaScript or the like, as simply as this:

$wurfl->getDeviceCapability('is_tablet')

All of the magic of looking up the HTTP request and recovering a profile for the device is happening under the hood.

Model-View-Controller Framework

MVC is a popular programming pattern among Java developers that over the years has made inroads among programmers of other languages (including PHP). In short, the MVC framework analyzes an incoming HTTP request and “dispatches” the actual handling to a different PHP page that has been deemed to be more apt for the job. In our case, the framework will route the HTTP request to the PHP page that would implement the best UI for that “segment.”

For the record, the MVC framework we’re using in our example is homemade, but Steve explains that it was inspired by a micro-framework named Silex.

The framework itself is implemented in the lib/SimpleApp.php file:

require_once dirname(__FILE__).'/lib/SimpleApp.php'; 
  :
$app = new SimpleApp();

Once the MVC framework is included, dispatching an HTTP request to the right view (see below) is as simple as this:

$app->render('image/smartphone.php', $view_data);

The interesting part is that the URL will not be affected by this. Users will only see the index.php page that responded to the request. This effectively solves the problem of URL uniqueness that we discussed above.

Controller

The controller (the “C” in MVC) is in charge of segmentation (i.e. deciding the view to which a certain HTTP client should be directed based on its profile). Here is the core of the controller (in index.php):

if ($wurfl->getDeviceCapability('is_smartphone')) {
	$app->render('index/smartphone.php', $view_data);
} else if ($wurfl->getDeviceCapability('is_mobile') 
&& !$wurfl->getDeviceCapability('is_tablet')) {
	$app->render('index/featurephone.php', $view_data);
} else {
	$app->render('index/desktop.php', $view_data);
}

In light of what we have explained, this part should be rather self-explanatory: smartphone.php handles smartphones, featurephone.php handles feature phones, and everything else (including tablets) is handled by desktop.php. There are actually two sets of views, one that manages the discovery page (i.e. the thumbnails with pictures) and one that represents the single picture.

The is_smartphone capability is a so-called “virtual capability” — i.e. a computed property that relies on other capabilities and that represents ScientiaMobile’s understanding of what a smartphone is. A lot of people find this handy. Of course, nothing prevents a WURFL user from choosing the capabilities and rolling a particular segmentation that make the most sense for their business model.

Image Resizing (RESS)

RESS stands for “responsive images and server-side components,” making it the most screwed-up abbreviation I have ever seen in my life. Because it is now common, though, I will use it, too. The premise of RESS is fairly reasonable: RWD is cool, but sending 500 KB pictures to a mobile device is not a good idea for a variety of reasons. This is why even the most inveterate RWD promoters will concede that resizing pictures on the server in order to speed up downloading and rendering on mobile devices is still a good idea. Of course, CSS and JavaScript files are also resources that you’ll want to make as light as possible. These also fall under the RESS umbrella.

Users of WURFL Cloud also have access to a service called Image Resizer. In short, Image Resizer enables you to create a URL that piggybacks the following bits onto itself:

• the URL of the original picture,
• a combination of parameters that specify how the picture should be resized and manipulated.

Requesting the URL will result in a picture with the desired features being obtained. For the record, other services of this kind are around, such as Sencha.io Src and the up-and-coming WhateverWeb, which promises to go beyond simple image resizing. Call me a romantic, but I prefer that we eat our own dog food for this example.

A photographer also graciously gave me some pictures of Chicago for this article, which I’ve hosted at http://cto.scientiamobile.com/chicago/ (i.e. in a place where Image Resizer can pick them up):

Let’s see how Image Resizer is used in practice (see views/index/smartphone.php):

// Compute the size of the image thumbnails
$thumb_width = 95;
$thumb_height = 95;
$rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/
                  h_$thumb_height/m_cropbox/";
  :
<div style="width: 100%; float: left; margin: 5px;">
  <?php foreach ($images as $id => $image) { ?>
   <div style="float: left; margin: 5px;">
      <a href="<?php echo $app->getUriPrefix().'/image/'.$id; ?>">
        :
       <img alt="" src="<?php echo $rszr_tumbnail.$image['src']; ?>" />
      </a>
    </div>
  <?php } ?>
</div>

This will generate markup like the following snippet:

<div style="float: left; margin: 5px;"><a href="/smash/image/1"><img alt="" src="http://rszr1.wurflcloud.com/234341/w_95/ h_95/m_cropbox/http://cto.scientiamobile.com/chicago/chicago2.jpg" /></a></div>

In reality, I’ve cheated a bit. I cut some interesting bits from the code above. In particular, I’ve removed a trick to use a really important technique called the data URI scheme, which enables developers to nest pictures in the HTML itself in the form of ASCII Base64 garbage. As you can imagine, not all devices support the feature (although smartphones usually do). This is where WURFL’s image_inlining capability, along with the ability of the image resizer to provide the picture already in Base64 format, comes in handy. The image_inlining will tell you whether the data URI scheme is supported:

$image_inlining = $wurfl->getDeviceCapability('image_inlining');
if ($image_inlining) {
	$rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/
                         h_$thumb_height/m_cropbox/in_true/"; } else {
	$rszr_tumbnail = "http://rszr1.wurflcloud.com/234341/w_$thumb_width/
                         h_$thumb_height/m_cropbox/";
}	
  :
<div style="width: 100%; float: left; margin: 5px;"<
<?php foreach ($images as $id => $image) { ?>
  <div style="float: left; margin: 5px;">
    <a href="<?php echo $app->getUriPrefix().'/image/'.$id; ?>">
    <?php if ($image_inlining) { ?>
      <img alt="" src="<?php echo file_get_contents($rszr_tumbnail.$image['src']); ?>"/> 
    <?php } else { ?>
      <img alt="" src="<?php echo $rszr_tumbnail.$image['src'];?>"/> 
    <?php } ?> 
  </a></div>
<?php } ?>
</div>

In the case of a device that supports image inlining, the code above will produce the following:

<div style="float: left; margin: 5px;">
<a href="/smash/image/1"> <img alt="" src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD//gA7Q1JFQVRPUjogZ2QtanBlZ..
  :
AUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlN
   : 
cH14z9RXHTc6jb6dWdM3GmrdT//Z" /> </a>
</div>

As we discussed earlier, this is particularly crucial because of the importance of minimizing the number of HTTP requests demanded by a mobile device to download a page, an aspect that is simply not worth optimizing in classic Web programming: too much extra work for way too little gain.

Of course, the data URI scheme will greatly increase the perceived download speed on smartphones and non-smartphones alike.

The Views: Feature Phone, Smartphone and Desktop/Tablet

The three segments we initially defined map one to one with our three views (feature phone, smartphone and tablet/desktop), according to the MVC paradigm. Each view offers a user experience that is best suited to the respective class of devices and browsers.

It goes without saying that adopters of a DDR still retain control over the UX of a deployed application simply by configuring a device to access a given view (for example, by downgrading a misbehaving smartphone to the feature-phone view).

The feature-phone view is particularly interesting because you’ll want to serve XHTML Mobile Profile (XHTML MP) as a markup to those devices. Developers who approach mobile today might get away with ignoring XHTML MP, but for years XHTML MP has been the standard mobile Web markup. Still today, smartphones will immediately recognize a website created in XHTML MP as being a mobile website, even when no viewport meta tag is available. Be aware that XHTML MP is typically better served with a different MIME type than text/html.

Note: Covering XHTML MP is beyond the scope of this article. If you are curious about the world of mobile programming on feature phones, my document “Global Authoring Practices for the Mobile Web” enjoyed some popularity for some time. Most people find it very informative still today.

The following screenshots visualize what the different UIs mean in practice:

The view on feature phones.

The view on smartphones.

The view on tablets and desktop. Above: The page on an iPad.

Here is the same page on the Xbox 360 (IE 10).

Of course, this example is just a proof of concept. Nothing prevents a programmer from making the desktop view even more responsive than it already is, or from adopting something like the good PhotoSwipe to provide interactive slideshows on smartphones and tablets (but not on older phones, where they would be unlikely to work). Divide and conquer.

Conclusion

Purely client-side approaches such as RWD and PE can make Web pages accessible on smartphones. For companies and organizations, this means that supporting mobile devices could be cheaper now than it was a couple of years back. Yet, these savings come at the cost of sacrificing certain aspects of a full-fledged cross-channel Web offering.

Large organizations may still want to adopt server-side device detection in some form to deliver a great UX to everyone who accesses their websites. While RWD and PE strategies can (and should) be adopted by companies, a hybrid client- and server-side approach is the most likely to deliver a great service to desktop, tablet and mobile users alike.

We’ve discussed an instance of such a hybrid approach by showing how segmentation, server-side resized images and the data URI scheme are key components to a great user experience across devices and browsers.

Have a look at the demo app.

(al) (ea)

---

© Luca Passani for Smashing Magazine, 2013.

Typekit is the easiest way to use real fonts on the web. Add a line of code to your pages and choose from hundreds of web fonts. Simple, bulletproof, standards compliant, accessible, and totally legal. Learn more at http://typekit.com

The <picture> element is a new addition to HTML5 that’s being championed by the W3C’s Responsive Images Community Group (RICG). It is intended to provide a declarative, markup-based solution to enable responsive images without the need of JavaScript libraries or complicated server-side detection.

The <picture> element supports a number of different types of fallback content, but the current implementation of these fallbacks is problematic. In this article, we’ll explore how the fallbacks work, how they fail and what can be done about it.

The <picture> Element And Fallback Content

Like <video> and <audio>, <picture> uses <source> elements to provide a set of images that the browser can choose from. The <source> elements may optionally contain type and media attributes to let the browser know the file type and media type of the source, respectively. Given the information in the attributes, the browser should render the first <source> with a supported file type and matching media query. For example:

<picture>
    <source src="landscape.webp" type="image/webp" media="screen and (min-width: 20em) and (orientation: landscape)" />
    <source src="landscape.jpg" type="image/jpg" media="screen and (min-width: 20em) and (orientation: landscape)" />
    <source src="portrait.webp" type="image/webp" media="screen and (max-width: 20em) and (orientation: portrait)" />
    <source src="portrait.jpg" type="image/jpg" media="screen and (max-width: 20em) and (orientation: portrait)" />
</picture>

For situations in which a browser doesn’t know how to deal with <picture> (or <video> or <audio>) or cannot render any of the <source> elements, a developer can include fallback content. This fallback content is often either an image or descriptive text; if the fallback content is an <img>, then a further fallback is provided in the alt attribute (or longdesc), as normal.

<picture>
    <source type="image/webp" src="image.webp" />
    <source type="image/vnd.ms-photo" src="image.jxr" />
    <img src="fallback.jpg" alt="fancy pants">
</picture>

The <picture> element differs from <video> and <audio> in that it also allows srcset. The srcset attribute enables a developer to specify different images based on a device’s pixel density. When creating a responsive image using both <picture> and srcset, we might expect something like the following:

<picture>
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg 3x" type="image/jpeg" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" type="image/jpeg" />
    <img src="fallback.jpg" alt="fancy pants" />
</picture>

The idea behind a <picture> example like this is that exactly one image should be downloaded, according to the user’s context:

• Users with <picture> support and a viewport at least 40 ems wide should get the big image.
• Users with <picture> support and a viewport narrower than 40 ems should get the med image.
• Users without <picture> support should get the fallback image.

If the browser chooses to display the big or med source, it can choose an image at an appropriate resolution based on the srcset attribute:

• A browser on a low-resolution device (such as an iMac) should show the 1x image.
• A browser on a higher-resolution device (such as an iPhone with a Retina display) should show the 2x image.
• A browser on a next-generation device with even higher resolution should show the 3x image.

The benefit to the user is that only one image file is downloaded, regardless of feature support, viewport dimensions or screen density.

The <picture> element also has the ability to use non-image fallbacks, which should be great for accessibility: if no image can be displayed or if a user needs a description of an image, then a <p> or <span> or <table> or any other element may be included as a fallback. This allows for more robust and content-appropriate fallbacks than a simple alt attribute.

The Fallback Problem

Right now, the <picture> element is not supported in any shipped browsers. Developers who want to use <picture> can use Scott Jehl’s Picturefill polyfill. Also, Yoav Weiss has created a Chromium-based prototype reference implementation that has partial support for <picture>. This Chromium build not only shows that browser support for <picture> is technically possible, but also enables us to check functionality and behavior against our expectations.

When testing examples like the above in his Chromium build, Yoav spotted a problem: even though <picture> is supported, and even though one of the first two <source> elements was being loaded, the fallback <img> was also loaded. Two images were being downloaded, even though only one was being used.

This happens because browsers “look ahead” as HTML is being downloaded and immediately start downloading images. As Yoav explains:

“When the parser encounters an img tag it creates an HTMLImageElement node and adds its attributes to it. When the attributes are added, the node is not aware of its parents, and when an ‘src’ attribute is added, an image download is immediately triggered.”

This kind of “look ahead” parsing works great most of the time because the browser can start downloading images even before it has finished downloading all of the HTML. But in cases where an img element is a child of <picture> (or <video> or <audio>), the browser wouldn’t (currently) care about the parent element: it would just see an img and start downloading. The problem also occurs if we forget about the parent element and just consider an <img> that has both the src and srcset attributes: the parser would download the src image before choosing and downloading a resource from srcset.

<picture>
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg 3x" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" />
    <img src="fallback.jpg" alt="fancy pants" />
    <!-- fallback.jpg is *always* downloaded -->
</picture>

<img src="fallback.jpg" srcset="med.jpg 1x, med-2x.jpg 2x, med-3x.jpg 3x" alt="fancy pants" />
<!-- fallback.jpg is *always* downloaded -->

<video>
    <source src="video.mp4" type="video/mp4" />
    <source src="video.webm" type="video/webm" />
    <source src="video.ogv" type="video/ogg" />
    <img src="fallback.jpg" alt="fancy pants" />
    <!-- fallback.jpg is *always* downloaded -->
</video>

In all of these cases, we would have multiple images being downloaded instead of just the one being displayed. But who cares? Well, your users who are downloading extra content and wasting time and money would care, especially the ones with bandwidth caps and slow connections. And maybe you, too, if you’re paying for the bandwidth you serve.

A Potential Solution

This problem needs both short- and long-term solutions.

In the long term, we need to make sure that browser implementations of <picture> (and <video> and <audio>) can overcome this bug. For example, Robin Berjon has suggested that it might be possible to treat the contents of <picture> as inert, like the contents of <template>, and to use the Shadow DOM (see, for example, “HTML5’s New Template Tag: Standardizing Client-Side Templating”). Yoav has suggested using an attribute on <img> to indicate that the browser should wait to download the src.

While changing the way the parser works is technically possible, it would make the implementation more complicated. Changing the parser could also affect JavaScript code and libraries that assume a download has been triggered as soon as a src attribute is added to an <img>. These long-term changes would require cooperation from browser vendors, JavaScript library creators and developers.

In the short term, we need a working solution that avoids wasted bandwidth when experimenting with <picture> and srcset, and when using <video> and <audio> with <img> fallbacks. Because of the difficulty and time involved in updating specifications and browsers, a short-term solution would need to rely on existing tools and browser behaviors.

So, what is currently available to us that solves this in the short term? Our old friends <object> and <embed>, both of which can be used to display images. If you load an image using these tags, it will display properly in the appropriate fallback conditions, but it won’t otherwise be downloaded.

Different browsers behave differently according to whether we use <object>, <embed> or both. To find the best solution, I tested (using a slightly modified version of this gist) in:

• Android browser 528.5+/4.0/525.20.1 on Android 1.6 (using a virtualized Sony Xperia X10 on BrowserStack)
• Android browser 533.1/4.0/533.1 on Android 2.3.3 (using a virtualized Samsung Galaxy S II on BrowserStack)
• Android browser 534.30/4.0/534.30 on Android 4.2 (using a virtualized LG Nexus 4 on BrowserStack)
• Chrome 25.0.1364.160 on OS X 10.8.2
• Chromium 25.0.1336.0 (169465) (RICG Build) on OS X 10.8.2
• Firefox 19.0.2 on OS X 10.8.2
• Internet Explorer 6.0.3790.1830 on Windows XP (using BrowserStack)
• Internet Explorer 7.0.5730.13 on Windows XP (using BrowserStack)
• Internet Explorer 8.0.6001.19222 on Windows 7 (using BrowserStack)
• Internet Explorer 9.0.8112.16421 on Windows 7 (using BrowserStack)
• Internet Explorer 10.0.9200.16384 (desktop) on Windows 8 (using BrowserStack)
• Opera 12.14 build 1738 on OS X 10.8.2
• Opera Mobile 9.80/2.11.355/12.10 on Android 2.3.7 (using a virtualized Samsung Galaxy Tab 10.1 on Opera Mobile Emulator for Mac)
• Safari 6.0.2 (8536.26.17) on OS X 10.8.2
• Safari (Mobile) 536.26/6.0/10B144/8536.25 on iOS 6.1 (10B144) (using an iPhone 4)
• Safari (Mobile) 536.26/6.0/10B144/8536.25 on iOS 6.1 (10B141) (using an iPad 2)

I ran five tests:

1. <picture> falls back to <object>
2. <picture> falls back to <embed>
3. <picture> falls back to <object>, which falls back to <embed>
4. <picture> falls back to <object>, which falls back to <img>
5. <picture> falls back to <img>

I found the following support:

What the user sees

	Test 1	Test 2	Test 3	Test 4	Test 5
Android 1.6	fallback image	fallback image	fallback image	fallback image	fallback image
Android 2.3	fallback image	fallback image	fallback image	fallback image	fallback image
Android 4.2	fallback image	fallback image	fallback image	fallback image	fallback image
Chrome 25	fallback image	fallback image	fallback image	fallback image	fallback image
Chromium 25 (RICG)	picture/source image	picture/source image	picture/source image	picture/source image	picture/source image
Firefox 19	fallback image	fallback image	fallback image	fallback image	fallback image
IE 6	no image	no image	no image	no image	fallback image
IE 7	no image	no image	no image	no image	fallback image
IE 8	fallback image	no image	fallback image	fallback image	fallback image
IE 9	fallback image	fallback image (cropped and scrollable)	fallback image	fallback image	fallback image
IE 10	fallback image	fallback image (cropped and scrollable)	fallback image	fallback image	fallback image
Opera 12.1	fallback image	fallback image	fallback image	fallback image	fallback image
Opera Mobile 12.1	fallback image	fallback image	fallback image	fallback image	fallback image
Safari 6	fallback image	fallback image	fallback image	fallback image	fallback image
Safari iOS 6 (iPad)	fallback image	fallback image	fallback image	fallback image	fallback image
Safari iOS 6 (iPhone)	fallback image	fallback image	fallback image	fallback image	fallback image

HTTP requests

	Test 1	Test 2	Test 3	Test 4	Test 5
Android 1.6	1 GET	1 GET	1 GET	2 GETs	1 GET
Android 2.3	1 GET	1 GET	1 GET	2 GETs	1 GET
Android 4.2	1 GET	1 GET	1 GET	2 GETs	1 GET
Chrome 25	1 GET	1 GET	1 GET	2 GETs	1 GET
Chromium 25 (RICG)	1 GET	1 GET	1 GET	2 GETs	2 GETs
Firefox 19	1 GET	1 GET	2 GETs	2 GETs	1 GET
IE 6	1 GET	none	1 GET	1 GET	1 GET
IE 7	1 GET	none	1 GET	1 GET	1 GET
IE 8	1 GET	none	1 GET	1 GET	1 GET
IE 9	1 HEAD, 1 GET	1 GET	1 HEAD, 1 GET	1 HEAD, 2 GETs	1 GET
IE 10	1 HEAD, 1 GET	1 GET	1 HEAD, 1 GET	1 HEAD, 2 GETs	1 GET
Opera 12.1	1 GET	1 GET	1 GET	2 GETs	1 GET
Opera Mobile 12.1	1 GET	1 GET	1 GET	2 GETs	1 GET
Safari 6	1 GET	1 GET	1 GET	2 GETs	1 GET
Safari iOS 6 (iPad)	1 GET	1 GET	1 GET	2 GETs	1 GET
Safari iOS 6 (iPhone)	1 GET	1 GET	1 GET	2 GETs	1 GET

Image-aware context menu

	Test 1	Test 2	Test 3	Test 4	Test 5
Android 1.6	yes	yes	yes	yes	yes
Android 2.3	yes	yes	yes	yes	yes
Android 4.2	yes	yes	yes	yes	yes
Chrome 25	no	no	no	no	yes
Chromium 25 (RICG)	no	no	no	no	no
Firefox 19	yes	yes	yes	yes	yes
IE 6	no	no	no	no	yes
IE 7	no	no	no	no	yes
IE 8	yes	no	yes	yes	yes
IE 9	yes	yes	yes	yes	yes
IE 10	yes	yes	yes	yes	yes
Opera 12.1	yes	yes	yes	yes	yes
Opera Mobile 12.1	yes	no	yes	yes	yes
Safari 6	no	no	no	no	yes
Safari iOS 6 (iPad)	no	no	no	no	yes
Safari iOS 6 (iPhone)	no	no	no	no	yes

Making Sure The Content Is Accessible

Although the specifics of how to provide fallback content for <picture> are still being debated (see also this thread), I wanted to test how Apple’s VoiceOver performed with different elements. For these experiments, I checked whether VoiceOver read alt attributes in various places, as well as fallback <span> elements. Unfortunately, I wasn’t able to test using other screen readers or assistive technology, although I’d love to hear about your experiences.

Read by VoiceOver

	alt on picture	alt on source (picture → source)	alt on object (picture → object)	alt on embed (picture → embed)	alt on embed (picture → object → embed)
Chrome 25	no	no	yes	yes	no
Chromium 25 (RICG)	yes	no	no	no	no
Firefox 19	no	no	yes	yes	no
Opera 12.1	no	no	no	no	no
Safari 6	no	no	yes	yes	no
Safari iOS 6 (iPad)	no	no	yes	yes	no
Safari iOS 6 (iPhone)	no	no	yes	yes	no

Read by VoiceOver

	alt on img (picture → object → img)	alt on img (picture → img)	span (picture → span)	span (picture → object → span)
Chrome 25	no	yes	yes	no
Chromium 25 (RICG)	no	no	no	no
Firefox 19	no	yes	yes	no
Opera 12.1	no	no	yes	no
Safari 6	no	yes	yes	no
Safari iOS 6 (iPad)	no	yes	yes	no
Safari iOS 6 (iPhone)	no	yes	yes	no

Bulletproof Syntax

Based on these data, I’ve come up with the following “bulletproof” solution:

<picture alt="fancy pants">
    <!-- loaded by browsers that support picture and that support one of the sources -->
    <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg" type="image/jpeg" media="(min-width: 40em)" />
    <source srcset="med.jpg 1x, med-2x.jpg 2x, big-3x.jpg" type="image/jpeg" />

    <!-- loaded by IE 8+, non-IE browsers that don’t support picture, and browsers that support picture but cannot find an appropriate source -->
    <![if gte IE 8]>
    <object data="fallback.jpg" type="image/jpeg"></object>
    <span class="fake-alt">fancy pants</span>
    <![endif]>

    <!-- loaded by IE 6 and 7 -->
    <!--[if lt IE 8]>
    <img src="fallback.jpg" alt="fancy pants" />
    <![endif]-->
</picture>

.fake-alt {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}

Here we have a <picture> element, two sources to choose from for browsers that support <picture>, a fallback for most other browsers using <object> and a <span> (see note just below), and a separate <img> fallback for IE 7 and below. The empty alt prevents the actual image from being announced to screen readers, and the <span> is hidden using CSS (which is equivalent to HTML5 Boilerplate’s .visuallyhidden class) but still available to screen readers. The <embed> element is not needed.

(Note: The use of the <span> as a fake alt is necessary so that VoiceOver reads the text in Opera. Even though Opera has a relatively small footprint, and even though it’s in the process of being switched to WebKit, I still think it’s worth our consideration. However, if you don’t care about supporting that particular browser, you could get rid of the <span> and use an alt on the <object> instead (even though that isn’t strictly allowed by the specification). This is assuming that the <span> and alt have the same content. If you have a richer fallback element, such as a <table>, using both it and a non-empty alt attribute might be desirable.)

A similar solution should also work with <audio>, although <img> fallbacks for that element are, admittedly, rare. When dealing with <video>, the problem goes away if our fallback image is the same as our poster image. If these may be the same, then the “bulletproof” syntax for <video> would be this:

<video poster="fallback.jpg">
    <!-- loaded by browsers that support video and that support one of the sources -->
    <source src="video.mp4" type="video/mp4" />
    <source src="video.webm" type="video/webm" />
    <source src="video.ogv" type="video/ogg" />

    <!-- loaded by browsers that don't support video, and browsers that support video but cannot find an appropriate source -->
    <img src="fallback.jpg" alt="fancy pants" />
</video>

However, if your <video> needs a separate fallback and poster image, then you might want to consider using the same structure as the <picture> solution above.

Note that <video> and <audio> don’t have alt attributes, and even if you add them, they will be ignored by VoiceOver. For accessible video, you might want to look into the work being done with Web Video Text Tracks (WebVTT).

Unfortunately, extensive testing with <video> and <audio> elements is beyond the scope of this article, so let us know in the comments if you find anything interesting with these.

How Good (Or Bad) Is This Solution?

Let’s get the bad out of the way first, shall we? This solution is hacky. It’s obviously not workable as a real, long-term solution. It is crazy verbose; no one in their right mind wants to code all of this just to put an image on a page.

Also, semantically, we really should use an <img> element to display an image, not an <object>. That’s what <img> is for.

And there are some practical issues:

• Chrome and Safari won’t show proper context menus for the images, meaning that users won’t be able to open or save them easily.
• IE 9 and 10 send an extra HEAD request along with the GET request.
• Using a <span> as a fake alt is pretty sketchy, and although it worked for my tests in VoiceOver, it could potentially cause other accessibility problems.

All that being said, as a short-term solution, it’s not too bad. We get these benefits:

• A visible image in every browser is tested (<picture> and <source> when supported, and the fallback otherwise).
• Only one HTTP GET request in every browser is tested (and the extra HEAD request and response in IE are tiny).
• VoiceOver is supported (and is hopefully supported with other screen readers).

<!-- show screenshot of network pane here -->

The semantics of the solution, while not ideal, are not horrible either: the HTML5 specification states that an <object> “element can represent an external resource, which, depending on the type of the resource, will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin” (emphasis mine).

And although the <span> is not as nice as a real alt attribute, using a visually hidden element for accessibility is not uncommon. Consider, for example, “Skip to content” links that are visibly hidden but available to screen readers.

Next Steps

The best part about this solution, though, is that it highlights how bad the current situation is. This is a real problem, and it deserves a better solution than the monstrosity I’ve proposed.

We need discussion and participation from both developers and browser vendors on this. Getting support from browser makers is crucial; a specification can be written for any old thing, but it doesn’t become real until it is implemented in browsers. Support from developers is needed to make sure that the solution is good enough to get used in the real world. This consensus-based approach is what was used to add the <main> element to the specification recently; Steve Faulkner discusses this process a bit in his excellent interview with HTML5 Doctor.

If you’re interested in helping to solve this problem, please consider joining the discussion:

• Join the RICG, and participate in the #respimg IRC channel and the public-respimg mailing list.
• Check out the RICG on GitHub, and consider adding your voice to the discussion on this issue.
• Join the W3C public-html mailing list and the WHATWG mailing list to follow and contribute to discussions about the specifications.
• Help fix problems with current implementations by reviewing, patching, commenting on and filing bugs for WebKit, Mozilla and Internet Explorer.

The next step towards a long-term solution is to achieve consensus among developers and browser vendors on how this should work. Don’t get left out of the conversation.

Thanks to fellow RICG members Yoav Weiss, Marcos Cáceres and Mat Marquis for providing feedback on this article.

(al)

---

© David Newton for Smashing Magazine, 2013.

WordPress is built by volunteers. People from all over the world collaborate to create the core software, write the documentation, provide support, translate WordPress, organize events and generally keep the project running. Individuals work on WordPress in their free time, and companies ask their employees to get involved.

Part of WordPress’ success is that the community consists not only of developers, but of designers, user experience experts, support volunteers, writers, users, accessibility experts and enthusiasts. This diverse input strengthens the project. It also means you have more space to get involved. Whatever your skill set, the WordPress community has room for you.

A bunch of WordPress contributors.

In this article, we’ll talk about the different contributor groups and how you can take part. I spoke with the current team reps and project leads, who have offered advice on how to get started with their contributor groups. But first, why should you get involved with WordPress?

Why Get Involved?

I had a chat with Matt Mullenweg, one of the founding developers of WordPress, about contributing to the project. We started off talking about the mix of people who contribute to WordPress. There are contributors who are sponsored by businesses that use WordPress, such as Automattic, Dreamhost and 10up, and then there are passionate individuals who dedicate their own time to the project.

“People who use WordPress are passionate about open source, want to democratize publishing and like to learn. I would say that’s the number-one biggest characteristic, because contributing to open source, and particularly the WordPress project, is probably one of the best learning opportunities on the Internet.”

Matt chats about the future of WordPress at the WordPress Community Summit 2012. (Image: konsobe)

For Matt, this is the greatest benefit you will get from contributing. You get to be part of a large, supportive community that has an impact on the lives of millions and millions of people. Something you do in an afternoon can have an effect on people all over the world.

“You can’t knock on the door at Google and say, “Hey, do you mind if I help you out with your home page? I have some ideas for you.” But you could come to us and say, “Hey, I have some ideas for your dashboard, and here are some patches.””

A number of challenges face the WordPress project:

• Contributor balance
  Currently, the number of contributors is skewed towards people involved with code. Plenty of opportunities lie in other areas — support, documentation and marketing, for example — but not so many people are getting involved.
• Mobile
  Not enough people are getting involved with mobile. Most of the people involved with mobile are currently sponsored by Automattic. Because mobile is fast becoming the way that people interact with the Internet, this is a crucial group and currently has a dearth of contributors.

With that in mind, let’s look at the ways you can get involved with WordPress.

Core

Mark Jaquith is an independent developer and one of the lead developers of WordPress. These days, he is a jack of all trades in the project, working closely with younger and newer developers, helping to point them in the right direction. He was also the release lead for the 3.6 release cycle. The core team comprises all sorts of developers and designers — PHP and JavaScript developers and front-end developers and designers. These are the people who build the WordPress that you install on your server.

Being a lead WordPress developer makes Mark Jaquith happy. (Image: Michael Yoshitaka Erlewine)

I asked Mark how the the core contributor team works. He describes it as a set of concentric rings:

“You have the leads in the inner sanctum, and then you have the people with permanent commit access, and then you have the people to whom we give temporary commit access for release, and then there are the people whose patches are implicitly trusted and go in without too much inspection. It just keeps going out from there. Those are very fluid boundaries, so people flow between them.”

Challenges

As much as possible, the core team tries to work by consensus. Issues are discussed, publicly if possible, although anything contentious may be addressed in private discussion.

One of the biggest challenges facing WordPress is that not everyone is on the project full time. Even Automattic employees have other responsibilities within Automattic. This means that people can contribute varying amounts of time. If a lot of people see a dip in their free time, this can cause problems for the project. The core team tries to mitigate this by having more contributors and more people who can commit. However, a balance has to be struck because if there are too many committers, no one would know what’s going on.

Get Involved

You can start getting involved in a number of ways:

• Live chats
  Tap into the weekly live chats (Wednesdays 21:00 UTC, irc.freenode.net, #wordpress-dev). Before diving in, you should gauge at what point in the release cycle the project is at:
  • Early stages
    Planning the next release.
  • Middle stages
    Guiding the features and checking on progress.
  • Final stages
    Bug scrubs.
  • After a release
    Mostly an open forum, a good time to ask for advice on moving your ticket forward.
• Firehose
  You can subscribe to trac notifications and get notified of every comment in every ticket. It’s a lot of data to process, but you should get an idea of how the project works, various people’s roles, how much authority they have, and best practices.
• Ideas
  If you have an idea for a feature or anything else WordPress-related, a good place to start is to write a blog post about it. There is an ideas forum, but it’s not very well used. If you have a concrete idea, with a vision of how to implement it, a blog post may well get you more traction. It will give you space to flesh out the idea and provide an opportunity for other community members to comment on it.

Ready to get involved with WordPress core? Other than development skills, I asked Mark what skills someone should have:

“The number one skill you need for just about any job, but specifically working on open source, is communication skills. You need to have clarity, consistency, compassion, relatability, a little bit of a thick skin and a decent sense of humor.”

User Interface

In recent history, the UI group has been separate to core, but there has been discussion about merging it into the core group. UI handles WordPress’ user interface, user experience, and other elements related to quality, accessibility and graphic design.

The UI group talks UI in Georgia. (Image: konsobe)

Helen Hou-Sandi is the lead user interface developer at 10up, and is also involved in WordPress’ core with a focus on UI. She outlined six areas that the UI group currently focuses on:

• Graphic design
  This is only occasional work.
• UX design
  Including wireframes, storyboards and concepts.
• User testing
  Dave Martin from Automattic has been running a lot of user tests recently to help identify issues.
• Front-end development
  The HTML and particularly CSS to create the admin interface.
• Quality assurance
  While this is within the purview of the UI group, Helen noted that improvements could be made in this area.
• Accessibility
  This has its own group, but the UI group also tries to ensure that accessibility gets the attention it deserves.

The UI group has a number of different challenges. A particular problem for contributors can be that the CSS is huge. Jumping into them can be scary for some people.

I asked Helen what she gets out of contributing to WordPress:

“I love the community, and I think that the basic premise that WordPress is built on — democratizing publishing for everybody — is a really important one.… The premise that it’s making content management and creation easier and more accessible for more people was something that I loved, and altruism wins out.”

Get Involved

There are a number of ways to get involved:

• IRC
  Stop by the UI chat (Tuesdays at 19:00 UTC) or the chat room and introduce yourself, although doing it outside of meeting hours is usually best.
• Make blog
  Stop by the Make blog and introduce yourself. Offer to get involved with projects that are starting up.

Those are the two official places to get involved, but Helen said that she doesn’t mind someone reaching out on Twitter or even chatting about getting involved at WordCamps.

The UI group needs people with a lot of different skills, including CSS and PHP development. What the group really needs right now are JavaScript developers. Anyone who’s comfortable with things like Backbone.js or TinyMCE would be a huge asset.

UX designers are extremely valuable to the team because they are focused on the user’s perspective, rather than the designer’s perspective. Of particular value are people with a good sense of how an interface and workflow should work. As with all of the groups, being able to function as part of a team is important:

“Good communication skills are pretty important. They should be willing to chase something for a while, because things get lost all the time. We forget or we drop the ball, so somebody who’s willing to almost nag in a way and is confident enough to ask, “Hey, what’s going on with this?” is really good to have on board. To watch someone develop that kind of confidence is a really good thing to see.”

Mobile

The mobile group builds apps for six different platforms: iOS, Android, BlackBerry, Nokia, Windows, WebOS. It also helps to expand the API and XML-RPC layer, and it investigates new APIs and ways of tackling mobile. Its rep is Isaac Keyet, a mobile designer at Automattic. The mobile group isn’t currently involved in the move towards responsiveness in WordPress core, but Isaac would like to see the team becoming more involved in it in the future.

Isaac Keyet leads the WordPress mobile group. (Image Michael Yoshitaka Erlewine)

Given that mobile is growing exponentially, it’s crucial that more people volunteer for the WordPress mobile group. In addition to Isaac, only six developers are in the group. If you’re a mobile developer and you’d like to be involved in an open-source project, then WordPress is a great place to start.

Challenges

A number of technical issues affect development of the native apps. This is particularly true when dealing with XML-RPC or the API. Any plugin or theme can add to or modify the XML-RPC layer. This means that the app has to deal with malfunctions and improper responses in the XML-RPC layer and in the responses that are returned from the blog.

To deal with this, the team is using client-side clean-up libraries, which take the responses and clean them up. But the XML-RPC layer can fail in so many different ways that the libraries are not complete. This makes it a constant struggle to ensure that everything works in all possible instances.

Get Involved

As with the other groups, there are two ports of call for getting involved:

• Make WordPress Mobile
• The WordPress Mobile IRC Chat: 16:00 UTC on freenode, #wordpress-mobile

It’s no surprise that WordPress attracts PHP developers, and it’s not a place that mobile developers would instinctively think to look. The mobile apps are written in:

• Java: BlackBerry and Android
• Objective-C: iOS
• C#: Windows

Contributors with coding skills in any of these languages are extremely welcome. And there is a particular need for Windows Phone developers right now. This is the fastest-growing app at the moment; so, if you’re a C# developer, visit the weekly chat and see how you can help out.

Another skill that the group currently needs is graphic design. Isaac is the only person currently working on graphic design for the group. As he is overloaded with work, which means that designs can’t be escalated as quickly as the group would like.

If you really want to make a difference to the future of WordPress, the mobile group is a great place to start.

Polyglots

The polyglots team is responsible for translating WordPress and for wider global outreach. It is led by Zé Fontainhas, a Portuguese WordPress consultant who speaks countless languages and is very active in the global community.

Zé Fontainhas speaks all of the languages. (Image: Michael Yoshitaka Erlewine)

Zé identifies three major areas that the Polyglots team is responsible for:

• Translations
  The team translates WordPress core, as well as a number of plugins, such as BuddyPress and the import/export plugins.
• GlotPress
  GlotPress is the translation tool that makes collaborating on a translation of WordPress possible. It is open source, just like WordPress. Developers and designers are needed to test patches, suggest features and fix bugs.
• Community
  The global team will be a new branch of the polyglots team, focusing on increasing WordPress’ visibility worldwide and on connecting people from worldwide communities.

Challenges

Many of the challenges facing the polyglots team have to do with raising awareness and managing perceptions. Around 40% of all downloads of WordPress are not for the English language version, yet WordPress continues to be very US-centric.

“The proof of that is that we are talking about “international” as if it were an objective concept. It isn’t; it’s meaning really depends on where you’re looking from. So, when someone in the US says “international,” it means the world outside of the States, but when I say it, “rest of the world” includes the US. We need to first stop using that term. It means different things to different people.”

Other challenges include ensuring that developers prepare their code for translation. This means implementing proper practices for plugins, themes and even core code to be ready for translation.

Of course, things will always get lost in translation:

“The “Howdy” of the dashboard screen is untranslatable for mostly everybody in another language because the spirit gets lost. There’s no real translation for that.”

Get Involved

All you need to get involved is a WordPress.org user name. Then think about what you’d like to do:

• Translation
  Check whether a team is translating into your chosen language. Get in touch with them to see how you can help out. [find list of teams/contacts]
• GlotPress
  Head to GlotPress trac to see what tickets you feel you can help out with.
• Community
  Keep an eye out for the new global blog, which will be launching soon.

Essential skills for translating WordPress are pretty obvious: language skills and knowledge of how to translate. You have to understand context, and you have to understand English. With the community, you need to have an awareness of how communities work and how they can better interact with each other.

Support

Support forum volunteers are the backbone of WordPress. They patiently answer questions like “OMG my site is broken! Can you fix it?” in WordPress.org’s support forum. The team is currently led by Mika Epstein, the in-house WordPress expert at Dreamhost. Mika also reviews plugins for the plugin repository — she’s one busy lady!

For Mika Epstein, support never stops. (Image: konsobe)

Around 30 moderators are currently in the WordPress.org support forums. Only about 12 of the moderators are active, answering queries every day. About 200 people actively answer questions.

WordPress’ support volunteers focus on the following areas:

• WordPress.org support forums
  This is often the first port of call for people looking for WordPress support. Volunteers help people with things ranging from forming their request correctly to writing code. There’s room for volunteers at every level of the WordPress experience.
• IRC Chatroom
  Some people prefer to request support via the chatroom. If you want to instantly give feedback to people, you could start hanging out in the IRC chatroom on freenode at #wordpress.
• WordPress Stack Exchange
  Questions that used to show up on the wp-hackers mailing list have now found a home on WordPress Stack Exchange. If you’re keen to answer more advanced questions, you could dive in here.

Since the Community Summit, there has been discussion on how to create training courses on different aspects of WordPress. This now comes under the purview of the support group. The material will be available to anyone who wants to use it for teaching or training, but also anyone who wants to learn from it. Both online and offline training material will be created. These are intended to help people do more with WordPress and make it easier for them to contribute.

Challenges

The biggest challenge facing the support team is the signal-to-noise ratio. Many more people are asking questions than answering them. People get impatient and start bumping their threads or getting snarky. They expect fast responses, or they want a phone number to call. When people get irate, it’s easy for a supporter to get irate, too. After all, the volunteer is spending their own free time helping.

Another issue is that people think they don’t have enough knowledge to sufficiently answer questions. But, as Mika says:

“It’s hard to know everything. And that actually scares a lot of people off. They think, “Well, I don’t know everything, so I can’t answer anything.” No, no, no. Just answer the one thing. That would make us really happy.”

Get Involved

The first step is to create an account and dig around the support forums.

“It’s always scary when you’re trying to join a new community. You feel like you’re in high school all over again. You’re this itty bitty freshman, and everybody else is a great huge, hulking senior. They’re adults. They know what they’re doing. And you’re like, “There is no way I can ever be that cool.””

If you remember high school, four years go by, and all of a sudden you were the cool guy. You were the great person. Everybody looked up to you. You have to remember that you don’t start out being an expert. None of us did.

Just look around and see if there are discussions you could get involved in. If a discussion is more than a couple of months old, just leave it alone because the person who made the request has probably moved on.

If you want to do more than poke around the forums and you want to be really useful, go to the forums and click the “No Replies” link.

Be super-helpful by answering unanswered questions.

Some supporters just go to the last page of queries with no replies and work their way up.

Another way to be helpful is to flag posts as spam, or to alert a moderator when someone double-posts a lot. On the right side of the post, you’ll see a section called “Tags.” Just add the tag “ModLook” (all one word), and a moderator will know to look at it.

To get involved in the new training initiative, stop by the post “Training Group, Team Reps, and Growing the Team” in the support section.

Theme Review

The theme review team sets guidelines for the quality of themes hosted in WordPress’ Theme Directory. It reviews every submitted theme against those guidelines and, if it meets the standard, pushes it to the repository.

Chip Bennett talks about theme review. (Image: konsobe)

The representative of the theme review team is Chip Bennett, the developer behind the Oenology theme. I chatted with him recently about how the theme review process works:

1. A developer submits a theme on WordPress.org, using the “Theme Authors” link. The uploader runs the theme through a script, unpacks it and puts it through a bunch of tests. If it passes the tests, the theme is repacked and stored in a special subversion repository for themes. It then generates a ticket in the Theme Trac.
2. The ticket goes into a queue. The queue is prioritized based on whether the theme is currently approved, whether it has been reviewed before, and how long it has been in the queue.
3. A reviewer will take on the highest priority theme. They review the ticket, which includes a link to the ZIP file, or a link to a diff file if the theme has been previously submitted.
4. In reviewing the theme against the guidelines, the reviewer looks for the following things:
   • code quality,
   • theme files,
   • front-end tests,
   • theme unit test data.
5. If the theme passes the review criteria, then the ticket is closed and resolved as “Approved.”
6. If the theme doesn’t pass, the reviewer posts comments on the ticket, explaining the issues and what is required and perhaps making some recommendations.

The longest theme reviews take around two to three hours, the whole way through. If there are major issues, the review will be stopped early, and the reviewer will note the issues for the developer to address.

Currently, about 70 to 80 people can close tickets. Around 10 people have reviewed more than 50 or 100 tickets. This means that participation is wide but shallow. The goal is to not leave a ticket in the queue for longer than a few days. On average, 10 tickets are submitted per day.

Challenges

A major challenge for the theme review team is the sheer volume of submissions, making reviews take longer than they would like. There are also occasional challenges to the review guidelines, although that has lessened in the past two years.

“Hopefully people have seen the benefits that the improved theme review guidelines have brought to the directory and overall code themes, so we don’t get a whole lot of challenges on the theme review guidelines themselves.”

We constantly have to review them as WordPress changes. Each release cycle, we have to look at them, find out what needs to change and understand how the various changes to core will impact themes to make sure we incorporate those.

Get Involved

The first place to start is the Make WordPress Themes blog, which is becoming the hub of activity for the theme review team. You’ll find a link to the reviewers mailing list, where a lot of the communication happens.

If you’re just starting out, you won’t have trac privileges to close tickets, so you’ll need to request a ticket to be assigned to you. To do this, post a comment on the “Trac Ticket Request Queue” page with your trac user name, and then one of the admins will assign the next ticket to you. Once you’ve done a few, you’ll get review privileges and be able to do it on your own.

You may also want to get involved in discussions about guidelines:

“We always welcome more people to contribute by reviewing themes, submitting themes and taking part in the discussion. The more developers we have participating in discussion about the guidelines and the process, it can only make it better.”

Plugin Directory

The plugin directory team is a relatively small group that is responsible for WordPress’ Plugin Directory. Its current rep is Scott Rielly.

Scott Reilly helps to secure and monitor WordPress’ plugin directory. (Image: konsobe)

The team does the following:

• Processes all incoming plugin submissions. There could be more than 40 submissions in a day. Each plugin is reviewed for guideline violations and coding best practices. If there is a problem with the plugin and it isn’t malicious, the team works with the author to fix the issue.
• Deals with support requests sent to plugins@wordpress.org.
• Monitors and curates the plugin directory, including looking for guideline violations and security exploits.
• Monitors the security-exploit database and announcements for anything relating to plugins.

Challenges

The biggest challenge facing the team, says Scott, is not having enough time in the day.

“Given the volume of newly submitted plugins each day, the constant updates by plugin developers and the support emails, it’s a constant effort to stay on top of everything — particularly because we’ll all just volunteers to the team. But we’ve been working to remedy this with enhanced admin tools and, eventually, additional team members.”

Another challenge is that spammers always try to game the system. The plugin directory is a target for people who want to inject spam into the websites of WordPress users. “In many ways, it’s an arms race,” says Scott. “They keep trying new stuff, and we keep shutting them down once we become aware of it”

Get Involved

The first way to help out with the plugin directory is to check out plugins and evaluate code. If you find any guideline violations or malicious code, send an email plugins@wordpress.org. Include the name of the plugin and a link to its page, as well as a list of the issues. The team will get in touch with the plugin’s author and get the issues fixed.

The team isn’t currently set up to accept many new people in an official capacity, Scott says:

“Part of it is getting internal tools and documentation organized in order to facilitate a larger team, and part of it is that we need to be selective of candidates since full membership grants capabilities that require adequate vetting.”

But the team is on the lookout for new members. Recently, Pippin Williamson was brought on board. The team keeps an eye out for potential team members amongst WordPress contributors who have demonstrated their ability through “code, competence and trustworthiness.” If you want to be invited to join the plugin directory team, help out across the community, showing off your technical expertise. Anyone who wants to get involved with reviewing plugins will need a deep knowledge of WordPress, of PHP and its best practices and of the plugin guidelines. Security expertise and the ability to understand other developers’ code are also desired. “Not just to understand what it does and what it’s supposed to do, but also how it may be wayward or exploitable in its implementation.”

Documentation

Often, when people think about WordPress documentation, the first thing they think of is the Codex. While the Codex is the cornerstone of WordPress documentation, it’s one element of a wider drive towards improving documentation. I’m currently the acting rep for documentation, which means that I’m responsible for reporting back to the community on the week’s activities.

Me, telling people they should use fewer words. (Image: Michael Yoshitaka Erlewine)

As with getting involved in any aspect of WordPress, contributing to documentation will improve your WordPress skills, not to mention your technical writing skills. It’s also a great way to give back to the community. Currently, there are a few ways to get involved:

• Codex
  The Codex always needs updating to maintain it as a useful resource for users. There’s always a flurry of activity around a new WordPress release as the Codex is updated to reflect any changes. Anyone can edit the Codex; all you need is a WordPress.org account. Lorelle VanFossen has listed all of the tasks in the Codex that currently need completing.
• Handbooks
  The handbooks are a collection of guides that teach people how to contribute to WordPress. There will also be handbooks for theme development and plugin development. This project will be active over the coming year.

We are also discussing the possibility of conducting a review of the inline help tabs, and looking at other ways that we can generally be helpful with documentation.

Challenges

A major challenge for the documentation team is to keep everything updated. WordPress has a fast release cycle, so the docs team has to be quick to stay on top of updating the Codex. Another challenge is that the Codex itself is such a huge resource. Keeping abreast of what needs to be done can be hard. A lot of functions lack practical examples, which people would find very useful for learning.

Also, sometimes the problem is that people don’t realize they can edit the Codex — you can, and you definitely should!

Get Involved

The easiest way to help out with documentation is to go to the Codex and log in with your WordPress.org user name. Once you’re logged in, you’ll see an “Edit” link at the top of the right sidebar. Click that button and you’re editing the Codex!

Editing the Codex is easy — go try it!

Even fixing a typo improves the documentation. If you’re using the Codex and you see an issue, fix it. If you have had to go elsewhere to find a solution, add that solution to the Codex so that others will benefit from it.

You could also stop by the Make WordPress Documentation blog, where you can say hello and get involved with the docs team. There is currently a major push to get the handbooks together, but you’ll find other projects that you can get involved with on the blog. We also have a weekly chat with the support team. This takes place on Thursdays at 9:00 pm UTC in the freenode IRC channel #wordpress-sfd.

Events

WordCamps and meetups are events at which WordPress users can get together to share knowledge, learn and socialize. One of the current reps for the Events blog is Andrea Middleton. She works on the WordCamp program, reviewing applications and providing a point of contact for organizing teams. The events contributor group consists of people who have organized WordCamps and meetups.

Events organizers have to deal with a lot of people standing around, staring at stuff. (Image: konsobe)

Challenges

Organizing an event has many challenges — you’ve got to get good speakers who will engage the audience, find sponsors and a venue, sort out catering, arrange AV, manage a budget, organize a team of volunteers. You’ve got to get a lot of details right in order to organize a successful event. Once you’ve been through the baptism of fire, you’ll be an experienced event organizer, which is a great time to get involved with the events contributor group.

Get Involved

Having experience as an organizer of meetups or any volunteer-run event is a great asset if you want to get involved with the events group. Having good accounting and communication skills also helps. As Andrea says:

“I think anyone looking to get involved with an ongoing open-source project, from whatever area of contribution, should come bearing humility, tolerance, patience, respect and a healthy sense of humor. We’re a meritocracy, and we value civil discourse.”

If you want to organize a WordCamp but don’t have a local community, start with a meetup. These will get people out of their house and talking about WordPress. WordCamps are most successful in regions that have vibrant WordPress communities. WordCamps are great, but they are just once a year — meetups happen every month and, as Andrea points out, they “sometimes have a more persistent effect on people’s lives and how they interact with WordPress.”

To get involved with the events group, stop by the blog and say hi.

Accessibility

The accessibility group was created to support core developers with issues regarding accessibility. Its rep is currently Mel Pedley. I asked Mel about the motivation for creating the group:

“Because a11y [accessibility] isn’t a binary subject but one based on experience, best practice, judgement and balance, the core devs were being hit with conflicting opinions that just caused even more confusion. They needed one point of contact with regard to tackling a11y problems — hence, the group.”

The group comprises technical developers and assistive-technology users. The group looks at issues and figure out solutions, passing answers back to the core developers.

The team is in the process of expanding to cover themes and plugins, and one day it would like to cover everything that falls under WordPress.org.

Challenges

Mel identified three major challenges facing the accessibility group. First:

“Wrangling any group of a11y experts is always a challenge. Put four of them in a room and you’ll get five opinions. It’s also quite slow, in my experience, to create real change. Things tend to change very slowly. So, keeping momentum is a major issue. I hope that we can address this by throwing a wider net — publishing best practice support documents and getting involved in outlying a11y projects — like Joseph O’Connor’s “Cites” project, which involves teams in cities across the world each developing an accessible theme.”

Secondly, the teams needs to get users with a greater range of assistive technology involved. There are screen reader users, but Mel is keen to get VR, braille and switch users involved, as well as dyslexics, so that there is a pan-disability user group. Successful accessibility is all about getting the right mix of people.

The third challenge is to convince the large community that accessibility doesn’t mean boring design or ugly UIs. You can have beautiful, graphically rich and accessible designs. Mel has been involved in Accessites.org to prove this point, and she wants to showcase what was learned there on WordPress.

Get Involved

To get involved, start following the Make WordPress Accessibility/ blog. You can also get in touch with Mel. The group is happy to hear from anyone interested in promoting accessibility and making WordPress more accessible.

There are two distinct streams for getting involved:

• Users
  This includes anyone who uses assistive technologies to access the Web. The group would value your feedback on existing issues and solutions.
• Technical
  This is any WordPress developer. You can translate users’ needs into practical solutions.

And a note to any WordPress developers:

“If you want to develop more accessible themes or plugins but aren’t sure where to start or how to tackle a particular problem, we’re here to help.”

Community

The community builders group was set up after the WordPress Community Summit to focus on outreach, mentorship programs and contributor engagement. The group’s current reps are Jane Wells and Andrea Rennick. Some of the things that the community group will be tackling are mentorship programs, college outreach, diversity, school programs, WordPress.org improvements, and finding new contributors at events.

Andrea likes hugging people. (Image: Andrea Rennick)

I asked Andrea what the group will be doing:

“Mostly it involves finding new members in the community who want to contribute and directing them to where they need to go. It also means answering a lot of questions. This requires a broad understanding of how each of the current groups works and what each group entails.”

Challenges

I asked Andrea about what challenges she thinks the group will face:

“At the minute, there’s no one spot where people can go to with their questions about getting involved with WordPress. Also, there are issues around dissemination, which really needs to be improved. The new Make WordPress.org Updates blog is an example of attempts to improve communication. Reps will post weekly updates so that everyone stays informed of what’s going on across the groups.”

But those aren’t the only challenges:

“Other sticky spots I can see being a challenge are things that are present in any large group of passionate people; things can be misinterpreted, feelings are hurt, tempers flare, and sometimes someone is needed to help smooth things over.”

Get Involved

Because the group is currently being formed, there are plenty of opportunities to get involved. People of any skill level are needed — even if your limit is installing WordPress and navigating the admin area, you still have enough skill to help others. Stop by the Make WordPress Community blog, leave your name in the comments, and say how you would like to help out.

BuddyPress and bbPress

BuddyPress and bbPress are the younger siblings of WordPress. If you get excited about social networking, communities and forums, they could be the places to get your feet wet. BuddyPress is “social networking in a box.” You can use it to build a community around WordPress. bbPress is a forum plugin for WordPress.

The lead developer of BuddyPress and bbPress is John James Jacoby (aka JJJ or J-Trip). JJJ manages the overall direction of the project, gets more contributors involved and helps out with development. The role he focuses on the most is building an active contributor community so that everyone can make the most of their unique skills and abilities.

JJJ leads the BuddyPress and bbPress projects. (Image: Andrea Rennick)

BuddyPress and bbPress are like microcosms of WordPress itself, with contributors needed in many of the same areas, just on a smaller scale. There are a lot of ways to get involved with the plugins: refactoring code, helping in the support forums, developing new features and functionality, working on user experience and design, helping with the codices, and writing plugins.

Challenges

The biggest challenge facing bbPress has been maintaining momentum. There isn’t always a lot of focus on it, and other distractions come up for developers. This is frustrating for JJJ because people assume that the project is dead when it is still active.

The biggest challenge with BuddyPress is that the code has changed so much since it was launched. Its direction has changed, and the code has been adapted. This means that a bunch of code is hanging around that they want to get rid of but can’t because doing so would break everyone’s installation.

“I like the house to be presentable when I have visitors come over. And when I know the house is not very clean, even though people might not really see it, we feel like we can do a better job with it. That might just be me. But for the project as a whole, because we have so much code, our release cycles are not as quick as we’d like them to be. We always have to fix a bunch of things, or we linger in beta for too long, or we don’t get to beta fast enough.”

Get Involved

The easiest way to get involved is to help out in the BuddyPress and bbPress support forums.

“Having someone’s experience of the forums be a rewarding, fun thing is the easiest way to be helpful. If you think you know anything, you probably know more than somebody else, and sharing that knowledge goes a long way for someone who’s looking for help.”

Help is also needed on both of the codices. As JJJ points out, this often feels like a thankless job because writing and formatting take so much time. But it’s a really useful place to get involved, especially because so few people are doing it.

If you’re interested in getting involved with development, join #buddypress-dev on Wednesdays at 19:00 UTC, or #bbpress on Wednesdays at 21:00 UTC. Contributors are always hanging around outside those hours.

What’s In It For You?

I asked all of my interviewees about what contributors get out of being involved in WordPress. There were commonalities across all of their responses: the joy of being part of a community, the thrill of creating something used by millions of people across the world, the rate at which you learn, and the pleasure of being involved in democratizing publishing. While the responses were varied, Mark Jaquith’s response sums them all up:

“I consider it part of my continuing education. I mean, tech is such a fast-moving industry that if you stand back and, say, just focus on the planning board and aren’t involved in the process and the technologies and the new skills, you’ll be left behind in a few months. It’s just part of the upkeep for me — that’s number one.”

Number two is because I enjoy it. I enjoy making things. I enjoy working on software that’s used by tens of millions of people. It’s a fairly powerful and rewarding feeling. And the other thing is that it raises your status inside the community, which is helpful, because it’s a very tight-knit community, and a lot of your business links are going to come from the community. A lot of your potential partners on ventures and projects are going to come from within the community. And by contributing and staying close to that tight knit group, you keep those connections alive.

Tips For Getting Involved

Now that you’re excited about contributing to WordPress, and you’ve found a contributor group that fits, here are some tips:

• Before diving in, do a bit or research and see how the group operates and what’s currently on the agenda. This will help you figure out where you fit in and whether your ideas have been discussed before. Reading though the P2s will usually suffice.
• Stop by the P2 for the group you’re interested in and say “Hi.”
• If you’re not sure what to get involved with, stop by the #wordpress-contribute IRC chatroom on freenode. Some people should be around to help you get started.
• Read through the P2, mailing lists or trac. Check that your ideas haven’t been proposed before, and if they have, see what the reasons were for refusing them.
• Go to WordCamps and Meetups! My involvement in WordPress has increased massively since I started meeting people in person.
• Reach out to people on Twitter or, if they publicize their address, via email.

Some Final Advice

A few pieces of advice didn’t fit neatly anywhere else in this article but are too valuable to be discarded. First of all, Matt has some words on starting out with contributing to WordPress:

“Remember that everyone who’s involved at WordPress started where the people who are reading this article are today, including myself. It looks big and scary. The first time someone said to me “You should patch that and put a diff on SourceForge,” I was like, “I don’t know what half the words in that sentence mean.” I had to figure out patches, I had to figure out what a diff is, I has to figure out what SourceForge is. We all started there. You’ve just got to dive in.”

And Mika has some words on the value of every WordPress contributor.

“Don’t ever feel that just because you don’t know how to code like Nacin and Otto that you’re not just as valuable as they are. Because without us, too, WordPress would fall apart. A healthy community is healthy on all levels, and everybody does know that.”

Contributor Information

Make WordPress Blogs

Here are the discussion blogs where the different groups carry on discussion and post updates:

• Master List
• Updates
  regular updates from the reps of every team
• Core
• Support
• Plugins
• Themes
  including Theme Review
• UI
• Mobile
• Polyglots
• Documentation
• Community
• Changes to WordPress.org

Chat Schedule

WordPress has a number of rooms on the freenode IRC channel. This is where the weekly chats take place. Remember that the chats are for getting things done, not just for saying hi, but they are a great time to find out how things work. People also usually hang out in the chat rooms throughout the day, which tends to be a better time to introduce yourself. Don’t be upset if people don’t respond — there are time-zone differences to take into account, and many WordPress people leave IRC on throughout the day, even if they’re not at their computer.

If you’re confused, the Codex has some information on IRC

• Tuesday: UI
  19:00 UTC in #wordpress-ui
• Wednesday: Mobile
  16:00 UTC in #wordpress-mobile
• Wednesday: BuddyPress
  19:00 UTC in #buddypress-dev
• Wednesday: bbPress
  20:00 UTC in #bbpress
• Wednesday: Core
  21:00 UTC in #wordpress-dev
• Thursday: Support and docs
  21:00 UTC in #wordpress-sfd

If you want help getting started, don’t forget that you can stop by #wordpress-contribute, where people are on hand to help.

(al) (il)

---

© Siobhan McKeown for Smashing Magazine, 2013.

» W3C to Publish Encrypted Media Extensions Specification

The W3C announced today that it intends to publish the controversial Encrypted Media Extensions extension specification despite highly outspoken resistance, paving the way for native web DRM.