Tag: kranthi

Front-End Author Listing And User Search For WordPress


  

This article will guide you through the process of creating a front-end page in WordPress that lists your authors. We’ll discuss why you would want to do this, we’ll introduce the WP_User_Query class, and then we’ll put it it all together.

User Engagement And WordPress

At its core, WordPress is a rock-solid publishing platform. With a beautiful and easy to use interface, and support for custom post types and post formats, publishers have the flexibility to do what they do best: write content.

However, WordPress is lacking in social interaction between content authors and readers. BuddyPress is trying to solve this, but I believe it’s going in the wrong direction by trying to be a full-fledged social network.

A big phrase in the publishing world is “user engagement.� This is about getting readers to spend more time on the website, actively searching for content and even generating their own. While one could write a few books on the subject, here are a few things a WordPress publisher can do:

  • Create a daily or weekly newsletter, with top stories from selected categories;
  • Provide an editorial-driven open forum in which editors propose themes, stories and questions and readers comment on them;
  • Continue the discussion of articles on social platforms;
  • Encourage users to submit articles and images for contests;
  • Highlight your authors.

Listing Authors, And Why It’s A Good Thing

user-listing

If you’re a publisher, your authors are your biggest asset. They are the content creators. Their writing gets consumed by millions of people all over the world.

Showcasing them exposes them for what they really are: authorities. Your authors will thank you for acknowledging them, and readers will get to see the human face behind the technology.

Coding The Perfect Author Listing

Here are the things we want to achieve with our page:

  • Build it as a WordPress plugin so that we can reuse it more easily;
  • Display the name, biography, number of posts and latest published post of all authors;
  • Paginate the listing if we have many authors;
  • Make the listing searchable.

Introducing WP_User_Query And get_users

The WP_User_Query class allows us to query the user database.

Besides returning an array of users, WP_User_Query returns general information about the query and, most importantly, the total number of users (for pagination).

One can use WP_User_Query by passing a series of arguments and listing the output.

$my_authors = new WP_User_Query( 
	array( 
		'blog_id' => $GLOBALS['blog_id'],
		'role' => '',
		'meta_key' => '',
		'meta_value' => '',
		'meta_compare' => '',
		'include' => array(),
		'exclude' => array(),
		'search' => '',
		'orderby' => 'login',
		'order' => 'ASC',
		'offset' => '',
		'number' => '',
		'count_total' => true,
		'fields' => 'all',
		'who' => ''	
));

We’ll focus on only a few arguments, rather than go through all of them:

  • role
    This is the user’s role. In our example, we’ll query for author.
  • offset
    The first n users to be skipped in the returned array.
  • number
    Limit the total number of users returned.

We also have the get_users class, which (like WP_User_Query) returns a number of users based on the parameters set.

The important difference between the two is that get_users only returns an array of users and their meta data, whereas WP_User_Query returns extra information such as the total number of users (which is useful when it comes time to paginate).

Simple User Listing Using get_users()

Before moving on with the full user listing, including pagination and search, let’s see get_users in action.

If all you need is a simple list of authors, then you could just use wp_list_authors, like so:

wp_list_authors('show_fullname=1&optioncount=1&orderby=post_count&order=DESC&number=3');

Creating A Plugin And Shortcode With A Bit More Functionality

A simple and straightforward way to build our user listing would be to create a shortcode that we could include on any page we like. Housing this type of functionality in a plugin is ideal, so that we don’t have to worry about migrating it when we change the theme.

Let’s keep it simple. Our entire plugin will consist of just one file: simple-user-listing.php.

<?php
/*
Plugin Name: Simple User Listing
Plugin URI: http://cozmoslabs.com
Description: Create a simple shortcode to list our WordPress users.
Author: Cristian Antohe
Version: 0.1
Author URI: http://cozmoslabs.com
*/

function sul_user_listing($atts, $content = null) {
	global $post;
	
	extract(shortcode_atts(array(
		"role" => '',
		"number" => '10'
	), $atts));
	
	$role = sanitize_text_field($role);
	$number = sanitize_text_field($number);

	// We're outputting a lot of HTML, and the easiest way 
	// to do it is with output buffering from PHP.
	ob_start();
	
	// Get the Search Term
	$search = ( isset($_GET["as"]) ) ? sanitize_text_field($_GET["as"]) : false ;
	
	// Get Query Var for pagination. This already exists in WordPress
	$page = (get_query_var('paged')) ? get_query_var('paged') : 1;
	
	// Calculate the offset (i.e. how many users we should skip)
	$offset = ($page - 1) * $number;
	
	if ($search){
		// Generate the query based on search field
		$my_users = new WP_User_Query( 
			array( 
				'role' => $role, 
				'search' => '*' . $search . '*' 
			));
	} else {
		// Generate the query 
		$my_users = new WP_User_Query( 
			array( 
				'role' => 'author', 
				'offset' => $offset ,
				'number' => $number
			));
	}
	
	
	// Get the total number of authors. Based on this, offset and number 
	// per page, we'll generate our pagination. 
	$total_authors = $my_users->total_users;

	// Calculate the total number of pages for the pagination
	$total_pages = intval($total_authors / $number) + 1;

	// The authors object. 
	$authors = $my_users->get_results();
?>
	
	<div class="author-search">
	<h2>Search authors by name</h2>
		<form method="get" id="sul-searchform" action="<?php the_permalink() ?>">
			<label for="as" class="assistive-text">Search</label>
			<input type="text" class="field" name="as" id="sul-s" placeholder="Search Authors" />
			<input type="submit" class="submit" name="submit" id="sul-searchsubmit" value="Search Authors" />
		</form>
	<?php 
	if($search){ ?>
		<h2 >Search Results for: <em><?php echo $search; ?></em></h2>
		<a href="<?php the_permalink(); ?>">Back To Author Listing</a>
	<?php } ?>
	
	</div><!-- .author-search -->
	
<?php if (!empty($authors))	 { ?>
	<ul class="author-list">
<?php
	// loop through each author
	foreach($authors as $author){
		$author_info = get_userdata($author->ID);
		?>
		<li>
			<?php echo get_avatar( $author->ID, 90 ); ?> 
			<h2><a href="<?php echo get_author_posts_url($author->ID); ?>"><?php echo $author_info->display_name; ?></a> - <?php echo count_user_posts( $author->ID ); ?> posts</h2>
			<p><?php echo $author_info->description; ?></p>
			<?php $latest_post = new WP_Query( "author=$author->ID&post_count=1" ); 
			if (!empty($latest_post->post)){ ?>
			<p><strong>Latest Article:</strong>
			<a href="<?php echo get_permalink($latest_post->post->ID) ?>">
				<?php echo get_the_title($latest_post->post->ID) ;?>
			</a></p>
			<?php } //endif ?>
			<p><a href="<?php echo get_author_posts_url($author->ID); ?> ">Read <?php echo $author_info->display_name; ?> posts</a></p>
		</li>
		<?php
	}
?>
	</ul> <!-- .author-list -->
<?php } else { ?>
	<h2>No authors found</h2>
<? } //endif ?>

	<nav id="nav-single" style="clear:both; float:none; margin-top:20px;">
		<h3 class="assistive-text">Post navigation</h3>
		<?php if ($page != 1) { ?>
			<span class="nav-previous"><a rel="prev" href="<?php the_permalink() ?>page/<?php echo $page - 1; ?>/"><span class="meta-nav">�</span> Previous</a></span>
		<?php } ?>
		
		<?php if ($page < $total_pages ) { ?>
			<span class="nav-next"><a rel="next" href="<?php the_permalink() ?>page/<?php echo $page + 1; ?>/">Next <span class="meta-nav">→</span></a></span>
		<?php } ?>
	</nav>

	
	<?php 
	// Output the content.
	$output = ob_get_contents();
	ob_end_clean();

	
	// Return only if we're inside a page. This won't list anything on a post or archive page. 
	if (is_page()) return  $output;

}

// Add the shortcode to WordPress. 
add_shortcode('userlisting', 'sul_user_listing');
?>

Breaking Down The Code

The top of our plugin’s main PHP file must contain the standard header of information. This header tells WordPress that our plugin exists, and it adds it to the plugin management screen so that it can be activated, loaded and run.

/*
Plugin Name: Simple User Listing
Plugin URI: http://cozmoslabs.com
Description: Create a simple shortcode to list our WordPress users.
Author: Cristian Antohe
Version: 0.1
Author URI: http://cozmoslabs.com
*/

Creating a Shortcode

Adding a new shortcode in WordPress is rather easy. We find the function that returns the desired output (in our case, sul_user_listing), and then we add it using the add_shortcode WordPress function.

function sul_user_listing($atts, $content = null) {
// return our output
}
add_shortcode('userlisting', 'sul_user_listing');

Extracting Our Shortcode Arguments

We want to be able to list users based on their roles and to control how many users are displayed on the page. We do this through shortcode arguments. We’ll add the shortcode to our theme in this way: [userlisting role="author" number="15"]. This will allow us to reuse the plugin to list our subscribers as well.

To do this, we need to use shortcode arguments:

extract(shortcode_atts(array(
	"role" => '',
	"number" => '10'
), $atts));

The extract function imports variables into our function from an array. The WordPress function shortcode_atts basically returns an array with our arguments; and we’ll set up some defaults in case none are found.

Note that the role default is an empty string, which would list all users regardless of their role.

Shortcodes Should Never Echo Stuff Out

The return value of a shortcode handler function gets inserted into the post content’s output in place of the shortcode. You should use return and not echo; anything that is echoed will be outputted to the browser but will probably appear above everything else. You would also probably get “headers already sent� type of errors.

For simplicity, we’re buffering the output through ob_start(), so we put everything into an object and return it once we’re done.

Setting Up Our Variables

Now we can start building our listing of authors. First, we need to set up a few variables:

  • $search
    This takes the GET parameter as if it exists.
  • $page
    The get_query_var for the pagination. This already exists in WordPress.
  • $offset
    Calculate the offset (i.e. how many users to skip when paginating).
  • $total_authors
    Get the total number of authors.
  • $total_pages
    Calculate the total number of pages for the pagination.

The Query

We actually have two queries: the default listing and the search results.

if ($search){
	// Generate the query based on search field
	$my_users = new WP_User_Query( 
		array( 
			'role' => $role, 
			'search' => '*' . $search . '*' 
		));
} else {
	// Generate the query 
	$my_users = new WP_User_Query( 
		array( 
			'role' => 'author', 
			'offset' => $offset ,
			'number' => $number
		));
}

WP_User_Query->total_users and WP_User_Query->get_results

WP_User_Query provides us with two useful functions, among others:

  • total_users
    Returns the total number of authors. This, the offset and the number of users per page will generate our pagination.
  • get_results
    Returns an object with the authors alone. This is similar to what get_users() returns.

The Search Form

For the search, we’re using a simple form. There’s nothing complex here.

<div class="author-search">
<h2>Search authors by name</h2>
	<form method="get" id="sul-searchform" action="<?php the_permalink() ?>">
		<label for="as" class="assistive-text">Search</label>
		<input type="text" class="field" name="as" id="s" placeholder="Search Authors" />
		<input type="submit" class="submit" name="submit" id="searchsubmit" value="Search Authors" />
	</form>
<?php 
if($search){ ?>
	<h2 >Search Results for: <em><?php echo $search; ?></em></h2>
	<a href="<?php the_permalink(); ?>">Back To Author Listing</a>
<?php } ?>

</div><!-- .author-search -->

User Data and Listing the Authors

Looping through our results is fairly simple. However, getting information about users is a bit confusing in WordPress. You see, there are a lot of ways to get user data. We could get it directly from the returned query; we could use general functions such as get_userdata, get_user_meta, the_author_meta and get_the_author_meta; or we could even use dedicated functions such as the_author_link and the_author_posts.

We’ll just use get_userdata plus two other functions: get_author_posts_url and get_avatar.

<?php if (!empty($authors))	 { ?>
	<ul class="author-list">
<?php
	// loop through each author
	foreach($authors as $author){
		$author_info = get_userdata($author->ID);
		?>
		<li>
			<?php echo get_avatar( $author->ID, 90 ); ?> 
			<h2><a href="<?php echo get_author_posts_url($author->ID); ?>"><?php echo $author_info->display_name; ?></a> - <?php echo count_user_posts( $author->ID ); ?> posts</h2>
			<p><?php echo $author_info->description; ?></p>
			<?php $latest_post = new WP_Query( "author=$author->ID&post_count=1" ); 
			if (!empty($latest_post->post)){ ?>
			<p><strong>Latest Article:</strong>
			<a href="<?php echo get_permalink($latest_post->post->ID) ?>">
				<?php echo get_the_title($latest_post->post->ID) ;?>
			</a></p>
			<?php } //endif ?>
			<p><a href="<?php echo get_author_posts_url($author->ID); ?> ">Read <?php echo $author_info->display_name; ?> posts</a></p>
		</li>
		<?php
	}
?>
	</ul> <!-- .author-list -->
<?php } else { ?>
	<h2>No authors found</h2>
<? } //endif ?>

Pagination

We need pagination because each listing will generate two extra queries. So, if we were listing 100 people, we would end up with 200 extra queries per page. That’s a bit much, so pagination is really needed. Otherwise, for websites with many authors, the load could get so heavy that it brings down the website.

<nav id="nav-single" style="clear:both; float:none; margin-top:20px;">
	<h3 class="assistive-text">Post navigation</h3>
	<?php if ($page != 1) { ?>
		<span class="nav-previous"><a rel="prev" href="<?php the_permalink() ?>page/<?php echo $page - 1; ?>/"><span class="meta-nav">�</span> Previous</a></span>
	<?php } ?>
	
	<?php if ($page < $total_pages ) { ?>
		<span class="nav-next"><a rel="next" href="<?php the_permalink() ?>page/<?php echo $page + 1; ?>/">Next <span class="meta-nav">→</span></a></span>
	<?php } ?>
</nav>

Final Thoughts

We’ve discussed the code for an authors listing, but it has so many more uses:

  • List your company’s employees;
  • Showcase users who have won a competition (by listing users with the role of “winnersâ€�);
  • Present your company’s departments, each with its respective team (based on user roles).

If you allow users to register on your website, you could use more or less the same code to generate any listing of users based on your needs. If you require users to log in in order to comment (an effective way to stop automated spam), then listing users and their number of comments could increase engagement.

Have you used something similar for a project? If so, let us know in the comments!

(al)


© Cristian Antohe for Smashing Magazine, 2012.


An alternative to select elements as navigation in narrow viewports

A recurring problem when making sites fit in a narrow viewport is navigation. The most common approach on larger screens is to use a horizontal navigation for the top level items. Sometimes such menus are complicated/complemented by drop-downs listing sub-items, but I’ll leave that out of this post and focus on how to handle just the horizontal navigation bar.

Now, you could simply let the menu items wrap as they need to on small screens. In some cases that is a completely acceptable option, but often that can make the menu take up too much vertical space. One common design pattern (there are more, as evidenced by Brad Frost in Responsive Navigation Patterns) for avoiding that is to convert the navigation items into a select element on small screens. While doing so does save space and may initially feel like a smooth solution, there are a number of drawbacks, some of which Andy Clarke mentions in The select menu navigation pattern. I think there are better options.

I’ve always felt that using select elements for navigation is a bad idea, be it on the desktop, mobile, wide screens, or narrow screens. Form elements are simply not meant for navigation. So here is an alternative way of solving the problem.

Read full post

Posted in , , , .

Copyright © Roger Johansson


Sketching A New Mobile Web


  

The mobile Web has gotten a bum rap. It spends most of its time either in the shadow of the desktop or playing the role of the native app’s frumpy friend. Luckily, we’ve got the tools to change that. Progressive enhancement, mobile-first and responsive design can help lead us towards a more unified, future-friendly Web. That’s the good news. The bad news? These tools are worthless if you don’t have license to use them.

What’s holding us back, in many cases, is our clients and the conceptual models they cling to. If our clients are to embrace the potential of the mobile Web, then we need to get them thinking beyond desktops and apps.

The Promise Of The Mobile Web Is a Tough Sell

Let’s face it: designing responsively takes longer and costs more.

When we introduce different screen sizes, resolutions and device capabilities, there’s a lot more to design. We’ve got more layouts to wireframe, different gestural interactions to consider, and a broad range of functional capabilities to support. All of this packs on significant testing time as well. Still, time and expense can be justified, especially when compared to the cost of trying to retrofit device-specific optimizations onto your design. You can make rational arguments to justify longer timelines, and most companies can find additional resources when they want to. There’s an obstacle much bigger than time or cost: it’s the obstacle of change.

Change Is Hard

Changing the way we do things is hard. Breaking from convention is scary. As humans, we’re naturally averse to this. Saying, “Got no time, got no money� is much, much easier than investing in a forward-thinking strategy that requires a fundamental shift in our notion of what a website is. We’re battling against stereotypes that we’ve collectively created for the Web. Ask someone to envision a website, and they’ll picture a 960-pixel-wide layout, comfortably nested in their desktop browser window. Ask them to envision a mobile website, and they’re bound to think of apps. They’ll picture a simple task-based interface with limited content, minimal navigation and elegant transitions. Desktop and mobile: two entirely different beasts.

Fork in the road, desktop vs. mobile
We continue to fracture the Web every time we prompt users to choose a path: desktop or mobile website.

Expectations Are Project Baggage

We need to wean ourselves and our clients off the baggage that these expectations introduce into projects. We need to abandon outdated conventions. That’s easier said than done, so let’s attack the problem head on. Below, I’ll share the methods we use to change the way people think of the mobile Web; if you have other or different methods, let’s hear about them. How do we get ourselves and our clients to let go of the conceptual models they cling to?

Rational Appeal Is Effective (Until It’s Not)

Begin by creating a compelling business case for a more responsive approach to the Web. Bombard your stakeholders with mobile statistics, research and real use cases. If they seem to be hung up on creating mini-websites with arbitrary portions of content, then discuss the fragmentation of screen sizes. Focus specifically on that murky area between large smartphones and small tablets. Challenge them to define at exactly which screen size the interface should turn on its head and snatch the content from users’ reach. If you’re able to build a strong case, you should have a room full of people who see the light and are amenable to this new approach. Until they’re not… until later when they seem to have relapsed into their old ways. Rational arguments for adaptive design will get you only so far because:

  1. You are asking people to discard a conventional system that they’re familiar and comfortable with;
  2. The concept remains abstract, creating a gap between theory and reality.

If a client can’t envision how their website will adapt across a range of screen sizes, then they’ll have trouble committing to this approach. In the wake of uncertainty, people will retreat to the security of convention.

If you want to lead clients to a new way of thinking, collaborative sketching can help shape the path.

The path to the unfamiliar seems treacherous
When guiding clients down an unconventional path, the first steps are always easy. How do you keep them moving forward, and stop them from turning back halfway?

Use Sketching as a Form of Exorcism

Expectations of a design start to form the moment team members begin to envision the project. As planning and discussion go on, the mental images that take shape become more defined. This can lead to situations in which you find yourself designing for what’s in the client’s head, instead of designing for the project’s goals and users’ needs. In order to get people to accept new ideas, you need to exorcise the old ones. This is where sketching comes in. We often think of sketching as a way to generate and communicate ideas, but we can also think of it as a weapon to dismantle them. The goal of sketching here isn’t to produce drawings that inform the final design. We are not replacing the UX process. The goal is to drive out those stubborn, thorny ideas and make room for new ones.

Sketching can be used as a tool to purge ideas and reconstruct them

Developing A Workshop Plan

The steps outlined below reflect our current process. Although each one has value independently, consider how they work in combination to guide the group’s thinking along an intended path. Try to continually approach the design from different angles, alternating between techniques that require the group to focus (convergent thinking) and those that require the group to explore (divergent thinking). As you do so, conflicting ideas may emerge. Embrace these points of dissonance, because they can be key to breaking stubborn mental models.

The current process of our design workshop is this:

  1. Set up, define objectives
    Prioritize the goals that everyone is working toward. Establish the rules and the criteria through which ideas will be discussed and evaluated.
  2. Stick-figure comic strips
    Set some context that exists beyond the screen. Give people a world to design within.
  3. Mobile-first
    Ask the group to focus on information hierarchy and user goals. Get the small-screen ideas (especially those thorny app-centered ones) out of people’s minds and onto paper.
  4. 6-up templates
    Introduce conflict. There is likely a gap between what the group just drew for mobile and what it’s been envisioning for the “desktop� website — explore these incongruities. Purge as many ideas as you can from the minds of the participants.
  5. Concept sketches
    Collaboratively reconstruct ideas into new models that work regardless of screen size or device.

Set Up

Define the website’s business objectives and users’ needs

Stakeholder group
Time: 30 to 60 minutes.

  1. Establish and prioritize objectives.
    Before any drawing happens, we try to set some parameters. We begin by establishing the website’s objectives, all of which we make sure can be tied back to the organization’s broader goals. Steering clear of anything that describes particular features or functionality is important. “Quick links� and “Rotating slideshow� are not objectives. We list as many objectives as we can on a whiteboard or large sheet of paper, assigning a priority to each one.
  2. Define audiences and user needs.
    Next to that, we create a new list of user needs. This information should really be drawn from actual user research and interviews. Worst case scenario, if you are not able to get any, you could draw on your clients’ understanding of the target audience and what they perceive their needs to be. Start by identifying the primary user group and listing the tasks they will need to complete on the website. If you’re having trouble coming up with a list of actionable tasks, think about questions these audience types might have when coming to the website. What is motivating them to come in the first place, and what information would be most valuable to them? After brainstorming the needs of your primary target audience, move on to any key secondary audiences.
  3. Brainstorm mobile opportunities.
    Now that you have created a list of website objectives and user needs, it’s time to start planting the mobile seed. When we approach this, our goal is to start shifting people away from the mindset that mobile needs to be an add-on or a website-lite experience. I’ll challenge the group to think about what opportunities are created when a user is not tethered to a desk. What if they’re on a couch, at work or standing around somewhere? How do the capabilities of different types of devices open up possibilities for interacting with content that didn’t exist before? The goal here is to generate a lot of different ideas, even if some of them are implausible. Get people pumped up by the possibility of adding to rather than subtracting from the website.

This exercise is not meant to be exhaustive, so we try not to spend more than an hour total on it.

Start Sketching

With the set-up out of the way, it’s time to start sketching. These sketching exercises seem to change a bit from time to time and depending on the dynamic and size of the group we’re working with. Counting people on both sides, we try to limit the workshops to around 10 people or just under. This allows everyone a chance to work individually, but the group is also big enough that you can break into small teams. The more clout the group has, the better. Sketches should be simple and, more importantly, fun. Which brings us to our first exercise: stick-figure comic strips.

Stick-Figure Comic Strips

Teams of two or three
Time: 30 minutes plus discussion.

Stick-figure comics are simple to do. Break your group into teams of two. Give each team a piece of paper filled with square panels, and ask them to draw a crude comic that depicts a member of the target audience coming to the website and ultimately completing a task. We used this technique most recently when working with Marian University in Wisconsin. To give our burgeoning comic artists a little more direction, we specified, “Begin your comic strip with a character who is representative of your target audience. Your character’s story does not begin on your website. Think of a place where the story begins. What motivates them to visit your website, and what actions do they take when they get there? What device are they using?�

In the university workshop, one team described the story of a teen who is attached to his friends and home town and doesn’t want to move away for school. He loves sports but doesn’t quite have the level of talent to play at a larger university. He’s excited to see that this university offers sports and has great student residences. He’ll be able to experience campus life while being just a short drive from home. The sketches showed the protagonist coming to the website with a purpose and interacting with different pages.

Examples of comics as a form of storytelling
Drawing comics can be a fun way to imagine new use cases, whimsical though they may be.

These storyboard-type comics are great because they make people turn lists of needs and objectives into narratives. Layers of abstraction peel away as participants relate detailed accounts of how they envision individuals using the website. This also moves conversation in the right direction, getting your stakeholders excited about how the website plays a role that extends beyond the screen and into people’s lives.

3-Up Mobile-First Templates

Solo sketching
Time: 30 minutes plus discussion.

We’ve got people thinking in the right direction: stories about people using the website. Then we’ll start to focus on the website’s interface. I’ll point to the whiteboard, filled with scribbles and notes about users and objectives, and remark that including all of that on one page wouldn’t work. After a brief refresher on the mobile-first approach, we hand out 3-up mobile templates to every person in the room and then establish which key page(s) to focus on. The challenge for this exercise is to “Assume that your user is using a device with a small screen. There is not a lot of room for complex interactivity, and you have limited space to present your content. What do you show on this page? Focus on the priority of content and the actions you want to encourage.�

With this and the other sketching exercises, keep everyone focused on the adaptability of the content, not the container.

Whereas the brainstorming and storyboards encouraged everyone to think big and to explore a wide range of ideas, this exercise is designed to rein in those ideas. The narrow page templates require people to focus and draw only the most important ideas and page elements. Many of the sketches will still look like apps at this point. This is a natural starting point and to be expected. Once sketching is complete, ask each participant to explain their ideas to the rest of the group.

3-up mobile template
Mobile templates challenge participants to focus on important content and actions.

6-Up Responsive Templates

Solo sketch
Time: 30 minutes (no discussion)

If we could get through the entire sketching and design process without relapsing to age-old conventions, that would be great. But although we’ve come up with a lot of new ideas so far, we haven’t really done anything to get rid of those sleeper agents — those notions of “what a website should be� ingrained so deeply that they are bound to reemerge.

In the 6-up sketching exercise, we’ll ask each team member to take their original ideas from the 3-up mobile sketches and think about how to adapt them to different screen sizes. If new page elements are introduced, they should be justifiable and tie directly back to the user goals or website objectives established earlier. We’ve modified the traditional 6-up exercise slightly so that there’s an inconsistency between the proportions of the six panels; the boxes are still small, so that drawings stay crude. What I like about this exercise is that it encourages participants to move beyond their initial ideas and grasp for new ones. This is where you’ll see people desperately try to work in some sort of horizontal navigation bar or sliding image rotator. They are trying to reconcile their impulse to include these standard elements with the goals and stories that the group has already worked on. Of all the exercises, this one seems to give people the most challenge.

6-up template
The 6-up template encourages people to move beyond their initial ideas and push for new ones. It can get pretty messy.

About 10 minutes in, after most people have sketched the low-hanging fruit ideas, I’ll often walk around and hand out Mental Notes (see below) to inspire participants to begin thinking about intent and the behavior they would like to encourage. When the sketching time is complete, we move directly into the concept sketches, without any group discussion.

1-Up Concept Sketches

Teams of two or three
Time: 30 minutes plus discussion.

If the exercises have gone well so far, people will be in a state of utter confusion. The website they were originally able to picture so clearly should now be a big cloudy mess — and that’s great! This is right where you want them. It’s like the part of spring cleaning when the house is messier than it was to begin with. In the wake of this confusion, you can begin to rebuild. Get people back into teams and have them work together on each other’s ideas. Have each team develop a single concept that represents an adaptive solution. When finished, post a large blank sheet of paper on the wall and have each team pin their drawings to it and present their concept to the group. Ask them to describe the evolution of their design. Walk through your own as well, which ideally will have also evolved beyond your original ideas. Use the paper backdrop to add notes about which ideas resonate with people or to flag parts that might require rethinking. You can then roll up the whole sketchboard and bring it back to your team.

Concept sketches
Concept sketches should reflect an evolution in thinking as the initial 3-up mobile sketches are adapted and modified to take into account different-sized canvases.

Tips for Group Sketching

  • Pack a bag with pens, markers, pencils, paper and any other supplies you might need.
  • Show examples of everything.
  • If you are a Picasso, then intentionally drawing crudely might not be a bad idea. Make people feel like they can do it just as well.
  • Play music, because silence is awkward and it shouldn’t feel like your conducting a test. Chutes Too Narrow by The Shins and The Kinks are the Village Green Preservation Society are two pretty solid go-to albums.
  • Introduce Mental Notes. I like to allow people to draw from a deck of Mental Notes and promise “prizes and gloryâ€� to people who can incorporate the given principles into their design.
  • No sketch is bad. The quality of the drawing doesn’t matter — drawing is thinking. Praise ideas and encourage exploration.
  • When forming teams, don’t pair up Bert and Ernie; they will only enable each other. Pair up people who don’t typically work side by side.
  • Some people won’t want to participate in the drawing. Offer to draw for them, or let them just participate in the dialogue.
  • Minimize the amount of time that elapses between sketching and delivering wireframes, designs or whatever is next in your process. The longer the span of time, the more time it gives for people to relapse.

Finishing Up

By the end of the workshop, everyone will feel creatively exhausted, every possible idea drained out of them. The concepts presented at the end of the day will lack the stamp of individual ownership, since everyone has had a hand in shaping them. While these sketches might not directly inform the final design, people will know that they’ve been able to contribute. More importantly, you’ll have removed the layers of abstraction that surround adaptive, device-agnostic solutions. Something that was once hard to envision has now been made much more attainable. You’ve hopefully also purged those thorny ideas buried in your clients’ heads that seem to resurface at the most inopportune moments. Collaborative sketching can help people make the leap to understanding the real potential of mobile to extend, not limit, how we interact with the Web. Fueled by possibility, they might even become advocates for more future-friendly approaches in their organizations. If you’ve ever been crushed by seeing a project not live up to its potential, you’ll recognize the importance of this.

There is no secret way to change what people believe or to overcome the conceptual models they cling to. We’ll always battle against stubborn personalities and decisions that seem to be driven by fear rather than strategy. Hopefully, you’ll find that incorporating collaborative sketching workshops into your client work helps you win more battles and build a more accessible Web. What techniques do you use?

Resources

(al)


© Dennis Kardys for Smashing Magazine, 2012.


Smashing Daily #18: Hiring, Detecting, Singing


  

Here’s episode #18 of The Smashing Daily, with the question if designers must know how to code, an in-depth look at type classification, lots of great stuff about Responsive Design, things about content and much more. Enjoy!

“We don’t hire designers who can’t code�
Many developers think that designers should be able to code, but most designers think that’s not necessary. Here’s a very interesting article by Roger Davis about this subject. Interesting, because Roger has been working in an environment that forced him to code a long time ago, so he knows what it means to both design and code. A great read for designers and developers.

Should designers code?

“Adactio: Journal—Responsive questionsâ€�
A while ago Jeremy Keith was interviewed about Responsive Design. It turned out to be a very interesting read, with good questions and good answers, too. I liked Jeremy’s answer about the fact that it took so long to finally start using fluid layouts: “While media queries are a relatively recent innovation, we’ve always had the ability to create fluid layouts. And yet Web designers and developers have willfully ignored that fact, choosing instead to create un-webby fixed-width layouts.” Exactly my thoughts. You should read this interview, it’s really good!

“Type classifications are useful, but the common ones are not�
For anyone who has ever tried to manage a large type library: how do you do that? How do you classify all those different types? In this article Indra Kupferschmid looks at the history of type classification and at current models, proposing some new ways to approach them. A long, very well researched article, and a great read!

“A New Take on Responsive Tables�
Tables are extremely hard to get right on small screens. Several possible solutions have been created, and here’s a new one which uses a fixed left header and a scrollable table body. The only issue with this solution is that it doesn’t work on a large portion of the current phones out there.

A responsive tables solution

“Taking “Content First� Very Seriously�
When Cloudfour decided to redesign their website they decided to take a “Content First” approach. Lyza Gardner wrote this post about the process and about the things they found out while building the website.

“What’s the greater fear for publishers: Amazon or piracy?�
Book publishers have been looking at the wrong enemy for too long: they always thought piracy would be a problem for eBooks, so they embraced eBook formats that support DRM. It turns out that the biggest book seller (who also has its own eBook format), has turned into the biggest enemy.

“Using Modernizr to detect HTML5 features and provide fallbacks�
One of the most interesting things about Web development (but also one of the more complex things) is the fact that you can create fallbacks for older browsers. One great tool that can help you out in making these fallbacks is Modernizr. Tom Leadbetter wrote this in depth article about how it works and about what you can do with it. I highly recommend reading it, it’s a great tool and a great article.

Modernizr

Last Click

“Like A Rounded Corner (Bruce and The Standardettes)�
For all you webstandards nerds and CSS3 designers out there, here’s the brilliant song Like A Rounded Corner by Bruce Lawson and The Standardettes. I laughed out loud at “styelsheet masturbation has replaced my imagination” and at “HTML5, so it is iOs ready for you”. Hilarious.

Hahaha

Previous Issues

For previous Smashing Daily issues, check out the Smashing Daily Archive.


© Vasilis van Gemert for Smashing Magazine, 2012.


Design Patterns: When Breaking The Rules Is OK


  

We’d like to believe that we use established design patterns for common elements on the Web. We know what buttons should look like, how they should behave and how to design the Web forms that rely on those buttons.

And yet, broken forms, buttons that look nothing like buttons, confusing navigation elements and more are rampant on the Web. It’s a boulevard of broken patterns out there.

This got me thinking about the history and purpose of design patterns and when they should and should not be used. Most interestingly, I started wondering when breaking a pattern in favor of something different or better might actually be OK. We all recognize and are quick to call out when patterns are misused. But are there circumstances in which breaking the rules is OK? To answer this question properly, let’s go back to the beginning.

The History of Design Patterns

In 1977, the architect Christopher Alexander cowrote a book named A Pattern Language: Towns, Buildings, Construction, introducing the concept of pattern language as “a structured method of describing good design practices within a field of expertise.â€� The goal of the book was to give ordinary people — not just architects and governments — a blueprint for improving their own towns and communities. In Alexander’s own words:

At the core… is the idea that people should design for themselves their own houses, streets and communities. This idea… comes simply from the observation that most of the wonderful places of the world were not made by architects but by the people.

Street cafe
Street cafe in San Diego (Image credit: shanputnam)

A pattern — whether in architecture, Web design or another field — always has two components: first, it describes a common problem; secondly, it offers a standard solution to that problem. For example, pattern 88 in A Pattern Language deals with the problem of identity and how public places can be introduced to encourage mixing in public. One of the proposed solutions is street cafes:

The street cafe provides a unique setting, special to cities: a place where people can sit lazily, legitimately, be on view, and watch the world go by. Therefore: encourage local cafes to spring up in each neighborhood. Make them intimate places, with several rooms, open to a busy path, where people can sit with coffee or a drink and watch the world go by. Build the front of the cafe so that a set of tables stretch out of the cafe, right into the street. The most humane cities are always full of street cafes.

For those interested in going further down the pattern 88 rabbit hole, there is even a Flickr group dedicated to examples of this pattern.

The jump from architecture to the Web was quite natural because the situation is similar: we have many common interaction problems that deserve standard solutions. One such example is Yahoo’s “Navigation Tabs� pattern. The problem:

The user needs to navigate through a site to locate content and features and have clear indication of their current location in the site.

And the solution:

Presenting a persistent single-line row of tabs in a horizontal bar below the site branding and header is a way to provide a high level navigation for the website when the number of categories is not likely to change often. The element should span across the entire width of the page using limited as well as short and predictable titles with the current selected tab clearly highlighted to maintain the metaphor of file folders.

This is all very nice, but we need to dig deeper to understand the benefits of using such a pattern in digital product design.

The Benefits Of Design Patterns

Patterns are particularly useful in design for two main reasons:

  • Patterns save time because we don’t have to solve a problem that’s already been solved. If done right, we can apply the principles behind each pattern to solve other common design problems.
  • Patterns make the Web easier to use because, as adoption increases among designers, users get used to how things work, which in turn reduces their cognitive load when encountering common design elements. To put it in academic terms, when patterns reach high adoption rates, they become mental models — sets of beliefs in the user’s mind about how a system should work.

Perhaps the strongest case for using existing design patterns instead of making up new ones comes (once again) from architecture. In the article “The Value of Unoriginality,� Dmitri Fadeyev quotes Owen Jones, an architect and influential design theorist of the 19th century, from his book The Grammar of Ornament:

To attempt to build up theories of art, or to form a style, independently of the past, would be an act of supreme folly. It would be at once to reject the experiences and accumulated knowledge of thousands of years. On the contrary, we should regard as our inheritance all the successful labours of the past, not blindly following them, but employing them simply as guides to find the true path.

That last sentence is key. Patterns aren’t excuses to blindly copy what others have done, but they do provide blueprints for design that can be extremely useful to designers and users. And so we do need to stand on the shoulders of designers who have come before us — for the good of the Web and users’ sanity. Many have tried to document the most common Web design patterns, with varying levels of success. In addition to the Yahoo Design Pattern Library, there’s Peter Morville’s Design Patterns, Welie.com and, my personal favorite, UI-Patterns.com.

When Patterns Attack

Here’s the “but� to everything we’ve discussed up to now. There is a dark side to patterns that we don’t talk about enough. One doesn’t simply copy a pattern library from a bunch of random places, put it on an internal wiki and then wait for the magic to happen. Integrating and maintaining an internal design pattern library is hard work, and if we don’t take this work seriously, bad things will happen. Stephen Turbek sums up the main issues with pattern libraries in his article “Are Design Patterns an Anti-Pattern?�:

  • Design patterns are not effective training tools.
  • Design patterns don’t replace UX expertise.
  • Completeness and learn-ability are in conflict.
  • Design patterns take a lot of investment.
  • Design patterns should help non–UX people first.

This article isn’t meant to discuss these issues in detail, so I highly recommend reading Turbek’s post.

For the purpose of this article, let’s assume we’ve done everything right. We have a published and well-known pattern library that enjoys wide adoption within our organization. We treat the libraries as guidelines and blueprints, not laws to be followed without thinking about the problem at hand. The question I’m particularly interested in is, when is it OK to break a widely adopted design pattern and guide users to adopt a new way of solving a problem?

When We Attack Patterns

Despite all of their benefits, most of the Web seems to have little respect for patterns. The most glaring examples of broken design patterns are found in Web forms. Based on years of research, we know how to design usable forms. From Luke Wroblewski’s book Web Form Design to countless articles on things like multiple-column layouts and positioning of labels, we don’t have to guess any more. The patterns are there, and they’re well established. And yet, we see so many barely usable forms online.

As an example of a broken form pattern, look at the registration form for Expotel below:

Notice the small input fields; the left-aligned labels, with the miles of space between them and the input fields; the placement and design of the “Close� and “Register� buttons, which actually emphasize “Close� more. Oh, and what is a “Welcome Message�? Where will it be used? We can all agree that this is not good form design and is not a good way to break a pattern.

But passing judgment on a broken pattern is not always as easy as it is with the example above. Google’s recent decision to remove the “+� from the button to open a new tab in Chrome came under a bit of fire recently. It breaks a pattern that has been included in most browsers that have tab-based browsing as a feature, and yet Google claims that it did user research before making this change. Was this the right decision?

Google New Tab

And then there are UIs that we might not know what to make of. iOS apps such as Clear and Path introduce new interactions that we haven’t seen before — to much praise as well as negative feedback. A step forward in design or failed experiments?

As with most design decisions, the answers are rarely clear or black and white. A tension exists between patterns and new solutions that cannot be resolved with a formula. Users are familiar with the established way of doing things, yet a new solution to the problem might be better and even more natural and logical. So, when is changing something familiar to something different OK? There are two scenarios in which we should consider breaking a design pattern.

The New Way Empirically Improves Usability

One of the dangers of iterating on an existing design is what is known as the “local maximum.� As Joshua Porter explains:

The local maximum is a point at which you’ve hit the limit of the current design… It is as effective as it’s ever going to be in its current incarnation. Even if you make 100 tweaks, you can only get so much improvement; it is as effective as it’s ever going to be on its current structural foundation.

With patterns, it could happen that we continue to improve an existing solution even while a better one exists. This is one of the pitfalls of A/B testing: it does a great job of finding the local maximum, but not for finding those new and innovative solutions.

We gain much from incremental innovation, but sometimes a pattern is ripe for radical innovation. We need to go into every design problem with our eyes wide open, eager to find new solutions, and ready to test those solutions to make sure that we’re not following bad intuition. As Paul Scrivens points out in “Designing Ideas�:

You will never be first with a new idea. You will be first with a new way to present the idea or a new way to combine that idea with another. Ideas are nothing more than mashups of the past. Once you can embrace that, your imagination opens up a bit more and you start to look elsewhere for inspiration.

This is what the Chromium team claims to have done with the “+� button in Chrome. It believes it has found a better solution, and it’s tested it.

The Established Way Becomes Outdated

Think of the icon for the “save� action in most applications. When was the last time you saw a floppy drive? Exactly. Sometimes the world shifts beneath us, and we have to adjust. Failing to do so, we could get stuck in dangerous ruts, as Twyla Tharp attests (quoted by Yesenia Perez-Cruz):

More often than not, I’ve found a rut is the consequence of sticking to tried and tested methods that don’t take into account how you or the world has changed.

The publishing industry knows this better than most. Stewart Curry has this to say in “The Trope Must Die�:

Design patterns can be very useful, but when we’re making a big shift in media, they can sometimes hold progress back. If we look at the evolution of digital publications, it’s been a slow and steady movement from (in the most part) a printed page to reproducing that printed page on a digital device. It’s steady, linear, and not very imaginative, where “it worked in print, so it will work in digital� seems to be the mindset.

This is where the developers of apps such as Clear and Path are doing the bold, right thing. They realize that we’re at beginning of a period of rapid innovation in gesture-based interfaces, and they want to be at the forefront of that. Some ideas will fail and some will succeed, but it’s important that our design patterns respond to the new touch-based world we’re a part of.

Clear Todo App

Our design patterns have to adjust not only to a shift in our interaction metaphors, but to a significant shift in technology usage in general. Tammy Erickson did some research on what she calls the “Re-Generation� (i.e. post-Generation Y) and discusses some of her findings in “How Mobile Technologies Are Shaping a New Generation�:

Connectivity is the basic assumption and natural fabric of everyday life for the Re-Generation. Technology connections are how people meet, express ideas, define identities, and understand each other. Older generations have, for the most part, used technology to improve productivity — to do things we’ve always done, faster, easier, more cheaply. For the Re-Generation, being wired is a way of life.

Expectations of apps and services change when everything is always on and accessible. We become less tolerant of slow transitions and flows that are perceived to be too complex. We are being forced to rethink sign-up forms and payment flows in an environment where time and attention have become scarcer than ever. We don’t have to reinvent the wheel, but we do need to find better ways to keep it rolling.

The Informed Decision Is The Right Decision

Design patterns bring many benefits, as well as some drawbacks to watch out for. But we’d be foolish to ignore these helpful guidelines. There is no formula for what we need to do; rather, we need to operate within certain boundaries to ensure we’re creating great design solutions without alienating users. Here is what we need to do:

  • Study design patterns that are relevant to the applications we are working on. We need to know them by heart — and know why they exist — so that we can use them as loose blueprints for our own work.
  • Approach each new project with a mind open enough to discover better ways to solve recurring problems.
  • Stay up to date on our industry (as well as adjacent ones) so that we recognize external changes that require us to rethink solutions that currently work quite well but might be outdated soon.

In short, we can neither follow nor ignore design patterns completely. Instead, we need a deep understanding of the rules of human-computer interaction, so that we know when breaking them is OK.

(al)


© Rian van der Merwe for Smashing Magazine, 2012.


  •   
  • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress