In corporate design, humor can be your most powerful tool—or a total disaster

The first of April is a day for jokes.

Yesterday, brands including Google, Lexus, Adobe and Virgin America deployed their obligatory April Fools gags, to varying results. As the newly updated design classic, A Smile in the Mind: Witty Thinking in Graphic Design (released on Feb. 15 by Phaidon Press) argues, humor is big business and, when done right, it can help companies win favor and even forge an emotional bond with customers more effectively than hard sell tactics.

A compendium of design jokes, visual puzzles and optical gags first published in 1996, A Smile in the Mind offers hundreds of examples of graphic wit from the world of branding, packaging, publications, and advertising. Even for those who roll their eyes at such witticisms, there is still plenty of serious, practical wisdom packed in this excellent compendium, written by design and branding experts.

“Wit,” as authors Beryl McAlhone and David Stuart explained, is “of the frisky tendency in that it makes its impact through sudden jumps, skips and somersaults and reversals in the mind.” The book’s first edition featured that secret arrow cleverly embedded in the FedEx logo, irresistibly clever Japanese food packaging, and a black umbrella concealing a joyful patch of blue sky conjured by graphic design wit master Tibor Kalman. Page after page, its authors make a compelling case that humor is the “shortest distance between two people,” to paraphrase a famous quip by the piano-playing comedian Victor Borge. The book’s simple cover with the tipped red letter “D” fittingly demonstrates this approach.


A decade later, the 2016 edition teems with contemporary examples of graphic cleverness and outlines humor’s utility in the era of shorter attention spans and social media. “Wit makes memes, the currency of the sharing age,” write authors Nick Quinton and Greg Ashbury, who took on the challenge of updating the design classic.

With the daily cascade of images on Twitter, Instagram, Pinterest, and myriad blogs, Quinton and Ashbury had a lot to choose from. “It was a joy to sift through so much wonderful work from around the world—we could easily have filled the book ten times over,” says Ashbury.

Ballet classes: tear off for details. Grupo Gallegos, USA, 2006. Creative directors Favio Ucedo/Juan Oubiña; art directors Curro Chozas/Paula Olios(Phaidon)

To whittle their selection to around 500 examples for the 270-page volume, the authors held two guiding principles: intention and variety. “We had in mind a definition of wit that is about generosity and openness—big ideas that create a smile in as many minds as possible,” explains Quinton to Quartz. “We also wanted to reflect the sheer variety of wit at work today, not only in the sense of laugh-out-loud humor, but also lateral thinking and playful interventions in everyday life.”

NYC Spaghetti: a mould at the base of the pack creates the spaghetti formation at the top. Alex Creamer, UK, 2000. Designer Alex Creamer; 3D modeller Ben Thorpe; tutors Billy Harkcom, Andrew Bainbridge, Jon Harker(Phaidon)

Humor as a business strategy

But wit can deliver more than personal amusement. Citing the management expert Jean-Louis Barsoux’s 1993 book, Funny Business: Humour Management and Business Culture, they explain that a well-executed visual joke can induce a relaxed and receptive frame of mind. For new or skeptical customers, “getting the joke,” incites a shared flash of insight that somehow forms a complicit bond. “This is like persuading the goalkeeper to stand aside before you shoot at the goal,” they wrote.

Polar ice: ice cubes with a message. Atsuhiro Hayashi, Japan, 2011(Phaidon)

Quinton, who also serves as executive creative director of the branding firm The Partners, suggests that wit can go beyond one-off product advertising campaigns. “Wit can be a structural idea that underpins a whole brand,” he says. “It works for global giants like Google, Amazon and Coca-Cola. And it works for grassroots ideas, as a tool of political protest or spreading environmental and health messages.

Humor can be also be an effective way to stand out in today’s “attention economy.” Because wit sparks curiosity, well-conceived concepts and mental puzzles can help brands “win time” with distracted consumers. “Why is witty work more memorable?” the authors ask. “We would argue that an idea that happens in the mind, stays in the mind.”

 The trick of the joke

As comedians know, many jokes fall flat. For companies, a misconceived joke can have more dire consequences.

Google learned this first-hand today when, within an hour of its launch, the company was forced to abort its cheeky “Gmail Drop Mic” gag after causing confusion and distress, and even allegedly costing one user a job. Virgin America, which unveiled a new fake logo—a pair ofpendulous boobs, referencing Airbnb’s accidental (and real) vagina-shaped brand mark—has also managed to offend many.

Sometimes creative teams can have too much fun coming up with these “intellect-flaunting” ideas. “A witty idea that baffles people is always worse than no idea at all,” Quinton and Ashbury explain. “The first danger for a designer is self-indulgence.”

As a guideline, they offer some no-nonsense advice from the poet Ogden Nash: “Here’s a rule of thumb. Too clever is dumb.”

[Source:- Webdesignernews]

Introducing Google Tag Manager for Real World Tags

Google Tag Manager is great for easily deploying and organizing all your site and app tags. But what about the complex problem of tags in the real world? Libraries, dentist offices, and college universities are a big mess of file folders with complex tagging systems. (The Dewey Decimal System for example dates all the way back to 1876!) Street artists have to manually spray paint their tags, and retailers have to keep track of tags on their wares. Conservationists and marine biologists tag animals such as sharks in order to fully understand their behaviors. But how to wrangle your universe of real-world items is the question.

The Tag Manager team thought deeply about this issue and decided there had to be a better way to manage the broad spectrum of real world tags. Finding things like folders by numerical sorting in stacks of thousands is simply too difficult. What if one is out of place? That’s why today we’re excited to announce Google Tag Manager for real world tags!

Simply place the patented Google Tag Manager RFID tag on what you want to manage, such as the above LP, and we’ll do the rest.

Feature Overview 
Google Tag Manager for real world tags seeks to automagically inventory, categorize and help manage your real world tags no matter what variety they are. And by using the power of the cloud, the hard work will get done for you!

Once placed on the desired item, Google Tag Manager for real world tags will create a record of that item in your Tag Manager dashboard. Now you have a record of this item from your mobile device or workstation, so you can manage it from anywhere in the world.

Automatic Categorization 
We’ll automatically determine what’s going on with your items and scan their contents in real-time. So whether you’re tagging a shark, or just tagging your lunch in the break room refrigerator, our tag management technology will discern what’s being tagged appropriately, and help you easily turn on the set of functions specific to your use case (for example, tracking down your missing leftovers).

Edit & Create Rules 
You can create rules for your tags without having to even go back to your physical item. For example, are you a street artist? Simply stick one of our RFID stickers on the wall next to your tags, and change the color or style from anywhere in the world through our easy to use interface.

Speaking of sharks, are you a marine biologist? We’ve got you covered. No longer do you have to manually tag each animal you’re tracking one by one. With our new fleet of Google Tag Manager Real World Drones, simply setup a trigger for the animals you’re working to protect, and the drones will gently and humanely deploy the necessary tags to all relevant animals:

How to get started … 
We’ll be releasing Google Tag Manager for real world tags in the coming weeks, and shipping 10,000 physical tags to each registered user of Google Tag Manager to get started. The first release will require you to manually update your tags, but of course you only need to re-tag your items once – after that, it’s smooth sailing.

[Source:- Webdesignernews]

Building An Advanced WordPress Search With WP_Query

Many WordPress superpowers come from its flexible data architecture that allows developers to widely customize their installations with custom post types, taxonomies and fields. However, when it comes down to its search, WordPress provides us with only one-field form that often appears inadequate and leads site admins to adopt external search systems, like Google Custom Search, or third-party plugins.

In this article I’ll show you how to provide your WordPress installation with an advanced search system allowing the user to search and retrieve content from a specific custom post type, filtering results by custom taxonomy terms and multiple custom field values.

The article has two parts. First, I will present a theoretical introduction to handling user requests, starting from the URL transmission, passing through the query execution, and ending with the output production. The second part of the article is a concrete application of what we’re going to learn in the first part, and there we will build our advanced search system.

So, let’s start learning some key concepts.

User Requests Link

When a user clicks on a link or types a URL pointing to a page of the website, WordPress performs a series of operations described well in the Codex Query Overview. Briefly, this is what happens:

  1. WordPress parses the requested URL into a set of query parameters (called query specification).
  2. All the is_ variables related to the query are set.
  3. The query specification is converted into a MySQL query, which is executed against the database.
  4. The retrieved dataset is stored in the $wp_query object.
  5. WordPress then handles 404 errors.
  6. WordPress sends blog HTTP headers.
  7. The Loop variables are initialized.
  8. The template file is selected according to the template hierarchy rules.
  9. WordPress runs the Loop.

URL parsing comes first, so let’s dive into query strings and variables.


The Codex states:

An array of query vars are available for WordPress users or developers to utilise in order to query for particular types of content or to aid in theme and/or plugin design and functionality.

In other words, WordPress query vars are those variables in a query string that determine (or affect) results in a query performed against the database. By default, WordPress provides public and private query vars, and the Codex defines them as follows:

Public query vars are those available and usable via a direct URL query in the form of

Private query vars cannot be used in the URL, although WordPress will accept a query string with private query vars, the values will not be passed into the query and should be placed directly into the query. An example is given below.


As a consequence, it’s not possible to send via a query string private vars likecategory__in, category__not_in, category__end, etc. (check the Codex for a comprehensive list of the built-in query vars) .

With the public variables at our disposal (as users as well as developers), we can assemble a great number of queries with no need to develop a plugin or edit the theme’s functions file. We just need to build a URL, add to the query string one or more of the available parameters, and WordPress will show the requested results to the user.

As an example, we can query for a specific post type by adding the post_typeparameter to the query string; or we can request a custom taxonomy, appending to the query string the pair taxonomy-name=taxonomy-term. For instance, we can build the following URL:

WordPress will query the database and retrieve all movie post types belonging to the thriller genre, where genre is a custom taxonomy.

It’s awesome, but that’s not all. What we have said so far, in fact, concerns just the built-in functionalities of query vars. WordPress allows us to go further and create our own custom query variables.


Before we can use them, the custom query vars should be registered. We can accomplish this task thanks to the query_vars filter. So, let’s open the main file of a plugin (or a theme’s functions.php file) and write the following code:

 * Register custom query vars
 * @link
function myplugin_register_query_vars( $vars ) {
	$vars[] = 'author';
	$vars[] = 'editor';
	return $vars;
add_filter( 'query_vars', 'myplugin_register_query_vars' );

The callback function keeps an array of variables as an argument, and must return the same array when new variables have been added

Now we can include the new variables in the parameters that will affect the query. These parameters will be available in our scripts thanks to theget_query_var() template tag, as we’ll see later. Now it’s time to introduce the class that manages the queries in WordPress.


Querying a database is not an easy task. It’s not only a matter of building an efficient query, but it’s a problem that requires security issues to be carefully taken into account. Thanks to WP_Query Class, WordPress gives us access to the database quickly (no need to get our hands dirty with SQL) and securely (WP_Query builds safe queries behind the scenes).

The retrieved dataset will be available for use in the Loop, thanks to the many methods and properties of the class.

Let’s take a generic Loop as an example:

<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
	<!-- code here -->
<?php endwhile; else : ?>
	<!-- code here -->
<?php endif; ?>

If you are new to WordPress development, you may ask: “Hey, buddy! Where’s the Query?”

In fact, you don’t need to create a new instance of the WP_Query object. The class itself establishes the query to be executed according to the requested page. So, if the site viewer requires a category archive, WordPress will run a query retrieving all posts belonging to that specific category, and the Loop will show them.

But this is just a vary basic example of a main query. We can do a lot of more, and filter the returning result set granularly, just by passing an array of parameters to a new instance of the WP_Query class, as we’ll do in the following example:

// An array of arguments
$args = array( 'arg_1' => 'val_1', 'arg_2' => 'val_2' );

// The Query
$the_query = new WP_Query( $args );

// The Loop
if ( $the_query->have_posts() ) {
	while ( $the_query->have_posts() ) : $the_query->the_post(); 
		// Your code here
} else {
        // no posts found
/* Restore original Post Data */

Things look a bit more complicated, don’t they? But if we look closely, they’re not.

The new instance of WP_Query keeps an array of arguments that will affect data retrieved from the database. The Codex provides the full list of parameters, grouping them in seventeen categories. So, for instance, we haveAuthor Params, Category Params, just one Search parameter (s), Custom Field params, and so on (we’ll get back to WP_Query params in a moment).

Now that we have instantiated the $query object, we can access all itsmethods and properties. have_posts checks whether any post remains to be printed, while the_post moves the Loop forward to the succeeding post and updates the $post global variable.

Outside the Loop, when using a custom query, we should always make a call to wp_reset_postdata(). This function restores the $post global variable after the execution of a custom query, and is necessary because any new query overwrites $post. From the Codex:

Note: If you use the_post() with your query, you need to runwp_reset_postdata() afterwards to have Template Tags use the main query’s current post again.

Now let’s get back to the query args.


We said that the WP_Query class keeps an array of parameters that allow developers to select granularly the results from the database.

The first group, the Author Parameters, includes those arguments that allow us to build queries based on the author(s) of the posts (pages and post types). They include:

  • author
  • author_name
  • author__in
  • author__not_in

If you want to retrieve all the posts from carlo, you just need to set the following query:

$query = new WP_Query( array( 'author_name' => 'carlo' ) );

The second group includes the Category Parameters, i.e. all those arguments that allow us to query for (or exclude) posts assigned to one or more categories:

  • cat
  • category_name
  • category__and
  • category__in
  • category__not_in

If we needed all posts assigned to the webdesign category, we just have to set the category_name argument, as we’ll do in the following example:

$query = new WP_Query( array( 'category_name' => 'webdesign' ) );

The following query searches for posts from more than one category, the comma standing in for OR:

$query = new WP_Query( array( 'category_name' => 'webdesign,webdev' ) );

We can also ask for posts belonging to both webdesign and webdevcategories, with plus (+) meaning AND:

$query = new WP_Query( array( 'category_name' => 'webdesign+webdev' ) );

And we can also pass an array of IDs, as in the next examples:

$query = new WP_Query( array( 'category__in' => array( 4, 9 ) ) );
$query = new WP_Query( array( 'category__and' => array( 4, 9 ) ) );

And so on with tags and taxonomies, search keywords, posts, pages and post types. Refer to the Codex for a more detailed walk-through of query arguments.

As we said before, we can also set more than one argument and retrieve, for instance, all posts in a specific category AND written by a certain author:

$query = new WP_Query( array( 'author_name' => 'carlo', 'category_name' => 'webdesign' ) );

When the data architecture get more complex – and that occurs when we add custom fields and taxonomies to post types – then it could become necessary to set one or more Custom Field parameters allowing us to retrieve all posts (or custom post types) labeled with specific custom field values. Shortly, we’ll need to execute a meta query against the database.


The Codex informs us that when dealing with a meta query, WP_Query uses the WP_Meta_Query class. This class, introduced in WordPress 3.2, builds the SQL code of the queries based on custom fields.

To build a query based on a single custom field, we just need one or more of the following arguments:

  • meta_key
  • meta_value
  • meta_value_num
  • meta_compare

Suppose a custom post type is named accommodation. Let’s assign to eachaccommodation a custom field named city, which stores the name of a geographical location. With a meta query we can retrieve from the database all accommodations located in the specified city, simply passing the right arguments to the query, as you can see below:

$args = array( 
	'post_type'		=> 'accommodation', 
	'meta_key'		=> 'city', 
	'meta_value'		=> 'Freiburg', 
	'meta_compare'	=> 'LIKE' );

Once we’ve set the arguments, we can build the query the same way as before:

// The Query
$the_query = new WP_Query( $args );

// The Loop
if ( $the_query->have_posts() ) {
	while ( $the_query->have_posts() ) : $the_query->the_post(); 
		// Your code here
} else {
        // no posts found
/* Restore original Post Data */

Copy and paste the code above in a template file and you’ll get an archive of all accommodations available in Freiburg.

This is the case for a single custom field. But what if we needed to build a query based on multiple custom fields?


For this kind of query, the WP_Meta_Query class (and the WP_Query class as well) provides the meta_query parameter. This has to be an array of arrays, as shown in the following example:

$args = array(
	'post_type'  => 'accommodation',
	'meta_query' => array(
			'key'     => 'city',
			'value'   => 'Freiburg',
			'compare' => 'LIKE',

The meta_query element is a bidimensional array whose items are single meta queries with the following arguments:

Argument Type Description
key string Identifies the custom field.
value string|array Can be an array just when the compare value is 'IN', 'NOT IN', 'BETWEEN', or 'NOT BEETWEEN'.
compare string A comparison operator. Accepted values are '=', '!=', '>','>=', '<', '<=', 'LIKE', 'NOT LIKE', 'IN', 'NOT IN','BETWEEN', 'NOT BETWEEN', 'EXISTS', 'NOT EXISTS','REGEXP', 'NOT REGEXP' and 'RLIKE'. It defaults to '='.
type string The custom field type. Possible values are 'NUMERIC','BINARY', 'CHAR', 'DATE', 'DATETIME', 'DECIMAL','SIGNED', 'TIME', 'UNSIGNED'. It defaults to 'CHAR'.

If we set more than one custom field, we also have to assign the relationargument to the meta_query element.

Now we can build a more advanced query. Let’s begin by setting the arguments and creating a new instance of WP_Query:

$args = array(
	'post_type'	=> 'accommodation',
	'meta_query'	=> array(
		array( 'key' => 'city', 'value' => 'Paris', 'compare' => 'LIKE' ),
		array( 'key' => 'type', 'value' => 'room', 'compare' => 'LIKE' ),
		'relation' => 'AND'
$the_query = new WP_Query( $args );

Here, the meta_query argument holds two meta query arrays and a third parameter setting the relation between the meta queries. The query searches the wp_posts table for all accommodation post types where the custom fieldscity and type store respectively the values Paris and room.

Let’s copy and paste the code into a template file named archive-accommodation.php. When requested, WordPress will execute the query searching the wp_posts table, and the Loop will show the results, if available.

At this point we’re still writing the code in a template file. This means that our script is static and each time the Loop runs, it will produce the same output. But we need to allow site users to make custom requests, and to accomplish this task we need to dynamically build custom queries.


The pre_get_posts action hook is fired after the $query object creation, but before its execution. To modify the query, we’ll have to hook a custom callback to pre_get_posts.

In an earlier example, we queried the database to retrieve all posts in thewebdesign category from a certain author. In the following example we’re passing the same arguments to the $query object, but we won’t do the job with a template file, as we’ve done before, but we’ll use the main file of a plugin (or a theme’s functions.php), instead. Let’s write the following block of code:

function myplugin_pre_get_posts( $query ) {
	// check if the user is requesting an admin page 
	// or current query is not the main query
	if ( is_admin() || ! $query->is_main_query() ){
	$query->set( 'author_name', 'carlo' );
	$query->set( 'category_name', 'webdesign' );
add_action( 'pre_get_posts', 'myplugin_pre_get_posts', 1 );

The $query object is passed to the callback function by reference, not by value, and this means that any changes made to the query directly affect the original $query object. The Codex says:

The pre_get_posts action gives developers access to the $query object by reference (any changes you make to $query are made directly to the original object – no return value is necessary).

As we’re manipulating the original $query object, we have to pay attention to which query we’re working on. The is_main_query method checks if the current $query object is… (yes!) the main query. The Codex also informs us that the pre_get_posts filter can affect the admin panel as well as the front-end pages. For this reason, it’s more than appropriate to check the requested page with the is_admin conditional tag as well.

The pre_get_posts action hook is well documented and it’s well worth reading the Codex for a more detailed description and several examples of use.

We can now end our introduction to the the main tools available to handle WordPress queries. Now it’s time to present a concrete example of their use, building an advanced search system of the site content. Our case study is provided by a real estate website.

From Theory To Code: Building The Search System Link

We will follow these steps:

  1. Define the data structure.
  2. Register the custom query vars.
  3. Get the query var values and use them to build a custom query.
  4. Build a form programmatically generating the field values.


The purpose of the custom post types is to add contents that logically can be included neither in blog posts nor in static pages. Custom post types are particularly appropriate to present events, products, books, movies, catalogue items, and so on. Here we’re going to build an archive of real estate ads with the following structure:

  • custom post type: accommodation;
  • custom taxonomy: typology (B&B, homestay, hotel, etc.)
  • custom field: _sm_accommodation_type (entire house, private room, shared room)
  • custom field: _sm_accommodation_city
  • other custom fields

We have to register the post type, the custom taxonomy and custom fields and meta boxes, as shown in the figure below.

Accommodation edit page
The edit accommodation page shows all custom meta boxes and fields. (View large version)

The image shows how the Edit Accommodation page will appear once three custom meta boxes containing the Typology custom taxonomy and several custom fields have been registered.

It’s not our goal to analyze WordPress data architecture, as this topic has already been covered here on Smashing Magazine by Daniel, Brian, Kevin,Josh and Justin. Read their articles if you need a refresher, and come back as soon as you’re ready.

Once we’ve defined the data architecture, it’s time to register the query vars.


Earlier we defined query vars as key=value pairs following a question mark in a URL. But before we can handle these pairs in our scripts, we have to register them in a plugin or functions file. For our purposes, we need just two variables that will enable the execution of a query based on the values of the corresponding custom fields:

 * Register custom query vars
 * @link
function sm_register_query_vars( $vars ) {
	$vars[] = 'type';
	$vars[] = 'city';
	return $vars;
add_filter( 'query_vars', 'sm_register_query_vars' );

That’s it! We have added two more parameters to query the database. Now it would make sense to build a URL like this one:


Now let’s add a new block of code to our script:

 * Build a custom query based on several conditions
 * The pre_get_posts action gives developers access to the $query object by reference
 * any changes you make to $query are made directly to the original object - no return value is requested
 * @link
function sm_pre_get_posts( $query ) {
	// check if the user is requesting an admin page 
	// or current query is not the main query
	if ( is_admin() || ! $query->is_main_query() ){

	// edit the query only when post type is 'accommodation'
	// if it isn't, return
	if ( !is_post_type_archive( 'accommodation' ) ){

	$meta_query = array();

	// add meta_query elements
	if( !empty( get_query_var( 'city' ) ) ){
		$meta_query[] = array( 'key' => '_sm_accommodation_city', 'value' => get_query_var( 'city' ), 'compare' => 'LIKE' );

	if( !empty( get_query_var( 'type' ) ) ){
		$meta_query[] = array( 'key' => '_sm_accommodation_type', 'value' => get_query_var( 'type' ), 'compare' => 'LIKE' );

	if( count( $meta_query ) > 1 ){
		$meta_query['relation'] = 'AND';

	if( count( $meta_query ) > 0 ){
		$query->set( 'meta_query', $meta_query );
add_action( 'pre_get_posts', 'sm_pre_get_posts', 1 );

This code is the sum of all we covered in the first part of the article. The callback function quits if the user is in the admin panel, if the current query is not the main query, and if the post type is not accommodation.

Later, the function checks if any of the query vars we’ve registered before are available. This task is accomplished thanks to the get_query_var function, which retrieves a public query variable from an HTTP request (read more about get_query_var in the Codex). If the variable exists, then the callback defines one array for each meta query and pushes it into the multi-dimensional $meta_query array.

Finally, if at least two meta queries are available, then the relation argument is pushed into $meta_query and its value is set to 'AND'. Once done, the setmethod saves $query for its subsequent execution.

You don’t need to worry about data sanitization here, because the WP_Queryand WP_Meta_Query classes do the job for us (check the WP_Query andWP_Meta_Query source code)


The form data are submitted with the GET method. This means that the nameand value attributes of the form fields are sent as URL variables (i.e. as query vars). So we’re going to give the name attributes of the form fields the same values as the previously registered query vars (city and type), while the field values could be assigned programmatically, retrieving data from the database, or filled in by the user.

First we will create a shortcode that will allow the site admin to include a search form in posts and pages of the website. Our shortcode will be hooked to the init action:

function sm_setup() {
	add_shortcode( 'sm_search_form', 'sm_search_form' );
add_action( 'init', 'sm_setup' );

Next we will define the callback function that will produce the HTML of a form containing three select fields, corresponding to a custom taxonomy and two custom fields.

function sm_search_form( $args ){
	// our code here

$args is an array of the shortcode attributes. Inside the function we’ll add the following code:

// The Query
// meta_query expects nested arrays even if you only have one query
$sm_query = new WP_Query( array( 'post_type' => 'accommodation', 'posts_per_page' => '-1', 'meta_query' => array( array( 'key' => '_sm_accommodation_city' ) ) ) );

// The Loop
if ( $sm_query->have_posts() ) {
	$cities = array();
	while ( $sm_query->have_posts() ) {
		$city = get_post_meta( get_the_ID(), '_sm_accommodation_city', true );

		// populate an array of all occurrences (non duplicated)
		if( !in_array( $city, $cities ) ){
			$cities[] = $city;    
} else{
       echo 'No accommodations yet!';

/* Restore original Post Data */

if( count($cities) == 0){

$select_city = '<select name="city" style="width: 100%">';
$select_city .= '<option value="" selected="selected">' . __( 'Select city', 'smashing_plugin' ) . '</option>';
foreach ($cities as $city ) {
	$select_city .= '<option value="' . $city . '">' . $city . '</option>';
$select_city .= '</select>' . "\n";


We’ve built a query that will retrieve all accommodation post types having set a custom field named _sm_accommodation_city (the underscore preceding the name represents a hidden custom field).

The Loop won’t show any accommodation, but will add elements to the$cities array from the corresponding custom field value. The condition will skip duplicates. If no accommodations are available, the execution is interrupted; otherwise the array elements are sorted and used to print the values of the first group of option elements.

Select box
All available cities are shown as options in a select box.

The second form field is still a select button, and it corresponds to thetypology custom taxonomy. The values of the second group of optionelements are provided by the get_terms template tag. Here follows the second block of code, generating a new select field corresponding to thetypology taxonomy:

$args = array( 'hide_empty' => false );
$typology_terms = get_terms( 'typology', $args );
if( is_array( $typology_terms ) ){
	$select_typology = '<select name="typology" style="width: 100%">';
	$select_typology .= '<option value="" selected="selected">' . __( 'Select typology', 'smashing_plugin' ) . '</option>';
	foreach ( $typology_terms as $term ) {
		$select_typology .= '<option value="' . $term->slug . '">' . $term->name . '</option>';
	$select_typology .= '</select>' . "\n";

get_terms returns an array of all terms of the taxonomy set as first argument, or a WP_Error object if the taxonomy does not exist. Now again a foreachcycle prints out the option elements.

Select box
The options of the second select box.

Then we build the last select element, corresponding to the type custom field. Here is the code:

$select_type = '<select name="type" style="width: 100%">';
$select_type .= '<option value="" selected="selected">' . __( 'Select room type', 'smashing_plugin' ) . '</option>';
$select_type .= '<option value="entire">' . __( 'Entire house', 'smashing_plugin' ) . '</option>';
$select_type .= '<option value="private">' . __( 'Private room', 'smashing_plugin' ) . '</option>';
$select_type .= '<option value="shared">' . __( 'Shared room', 'smashing_plugin' ) . '</option>';
$select_type .= '</select>' . "\n";

As you can see, in this case we have manually set the option values.

Finally, we can print out the form:

$output = '<form action="' . esc_url( home_url() ) . '" method="GET" role="search">';
$output .= '<div class="smselectbox">' . esc_html( $select_city ) . '</div>';
$output .= '<div class="smselectbox">' . esc_html( $select_typology ) . '</div>';
$output .= '<div class="smselectbox">' . esc_html( $select_type ) . '</div>';
$output .= '<input type="hidden" name="post_type" value="accommodation" />';
$output .= '<p><input type="submit" value="Go!" class="button" /></p></form>';

return $output;

We’ve set a hidden input field for the post_type public query var. When the user submits the form, WordPress gets the post_type value, and loads thearchive.php template file, or, if available, the archive-{post_type}.php file. With this kind of form, if you’re going to customize the HTML structure of the resulting page, you’ll need to provide the most appropriate template file.

Advanced search form
The image shows the advanced search form we’ve been building through this article.

The form we’ve built so far allows the user to set up three filters from a number of predetermined options. We’re now going to improve the search system including a text field in the form, so that users can search accommodation by custom keywords. We can do that thanks to the s query argument. So, let’s change the form as follows:

$output = '<form id="smform" action="' . esc_url( home_url() ) . '" method="GET" role="search">';
$output .= '<div class="smtextfield"><input type="text" name="s" placeholder="Search key..." value="' . get_search_query() . '" /></div>';
$output .= '<div class="smselectbox">' . esc_html( $select_city ) . '</div>';
$output .= '<div class="smselectbox">' . esc_html( $select_typology ) . '</div>';
$output .= '<div class="smselectbox">' . esc_html( $select_type ) . '</div>';
$output .= '<input type="hidden" name="post_type" value="accommodation" />';
$output .= '<p><input type="submit" value="Go!" class="button" /></p></form>';

Thanks to the text field, we can pass WP_Query a new key/value pair, where the key is the s parameter, and the value is the user input or theget_search_query() returning value (read the Codex for more details).

Advanced search form
A more advanced search form.

A final note: in our preceding example, we’ve seen WordPress loading an archive template file to show the results of the query. That’s because we did not set the search argument. When the query string contains the s param, WordPress automatically loads the search template file, as shown in the last image of this post.

Advanced search form
The image shows the search page in Twenty Fifteen.


The examples of this article are intended to demonstrate what can be achieved with the tools provided by WordPress. Sure, the form can be improved by adding new fields allowing more granular customization. Nevertheless, I hope I’ve provided a quite detailed view of the functionalities that make it possible to build a search system overcoming the limits of the built-in search system with no need of external services and plugins.


[Source:- Smashingmagazine]

How To Make A Physiology-Friendly Application For The iPad

If you’ve ever had to move your iPad from one hand to the other just to tap a button you couldn’t reach, then you may have already guessed why we began this study in our UX lab.

Our Mail.Ru Group’s UX lab team carries out many usability studies of our apps for smartphones and tablets. We address users’ needs by introducing features in our products. We carefully test all of the functions to ensure users notice and understand them well. Nevertheless, this was the first time we had looked at the physiological aspect of our app’s usage.

We came across several studies dedicated to the physiology of using iPads, but they were all scientific, rather than practical, and quite far from business needs. Moreover, such studies were performed on smartphones alone, excluding tablets.

So, we decided to analyze the physiology of using the interface of Mail.Ru’s Email app; for example, how comfortable is it to use an iPad app in typical positions? The behaviors we studied included tapping buttons while lying down, browsing photos while sitting, swiping, and writing text. Our results revealed a number of purely ergonomic problems that should be taken into account when developing any iPad app.

Our results are shown here on an iPad layout using a three-color schema. Controls located in the green zone are easily reachable by the average person; the yellow zone is still reachable but not as easily; and the red zone is the most inconvenient location for controls.

(The images in this article always follow the relevant paragraphs.)

Safe zones on iPad
Safe zones on iPad. (View large version)

Description Of Study Link


In terms of user experience, an iPad is interesting as a replacement for a notebook at home (when the user is lying on a couch) or on journeys (when the user is sitting on an airplane or in a hotel room). Such conditions differ greatly from the environment in which we first tested iPad apps. The majority of our previous studies were carried out in a laboratory with an iPad fixed to a bench and using an eye-tracking device. However, we soon learned that this wasn’t suitable for our study because we needed to observe how people use iPads in their everyday environment. So, instead, we had our respondents sit or lie down on a couch to simulate natural conditions.

Tobii mobile eye-tracker in our UX lab
Tobii mobile eye-tracker in our UX lab. (View large version)


Our audience consisted of the following:

  • eight Mail.Ru Group employees who aren’t designers or involved in any way in the email product’s development;
  • five males and three females, 25 to 35 years of age.

All respondents use an iPad, in particular, to check their Mail.Ru email.

Research Methodology Link


Every user would lie or sit on a couch in the pose that is the most natural for them when using their iPad:

  • supine position (i.e. lying flat, face up);
  • prone position (i.e. lying flat, face down);
  • sitting with legs crossed;
  • sitting with one foot on the couch.

This study dealt only with usage in landscape orientation because a number ofstudies show the majority of iPad users prefer it. Some research shows that it accounts for 35% of usage and is used mostly for specific passive tasks that don’t involve tapping buttons, such as reading a book.

Respondents in different positions when using an iPad
Respondents in different positions when using an iPad. (View large version)


Users performed their usual actions with the email app in scenarios such as the following:

  • replying to a message and downloading three photos;
  • setting a push notification for 8:00 am to 11:00 pm;
  • looking for all flagged emails.
User interface of email app
User interface of email app. (View large version)


All activities were recorded with a GoPro camer (worn by the respondents) and an external camera.

Respondents with GoPro camera
Respondents with GoPro camera. (View large version)

Key Results Link

Analysis of the video showed that some difficulties in using iPad apps were purely physiological — for example, a user seeing all buttons and understanding which one to push and when, but not being able to do so comfortably.

We discovered the following difficulties:

  • having to change how the iPad is held in order to reach a button;
  • having to change the position of one’s fingers in order to press a button;
  • having to change the position of one’s hands in order to press a button.
  • having to bend a hand or finger unnaturally.
  • having to cover the screen with one’s hand in order to reach a button.

Examples of each difficulty are listed below.


Extra features in an app are often available via swiping. For instance, users of Mail.Ru’s Email app swipe to interact with the message list. Respondents mentioned that the outer buttons (“Spam” and “Trash”) were positioned too far away. This particularly affected those sitting on a couch. As they held the iPad with their left hand, keeping hold of it to reach those buttons proved to be uncomfortable, and so they had to stretch their thumb to reach.

Respondents had to stretch their thumb to reach buttons
Respondents had to stretch their thumb to reach buttons. (View large version)


Respondents sometimes had to change their finger position when performing a step-by-step operation. For instance, the first two steps for adding a second account to the email app is performed in the center of the screen, but the button for the third step is at the bottom of the screen. To press it, respondents had to change their finger position.

To proceed with the registration process, users had to change their finger position three times
To proceed with the registration process, users had to change their finger position three times. (View large version)


Sometimes, our respondents changed hands while performing step-by-step operations; for example, when using the app’s menu. Seven out of eight respondents browsed the menu with their left thumb. All of them found it easy to tap the menu options, but they found it difficult to empty the “Trash” folder. That button was too far away to be easily reached (note that four out of eight respondents had to do it with their right hand instead of their left, which was normally used to access the menu). Moreover, this task required two steps: emptying the folder and then confirming the operation. The second step was difficult for respondents who managed to tap the “Trash” folder with their left thumb, because the second step had to be performed with the right hand.

To clear the “Trash” folder, users had to change hands
To clear the “Trash” folder, users had to change hands. (View large version)


Due to the size and shape of the device, some areas of the screen were difficult to tap. A hand would be pressed against the iPad and have to be bent unnaturally to tap a button.

Let’s take the location of the “Save Image” button as an example. The respondents sitting on the couch found it difficult to tap this button. The icon is located in the upper part of the screen, at the edge of the viewport. Therefore, using the index or middle finger, as is usually done, wasn’t quite comfortable because the metacarpophalangeal joint of the thumb was pressed against the device.

When pushing the “Save Image” button, the metacarpophalangeal joint of the thumb pressed against the device
When pushing the “Save Image” button, the metacarpophalangeal joint of the thumb pressed against the device. (View large version)


Buttons in apps are traditionally located in the upper part of the screen, following the common practice on websites. But this location has turned out to be inconvenient, both for smartphones and tablets. When tapping a button in the upper part of the screen, the hand will end up covering most of the screen. Also, the part of the screen where changes caused by tapping certain buttons appear is also covered. This will sometimes confuse the user, who might need a couple of seconds to understand what has occurred as a result of their selection.

I can illustrate this point using our email app’s “Compose” button. One of the respondents used their left hand to tap it. Reaching the center of the screen this way isn’t very comfortable but still possible.

When pressing the “Write a letter” button, the active hand covers half the screen
When pressing the “Write a letter” button, the active hand covers half the screen. (View large version)

However, the other seven respondents used their right hand, covering more than half of the screen:

When the right hand is used to press the “Write a letter” button, over half the screen is covered
When the right hand is used to press the “Write a letter” button, over half the screen is covered. (View large version)

Safe Zone Map Link

An iPad’s physiology-friendly zones for various body positions are shown below. The calculation was performed based on the average length of a finger (the average length being 5.8 cm for males and 5.3 cm for females for 95% of the US population). According to research, male and female iPad users are essentially equally represented (as of June 2012, males accounted for 51.9% of all iPad users, but we’ll consider usage to be equal for the sake of convenience). Therefore, we’ve used the average length for both male and female fingers. And because all of our respondents, as well as most (85%) people in general, are right-handed, these safe zones were determined for right-handed people. For left-handed users, the safe zones would need to be inverted.

The results below take into account the dimensions of an iPad’s frame, being 2 × 1 cm.

Because our respondents used controls located in various parts of the screen, the safe zones we determined could be applied to any iPad app.


Refer to the layout below for physiology-friendly locations of iPad app controls. The diagram applies to a user sitting on a couch with an iPad on their knees.

The controls in the green zone are the easiest to reach for the average person. The yellow zone is still reachable but not as easily. The red zone is the most inconvenient location for controls; a user will encounter several of the difficulties mentioned above; for example, they would have to move their hand to tap a button and end up covering most of the screen.

Safe zones on iPad when user is seated
Safe zones on iPad when user is seated. (View large version)

Lying Supine On Couch (Illustration) Link

This safe zone layout applies to a user lying supine; in other words, lying down, face up, with the iPad resting on their stomach and being held with both hands. Note that the red zone in the lower part of the screen is larger than in all other layouts. An iPad supported by your abdomen in this way over an extended period of time will create a ridge in one’s clothes. This ridge would be about 1 to 2 centimeters high and would cover the controls in the lower part of the screen.

Clothes cover part of the screen for users lying on a couch
Clothes cover part of the screen for users lying on a couch. (View large version)


The third layout applies to a user lying prone; that is to say, lying face down on the couch. In this position, the person has to rest on their forearms, which significantly limits the mobility of their hands, making use of both thumbs the most comfortable way to navigate.

However, because the left hand of right-handed users is holding the device, there are more green zones for the right hand.

Safe zones on iPad when user is lying prone on the couch
Safe zones on iPad when user is lying prone on the couch. (View large version)


The illustration below combines all of the zones for the different body positions into one layout. The areas where green and yellow zones overlap are shown in yellow, while the ones where the green and red zones overlap are shown in red. This enabled us to develop the layout of absolutely safe green zones for all of the body positions of iPad users.

All of the layouts were developed according to the dimensions of the iPad’s bezel, which is 2 centimeters on the left and right sides and 1 centimeter on the upper and lower edges, assuming it is held horizontally. If your app is designed for iPad mini users, you should measure the edges of that device to determine your own safe zones.

Safe zones on the iPad for all positions
Safe zones on the iPad for all positions. (View large version)

We hope the results of this study will assist all developers to improve the usability of their apps during the creation process. We are certain that the results of our study would be relevant to the design of any app, because it was in no way affected by the design of our own app. Respondents were familiar with all of the controls, and our findings were based solely on physiological observations. In addition, note that the Mail.Ru Email app has controls on every side of the screen, so we’re sure that the device’s entire surface was tested.

A user chooses the time when they want to receive push notifications
A user chooses the time when they want to receive push notifications. (View large version)
The user selects a message style
The user selects a message style. (View large version)

If, in a few months (and after having absorbed the recommendations derived from our research here), you find yourself having to change hands less often while using an iPad and you are able to hit controls and menu items more easily and frequently, then you’ll know we’ve addressed the problem effectively.

Recommendations For Designing iPad Apps For Physiology Link

    • Put controls within easy reach on the iPad, however the user is positioned (see our safe zone map). [Note: Readers could have the ability to download raw images of safe zones with real parameters. It would be advisable to have a link here.]
    • If an action consists of two steps (controls, fields, etc.), all steps should be located in the same part of the screen.
Email registration page in Mail.Ru Email app with safe zones
Email registration page in Mail.Ru Email app with safe zones. (View large version)
Message page with safe zones
Message page with safe zones. (View large version)
    • With any step-by-step functions, putting the second step a little higher than the first would be advisable, since the user’s hand would be covering the first step’s controls.
    • The center of the iPad screen is not the best place for controls, because the largest portion of the screen would be covered by the hand that is interacting with the controls. A user lying prone or supine on a couch would have to remove their hand from the device in order to tap the center. We recommend using our safe zone map, where the green shows the optimal location for controls.
App menu with safe zones
App menu with safe zones. (View large version)
Settings window with safe zones
Settings window with safe zones. (View large version)
  • Controls should be located away from the edge of the viewport; that is, 2 centimeters from the left and right sides and 1 centimeter from the upper and lower sides. Bear in mind that users have to aim for buttons while trying to remain within the screen. Also, they have to bend or stretch their fingers to reach the edge of the screen.
  • Other factors not addressed in our experiment can influence the physiological aspects of iPad app design; we’ve focused on the positions that we consider to be the most common. However, you may need to consider factors such as button size, button spacing and long pressing, as well as occasions when an iPad is lying on a table or held in a magnetic cover.

[Source:- Smashingmagazine]

The all new Twitter experience, handcrafted for Windows 10

Connect with people, express yourself, and discover more about the things you love with the Twitter app for Windows 10. Twitter for Windows 10 is a Universal Windows App that features a new media rich timeline and shows you photos and Vine videos. You can also see tweets in Live Tiles right from your Start menu.

Twitter image 1

Free to download from the Windows Store, the new and improved Twitter app for Windows 10 sports a cleaner, more potent perch for sharing and following along. See it quicker with a media forward timeline. Share photos privately and upload multiple photos straight from a timeline. And see what’s happening now on Twitter without being logged in. Get the most interesting Tweets from the day optimized for your location even when logged out, a Windows 10 first!

Screenshot (11)

Be part of the conversation like never before with Twitter for Windows 10, download it for free today! You can also read the news Twitter shared on their blog last week.


[Source:- Windows]