Professional WordPress: Design and Development, 3rd Edition (2015)

Chapter 12. Crafting a User Experience

WHAT’S IN THIS CHAPTER?

· Understanding the principles of the user experience

· Learning the benefits of usability and usability testing

· Recognizing how to optimize your site for search engines

· Improving the built-in WordPress search

The last few chapters have been about creating and presenting your great content to the user. In truth, those chapters are really about your own goals—how you want the site to look and function and what content you are presenting. But it is not all about you. What about the visitors to your site? This is where the user’s experience is a factor.

Up to this point, the focus has been on how to create a site and manage its content. Now the question is whether the site is going to attract and retain viewers (users) with the mechanics and decisions you have put in place. Because you are dealing with people and their unique perceptions, it is an entirely nondeterministic exercise. That is, beauty is in the eye of the beholder.

The user experience really involves more than what an actual person sitting at a browser in Middle America thinks. Indirectly, web spiders, search engines, and service consumers such as RSS readers are also your users. Your site needs to be designed and structured so that all classes of users benefit and have a great experience.

USER EXPERIENCE PRINCIPLES

User experience is a topic that is open to interpretation; everyone sees it a little differently. But some good guidelines are available. Some of these guidelines are common sense, or seem to be. They all strive to establish a balance between what is aesthetically pleasing but also practical. These are not hard-and-fast decrees that must be followed. Humans are fickle and these guidelines need to be flexible to meet their needs.

Here are some basic questions to ask:

· Does my site have a consistent look?

· Is the design helpful or hurtful?

· Is my content easy to find and access?

· Is my content well structured?

· Is my site reasonably quick to load?

This list itemizes the pillars of the user experience. How you choose to use them, or in what combination, is really what this chapter is about. The following sections delve into these topics for a little more clarity.

Consistent Navigation

This is almost a no-brainer these days; it is difficult to not have a consistent look and feel with WordPress themes. You want your visitors to be aware that they are consistently using your site, independently of the path taken to get there. That means having a coherent look and feel to your site—such as a masthead and dependable global navigation.

That does not mean that different sections cannot have their own flair, but it needs to be coherent. It will be very disorienting for a visitor to read some of your content on one page and then click through to the next page with a totally different look and feel to it. Visitors will think they have left your site and you will not get credit for the great content you have created.

Likewise, each page in your site should have a dependable global navigation. Dependable means that it does not change and does not move. Visitors should be able to explore your content without fear of getting lost. It may sound silly to a technologist like you, but the average user has a different relationship with technology. This global navigation is a safety line for your visitors to get back to where they came from.

Good global navigation also tells visitors where they are in the site. Specifically, setting an “active” item in the menu and making it clear that it is lit up, or somehow distinguished from the rest of the global navigation. This enables a visitor to glance at the navigation and immediately see where he is in your site with respect to the other sections or pages. The built-in menu system in WordPress does this automatically; you will automatically receive a current_menu_item or current_page_item class in your currently active menu items like so (this is the rendered HTML):

<a href="http://local.wordpress-trunk.dev/?page_id=2">Sample Page</a>

</li>

Alternatively, if you are manually creating navigation in the templates, using WordPress’s built-in is_page() function, you can achieve the same result (this is the PHP code in the template file):

<li class="benefits

<?php if(is_page('benefits')){ echo "current_menu_item";}?>">

Benefits

</a>

</li>

In both cases, some nice CSS on the current_menu_item class would differentiate this menu item from the rest. We are firm believers in the user feedback functions of the anchor element. First, mousing over the element should provide some sort of feedback beyond switching the cursor to a hand. Usually, this means a highlight or darkening of the font, background, or border. Second, the currently active navigation section should be similarly delineated, but different. These two tenets, when taken together, create a nice global navigation that visually presents a multitude of information on where the visitor is in relation to the rest of the site and where he can go to read more. The following is sample CSS from the Twenty Fourteen theme:

.primary-navigation li:hover > a,

.primary-navigation li.focus > a {

background-color: #24890d;

color: #fff;

}

.primary-navigation ul ul a:hover,

.primary-navigation ul ul li.focus > a {

background-color: #41a62a;

}

This works in Chrome, Safari, Firefox, and Internet Explorer. In Figure 12.1, you can see how this plays out in the web browser. If you browsed this site in real life, you would see that the global navigation across the top is in the same place on each and every page of this test website. You will also notice that this screenshot is of the Child Page of the Sample Page menu item, and that navigation item is visibly different from the other menu items to indicate that it is the active page, and also the active top-level navigation item.

images

Figure 12.1 Active navigation

Notice that it is referred to as global navigation. That does not mean that every page in your site has to be listed in the main menu. It can be, but it does not have to be. Sections can have a local navigation block once you are inside them, but the main sections should be accessible via the main menu. This is what makes navigation dependable. It reinforces what the visitor can expect on your site and the methods used to navigate it.

A consistent style and dependable navigation comfort your visitor and reinforce the validity of your content.

Visual Design Elements

Specifically, are the visual assets of your site helpful or distracting to the user? Does the theme reinforce the persona you are portraying with your content or detract from it? This is another one of those topics that are open to personal interpretation. Photos and colors trigger differing subjective responses from different people, but the overall impression of your site should match the general content.

For example, a business site should not have a bubble-gum pink theme if it wants to be taken seriously—unless, of course, the site is selling toys or bubble gum. At the other extreme, there has recently been a bit of backlash against the use of pink to denote sites or content addressing women’s health issues; overuse degrades its impact and importance if blindly applied. Visual design should reflect the brand and brand values you are trying to develop with your WordPress site.

Colors evoke different feelings. Blue instills trust, which is why it is so prevalent in business and financial logos. Orange suggests new technology and is often used in the telecom industry. Color and branding is a whole topic unto itself, but just consider that pink ponies may not be the way to market your bank, and skulls and crossbones may not be the way to market your children’s furniture site.

This topic is pretty difficult to gauge. It is a very emotional topic and often marketing takes over rather than common sense. For example, it is likely that many of you have worked for clients who were absolutely certain that each new addition to the index page will be the most important thing on the page. That meant that every design element was oversized and blinking, causing the whole page to become nausea inducing. Sort of along the same lines as laundry detergent: If every brand is ultra-new-super-improved, are they not really all the same again?

One design theory that that works well when working up a new mockup is to toil away at the composition. Build up layers of elements working toward the end goal. Once you are happy with what you think could be the final mockup, remove an element. Kick it back one rung and use that. This is a variation on the less-is-more approach.

Take, for example, the mockup being created in Adobe Photoshop in Figure 12.2. You will notice in the Layers palette on the right side that all the components that make up the mockup are broken into individual layer groups. During the development of this mockup, each graphic element was composed using this method, which means that you can easily move and change them without interfering with other layers. You will also notice that a couple of the layer groups are currently turned off: The little eyeball icon is not there next to them. When creating this mockup, both of the graphic elements in those layers were tried and deemed to be too much. Turning them off, kicking it back a notch, created a stronger layout.

images

Figure 12.2 Mockup being created in Photoshop

Making Content Easy to Find

With a successful site, you will reach a point where you have a substantial body of content. Often, the visitor to your site does not categorize or organize content mentally in exactly the same manner as you do. Therefore, there should be multiple paths to get to all of the content on your site. This increases the likelihood that visitors will be able to find what they are looking for. This is also an excellent reason for having categories, tags, and calendar-based archives templates, as discussed in Chapter 9. Having these templates addresses three popular ways in which people remember where something was. They also serve as a way to drive more content interaction and consumption, exposing your thoughts (as the creator) on content sorting.

WordPress assists in this strategy right out of the box. First and foremost, your site should have a dependable global navigation, as mentioned previously. WordPress encourages this with its native structure, but how you actually build and organize the navigation is up to you.

Second, WordPress does come with a built-in search functionality. Although it can be improved, as discussed later in this chapter, some search is better than no search. Tagging your content helps with search.

Third, WordPress offers many alternative views of the content. Either with special templates or by simply using the default index template file (see Chapter 9 for more information on template files), WordPress can offer up your content by date, category, title, or author, or through several other variations. Creative use of these templates and other custom loops offers another vector into your content. The catch here is that this method also serves duplicate content, which the search engines discourage, but that is covered later in this chapter.

Fourth, many plugins are available for related posts. Adding a related posts list to the bottom of a post is another method for providing a deeper dive into your content. This is particularly effective if you have already piqued the interest of your reader with one set of content. Offering similar content is a great idea, and it is a way to provide more information on the subject that can be useful to your visitor.

Site Load Times

Back when dial-up was the most prevalent means of connection, web developers were extremely conscientious about the weight of the page and how long it took to load. But as broadband access has increased, developers have become lax about load times when updating existing sites. CSS files have bloomed as new selectors and styles are added rather than merged with existing styles. AJAX and JavaScript libraries have been included, sometimes more than one JavaScript library, just to achieve neat-o gee-whiz effects. iFrames, web services, and other third-party components all add to the bloat of an HTML document. Multiple database queries to gather information slow down the page on the server side.

In addition, elaborate new designs require more CSS and images and other effects, which adds to the bandwidth inflation. This is a problem for both new greenfield development and with the maintenance of legacy designs.

Is the time to load still a factor to consider? It should be and with mobile access becoming more prevalent, it might even be more important. The fact that the access speeds are faster does not mean you should ignore optimizations in the code. However, never optimize too early in the process. Premature optimization slows down the development and deployment of your site. This is a delicate balance between getting things done and out the door and optimizing them so the launch is successful. Page load times should be a consideration when developing your site. A nicely optimized site loads much quicker than one that was put together by someone who does not understand the implications.

This can be a complex issue: Think about all the aspects that affect load times of your website. There are the obvious ones that you should be familiar with, including the quantity and sizes of images, the number of JavaScript libraries being used, and to what effect those JavaScript libraries are being used. Consider also your integrations with third-party sites, such as using a few too many Facebook badges with Status and Like updates, or multiple hotlinked images from image hosting sites. What happens when these remote locations are slow to respond, or worse, do not respond at all? Does your site’s response time suffer because of something outside your control? Think about the tree of performance dependencies that you create by referencing other sites. That does not mean that you should not use them at all, but that you should recognize how they can affect your own site’s performance.

Firebug continues to be an excellent tool for working through optimizations and network bandwidth on your site. Google Chrome’s Developer Tools is also a very popular choice. In addition, Yahoo! and Google each have add-ons for Firebug and Chrome Developer tools to help improve your page speed: YSlow (http://developer.yahoo.com/yslow/) and Page Speed (https://developers.google.com/speed/pagespeed/), respectively.

A caveat with YSlow and Page Speed is that they are provided by Internet power houses. These sites likely see more traffic in an hour than you see all year. The problems and speed issues that they need to address are not the same types of issues that you need to address. YSlow always recommends a Content Delivery Network (CDN). Sure, a CDN distributes your assets across a geographically diverse set of servers to increase reliability and reduce latency, but does your site really need this? Do you really need to incur the costs? It is a developer choice, but in short, just remember that your site is probably not on the same scale as Yahoo! or Google.

You need to pick and choose your battles in the area of site load times. Here is a quick checklist of things to consider, starting with the low-hanging fruit:

· Optimize your graphics and pick the right DPI, color depth, and format. Do not forget about higher DPI Apple and other mobile devices.

· Standardize your JavaScript library and use only one. Measure the benefits of packing and minifying your JavaScript and CSS. Those efforts may not improve page load times.

· Evaluate the number of external references made, whether hotlinking an image or including a Facebook badge with a status update. Consider using transients, as discussed in Chapter 11.

· Be sensitive to MySQL database performance on your hosting site. Because every page or post displayed involves database queries, make sure you’re not overtaxing the expected performance of your hosting option. Plugins that store content in the database give you flexibility, but also add to the database query burden when you’re generating page output. Again, transients may help you here.

· Caching your output may be a viable solution; that is covered more in Chapter 15. You will have to weigh the deployment options and come up with a solution to meet your site’s scale requirements and deployment obstacles.

Using JavaScript

One more tip when using JavaScript in your web design: You may be tempted at times to base your entire site navigation (or another design element) around a super-cool jQuery plugin. The JavaScript may be a really neat effect, but JavaScript should not be the core of your design. jQuery effects should be the sprinkles you put on top of the frosting on the cake. You need to have a solid foundation so that the site still functions and is aesthetically pleasing, even if the JavaScript sprinkles fail. You should build a site from the bottom up and only add the glitter to a functioning site. Realize that each new JavaScript library and gee-whiz effect you add to your site increases the load time for the end user. Consider if the effect really adds something to your site, or if you are just using it because it looks neat to you.

Furthermore, make sure that your site degrades gracefully if the JavaScript does not work. That is, make your cake still taste good even if a slice does not have any sprinkles on it. If your site relies on JavaScript for some functionality to work, and it is the only way for it to work, your site may not be accessible. You have to consider that some visitors will not have JavaScript enabled, or perhaps not even available to them, and your site should be able to elegantly downgrade to support them.

In every case, there is a level of effort or visual trade-off required to improve page load times, and you will have to measure the work input versus the user experience output improvement.

USABILITY AND USABILITY TESTING

Your client is probably not the end user. Furthermore, your clients do not know what their users really want. For that matter, those in the content creation side of things, be they developers or writers, do not know what the eventual users—the readers—really want, unless there is some sort of feedback mechanism, such as testing. Web design is one of those weird trades where everyone thinks they know what is best. Think back to the marketing person who wanted every element to be the most important element on the page, which in the end created a wash of blinking badges.

Your clients generally think they know what their users want because it is what they would want when visiting a site of this nature—that is, the site you are building. This works sometimes. But often, your clients have an intimate knowledge of the topic that their visitor does not have, making it impossible to be objective. For example, one of the authors did a project where 60 percent of the traffic to the site came directly from the client’s own employees. However, the nature of the business meant the client could only enroll 12 new customers a month and based on the business’s growth goals these low traffic 12 visitors for the year are the most important visitors to the site.

If you are serious about having a well-crafted user experience, test early and test often. You have to decide what you are going to test and this really depends on what the goals are for your site. For example, an e-commerce site generally wants to sell products.

NOTE The story at http://www.uie.com/articles/three_hund_million_button/ has been used as the poster child for usability testing for quite a while now; it is older but still appropriate. This story is an interesting anecdote about how changing one button made a $300 million difference during checkout: http://www.uie.com/articles/three_hund_million_button/.

How can you apply this type of thinking to testing your own site? A/B testing is a nice way to test what works in a real-world laboratory. With A/B testing, you have two different versions of an actionable web page. Your site will randomly display one version or the other to each visitor. The process involves some nice code trickery and provides an easy way to do usability testing with the general public so it does require that your site be live. Using the results of the test, you can see which version of your action item performs better. This is, in some ways, also how Google does usability testing—it modifies its services on-the-fly and sees what generates actual traffic. If you are going to try A/B testing on your WordPress site, there are several plugins that simplify this process. Some even work in conjunction with Google Analytics’s Content Experiments for tracking.

Some other options are to use your family and friends, or call for help on Twitter or other social networks. This is called crowdsourcing.

Any testing is better than no testing. Having a second set of eyes is just a good idea. You do not always have to accept the results and make the changes the users suggest, but you should at least consider them. Again, a fresh set of eyes and a new perspective from someone who is not intimate with the site, as you are, is a good idea.

If your budget does not have room for usability testing, use your family and friends and watch them interact with your site. Observing how they find information enables you to isolate places where your design can be improved, and listening to their comments enables you to see what is good and bad about the overall feel. Generally, your family and friends represent the average user’s computer skills and make a nice test audience.

Likewise, you can solicit help from strangers via social networks. However, the results you get back vary greatly. Generally, people will be polite and tell you one or two little things either positive or negative, but rarely will you get a cohesive user test back. It is just too time-intensive for the average Joe.

You may be able to get more focused results by enlisting your local WordPress User Group. These are likely fellow developers and they will have that sensibility in their feedback. Some groups are more heterogeneous with developers and users, especially on show-and-tell nights. This can be a good opportunity to solicit some feedback and testing.

If you do have a budget, many sites are available that provide you access to user testing agents. Generally with these services, you submit your application or site and provide some goals for the user to achieve. You can also select which level of computer literacy you are targeting. The service then contacts its agents, who are average users at home, and using special software, the user records a session while trying to accomplish your goals.

We have used one of these services to test a whole new front-end interface to one of our core web applications (not WordPress-related). The resulting videos allowed us to watch how the user interacted with the site and provided audio commentary from the users. Some comments were quite overt whereas others required us to interpret the emotions of grunts and “OKs.” In the end, the user testing showed us some places that required immediate improvement to make the actions more clear and reinforced some changes that were made based on more experienced internal focus groups.

The WordPress team has done some user testing with the Dashboard Screens in the last several releases. It seems that the administration dashboards were receiving complete overhauls every couple of versions. WordPress is, by virtue of being community-developed, a terrific example of crowdsourcing, in both development testing and usability. These user tests focused on what features WordPress users used the most and directly led to the development of the QuickPress and other features. This crowdsource testing has led to the very usable Administration Screens.

Along these same lines, a little user testing goes a long way in improving the layout and design of your site. It is usually overlooked because developers are smart people and often know best, but you are also very intimate with the site and the fresh perspective can make your site better if you listen to some of the advice.

STRUCTURING YOUR INFORMATION

How your site is organized is critical to your visitors and to search engine spiders. In general, WordPress does a good job of keeping your content organized. After all, that should be a core function of a content management system. However, you do have to put a little thought into the overall structure of your site.

One of the first things you want to ask clients who want to redesign their site, or develop a new one, is to create an outline of the pages or content for the new site. This forces the client to think about the structure and organization of the entire site from a 10,000-foot view. Including what type of content each outline item represents also helps in structuring the overall flow of the site. Using this outline, developers are able to stub out an information architecture of post categories, custom post types, pages, and parent pages that will align with the client’s outline and make creating the site a smoother operation. This also allows the client to see the layout of the site with dummy copy, such as lorem ipsum, early in the process to make any structural changes as needed.

Once upon a time, there was a golden rule for websites that no page in your site should be more than three mouse clicks deep. This was back in the days when dialup connections were the most prevalent form of Internet access. Although we are not fans of deep sites, we are not sure if this rule is still true today. It is not that the attention span of the visitor has increased at all; in fact, it has probably diminished. And certainly broadband is more widespread nowadays, but you also have to consider mobile access. It is not page load times that are affecting our opinion here.

The short answer is: Search has largely replaced top-down navigation. In our opinion, people do not go to a website’s index page and run through the global navigation to find the particular topic, article, or product they are looking for. Rather, they go to a search engine. The search engine provides a link to the exact page, or as close as it can get, regardless of how deep in the site it is.

So, although we still favor “everything in three clicks” as a design rule, it is only because it adheres to the K.I.S.S. methodology and makes your site easier to use. But do not think this is a hard-and-fast rule, as sites are far more complex and encompass more content than they did when this rule was in favor. Putting in effort to make your content easier to find through search engines, and then structuring the content itself with the “three clicks rule” will together improve the user experience.

This is also the ideal time to evaluate what the individual pages or sections are titled. Here is a sad truth of web design: No one actually reads your content. In a now classic 2006 study by Jakob Nielson (http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/), the researchers found that visitors scanned the content of a web page in a very fast F-shaped pattern, meaning their eyes scroll down the left-hand side and skim the headers searching for the content they are looking for. The year 2006 seems like a long time ago, and it is in the technology world, but this study has been continually cited since.

Again, this is not a blanket statement. Obviously, people do read the articles and content on websites or there would be no reason to have them. But, when you are still trying to attract visitors and get them to stick around on your site, what should you take away from this study?

Headers matter. Headers should be concise and descriptive. Your content should start with the most important and evocative information and then get more in-depth. They should also be properly formatted to use the different levels of HTML headers (more on this later). Headers should contain action words. They should be interesting and make visitors want to read your content, assuming that is your goal. Given that visitors are scanning your site, having actions and descriptions in your headers will allow the visitor to get the overall gist of your page, help them find what they are looking for, and possibly entice them to read the rest of the section.

For example, which of the following outline structures is more meaningful and interesting? This one:

· How to Use WordPress

· Overview

· The Technology

§ Software

§ Hardware

· How to Get Started

Or this one:

· Publishing Your Content on the Internet Using WordPress

· What Steps Are Involved?

· What Do I Need?

§ Installing the Applications

§ Configuring the Server

· Getting Started Publishing

As you can see, with the first outline, you grasp the general idea of the website. But the second outline is much more engaging and draws you in with actionable tasks. You can also see the structure of the site and how it flows.

Remember back in school when you had to write an outline with several levels of headings? This is the same endeavor. Your content should have structure and headings and supporting paragraphs. If a heading intrigues a visitor enough, he will read the supporting paragraphs. If not, he will scan on to the next header. Funny how school actually taught you things you can use in real life, isn’t it?

GETTING YOUR SITE FOUND

Search engine optimization (SEO) is how to get your site discovered by the search engines. One of the key ways to do this is to use the permalink structure in WordPress. These search engine–optimized permalinks are one of the key features that actually show up in the results pages of all the search engines. Making them meaningful and descriptive is a must.

Unfortunately, out of the box, the WordPress URL structure uses the query string post identifier format (http://example.com/?p=100). For compatibility reasons, this is the default because it works across the board on different platforms and servers.

Given the choice in a search engine results page between this:

http://example.com/?p=42

or this:

http://example.com/this-is-the-information-you-want

which would you choose? The choice is pretty obvious. With the second option, the visitor or potential visitor at least has an idea of what he is going to find at the site. This descriptive URL helps with search engines and click-throughs because the savvy web user knows to look in the status bar of his browser to see the target site. Therefore, we heartily recommend that one of the first things you should do when setting up a WordPress site is change the permalink structure, as shown in Figure 12.3. Of course, you have to be on a platform that will support them.

images

Figure 12.3 Setting the permalink structure in the Dashboard

Shorter URLs are generally better because they are easier to type, yet they need to maintain some inherent descriptive nature. Therefore, we recommend the Post name setting, which is the same as a custom permalink structure using /%postname%/. This will use the slug from your post or page and create the nice SEO-friendly URLs referenced in the preceding example.

In previous versions of WordPress, using this setting included a heavy duty parsing penalty during the search. That is, the database query really needed a number to get good performance. However, as of WordPress 3.3, the database query rules have been simplified and improved with the result being a performance boost during parsing.

Additionally, you have two optional fields on this Permalink Screen to rewrite the category and tag base URL elements. For example, when you visit a category page in your WordPress site, the URL usually looks something like http://example.com/category/cool-stuff/. You can replace the word “category” with whatever you key into these optional fields. You can just use a letter c for category and t for tag to make the URLs shorter, but some creative uses of these fields can lead to some interesting and meaningful URL structures.

NOTE Chris Shiflett has an interesting post on his PHP Security blog (http://shiflett.org/blog/2008/mar/urls-can-be-beautiful) that discusses how URLs can be beautiful. At the time, Chris worked for OmniTI, and the URLs for the new site involved action words that conveyed a very clear meaning: for example, http://omniti.com/is/hiring and http://omniti.com/helps/national-geographic.

Duplicate Content

When a search engine is spidering your site, if you have duplicate content, or more specifically, multiple paths to the same content, the search engine may divide up your ranking (and SEO equity) across these multiple pages, diluting your overall ranking for any specific content piece. This section addresses how to keep multiple paths to content from appearing as distinct content views.

WordPress practically encourages duplicate content. Your posts are shown on the front page and on the category page for each category the post is in. Each tag creates a tag page for that content; plus your posts are kept in the yearly and monthly archives. So, while this provides you multiple paths to get to your content, which was considered a good thing in a previous section, it also weighs you down with duplicate content issues. Duplicate content on your own site may or may not actually be a bad thing; the jury still seems to be out on it. For example, the Google crawler, which indexes your site, has built-in logic to try and determine the nature and cause of your duplicate content. The crawler knows how to handle different views of the same content, such as for print versions. It also does its best to reinforce the primary source of the content—for example in a WordPress site, the single.php view.

In addition, Google provides a Webmaster Tools site that can provide insight into how the Google crawler sees your website. Use the Google XML Sitemaps plugin from Arne Brachhold, available online at http://wordpress.org/plugins/google-sitemap-generator/. This creates an XML sitemap for Google to use when indexing your site, which helps the spiders find everything. But Webmaster Tools also has some other interesting tools and investigative features. For example, under Search Appearance HTML Improvements, you can see duplicate content that the spider saw, as shown in Figure 12.4.

images

Figure 12.4 Google Webmaster Tools

Further clicking into the duplicate content suggestion will indicate exactly which pages are causing you problems. In all fairness, Microsoft’s Bing.com has a similar set of tools that are just as nice.

Additionally, you should edit your robots.txt file. The robots.txt file provides some more guidance to the search engine spiders on what should not be indexed. By default, a spider will aggressively index whatever it can find. The robots.txt file tells the spider what it is explicitly not allowed to index. Again, you are relying on the spider to play by the rules, but here is a good start for your robots.txt file:

Sitemap: http://www.example.com/sitemap.xml

# global

User-agent: *

Disallow: /cgi-bin/

Disallow: /wp-admin/

Disallow: /wp-includes/

Disallow: /wp-content/plugins/

Disallow: /wp-content/cache/

Disallow: /wp-content/themes/

Disallow: /trackback/

Disallow: /comments/

Disallow: */trackback/

Disallow: */comments/

Disallow: wp-login.php

Disallow: wp-signup.php

If you include your sitemap, do not forget to change the URL in your robots.txt file to match your actual site. Pretty much, you are asking the crawlers to look at your actual content pages while ignoring all the other components of your WordPress site—which makes sense because you content is what people are searching for in the search engines.

Trackbacks and Pings

Google increases your page rank by counting links to your site through trackbacks. Trackbacks are a validation of your content by other sites. They started as a way for one site to inform its readers that they may be interested in this content from another site and also to let the other site know, “Hey, I talked about your content and here’s the link.” They can basically be thought of as comments about your content on a remote site.

By default, WordPress groups comments and trackbacks together, further validating that they are remote comments, but this can often look messy to your reader. A common practice is to separate out the trackbacks from the actual comments in the comment loop. The Twenty Twelve theme did this for you in the default templates using the twentytwelve_comment() function found in functions.php:

$GLOBALS['comment'] = $comment;

switch ( $comment->comment_type ) :

case 'pingback' :

case 'trackback' :

// Display trackbacks differently than normal comments.

<li <?php comment_class(); ?> id="comment-<?php comment_ID(); ?>">

<?php comment_author_link(); ?>

<?php edit_comment_link( __( '(Edit)', 'twentytwelve' ),

'<span class="edit-link">', '</span>' ); ?></p>

<?php

break;

default :

// Proceed with normal comments.

As the comments are walked, this function determines if it is a trackback or an actual comment and displays it accordingly. You can review the Twenty Twelve functions.php template file for more information and to view the remainder of the function. Automattic did not choose to separate comments and trackback into different formatting styles in the Twenty Thirteen or Twenty Fourteen themes.

You can also override this rendering function in a child theme to make the display logic your own. What this gets you is a clear separation between the active discussion on your site, for your visitors to participate in, and a list of related sites that have also mentioned your content. They can be divided logically and visually, making it easier to digest for the visitor.

Pings, on the other hand, notify other sites when new information is published. Generally, your WordPress site would ping an update service, such as Ping-o-Matic, that you have new content on your site. Likewise, if you are writing about content on another WordPress site, your site may ping that other site to let it know about your content. In this respect, pings are similar to trackbacks.

Pinging update services is a good way to drive traffic to your site. Some sites take the information from these update services and create information link sites about them. The theory is that casual surfers of these sites may discover your content related to a topic they are browsing. In this respect, pinging works very much like a push version of RSS or tweeting your new content.

Signing up to use an update service such as Ping-o-Matic is really simple to do. Simply browse to the site at http://pingomatic.com/, sign up your site, and it starts working. There is not much to it.

Similar to pings is a newer protocol called PubSubHubBub, which besides being glorious to say out loud, is another way to broadcast that your content has been updated. PubSubHubBub, or PuSH, works by pinging a central hub that your content has been updated and subscribers get notified. Google runs open hubs for anyone to use, or you can run your own hub, making this a decentralized protocol. There are several WordPress plugins that enable this functionality on your website.

In practice, the pinging and PuSH functionality are not used very much. Social media is the new word of mouth and news travels faster when shared via this route. Building a custom application that parses the RSS feeds of your WordPress sites and tweets new posts on Twitter and shares on Facebook as they are posted in near real time may be more effective broadcast marketing. In certain situations, this type of notification works better.

HOW WEB STANDARDS GET YOUR DATA DISCOVERED

HTML is text markup. That is literally what it means. When HTML was first developed, the intention was to take content and mark it up in a consistent and meaningful way. Many different HTML tags accomplish this. It was originally for scientific and academic use and the majority of content fit this nature.

Eventually, the marketers showed up and got their greasy hands involved. They wanted fancy layouts, graphics, sales pitches, and pretty pink ponies. To accomplish this, designers and developers, both good and bad, lost sight of the original markup and used whatever means necessary to create the best-looking site on the web. This included table-based layouts.

In recent years there has been a back-to-basics mentality among the better developers. This likely includes you, because you are reading this book. These developers recognize the power of separating concerns, such as presentation and content, CSS and HTML. They also recognize the advantages of using semantic HTML. The explosion of mobile access has further accelerated and emphasized this push.

Semantic HTML

POSH stands for plain old semantic HTML. This acronym expresses a back-to-basics mentality in the underlying HTML of websites. For all the glittery design and flair, developers can use CSS to make it happen. Look at CSS Zen Garden online athttp://www.csszengarden.com/ for an example.

Why should your site use POSH? There are a few reasons. First, it is the best thing for the future web. Paying it forward, if your site continues to use semantic HTML, browser manufacturers will continue to support it in their browsers.

Second, for the developer, it makes the content easier to validate and maintain. There is much less cruft in a properly semantic HTML document than in one that is coded old style. Consider this,

<div style="

background: #F0CCFA;

border: 1px solid # D894EB;

color: #f00;

font-size: 2em;

margin: .25em 0;

padding: .5em;">

This is my subheading

</div>

versus this:

<h2>This is my subheading</h2>

And that is not even really old style. This still uses CSS instead of the multiple nested <font> tags that really clutter up the old HTML documents. Valid, lean HTML is easier to maintain. It is that simple.

Speaking of lean, stripping all the cruft out of your HTML can really make your pages load faster. Think of all the extra markup that is moved out of each page load and into a browser-cached CSS file. This can be a significant weight loss for your pages.

The third reason to use POSH is accessibility. Structuring your HTML semantically increases the likelihood of screen readers figuring out your content and having it make sense to the visitor.

Finally, valid semantic HTML helps with search engine optimization. Search spiders are not very smart. They do not care how pretty the site looks or the cool new graphic treatment you created. They only care about the content. And they cannot think for themselves.

Semantic HTML conveys the meaning of the text you are marking up. That is why it is called semantic, after all. Using the proper HTML tag for the content is the first step. For example, six levels of headers are available to you in HTML. Using them in the correct order is essential for SEO. Similar to using a site outline to map out your site, this is also how the crawler knows the order of your content.

Even if you separate your CSS properly into a style sheet, the spider cannot determine the value of this HTML:

<div class="pagetitle">My Site Is About Something Important</div>

If you use the <h1> tag, however, the spider knows that this is the header for the entire page and attributes this content with the appropriate weight.

<h1 class="pagetitle">My Site Is About Something Important</h1>

Scrolling down through your content, you should use the appropriate levels of headers for additional content. The general consensus is that each page on your site should have only one <h1> tag to indicate the top level of each rendered page. Conventional wisdom is that this <h1> is reserved for the name of the site and then there can be multiple instances of the other heading levels as needed. The only flaw in this is that the name of your site does not really change, so it is not the <h1> that matters the most for each page. Using headers in this manner makes the <h1> really irrelevant; the <h2> would be the page title describing the rendered page’s content. It is easy to understand both sides of the argument; you will have to make your own decision.

Images should always have alt attributes. This informs the spider what the image is rendering because the spider cannot see the graphic itself. This information is also what screen readers use.

The <div> tag is for blocks of content and the <p> is for paragraphs. Use the more meaningful <em> and <strong> to emphasize and strongly emphasize your content. Also discussed later in this chapter are HTML5 tags for specific blocks of content, such as <header>,<footer>, and<article>.

Use proper lists to organize your data. Ordered lists (<ol>) and unordered lists (<ul>) are easy ways to convey information to the spider. A properly formatted list is semantically more information to rate than a paragraph filled with <br> tags. There is also the lesser-known definition list (<dl>) element, which is very effective in paired information lists, such as Frequently Asked Questions. This list and explanation of HTML attributes can go on and on.

In short, semantic HTML is all about using the proper HTML tag for its intended use. It is worth reading through the W3C specifications and learning the different tags and their purpose. Adding these additional tools to your bag of tricks will make you a better developer, but will also make your pages lighter, more meaningful, and more accessible, all of which are good things for your visitors and your search engine rankings.

Valid HTML

For you, the developer, valid HTML and valid CSS are just plain easier to maintain. It is a simple fact. If your code is structured correctly, you can get in and out and make the changes you want quicker. We still have some ancient table-based layouts lying around from clients that have never wanted to update the look of their site. If you have not had to work on one of these in a while, it is astonishing to remember how hard they were to work on. But at the time, this is what we had.

Valid HTML also helps in solving cross-browser rendering issues. All developers dread the day they have to test their great looking site in one of the older less standards-compliant browsers. You know which one. It is important that the developer has completely consumed the requisite amount of coffee and moved all sharp objects out of arm’s reach before opening this browser for testing. Inevitably, something will not be right. Having validated HTML is the first line of attack when dealing with this browser’s rendering challenges. Always start from clean code before taking measures to make it look reasonable in these browsers. And have hope, maybe, that someday this browser will not be around anymore. Fortunately, supporting the older browsers is becoming easier as users become more aware of the need to upgrade and try alternate browsers.

In addition, some new tricks in the theme HTML allow you to target specific browsers with conditional comments. Take a look at the source code of your rendered Twenty Fourteen theme. Notice the first few lines of the HTML include conditional comments to set the root <html> element to focus on specific browsers and set the root CSS class for further CSS and JavaScript hooks:

<!DOCTYPE html>

<!--[if IE 7]>

<![endif]-->

<!--[if IE 8]>

<![endif]-->

<head>

The Twenty Fourteen theme is only specifically going after Internet Explorer versions 7 and 8, but your theme could use additional conditional comments to target any number of specific browsers.

For SEO, it is back to a “spiders are not very smart” problem. Valid HTML makes your content easier for the spider to understand and therefore rank. If your HTML is not properly valid, the search engine can lose the content that is not visible to it while it is looking for the closing tag or attribute. This can severely limit the content that is viewable to the spider and hinder your site’s ability to rank. Browsers tend to be more forgiving on invalid HTML and do their best to render what they can, but a spider is working on speed and quantity of content to digest. The spider is just going to breeze past anything it does not understand. Again, use a tool like Google Webmaster Tools to see how a spider perceives your site.

Many resources are available to validate your HTML, including the W3C’s own Markup Validation Service at http://validator.w3.org/. In addition, most browser developer tools have a plugin or extension to use the W3C’s validator service.

Microformats

Microformats are the more complicated brother of POSH. The idea is to add simple tags to HTML that convey contextual information for the HTML content. Once you see how they work, some are an almost natural way of dealing with the content, similar to an implementation of XML in HTML. The microformat convention is to format certain information in HTML so that it is reliable and can be discovered by microformat-enabled tools such as smartphones. For example, you will often see contact information and addresses expressed in a microformat syntax. You might even be using microformats already and not even know it.

For example, the Technorati tags mentioned earlier are microformats. The rel attribute on an anchor tag linking to Technorati.com indicates that the page you are linking from has been tagged for Technorati consumption. This is a microformat:

<a href="http://technorati.com/tag/wordpress" rel="tag">WordPress</a>

Prior to WordPress 3.5, WordPress used a common microformat built right in called the XFN (XTHML Friends Network). This microformat is simply an attribute you place on links to indicate your relationship with that person. This feature is built-in on the Links screen, also known as your blogroll. While this feature was removed in WordPress 3.5, all of the functionality is still available with the Link Manager plugin (http://wordpress.org/plugins/link-manager/) by Andrew Nacin.

Using this handy screen, you can easily add microformat attributes to your link indicating how and where you know the individual you are linking to. For example, consider the settings shown in Figure 12.5.

images

Figure 12.5 Editing the XFN of a link

These settings will render the HTML as:

<a title="WordPress.org" rel="friend colleague muse"

href="http://WordPress.org">WordPress.org</a>

This is a simple yet effective way to create some meaningful information about the link. The key is the simplicity of it. To a web browser, this information does not affect the rendering, unless you are applying CSS or JS specifically to it. In fact, only recently has Internet Explorer even allowed developers to use the rel attribute as a CSS selector.

But imagine the power when a search engine spider or other tool can create a social graph out of the information contained in microformats. You can find more information about the XFN at http://gmpg.org/xfn/.

Another microformat that is gaining traction is the hCard. The hCard microformat is for displaying contact information for a person or organization. It is the HTML rendering of the common vCard format used in e-mail and e-mail address books such as Microsoft Outlook and Mac OS X Address Book.

Here is a sample hCard:

<a class="url fn" href="http://mirmillo.com">David Damstra</a>

<div class="org">Professional WordPress</div>

<div class="street-address">123 Main Street</div>

<span class="locality">Grand Rapids</span>,

<span class="region">MI</span>,

</div>

The hCard is one of the most common microformats used. It is very similar to the vCard format used in e-mail and address book software.

Render the preceding hCard on your site and it looks like an innocuous address block. But running this same code through a tool or spider that understands this microformat can lead to much more intelligent use of the information.

Microformats allow external tools to make better use of your site content, ideally driving more viewers to your site. Conversely, they make use of external services using metadata in your microformat tagged posts possible.

Currently, search engine spiders do not weigh microformatted data any differently than the other content on your site. However, microformats are emerging and continue to gain traction, and eventually spiders will recognize them and be able to harvest the semantic data included. The bottom line is that microformats are becoming the de facto convention for marking up this type of information. So although the microformat is spidered the same as traditional content, by using the microformat conventions you are working toward future-proofing your content.

Microformats continue to be an investment in the future. They are relatively simple ways to structure specific content so that at a later time this information can be used to do something informative or cool. Hopefully in the future, you will be able to search for a name and find that person’s social graph along with it, search for a business and automatically have the contact information logged to your smartphone, or search for a location and time and have an aggregated list of events that are occurring in the vicinity. The data is starting to emerge, so the tools cannot be far behind.

HTML5

While talking about progressive HTML elements, let’s take a quick dive into HTML5. While not WordPress-specific information, this topic is very appropriate for web development in general.

What is HTML5? Basically, it is the next iteration of the HTML standard that web developers have been using for years. But the term itself is a little loaded. It has become a marketing term to encompass many, many aspects of web development above and beyond the basic HTML syntax. It is essentially a buzz term for executives to indicate the latest and greatest web development techniques, sort of like Web 2.0 was in the late 2000s. So when you hear someone mention HTML5, you have to ask yourself whether they mean HTML5 specifically, or the current crop of web development techniques, including HTML5, CSS3, and JavaScript.

Let’s focus on actual HTML5. What is included in HTML5? Quite a bit actually—some things that you can use immediately, some that you can use selectively depending on your audience, and many things that you will have to wait for browser adoption to really take up.

The biggest feature of HTML5, and likely the one most web developers think of first, is the new tags. HTML5 introduced many HTML elements that are more descriptive and have a semantic purpose. With a little help, you can actually use these new tags today, but more on that in a minute. If you have been developing websites or WordPress themes for a while, you will recognize the common <div id=”header”> and <div id=”footer”> as pretty pervasive to all websites. With HTML5, these elements are replaced with the new<header> and <footer> tags. Additional tags have been created that are particularly appropriate to WordPress themes, including <nav>, <article>, and <aside>.

As you can imagine, the <article> tag specifically fits right into the pages and posts paradigm of WordPress. In fact, the Twenty Eleven theme started using these tags for that purpose. The Twenty Fourteen theme leverages many of the new HTML5 tags in the theme templates and is a good place to start when exploring how to use these tags in your own custom themes.

Another good resource for seeing the HTML5 tags in action is the HTML5 Boilerplate by Paul Irish, online at http://html5boilerplate.com/. This resource is not WordPress-specific but takes all the best practices and recommendations and bundles them together in a HTML5 starter set. Additionally, there are several WordPress themes that have been created using the HTML5 Boilerplate as a source.

A quick cautionary note about HTML5 tag elements: They are not directly supported by all browsers, notably Microsoft browsers prior to Internet Explorer 9. However, all is not lost. There are JavaScript solutions to make these older browsers recognize the new HTML5 tags and let you style them appropriately. The Twenty Fourteen theme uses HTML5Shiv (http://code.google.com/p/html5shiv/) to achieve this functionality. Another option, the one used by HTML5 Boilerplate, is the modernizr.js from http://modernizr.com. Modernizr includes the HTML5Shiv to allow older browsers to recognize the new HTML tags, but also includes additional feature detection to enable you to use additional HTML5 features and CSS3 attributes. Which one you use is dependent on your needs. Depending on your browser support matrix, this may not even be an issue. Unfortunately for those developers among us who have to support an enterprise or corporate network, this remains a fact of developer life.

In our opinion, HTML5, with the appropriate JavaScript, is safe to use in production sites. You can and should be building new themes with the HTML5 tags. The fact that Twenty Fourteen uses these tags is an additional stamp of approval from Automattic, and they even started using these tags more than three years ago. Just make an evaluation of the browsers you need to support and make a decision based on your requirements.

In addition to the new more descriptive HTML tags, HTML5 has a bevy of additional features. As mentioned before, some of them you can use today and some of them you’ll need to wait until browser adoption takes off. A convenient website for determining browser support is http://caniuse.com.

This website tracks past, current, and development versions of the common web browsers and assesses their support of new features, including HTML5, CSS3, and others. It does not take into account when you apply a JavaScript shim such as HTML5Shiv or Modernizr.js. The site tracks out-of-the-box support. This can be a very convenient resource when you are planning your design and settling on which browser to support and which features you want to include.

Some of the additional features of HTML5 include offline storage, which could be used for mobile device web applications when the mobile device does not have an Internet connection. Media and canvas tags are available for delivering certain media files directly in the browser. An especially exciting feature is the new form validation and helpers. These updated form tags include the actual validation mechanism built right into the browser and include additional features such as placeholder text on the forms and formatting. Basically, the new form features are trying to solve the problems on the web that you currently deal with every day.

As mentioned, HTML5 has many more features; to learn more, check out http://www.html5rocks.com.

CSS3

This section is about cascading style sheets, version 3, or CSS3. This is the next iteration of styling websites. Currently, many of the new CSS3 styles are implemented in browsers using browser-specific prefixes. This allows you to try out these new features on specific browsers but also makes maintenance more difficult when you have three to four lines in your CSS file to produce the same effect on different browsers.

Again, http://caniuse.com is an invaluable resource for determining which features you can use across browsers using official CSS3 syntax and when you need to implement browser-specific prefixes. Also, the general consensus now is that developers do not need all browser versions to render websites exactly the same. Being reasonably close is usually good enough. Also, adding flourishes and design details to browsers that support them while leaving older browsers to render it without them is also acceptable. This is generally called progressive enhancement.

A common example of progressive enhancement is rounded corners. Imagine your design mockup has rounded corners on certain design elements. Prior to CSS3, web developers had several tricks for making rounded corners, including images, both positive and reverse in color, as well as countless JavaScript libraries. With CSS3, rounded corners is a simple CSS3 style using the border-radius style.

You can apply this style and check it in your browser, and it works fine. However, if you look up border radius on www.caniuse.com, you will notice that Internet Explorer 7 and 8 do not support this style—which is why you had all those tricks in the first place. At this point, you can choose to accept progressive enhancement. The website still renders fine in Internet Explorer, but certain elements have squared off corners. Browsers that support the enhanced effect have the look you intend. The thought here is that eventually (one hopes), all browsers will converge on the standards, and eventually (one hopes), your enhanced design will become the design that everyone sees. The flip side is that you still have to test your design in the older browsers to make sure they do, in fact, render reasonably well, assuming you do need to support these older browsers. We know Internet Explorer 7 and 8 sound like dinosaurs, but if you do not still have to support them from time to time, consider yourself lucky.

One of the biggest, most immediately accessible features of CSS3 is a media query. Media queries enable the designer to tailor a website to specific screen resolutions, prompting a new type of mobile website experience. This topic, called responsive web design, is covered in a little more depth later in this chapter.

HTML5 adds new semantic tags to make your site’s content more understandable to devices that are rendering or crawling your data. Couple this with CSS3 styling to add new appearance and design attributes to the look and feel of your content. Together they are making the user experience easier to maintain for both human and nonhuman consumers.

SEARCHING YOUR OWN SITE

So far, you have learned how to make your site visible and effective in the big search engines by structuring, organizing, and coding your site to raise your listings, or at least get the ranking you deserve. What happens when the visitor gets to your site and uses the built-in on-site search? Do the same rules and guidelines apply?

The answer is yes and no. The SEO principles and practices discussed are a solid foundation to build on. They are tried-and-true rules, although the search engines can make up their own rules and change them on a whim—you are in the Wild West Internet. The change lies in the built-in WordPress search.

Weaknesses of the Default Search

Out of the box, the WordPress search is probably good enough for most small sites. After all, this is how WordPress evolved, and good enough was good enough. But as your site grows, or as you build larger, more prominent sites, good enough is no longer good enough. The default WordPress search has some serious deficiencies for larger sites, and there are a couple of important challenges to be addressed here.

Results are sorted by date, not relevance to the search terms. WordPress loves showing content in chronological order. Chronological posts are the heart of the WordPress engine. So the default search will return results of the search term in reverse chronological order. It suffers from a recency effect.

Even if you have a large, excellently written article about a topic, if newer posts about the same topic exist, the newer ones will get top billing in the results pages. Relevance to the search terms does not matter. There is no weighting in the results for search term counts. The search strictly glances through all the post and page content, and if the term appears, it flags it for the results and then spits them out in date order.

This brings you to the next shortcoming. The search only searches some of your site’s content. The default search only looks in the post content and page content—not the headlines, not the comments, not the links, not the categories, not the tags, nothing else. You learned earlier that headlines matter, and visitors only read the headlines, so if your catchy article headline sticks in someone’s head and they return to your site to search on some variation of your headline, your search may not find it because headlines are not indexed.

Ideally, your content supports the catchy headline you made, so eventually your content will be found with a search. But there is so much more content to your site that could be used to empower the search to make it more effective or even to broaden the search. After all, it could have been one of your comments that really sparked the interest.

Next, there is no logic to the search. That is, you cannot use any sort of Boolean syntax in the query. The search is a straight up “find this word in the posts” kind of search. Search power users use Boolean syntax all the time to create very refined search engine results. WordPress search does some silly things with these keywords.

For example, try searching on your WordPress site using Boolean keywords in your search string, such as searching for keyword1AND keyword2. In this case, you want to find content that contains both keywords. You will find that WordPress search treats the ANDjust like any other keywords and will include content that contains all three words, that is, the keywords and the word AND. In all likelihood, you will have no results.

WordPress search handles a Boolean “or” in the same fashion. Try searching for content with either keyword1 or keyword2 in it using the search string keyword1OR keyword2. Again, WordPress search treats the OR just like the actual keywords. Now search for either keyword independently and compare the results. Depending on your site, you will notice that the OR search does not contain the same results as the two independent searches combined. After some simple experimentation, you will see that WordPress search does not know how to handle these generic Boolean queries.

Some people complain that the WordPress search does not highlight the search terms in the results. In some situations highlighting is handy; other times, it does not affect the usefulness of the search results. This definitely seems like a personal developer choice, which makes it ripe for a plugin. On the other hand, this could easily be handled with some creative PHP and CSS also.

The WordPress search has been good enough, but it does not take advantage of some available tools such as MySQL FullText search or other third-party search engines such as Lucene or Sphinx. Understandably, WordPress needs to keep the installation process simple and reduce the dependencies on external software packages. This definitely complicates the whole installation. But if a developer is capable and willing to integrate these other packages, why not let them?

Some of these seem like big deals, and for some developers they certainly are. But search is a pretty personal thing. Different developers want it to have specific functionality or algorithms and because WordPress has a great plugin system, each developer can have what he wants. You can either find an existing plugin or you can write your own to scratch that pesky search engine itch.

Alternatives and Plugins to Help

Obviously, we are not the first to recognize these inadequacies in the default search mechanism. Some very talented developers have set out to create plugins that enhance or replace the built-in search. Many, many plugins are available. Some target specific issues, and others change the whole search process. Following are some of the more popular search engine plugins for WordPress.

Search Everything (http://wordpress.org/plugins/search-everything/), now developed by Zemanta, extends the breadth of the WordPress search to include the different content sources in the index, including comments, tags, and categories. Search Everything also has settings for search term highlighting, and all the settings are managed from an Administration Screen.

Relevanssi (http://wordpress.org/plugins/relevanssi/) by Mikko Saari is another search replacement plugin. This plugin comes in both a free version and a premium version that includes support and additional features. This plugin includes search term highlighting and also searches additional fields such as comments, tags, and custom fields. But the biggest advantage of this plugin is that it uses syntax that will be familiar to Google users. This plugin supports the Boolean logic operators AND and OR. It supports phrase searches when included in quotes and partial word matches. This is much more of the search experience users are expecting.

Alternatively, you can actually match the experiences users expect by using a Google Custom Search Engine (http://www.google.com/cse/). Google Custom Search Engine (CSE) is a service offered by Google to provide your own subset of Google’s existing search results. Google offers two programs for your Custom Search Engine. The basic free edition enables you to customize the look and the index but includes Google Ads. The second tier starts at $100 per year to remove the ads and the Google branding, if you desire. Either option integrates into your WordPress site in the same way.

There are several plugins for integrating a Google CSE into your site. Alternatively, you can integrate it manually using page templates and the code provided by Google. Page templates were covered in depth in Chapter 9, but here is a quick example of how you could set this up.

First, sign into the Google Custom Search Engine control panel and create your new custom search engine. After you have set it up, you will want to modify the look and feel. Change the layout to the Two Page option. This enables you to put the search box anywhere on your website and then have a specific page designated for the results. Save this setting and get the code.

Here you need to do a little juggling to create the page you need for the code page of the Google Custom Search Engine. Switching back to your WordPress site, you need a specific page for your search engine results and you want to assign that page a specific template. First, make a new page template for the results. It could be as simple as the following:

<?php

* Template Name: Google Search Results

get_header(); ?>

</div>

</div>

<?php get_footer(); ?>

Notice there is a spot in the content area where you will paste in the search results code provided by Google. Save this template file and push to your WordPress theme on the server.

Next, you need to make a page that uses your theme to show the results. Create a new page on your WordPress site. Select the page template you just pushed and publish the page. Because you are using the preceding page template, you do not need anything in the content area of the page; Google will fill it in for you.

Finally, you need to create the search box on your WordPress installation. Probably the simplest method is to use a text widget in one of your widget areas. Simply copy the Search box code provided by Google and save it in a widget.

Now you need to test that it all works together. Depending on when your website went live, you may need to wait for Google to index your pages.

To really leverage the power of a Google Custom Search Engine, make sure you connect it to your Google Analytics and Google Webmaster Tools accounts. In addition, evaluate some of the additional features in the Google Custom Search Engine such as Refinements to modify the indexing, and Promotions to highlight certain search results.

MOBILE ACCESS AND RESPONSIVE WEB DESIGN

Mobile access continues to be a hot topic because of an enormous market increase of smartphones with high-speed data services and stores that proliferate fat client applications for these phones. Forrester, a global research firm, reports that more than half of the world’s population has a mobile device (http://blogs.forrester.com/susan_huynh/12-02-21-mobile_internet_users_will_soon_surpass_pc_internet_users_globally). Google reports more of its Google+ users are on mobile devices than desktop devices (http://www.engadget.com/2012/06/27/google-has-250-million-users-more-mobile-than-desktop/). Morgan Stanley has been saying for years that mobile access will exceed desktop access in the next several years (http://mashable.com/2010/04/13/mobile-web-stats/). In looking to update these statistics and projections for this edition of this book, we realized that these projections continue to hold true with little updates, in our opinion.

Mobile users are clearly an audience you cannot afford to ignore. The question is how much attention you need to give to this set of visitors. Do you customize an experience for each type of device? Can you keep up with device proliferation? Screen sizes and features and the feature API all vary. There are currently a couple of schools of thought on how to handle this.

Leave It Alone

The first paradigm, and obviously simplest, is to leave it alone—that is, show mobile browsers your full website. Give them the whole experience that you are providing to desktop users.

The idea here is that the newer browsers on the smartphones, such as the Apple iPhone and Google Android devices, can render traditional websites acceptably fine. The tech savvy users of these devices know that the browser is limited and the screen is small and they do not expect a stellar user experience. In short, leave it to the user and the device. Tablets and smartphones can zoom and scroll and users are used to these techniques. If you have young children with tablet experience, you probably have fingerprints on your desktop monitor from the child trying to scroll the screen and subsequently complain when it does not work.

In practice, this method generally works well for certain classes of websites but not others. All of the information on the website is still accessible on a mobile device. The visitor continues to use learned website conventions and behaviors from the traditional browsing experience. The challenge is the small text and limited screen real estate.

Lightweight Mobile

Another school of thought is that you have the technology available to create custom themes for these devices, especially with the power of WordPress. Mobile themes hearken back to the lightweight themes of dial-up days to conserve the limited bandwidth available. This makes mobile themes faster to load over the wireless bandwidth. In addition, they should be tailored to fit the small screen real estate and focus on the information that the mobile visitor is really looking for—often locations and contact information.

WPTouch is a plugin that converts your site to look like a native iPhone application. The WPTouch Plugin was created by Dale Mugford and Duane Storey from Brave New Code and is available at http://wordpress.org/plugins/wptouch/.

After installing this plugin, your site will automatically detect mobile browsers and offer them your entire site, but in a specific mobile-enhanced theme. This theme uses AJAX requests and other effects, giving the illusion of a native application. In addition, WPTouch offers an extensive Administration Screen to manage all the settings.

WPTouch also offers the ability to set a custom index page for mobile browsers. This is a fantastic feature and enables the developer to create a custom page for the quick information that the mobile visitor really needs. In addition to the multiple default themes, WPTouch includes the capability to tweak the CSS to create a theme that matches your traditional site theme. WPTouch also offers the capability for the mobile visitor to select to view the traditional desktop theme.

A couple of notes of caution: If you are using a caching plugin, discussed in Chapter 15, you will have to set it to exclude showing cached content to the mobile browser. Otherwise, the caching will supersede the WPTouch browser detection and the traditional theme will be shown. Second, every mobile detection algorithm behaves a little differently. Should the iPad browser be considered mobile, or is the screen large enough to offer the desktop version? What about the Amazon Kindle with a slightly smaller screen? What about those in-between devices popularly called phablets? Should it behave differently if the device is on WiFi or a slower cell signal? Compound these automatic software decisions with user preferences.

Responsive Design

A responsive design is the current craze. Responsive web design was first proposed by Ethan Marcotte on A List Apart in 2010 (http://alistapart.com/article/responsive-web-design). In essence, responsive web design uses the CSS3 media queries’ functionality, mentioned previously, to reformulate the layout and design of your website theme to match the screen size of the device it is being viewed on. The theory here is that you manage the content and theme at once, and then tweak the rendering for different screen resolutions. That is one set of content for every screen size that adapts, or responds to the viewing environment through selective CSS rules. In practice, it is much more complex.

This works because of media queries. Media queries existed prior to CSS3. Print style sheets are a form of media query that web developers have used for a long time. What changed with CSS3 is that the media queries now support screen resolution calculations. These queries now allow you to apply certain CSS styles only if the screen resolution falls in a certain range, as determined by you. Best practices recommend targeting a desktop, full scale version, a mid-scale or tablet version, and then a small screen or smartphone resolution.

The specific intricacies of responsive web design are not WordPress-specific and are outside the scope of this book, but let’s take a quick look at how they might work.

A common responsive design change on a WordPress site is dealing with the sidebar. On a desktop browser, you have the screen real estate and generally the sidebar is located on the left or right-hand side. This is a traditional website. However, on a mobile small screen, where space is much more limited, this sidebar information may not be as important as the primary content of the page. For example, when viewed on a handheld device, perhaps the sidebar content gets moved below the primary information. Using a media query block in your style sheet, you can change the flow of your content pieces. This would leave your primary content, generally considered the most important information, front and center on the small screen, and relegate the secondary content to a less prominent position.

Again, the actual implementations of responsive website design could fill an entire book. Many tutorials and how-tos are available online for best practices and recommendations. Furthermore, many responsive WordPress themes are already out there, including Twenty Fourteen, for you to try and explore how they work.

Responsive web design is a popular solution among developers to address the mobile audience right now. It is a solution deployed on many websites. But the more involved the responsive themes get, the more complicated the process becomes. Anyone remember the days when you made separate website themes for Netscape Navigator and Internet Explorer? Some days, responsive themes feel the same way when you are managing multiple versions of your site for different sizes, under the guise that you are not. You end up troubleshooting and debugging the theme multiple times at the different resolutions. And as devices proliferate, this may become more and more convoluted as you try to match designs to resolutions. The flip side is that you are in complete control and responsive web design will only be as complex as you make it.

Mobile themes continue to be an up-and-coming area of web development. As smartphones with reasonably supportable browsers become more and more the default mode of web access, this type of functionality will become a requirement for all sites. You will continue to see mobile optimized themes and responsive themes pop up all over the place. Most theme frameworks and starter themes include responsive elements from the start, making the whole process easier.

SUMMARY

This chapter covered the user experience that makes your site interesting and available to both readers and devices. Techniques included HTML5 and CSS3 as well as general user experience principles. In the next chapter, you learn about securing your site against several types of common threats.