Tag: kranthi

PBS Off Book: The Art of Web Design

» PBS Off Book: The Art of Web Design

Whitney Hess, Jason Santa Maria and Jeffrey Zeldman discuss the past two decades of design history.


Talks To Help You Become A Better Front-End Engineer In 2013


  

Many of us care deeply about developing our craft. But staying up to date can be a true challenge, because the quantity of fresh information we’re regularly exposed to can be a lot to take in. 2012 has been no exception, with a wealth of evolution and refinement going on in the front end.

Great strides have been made in how we approach workflow, use abstractions, appreciate code quality and tackle the measurement and betterment of performance. If you’ve been busy and haven’t had time to catch up on the latest developments in these areas, don’t worry.

With the holiday season upon us and a little more time on our hands, I thought it would be useful to share a carefully curated list of the most relevant front-end talks I’ve found helpful this year. You certainly don’t have to read through them all, but the advice shared in them will equip you with the knowledge needed to go into the new year as a better front-end engineer.

Screenshot
Image credit: Jacob Bøtter

Baseline

Have a Strategy for Staying Up to Date

How to Stay Up to Date on Web Stuff, Chris Coyier

Part of continually developing your craft is staying up to date. Doing this is important for all professionals, and in this talk you’ll learn strategies for staying updated even when the ideas that surround the technologies we use are constantly evolving.

Screenshot

Make Sure Your Baseline for Development Is Current

A New Baseline for Front-End Developers, Rebecca Murphey

There was a time when editing files, testing them locally and simply FTP’ing them was the common workflow for a front-end developer. We would measure our abilities based on how well we could harass IE 6 into rendering pages correctly, and we generally lacked strong skills in HTML, CSS and JavaScript.

This has greatly changed over the past few years, with improvements in workflow and tooling. Front-end development is now taken more seriously, and this talk sheds light on the new baseline process for developing on the front end.

Screenshot

Understand How Browsers Work Behind the Scenes

So, You Want to Be a Front-End Engineer, David Mosher (Video)

Some would say that the browser is the most volatile development platform the world has ever known. If you’re a client-side developer, understanding how browser internals work can help you both make better decisions and appreciate the justifications behind many development best practices. In one of the best talks this year, David Mosher takes you through how browsers parse and render your pages.

Screenshot

Know What the Web Platform Now Has to Offer

The Web Can Do That!?, Eric Bidelman (Video)

The Web is constantly evolving, and keeping up with what’s new on the platform can be hard. HTML5’s new capabilities enable us to build an entirely new suite of applications with features that were simply impossible to achieve before (at least, not without the use of plugins) but are now a reality.

In this talk, my teammate Eric guides you through the bleeding edge of HTML5, focusing on solving many real-world problems. You’ll learn about media streaming, device input, modern CSS design, media capture, file I/O and more.

Screenshot

Workflow

For Web App Developers

Tooling for the Modern Web App Developer, Addy Osmani

Whether you’re using JavaScript or CoffeeScript, LESS or Sass, building an awesome Web application these days usually requires a plethora of boilerplates, frameworks and tools and a lot of glue to get them to work together. In short, you need a kick-ass utility belt.

In this talk, you’ll get an overview of the current tooling eco-system for the front-end and learn about a new tool that tries to bring together all of the pieces of this eco-system for you, called Yeoman.

Screenshot

An extended version of this talk is also available.

For Web Designers

A Modern Web Designer’s Workflow, Chris Coyier (Video)

A lot is expected from today’s Web designers. If this role defines what you do, then it’s now not just about visual design, but increasingly about building interactions. Designs need to work across different devices of varying shapes, sizes and connections, and they also need to be accessible.

As a designer, you often need to communicate and share code across teams and be familiar with many different technologies. In this talk, Chris Coyier discusses many of the amazing tools that can help things along, discussing what does what and giving a high-level view of a modern workflow.

Screenshot

For Mobile Web Developers

Mobile Web Developers Toolbelt, Pete Le Page (Video)

Building for the mobile Web requires a different mindset to the one we use when developing for desktop, and a different set of tools. Thankfully, a number of great options are available. From remote debugging to emulation, mobile browsers are offering more and more tools to make our lives easier.

In this talk, Pete Le Page takes you through a couple of tools that you can use today to make cross-platform mobile Web development easier, and then he peers into the crystal ball to see what tools the future may bring.

Screenshot

For Debugging

Secrets of the Chrome DevTools, Patrick Dubroy (Video)

Google Chrome Developer Tools provide powerful ways to understand, debug and profile Web applications. Most developers are familiar with Chrome’s basic inspection and debugging tools, but some of its most valuable features, like the Timeline and memory analysis tools, are less known.

In his demo-based walkthrough, Patrick Dubroy provides an overview of Chrome Developer Tools and an in-depth demonstration of some lesser-known features.

Screenshot

The Future

CSS

The CSS of Tomorrow, Peter Gasston

In this talk, Peter looks briefly at the state of CSS3: what you can do right now, and what you’ll be able to do in the very near future. He then looks into the long-term future, to a time when CSS3 will make possible page layouts far richer and more dynamic than we’d thought possible, and when CSS3 has taken on aspects of programming languages. This is effectively what CSS developers will be learning years from now.

Screenshot

JavaScript

The Future of JavaScript, Dave Herman

The Web platform is growing, and JavaScript is growing along with it. EcmaScript 6, the next edition of the JavaScript standard, is gearing up to be a huge step forward for Web programming. In this talk, Dave Herman discusses the exciting new features being worked on for EcmaScript 6 and how they can be used.

Screenshot

Web Applications

Web Components and the Future of Web App Development, Eric Bidelman

Web components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit together?

This talk prepares you for the future of the Web platform by discussing the fundamentals of Web components and how we can use them today with frameworks such as AngularJS.

Screenshot

CSS

State of the Art

All the New CSS Hawtness, Darcy Clarke

This talk dives into some of the latest CSS implementations and specifications floating around. You’ll learn what’s here and what’s around the corner, and you’ll gain insight into why these new features will change our development workflow.

Darcy Clarke touches on modules such as paged-media, multi-columns, flex-box, filters, regions, box-sizing, masking and 3D.

Screenshot

Modularity

Your CSS Is a Mess, Jonathan Snook

We all think that CSS is easy. Take some selectors, add some properties, maybe a dash of media queries, and — presto! — you have a beautiful website. And yet, as the project changes and the team grows, we see the frustration build, with increasingly complex selectors and overuse of !important.

In this talk, Jonathan looks at common problems and solutions that will make your CSS (and your projects) easier to manage and easier to scale.

Screenshot

Pre-Processors

CSS Pre-Processors, Bermon Painter

If you haven’t jumped on the pre-processor train this year, you’re missing out. In this helpful overview of (current) popular pre-processors, Bermon Painter takes you through Stylus, LESS and Sass, with features subdivided into easy-to-learn sections of beginner, intermediate and advanced. I’ve been using mixins quite heavily this year, and I simply wouldn’t have been able to if it weren’t for projects like Sass.

Screenshot

Documentation

A Better Future With KSS, Kyle Neath

Writing maintainable CSS within a team is one of those problems that a lot of people think can be solved by writing CSS in a particular style. But in Kyle’s experience, that never works out.

In this talk, he introduces you to his latest creation, KSS. It’s a documentation and style guide format. He’ll show you why he built KSS and how it’s been helping him at GitHub to refactor its four-and-a-half year old CSS, and he’ll give you a glimpse into the future of KSS.

Screenshot

JavaScript

The Importance of Code Style

Maintainable JavaScript, Nicholas Zakas

Some say that good code is its own documentation, and the fact is that the more readable our code is, the easier it is to maintain.

Writing JavaScript for fun and writing it professionally are two different things, and in this talk by Zakas, you’ll learn practices to make JavaScript maintainable over the long run, to reduce errors and to make your code easily adaptable to future changes. It’s highly recommended reading.

Screenshot

A Modern Large-Scale App Stack

SoundCloud’s Stack, Nick Fisher

I’ve talked a lot about large-scale development in the past. It’s a non-trivial problem that’s difficult to get right, and so it’s exciting when someone working on such challenges shares their experience.

In this talk, Nick Fisher of SoundCloud discusses the company’s story of developing large-scale applications with JavaScript, not only at runtime, but also its steps to make development and deployment easier. In particular, he looks at RequireJS and Backbone, talking about how SoundCloud has used and abused each to suit its needs, sometimes in uncommon ways.

Screenshot

Rethinking Application Structure

Re-Imagining the Browser With AngularJS, Igor Minar

What if you could a write modern Web app with dramatically fewer lines of code and improve its readability and expressiveness at the same time? In case you’re wondering: no, there’s no new language to learn, just familiar old HTML and JavaScript. As a matter of fact, there are concepts for you to unlearn.

AngularJS is a client-side JavaScript Web development framework whose authors believe they’ve done something special. Instead of asking what kind of functions they could provide to make writing apps smoother, they asked, “What if the browser worked differently in a way that eliminates code and gives structure to apps?�

In this talk, you’ll get a tour of how to get the power of tomorrow’s Web platform in today’s Web applications.

Screenshot

Internationalization and i18n

Entschuldigen you, parlez vouz JavaScript, Sebastian Golasch (Video)

While JavaScript applications grow in size and complexity, there are still some white spots on the big map of Web applications: internationalization and globalization! If you´re still thinking that switching strings in and out is the way to go, you are definitely headed in the wrong direction.

In this talk, Sebastian takes you through how to spot real-world internationalization problems and how to solve them in the most elegant way.

Screenshot

I couldn’t cover internationalization without mentioning Alex Sexton, who has also spoken a great deal on this topic. His JSConf talk on client-side internationalization is available in video form if you’re interested in checking it out.

Patterns and Principles

The Plight of Pinocchio, Brandon Keepers

JavaScript is no longer a toy language, and many of our Web applications can’t function without it. Brandon states that if we are going to use JavaScript to do real things, then we need to treat it like a real language, adopting the same practices that we use with real languages. I completely agree with him.

This framework-agnostic talk takes a serious look at how we develop JavaScript applications in the real world. Despite their prototypical nature, good object-oriented programming principles are still relevant. The design patterns that we’ve grown to know and love work just as well in JavaScript as they do in any other language.

Screenshot

When to Lazy Load Scripts

How Late Is Later?, Massimiliano Marcon

Reducing the loading time of a Web application is a well-known challenge. Developers need to make sure that the browser downloads only the code that is strictly necessary to bootstrap the application, and leave the rest for later. This is what we commonly call “lazy loading.�

But when is “laterâ€�? When is the right time to lazy load? This talk shows how JavaScript code — functions and objects — can be delivered to the browser on demand, thus reducing the perceived loading time of a Web application.

Screenshot

Mobile

Building Touch-Based Interfaces

Creating Responsive HTML5 Touch Interfaces, Stephen Woods (Video | Audio)

Flickr front-end engineer Stephen Woods shares some hard-learned lessons about building responsive touch-based interfaces using HTML5 and CSS. Because our users are demanding better instant feedback from touch-based UIs, understanding how to approach this problem and avoid the pitfalls will be critical for many application developers in the future.

Screenshot

The Challenge With Scrolling

Embracing Touch: Cross-Platform Scrolling, Mark Dalgleish (Video)

Scrolling effects are a popular way to add personality to the simple act of moving down the page. Unfortunately, these effects don’t work natively on mobile devices, where the touch interaction would make these techniques more effective. In this talk, Mark looks at some ways to implement these effects within the limitations of mobile browsers.

Screenshot

Native, HTML5 and Hybrid Apps

Native, HTML5 and Hybrid Mobile Development, Eran Zinman

One of the toughest decisions every mobile developer faces is choosing a development strategy: “Should I develop a native, HTML5 or hybrid mobile app?� Over the past two years, Eran has led Conduit’s mobile client development efforts, experimenting with cross-platform development in various flavors: from complete HTML5 solutions (using PhoneGap and other technologies) to hybrid solutions to semi-hybrid solutions to fully native solutions.

In this talk, Eran shares some real-life experiences in cross-platform development, describing changes that Conduit has implemented along the way, and sharing what some of the “big players� (such as Facebook, LinkedIn and Twitter) are doing in their mobile app development.

Screenshot

Performance, Distribution and Facebook on HTML5

On the Future of Mobile Web Apps, Simon Cross

Simon looks at Facebook’s experience with and investment in the mobile Web, the issues affecting mobile Web developers and what Facebook and the industry are doing to push the mobile Web forward. Mark Zuckerberg’s comments on HTML5 were undoubtedly one of the most discussed topics in mobile this year, and I personally found these slides a good summary of Facebook’s current take on what works and what still requires improvement.

Screenshot

Tools for Mobile Debugging

Mobile Debugging, Remy Sharp

Debugging Web apps on mobile devices can be a genuine pain. Luckily, a number of tools are available today to ease the process. From remote debuggers to cross-device consoles, this talk summarizes the current state of debugging for mobile, going into more depth on debugging than Pete’s talk from earlier in the post.

Screenshot

Responsive Design Techniques

Responsive Web Design: Clever Tips and Techniques, Vitaly Friedman

Responsive Web design challenges designers to apply a new mindset to their design processes and to the techniques they use in design and coding. This talk (by Smashing Magazine’s own Vitaly Friedman) provides an overview of various practical techniques, tips and tricks that you might want to be aware of when working on a new responsive design project.

Screenshot

Web Apps

Offline Web Apps

Offline Rules, Andrew Betts (Video)

In the last couple of years, a deluge of new offline storage technologies have appeared. In this talk, Andrew looks at why they are all excellent and rubbish at the same time and why you need to use all of them, and he walks through techniques to consider when building a Web application that can load and function with no network connectivity.

But making use of client-side storage is necessary not only in order to make an app that works offline, but it can also hugely improve the experience of your website when the user actually does have connectivity.

Screenshot

State of the Art

Building Web Apps of the Future: Tomorrow, Today and Yesterday, Paul Kinlan (Audio)

The browser is an amazing runtime that can already deliver amazing apps. Paul dives into the technologies that will help you deliver Web apps that will blow your users’ socks off now and in the future.

Screenshot

Client-Side Storage

Storage in the Browser, Andrew Betts

Installed native applications can use all the space they want, but in the browser we’re much more limited. This talk explores how to make the best use of the storage technologies available to Web apps, comparing the virtues of different packaging and encoding techniques, and covering simple forms of in-browser compression that can yield surprising results.

As more apps are developed to surf over network turbulence, and to work even when completely disconnected from the network, local storage becomes ever more important.

Screenshot

Application Cache

Application Cache: Douchebag, Jake Archibald (Video)

The Application Cache is one of the cool bits of HTML5. It allows websites to work without a network connection, and it brings us much closer to native app-like behavior. However, from roundup articles and talks about HTML5, you might be left with the impression that it’s a magic bullet. Unfortunately, it isn’t; the Application Cache is, as Jake famously puts it, a douchebag.

In this talk, he looks at how to use the features of Application Cache without the horrible side effects, comparing techniques that you’d use for both a simple client-side app and a large content-driven website. He explores the many gotchas left out of most articles about Application Cache and discusses how to build your website to survive them.

Screenshot

Performance

CSS

High-Performance CSS, Paul Irish

Paul dives into the tools available in and outside of the browser to assess the performance of your CSS. Find out what’s slow (is box-shadow causing paints to be 70 milliseconds longer?) and how to fix it. Learn about about:tracing, CSS profiling and speed tracer, and get a better understanding of the browser’s internals in the process.

Screenshot

There’s also Jon Rohan’s talk about some problems related to CSS performance that were solved at GitHub. Recommended reading.

GitHub’s CSS Performance, Jon Rohan

Screenshot

Avoiding Jank

Jank-Free: In Pursuit of Smooth Web Apps, Tom Wiltzius

Building beautiful experiences on the mobile Web takes more than a good designer and fancy CSS: performance is critical for a Web app to feel fluid. Smooth animation that never drops a frame can give your app a native feel. But when animations stutter, effects lag or pages scroll slowly, we call that “jank.� This talk is about identifying jank and getting rid of it.

Screenshot

Web

Building Faster Websites, Ilya Grigorik

In this comprehensive crash course, Ilya Grigorik shares some really juicy tips on how to make the Web faster, including Google’s findings on what slows down people’s Web experience and how Chrome and other services have improved it. If you’re an engineer looking to improve the performance of your websites or apps, this talk comes highly recommended.

Screenshot

JavaScript

Breaking the JavaScript Speed Limit With V8, Daniel Clifford

Are you interested in making JavaScript run blazingly fast? If so, this talk looks at V8 under the hood to help you identify how to optimize your JavaScript. Daniel shows you how to leverage V8’s sampling profiler to eliminate performance bottlenecks and optimize JavaScript programs. He also exposes how V8 uses hidden classes and runtime-type feedback to generate efficient JIT code. A very interesting talk for performance junkies.

Screenshot

Note: Some of the optimizations mentioned in this talk are specific to V8 and may not apply to other JavaScript engines. I wrote about how to write memory-efficient JavaScript on Smashing Magazine recently, in case you’re interested in exploring the topic further.

Testing

Understanding Code Smells

Why Our Code Smells, Brandon Keepers (Video)

Odors exist for a reason, and they are usually trying to tell us something. If our code smells, it might be trying to tell us what is wrong.

Does a test case require an abundance of setting up? Maybe the code being tested is doing too much, or it is not isolated enough for the test? Does an object have an abundance of instance variables? Maybe it should be split into multiple objects? Is a view brittle? Maybe it is too tightly coupled to a model, or maybe the logic needs to be abstracted into an object that can be tested?

In this talk, Brandon walks through code from projects that he works on every day, looking for smells that indicate problems, understanding why the smells are there, what the smells are trying to tell us, and how to refactor them.

Screenshot

Current State of the Art

JavaScript Testing: The Holy Grail, Adam Hawkins (Video)

Adam talks about this Holy Grail for JavaScript developers: getting a test suite up and running fast and having multiple browsers execute the tests. Getting the Holy Grail is difficult, though, even though several tools have been created in the past in attempts to solve this problem.

Barriers to entries are everywhere. How easy is it to get going testing small parts of JavaScript functionality? What happens as your become bigger and more complex? What about headless testing? Does this process scale up to CI? Can you even do this stuff locally?

A myriad of testing tools and solutions are available, and Adam shows what’s out there and what we as a community need to do next to get the Holy Grail, to ensure a better Web experience for everyone.

Screenshot

Tip: One tool for testing that I’m loving at the moment is Testling-CI, which runs browser tests on every push.

Improving the Testability of Your Code

Writing Testable JavaScript, Rebecca Murphey (Audio)

It’s one thing to write the code that you need to write to get something working; quite another to write the code that you need to write to prove that it works — and to prove that it will continue to work as you refactor and add new features.

In her talk, Rebecca looks at what it means to write testable JavaScript code.

Screenshot

Conclusion

Time spent thinking about (and developing) your craft is time well spent. The more honed your skills are, the more opportunity you will have to become an efficient engineer.

While this list doesn’t cover every excellent talk presented this year, it hopefully offers some direction for you to accentuate your skills. Do consider reading through a few of them. Focused reading in this way will add to your value as a craftsperson and hopefully improve your daily development workflow.

With that, do enjoy the holiday season and have a fantastic new year.

(al)


© Addy Osmani for Smashing Magazine, 2012.


SEO Article Revisited: What The Heck Is SEO? A Rebuttal


  

This article is a collective reply of the active members of the SEO community to the article “The Inconvenient Truth About SEO” in which Paul Boag discusses the value of search engine optimization for website owners. Written and edited by Bill Slawski and Will Critchlow, this article explains what exactly “SEO” means today and discusses the common view many Web designers share about the work of SEO companies.—Ed.

When I [Bill Slawski] saw a link to a Smashing Magazine article titled “The Inconvenient Truth About SEO� by Paul Boag a week ago, my fear was that the headline would lead to an article blaming SEO for global warming and other calamities.

Storm clouds gather
(Image: rossap)

The title intrigued me, as someone who has done SEO for more than a decade, and I clicked on the link not certain what to expect. As I read the article, I came across terms such as “keyword density” and “gateway pages,” which Paul associated with SEO in his article. Those practices aren’t the kinds of things that SEOs do, and they would trigger a response from SEOs who would consider the first to be snake oil and the second to be a practice that’s often been used to deceive consumers.

Of course, Paul’s article has nothing to do with global warming, and Al Gore wasn’t mentioned once. The “inconvenient truthâ€� referred to in the article seems to be that throwing money at a website usually isn’t the solution to generating interesting, engaging and persuasive content that attracts visitors and traffic, links and referrals. The subject-matter experts who are often in the best position to share some of their expertise are the owners of the websites — the business people or journalists or people who run the nonprofit. As Paul was making this point, he cited the practice and practitioners of SEO as an example of a group who might be hired to create such content and presented their efforts in a negative light.

This rebuttal agrees with a number of the points Paul made in his article, but focuses on what an SEO actually does, what role an SEO might play in creating content and developing a content strategy, and how an SEO often tackles technical issues that designers and developers often don’t address.

After reading Paul’s article, I couldn’t help but respond in the comments with the following:

A person who uses things like “keyword density” and “gateway pages” is not an SEO, and never has been. But, if you need help with hreflang, canonical link elements, parameter handling, rel="prev" and rel="next" values for pagination, XML sitemaps for pages and images and videos and news, Google Plus authorship markup, Facebook’s Open Graph meta data, schema.org implementation, and many other issues that great content alone will not solve, an SEO can help you with those.

Your objective should be to make it easier for people who are interested in what you have to offer to find you, and see the great content that you offer. Relevant content isn’t “great contentâ€�. Someone searches for a pizza on Google, and they don’t want prose from Hemingway or Fitzgerald on the history and origin of pizza — they most likely want lunch. An SEO adds value to what you create by making sure that it is presented within the framework of the Web in a way which makes it more likely that it will reach the people that you want it seen by, when they are looking for it.

I have Paul to thank for the chance to write a rebuttal to his article. He recommended me to the editor of Smashing Magazine, who then received an email from Will Critchlow asking for the chance to write a rebuttal as well and to share the thoughts and opinions of some others who perform SEO.

I was asked if I was willing to collaborate with Will in writing this response. (I was thrilled with the chance to do so.) Will and I spent some time talking via instant messaging and thought it would be interesting to see if we could elicit some responses about search engine optimization from a number of SEOs who expressed interest in the original article by commenting on it, blogging about it or discussing it on social sources such as Twitter and Google Plus.

This article is in three parts, with the prologue written by me. The middle section includes responses to the questions I mentioned above about what SEO is, what role SEOs might play in content creation, and the technical issues that SEOs often see and the solutions they use to resolve them. The final section is an epilogue by Will, offering some final thoughts.

SEOs And Content Creation

Paul told me in a Skype conversation a few days ago that he didn’t understand or anticipate the reaction his article received from the SEOs like me who read it and responded to it in the comments section. His intent was to address website owners and influence them to take more ownership of their websites, to be more involved in the creation of those websites and the content they contain; to take the time and make the effort to create something that appeals to their audience, based on their own experience and expertise; or to hire someone with that type of knowledge to create quality information that provides a great experience to visitors to their pages.

I agreed with him — about website owners taking more control over the creation of content, that is. But I also disagreed. I told him about website owners I’ve worked with who were willing to write content but had no idea where to start or had no time to create it, people who needed coaching and help in writing in order to make it more likely that their great content would be seen by visitors and would be shown in search results to the people they were interested in reaching.

I’ve taught people to do keyword research to find and use the words and language that their audience might search with and would expect to see on their pages. I’ve explained how titles that are too long or too short or not very descriptive of the pages they title might not bring them the traffic they would like to see. The same with meta descriptions and page headings and other content.

What SEOs do when it comes to content creation and strategy is to help people work within the framework that exists for content created on the Web — a framework that dictates, for example, that a page title of a certain length is more likely to be seen in full if it is of a certain length, and that the title will be shown out of its original context when shared on Facebook, Google+ and Twitter or when saved as a bookmark. If it’s interesting and engaging in those contexts, then it is more likely to be clicked on and shared by others. SEOs study and explore the framework of the Web, of search engines, of social networks, and help others understand it.

SEOs And Technical Recommendations

Before I finish with this prologue, I want to share one of the technical issues I’ve seen more than a couple of times recently, to give you a sense of what an SEO actually does. And if it’s something that helps you, even better.

Previous and Next Link Elements

Many websites publish pages that are related, as part of a series, such as products in the same categories on an e-commerce website, articles that span more than one page, and galleries that show off related images, often with descriptive text. These often include pagination that enables you to go from page to page, often with numbers as links at the pages’ bottoms, and sometimes with a link to see all of the content on a single page.

These paginated pages often share the same HTML title element and meta description, and they could be perceived by search engines to be duplicative because of that. Google has defined a way that websites can overcome this perception, by treating these pages as if they are related.

Link elements within the head sections of the pages, with rel="prev" pointing to the previous page and rel="next" pointing to the next in the series, tell Google that this content spans more than one page. Here’s an example of what that might look like for a three-page series about blues music in Chicago:

  1. On http://www.example.com/chicago-blues.htm,
    the following should be in the head section of the page:

    <link rel="next" href="http://www.example.com/chicago-blues-pg2.htm">
    
  2. On http://www.example.com/chicago-blues-pg2.htm,
    the following should be in the head section of the page:

    <link rel="prev" href="http://www.example.com/chicago-blues.htm">
    <link rel="next" href="http://www.example.com/chicago-blues-pg3.htm">
    
  3. On http://www.example.com/chicago-blues-pg3.htm,
    the following should be in the head section of the page:

    <link rel="prev" href="http://www.example.com/chicago-blues-pg2.htm">
    

During a search, Google might identify relevant content on one page of the series and deliver you to that page, or it might deliver you to the first page of the series or to the “View all� page, if there is one. If a query that returned these pages as a result was “Chicago Blues,� then it might make sense for the first page to be listed in the results, since the whole series is about that topic. If the query was for “Chester Burnett, aka Howlin’ Wolf� and the second page focused specifically on him, then Google might return the second page in the series because it is most relevant.

If you have an “allâ€� page for your series of paginated pages, where all of the content is available on one page, then you have another thing to consider — you have two options for using canonical link elements on those pages.

Canonical Link Elements

In addition to using rel="prev" and rel="next" values in a link element as described above, you can use canonical link elements for those pages as well. A canonical link element tells search engines what the canonical version of the URL might be for a page.

Let’s explore how a canonical link element might work first. The home page of a website could possibly be reached in a number of ways, such as:

  • http://www.example.com/
  • http://example.com/
  • https://www.example.com/
  • https://example.com/
  • http://www.example.com/default.aspx
  • http://example.com/default.aspx
  • http://example.com/default.aspx
  • http://www.example.com/?jssessionid=gth2385756646353534434434
  • http://www.example.com/?ref=affiliate12342

This page might have a canonical link element in its head section that tells search engines that http://www.example.com/ is the preferred version of this URL. The code for this would look like this:

<link rel="canonical" href="http://www.example.com/" />

Ideally, you wouldn’t rely solely on a canonical link element to straighten out a website’s architectural issues. If you prefer the www version of URLs for pages on your website, then you would use a 301 redirect to send URLs without the www to the version with the www. You would also point all of the links on your pages to the www versions of your pages, instead of the non-www versions.

You would also want to be very consistent in how you link to the home page, using the canonical version throughout the website instead of using http://www.example.com/ in some cases and http://www.example.com/default.aspx in others. You could also set up a 301 redirect so that the default.aspx version redirects to the canonical version. Don’t rely solely on search engines to get things like this right by themselves if you have the ability to take matters into your own hands.

Canonical and Previous/Next Link Elements Together

When you have a “View all” page for an article that is otherwise spread over multiple pages, Google might identify that full page as the best one to send searchers to. A Google help article on “Paginationâ€� makes that point clearly:

Searchers commonly prefer to view a whole article or category on a single page. Therefore, if we think this is what the searcher is looking for, we try to show the View All page in search results. You can also add a rel=”canonical” link to the component pages to tell Google that the View All version is the version you want to appear in search results.

The help page recommends that the canonical link element for each page in the series be the “View all� page’s URL. The canonical link element for the page at http://www.example.com/chicago-blues-pg2.htm would be this:

<link rel="canonical" href="http://www.example.com/chicago-blues-view-all.htm">

However, website owners often split up articles into multiple pages in order to get viewers to see advertisements and other information on each page as they go through the parts of the article. If you want that to happen, then you might decide not to include a “View all� page. If so, then the canonical link URL for each of the paginated pages in a series would point to itself, rather than to the “View all� page’s URL, as recommended in the snippet from Google above.

For example, the canonical link element for http://www.example.com/chicago-blues-pg2.htm would be this:

<link rel="canonical" href="http://www.example.com/chicago-blues-pg2.htm">

If you still want to offer a “View all� page but don’t want it to be what Google shows as a search result for content on this series of pages, you could also use a meta robots noindex element in the head section of that page. So, in the head section of http://www.example.com/chicago-blues-view-all.htm would be this meta element:

<meta name="robots" content="noindex,follow" />

Knowing how these work together gives you a voice in determining which pages will show up for a relevant query. (Note: If you have a “View all� page but have put a noindex meta element in it, and people link to that version of the page, then you will lose the benefit of any PageRank pointing to that page.)

Prologue written by Bill Slawski (@bill_slawski).

What SEOs Say: SEO Tips You Can Use

We picked three questions to ask a range of professional SEOs. We wanted to present opinions and perspectives from a diverse set of people, as well as provide some real value to the expert designers and developers who frequent Smashing Magazine. Here are the questions we chose:

  1. “How do you define SEO?�
    Our hope here is that you will see common themes and ideas. Hopefully, some of them will resonate with you, and you’ll get a better sense of what we actually do.
  2. “What role should an SEO play in the development of content for a website?�
    One of the big themes in Paul’s post was the feeling that content should be the domain of the business owner or specialists. We wanted to show you some SEOs’ opinions on where they can add value.
  3. “Do you have a tip for Smashing Magazine readers about technical SEO?�
    We wanted to leave you with some actionable advice that you can take away and hopefully use immediately for your website and business. Technical tips tend to be the easiest things to implement immediately, so we asked our colleagues for their ideas.

1. How Do You Define SEO?

Bill Slawski:

SEO is the practice of making it easier for site owners and their audience to find each other, to meet the objectives of the site owner and the informational and situational needs of that audience. This means in part helping site owners find the right language to use that audience members will search for, and overcoming technical obstacles that might keep search engines from crawling and indexing the great content developed for that audience.

Gianluca Fiorelli:

It is not simply “search engine optimizationâ€� (we don’t optimize search engines), but more “search experience optimization.â€� Users are the main focus of real SEO, and that is something Google itself is preaching to all site owners (not just to SEOs).

Ian Lurie:

SEO means making sure search engines can find, properly classify and value content. “Properlyâ€� means “from the perspective of a human being performing a relevant query.â€� So, while link buying, etc. may help with rankings, it’s not really SEO so much as a way of getting around true SEO. That’s why so many “short cutâ€� tactics get sites into so much trouble.

Patrick Altoft:

SEO is doing anything that will increase traffic from the major search engines. This could be anything from content to design to link building to online PR. We just do whatever we think is going to have an impact. If Google started to rank sites higher that did more TV advertising or had more Facebook likes, then those might become SEO, too. Currently, a good SEO agency does the things mentioned in my post, but that could change at any time depending on the direction Google is heading.

Richard Baxter:

I’ve been reading Smashing Magazine for years, and I’ve always found it an invaluable source of inspiration and instruction and a good source to discover new technologies and design principles. SEO practitioners depend on sources of information just like this. The truth is, we couldn’t work without great front-end design and development, ideas and inspiration. We’re working in an industry where great content is finally winning the battle against very poor-quality, badly designed and heavily over-optimized junk pages. I’m personally delighted about that fact because it makes my job challenging, interesting and closer to marketing than ever before. It’s what keeps me in search marketing, in fact.

I want to show you a search result in the UK: “laptop reviews.â€� Every single page in the first 10 results is, frankly, woeful — uninspiringly designed and there primarily to serve the needs of traffic generation over and above the needs of a user trying to find their next laptop. I believe that this search result is just one example of an opportunity to really help an underserved content niche by creating the best possible experience for users, by putting their needs first. There is an infinite number of these opportunities in search.

So, here’s what an SEO does. We seek opportunity, and we work to differentiate in order to gain competitive advantage. We build tools to help us achieve those aims, and the best SEO people spend a good amount of their time giving back to their communities by sharing their tools and teaching these principles. We should never put simple objectives such as “driving traffic from search enginesâ€� over and above user experience and conversion. Great design is fundamental to being able to achieve that goal, and we’re working to achieve this on every single touch point that a user might have with our clients’ (or our own) websites.

Mackenzie Fogelson:

SEO means focusing more on the customer and less on yourself. SEO means providing value. SEO means looking at the big picture and helping a company transform its business. SEO means identifying business objectives and determining the best way to go about realizing them.

Adam Melson:

[SEO is about] making search engines undoubtedly confirm that a site is increasingly valuable to searchers.

Value could be measured by the number of quality links pointing to a great resource. Value could be really useful, actionable or well-written content. Value could be changing a website to allow Web crawlers to index great pages that exist but that they’ve had trouble getting to in the past.

Will Critchlow:

We see SEO as being about succeeding in a world where users turn to search engines for discovery, research, validation and comparison.

In a practical sense, SEO is the process of making a website accessible to search engines, ensuring that it has well-organized, high-quality content that matches the needs and demands of its target market and that it becomes well known and cited.

2. What Role Should an SEO Play in the Development of Content for a Website?

Bill Slawski:

An SEO’s role is that of a helper, an assistant, an aide, to make it possible for the owner of a site to have a voice to share their wares or publish their message or educate others. An SEO does this with the experiences and expertise they’ve developed from having worked with site owners of many different types, from having studied the search engines’ guidelines and practices, and from having researched sources such as patents and papers and blog posts from the search engines and from others who study the search engines.

SEOs can help with the creation of content in a number of ways. These can include working with copywriters, researching keywords and competitors, and helping to develop a marketing strategy. The focus is on a collaborative effort with site owners that enables and helps site owners to improve their visibility on the Web.

Gianluca Fiorelli:

An SEO should be considered one of the most useful resources when creating content for a site. Their knowledge and expertise on how people search and in discovering what users really are searching for about a topic means they can provide invaluable input to content strategy.

Ian Lurie:

SEOs should help guide topic strategy through audience analysis. Few other marketers have the same insight into what the public really wants. We can find search phrases (obviously), questions (via Google Suggest and similar tools) and help analyze responses to content. We should also help with online content usability and writing best practices.

Patrick Altoft:

Any content strategy should be developed primarily for users. Content needs to be useful, but a content strategy needs to take into consideration the number of people who might want to read that content — this is where search engines and keyword search volumes come in. Create content that people are searching for, and that’s probably going to be better than creating content that there is currently no appetite for.

Mackenzie Fogelson:

When developing content for a website, an SEO serves as a knowledgeable consultant who will:

  • Define business objectives
    They will thoroughly understand a company’s overall business objectives, not just their objectives with SEO or social media, content marketing or traditional marketing. They know the company’s overarching goals for what they’d like the business to achieve.
  • Define target audience(s)
    They will conduct the necessary research to understand and define a company’s target audience(s).
  • Determine pain points, the conversion funnel and messaging
    They will understand the target audience or personae’s pain points in order to effectively develop content that helps customers get what they need at the appropriate stage in the sales funnel. Then, they will develop the messaging to fit.
  • Develop strategy
    They will consider business objectives, the target audience, pain points and the conversion funnel. SEOs assist companies in formulating a content strategy that will generate the content that really meets the needs of their customers.
  • Determine target keywords
    It would certainly be a shame to generate content that is never found. SEOs determine the keywords that customers are actually using to find relevant information related to their queries.
  • Develop a navigation structure
    Once a company knows what type of content their customers need, an SEO can assist in planning a navigation structure that helps a user find what they need quickly and easily. Ultimately, the structure will also allow the search engines to easily crawl all content on the site so that it can also be found and returned in a relevant search.
  • Develop valuable content
    A great deal of work is done before an SEO can help a client develop valuable content. Once they’re there, it’s a matter of generating authentic, engaging content that benefits the customer. This requires a partnership between the SEO and the client to effectively convey the right message at the right time.
  • Integrate appropriate keywords into content
    SEOs assist customers in finding the content they need by integrating the appropriate keywords into the content. This allows the search engines to properly crawl and index that content to be returned in a search.
  • Facilitate outreach
    They assist companies in connecting with people who would find value in the content that has been generated. This can be done in person, online through social media or through email marketing. Certainly, when content is effectively optimized, it will organically contribute to outreach.
  • Measure and analyze
    Based on data that is collected, SEOs measure and analyze the content that has been generated to determine whether it’s satisfying the needs of the customer.
  • Provide strategic direction
    Based on everything that has been learned from generating content, where does the company go next? The data collected will inform the SEO so that they can help the company make educated decisions about their content moving forward.

Adam Melson:

SEO should help guide content development where it makes sense for a business and its customers. Content creation has become so much less about cramming keywords repetitively on a page and much more about having great content.

Yes, keyword research should still be conducted and keywords selected based on criteria like conversion rate (potentially taken from PPC data), search volume and whether a term is a fit for the business (e.g. deciding whether “cheap� or “discount� is appropriate for the image of the company). Developing content that fits a business and its customers is what will be valued, linked to, shared and typically placed higher in results by search engines.

Will Critchlow:

Not all SEOs have exactly the same skills, but if we broaden the scope to “SEO agency,� we believe good SEO agencies add value to content strategy work, topic selection, concept development, production and promotion. In the strategy stage, SEO skills are particularly useful in research and competitor analysis, in topic selection and in convincing business owners to create more public-facing non-self-promotional content.

3. Do You Have a Tip for Smashing Magazine Readers About Technical SEO?

Ian Lurie:

Build fast and responsive. Most importantly, build for beautiful content. Text doesn’t prevent great design — it’s part of it.

Gianluca Fiorelli:

Imagine a site built for an international audience and created with different language versions. You want that site to be visible in the correct language or country version in each respective country’s search engine (e.g. Spanish in Spain, German in Germany). If you are in this situation, you should research rel="alternate" hreflang="X-x" to highlight to Google which version is appropriate for which market.

Adam Melson:

Watch out for the ways you could kill your site accidentally. Improperly using robots.txt, improperly using the canonical, selecting the wrong type of redirect when relaunching your site to a new domain, and disavowing all your links are just a few.

Epilogue

For me [Will Critchlow], the “inconvenient truth� is that SEO is a poor description of what we do today. We neither “optimize� for search engines nor “optimize� search engines. Despite running an agency that is best known for our SEO work, I would like nothing more than for a better name to take its place.

Why do we use the phrase “SEO,â€� then? A large part of our work is education. We want smart and informed clients — but first, those clients need to find us. I think I speak for most of the people quoted above when I say that most of our clients have come to us asking for SEO without really knowing what tactics they are seeking. They really want to make more money from their online presence. Our solutions range from “traditionalâ€� technical SEO recommendations to content strategies to conversion rate improvements. Step one is to make sure we agree on the best way to achieve their goals.

education in action

This is a world away from the short-term views described in the original article. Is it SEO? I believe so. To the extent that SEO is a useful descriptor, I believe that it’s about finding the ways to succeed in an online world where commercial discovery is dominated by search.

Now, I agree 100% with Paul when he talks about how “manipulation of the system� is a poor idea. To use that as an argument against (good) SEO agencies, however, is a straw-man argument, in my opinion. We are focused on finding the same long-term investments and returns that Paul describes in the remainder of his post. We may disagree on some details, such as whether there is a role for an external advisor or resource, but fundamentally we agree on the majority of tactics and strategies that Paul describes.

Paul suggests, for example, hiring employees who are dedicated to creating content for your website. We have advised our clients to do exactly that (and have even helped them identify, hire, train and support those individuals).

There are two other areas in which I believe SEOs (and agencies, in particular) can add more value. Paul touched on the first in his update to the original post — and that is the importance of technical help when building large or complex websites, when creating multiple language versions, when migrating a website or when cleaning up the after-effects of poor implementation or architecture.

The second is in the promotion of great content. I see this role as closely resembling a modern form of digital PR. As with content strategy, I’m sure Paul would point to specialists who do nothing but this, but I feel that (especially for smaller companies) it is good to have integrated services provided by an agency that brings together individual specialists under one roof.

Finally, I’m really keen that no one sees this as a sales pitch for my company. We aren’t taking on new clients until late in Q1 next year, and I’m not here to win business. I really want you all to make better websites, to market yourselves better and to make search results better for all of us.

Go on: make my team’s job harder by making your websites and your clients’ websites better and more deserving of ranking. I’d love to see that.

My Tips

I thought I’d wrap up with a few tips to keep you busy:

  • Browse around your website with JavaScript and images turned off, and make sure not only that you can get around, but that you can access the content.
  • If you publish video, use a video site map to highlight where your video is embedded, so that you get rich snippets (including thumbnails) in search results.
  • Read up on Google’s authorship and publisher protocols, and tag your content with the experts who wrote it, so that you get both reputation benefits and head shots in the search results.
  • If you are a local business, claim your local listings, and make sure that references to your businesses are consistent around the Web.
  • If you need to remove an already-indexed URL from Google, you can’t use robots.txt. Adding a meta noindex (or removing the content with a 404 or 410 error) is normally best.
  • Check carefully any use of canonical elements. One of the most catastrophic SEO failures we see is when a website owner accidentally adds a canonical link pointing all pages to the home page.
  • If you use WordPress, check the text-only cache (visit http://webcache.googleusercontent.com/search?q=cache:YOURDOMAIN&hl=en&tbo=d&strip=1, replacing YOURDOMAIN with the URL of your home page) to ensure that the theme’s creator hasn’t included spammy links in the footer.
  • Use a 301 permanent redirect every time you move or rename a page.

Contributors to this post include (in nofollow’ed links):

(al)


© Bill Slawski, Will Critchlow for Smashing Magazine, 2012.


Boost Your Mobile E-Commerce Sales With Mobile Design Patterns


  

People are increasingly using their smartphones as a replacement for desktop computers, even for activities such as shopping and purchasing. And as more people move away from the desktop and onto mobile-optimized websites to shop for products and services, website creators can use established design patterns to help kickstart a mobile e-commerce project.

Having a good mobile e-commerce experience matters a lot. In fact, recent research has found that people are 67% more likely to make a purchase if a website they’ve reached on their phone is smartphone-friendly.

The power of design patterns is that they show you how other designers have solved similar problems so that you are not always reinventing the wheel. They also enable you to design your website in a way that meets the expectations that people develop from the other websites they’ve used, and they encourage you to consider design approaches that you would not have thought of on your own.

In this article, which focuses on smartphones, not tablets, we’ll look at design patterns and approaches used for mobile e-commerce functionality, including the following:

  • Home pages,
  • Site-wide navigation,
  • Suggested search,
  • Search results,
  • Search filtering and sorting,
  • Product pages,
  • Photo galleries,
  • Shopping carts,
  • Checking out with an account or as a guest,
  • Forms.

All the examples in this article are drawn from mobile websites that run in smartphone browsers. Most are taken from large multi-department retailers because they have large product catalogs that require a thoughtful approach to features such as search and filtering and sorting of search results. There are also countless native apps for e-commerce, and many of these patterns can be applied to them as well.

Home Pages

When visited on mobile devices, home pages are often less about content and more about helping users find what they are looking for. Common patterns are simple single-column layouts for promotions and single-column lists of links to featured website areas or product categories. Keyword search is commonly included on home pages, as are links to store locators and registration forms for promotional emails and loyalty programs.

Amazon and Macy’s home pages
Amazon and Macy’s both use a mix of promotional elements and list menus.

Target and Threadless home pages
Target’s promotional content takes up more screen space than a simple list but makes a stronger visual impact. Threadless uses a dashboard pattern, which is more common in native apps than on e-commerce websites on mobile.

If shoppers are coming to your website to compare prices quickly, then a simple list pattern and search function are probably more desirable. If they are coming to explore promotions and sales, then the approach taken by Target may be more appropriate. To answer these questions, you’ll need to mine your analytics to get an idea of what consumers are doing on your website.

Site-Wide Navigation

Beyond using the home page as the main navigational hub, many websites also have navigation menus on most of their pages, usually in the header. This enables shoppers to easily get from one part of the website to another without having to return to the home page.

Lowe's and Best Buy website menus
Lowe’s site-wide menu has icons for each option. Best Buy’s menu has a two-column layout for navigation and has buttons instead of list items. Lowe’s menu covers the page when it appears, while Best Buy’s pushes the page’s content down the screen.


Macy’s has a site-wide menu that contains submenu options. CVS has a two-column menu with an icon for each option. In both cases, the menu is displayed at the top of the page.

As you can see from the screenshots above, there are several ways to design a site-wide menu. Lowe’s design is simple, and the icons add a nice bit of visual polish. The fact that the rest of the page fades into the background when the user chooses to use the navigation helps users focus on their current tasks. CVS seems cluttered in comparison, with two columns of options, each item accompanied by an icon. CVS’ menu also places a lot of tap targets close to each other, which can present usability problems on touchscreens.

What’s interesting that large e-commerce websites usually don’t have many navigation options displayed at once. They try to balance the visual design of the navigation with the information architecture of your website, carefully considering the number of items that should be in the global navigation. Use website analytics to see which menu options shoppers click to help you determine what should be in the menu. Conducting A/B testing and usability tests of different designs to see whether one has too many options and overwhelms people is not just recommended but necessary to find the optimal solution — for your business and for your users.

Suggested Search

Suggested search, also known as type-ahead or autocomplete, displays potential results as soon as a shopper has typed in a few characters. For commonly searched terms, this can be a real convenience to shoppers, especially if the search term is long. One limitation of suggested search is that tapping a wrong character on a virtual keyboard is easy, which would change the suggested results. Showing common “correct” results instead might be useful. Also, consider using an improved Auto-Suggest pattern to reduce the amount of typing needed to enter queries, and utilizes slower mobile bandwidth in the most efficient manner.

Office Depot suggested search
Typing “d-r-a-f� into the search box on Office Depot’s website brings several possible results. And mistyping “d-r-a-g� instead of “d-r-a-f� leads to unexpected results for someone who is trying to find drafting supplies. Tapping a letter adjacent to the intended one is a common problem on virtual keyboards.

While designers can’t do anything about people mistyping queries, they can ensure there are other ways to get to product pages from mistyped results, such as drill-down lists for product categories or a site-wide menu of top-level categories. Website managers can also fine-tune their search functionality by suggesting results for “draft� from queries typed as “dragt.� Your ability to do this will depend on the search engine technology you are using.

Search Results

Two primary patterns are used for search results on mobile e-commerce websites: table display and grid display. Tables show a thumbnail photo and some basic information such as product name and price in a compact row. Grids show larger images with less descriptive information. Some websites allow shoppers to switch between the two views.

Zappos and Walgreens search results
Zappos shows its search results in a grid to allow for larger photos of its products, a sensible choice in a market like shoe sales. Walgreens has a table that includes buttons for finding item in stores and adding items to a shopping cart.

OfficeMax search results
OfficeMax asks shoppers to select a subcategory for broad search terms like “Paper.� Once a subcategory has been selected, results are displayed as a table. Searches for terms like “Scissors,� which have fewer subcategories, takes shoppers directly to the table view of the results.

Having shoppers select a subcategory can be problematic if it’s not clear where a product fits in a complicated hierarchy. In the OfficeMax example above, someone looking for 8.5 × 11-inch paper for their home printer might not know whether to look in “Copy & multipurpose paperâ€� or “Laser paper.â€� A better approach might be to list subcategories under search filters, where they can be presented in context with other filters, like “colorâ€� and “size.â€� Regular testing (every 4–6 weeks) with representative users and commonly searched-for terms and top-selling products could give you insight into which approach is better. A/B testing could also reveal whether one approach gets more people to a product page and leads to a higher conversion rate.

Gap search results
Visitors to Gap’s website see a table display by default, with the option to see a grid display. Notice that Gap also retains the search term in the keyword field.

Gap lets shoppers choose how to view search results, allowing them to switch from an easy-to-scan list to a view with larger photos. Gap could have retained some product information though — e.g. prices — in its grid display (as Zappo’s does). Details such as price and color make it easier for a shopper to determine which product they want to learn more about.

Retaining the term in the field also reminds shoppers what they searched for and lets them easily narrow the results by adding another word (like “red�) to the search term.

Searching Gap for “men’s tshirts� takes shoppers to a page with no results (not shown), and without linking to search results for “men’s t-shirts.� Gap could improve its search by adding a “Did you mean?�-type question to the results page. Google handles this scenario by listing “mens t shirts� as a suggested query and then presenting results for “men’s t-shirts� if that suggestion is ignored.

Sorting Results

Sorting results helps shoppers organize a large set of results along a continuum of values, usually numerical ones such as price and consumer rating. Common interface patterns for sorting are buttons and <select> menus.

Walmart and Sears search sorting
Walmart lets shoppers select one of three buttons to sort results. Sears uses a similar approach, but with a “segmented control”. JavaScript frameworks such as jQuery Mobile are making these app-like interface widgets more readily available to designers.

J.C. Penney and Eddie Bauer search sorting
J.C. Penney allows for sorting through a <select> menu that is slightly customized in style, while Eddie Bauer uses the browser’s default <select> menu. Both trigger the browser’s native control for <select> menus (in these examples, the iPhone picker).

The size and generous spacing between Walmart’s buttons make for better tap targets; although, to be fair, Walmart has only three options, while Sears has four. Sears’ inclusion of an “Allâ€� button allows shoppers to get back to the original results page if they don’t find what they want after having sorted. Using a <select> menu is a quite safe choice because it is supported by modern mobile browsers and allows for longer lists of sorting options. However, it also takes a lot of valuable space. These are the types of design trade-offs that can be evaluated with regular testing.

Filtering Results

Filters enable shoppers to narrow their results based on one or more attributes, like color, brand and size. Filters are usually organized by type (called facets), with several values appearing under each facet (for example, color is a facet, and red is a facet value). Common interface patterns for displaying filtering options are <select> menus, drop-down lists and accordion displays. Filtering can be applied when one or more values are selected from within a facet. While allowing a single search to include values from more than one facet is technically possible, it comes with a higher interaction cost and could lead to no results (for example, cross-training athletic shoes that cost less than $75).

CVS and jcpenney search filtering
CVS uses <select> menus in its “Refine” tab for filtering. Selecting a menu option will immediately filter the results. J.C. Penney offers a drop-down list for selecting filters and indicates the number of products that match a filter value. J.C. Penney also allows multiple values from a single facet to be selected on one screen, the trade-off being that the shopper has to tap the “Applyâ€� button.

Kohl's and Threadless search filtering
Kohl’s uses an accordion to expose a set of checkboxes for each filter type. Threadless exposes the values for all of its search facets as buttons. On both websites, selecting a single filter value will immediately filter the results.

Showing the number of items available under each facet value offers greater transparency into what shoppers will get with each selection. Threadless’ approach of showing all available facet values takes up the entire screen, but it offers consumers an at-a-glance view of all filtering choices available to them. Whether you take this approach or use an accordion like Kohl’s will likely depend on how many facet values are present for a given category of products. If your catalog has a high degree of variability in the number of facet values for each category, then you will need to experiment to find the right design. You could optimize the filtering interface for those product categories for which shoppers use filters the most.

Product Pages

Product pages are where e-commerce websites really showcase their products in detail. They are not a “pattern� in the true sense of the word, but rather a collection of patterns that include elements such as tabs, accordions and photo galleries. Two common approaches to product pages are one long page with all of a product’s information or a page with tabs or accordions to allow for progressive disclosure of information as shoppers need it.

Samsung and Dell product pages
Samsung and Dell progressively disclose content on their product pages, which have a lot of information for shoppers. Samsung uses accordions to expose chunks of information, while Dell uses tabs.

Cabela’s and Office Depot product pages
Cabela’s and Office Depot both use a single long page to display product information. This approach requires more swiping up and down to get to information, but it frees shoppers from having to work with small tabs or manipulate accordion headers. You choice will depend on the amount of information associated with a product and how the information can be broken down into logical sections.

Long product pages require more scrolling than pages broken into manageable chunks with tabs or accordions. They also require shoppers to put more effort into finding the specific information they are seeking. In my own usability testing, I’ve heard people express preferences for both approaches, but they seem to have an easier time working with a page broken into logical chunks. If you take this approach, make sure any content not initially displayed renders quickly when the shopper taps on the tab or accordion.

The obvious way to accomplish this is to load all of the page’s content at once so that the hidden content appears almost instantly. This approach has an advantage for when the user’s network connection drops while they are switching between sections. The big downside is that all product information has to be downloaded, whether it is actually viewed or not; this adds more load to your servers and uses more of the shopper’s data plan, which could be metered.

Photo Galleries

Photo galleries are particularly critical in e-commerce industries such as apparel and consumer electronics. You might not need to see a wrench from three different angles when shopping at Home Depot, but more images are better when looking for clothes, shoes or a high-end smartphone or tablet. A few commonly used patterns are the swipeable gallery, “double-tap to zoom”, and thumbnails for selecting photos.

Payless photo gallery
Payless uses a swipeable gallery to show its products from different angles. Users can also double-tap to zoom in to see details like stitching and eyelets.

Payless wisely keeps its “Tap tap to zoom� call-out on the screen for several seconds, giving the shopper time to understand how to navigate the page and still notice it. The ability to zoom in to a photo to view a product’s details is critical for apparel and shoes.

Dockers and Levi's photo galleries
Dockers (above left) has a swipeable photo gallery, with double-tap to zoom in to details, and shoppers can see a product in different colors. Levi’s (above right) takes a similar approach, with the addition of thumbnails to indicate the photo angles in the gallery. Selecting a new color on Dockers’ website causes a full-page refresh, while Levi’s does not.

Levi’s keeps most of the page from refreshing when the shopper changes colors, which at first seems like a better user experience. But, from a brief review of both websites on the same date and at the same time of day, Dockers’ full-page refreshes appeared to run faster from the time I tapped a color swatch to the moment the page with the new photo appeared. Levi’s slowness could have been caused by the five thumbnails needing to be refreshed, in addition to the main photo, or other unseen factors, such as a heavy traffic load. Each approach has its trade-offs.

Samsung and Dell photo galleries
Samsung (above left) and Dell (above right) both use swipeable photo galleries for their products. Samsung incorporates the gallery into an accordion on its product page, while Dell uses a separate page.

Samsung’s approach seems more user-friendly because it has fewer pages to navigate. Both Samsung and Dell go with large high-resolution photos, because apparently image quality is critical when looking at expensive products. One advantage to Dell’s approach is that it allows shoppers to focus on the photos themselves without any distracting page content.

Shopping Carts

Shopping carts usually display products using a table pattern. Besides displaying the contents to be purchased, they also offer additional functionality, such as the ability to save an order, to save a product to a favorites or wish list, to remove products or update quantities, to choose shipping or in-store pickup, to apply promotional or coupon codes, and to check out. Once a product has been added, a shopping cart is commonly reached through an icon in the website’s header or an option in the global navigation menu.

Lowes and Bed Bath and Beyond shopping carts
Each table row in the Lowe’s shopping cart (above left) lets the user remove the corresponding product from their cart, and it includes options for shipping or in-store pickup. Bed Bath & Beyond (above right) also allows items to be removed; product quantities may be changed for each item in the table, and a single button farther down updates the page.

Crate and Barrel and Payless shopping carts
Crate & Barrel (above left) has table rows that allow users to remove products, save to favorites and update quantities. Each row also includes shipping information such as cost and delivery time. Payless (above right) also allows consumers to update quantities and remove items; its cart also offers a choice of delivery options, including having the product sent to a Payless store (not shown).

Shopping carts should provide maximum utility because shoppers are close to the final point of purchase. Allowing shoppers to change quantities, remove items and apply promotional or coupon codes without having to go to another page is critical to getting them through the purchasing funnel quickly. If you feel this adds too much content to the page, you can use progressive disclosure to hide some content (such as promo code fields) behind accordions until it is needed.

Checkout

Checkout is more of a process than a pattern, although form patterns can be applied to checkout flows. Many e-commerce websites allow customers who use their websites on mobile to check out with an existing account or as a guest. For people who already have an account, the checkout process is greatly streamlined by using existing payment and shipping information.

Crutchfield and Nordstrom checkout
Crutchfield and Nordstrom both allow customers to check out as guests or by using their existing account. Both allow mobile shoppers who have checked out as guests to create an account after placing their order, and both support password resetting.

Amazon and Target checkout
Amazon asks for an email address on the first page of the checkout, whether the shopper has an account or is checking out as a guest. The experience is very much the same like for users of the website on desktop. Target offers options on the mobile website to sign in with an account, to check out as a guest or to create an account. Both support password resetting.

Allowing customers to either sign in or check out as a guest and to reset their password is a must for mobile e-commerce websites. Also, consider inviting shoppers to create an account on their phone after placing their order, because they have already given you enough information (except for a password) to do so. This could make guests more likely to create an account because the effort should be minimal at this point.

The “Create a Target.com account� button could lead to some abandoned carts if shoppers go down that path and decide it’s too much effort. Confirming the order first and then inviting registration on the invoice page might be better. Limiting the initial checkout screen to two choices could improve conversions because the shopper will have fewer decisions to make while working on a small screen. Fewer choices in critical tasks such as check out usually works better.

Forms

Forms are most commonly used in mobile e-commerce for searching, checking out, registering, and entering coupon and promotional codes. Be aware of a few good practices when designing forms for the small screen:

  • Place form labels above input fields so that they don’t shift off screen when the user zooms into the input.
  • Use HTML5 input types to display the appropriate keyboard for the field being used. For email addresses, use type="email". For numeric fields, like ZIP codes, use type="number" or type="tel" (the latter will display a numeric keypad with larger buttons).
  • Make fields mandatory only when absolutely necessary. This will reduce friction in getting customers through the checkout process.

The best way to handle forms on a smartphone is to use as few of them as possible. You can use geo-location to suggest the shopper’s ZIP code, and you can allow customers to check out using the account information they entered earlier when using your site. Remember that the best form is the one the shopper never has to complete.

CVS and Crate and Barrel checkout forms
CVS (above left) doesn’t bring up a numeric keyboard when the user taps the ZIP code field on the checkout page. This requires one unnecessary tap from the shopper to get the correct keyboard. CVS also aligns labels to the left of form fields, where they could get pushed off screen if the user zooms into a field. Crate & Barrel (above right) has a much more mobile-friendly form. It brings up the large numeric keypad when someone taps the ZIP code field. It also top-aligns form labels so that they don’t slide off the page.

Remember that forms are how shoppers complete their transactions on websites. Pay special attention to them, and do everything you can to reduce the interaction cost of completing them. Sometimes it might even mean trying out something entirely different. For example, Typeform recently suggested a new kind of experience for more responsive, simple and user-friendly Web forms. The idea is to ask just one question at a time, but display it prominently, allowing users to type the hotkeys when filling in the form. This is not the option that would work in every situation, but for some forms it might be quite helpful.

Conclusion

With the increasing importance of mobile e-commerce as a source of revenue to retailers, mobile-optimized websites are offering many of the features that shoppers want and expect based on their desktop shopping experiences. And as the research by Sterling Brands and SmithGeiger shows, mobile consumers are more willing to purchase when the website is mobile-friendly.

By using existing design patterns, you can begin to explore different options to more quickly get your e-commerce website ready for the small screen. But don’t stop with existing patterns; use them as a jumping-off point to explore a design and to help you consider options you might not have thought of. And as browser capabilities increase, consider bringing interface design and interaction patterns from native apps into your browser-based smartphone shopping experience.

Resources

(al)


© Will Hacker for Smashing Magazine, 2012.


Vexing Viewports

Vexing Viewports

“The Web is Agreement.” Jeremy Keith’s eloquent statement neatly summarizes the balance that makes it possible for us to build amazing things. Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal.

This agreement has never been more important.

That’s why it always hurts when a device or browser maker does something that goes against our agreement. Especially when they’re a very visible and trusted friend of the web—like Apple.

You see, Apple’s newest tablet, the iPad Mini, creates a vexing situation: Its device-width viewport tag defaults to the same values as Apple’s original iPad (768x1024 pixels), even though the Mini's screen is physically 40 percent smaller. That means every button, graphic, link, and line of text on a web page on the iPad Mini appears tiny—even when we try to do the right thing and build flexible, multi-device experiences.

Two iPads, one too small.

But Cupertino isn’t the only culprit out there. This is a problem that’s been brewing since we started using the viewport—and it has to do with not just pixels, but our own practices as well. Let’s take a step back and understand what’s really causing today’s woes—and what all of us need to do about it.

The trouble with pixels

Today’s viewport woes can be traced right back to pixels—yes, those tiny elements we work with every day.

The first pixel challenge is quantity. The more pixels in the display, the more information can be displayed. But as these are physical pixels whose number can’t be altered after the fact, a second factor comes into play: the screen’s physical size.

Imagine two two-inch-wide displays (about the width of the iPhone), as shown below.

Two devices, each with a two-inch-wide display. The one on the right, at 640x960, would pack four times as many pixels into the same space as the 320x480 screen on left.

The first is 320x480 pixels, the second 640x960. This gives the second display four times as many pixels as the first, but fits all of them into the same physical space. This smaller pixel size results in content that is also smaller—making it crisper, but much harder to read as well.

This is exactly what happened on the Nokia E60. In 2005, most mobile phone displays were about an inch and quarter wide, with an average of 176 pixels in that width. But the E60, which sported a “huge” 352x416-pixel display, crammed twice the number of pixels into a similar amount of space. The result: A gorgeous, crisp—but often hard-to-read—display.

The E60 also introduced a now-familiar problem: how users would manage to surf “big” sites on a tiny device. Nokia’s solution was a new browser, the Mini Map. This browser behaved similarly to today’s smartphone browsers by first rendering the full-sized page, then scaling it to fit the available screen size. Superimposed onto this rendering was a transparent red box that could be repositioned using the device’s joystick. Clicking the joystick would zoom the content indicated within the box.

Enter viewports

Mini Map was probably one of the first commercial uses of a dynamic viewport—a construct designed to dynamically change the size or scale of the visible screen area in order to improve the user experience. But it was far from the last.

In 2007, Apple released the iPhone, a much larger device than the E60, but one with a similar problem. Even on a “huge” two-inch display, surfing the “real web” on an iPhone meant loading large pages onto a small device. Apple chose to solve this problem through a series of carefully orchestrated enhancements.

The first was the creation of a virtual viewport similar to the one Nokia designed for Mini Map. When encountering desktop websites, the browser would render them at their full size (based on a default canvas width of 960 pixels). It would then scale them down to fit the two-inch display. Users could interact with the page to scroll and zoom in on areas of their choice.

Apple didn’t stop there. It also developed a new viewport meta tag. Sites not using the tag would be rendered using the default, legacy-web viewport of 980 pixels. But developers who opted to use the tag could declare the viewport for their sites, including setting the width to the all-important device-width value. This value tells the browser, “please pick a width that fits this specific device’s screen best.”

Other mobile browser vendors were quick to follow Apple’s lead. Nowadays just about every mobile browser supports the viewport meta tag, including the device-width value. This provides us with an even playing field: It respects the efforts of those who take the time to adapt sites for the multi-device web, while those who haven’t yet made this transition still receive a “good-enough” default experience.

Mini problems

The value device and browser vendors assign to device-width is directly related to that device’s physical dimensions. Physically smaller devices need a smaller device-width value (which will result in larger content). Set a value that’s too large, and most content will be too small to comfortably read.

And that’s why Apple’s iPad Mini has a vexing viewport. It uses the same 768-pixel device-width as the regular iPad, even though its physical size is much smaller. One would expect to see a device-width more in line with those of similarly sized tablets like the BlackBerry PlayBook or second-generation Samsung Galaxy 7″—around 500 to 600 pixels, as shown in this chart.

Because of this device-width, web pages appear 27 percent smaller on the iPad Mini than they do on the Google Nexus 7 (calculated based on the relative size of device pixels)—all because Apple decided to describe the device’s viewport as 768 pixels.

Solving for content size

One of the first places this causes problems is in text: More pixels in a smaller space means that fonts sized in pixels will look correspondingly dinky.

Of course, many of us aren’t sizing in pixels anymore—we’re using relative dimensional elements like ems, right? Only, that doesn’t quite solve the problem this time.

When we use ems, we imply a certain trust that the browser’s baseline font size at the default zoom level—1em or 100 percent in unit parlance—is sane and readable. But that’s not always the case. The browser’s baseline font-size value (1em) roughly equates to a 16-pixel square. This ratio serves as a ligament that binds absolute and relative units, but it can vary from browser to browser.

On the iPad Mini, font-size at baseline is precisely 16 pixels. That may have worked fine when fewer pixels were packed into our screens, but on a dense display with an improperly defined viewport, that’s going to be uncomfortably small.

Not all browsers toe the 1:16 em-to-pixel line, though. The Kindle Touch’s browser, for example, has a high-density viewport, but adapts by using a 1:20 ratio, kicking the default font size up a few pixels for readability.

This might not fix all of iPad Mini’s viewport problems, but at least the content would be legible.

Three seven-inch tablets. Note the difference in rendering.

So why did Apple do this?

To understand why Apple would release a product with such a vexing viewport, we don’t have to look further than our own habits.

In the wake of the iPad’s initial release, web folk worldwide scrambled to adapt sites to look good on the new tablets. Somewhere along the way many of us collectively settled upon pixel-based notions of tablet-ness, and those notions often resulted in fixed, 1024x768-pixel layouts precisely targeted at these devices.

Were Apple to decrease the device-width value for the iPad Mini on account of its smaller physical size, it would guarantee a second scramble as existing tablet-adapted sites assuming a 1024x768 viewport suddenly looked unexpectedly wretched on the new device.

The responsibility here goes two ways. Browser makers need to provide reliable baselines of viewport and text sizing, yes. But we as implementers also need to stop grasping for pixel-perfect control over our layouts (the “control” is an illusion, anyway).

A way forward

The only way for us to move forward is together. As developers and designers, we need to hold up our end of the bargain and be mindful of how we do our work—and that means letting go of the notion of pixel precision once and for all. We need to earn the trust of browser makers so they hear us out when things just frankly aren’t right. We hope this article illustrates we’re trying to do the right thing. We hope browser makers acknowledge that and follow suit.

Standards and consistency are more important now than ever before. Please let browser makers and device manufacturers, like Apple, know that we rely on consistent and reliable decisions about default viewports and their zooming. We’re willing to hold up our end of the agreement, and we need them with us.

Let’s move into the future—together.


RSS readers: Don't forget to join the discussion!


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