Social media is so common nowadays, you might assume every business is clamoring to use it at the earliest possible opportunity. Surprisingly, however, that’s often not the case.

Convincing management that your company should be active on social media takes more than just good old-fashioned “Hey, let’s put on a show” enthusiasm. Executives care about impact on sales volume, revenue and cost. And since management teams are held accountable for financial success, they need to understand how social media management will affect their company’s bottom line before they’ll give it their full support.

How do you do that?

Well, the best way is to show them where social media fits in the sales funnel. Nothing illustrates the sales and revenue-generation process to executives like a sales funnel. So use it to explain the benefits of social media to management teams in a language they can understand.

Traditionally, the sales funnel starts when a prospective customer does something that triggers your sales process — scheduling a meeting with a salesperson, say, or responding to a pay-per-click ad. The advantage of social media, however, is that it allows your company to “extend” its sales funnel by adding three additional stages to the beginning, thus allowing you to beat your competition to prospects and more opportunities to convert prospective clients.

The five categories of the social media sales funnel define where a prospect is in the buying cycle. They also provide a clear list of metrics to measure activities within each stage. When trying to measure ROI it’s important to understand that you will have to connect social media activities to their impact on revenue. This is possible, but I could write a whole separate post on that. So for this post, we’ll focus on the one thing you can absolutely measure today: cost. So let’s go through each category, step by step:

Social Media Sales Cycle Category 1: Exposure

The exposure section of the sales funnel focuses on brand reach. Here the idea is that the more your brand is seen, the more people are likely to remember it. This is essentially the first stage in measuring brand awareness, and in some ways it’s the most important, since the more people you put into the top of the funnel, the more opportunities your company will have to create sales.

In PR and online advertising, exposure is measured in “impressions.” Circulation, viewers or listeners are common measures of impressions in public relations; in social media, fans, followers or subscribers are often used. Bear in mind that in either area, impressions don’t equate to people actually noticing your ad — just because your add pops up during “Here Comes Honey Boo Boo” or on Aunt Janet’s Jon Bon Jovi Facebook fan page, it doesn’t mean somebody will actually hear or see it. We’re simply talking about potential here.

Social media does offer one important advantage over traditional media in this regard: It gives you the chance to significantly increase the number of people who are exposed to your brand at a fraction of the cost.

Key Performance Indicator:

1. Cost per impression

Social Media Sales Cycle Category 2: Influence

The influence section of the funnel describes people who were exposed to your brand by an influencer in your industry. This is a separate category from exposure because those who are exposed to your brand by an influencer convert more readily than those who are simply exposed to your brand. In this way, discovering a brand through an influencer is more like learning about a company through a friend.

As businesses have begun to recognize the power of influence, there’s been a need to measure how influential people are. Companies such as Klout are not only using algorithms to attempt to measure influence, but they’re also creating a marketplace where you can search for influencers in topics that are relevant to your industry.

To quantify the value of influencer outreach, you measure how many influencers mention your brand, estimate the reach achieved through those efforts, and in the next category of the funnel — engagement — measure the response the company receives.

Key Performance Indicators:

1. Cost per site visit

2. Cost per conversion

3. Conversion rate

Social Media Sales Cycle Category 3: Engagement

There has been a lot of debate over exactly what engagement means, but for the purposes of this discussion we will say that engagement describes when somebody takes physical action to interact with your brand during a particular timeframe.

It’s at this stage that you can start quantifying who is engaging with your brand. This is where the value of social media really starts to widen management’s eyes, as it is particularly well suited for this purpose.

What’s more, by its very nature social media facilitates and encourages two-way interactions with brands. So it enjoys a significant advantage over traditional media, which simply isn’t equipped for that level of interaction.

Engagement is placed one level further into the sales funnel because the theory is that people are more likely to buy from your brand if they have taken the time to engage with it. The big difference between exposure and engagement is physical action. Engagement is measured based on the end user having to physically take an action to engage with your brand, for example, clicking on something, typing a comment or sharing a message. Because there are numerous ways someone can engage with a brand on social networks, the ease of getting the data to quantify engagement varies greatly from channel to channel.

Key Performance Indicators:

1. Cost per engagement

2. Cost per site visit

3. Cost per inbound link

4. Cost per click

Social Media Sales Cycle Category 4: Action/conversion

This stage of the new social media sales funnel is actually where most companies would traditionally begin. It’s solely dedicated to qualified leads and prospective customers who go on to purchase your products or services.

Two types of leads are generated through social media:

1) those who are ready to buy now (hard leads)

2) those who have provided their contact information in exchange for content you’ve made available (soft leads)

Once you get to this stage in the funnel, the metrics are the same, but the response is evaluated independently for each social media channel that is used.

Key Performance Indicators:

1. Cost per hard lead

2. Cost per soft lead

3. Conversion rate

Social Media Sales Cycle Category 5: Customer retention

This is probably the most overlooked area of measurement for marketing channels. For some reason, once companies get a customer, they tend to move on and forget to measure the customer’s life cycle. Retention is crucial for determining the overall profitability of customers you generate.

Once prospects have become customers, you use different marketing activities to put them back into the top of the funnel, where they go through the buying stages to make future purchases. Although they go back into the funnel, they tend to go through the stages much more quickly because there is already a familiarity with your brand. If you kept them happy during their first experience, they are more likely to buy again.

You can make more money from existing customers in two core ways:

1) encouraging them to spend more at each transaction
2) encouraging them to purchase more frequently

As a result, you actually perform two types of analyses for existing customers. Similar to action/conversion, the metrics used to evaluate customer retention do not change with each channel. Instead, you measure the performance of each channel to see whether one channel is performing better than another.

Key Performance Indicators:

1. Cost per client serviced

2. Retention rate

Final thoughts

Chances are, once you’re able to explain the benefits of social media through the use of the sales funnel, management will be on board with implementing social media in its operations. This is good news, as social media allows companies to extend the sales funnel and attract customers earlier in the buying cycle, essentially bringing opportunities to the door when traditional marketing would close them out.

Are you measuring the effectiveness of your social media efforts?  What metrics have been helpful to you in getting executive buy-in?

Source: Rignite

SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

When the mockups for the new Financial Times application hit our desks in mid-2012, we knew we had a real challenge on our hands. Many of us on the team (including me) swore that parts of interface would not be possible in HTML5. Given the product team’s passion for the new UI, we rolled up our sleeves and gave it our best shot.

We were tasked with implementing a far more challenging product, without compromising the reliable, performant experience that made the first app so successful.

We didn’t just want to build a product that fulfilled its current requirements; we wanted to build a foundation that we could innovate on in the future. This meant building with a maintenance-first mentality, writing clean, well-commented code and, at the same time, ensuring that our code could accommodate the demands of an ever-changing feature set.

In this article, I’ll discuss some of the changes we made in the latest release and the decision-making behind them. I hope you will come away with some ideas and learn from our solutions as well as our mistakes.

Supported Devices

The first Financial Times Web app ran on iPad and iPhone in the browser, and it shipped in a native (PhoneGap-esque) application wrapper for Android and Windows 8 Metro devices. The latest Web app is currently being served to iPad devices only; but as support is built in and tested, it will be rolled out to all existing supported platforms. HTML5 gives developers the advantage of occupying almost any mobile platform. With 2013 promising the launch of several new Web application marketplaces (eg. Chrome Web Store and Mozilla Marketplace), we are excited by the possibilities that lie ahead for the mobile Web.

Fixed-Height Layouts

The first shock that came from the new mockups was that they were all fixed height. By “fixed height,” I mean that, unlike a conventional website, the height of the page is restricted to the height of the device’s viewport. If there is more content than there is screen space, overflow must be dealt with at a component level, as opposed to the page level. We wanted to use JavaScript only as a last resort, so the first tool that sprang to mind was flexbox. Flexbox gives developers the ability to declare flexible elements that can fill the available horizontal or vertical space, something that has been very tricky to do with CSS. Chris Coyier has a great introduction to flexbox.

Using Flexbox in Production

Flexbox has been around since 2009 and has great support on all the popular smartphones and tablets. We jumped at the chance to use flexbox when we found out how easily it could solve some of our complex layouts, and we started throwing it at every layout problem we faced. As the app began to grow, we found performance was getting worse and worse.

We spent a good few hours in Chrome Developers Tools’ timeline and found the culprit: Shock, horror! — it was our new best friend, flexbox. The timeline showed that some layouts were taking close to 100 milliseconds; reworking our layouts without flexbox reduced this to 10 milliseconds! This may not seem like a lot, but when swiping between sections, 90 milliseconds of unresponsiveness is very noticeable.

Back to the Old School

We had no other choice but to tear out flexbox wherever we could. We used 100% height, floats, negative margins, border-box sizing and padding to achieve the same layouts with much greater performance (albeit with more complex CSS). Flexbox is still used in some parts of the app. We found that its impact on performance was less expensive when used for small UI components.

Page layout time with flexbox

Page layout time without flexbox

Truncation

The content of a fixed-height layout will rarely fit its container; eventually it has to overflow. Traditionally in print, designers have used ellipses (three dots) to solve this problem; however, on the Web, this isn’t the simplest technique to implement.

Ellipsis

You might be familiar with the text-overflow: ellipsis declaration in CSS. It works great, has awesome browser support, but has one shortfall: it can’t be used for text that spans multiple lines. We needed a solution that would insert an ellipsis at the point where the paragraph overflows its container. JavaScript had to step in.

Ellipsis truncation is used throughout.

After an in-depth research and exploration of several different approaches, we created our FTEllipsis library. In essence, it measures the available height of the container, then measures the height of each child element. When it finds the child element that overflows the container, it caps its height to a sensible number of lines. For WebKit-based browsers, we use the little-known -webkit-line-clamp property to truncate an element’s text by a set number of lines. For non-WebKit browsers, the library allows the developer to style the overflowing container however they wish using regular CSS.

Modularization

Having tackled some of the low-level visual challenges, we needed to step back and decide on the best way to manage our application’s views. We wanted to be able to reuse small parts of our views in different contexts and find a way to architect rock-solid styling that wouldn’t leak between components.

One of the best decisions we made in implementing the new application was to modularize the views. This started when we were first looking over the designs. We scribbled over printouts, breaking the page down into chunks (or modules). Our plan was to identify all of the possible layouts and modules, and define each view (or page) as a combination of modules sitting inside the slots of a single layout.

Each module needed to be named, but we found it very hard to describe a module, especially when some modules could have multiple appearances depending on screen size or context. As a result, we abandoned semantic naming and decided to name each component after a type of fruit — no more time wasted thinking up sensible, unambiguous names!

An example of a module’s markup:

<div class="apple">
  <h2 class="apple_headline">{{headline}}</h2>
  <h3 class="apple_sub-head">{{subhead}}</h3>
  <div class="apple_body">{{body}}</div>
</div>

An example of a module’s styling:

.apple {}

.apple_headline {
  font-size: 40px;
}

.apple_sub-head {
  font-size: 20px;
}

.apple_body {
  font-size: 14px;
  column-count: 2;
  color: #333;
}

Notice how each class is prefixed with the module’s name. This ensures that the styling for one component will never affect another; every module’s styling is encapsulated. Also, notice how we use just one class in our CSS selectors; this makes our component transportable. Ridding selectors of any ancestral context means that modules may be dropped anywhere in our application and will look the same. This is all imperative if we want to be able to reuse components throughout the application (and even across applications).

What If a Module Needs Interactions?

Each module (or fruit) has its own markup and style, which we wrote in such a way that it can be reused. But what if we need a module to respond to interactions or events? We need a way to bring the component to life, but still ensure that it is unbound from context so that it can be reused in different places. This is a little trickier that just writing smart markup and styling. To solve this problem, we wrote FruitMachine.

Reusable Components

FruitMachine is a lightweight library that assembles our layout’s components and enables us to declare interactions on a per-module basis. It was inspired by the simplicity of Backbone views, but with a little more structure to keep “boilerplate” code to a minimum. FruitMachine gives our team a consistent way to work with views, while at the same time remaining relatively unopinionated so that it can be used in almost any view.

The Component Mentality

Thinking about your application as a collection of standalone components changes the way you approach problems. Components need to be dumb; they can’t know anything of their context or of the consequences of any interactions that may occur within them. They can have a public API and should emit events when they are interacted with. An application-specific controller assembles each layout and is the brain behind everything. Its job is to create, control and listen to each component in the view.

For example, to show a popover when a component named “button” is clicked, we would not hardcode this logic into the button component. Instead “button” would emit a buttonclicked event on itself every time its button is clicked; the view controller would listen for this event and then show the popover. By working like this, we can create a large collection of components that can be reused in many different contexts. A view component may not have any application-specific dependencies if it is to be used across projects.

Working like this has simplified our architecture considerably. Breaking down our views into components and decoupling them from our application focuses our decision-making and moves us away from baking complex, heavily dependent modules into our application.

The Future of FruitMachine

FruitMachine was our solution to achieve fully transportable view components. It enables us to quickly define and assemble views with minimal effort. We are currently using FruitMachine only on the client, but server-side (NodeJS) usage has been considered throughout development. In the coming months, we hope to move towards producing server-side-rendered websites that progressively enhance into a rich app experience.

You can find out more about FruitMachine and check out some more examples in the public GitHub repository.

Retina Support

The Financial Times’ first Web app was released before the age of “Retina” screens. We retrofitted some high-resolution solutions, but never went the whole hog. For our designers, 100% Retina support was a must-have in the new application. We developers were sick of maintaining multiple sizes and resolutions of each tiny image within the UI, so a single vector-based solution seemed like the best approach. We ended up choosing icon fonts to replace our old PNGs, and because they are implemented just like any other custom font, they are really well supported. SVG graphics were considered, but after finding a lack of support in Android 2.3 and below, this option was ruled out. Plus, there is something nice about having all of your icons bundled up in a single file, whilst not sacrificing the individuality of each graphic (like sprites).

Our first move was to replace the Financial Times’ logo image with a single glyph in our own custom icon font. A font glyph may be any color and size, and it always looks super-sharp and is usually lighter in weight than the original image. Once we had proved it could work, we began replacing every UI image and icon with an icon font alternative. Now, the only pixel-based image in our CSS is the full-color logo on the splash screen. We used the powerful but rather archaic-looking FontForge to achieve this.

Once past the installation phase, you can open any font file in FontForge and individually change the vector shape of any character. We imported SVG vector shapes (created in Adobe Illustrator) into suitable character slots of our font and exported as WOFF and TTF font types. A combination of WOFF and TTF file formats are required to support iOS, Android and Windows devices, although we hope to rely only on WOFFs once Android gains support (plus, WOFFs are around 25% smaller in file size than TTFs).

The Financial Times’ icon font in Font Forge

Images

Article images are crucial for user engagement. Our images are delivered as double-resolution JPEGs so that they look sharp on Retina screens. Our image service (running ImageMagick) outputs JPEGs at the lowest possible quality level without causing noticeable degradation (we use 35 for Retina devices and 70 for non-Retina). Scaling down retina size images in the browser enables us to reduce JPEG quality to a lower level than would otherwise be possible without compression artifacts becoming noticeable. This article explains this technique in more detail.

It’s worth noting that this technique does require the browser to work a little harder. In old browsers, the work of scaling down many large images could have a noticeable impact on performance, but we haven’t encountered any serious problems.

Native-Like Scrolling

Like almost any application, we require full-page and subcomponent scrolling in order to manage all of the content we want to show our users. On desktop, we can make use of the well-established overflow CSS property. When dealing with the mobile Web, this isn’t so straightforward. We require a single solution that provides a “momentum” scrolling experience across all of the devices we support.

overflow: scroll

The overflow: scroll declaration is becoming usable on the mobile Web. Android and iOS now support it, but only since Android 3.0 and iOS 5. IOS 5 came with the exciting new -webkit-overflow-scrolling: touch property, which allows for native momentum-like scrolling in the browser. Both of these options have their limitations.

Standard overflow: scroll and overflow: auto don’t display scroll bars as users might expect, and they don’t have the momentum touch-scrolling feel that users have become accustomed to from their native apps. The -webkit-overflow-scrolling: touch declaration does add momentum scrolling and scroll bars, but it doesn’t allow developers to style the scroll bars in any way, and has limited support (iOS 5+ and Chrome on Android).

A Consistent Experience

Fragmented support and an inconsistent feel forced us to turn to JavaScript. Our first implementation used the TouchScroll library. This solution met our needs, but as our list of supported devices grew and as more complex scrolling interactions were required, working with it became trickier. TouchScroll lacks IE 10 support, and its API interface is difficult to work with. We also tried Scrollability and Zynga Scroller, neither of which have the features, performance or cross-browser capability we were looking for. Out of this problem, FTScroller was developed: a high-performance, momentum-scrolling library with support for iOS, Android, Playbook and IE 10.

FTScroller

FTScroller’s scrolling implementation is similar to TouchScroll’s, with a flexible API much like Zynga Scroller. We added some enhancements, such as CSS bezier curves for bouncing, requestAnimationFrame for smoother frame rates, and support for IE 10. The advantage of writing our own solution is that we could develop a product that exactly meets our requirements. When you know the code base inside out, fixing bugs and adding features is a lot simpler.

FTScroller is dead simple to use. Just pass in the element that will wrap the overflowing content, and FTScroller will implement horizontal or vertical scrolling as and when needed. Many other options may be declared in an object as the second argument, for more custom requirements. We use FTScroller throughout the Financial Times’ Web app for a consistent cross-platform scrolling experience.

A simple example:

var container = document.getElementById('scrollcontainer');
var scroller = new FTScroller(container);

The Gallery

The part of our application that holds and animates the page views is known as the “gallery.” It consists of three divisions: left, center and right. The page that is currently in view is located in the center pane. The previous page is positioned off screen in the left-hand pane, and the next page is positioned off screen in the right-hand pane. When the user swipes to the next page, we use CSS transitions to animate the three panes to the left, revealing the hidden right pane. When the transition has finished, the right pane becomes the center pane, and the far-left pane skips over to become the right pane. By using only three page containers, we keep the DOM light, while still creating the illusion of infinite pages.

Infinite scrolling made possible with a three-pane gallery

Making It All Work Offline

Not many Web apps currently offer an offline experience, and there’s a good reason for that: implementing it is a bloody pain! The application cache (AppCache) at first glance appears to be the answer to all offline problems, but dig a little deeper and stuff gets nasty. Talks by Andrew Betts and Jake Archibald explain really well the problems you will encounter. Unfortunately, AppCache is currently the only way to achieve offline support, so we have to work around its many deficiencies.

Our approach to offline is to store as little in the AppCache as possible. We use it for fonts, the favicon and one or two UI images — things that we know will rarely or never need updating. Our JavaScript, CSS and templates live in LocalStorage. This approach gives us complete control over serving and updating the most crucial parts of our application. When the application starts, the bare minimum required to get the app up and running is sent down the wire, embedded in a single HTML page; we call this the preload.

We show a splash screen, and behind the scenes we make a request for the application’s full resources. This request returns a big JSON object containing our JavaScript, CSS and Mustache templates. We eval the JavaScript and inject the CSS into the DOM, and then the application launches. This “bootstrap” JSON is then stored in LocalStorage, ready to be used when the app is next started up.

On subsequent startups, we always use the JSON from LocalStorage and then check for resource updates in the background. If an update is found, we download the latest JSON object and replace the existing one in LocalStorage. Then, the next time the app starts, it launches with the new assets. If the app is launched offline, the startup process is the same, except that we cannot make the request for resource updates.

Images

Managing offline images is currently not as easy as it should be. Our image requests are run through a custom image loader and cached in the local database (IndexedDB or WebSQL) so that the images can be loaded when a network connection is not present. We never load images in the conventional way, otherwise they would break when users are offline.

Our image-loading process:

1. The loader scans the page for image placeholders declared by a particular class.
2. It takes the src attribute of each image placeholder found and requests the source from our JavaScript image-loader library.
3. The local database is checked for each image. Failing that, a single HTTP request is made listing all missing images.
4. A JSON array of Base64-encoded images is returned from the HTTP response and stored separately in the local database.
5. A callback is fired for each image request, passing the Base64 string as an argument.
6. An element is created, and its src attribute is set to the Base64 data-URI string.
7. The image is faded in.

I should also mention that we compress our Base64-encoded image strings in order to fit as many images in the database as possible. My colleague Andrew Betts goes into detail on how this can be achieved.

In some cases, we use this cool trick to handle images that fail to load:

<img src="image.jpg" onerror="this.style.display='none';" />

Ever-Evolving Applications

In order to stay competitive, a digital product needs to evolve, and as developers, we need to be prepared for this. When the request for a redesign landed at the Financial Times, we already had a fast, popular, feature-rich application, but it wasn’t built for change. At the time, we were able to implement small changes to features, but implementing anything big became a slow process and often introduced a lot of unrelated regressions.

Our application was drastically reworked to make the new requirements possible, and this took a lot of time. Having made this investment, we hope the new application not only meets (and even exceeds) the standard of the first product, but gives us a platform on which we can develop faster and more flexibly in the future.

(al)

© Wilson Page for Smashing Magazine, 2013.

Source: Smashing Magazine

SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

Flexible box layout (or flexbox) is a new box model optimized for UI layout. As one of the first CSS modules designed for actual layout (floats were really meant mostly for things such as wrapping text around images), it makes a lot of tasks much easier, or even possible at all. Flexbox’s repertoire includes the simple centering of elements (both horizontally and vertically), the expansion and contraction of elements to fill available space, and source-code independent layout, among others abilities.

Flexbox has lived a storied existence. It started as a feature of Mozilla’s XUL, where it was used to lay out application UI, such as the toolbars in Firefox, and it has since been rewritten multiple times. The specification has only recently reached stability, and we have fairly complete support across the latest versions of the leading browsers.

There are, however, some caveats. The specification changed between the implementation in Internet Explorer (IE) and the release of IE 10, so you will need to use a slightly different syntax. Chrome currently still requires the -webkit- prefix, and Firefox and Safari are still on the much older syntax. Firefox has updated to the latest specification, but that implementation is currently behind a runtime flag until it is considered stable and bug-free enough to be turned on by default. Until then, Firefox still requires the old syntax.

When you specify that an element will use the flexbox model, its children are laid out along either the horizontal or vertical axis, depending on the direction specified. The widths of these children expand or contract to fill the available space, based on the flexible length they are assigned.

Example: Horizontal And Vertical Centering (Or The Holy Grail Of Web Design)

Being able to center an element on the page is perhaps the number one wish among Web designers — yes, probably even higher than gaining the highly prized parent selector or putting IE 6 out of its misery (OK, maybe a close second then). With flexbox, this is trivially easy. Let’s start with a basic HTML template, with a heading that we want to center. Eventually, once we’ve added all the styling, it will end up looking like this vertically and horizontally centered demo.

<!DOCTYPE html>
<html lang="en">
<head>
   <meta charset="utf-8"/>
   <title>Centering an Element on the Page</title>
</head>
<body>
   <h1>OMG, I’m centered</h1>
</body>
</html>

Nothing special here, not even a wrapper div. The magic all happens in the CSS:

html {
   height: 100%;
} 

body {
   display: -webkit-box;   /* OLD: Safari,  iOS, Android browser, older WebKit browsers.  */
   display: -moz-box;   /* OLD: Firefox (buggy) */ 
   display: -ms-flexbox;   /* MID: IE 10 */
   display: -webkit-flex;    /* NEW, Chrome 21+ */
   display: flex;       /* NEW: Opera 12.1, Firefox 22+ */

   -webkit-box-align: center; -moz-box-align: center; /* OLD… */
   -ms-flex-align: center; /* You know the drill now… */
   -webkit-align-items: center;
   align-items: center;

    -webkit-box-pack: center; -moz-box-pack: center; 
   -ms-flex-pack: center; 
   -webkit-justify-content: center;
   justify-content: center;

   margin: 0;
   height: 100%;
   width: 100% /* needed for Firefox */
} 

h1 {
   display: -webkit-box; display: -moz-box;
   display: -ms-flexbox;
   display: -webkit-flex;
   display: flex;
 
   -webkit-box-align: center; -moz-box-align: center;
   -ms-flex-align: center;
   -webkit-align-items: center;
   align-items: center;

   height: 10rem;
}

I’ve included all of the different prefixed versions in the CSS above, from the very oldest, which is still needed, to the modern and hopefully final syntax. This might look confusing, but the different syntaxes map fairly well to each other, and I’ve included tables at the end of this article to show the exact mappings.

This is not exactly all of the CSS needed for our example, because I’ve stripped out the extra styling that you probably already know how to use in order to save space.

Let’s look at the CSS that is needed to center the heading on the page. First, we set the html and body elements to have 100% height and remove any margins. This will make the container of our h1 take up the full height of the browser’s window. Firefox also needs a width specified on the body to force it to behave. Now, we just need to center everything.

Enabling Flexbox

Because the body element contains the heading that we want to center, we will set its display value to flex:

body {
   display: flex;
}

This switches the body element to use the flexbox layout, rather than the regular block layout. All of its children in the flow of the document (i.e. not absolutely positioned elements) will now become flex items.

The syntax used by IE 10 is display: -ms-flexbox, while older Firefox and WebKit browsers use display: -prefix-box (where prefix is either moz or webkit). You can see the tables at the end of this article to see the mappings of the various versions.

What do we gain now that our elements have been to yoga class and become all flexible? They gain untold powers: they can flex their size and position relative to the available space; they can be laid out either horizontally or vertically; and they can even achieve source-order independence. (Two holy grails in one specification? We’re doing well.)

Centering Horizontally

Next, we want to horizontally center our h1 element. No big deal, you might say; but it is somewhat easier than playing around with auto margins. We just need to tell the flexbox to center its flex items. By default, flex items are laid out horizontally, so setting the justify-content property will align the items along the main axis:

body {
   display: flex;
   justify-content: center;
}

For IE 10, the property is called flex-pack, while for older browsers it is box-pack (again, with the appropriate prefixes). The other possible values are flex-start, flex-end, space-between and space-around. These are start, end, justify and distribute, respectively, in IE 10 and the old specification (distribute is, however, not supported in the old specification). The flex-start value aligns to the left (or to the right with right-to-left text), flex-end aligns to the right, space-between evenly distributes the elements along the axis, and space-around evenly distributes along the axis, with half-sized spaces at the start and end of the line.

To explicitly set the axis that the element is aligned along, you can do this with the flex-flow property. The default is row, which will give us the same result that we’ve just achieved. To align along the vertical axis, we can use flex-flow: column. If we add this to our example, you will notice that the element is vertically centered but loses the horizontal centering. Reversing the order by appending -reverse to the row or column values is also possible (flex-flow: row-reverse or flex-flow: column-reverse), but that won’t do much in our example because we have only one item.

There are some differences here in the various versions of the specification, which are highlighted at the end of this article. Another caveat to bear in mind is that flex-flow directions are writing-mode sensitive. That is, when using writing-mode: vertical-rl to switch to vertical text layout (as used traditionally in China, Japan and Korea), flex-flow: row will align the items vertically, and column will align them horizontally.

Centering Vertically

Centering vertically is as easy as centering horizontally. We just need to use the appropriate property to align along the “cross-axis.” The what? The cross-axis is basically the axis perpendicular to the main one. So, if flex items are aligned horizontally, then the cross-axis would be vertical, and vice versa. We set this with the align-items property (flex-align in IE 10, and box-align for older browsers):

body {
   /* Remember to use the other versions for IE 10 and older browsers! */
   display: flex;
   justify-content: center;
   align-items: center;
}

This is all there is to centering elements with flexbox! We can also use the flex-start (start) and flex-end (end) values, as well as baseline and stretch. Let’s have another look at the finished example:

Simple horizontal and vertical centering using flexbox. Larger view.

You might notice that the text is also center-aligned vertically inside the h1 element. This could have been done with margins or a line height, but we used flexbox again to show that it works with anonymous boxes (in this case, the line of text inside the h1 element). No matter how high the h1 element gets, the text will always be in the center:

h1 {
   /* Remember to use the other versions for IE 10 and older browsers! */
   display: flex;
   align-items: center;
   height: 10rem;
}

Flexible Sizes

If centering elements was all flexbox could do, it’d be pretty darn cool. But there is more. Let’s see how flex items can expand and contract to fit the available space within a flexbox element. Point your browser to this next example.

An interactive slideshow built using flexbox. Larger view.

The HTML and CSS for this example are similar to the previous one’s. We’re enabling flexbox and centering the elements on the page in the same way. In addition, we want to make the title (inside the header element) remain consistent in size, while the five boxes (the section elements) adjust in size to fill the width of the window. To do this, we use the new flex property:

section {
   /* removed other styles to save space */
   -prefix-box-flex: 1; /* old spec webkit, moz */
   flex: 1;
   height: 250px;
}

What we’ve just done here is to make each section element take up 1 flex unit. Because we haven’t set any explicit width, each of the five boxes will be the same width. The header element will take up a set width (277 pixels) because it is not flexible. We divide the remaining width inside the body element by 5 to calculate the width of each of the section elements. Now, if we resize the browser window, the section elements will grow or shrink.

In this example, we’ve set a consistent height, but this could be set to be flexible, too, in exactly the same way. We probably wouldn’t always want all elements to be the same size, so let’s make one bigger. On hover, we’ve set the element to take up 2 flex units:

section:hover {
   -prefix-box-flex: 2;
   flex: 2;
   cursor: pointer;
}

Now the available space is divided by 6 rather than 5, and the hovered element gets twice the base amount. Note that an element with 2 flex units does not necessarily become twice as wide as one with 1 unit. It just gets twice the share of the available space added to its “preferred width.” In our examples, the “preferred width” is 0 (the default).

Source-Order Independence

For our last party trick, we’ll study how to achieve source-order independence in our layouts. When clicking on a box, we will tell that element to move to the left of all the other boxes, directly after the title. All we have to do is set the order with the order property. By default, all flex items are in the 0 position. Because they’re in the same position, they follow the source order. Click on your favorite person in the updated example to see their order change.

An interactive slideshow with flex-order. Larger view.

To make our chosen element move to the first position, we just have to set a lower number. I chose -1. We also need to set the header to -1 so that the selected section element doesn’t get moved before it:

header {
   -prefix-box-ordinal-group: 1; /* old spec; must be positive */
   -ms-flex-order: -1; /* IE 10 syntax */
   order: -1; /* new syntax */
} 

section[aria-pressed="true"] {
   /* Set order lower than 0 so it moves before other section elements,
      except old spec, where it must be positive.
 */
   -prefix-box-ordinal-group: 1;
   -ms-flex-order: -1;
   order: -1;

   -prefix-box-flex: 3;
   flex: 3;
   max-width: 370px; /* Stops it from getting too wide. */
}

In the old specification, the property for setting the order (box-ordinal-group) accepts only a positive integer. Therefore, I’ve set the order to 2 for each section element (code not shown) and updated it to 1 for the active element. If you are wondering what aria-pressed="true" means in the example above, it is a WAI-ARIA attribute/value that I add via JavaScript when the user clicks on one of the sections.

This relays accessibility hints to the underlying system and to assistive technology to tell the user that that element is pressed and, thus, active. If you’d like more information on WAI-ARIA, check out “Introduction to WAI-ARIA” by Gez Lemon. Because I’m adding the attribute after the user clicks, this example requires a simple JavaScript file in order to work, but flexbox itself doesn’t require it; it’s just there to handle the user interaction.

Hopefully, this has given you some inspiration and enough introductory knowledge of flexbox to enable you to experiment with your own designs.

Syntax Changes

As you will have noticed throughout this article, the syntax has changed a number of times since it was first implemented. To aid backward- and forward-porting between the different versions, we’ve included tables below, which map the changes between the specifications.

* Opera will soon switch to WebKit. It will then require the -webkit- prefix if it has not been dropped by that time.

This takes effect only when there are multiple flex lines, which is the case when flex items are allowed to wrap using the flex-wrap property and there isn’t enough space for all flex items to display on one line. This will align each line, rather than each item.

The flex property is more or less unchanged between the new standard and the draft supported by Microsoft. The main difference is that it has been converted to a shorthand in the new version, with separate properties: flex-grow, flex-shrink and flex-basis. The values may be used in the same way in the shorthand. However, the default value for flex-shrink (previously called negative flex) is now 1. This means that items do not shrink by default. Previously, negative free space would be distributed using the flex-shrink ratio, but now it is distributed in proportion to flex-basis multiplied by the flex-shrink ratio.

In the old version of the specification, the box-direction property needs to be set to reverse to get the same behavior as row-reverse or column-reverse in the later version of the specification. This can be omitted if you want the same behavior as row or column because normal is the initial value.

When setting the direction to reverse, the main flexbox axis is flipped. This means that when using a left-to-right writing system, the items will display from right to left when row-reverse is specified. Similarly, column-reverse will lay out flex items from bottom to top, instead of top to bottom.

The old version of the specification also has writing mode-independent values for box-orient. When using a left-to-write writing system, horizontal may be substituted for inline-axis, and vertical may be substituted for block-axis. If you are using a top-to-bottom writing system, such as those traditional in East Asia, then these values would be flipped.

The wrap-reverse value flips the start and end of the cross-axis, so that if flex items are laid out horizontally, instead of items wrapping onto a new line below, they will wrap onto a new line above.

At the time of writing, Firefox does not support the flex-wrap or older box-lines property. It also doesn’t support the shorthand.

The current specification has a flex-flow shorthand, which controls both wrapping and direction. The behavior is the same as the one in the version of the specification implemented by IE 10. It is also currently not supported by Firefox, so I would recommend to avoid using it when specifying only the flex-direction value.

Conclusion

Well, that’s a (flex-)wrap. In this article, I’ve introduced some of the myriad of possibilities afforded by flexbox. Be it source-order independence, flexible sizing or just the humble centering of elements, I’m sure you can find ways to employ flexbox in your websites and applications. The syntax has settled down (finally!), and implementations are here. All major browsers now support flexbox in at least their latest versions.

While some browsers use an older syntax, Firefox looks like it is close to updating, and IE 11 uses the latest version in leaked Windows Blue builds. There is currently no word on Safari, but it is a no-brainer considering that Chrome had the latest syntax before the Blink-WebKit split. For the time being, use the tables above to map the various syntaxes, and get your flex on.

Layout in CSS is only getting more powerful, and flexbox is one of the first steps out of the quagmire we’ve found ourselves in over the years, first with table-based layouts, then float-based layouts. IE 10 already supports an early draft of the Grid layout specification, which is great for page layout, and Regions and Exclusions will revolutionize how we handle content flow and layout.

Flexbox can be used today if you only need to support relatively modern browsers or can provide a fallback, and in the not too distant future, all sorts of options will be available, so that we can use the best tool for the job. Flexbox is shaping up to be a mighty fine tool.

Further Reading

• “CSS Flexible Box Layout Module” (specification), W3C
• “Flexible Box Layout Module,” Can I Use?
• “Flexible box (‘Flexbox’) layout,” Microsoft
• “Using CSS Flexible Boxes,” Mozilla
• “‘Old’ Flexbox and ‘New’ Flexbox,” Chris Coyier

(al)

© David Storey for Smashing Magazine, 2013.

Source: Smashing Magazine

SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

Everyone is talking about mobile. Some e-commerce websites are venturing into it. Mobile commerce (also known as “m-commerce”) has immense potential, exhibiting a 86% growth rate and hitting $25 billion in 2012 (set to reach $86 billion by 2016, according to eMarketer).

It’s also a whole new platform, with new interaction methods and usage contexts that introduce a host of limitations and pitfalls to watch out for when designing and running an m-commerce website. With few best practices yet established, m-commerce is, to a large degree, unchartered territory when it comes to actual implementation.

This is why we decided to invest the better part of a year at Baymard Institute to conduct a large-scale usability study focusing specifically on m-commerce (following the “think aloud” protocol). We set out to explore the entire mobile shopping experience, including users’ conceptual understanding of m-commerce websites and how users interact with form fields, category navigation, search, product pages, the checkout process, etc.

The 18 m-commerce websites that we tested were: 1-800-Flowers, Amazon, Avis, Best Buy, Buy.com, Coastal.com, Enterprise.com, Fandango, Foot Locker, FTD, GAP, H&M, Macy’s, REI, Southwest Airlines, Toys “R” Us, United Airlines, Walmart.

Despite testing the mobile websites of some of the largest e-commerce players in the world, our subjects encountered 1,000+ usability-related issues during the testing sessions. These usability issues have been analyzed and distilled into 147 design recommendations in a report titled “M-Commerce Usability.” In this article, we’ll share 10 recommendations from that report with you.

While following some of the guidelines would improve the usability of desktop websites, too, there is a major difference in the severity of breaking them. Whereas these guidelines are largely “nice improvements” on desktop, they are among the “vital basics” to get right on an m-commerce website. Thus, most of these usability guidelines are not exclusive to mobile, but they are much more critical to get right in the m-commerce context.

1. Make The Home Page Easily Scannable

Issue: When users are not able to get an overview of the entire website by quickly scanning the home page, they will feel less confident with the website and often end up choosing the wrong path for their task.

70% of the test subjects scrolled up and down the entire page when first landing on a home page or a category list, in what most described as “getting an overview of my options.” These subjects wanted to see their options before deciding which to choose. Even when they knew how they wanted to find a given product, some subjects still chose to get an overview of the home page, presumably to get a better feel for the website on which they were going to shop. In some instances, when a subject found the category they were looking for, they continued to look through one or two other categories to get a better sense of the other options on the website.

Most subjects scanned the whole home page to get an overview of their options and to better understand what they could do on a particular website. Here, one subject continued to explore the home page options, even after having found his desired navigation path of “category” → “men.”

Therefore, making the home page easily scannable is important because this will be the first point of contact for a very large portion of your mobile visitors. This initial impression will have a significant impact on the types of products they expect your website to carry and, just as importantly, not carry. While “easily scannable” might sound a bit vague, three instances of “what not to do” became clear during testing.

Having Too Many Visual Elements

Avoid the confusing eye path that results from placing multiple highly graphical elements that demand attention high up on the home page. This was the case on Macy’s, where approximately 60% of the first viewable part of the home page is plastered with highly graphical content, with at least eight different elements calling for attention:

Multiple subjects were overwhelmed by Macy’s home page because it was very difficult to scan. As one subject expressed it, “I’m desperately trying to get an overview here. There’s so much crap being shoved at my face.” The right-hand image shows typical eye fixations.

This is not to say you cannot have graphics — but limit their size if they are above the fold on the home page, and design them to have a clear eye path.

Not Showing the First Layer of Categories

Another mistake is unnecessarily hiding the category navigation. Some websites have a single “browse categories” option, which takes the user to a new page with the first layer of category choices. If you have a website where the user cannot browse with any method other than category and search (i.e. not by “brand” or “store” directly from the home page) and the number of main category options is of a somewhat manageable size, then this is an oversimplification. Instead, show the first level of category options directly on the home page so that users can start scanning the list immediately upon landing on the home page.

On the left: On Coastal.com, all the category options are displayed directly on the home page, which not only allows direct access, but gives users an accurate idea of the types of products they can expect to find on the website. For stores with multiple ways of browsing the catalog (e.g. by both “category” and “brand”), displaying the category options directly on the home page might not be feasible. On the right: For stores with a very high number of first-layer categories (typically mass merchants), a curated list with the most popular options might prove to be a better option, because displaying all categories would impede scannability.

Moreover, do not present the categories in a drop-down dialog. Multiple subjects explicitly stated that they had to scroll through the entire list to choose the category in which they expected to find a particular product. The problem with a drop-down quickly became clear, then: because it takes up only 50% of the available screen, getting an overview of the available categories became needlessly difficult (see Best Buy below).

Because the gesture area is also only half the size, the subjects also had a much harder time accurately controlling the scrolling speed. Lastly, the drop-down interface element was confused with a filter selection by some subjects and not recognized as the main website category navigation.

Do not follow the example of Best Buy, which does not have a category option in the main body of its home page content. Instead, a “three bars” icon takes the place of a category option in the page’s header. This not only requires all users to understand the meaning of the three bars icon, but also makes it impossible to get an overview of the store by scanning the home page. And, of course, using a drop-down to actually select a category is not ideal either.

Perfect Fold Alignment

Finally, do not design your website to have perfect alignment or white space exactly at the fold. This happens on GAP’s website, where it is easy to doubt whether the home page contains more than a search field and a few graphics (i.e. no category navigation), because these home page elements align precisely with the viewport fold (on an iPhone at least).

One subject, a bit surprised, asked, “This is it? This is the entire page?” believing this was GAP’s entire home page. When elements are spaced with pixel-perfection alignment around the viewport fold, users are more likely to misinterpret the top part as being the entire home page (in this case, missing out on the category navigation below).

To indicate more content, simply align the elements so that some are only partly viewable within the viewport on the most popular mobile devices.

Therefore, when designing a scannable home page:

• Put very few (if any) very visually stimulating graphics above the fold on the home page, and make sure the ones that are there have a clear eye path so that the user can quickly get an overview.
• Try to ensure that the fold (on the most popular mobile devices) partially cuts off some content, to indicate more options below.
• Display navigation options on the home page as a list (not in a drop-down).
• If you have only one category navigation type (such as “product type” or “department,” and not also “brand” or “store”), then show the first level of the category hierarchy directly on the home page either in full or, if there are too many options, as a curated and collapsed list of the most popular choices.
• Only display highlighted or featured products below the search field and the category navigation options.

2. Be Sensitive To People’s Fear Of Losing Their Data

Issue: Typing on mobile devices is clumsy, so users are constantly worried about losing their inputted data.

“Argh, no! Do I have to start over? Now I’m getting angry. Doesn’t it have my shit already?,” a subject moaned, referring to his previously typed address and credit-card information, which suddenly disappeared. “Now I’m leaving. This isn’t a serious store.”

Data persistence is not something to take lightly. Your users certainly don’t. Of course, the recommendation is simple: always persist the user’s data, which requires investing in solid technology, testing thoroughly, and storing inputted data temporarily on the user’s device (most mobile browsers support localStorage). In practice, of course, this is easier said than done, and numerous websites have failed miserably, to the great frustration of users.

Because users have already suffered through many horrible experiences of lost data, they often exhibit extreme caution around certain types of elements and avoid certain interactions when possible. The following screenshot shows the types of actions and elements that particularly worry users. Either avoid these elements altogether or soothe users’ fear with the smart use of microcopy, icons and animations.

During checkout, the subjects consistently opened links in a new window because they were afraid their data would be lost if they opened links in the current window.

Subjects were almost always disturbed by unexpected page reloading (i.e. any page reloading that is not a direct consequence of clicking a link or button). In the image above, a subject selected a “Residence type,” which reloaded the page, causing the subject to immediately scroll up and down to ensure that none of their data was lost. We observed this type of unease with page reloading among subjects time and again throughout testing.

Many subjects were scared by system dialogs and often assumed that they would lose data by clicking “OK,” even though few of them actually read the message. The subject in the test shown above wanted to go backwards in the process to pick another ticket but was met with this dialog, which he cancelled — assuming that he would have to re-enter everything if he wanted to select another ticket.

A good number of the subjects believed that leaving the checkout process would destroy their data and so refused to go back and check for other products. The subject in the test above contemplated going back to find another bouquet of flowers, but decided against it because he did not want to re-enter all of his data. This happened despite many of the test websites actually remembering the users’ details, even if the users left the checkout process midway — the keyword, of course, being “many” websites, rather than “all.” Given this inconsistency, users have no way to know beforehand, so their only safe choice is to just assume the worst on all websites.

During checkout, the “back” button was generally perceived by the subjects to be dangerous, and subjects used it during checkout only when they felt they were out of all other options. In many cases, this perception was justified: numerous websites did indeed fail to persist the user’s data when they used the “back” button. However, equally important is that process step links and other “back” links and buttons that were part of the website’s UI were generally considered by the subjects to be “safe.”

Therefore, including either process steps or “back” links in the checkout is crucial so that users do not feel they have to gamble by using the browser’s “back” button and can instead use your website’s dedicated UI element(s) for the purpose. In the test shown above, the subject hunted up and down to find a link or button that would take him back to the previous step, but was unable to find one. Finally, he tried the browser’s “back” button.

These were the most significant insights relating to users’ fear of lost input. In general, the subjects were vastly more pessimistic about websites on which they had once lost data. For example, clicking the keyboard’s “next” button cleared one subject’s input on a website, which made her consistently avoid that button throughout the rest of the checkout. As she said, “Here, I don’t dare click ‘Next’ anymore because I don’t want to start over again.” Not only that, the subject also became overly cautious when interacting with any fields on the website, fearing that even the slightest hiccup would destroy her data.

A single bad experience set low expectations for the rest of the website. So, how do we avoid bad experiences in cases where we are unable to persist the user’s data due to technical limitations? In these instances, clearly warn the user that they are about to do something destructive.

As the subject left the incomplete checkout, the website warned her that her data would be lost. “This is very good,” the subject remarked, “because if I did something wrong by accident, I would be extremely annoyed if they deleted everything. So, it’s good that they warn me like this if the data would otherwise be lost.”

Persisting data is always the ideal, of course, but warning the user and giving them the option to back out before destroying their data is a good secondary solution, and it sure beats simply destroying the user’s data without warning; moreover, it gives the user a chance to cancel the destructive action. This type of fallback solution could be especially useful for less common navigation paths, where persistent data is too time-consuming to implement, considering how few users it affects.

This could also entail something like persisting the user’s cart or checkout data when switching between the full website and mobile website. In these instances, it is acceptable to simply warn the user that they will lose their data if they proceed, and then give them the option to proceed (and lose their data) or stay (and keep their data).

Data persistence is clearly a complex matter, especially when one considers the user’s expectations towards data persistence. We observed subjects creating accounts merely to ensure persistence, and witnessed data lost due to accidental clicks, and we watched with as much surprise as the subject when an entire form was remembered perfectly by autofill, turning potentially horrible data loss into a small moment of joy. Data persistence is tricky, but getting it right is crucial.

3. Add A Primary Button At The Bottom Of Product Pages

Issue: Users are likely to misinterpret cart buttons in the page’s footer if there is no “Add to Cart” button at the bottom of every product page.

A wide range of the tested websites had multiple identical primary call-to-action (CTA) buttons on product pages (i.e. two “Add to Cart” buttons), one at either the top or middle of the product page and a second one at the bottom.

On Best Buy, one subject read this product’s entire specification sheet and was in the mindset of “Yes, this is the product I want to purchase.” He saw the website’s shopping-cart icon at the bottom of the page (second image above) and clicked it, believing it was an “Add to Cart” button. Logically, he assumed the product would be added to his cart and so continued browsing for more products, only to notice much later in the shopping session that the website had “deleted” his cart’s contents (the TV was never added in the first place).

The subject here on Amazon thought the shopping-cart icon was the button for adding the displayed product to her cart.

It turned out that on the websites with only one CTA button on a product page, subjects often ran into severe problems even with adding a product to their cart — which, in some cases, ultimately led to abandonments. Cart icons in the page’s header or footer were often mistaken for an “Add to Cart” button.

Both Best Buy and Amazon failed to make the primary buttons immediately obvious and generally available, which led subjects to start interpreting various icons on the page, including the cart icon, as shown in the two examples above. Subjects often scrolled to the bottom of a product’s page when looking for the “Add to Cart” button (a behavior confirmed in another study).

This subject started looking for the “Add to cart” button by scrolling to the bottom of the page, then scrolling back to the top of the page, thinking she might have missed it, and finally scrolling down again patiently, until finding the “Add to bag” button in the middle of the page.

To accommodate this behavior and reduce misinterpretation of any cart icons, add a second “Add to Cart” button to the bottom of all of your product pages. A second button there will also support a more natural interaction flow, as the user first reads the product description, then the specification sheet, then the reviews and so on, and then, at the end of the page, decides whether to buy or not. Only if the product page is extremely short (one to two mobile viewports tall) would a single button suffice.

4. Be Very Careful With Animated Carousels

Issue: Users fail to discover vital features that appear only in a carousel, and they have a hard time interacting with carousels themselves.

Animated carousels caused interaction problems for half of the test’s subjects. The carousels simply changed too quickly for some subjects to both read and select an option.

A subject was about to click the “Mega Sale” slide (left image), but the carousel animated to the next slide at the very same moment, forcing the subject to wait for that slide to reappear.

In multiple instances, a subject found a carousel slide interesting and attempted to tap it. However, the carousel changed to the next slide at the very same moment, causing the wrong slide to load. Sometimes the subjects noted this, but sometimes they did not and left the landing page immediately because they did not find it relevant to what they were looking for.

Interestingly, the “Prev” and “Next” buttons in the Toys “R” Us carousel were not used by a single subject during testing, despite these issues:

The carousel changed the very second this subject tapped it, registering a click for “Bike Blast” instead of the “Mega Sale” she wanted. The subject never noticed and assumed that “Bike Blast” was the sale.

Both of these interaction issues were also encountered (and still exist) in the early versions of carousels on full websites, but as carousels have become increasingly popular on e-commerce home pages over the last several of years, they have evolved, so most now stop animating when the user hovers over an option with the mouse.

And most also have an indicator that enables the user to see how many slides a carousel has and, just as importantly, to jump to a particular slide (such as back to the one that piqued their interest but changed too quickly). These interaction issues cannot be easily solved on mobile because there is no hover state and much less screen real estate.

On Toys “R” Us’ home page, the subjects pored over the menus to find a “Gift Guide” wizard but could not find one (image on left). It turns out there is a wizard but is accessible only via a particular slide in the rotating carousel at the top of the page.

Perhaps an even more critical usability issue is that most test subjects simply ignored the carousel after quickly glancing at the first slide. Some waited and looked at two to three slides before focusing elsewhere. This proved critical on some websites, such as Toys “R” Us’, because the majority of subjects were desperately looking in the traditional navigation for certain features (such as the “Gift Finder”) that were accessible only via the carousel. Some subjects spoke at length about how the website really should have some sort of “gift guide,” ultimately abandoning the website because they could not find one.

Users ignore animated carousels for multiple reasons. First, a carousel’s content might look like advertising, depending on how it is styled, greatly increasing the chance of banner blindness (a subgroup of subjects tended to focus much more closely on text-based navigation than on graphics-based navigation). Secondly, when using a large laptop or desktop monitor to browse a full website, the user is able to check out other options on the home page while still glancing at the carousel slides as they change.

On mobile devices, however, the screen is so small that a carousel would take up a significant portion of the viewport, making it practically impossible to scan any navigation or category options while monitoring the carousel slides (one of them will always be partly or completely out of sight). Therefore, if users are to see all options in a carousel on a mobile device, they will have to watch the carousel for its full duration (like a video clip).

Regardless of the cause(s), what is really important is that the vast majority of subjects ignored the animated carousels completely and, on the home page, focused instead on the category navigation and search features. For this reason, be very cautious about relying on carousels for important content, and never have it as the only path to a particular feature.

5. Be Careful Of Showing Product Information Or Images On Separate Subpages

Issue: Users have incredible difficulty understanding the scope of product subpages.

On a mobile device, understanding the scope of the current page is vastly more difficult for users, due to the very small display. Mobile pages often lack the subtle yet vital page-scope cues that are present on full-size pages, such as a full set of breadcrumbs, an overview of the current page, and full URL paths viewable throughout the browsing session.

This lack of scope on mobile makes having any kind of substeps or subpages that refer to a main page very risky, because the user would have to fully understand the scope of the current page in order to appreciate the difference between the subpage and main page.

When users want to see larger versions of images of an Amazon product (left), they are taken to a subpage (middle). Our test subjects clearly noticed that they were still within a product’s particular scope (because of the large product image), but they did not understand where the rest of the product page went (right).

This became immediately apparent when testing websites that offer a “larger view” option of their images, taking users to a separate product subpage, as seen on Amazon above. Because of the apparent lack of access to vital content, such as “Product Description,” “Product Specs” and “User Reviews” (which are available only on the main product page), the subjects who did not notice this change in scope assumed that such content simply did not exist for the given product and continued looking for other products with such information, discarding perfectly matching ones.

Amazon also uses subpages to show full specification lists, causing the exact same issue, except that this time subjects were unable to locate something as vital as the “Add to Cart” button.

On a mobile device, and especially on subpages, understanding the current scope is simply much more difficult. Instead, display your “larger views,” image galleries, detailed specification sheets and the like (i.e. all relevant content) directly on the product’s main page. You could also use progressive disclosure by collapsing each content section by default, to avoid overly long pages; but then be sure to have clear trigger indicators. A strategy such as this minimizes the need to display additional information and images on subpages and the resulting scope issues.

Especially with image galleries, you also have the option of an overlay, as shown above on Foot Locker. With an overlay, the user can still see the product page beneath and have a simple way to get back to it.

6. Be Thoughtful In The Design And Sequence Of Your Three Account-Selection Options

Issue: Users had difficulty figuring out how to initiate “Guest Checkout” and understanding field relationships, selection options and buttons in the account-selection steps.

On mobile, the user’s selection of a checkout type — “create an account,” “sign into account” or “guest checkout” — will be a separate step (unlike on full websites, where it could be integrated into the first step). More than half of the test subjects (60%) had serious trouble identifying, seeing and selecting the guest-checkout option at the account selection step during checkout.

Multiple times, the misunderstandings led subjects to believe that registration was required, despite it being optional, and carried all of the downsides of forced account registration (including abandonments). Therefore, the design of your account-selection screen for mobile is just as important as having a guest-checkout option at all.

Several different design schemes led to these serious misunderstandings, as the following screenshots illustrate.

On Macy’s, subjects saw the account-selection step (above left) after selecting the cart. Some clicked “Express Checkout,” believing they would have a fast checkout (as a guest), only to get form-field validation errors for the two fields because “Express Checkout” requires a Macy’s account (above center). Some only discovered the “Checkout as a Guest” option further down the page (right), after getting this validation error, while others never noticed the guest-checkout option and registered for an account, believing it was required.

On multiple websites (Amazon, Toys “R” Us, REI, GAP, Best Buy), subjects started to interact with the fields, such as by providing their email address (above). On REI, every single subject interacted with the email field before looking for, or figuring out that there was, a guest-checkout option.

In most cases, the subjects spotted the error before submitting the form (typically upon reaching the password field and deducing that they were on an account sign-in or creation form). In such cases, not even detailed analysis of your Web statistics and error logs would reveal these issues because no validation error ever occurs.

On Buy.com, things are even worse. The vast majority of subjects simply could not figure out the relationship between the four checkout methods (sign-in, create account, guest checkout and PayPal checkout), the two form fields, the three radio buttons and the two primary buttons. All tapped the “Checkout as a Guest” option after spending some time trying to understand the page.

Then, the naming of the “Sign in Using Our Secure Server” button utterly confused subjects because they were trying to check out as a guest (and, therefore, actively opted not to sign into anything). This particular naming has been used by Amazon for years and has even been highlighted as a best practice to indicate a secure checkout, so how could it lead to such major misinterpretation?

The reason is that it indicates the user will sign in, which makes sense only if they have an account or will create one, but not if they are checking out as a guest. (Amazon does not offer a guest-checkout option, so the wording makes sense in that context.) Given the button’s name, one subject assumed that the only other prominent button on the page, “Checkout with PayPal,” must be the one to pick to initiate the “Checkout as a guest” selection.

Others finally clicked the oddly named button — but nothing seemed to happen. It turns out that inline text reading “Required” appeared next to the “Enter your eMail Address” label (seen above), but no one noticed it initially. The subjects typically waited for a little while just in case the website did not load, and then clicked again, at which point most realized that they needed to fill in more data. By this point, some, especially those who did not notice the validation error, concluded that they were not allowed to check out as a guest and proceeded to create an account instead.

One explained his experience thusly, “Normally I would think ‘guest checkout’ would let me through without having to create an account. But here I have to fill in my mail, so I have no idea what that option is for, then. To be on the safe side, I’ll then pick the ‘No, I’m a new customer,’ because if I’m forced to create an account, I might as well just do it properly anyways.”

Making the account-selection process clear is as important as offering a guest checkout option. Following two main design principles will help to prevent these serious problems:

• Always place the guest-checkout option at the top, with its own button to proceed, so that the user does not need to fill in an email field in this step. (If needed, you can look up whether the user has an account in the next step, when you ask for their email address, to ensure that they have not selected the guest checkout just because it is the first option in the list.)
• Collapse all of the fields and descriptions for all three options — “guest checkout,” “sign in” and “create an account” — bringing each option down to a single line, making it possible to get an overview in the viewport without having to scroll or expand. Dynamically expand them when tapped, revealing the fields and descriptions. This will also make clear which fields are related (and required) for each option.

Below, we have created a simple mockup to illustrate how account selection can be clarified by combining these two principles:

All three account-selection options are displayed in collapsed state (with guest checkout at the top), so that the user can instantly see all available options. The options can either expand inline (image on right) or redirect to the next step in the checkout process. Progressive disclosure also makes the relationship between an option and its fields much clearer.

7. Disable Autocorrection When The Dictionary Is Weak

Issue: Poor autocorrection is frustrating when users notice it, and can be detrimental when they do not.

Autocorrection usually works poorly for abbreviations, street names, email addresses and similar words that are not in the dictionary. This caused significant problems throughout testing and resulted in a great deal of erroneous data being submitted as subjects completed their purchases.

When this subject typed in his street name, “westheimer,” the phone incorrectly autocorrected this to “weathermen” (left). However, the subject did not notice this, submitted the form and received a validation error (right).

One of the major issues of autocorrection was that the subjects often failed to notice the correction (because they were often focused on what they were typing, instead of what they had typed). This is fine if the “correction” is correct, but it can be detrimental if it is wrong. For example, in multiple instances, a valid address was autocorrected to an invalid one and submitted because the subject failed to notice it.

On websites without address validators, this resulted in wrong addresses being submitted, unless the subject was particularly attentive on the order review page. After all, the user’s address will often be replaced with something that looks very similar, although incorrect. In addition to the “weathermen” example, official address abbreviations, such as “Rd,” were autocorrected, to “Ed.”

That being said, autocorrection did prove very helpful when it worked. So, don’t disable it in all fields. Use it discreetly, and disable it on fields for which autocorrection dictionaries are weak. This typically includes names of various sorts (street, city, user) and other identifiers (such as email address).

You can disable autocorrection by adding an autocorrect attribute to the input tag and setting it to off, like so:

<input type="text" autocorrect="off" />

8. Make Fields Long Enough To Fully Display Common Data (And Put Labels Above Fields)

Issue: Users cannot easily spot errors, let alone correct them, when the field is too short to display the entire inputted data.

Due to the small size of mobile screens, form fields often get so short that users cannot self-validate before submitting their data, and users have a very difficult time correcting any validation errors because they cannot see the inputted data in its entirety.

“I can’t see what I’ve typed. Argh. Then I’ll delete everything and retype it.” On REI, a validation error for an email field that was too short to be displayed in its entirety made it impossible for the subject to see what the actual error was. In trying to pan the inputted text, the subject accidentally enabled both the iOS text-selection tool and the text-replacement tool.

Form fields that are too short presented problems for many subjects who tried to confirm the validity of their data before submitting it. They often made complaints such as, “I can’t see if the emails are the same when the email field isn’t long enough.” Some examples are seen below.

On the left: Amazon’s email field is too short, despite the abundance of white space. In the middle: United’s credit-card field shows only 15 characters, even though most card numbers are 16 digits. On the right: Macy’s email fields are too short for users to verify whether the two addresses they’ve inputted match.

Given how easy it is to make a typing mistake on a mobile device, fields that are not long enough to allow users to validate their data before submission are very harmful to the typing experience. Even worse, they make correcting any validation errors unnecessarily difficult.

Note that in the case of Amazon and the earlier example from REI, the white space is sufficient to make the field much longer, while the other two examples have no additional space to make the fields longer because the labels are all left-aligned. For this very reason, labels should be placed above form fields to allow full use of the space and to display all of the user’s data (at a decent font size). Displaying labels to the left of the fields would be acceptable only when the device is in landscape mode (as explained in detail in “Mobile Form Usability: Place Labels Above the Field”).

An adequate width for email and address lines is the full screen. Then, adjust the font size of the fields to allow for the full display of reasonably long data, such as first.lastname@my-company.com. (The character-length distribution of our own newsletter list shows that 96% of email addresses are 30 characters or fewer.)

9. Enable Users To Verify The Inputted Day And Date

Issue: Using text fields for dates requires unnecessary mental processing of the user and can cause serious selection errors.

During testing, websites that had only a simple text field or drop-down dialog for date selection presented problems for 80% of the subjects.

This subject was among the 80% who were unsure which date “this Friday” was. So, she decided to count the days on her hand, wanting to make sure she picked the right one.

This happened with both Southwest (which uses drop-downs for the month and day) and United (which shows a text field for writing MM/DD/YYYY). On both of these websites, the following scenarios occurred:

• A handful of subjects had to count the days on their hand (as explained above).

• Half of the subjects went off-site and opened the phone’s native calendar app to double-check the date for their weekend trip (to confirm “this Friday”). In the instance seen above, this calendar verification goes completely awry because the subject checked the day of June 15th, instead of July 15th, and ended up purchasing a flight ticket for his “weekend” trip that left on a Sunday and returned on a Tuesday.

  

• Lastly, a few struggled with typing and using the text-selection tool to enter the correct date on a website that uses a text field for date selection.

  

By contrast, on the three test websites that provided a graphical interface for inputting dates in the form of a calendar view (namely, Enterprise, Avis and 1-800-Flowers, seen above), not a single one of these issues arose, and the subjects generally liked being able to verify the day and date they were selecting. This could potentially save customers from incorrectly counting or “verifying” the wrong weekday (as mentioned earlier) and thus booking the wrong date.

While this is an annoyance on desktop as well (since the user would be no better equipped to spot the errors there), the severity and impact on the user’s experience is much greater in mobile when it comes to correcting the erroneous data, because panning and editing truncated data on a three- or four-inch touchscreen is much more cumbersome than using a mouse or keyboard arrows on a desktop. Furthermore, ordering tickets on the wrong day is much less likely on the desktop because the booking form and a separate calendar application can be displayed next to each other — whereas on mobile, only one can be viewed at a time.

Therefore, always provide an interface that enables users to verify the day of their selected date. One option is to display a calendar interface in which the user explicitly selects the date they want. That would simplify the actual selection interface and, more importantly, gives users a chance to verify the day. If you already use a drop-down for date inputs and do not want to replace it, you could instead append the day after each date option (for example, “March 15 – Monday”); although that would require the month to be included in each drop-down day value or, in case a separate drop-down is used to select the month, you would need to dynamically update the day names depending on the currently selected month.

10. Make The Hit Area For Each List Item Distinct

Issue: With some lists, users simply have no idea where to tap in order to select an item.

Can the entire “element” be tapped? Or only the product title? And what about the thumbnail? During testing, multiple issues arose as subjects were unsure of where to tap in order to select an item in a list. This was by far the worst on websites where list items were above the recommended half-screen height. In fact, one subject got completely stuck and was unable to complete her purchase.

The problem was by no means limited to websites with list items that were too tall; it was just worse on those websites. The issue also extended to websites whose list items were normal in size but whose hit areas were unclear, which severely limited the subjects and even resulted in abandonments.

It simply was not clear to subjects what can and cannot be clicked on this page. Note the very inconsistent link styles. Orange is sometimes used for the header, other times for a list item. Separators are sometimes used to set off list items, other times to set off elements of text. Some text is one shade of blue, which sometimes indicates a link, while other links are styled in a darker blue and underlined. Confused yet? The subjects were, too.

Note how the subject was trying to click the “Lowest Fare” label, believing this was the button to choose the displayed flight. Besides the primary button being unclear, the list item is also very long. Combined, these two design choices are a surefire way to leave some users in doubt on how to even proceed.

On the left: This subject did not know what to click in order to proceed on United’s website. Presumably, this was caused by the single result. With no options to compare and choose between, it was not clear to the subject what to select. On the right: Many subjects did not pick up on the ticket icon and its meaning on Fandango’s website. Instead, they assumed that the movie was playing only in theaters where a “Buy” button was shown (which was not the case).

The images above show only some of the many instances where it was unclear to subjects what elements are clickable, what the differences are between the different hit areas and, most importantly, where to click in order to select an item in a list. The websites with the far fewest problems with hit areas embraced multiple of the following recommendations:

• Make the entire element area clickable. In particular, the thumbnail, product header and price should be clickable and should lead to the product page.
• Style the title as a link (using your primary style for text links).
• Indicate the virtual space with an arrow or similar visual cue, showing that the entire list item will move the user to the next step in the process.
• Consider separate “Buy Now” or select buttons for very long list items — i.e. when a list item could be easily mistaken as pieces of information, rather than a collective entity to be clicked.
• Avoid multiple hit areas within the same visual element — in particular, links or buttons within a list item that lead to different pages.

Designing M-Commerce Websites

Aside from their practical use, these 10 recommendations have hopefully given you a glimpse of just how complex designing an m-commerce website really can be. It’s not simply a matter scaling and adding media queries; it’s an entirely new platform, and the balancing act is particularly difficult to get right due to the complex tasks involved, such as product finding and product comparison and multi-step processes such as checking out. In many ways, designing and optimizing an m-commerce website is much more difficult and often requires more “intelligent” website features than a traditional desktop e-commerce website. It comes as no surprise that IBM reports average m-commerce conversion rates that are roughly half of its desktop e-commerce conversion rates.

In general, the more complex a mobile website’s features, the more likely the experience should be significantly different from the desktop experience. The greater the difference between the two, the stronger the argument for having a standalone mobile website. Of course, maintaining two versions of the same website comes with many issues, especially with maintenance (of content, code and design). A responsive design is a better solution in some cases, but it depends very much on the size and complexity of the website, as well as on your organization’s strengths and weaknesses. It’s a nuanced issue, with many gray areas and with good arguments both for and against having a standalone mobile website.

If you can achieve this by designing for mobile first, then a responsive design could be truly great — not just in its maintainability, but also its user experience. Be clear, however, that if your existing website is complex, merely scaling it down to different devices won’t be enough to offer a great mobile experience. And if messing with the full website’s existing structure and content isn’t an option, then you might be forced to create a standalone mobile website in order to provide a decent experience — although maintaining content and code on the two separate platforms in parallel could turn out to be both expensive and messy.

Thus, getting an m-commerce website right tends to be very resource-demanding, as you account for all of the nuances. But the opportunities are great. This is a new world, and it will take time before best practices stabilize. Spending time and money on a mediocre m-commerce website is wasteful. Yes, making the website great will require significant investment, but the potential payoff is high, too. M-commerce is a window of opportunity; it enables you to distinguish yourself from competitors and to position yourself well to grab a share of this market, which is expected to reach $86 billion by 2016.

Note: Find out more about m-commerce usability guidelines in the (paid) report “M-Commerce Usability.”

(al) (il)

© Christian Holst for Smashing Magazine, 2013.

Source: Smashing Magazine

SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

Good typography has always been a defining aspect of effective Web design, and this holds true especially for websites in which the emphasis is on presenting a large amount of content — specifically, articles, news and stories. Whether for a magazine or international newspaper, the designer of any website that distributes a lot of content has always had to consider typographic details as seriously and thoroughly as a print designer would.

In 2009, we conducted a survey of then current typographic practices. Since then, responsive design techniques have clearly gained momentum and established their place in the landscape of CSS layout. With the advent of mobile, new modes of browsing websites and reading text have emerged.

Online publications have had to reevaluate how their content is presented on mobile devices. Web typography is as rich, versatile and accessible as ever before. Yet new opportunities introduce new complexity; and with new implementation challenges, we are all spurred to reconsider our practices.

Now, three years later, we’ve reviewed the original study and explored how Web typography has changed over these years. We spent countless hours between February and April of this year collecting new data and exploring common developments and trends in Web typography.

How Did We Conduct The Study?

We have compiled relevant data from over 50 well-respected websites to address these questions. For this study, we selected a wide variety of international newspapers, magazines and blogs, all of whose typographic choices should have been carefully and thoroughly weighed. We chose publications and organizations that have a very large readership (such as The Boston Globe and The Financial Times) as well as specialized magazines with smaller yet often more demanding readerships (such as A List Apart and UX Booth).

These websites focus primarily on text-based content rather than on generic environments such as Instapaper and Readability. As such, they need to be highly legible in order to ensure that users continue visiting and reading on their websites. Because readability of content is (or rather should be) the main design goal of these publications, the techniques they follow could be considered good practices. However, the results presented in this study should be taken with a grain of salt.

The questions asked in our first study nearly four year ago remain relevant but need to be complemented by questions about the challenges of mobile devices. How widely has responsive design been adopted by publications, if at all? Has there been any change in the typographic choices of big and small publications? How many weights of a large font family should we deliver to mobile devices? How large should the font size of body copy be? How should the font size change on a responsive website? Optimizing readability could require changing the font’s style, size and spacing according to the viewport’s width and height.

The second article in this series will address the growing diversity of eBook readers and mobile apps whose purpose is to give users a pleasant, improved or enhanced reading experience — from desktop readers down to smartphone readers. We were curious about the specifics of design and typographic choices that make reading articles in these applications more pleasing than reading on the original websites.

Note: For the sake of continuity, we have stayed close to the format of the original study from 2009. This article is meant to update the data, and hopefully detect new trends and reach new conclusions.

Typography In Online Publications

After carefully analyzing the style sheets in the publications in this study, we compiled a comprehensive spreadsheet of typographic points and collected the relevant data. You can view a spreadsheet of the raw data, which contains more data than was pertinent to this article.

Not limiting ourselves to the questions in the original study, we will broach issues that have arisen since then as a result of responsive design techniques, and we’ll examine whether such techniques are being applied at all. This led us to the following questions:

1. How popular are serif and sans-serif typefaces in body copy and headlines?
2. Which fonts are used most frequently?
3. What is the average font size (on narrow, mid-sized and large screens)?
4. What is the average ratio of the font sizes of headlines to the font sizes of body copy?
5. What is the average line height of body copy?
6. What is the average ratio of line height to font size in body copy?
7. What is the average ratio of line height to line length in body copy?
8. What is the average amount of space between paragraphs?
9. What is the average ratio of paragraph spacing to line height in body copy?
10. How are links styled?
11. How many characters per line are common in body copy?
12. How often are links underlined?
13. How often are font fallbacks used?
14. How often are responsive design techniques implemented?
15. Which ratios of display sizes are discernible?
16. How do websites deal with the performance of Web fonts?

To answer these questions, we collected more than 40 data points, all of which can be found in the aforementioned spreadsheet. We can extract several rules of thumb from this data. We wouldn’t recommend acting on the data from this study blindly; the statistical data, however, will no doubt yield useful insights.

Popular Serif And Sans-Serif Fonts

“Which typeface to use?” Obviously, this is one of the most important questions a designer has to answer when considering Web typography. The typeface will set the tone for the entire website, and a poor choice could send the wrong message or thwart the intended atmosphere. The argument for either serif or sans-serif hasn’t been won yet. Interestingly, looking back to the results of the 2009 study, sans-serif typefaces seemed to be more popular in body copy and headlines. The last four years have seen a tiny shift away from that.

Serif and sans-serif are almost equally popular in headlines.

The motivations of designers likely haven’t changed much. Serif fonts apparently stand out in headlines, but arguments have been made for serifs’ ability to guide the reader and for its readable structure in body copy as well. Still, contrasting a serif body with a sans-serif headline or vice versa can improve the overall visual appeal and readability of a website.

The data suggests that serifs have gained in popularity in recent years, leading almost to a reversal in common usage in the last four years, at least where body copy is concerned.

Serifs have strongly gained in popularity in body copy.

• Half of the websites analyzed use serifs in their headlines, the other half sans-serifs. The two most popular typefaces are Georgia — used on such websites as The Guardian and the Financial Times — and Arial — found on Zeit.de and the BBC’s website.
• Only 37% use a sans-serif typeface for body copy.
• The most popular serif typefaces for headlines are Georgia (14%) and Chaparral Pro (6%).
• The most popular serif typefaces for body copy are Georgia (20%) and Chaparral Pro (4%).
• The most popular sans-serif typefaces for headlines are Arial (10%) and Freight Sans Pro (4%).
• The most popular sans-serif typefaces for body copy are Arial (14%) and Helvetica (6%).
• However, 66% of headline typefaces and 39% of body copy typefaces are found in only one instance.

So, in summary we can state that nearly two thirds of the websites analyzed use serifs for body copy, and Georgia and Arial are still the most common primary typefaces. However, our most surprising find is that a majority of websites use non-standard fonts as their primary typeface — 39% of body copy and 66% of headlines. This development is truly interesting, because it shows that typography has become an important element in establishing brand identity and character. These numbers indicate growing typographic diversity on the Web — which we should probably expect anyway.

A majority of websites use non-standard fonts as their primary typeface.

The growth of “bulletproof” font-delivery services such as Typekit and Fontdeck likely explains the increasing variety of primary typefaces. Fallback typefaces are predominantly standard core Web fonts. Times, Times New Roman, Georgia, Helvetica and Arial are most often used in CSS font stacks. Mobile platform fonts such as Droid Sans, Palatino and Cambria are almost never used.

Ironically, a consequence of the resurgence in serif typefaces is that Times and Times New Roman, which had almost been written off as too old-fashioned in the last study, have made kind of a comeback as the two most popular fallbacks. Roughly 11% of headline and body copy fallbacks have Times, and another 11% have Times New Roman.

Font-delivery services are growing, and so is the variety of primary typefaces.

There is much literature on typography in Web design, most of which discusses the applications of serif or sans-serif typefaces. Increasingly, the argument for better readability combined with artistic value supports a judicious use of both styles. Douglas Bonneville discusses the benefits and best practices of combining serifs and sans-serifs, and Simon Pascal Klein discusses the intricacies of font families and makes further typographic considerations in his article “Achieving Good Legibility and Readability on the Web.”

The Great Discontent combines both the Stratum and Meta Serif Web Pro fonts to generate a dynamic yet respectable feel.

Compared to the previous study’s results, Verdana and Lucida Grande are the big losers. Verdana is used only twice as a primary font, and neither is used more than once as a fallback font. Chaparral Pro and Helvetica have risen in prominence. The increasing diversity and individuality in design is due to both the increased use of font foundries and the wider range of Web fonts.

One discovery of the previous study, that “alternative” fonts are more common among headline typefaces, is still proving accurate. No doubt, the general belief that experimentation is best applied to small details still stands. The look and feel of a page can be adjusted just enough by changes to the font family of headings, rather than by drastic changes to body copy. However, the overall use of alternative fonts for body copy has increased dramatically, creating a much richer and more diverse typographic landscape on the Web.

Light Or Dark Background?

The previous study concluded that a large majority of websites favored dark on light color schemes. Not much has changed, although the websites surveyed this time are more varied in their light background tones.

An Event Apart demonstrates the readability of a subdued color scheme.

Several websites have a less aggressive contrast of an off-white or even beige background with dark-gray text. The off-white is often chosen to lower contrast. The designers in this case have clearly opted for a comfortable, lengthy reading experience.

Black text on a white background is a common pattern for body copy. The contrast is easy on the eyes and is, at least among these websites, the status quo.

Average Font Size For Headlines

Generally, the font size of headlines is chosen according to the typeface of the body copy. Still, it’s interesting to see what common ranges designers prefer for body copy and headlines. In this study, the headlines for large display sizes average at roughly 38 pixels. Of course, we made sure that the text always displayed at the actual size, without any zoom.

The most popular sizes range from 20 to 32 pixels.

You can easily notice the increase in font size since the last study. Not only did the average increase by more than 10 pixels (!), but the range of headline sizes starts further up, at 20 pixels, and tops out at an impressive 212 pixels in the case of The Great Discontent. This publication is an exception, with its magazine-like headlines and smaller font sizes for headings.

We’re going further up. The Great Discontent shows an impressive 212 pixels font size.

Average Font Size For Body Copy

With readability as the determining criterion, the average pixel size of body copy has increased in four years as well. Back then, most of the websites were between 12 and 14 pixels in font size. Now, 14 pixels is as popular as 16 pixels; each is used on 13 websites.

14 pixels is also The Verge’s font size. While some websites offset the first paragraph of an article with a larger font size, many, like The Verge, follow a uniform size.

Ratio Of Headline to Body Font Size

We’ve updated our rule of thumb based on the current average ratio between headline and body font size. Don’t follow this rule blindly; rather, just keep it in mind as you make decisions in your projects.

Headline ÷ Body Copy = 2.5

According to our study, on average, the ratio between the headline and the body copy is around 2.5. The traditional scale (6, 7, 8, 9, 10, 11, 12, 14, 16, 18, 21, 24, 36, 48, 60, 72) and the Fibonacci sequence (16, 24, 40, 64, 104) are still relevant, of course, and represent a more naturalistic approach. The golden ratio (1.618) might also yield an organic effect, too.

Optimal Line Height For Body Copy

Leading (or line-height in CSS) will always depend on your font size and measure (or line length). But in general, the longer the measure, the longer the leading should be. Therefore, presenting a chart of the most popular leading values in pixel units wouldn’t make sense here. More appropriate for you would be to use a relative unit, such as an em or percentage value, that determines the ratio between leading and measure and between leading and font size.

This latest study reveals the following:

• line height (pixels)
  

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/17/case-study-typographic-design-patterns-and-current-practices/feed/ 0 http://sayingitfirst.com/2013/05/16/how-to-use-social-media-to-drive-local-sales-for-your-smb/?utm_source=rss&utm_medium=rss&utm_campaign=how-to-use-social-media-to-drive-local-sales-for-your-smb http://sayingitfirst.com/2013/05/16/how-to-use-social-media-to-drive-local-sales-for-your-smb/#comments Thu, 16 May 2013 20:38:00 +0000 SayingItFirst http://sayingitfirst.com/2013/05/16/how-to-use-social-media-to-drive-local-sales-for-your-smb/ Today’s guest author is Erica Bell, a social media specialist for Business.com. She covers a range of topics including SEO marketing, social media trends, and small business sales. Social media marketing is one of the most inexpensive ways for your business to connect with local customers online. Even if [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> Today’s guest author is Erica Bell, a social media specialist for Business.com. She covers a range of topics including SEO marketing, social media trends, and small business sales.

  Social media marketing is one of the most inexpensive ways for your business to connect with local customers online. Even if the ones you’re trying to reach aren’t “locals,” local online marketing is a great way for small and medium-sized businesses to connect with their audience. According to a recent study from the Local Search Association, 77% of smartphone users accessed local content in December 2012, including online directories and local resources. The likelihood of the users then making a decision about where to dine, make a purchase or engage with a business is high. If your SMB is looking to boost local sales through social media, consider taking these three steps to move forward.

  Be Available

  Google Local, Yelp, Foursquare and Facebook are networks your business must be on if you’re looking to generate new sales with consumers in your area. Making your business readily available through social platforms is a sign to consumers that you want to be where they are and you understand that means you need to be engaged and active on social media. Graph Search from Facebook and local searches conducted on Yelp and Foursquare that incorporate social signals from a consumer’s friends impact the decision of a consumer. Negative reviews your business has handled well, positive reviews from friends, check-in rewards and more will effect whether or not someone doing a local search chooses to do business with you. Be available on the networks where your customers can be found and where they’re looking to find a business like yours.

  Bonus:

  Check out Rignite’s infographic on how businesses can benefit from social media signals.

   Establish Sales Goals

  A 2012 study from Social Media Examiner found that increased exposure and increased site traffic were the two biggest benefits of social media activity. However, the majority (58%) also indicated that generating leads and developing loyal fans were perks of being active on social networks. In fact, 65% of small business owners were more likely than others to generate leads, compared to the 58% average for all marketers. What is your business aiming to do with social? If you want to drive online sales, in-store sales, the sale of a specific product, or something else entirely, you need to know this before you get started developing your strategy. Different contests, social campaigns, social content will be more successful than others. You need to gear your social media efforts toward meeting the specific sales goals you have in mind so you can build awareness, generate leads, and close sales.
  

  Put In the Time

  Social media success doesn’t come with setting up an account and expecting sales leads to flood in. You need to build your accounts, complete with the correct contact and location information, and then put in the time to listen and engage with those in your area looking for a product/service like yours. Social monitoring, keyword and location searches, and completing and updating profiles require a time investment. Make the investment and you’ll see consumers in your area make an investment in your business. Even if a consumer isn’t engaging with your business directly on social networks and is using a search engine instead, social media is making an impact. Social media is increasingly becoming a factor in SEO marketing and search results as engines begin to factor in social signals in their rankings. Put in the time to create social content, from blog posts to tweets, that targets customers near your location.

  Get started with a time commitment to social media marketing activities for only 1-5 hours a week to test which networks and what campaigns are the most effective in helping your business close local sales. Reach local customers by offering deals, being present on sites such as Yelp and Foursquare that encourage customer reviews, and engaging in social conversations with those in your area. Social media isn’t about pushing or pitching, it’s about engaging and building relationships. Build relationships with your local audience on social media to see a boost in sales.

  Bonus:  Check out Rignite’s infographic below of daily and weekly tasks to help you manage your time spent on social media marketing.

  

  Copy the embed code below to use this image on your site:

  <a class="colorbox" href="http://www.rignite.com/blog/5-tips-for-effective-social-media-time-management?utm_source=InfographicEmbed&utm_medium=EmbedReferral&utm_term=&utm_content=DailyWeeklyTasks&utm_campaign=Infographics" title="Social Media Time Management: Daily And Weekly Tasks" target="_blank"><img src="http://www.rignite.com/wp-content/uploads/2015/04/Time-Management-For-Social-Media-Infographic.jpg" alt="Manage Social Media More Efficiently With Rignite" style="width:540px;margin:0px auto" /></a></p> <p style="font-size:12px">Compliments of: <a class="colorbox" href="http://www.rignite.com/?utm_source=InfographicEmbed&utm_medium=EmbedReferral&utm_term=&utm_content=DailyWeeklyTasks&utm_campaign=Infographics" target="_blank" title="Social Media Time Management: Daily And Weekly Tasks">Rignite Inc.</a></p> <p>

  Are you using social media to drive sales for your SMB? Do you have any tips to add?

  Source: Rignite

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/16/how-to-use-social-media-to-drive-local-sales-for-your-smb/feed/ 0 http://sayingitfirst.com/2013/05/15/a-beginners-guide-migrating-a-website-to-wordpress-is-easier-than-you-think/?utm_source=rss&utm_medium=rss&utm_campaign=a-beginners-guide-migrating-a-website-to-wordpress-is-easier-than-you-think http://sayingitfirst.com/2013/05/15/a-beginners-guide-migrating-a-website-to-wordpress-is-easier-than-you-think/#comments Wed, 15 May 2013 14:33:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/15/a-beginners-guide-migrating-a-website-to-wordpress-is-easier-than-you-think/ Now powering over 17% of the Web, WordPress is increasingly becoming the content management system (CMS) of choice for the average user. But what about websites built with an outdated CMS or without a CMS at all? Does moving to WordPress mean starting over and losing all [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Now powering over 17% of the Web, WordPress is increasingly becoming the content management system (CMS) of choice for the average user. But what about websites built with an outdated CMS or without a CMS at all? Does moving to WordPress mean starting over and losing all the time, energy and money put into the current website? Nope!

  Migrating a website (including the design) over to WordPress is actually easier than you might think. In this guide, we’ll outline the migration process and work through the steps with a sample project. We’ll also cover some of the challenges you might encounter and review the solutions.

  About This Guide

  Before we get to work, let’s establish some context. First, this guide was written primarily with beginners in mind and will be most helpful for basic websites. Some of you will likely encounter advanced aspects of WordPress migration, but they are beyond the scope of this guide. If you’re tackling an advanced migration and get stuck, feel free to share your difficulty in the comments below.

  Objectives

  The objective of this guide is to help you with the following:

  • Plan an effective migration to WordPress.
  • Walk through the technical steps involved in migrating.
  • Get ideas and resources to solve common migration challenges.

  Assumptions

  I assume you have basic familiarity with WordPress. Previous development experience with WordPress would be helpful, but not necessary. I also assume you have an existing website and design that you want to migrate to WordPress.

  

  Basic Steps

  Here are the basic steps that I recommend you follow for a typical WordPress migration:

  1. Evaluate website.
     Work carefully through the pages on your existing website, identifying all of the types of content (standard pages, photo galleries, resource pages, etc.) and noting any areas that need special attention.
  2. Set up environment.
     Set up WordPress and get ready to import.
  3. Import content.
     Bring over and organize your content, whether via an importing tool, manual entry (for a small amount, when no tool is available) or a custom importing process.
  4. Migrate design.
     Incorporate your existing design into a custom WordPress theme.
  5. Review website, go live.
     Carefully review the import, making adjustments where needed, set up any URL redirects, and then go live.

  With this outline in mind, let’s work through each step in detail.

  Start With A Plan

  The key to a successful migration is to carefully evaluate your current website. You need to figure out how to import and structure the content in WordPress before carrying over the design.

  While the principles are the same across migration projects, the details often vary. So, below are two lists of questions to ask as you work out a plan.

  Imported Content

  • How much content needs to be imported (number of pages, number of images, etc.)?
  • Is the volume low enough to be imported manually, or do you need a tool?
  • If you need a tool, does one already exist?
  • Can the content be categorized into the standard “posts” and “pages,” or does it call for custom post types?
  • Does extra content need to be stored for certain pages (custom fields, taxonomies, etc.)?
  • Will the URL structure change? If so, will the old URLs need to be redirected?

  Existing Functionality

  • Does the website integrate any third-party services (data collection, reservations, etc.)?
  • Do any forms need to be migrated (contact forms, application forms, etc.)?
  • Is access to any content restricted (such as members-only content)?
  • Does the website sell products (digital or physical)?
  • Do any administrative tools need to be carried over (such as custom CMS functionality)?

  A Working Example

  My brother, Joshua Wold, has volunteered a website to serve as an example; it’s for a side project of his in which he sells posters and postcards of a Vegan Food Pyramid. He built the website in plain HTML, with some basic PHP includes for the header and footer. Below is a screencast of me evaluating the website to give you a sense of how the process will work. Enjoy!

  Set Up WordPress

  Before importing the content, we need to get WordPress ready to go. If you’re just experimenting or if you prefer offline development, start with a local installation of WordPress. Otherwise, the next step is to install WordPress with your current hosting provider; or you could use the migration process as a great opportunity to move to a new host.

  Once WordPress is up and running, you’re ready for action!

  

  For our example, we’ve installed WordPress with the same host, setting it up in a /wp directory for the duration of the migration process.

  Settings and Plugins

  With WordPress installed, we’ll make a few minor adjustments:

  • Update permalinks.
    Go to Settings → Permalinks to make changes. In most cases, I’ll switch to “postname”-style permalinks.
  • Update users.
    I create an admin-level account for myself and any admin or editor accounts that are needed for clients and collaborators. I also remove the default “admin” user name if it exists (a basic but wise step for WordPress security).

  Depending on the needs of the project, we might have to preinstall plugins. Here are the major categories of plugins:

  • Form management
    Migrating a form “as is” is usually a mess; simply recreating it using a forms plugin is usually easier. My current favorite is Gravity Forms ($39+ per license). Other options are Formidable (with free and pro versions) and Contact Form 7 (entirely free).
  • SEO management
    Search engine optimization (SEO) is a touchy subject. My philosophy is to build content for people, not for search engines. That being said, there is a common-sense approach to SEO that is solidly supported by the WordPress plugin ecosystem. And if your old website includes custom meta descriptions, giving them a new home during the importing process is important. I recommend WordPress SEO (free).
  • Multiple languages
    If your old website supports multiple languages, WordPress has you covered. My plugin of choice is WPML ($79 per license, free for non-profits). Another option is qTranslate (free).
  • Security
    WordPress security is a topic near and dear to me. The increasing popularity of WordPress has made it a target for security attacks. WordPress itself is rarely the problem; a poorly secured hosting environment or an outdated or poorly developed plugin usually is. I use managed WordPress hosting for the majority of my projects, which offers a good foundation for solid WordPress security. Options include WPEngine, ZippyKid, Pagely and Synthesis. In addition to managed hosting (and especially if you opt for a non-managed host), consider installing a security plugin, such as Better WP Security (free) or Wordfence (also free). Last but not least, review the “Hardening WordPress” guide in the Codex.
  • Backups
    If you opt for managed hosting, backups are usually included (make sure, though). If you’re managing backups yourself or you want an extra layer of data protection, great options are available, including VaultPress ($15+ a month), CodeGuard ($5+ a month), BackupBuddy ($75+ per license) and BackWPup (free).

  Import Content

  With WordPress up and running, it’s time to bring over all of your content.

  If your old website has a CMS, an importing tool might be available. Start by viewing the list of content-importing scripts in the Codex. If there’s a match, great! Follow the instructions and get to work. If all goes well, you’ll have migrated the content over without any trouble.

  If your old CMS is not in the list or you don’t have a CMS at all and you’ve got fewer than 100 pages, then manual migration is probably the way to go. Copy and paste the contents, noting the old URLs as you go (tracking the migration in a spreadsheet is a good idea).

  

  If you’ve got a custom CMS or a database of records without an importing tool and a high volume of content, then you might want to bring in a specialist to move the content over before continuing. The higher the volume of content, the higher the chance of human error and the more important automating it becomes.

  For our project, I’ve migrated the content manually and replaced the existing navigation with a WordPress menu. You can watch the process in this next screencast:

  Bring Over The Design

  With our content in WordPress, it’s time to bring over the design. Incidentally, if you’re considering a new design, then now is a great time to look at the many excellent WordPress themes out there, both in the official repository and in third-party marketplaces such as ThemeForest and Creative Market. For our purpose, I’ll assume that you’re happy with your design.

  Evaluating A Design

  Evaluate the source code of a prospective design as best you can before tackling the migration. If the code is table-based or more complex than you’re comfortable with, then migrating the design might not be worth the effort. While anything is possible (I’ve migrated some complex table-based designs in my time), not everything is practical.

  Working With Source Code

  In my experience, the easiest way to migrate is to work directly with the source code in the browser. While having access to the original hosting environment can be helpful (especially when working with a lot of images and downloadable files), the ways that websites are built vary so widely that you’ll often have to reverse-engineer the original architecture in order to derive anything useful.

  

  Going directly to the source code in your browser of choice will save a lot of time and, barring any important “behind the scenes” functionality, give you everything you need. Google Chrome is currently my browser of choice, and I’ve pulled our source-code samples directly from the browser. (In Chrome, go to Menu → Tools → View Source, or just right-click to bring up the contextual menu.)

  Create A Custom Theme

  If you’re new to them, learn about using themes in the Codex. For the migration process, you can either build a new WordPress theme from the ground up or modify an existing theme to meet your needs. I recommend the latter.

  Most of my migration projects have started with the latest version of WordPress’ default theme (currently Twenty Twelve). Recently, I stripped down the default theme to create my own migration starter theme, which I’ll use in our example and which you’re welcome to use yourself. (Feel free to suggest improvements!) Let’s get to work.

  Download a copy (ZIP) of the migration starter theme or follow along in your own theme of choice as we work through the relevant theme files.

  1. Style Sheet

  Our first step is to bring over the styles from the old website. In most cases, this is as simple as searching the source code for references to .css and then copying and pasting the contents from those style sheet(s) into our own style.css. Let’s get to it.

  1. Open up style.css.
  2. Replace the details of the theme (“Name,” “URI,” “Description,” etc.) with your own.
  3. Paste in the styles from the old website.

  A Note About Images

  As you migrate the style sheet(s), search for and update any references to images. In general, I like to keep all images in an /images/ folder within the theme’s directory. More often than not, changing the locations of images referenced in the original CSS is necessary, and I make sure to update all references in the style sheet and templates accordingly.

  2. Header

  The next step is to create the header for our new theme. Our objective here is to merge the structure of the current code base with WordPress’ templates. Here’s what we’re going to do:

  • Replicate the HTML structure of the old website.
  • Replace the static menu with a WordPress-powered menu.
  • Use WordPress’ title tag and leave the wp_head hook in place.
  • Merge any other relevant tags from the old header.

  Let’s get into the code!

  Original HTML

  
  <!DOCTYPE HTML>
  <html>
  <head>
  <title>Vegan Food Pyramid posters, postcards and wallpapers</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta name="google-site-verification" content="PO3bWDpUEh4O6XXwnmfyfxrKRDf8JsRrNIcGdzv3POs" />
  <link rel="stylesheet" type="text/css" href="style.css" media="screen" />
  <link rel="shortcut icon" href="http://www.veganfoodpyramid.com/favicon.ico?v=2" />
  <script type="text/javascript" src="//use.typekit.net/tty6xpj.js"></script>
  <script type="text/javascript">try{Typekit.load();}catch(e){}</script>
  
  </head>
  <body>
  <a href="http://veganfoodpyramid.com"><h1 id="logo">Vegan Food Pyramid</h1></a>
  <ul class="menu">
     <li><a class="active" href="http://veganfoodpyramid.com">Products</a></li>
     <li><a href="http://veganfoodpyramid.com/wallpaper.php">Wallpaper</a></li>
     <li><a href="http://veganfoodpyramid.com/about.php">About</a></li> 
     <li><a href="http://veganfoodpyramid.com/contact.php">Contact</a></li>
  </ul>
  

  Merged Header (header.php)

  
  <!DOCTYPE html>
  <html>
  <head>
     <title><?php wp_title( '|', true, 'right' ); ?></title>
     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
     <meta name="google-site-verification" content="PO3bWDpUEh4O6XXwnmfyfxrKRDf8JsRrNIcGdzv3POs" />
     <link rel="shortcut icon" href="http://www.veganfoodpyramid.com/favicon.ico?v=2" />
     <script type="text/javascript" src="//use.typekit.net/tty6xpj.js"></script>
     <script type="text/javascript">try{Typekit.load();}catch(e){}</script>
     <?php wp_head(); ?>
  </head>
  
  <body <?php body_class(); ?>>
  
     <header>
        <a href="http://veganfoodpyramid.com"><h1 id="logo">Vegan Food Pyramid</h1></a>
        <?php wp_nav_menu( array( 
              'theme_location' => 'primary',
              'container' => false,
              'menu_class' => 'menu'
        ) ); ?>
     </header>
  

  Explanation

  One of the challenges of migration is deciding whether to improve code as you go along. Our project has a few areas that could be improved, but Joshua and I agreed to leave them as is. Most of you will be tackling the migration of a design that hasn’t been coded to current best practices (although, in fairness to the original coder, they may have been best practices at the time).

  

  If time and opportunity allow, I encourage you to improve on the code. Otherwise, take comfort in the fact that, with the website now on WordPress, improvements will be a whole lot easier down the road.

  Let’s work through the changes we’ve made!

  • Doctype
    Make sure to carry over the same doctype. In this case, the original HTML already has an HTML5 doctype (a relatively rare occurrence on old websites). Using a modern doctype in a code base written for an older specification (such as XHTML or HTML4) could break the layout (especially in old browsers).
  • Meta tags
    I usually bring over the majority of meta tags as is, replacing them in WordPress. The exception in our case is the reference to the style sheet, which is being inserted automatically via wp_enqueue_style in the functions.php file.
  • Scripts
    Scripts can be tricky. If a script belongs on every page (such as a tracking script or font script), then putting it directly in the header (or footer) file is fine. If it needs to appear only on certain pages, then a conditional tag will do the trick. As a best practice, register all scripts and add them to the header (or footer) via wp_enqueue_script. If you’re up for the challenge, I recommend doing it this way. (Check out a tutorial on enqueuing TypeKit the right way.)
  • wp_head
    Leave at the bottom of the tag in the merged header file. WordPress uses wp_head, among other things, to enqueue scripts and style sheets that are referenced in the theme (usually in functions.php) and in plugins that you’ve installed. Without wp_head in place, most front-end plugins won’t work.
  • body_class
    Notice our use of the tag. WordPress uses this to provide a series of helpful classes to the tag depending on the page being viewed. In our example, the classes weren’t being used. Yours might have unique IDs or classes on each page, in which case you can create a custom function using conditional tags to add the appropriate classes to the corresponding pages. Have a look at the Codex for some examples.
  • WordPress menus
    Switching to a WordPress-powered menu is one of the more complex tasks in most basic migrations. It will be fairly straightforward for us. We have a menu with simple markup that uses an active class (generated via PHP) to indicate which page the visitor is viewing. The wp_nav_menu function is highly flexible and offers built-in functionality to handle the current state of an element in the menu. I’ve updated the references in the style sheet to the active class and changed them to use the equivalent generated by wp_nav_menu, which is current-menu-item. Watch the screencast on importing content to see how I’ve set up the menu for our example.

  And that’s a wrap! Let’s move on to the next piece.

  3. Footer

  The footer is usually the most uneventful template in the migration process. As with the header, our objective is to merge the relevant parts of the original source code. Let’s get to it!

  Original HTML

  
  <div id="footer"><p>© 2013 VeganFoodPyramid.com</p></div>
  
  <script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  </script>
  <script type="text/javascript">
  try {
  var pageTracker = _gat._getTracker("UA-6992755-1");
  pageTracker._trackPageview();
  } catch(err) {}</script>
  
  </body>
  </html>
  

  Merged Footer (footer.php)

  
  <div id="footer"><p>© <?php echo date('Y'); ?> VeganFoodPyramid.com</p></div>
  
  <script type="text/javascript">
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
  </script>
  <script type="text/javascript">
  try {
  var pageTracker = _gat._getTracker("UA-6992755-1");
  pageTracker._trackPageview();
  } catch(err) {}</script>
  
  <?php wp_footer(); ?>
  
  </body>
  </html>
  

  Explanation

  Some footers are hard to migrate (such as ones with complex menus and widgets), but most are simple. In this case, we’ve merged the HTML with our footer template, making sure to preserve our reference to the wp_footer hook. We’ve also changed the date reference to use PHP, ensuring that it updates with each year.

  4. Home Page

  One of the challenges of a migration is that there are so many different ways to get the job done. The home page is a good illustration of this because it tends to be the most different from the rest of the website. Adopting the simplest method is usually best. I’ve opted to put all of the home page’s content directly in the template. Changes will be rare and can easily be made by editing the template.

  Let’s look at the code, excluding the header and footer, which we’ve already covered.

  Original HTML

  
  <div id="content">
  
  <div id="poster">
  <a href="http://veganfoodpyramid.com/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="http://veganfoodpyramid.com/images/Vegan-Food-Pyramid-New.jpg" /></a>
  <div class="description">
  <h2>Poster</h2>
  <p>A 30×20-inch poster illustrating over 125 vegan food items as an alternative to the traditional food pyramid. This poster will catch people’s attention and serve as a suggestion for food ideas.</p>
  <h3>$30 each</h3>
  <p>Includes free shipping worldwide</p>
  <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2FKQT879CXYYG">Buy</a>
  </div>
  </div>
  
  <div id="postcard">
  <a href="http://veganfoodpyramid.com/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="http://veganfoodpyramid.com/images/postcard-splash.jpg" alt="Postcard Splash" /></a>
  <div class="description">
  <h2>Postcards</h2>
  <p>Beautiful 4×6 postcards that can be mailed and shared with friends and family. Hand them out at events. Post them on walls. Share the vegan love!</p>
  <h3>$50 for 50</h3>
  <p>Includes free shipping worldwide</p>
  <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=EN387WHNSSFMW">Buy</a>
  </div>
  </div>
  
  </div> <!-- end content -->
  

  Merged Home Page (/page-templates/front-page.php)

  
  <?php
  /**
   * Template Name: Front Page Template
   */
  
  get_header(); ?>
  
  <div id="content">
  
     <div id="poster">
        <a href="<?php echo get_stylesheet_directory_uri(); ?>/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="<?php echo get_stylesheet_directory_uri(); ?>/images/Vegan-Food-Pyramid-New.jpg" /></a>
        <div class="description">
           <h2>Poster</h2>
           <p>A 30×20-inch poster illustrating over 125 vegan food items as an alternative to the traditional food pyramid. This poster will catch people’s attention and serve as a suggestion for food ideas.</p>
           <h3>$30 each</h3>
           <p>Includes free shipping worldwide</p>
           <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=2FKQT879CXYYG">Buy</a>
        </div>
     </div>
  
     <div id="postcard">
        <a href="<?php echo get_stylesheet_directory_uri(); ?>/images/Vegan-Food-Pyramid-New.jpg"><img class="product-img" src="<?php echo get_stylesheet_directory_uri(); ?>/images/postcard-splash.jpg" alt="Postcard Splash" /></a>
        <div class="description">
           <h2>Postcards</h2>
           <p>Beautiful 4×6 postcards that can be mailed and shared with friends and family. Hand them out at events. Post them on walls. Share the vegan love!</p>
           <h3>$50 for 50</h3>
           <p>Includes free shipping worldwide</p>
           <a class="button" href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=EN387WHNSSFMW">Buy</a>
        </div>
     </div>
  
  </div> <!-- end #content -->
  
  <?php get_footer(); ?>
  

  Explanation

  The front-page.php template begins and ends with a reference to the header and footer that we’ve just prepared. In between, we’ll merge the rest of the HTML, and we’ll use the get_stylesheet_directory_uri function, which will dynamically generate references to the images folder in our new theme.

  5. Standard Page Template

  With the header and footer done, the standard templates are usually quite easy. For brevity’s sake, we’ll go directly to the merged templates.

  Merged Template (page.php)

  
  <?php
  /**
   * The template for displaying all pages.
   */
  
  get_header(); ?>
  
  <div id="content">
  
     <?php while ( have_posts() ) : the_post(); ?>
  
        <?php get_template_part( 'content', 'page' ); ?>
     
     <?php endwhile; ?>
  
  </div>
  
  <?php get_footer(); ?>
  

  Content Template (content-page.php)

  
  <?php
  /**
   * The template used for displaying page content in page.php
   */
  ?>
  
     <article <?php post_class(); ?>>
        <?php the_content(); ?>
     </article>
  
  

  Explanation

  There are several items to point out here:

  • The loop
    If you’re new to WordPress or programming in general, this piece of code in the #content container might look intimidating. The “loop” is code used by WordPress to display a post’s content. You can learn more about the loop in the Codex. Meanwhile, just make sure that it’s in there, or else the content you save in WordPress won’t show up.
  • get_template_part
    Our page template here employs the handy get_template_part function, which is a great way to keep content organized, especially in complex projects. Our website is simple enough not to warrant it, but I left it in just to show you.
  • post_class
    I also added a reference to

    (with the corresponding post_class function) to make further customization of the design easier.

  5. Full-Width Template (full-width.php)

  Although not illustrated in the screencast, the design includes a full-width template for use on the “Wallpaper” page, while the standard page template is changed to a narrow width.

  Let’s have a look.

  Merged Template (templates/full-width.php)

  
  <?php
  /**
   * Template Name: Full-Width Template
   */
  
  get_header(); ?>
  
  <div id="content" class="full-width">
  
     <?php while ( have_posts() ) : the_post(); ?>
  
        <?php get_template_part( 'content', 'page' ); ?>
     
     <?php endwhile; ?>
  
  </div>
  
  <?php get_footer(); ?>
  

  Explanation

  With the template created, all that remains is to assign it to a page. From the “Edit Page” interface, find the “Page Attributes” box (usually right below the “Publish” box) and select “Full-Width Template” from the “Templates” dropdown menu.

  6. Extras

  Now let’s tackle some of the “extras” that sometimes come up as challenges during a WordPress migration.

  • Breadcrumbs
    Breadcrumbs are relatively common on websites. The easiest way to reproduce them is with a plugin. My current favorite is Breadcrumb NavXT (free). WordPress SEO also offers built-in breadcrumbs.
  • Widgets
    If the design you’re migrating has a sidebar, you could either reproduce it as is (the migration theme has a sample sidebar in place) or integrate WordPress widgets to allow for a dynamically managed sidebar. The folks at Automattic have prepared a handy guide to widgetizing themes. Start there.
  • Restricted content
    In case some content needs to be restricted, WordPress offers basic password protection by default. If you want more control, use a plugin. For basic role management and content permissions, I recommend Members (free). For more advanced control (especially if payment is involved), consider Membership (which has basic and premium versions), s2Member (also free and premium) and WP-Members (free).
  • Custom Post Types
    Some migrations, especially ones with a lot of different types of content, call for “custom post types.” You can learn about custom post types in the Codex. To set them up, I recommend using a plugin. Two good choices are Custom Post Type UI and Types (both free).

  Review Website

  Now that we’ve wrapped up work on the theme, it’s time for a review. Work carefully through the pages on the migrated website. For a large website, focus on the different templates. As you review, here are some things to watch out for:

  1. Broken links
     Make sure all links work as they should. If you have only a few pages, you can check manually. For an automated check, use Integrity (free, for Mac) or Xenu’s Link Sleuth (free, for Windows).
  2. Broken styles
     Occasionally, for one reason or another, a design element of your website might have broken during the migration. Carefully compare the old HTML to the new to make sure you haven’t missed any important code and that the corresponding style sheet rules have been carried over. If all else fails, a quick rebuild of the design element on the new website might be in order.
  3. Broken functionality
     Test any functionality that you’ve migrated over, such as “Buy now” buttons, contact forms, newsletter opt-ins, “members-only” content, embedded maps, media players, etc.
  4. Temporary links
     Depending on how you’ve carried out the migration, temporary links to a subfolder or testing domain might appear in your content or theme. You’ll want to update these before going live. Use the Search and Replace plugin (free) to check for and update links in your content.

  Setting Up Redirects

  If your link structure has changed (and it usually will, even if only slightly), make sure that visitors are redirected from the old pages to the new. For small amounts of content, one of the easiest ways to set up redirects is by adding them to the .htaccess file.

  Open the .htaccess file in the WordPress directory. If you don’t see it, set your FTP client to show hidden files. Now, create redirect rules for each of the old pages. Be sure to put these rules after WordPress’ block of rules.

  Here are the rewrite rules for our links:

  
  Redirect 301 /wallpaper.php http://veganfoodpyramid.com/wallpaper/
  Redirect 301 /about.php http://veganfoodpyramid.com/about/
  Redirect 301 /contact.php http://veganfoodpyramid.com/contact/
  Redirect 301 /contactthanks.php http://veganfoodpyramid.com/contact/thanks/
  

  If editing your .htaccess file is not an option or if you’re dealing with a lot of redirects, then have a look at Redirection (free).

  Advanced tip: If the volume of redirects is very high (which is likely with a large-scale migration and a custom importing process), then consider building a function that hooks into template_redirect, compares a generated list of cases, and then uses the wp_redirect function to redirect any matches.

  Going Live

  Going live with a website usually involves one of two tasks:

  1. Relocate WordPress from the development folder to the root directory.
  2. Point the domain name from the old server to the new WordPress server.

  

  Relocating WordPress

  If you set up WordPress in a subfolder (as we did), then going live involves a few simple steps. Follow the guide to using a pre-existing subdirectory installation.

  Once you’ve made the change, check immediately for any broken links that you may have missed in the final review.

  Pointing to a New Server

  If you set up WordPress on a new server, then you probably used a temporary domain. Accordingly, remove references to the temporary domain before pointing the domain to the new server.

  Also, if you’re planning to update the name servers for your domain, then first resolve any dependencies in the current DNS records (such as hosted email and third-party services). I usually go live with a domain by updating the A records, leaving the name servers in place.

  Conclusion

  And there you have it! A successful WordPress migration is all about the details, and while this guide is by no means comprehensive, you now have a good outline of the process and a sense of some of the challenges you’ll encounter, along with ideas for solving them. If you run into challenges along the way, share them in the comments below. Now get migrating!

  (al)

  ---

  © Jonathan Wold for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/15/a-beginners-guide-migrating-a-website-to-wordpress-is-easier-than-you-think/feed/ 0 http://sayingitfirst.com/2013/05/14/a-client-and-server-side-approach-providing-the-best-mobile-user-experience-possible/?utm_source=rss&utm_medium=rss&utm_campaign=a-client-and-server-side-approach-providing-the-best-mobile-user-experience-possible http://sayingitfirst.com/2013/05/14/a-client-and-server-side-approach-providing-the-best-mobile-user-experience-possible/#comments Tue, 14 May 2013 18:53:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/14/a-client-and-server-side-approach-providing-the-best-mobile-user-experience-possible/ Now and again, I hit the swimming pool. It’s a good way to exercise, but also to relax after a long day in front of my PC. I can do quite a few laps in my front crawl, but only because I don’t use my legs much. [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

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

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

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

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

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

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

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

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

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

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

  Best Of Both Worlds

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

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

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

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

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

  Segmentation (Good Ol’ Divide And Conquer)

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

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

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

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

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

  Non-Smartphones

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

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

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

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

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

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

  The following wireframe nicely illustrates what we are getting at:

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

  Smartphones

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

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

  Tablets and Desktops

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

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

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

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

  Important Note About Mobile Bandwidth: Speed Isn’t Everything

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

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

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

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

  May Your Days Be Merry And Your URLs Unique

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

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

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

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

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

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

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

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

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

  End of the aside.

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

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

  The Code

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

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

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

  Let’s discuss each of them.

  Device Description Repository

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

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

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

  :
  require_once dirname(__FILE__).'/lib/WurflCloudClient/Client/Client.php';
    :
  
  // Disable caching for testing
  $cache_enabled = false;
  
  $wurfl_config = new WurflCloud_Client_Config();
  $wurfl_config->api_key = 'XXXXX:YYYYYYYYYYYYYYYYYYYYYYYYYYY';
    :
  if ($cache_enabled) {
  	$wurfl = new WurflCloud_Client_Client($wurfl_config);
  } else {
  	$wurfl = new WurflCloud_Client_Client($wurfl_config, new WurflCloud_Cache_Null());
  	header("Cache-Control: no-cache, must-revalidate");
  	header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");
  }
  $wurfl->detectDevice();
  

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

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

  
  $wurfl->getDeviceCapability('is_tablet')
  

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

  Model-View-Controller Framework

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

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

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

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

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

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

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

  Controller

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

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

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

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

  Image Resizing (RESS)

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

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

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

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

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

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

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

  This will generate markup like the following snippet:

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

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

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

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

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

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

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

  The Views: Feature Phone, Smartphone and Desktop/Tablet

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

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

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

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

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

  
  The view on feature phones.

  
  The view on smartphones.

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

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

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

  Conclusion

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

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

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

  Have a look at the demo app, or download the full source code.

  (al)

  ---

  © Luca Passani for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/14/a-client-and-server-side-approach-providing-the-best-mobile-user-experience-possible/feed/ 0 http://sayingitfirst.com/2013/05/13/fables-myths-and-narratives-converting-our-stories-into-multi-screen-experiences/?utm_source=rss&utm_medium=rss&utm_campaign=fables-myths-and-narratives-converting-our-stories-into-multi-screen-experiences http://sayingitfirst.com/2013/05/13/fables-myths-and-narratives-converting-our-stories-into-multi-screen-experiences/#comments Mon, 13 May 2013 18:24:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/13/fables-myths-and-narratives-converting-our-stories-into-multi-screen-experiences/ Storytelling takes many forms. In the past, stories were told orally, with people telling and retelling myths, fables and even histories. As writing technology became more prevalent, we began to record our stories, and we told them in the pages of books. Now, our society is awash [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Storytelling takes many forms. In the past, stories were told orally, with people telling and retelling myths, fables and even histories. As writing technology became more prevalent, we began to record our stories, and we told them in the pages of books. Now, our society is awash in different devices and technologies, and those traditions of spoken stories and printed stories are blurring.

  Multi-screen narratives are being told across all kinds of platforms, pages and devices, making for truly immersive experiences. We are watching them, tapping them and learning from them. They immerse us in the storyteller’s world. This article outlines what I believe are the five essentials of telling multi-screen stories.

  How I Fell In Love With Interactive Storytelling

  First, a little background. My childhood was spent in Nigeria, West Africa. I am a member of the Tiv tribe, a group of about 6 million people clustered in Nigeria’s Benue River Valley. As a child, I heard a lot of Nigerian folktales, about animals, humans and even magic. In Nigerian narrative tradition, stories are often told orally, in front of a gathered audience. During festivals and cultural events, men even dress up in elaborate costumes and perform stories for the crowds. I have vivid memories of these stories and have always been curious about how they could be translated into something digital and interactive.

  
  The Kwagh Hir, or Thing of Magic, my tribe’s largest cultural festival (Image: Naptu2)

  Those fables are a piece of my cultural inheritance. They always seemed to contain essential truths about humans. Take the story of the Ear and the Mosquito. One day, the Ear steals food from the Mosquito and refuses to pay it back. In anger, the Mosquito visits the Ear every evening, demanding the food to be returned, annoying Ear all night with his buzzing. It’s an old tale, with many versions, but the moral is consistent: don’t steal from your friends.

  Creating modern, interactive versions of these stories is possible, but how exactly do we do that? Let’s begin by talking about what I mean by the word “multi-screen.”

  A Bit About Context And Screens

  When speaking about multi-screen storytelling, remember that screens have different contexts, not only different capabilities. The same screen on which you carelessly watch videos at home becomes a closely guarded viewport when you’re watching a movie on a crowded train. The context in which people view stories is more important than the device’s specifications. When we tell interactive stories, we need to be aware of this, and embrace it.

  I like to focus on the following screens:

  • Sensors (Twine, GPS, Arduino, motion detectors, etc.)
  • Mobiles and tablets (phones, tablets, laptops and everything in between)
  • Flat-screens (desktops, TVs, etc.)
  • Public and immersive displays (store kiosks, large stadium screens, projectors, Kinects, etc.)

  Not all of these need to be used at the same time, because they won’t all be appropriate to the story you are telling. Context is extremely important.

  Now, as promised, here are the five essentials of multi-screen storytelling.

  1. Divide Your Story Into Separate Content Blocks

  When we create multi-screen narratives, we need to find natural breakpoints in the story, places where the visual or narrative content can easily be separated. This enables us to deliver different segments to different devices, in different contexts.

  Kolobok is a Slavic children’s story about the adventures of a round yellow cake. For the Moscow International Festival, a large team of designers and animators from SilaSveta Studio incorporated it into a truly fascinating demonstration of storytelling. Before the show, the team set up a large touchscreen at the children’s height. With their hands, the kids could manipulate parts of the animation by adding movement and color.

  
  A public display for children to play with

  For the show itself, the full story was projected onto the facade of a large building, allowing the crowd of adults and their children to watch the narrative unfold. Along with sound, it made for another discrete content block, one that closely resembled a 3-D movie.

  
  The full animated story in front of a large festival crowd

  While the touchscreen and the movie were different views of the same content, they could exist as independent pieces and did not have to appear next to each other. The SilaSveta team found the natural breakpoints in its story and created two separate visual experiences to match them.

  Questions to Ask

  • Where are the breakpoints in the story? Divide your content so that it makes sense in context. The practice of responsive design gives us numerous guidelines on how to do this.
  • Can those content blocks exist independently? Sometimes, the answer is no, but it depends on the story. In the Kolobok example above, they can. In other interactive stories, such as Snow Fall from the New York Times, the blocks are chapters in a single story and should be kept together.

  2. Offer People Multiple Perspectives

  Bear 71 is an award-winning multi-screen experience created by Jeremy Mendes and Leanne Allison. The creators tell the story of a bear living in Banff National Park in Canada. It feels like a cross between a role-playing game and a TV documentary, and as a linear narrative with a non-linear interface, it works beautifully.

  
  The Bear 71 story is told in a highly abstracted interface.

  Multiple viewpoints are accessible. Online, you roam in a stylized landscape, watch crittercam footage from the forest, and otherwise live as bears do — freely. Even though it may look like a game interface, you are not so much “playing” as you are participating in a story. Watching real crittercam footage, you see what the forest silently sees. You also have the option to turn on your webcam (“stealth mode”) to see other users around the world, all watching the same story online.

  

  During shows and installations, the team responsible for Bear 71 set up augmented-reality applications and motion-detection cameras, so that visitors could experience what it’s like to have their pictures taken with one. By playing with the augmented-reality apps and the motion-detection cameras at the installations, users got a bit of the same physical experience that the bears had.

  Questions to Ask

  • Does the narrative change when viewed from a different perspective? A variety of perspectives can make a narrative much more fascinating. Bear 71 forces us to see the world first from the bear’s perspective and to sympathize with its loss of habitat, but other viewpoints take a slightly different angle. The voyeurism common in our digital sharing culture takes on a different meaning when used for animal surveillance.
  • What data sets can be used in the narrative? Bear 71 cleverly combines crittercam video, GPS data, cell tower data, augmented reality, and topographical data. The photographs of visitors to the installation provide an additional emotional layer of data. The data we bring into our stories helps to define additional viewpoints and characters.

  3. Redefine A Tradition

  As Western culture has moved more deeply into Nigeria, Nigeria’s traditions are weakening. I wanted to take a piece of my culture and put it in the cloud, instead of leaving it locked in the heads of our oral storytellers. That meant redefining how the stories are relayed, how they are saved and, most importantly, what messages they convey to the audience.

  In 2011, I started a project named Pixel Fable in which I take those traditional stories and reinterpret them online. In essence, I’m creating an interactive archive of Nigerian stories. As mentioned earlier, the oral histories of Nigerians are rich, but capturing them and translating them into digital stories means they will reach a wider audience. About 25% of my website’s visitors come from the US, while another 25% come from Japan. Canada, France and Germany also send a fair amount of traffic.

  Pixel Fable uses responsive websites, iOS apps and augmented-reality animations to reinterpret Nigeria’s oral history.

  
  An introductory screen from “Cricket and Mud Brick,” a new Pixel Fable story built with the Tapestry app

  I’ve relied on two primary contexts to reinterpret the old Nigerian storytelling tradition. The first is people on their tablets and phones, clicking on and reading the stories. The spread of mobile devices makes this inevitable — why not tell African fables in a more accessible context? The second is my attempt to update the moral lessons for our modern age. While the original story of the Ear and the Mosquito may be a funny tale about annoying insects, the lesson can be updated to speak about how mosquitoes spread malaria in Nigeria. There’s room to redefine our old myths for the 21st century.

  Questions to Ask

  • Will people love or hate the reimagined version? Not every fable or myth can (or should) be recreated digitally. However, if people have an emotional reaction to a story that you have designed and pushed out to multiple screens, that is usually a good sign.
  • If people talk about your narrative, will it bring about change in society? Each Pixel Fable story has a message. Most fables do. Some revolve around love triangles, others around the wisdom of elders, and there’s even one about why you shouldn’t get angry at your friends. They are small messages, but put together, they force us to reconsider how we treat the narrative history of people in Nigeria and West Africa.

  4. Immerse People In The Narrative

  The Walking Dead, the famous comic and now TV show, used a polling Web app (AMC’s Story Sync, if you like marketing-speak) to ask viewers questions and show related content as an episode was being broadcast on TV. While the app was simply timed to each scene, it was an experiment in multi-screen storytelling that invited audience participation, not just audience attention. Polling has a gimmicky feel to it, but that probably came about as a result of Hollywood pressure and doesn’t reflect the value of the concept in general.

  
  Polling and syncing apps extend narratives from the TV to the couch.

  The creators also added mobile gaming to the mix, bringing viewers “into” the story in a completely different way, in different contexts.

  All of these facets of each story’s arc enabled people to immerse themselves in this apocalyptic narrative. Jason Spero of Google notes the need for a seamless experience as users move between devices. Other people, however, say that a second-screen experience can be extremely distracting, forcing viewers to miss key parts of the TV show. It is the opposite of an immersive experience, they say, and is confusing to use. In my opinion, each content block should work independently to avoid putting users in this position.

  Questions to Ask

  • Will people forget where they are? I’ll be the first to admit that this is not always a good thing. I can’t count the number of times that I’ve almost missed my train stop because my head was buried in my phone. Context, not only device capability, is key. Do you want users to get lost in the story or just engage in a manageable chunk?
  • Do the screens you have chosen feel natural? By this, I’m not referring to pixel density. That is simply impossible to control, and if the story if good, it won’t matter anyway. The screens that people choose will depend a lot on the tasks they want to complete, so make your story feel natural for whatever content block they are interacting with.

  5. Design Contextual Interactions

  Recently, a number of storytelling apps have relied on location to serve additional content, much in the same way that Foursquare or Google Maps do. The Silent History is a dystopian science-fiction story about children who do not speak. The iPad app contains the whole story, but by visiting certain geo-tagged locations, users can access additional content.

  

  For a novel about children all over the US, inviting readers to physically go to where the story’s kids are makes perfect sense. The additional contextual interaction makes the story more layered and thought-provoking, in a way that a simple app would not be.

  We use map data every day, to look for restaurants, check the weather, see road conditions and even check for public transit delays. Other contextual interactions make sense when creating digital stories: taking photographs, texting, sharing and saving information, even body motion. Use these, along with your UI and UX skill sets, to devise new storytelling methods.

  Questions to Ask

  • Does the device matter? With the rise of responsive design workflows, our content should not be device-dependent. Some things, however, such as camera or GPS functionality, may be integral to a part of your story, and so the device would need to be factored in.
  • Should the interface be designed as a seamless part of the narrative? As people who work on the Web, we really have a strength here. If we choose to make the interface part of the story, then we can rely on our experience in building websites and content management systems.
  • Will your story “remember” anything? As a child, I folded over the top corner of the page when I had to put a book down. It was a simple way to keep my place. With a narrative split across multiple devices, it might be necessary to design an interaction that flags where you’ve gotten to and then returns you there when you visit again. That all depends on the content, but the question does need to be asked. Everyone hates losing their place on the Internet and having to navigate back, so perhaps we should enable a memory in our stories as well.

  Conclusion

  We have conceptualized different uses of multiple screens to tell stories. All of us, from every corner of the globe, have intensely rich cultures filled with stories and fables. Using them to create interactive narratives is another way to explore the power of the Web, to wow people and to record our cultural history.

  I would love to see what you come up with, or hear about other examples of clever digital storytelling.

  (al) (ea)

  ---

  © Senongo Akpem for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/13/fables-myths-and-narratives-converting-our-stories-into-multi-screen-experiences/feed/ 0 http://sayingitfirst.com/2013/05/10/keeping-the-big-picture-small-how-to-avoid-duplicate-downloads-in-responsive-images/?utm_source=rss&utm_medium=rss&utm_campaign=keeping-the-big-picture-small-how-to-avoid-duplicate-downloads-in-responsive-images http://sayingitfirst.com/2013/05/10/keeping-the-big-picture-small-how-to-avoid-duplicate-downloads-in-responsive-images/#comments Fri, 10 May 2013 19:52:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/10/keeping-the-big-picture-small-how-to-avoid-duplicate-downloads-in-responsive-images/ The element is a new addition to HTML5 that’s being championed by the W3C’s Responsive Images Community Group (RICG). It is intended to provide a declarative, markup-based solution to enable responsive images without the need of JavaScript libraries or complicated server-side detection. The element supports a number [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

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

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

  The Element And Fallback Content

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

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

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

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

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

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

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

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

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

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

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

  The element also has the ability to use non-image fallbacks, which should be great for accessibility: if no image can be displayed or if a user needs a description of an image, then a

  or or
  or any other element may be included as a fallback. This allows for more robust and content-appropriate fallbacks than a simple alt attribute.

  The Fallback Problem

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

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

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

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

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

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

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

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

  A Potential Solution

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

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

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

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

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

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

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

  I ran five tests:

  1. falls back to
  2. falls back to
  3. falls back to , which falls back to
  4. falls back to , which falls back to
  5. falls back to

  I found the following support:

  What the user sees

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

  HTTP requests

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

  Image-aware context menu

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

  Making Sure The Content Is Accessible

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

  Read by VoiceOver

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

  Read by VoiceOver

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

  Bulletproof Syntax

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

  
  <picture alt="fancy pants">
      <!-- loaded by browsers that support picture and that support one of the sources -->
      <source srcset="big.jpg 1x, big-2x.jpg 2x, big-3x.jpg" type="image/jpeg" media="(min-width: 40em)" />
      <source srcset="med.jpg 1x, med-2x.jpg 2x, big-3x.jpg" type="image/jpeg" />
  
      <!-- loaded by IE 8+, non-IE browsers that don’t support picture, and browsers that support picture but cannot find an appropriate source -->
      <![if gte IE 8]>
      <object data="fallback.jpg" type="image/jpeg"></object>
      <span class="fake-alt">fancy pants</span>
      <![endif]>
  
      <!-- loaded by IE 6 and 7 -->
      <!--[if lt IE 8]>
      <img src="fallback.jpg" alt="fancy pants" />
      <![endif]-->
  </picture>
  
  .fake-alt {
      border: 0;
      clip: rect(0 0 0 0);
      height: 1px;
      margin: -1px;
      overflow: hidden;
      padding: 0;
      position: absolute;
      width: 1px;
  }
  

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

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

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

  
  <video poster="fallback.jpg">
      <!-- loaded by browsers that support video and that support one of the sources -->
      <source src="video.mp4" type="video/mp4" />
      <source src="video.webm" type="video/webm" />
      <source src="video.ogv" type="video/ogg" />
  
      <!-- loaded by browsers that don't support video, and browsers that support video but cannot find an appropriate source -->
      <img src="fallback.jpg" alt="fancy pants" />
  </video>
  

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

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

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

  How Good (Or Bad) Is This Solution?

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

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

  And there are some practical issues:

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

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

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

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

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

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

  Next Steps

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

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

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

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

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

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

  (al)

  ---

  © David Newton for Smashing Magazine, 2013.

  Source: <a href=http://www.smashingmagazine.com/2013/05/10/prevent-duplicate-images-downloaded-picture-element/ class="colorbox" title="Keeping The Big <picture> Small: How To Avoid Duplicate Downloads In Responsive Images”>Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>http://sayingitfirst.com/2013/05/10/keeping-the-big-picture-small-how-to-avoid-duplicate-downloads-in-responsive-images/feed/0 http://sayingitfirst.com/2013/05/10/sharing-your-experiences-how-to-contribute-to-wordpress/?utm_source=rss&utm_medium=rss&utm_campaign=sharing-your-experiences-how-to-contribute-to-wordpress http://sayingitfirst.com/2013/05/10/sharing-your-experiences-how-to-contribute-to-wordpress/#comments Fri, 10 May 2013 17:47:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/10/sharing-your-experiences-how-to-contribute-to-wordpress/ WordPress is built by volunteers. People from all over the world collaborate to create the core software, write the documentation, provide support, translate WordPress, organize events and generally keep the project running. Individuals work on WordPress in their free time, and companies ask their employees to get [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>

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

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

  
  A bunch of WordPress contributors.

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

  Why Get Involved?

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

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

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

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

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

  A number of challenges face the WordPress project:

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

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

  Core

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

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

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

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

  Challenges

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

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

  Get Involved

  You can start getting involved in a number of ways:

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

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

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

  User Interface

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

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

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

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

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

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

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

  Get Involved

  There are a number of ways to get involved:

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

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

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

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

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

  Mobile

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

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

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

  Challenges

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

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

  Get Involved

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

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

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

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

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

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

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

  Polyglots

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

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

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

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

  Challenges

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

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

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

  Of course, things will always get lost in translation:

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

  Get Involved

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

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

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

  Support

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

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

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

  WordPress’ support volunteers focus on the following areas:

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

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

  Challenges

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

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

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

  Get Involved

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

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

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

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

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

  
  Be super-helpful by answering unanswered questions.

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

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

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

  Theme Review

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

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

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

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

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

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

  Challenges

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

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

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

  Get Involved

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

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

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

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

  Plugin Directory

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

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

  The team does the following:

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

  Challenges

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

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

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

  Get Involved

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

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

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

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

  Documentation

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

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

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

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

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

  Challenges

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

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

  Get Involved

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

  
  Editing the Codex is easy — go try it!

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

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

  Events

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

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

  Challenges

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

  Get Involved

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

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

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

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

  Accessibility

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

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

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

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

  Challenges

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

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

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

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

  Get Involved

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

  There are two distinct streams for getting involved:

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

  And a note to any WordPress developers:

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

  Community

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

  
  Andrea likes hugging people. (Image: Andrea Rennick)

  I asked Andrea what the group will be doing:

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

  Challenges

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

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

  But those aren’t the only challenges:

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

  Get Involved

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

  BuddyPress and bbPress

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

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

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

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

  Challenges

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

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

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

  Get Involved

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

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

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

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

  What’s In It For You?

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

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

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

  Tips For Getting Involved

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

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

  Some Final Advice

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

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

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

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

  Contributor Information

  Make WordPress Blogs

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

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

  Chat Schedule

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

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

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

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

  (al) (il)

  ---

  © Siobhan McKeown for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/10/sharing-your-experiences-how-to-contribute-to-wordpress/feed/ 0 http://sayingitfirst.com/2013/05/09/5-ways-social-data-can-be-used-to-win-customer-love/?utm_source=rss&utm_medium=rss&utm_campaign=5-ways-social-data-can-be-used-to-win-customer-love http://sayingitfirst.com/2013/05/09/5-ways-social-data-can-be-used-to-win-customer-love/#comments Thu, 09 May 2013 20:21:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/09/5-ways-social-data-can-be-used-to-win-customer-love/ Marketing folks are all atwitter (Yes, we went there – you don’t like puns?) about how social media has changed marketing. But here’s the thing: at its core, marketing hasn’t actually changed.  It’s still about communication with customers.  What social media has done is transform marketing by [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> Marketing folks are all atwitter (Yes, we went there – you don’t like puns?) about how social media has changed marketing.

  But here’s the thing: at its core, marketing hasn’t actually changed.  It’s still about communication with customers.  What social media has done is transform marketing by making it easier and more intuitive to connect with your customers directly while simultaneously giving you greater insight into individual needs and desires.

  Simply put, social media is a more efficient way to connect with customers on their own turf.  There are literally millions of consumers shouting (well, tweeting, Facebooking and +1ing) what they want and when they want it on a 24-hour basis.  Your challenge? Managing the data and turning it into effective marketing.

  When done properly, social media management allows you to increase brand awareness, improve customer service and create customer experiences that customers will rave about.

  How can #SMB use #socialmedia to drive success? In a word—data.  In two words—using data.

  Social media including Twitter, Facebook, Google+ and blogs are all key to the online marketing success of any small to medium-sized business.  But how can they be used to drive customer relationships?

  In a word: data.

  In two words:  using data.

  In 912 words:  These 5 tips will help you use the information gathered from a customer’s — or potential customer’s — social media presence using a social media management tool.

  1Personalize Your Messages

  Get to know your customer.  By understanding their personal interests — whether it be running, sailing, or the latest episode of “Backwoods Pregnant Teens in Beauty Pageants” — you can spur new discussion.  Respond to what they said about last night’s episode, ask about their training, or even just how their kitchen remodeling is going.  Just get them engaged.

  BUT!!! Be sincere about it – you aren’t looking for an excuse to mention your product, you’re looking for a reason to connect. This is not unlike bumping into your crush at the grocery store.  You wouldn’t just start by proposing marriage.  You would ask about them, their upcoming 5K, or even (in a pinch), talk about the weather before you asked them on a date. The same applies to your brand in social media – you want to connect with your customers in a genuine and human way. It’s called social media for a reason – be sociable and don’t miss any opportunity to chat up a customer.

  2Deliver The Right Message At The Right Time

  Imagine that you’re a kitchen cabinet manufacturer and your social media management software flags the following tweet:

  JoeConsumer: @WifeConsumer just told me it’s time to remodel the kitchen. The #HoneyDo list just keeps getting bigger.

  Now’s the time to respond and offer advice and suggestions on how to most efficiently do the project, what pitfalls to watch out for and maybe throw in a discount offer on cabinets.

  However, not every insight is a good buying signal. If the same consumer tweets that his house just burned down, you probably want to hold off on offering discounted cabinets. No one likes an ambulance chaser – even one hawking deeply discounted cherry cabinets.

  3Tailor Messages To Personalized Interest Segments

  Pay attention to customer segmentation signals – themes and interests that a significant percentage of your customers are interested in. Are your customers fans of craft beers? Use an analogy in your marketing campaigns that explains how your product is as unique as their favorite brew. Maybe your streams are full of running benchmarks and shared records of daily running activity – it’s a good bet that tying your product to the personal drive and self-satisfaction that goes with running will really resonate.

  The upshot is that you no longer have to guess what specific features of your product people will like – you know what they like, now just explain to them how your product matches those desires.

  4Give Them Personalized Love

  When you want to tell a customer you appreciate them, there is no better way than to send a gift that is unique (no, baskets of crackers and sausages are not unique — plus, the crackers always end up tasting like the basket).

  If you do something above and beyond for your customers, others will hear about it.  Guaranteed*

  Going back to personalized campaign insights, if many of your primary customers are runners, a thoughtful gift or incentive would be a gift card to a sporting goods store. This shows them you care about them and know what matters to them and it goes a long way toward building customer loyalty.

  There is a caveat here – beware of becoming the Creepy Online Stalker Company. You know, like the one that hosts your email and shows you ads related to rash cream because you emailed your sister about a rash ONE TIME and it turned out to be NOTHING but still you see the ads every time you log in… There’s a fine line between insightful offers and creepy web-stalker activities.

  A good rule of thumb is that you should discuss (and feel comfortable discussing) the topic with your customers before offering the incentive or gift that relates to it.

  5Anaylze Sentiment Trends

  Take a second to read through your Facebook page. Better yet, use a social media monitoring tool (may we humbly suggest Rignite?) to conduct some conversation research for your brand or market.  Afterwards you should be left standing knee deep in a big pool of data. Now comes the fun part.

  Grab your magnifying glass and start taking a deep look at the data. You’re looking at not only what people are saying, but how they are saying it. Sure it’s great if your customers are talking about your new line of watermelon flavored steaks, but lots of volume doesn’t automatically mean the conversation is good. You’ll want to take a look at the sentiment behind the message.

  

  Are your customers saying they love or like that new steak? That it changes their world and is indeed the very thing that causes angels to sing and seals to play tiny horns?

  Or are they saying the exact opposite?

  By analyzing the sentiment trends that emerge from the data you can identify which areas of your business are going well and which areas need improvement. Better yet, see what the sentiment around your competitors’ conversations look like. By analyzing sentiment trends you could walk away with some ideas for your next marketing campaign, new product developments and even new customers.

  Successful companies have learned that a big and bold social media strategy can reap big and bold rewards – but it all starts with the data your social media management system can gather for you. Using the data and signals your customers are broadcasting on Twitter, Facebook, Googe+, and more is the most effective way to make a big splash with social marketing.

  *Not actually guaranteed, but the chances are very very very good.

  Are you using social data to improve your connection with your customers?  Tell us in what ways social media has helped you get more love from your customers.

  Source: Rignite

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/09/5-ways-social-data-can-be-used-to-win-customer-love/feed/ 0 http://sayingitfirst.com/2013/05/09/brave-new-world-designing-for-a-maturing-android/?utm_source=rss&utm_medium=rss&utm_campaign=brave-new-world-designing-for-a-maturing-android http://sayingitfirst.com/2013/05/09/brave-new-world-designing-for-a-maturing-android/#comments Thu, 09 May 2013 18:20:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/09/brave-new-world-designing-for-a-maturing-android/ Android is huge: 480 million people currently use Android devices, and 1 million new devices are activated daily. This means that every three weeks, the number of people who activate new Android devices is equal to the entire population of Australia. (Recent studies by Nielsen show that [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Android is huge: 480 million people currently use Android devices, and 1 million new devices are activated daily. This means that every three weeks, the number of people who activate new Android devices is equal to the entire population of Australia. (Recent studies by Nielsen show that more Android devices are on the market than iOS devices.)

  Popular apps that become available on Android experience huge growth. For example, Instagram grew by 10 million users with the launch of its Android app — in just 10 days.

  

  Despite this unprecedented expansion of the platform, the majority of Android apps are… well, not great. Fewer quality apps are in Google Play than in the iTunes Store. Part of the reason for this is that Android has been going through puberty in the past few years. It was disorganized and erratic, and many designers avoided it — even hated it — and naturally gravitated towards iOS.

  Some of Android’s problems no longer exist, and others have been blown out of proportion. For the ones that do exist, we’ll provide guidance on how to deal with them and how to start designing your first great Android app.

  Symptoms Of Puberty

  Many Android apps underperformed because the platform wasn’t mature enough to allow great apps to emerge. Though a powerful laboratory — it offered manufacturers and developers the freedom and openness to create whatever they wanted — not many wanted to work in a sandbox environment every day. But that sandbox has since coalesced into a foundation for great design.

  

  The points below are what you might remember about Android — and possibly what curbed your desire to give it a try — but these issues have also been eliminated or improved. If your concerns appear in this list, then the next section will demonstrate how they’ve been resolved with Android’s maturation and how you can design a better app as a result.

  Lack of Consistency in Google’s Own Apps

  Not long ago, almost all of Google’s own Android apps looked different from each other.

  
  Google took more than a year to start following its own advice. The action bar design pattern was presented in 2010 but wasn’t implemented until October 2011, with Android OS 4.0.

  Lack of a User-Centric Design Culture in the Android Community

  Google’s failure to set an example for other developers (because of its own inconsistencies) and the lack of consistent design guidelines and patterns contributed to another bigger problem: poor user experience. Good design starts with people; it leverages technology to help users accomplish their goals. Google wasn’t communicating this to developers clearly enough (unlike Apple).

  Dramatically Inconsistent Experience Between Devices and OS Versions

  Manufacturers often customize the system’s UI and hardware buttons. This contributed to fragmentation, made testing and quality control much harder and made consistency in app design nearly impossible.

  
  Manufacturers used to put hardware buttons in different orders. Switching between devices was a pain.

  Properly testing apps in the changing and fast-growing market was difficult for developers. Thus, a majority of apps didn’t function as they should have or were poorly designed.

  Those apps are still there, but yours doesn’t have to be one of them. Android has since improved, enabling you to create a better and more consistent experience for your users.

  Android Has Matured

  The Android user experience today is more robust than ever before, making it easier for app designers and developers to deliver great apps. While some of the earlier problems still exist, most have become more manageable — and many more have been solved altogether.

  One fundamental problem remains, however: there aren’t enough great apps. But with an improved and mature Android platform, designers and developers can solve this problem. All we have to do is give Android another chance.

  

  The areas below are what the mature Android has to offer.

  Better App Discovery

  Previously, the discovery process was limited to searching by keyword and then trying out all of the results. The new Google Play store offers better discovery through featured apps and staff picks.

  
  The new Google Play store offers more ways to discover cool new apps than its predecessor, Android Market.

  Proper Android Design Guidelines

  Until recently, no direction was provided for the basic elements that every app requires. Google has since created design guidelines, which remove the burden of small design decisions from app designers and developers. We can finally focus on the core value of the apps we’re creating and ensure a consistent experience across devices.

  
  Example of a grid and a 48 density-independent pixel (DP) rhythm, taken from the “Metrics and Grids” section of the guidelines.

  Menu and Search Hardware Buttons Are Gone

  Google has started removing hardware buttons from its devices, uniting the hardware and software and making Android devices more elegant and easier to use.

  
  The Nexus 4 is an instance of Google’s new approach to hardware buttons. They are always there, always in the same order. And gone are the search and menu buttons.

  A variety of Android device types still exist (for example, LG still produces devices with Android 4.0 and hard menu buttons), yet this diversity is one of the main reasons why Android apps are able to excel.

  Fragmentation Isn’t All Bad

  Fragmentation may be the biggest remaining challenge facing designers and developers, and it’s built into Android’s DNA — a permanent part of the Android experience. This diversity offers designers an opportunity to reach an unprecedented number of people globally.

  Learning to work within this fragmentation will make you a better designer or developer overall, with broader knowledge and an improved skill set. Given the rewards, the challenge is worthwhile to pursue. And to succeed in this pursuit, here are a few things to keep in mind when creating your Android app.

  

  Tips For Creating A Successful Android App

  Get to Know Android

  To understand Android, you should learn how to use it and get to know its users. The best way to do this is by buying several devices from different manufacturers, with different screen sizes and maybe even OS versions. This will help you not only to understand user diversity but also to test your app.

  To choose the best devices for your app, check the latest statistics from Google and select a device with your desired specifications. Independent studies, such as OpenSignal’s August 2012 report, can also help you select devices.

  Something to keep in mind is that Android updates are controlled by service providers and, as a result, usually arrive earlier on devices that are created in collaboration with Google, such as the Nexus series. Picking up the latest Nexus devices will keep you on the cutting edge of platform releases. You can save money by buying a used device, but make sure it runs the version of Android that you need before purchasing it (many old devices are no longer updated).

  Talk to your Android-using friends about how they use their devices and what they are happy and unhappy about. That will help you get to know the environment and bring you into the culture.

  Follow the Guidelines

  Following the guidelines will help you create an app that feels native to any device. But that’s just one of many reasons why following them is worthwhile. They can also help you achieve the following:

  • Create an app fit for virtually any device,
  • Make the app feel true to Android,
  • Provide a UI that is familiar to users,
  • Make the app easier to develop and support,
  • Increase the app’s chances of being featured in Google Play.

  Keeping Android navigation patterns in mind and using elements that are native to the platform will also help you create a consistent experience across devices.

  
  When bringing an iPhone design (left) to Android (right), use elements that are native to the platform: this table view is styled for Android; the buttons for searching and adding contacts are moved to the split action bar at the bottom; and switching between data views is done through the view control.

  Custom apps are more difficult not only to support, but also to design when ensuring operability across devices. New Android apps look great thanks to the new design guidelines; they are also very different from apps created before Android 4.0.

  Understand Android’s Look and Feel

  Google has invested a lot of effort in bringing a consistent visual experience to all of its products, including Android. Android 4.0 introduced its own style: simple, plain, clean — more about function than form.

  Although this provides great freedom in styling, you still have to consider the subtlety of Android’s visual style: saying more with less. Simply copying the styles and elements from an iOS app might not work. And releasing a new app with old styles or with elements that look like they belong on another platform could make users react negatively — which happened to Microsoft.

  Browsing Android Niceties is a great way to grasp Android’s style and to find inspiration.

  
  Google’s Search app is a great instance of Android’s look and feel.

  A good way to distinguish your app is through its icon. App icons for Android can take any shape or form. Users love great-looking icons and will gladly put your app on their home screen even if they don’t use it often. For tips on designing your icon, read the “Iconography” section in the guidelines.

  
  App icons for Android can take any shape and form you want.

  Build for Different Hardware Types

  When designing your app, ensure that it will run properly on most devices. Keep in mind not only different screen sizes and aspect ratios, but also screens with low brightness or poor contrast and color, as well as slow, weak hardware.

  For example, less-expensive devices might have smaller displays with lower contrast, so text that appears big enough on new devices with large screens might appear illegible there. Low contrast of text and visual elements might compromise the user experience as well.

  
  Designs created according to the guidelines will easily scale to fit virtually any screen.

  A few more things to keep in mind:

  • Use contrasting colors for text and elements. For example, don’t use white on gray for important elements; they’ll just blend together on bad displays.
  • Check your design on several devices with different brightness settings (low, high, auto) and in different lighting conditions.
  • Even when using standard sizes, make sure your text and UI elements appear big enough on small screens (i.e. screens with a DPI lower than 240). You might want to adjust these elements specifically for small devices.

  For a great example of designing for diversity, read Sebastiaan de With describe the process of creating the Alarm app.

  Use Density-Independent Pixels to Define Layout

  Part of providing a consistent experience is ensuring that UI elements stay roughly the same size across Android devices with varying pixels per inch (PPI). This doesn’t have to be a laborious task of calculating the number of pixels a button or font should contain in order to look great on a particular screen size. You can make the device do the work for you.

  
  The recommended size for buttons in the action bar is 48 DP, which will result in different pixel sizes on different screens, but you don’t have to worry about that.

  By defining sizes with density-independent pixels (DPs), you ensure that elements will appear at about the same physical size on any screen. Text will remain readable, and buttons will be comfortable to tap on any Android device, regardless of screen size or DPI. (See the section “Use Density-Independent Pixels” in the guidelines for more.)

  
  In our practice, giving developers guidelines on sizes of elements and fonts has proven useful.

  6. Create Assets for All Densities

  Four sets of assets are required to accommodate all Android devices and to make the interface crisp: low density (LDPI), medium density (MDPI), high density (HDPI) and extra-high density (XHDPI). Start with a 640 × 960 screen for XHDPI assets, and then scale them down for other densities.

  
  Start with XHDPI, and then scale down to other densities. Compare the actual sizes of these assets.

  MDPI and XHDPI resolutions are exactly the same as the iPhone’s regular and Retina screens. So, if you have an iPhone design, you can use it to style the Android counterparts, or you could even test your designs on iPhone or iPod screens. But don’t forget about Android’s unique look and feel.

  An XXHDPI bucket has been added to support the next generation of mobile devices, those with approximately 480 DPI screens. Although no such devices exist yet, the XXHDPI bucket is used today for launcher icons on XHDPI 10-inch tablets, such as the Nexus 10. (Because these devices are so large, the launcher icons are scaled up using the XHDPI assets.) To accommodate the next generation of screens, all you’ll need to do is scale your HDPI assets up by 200%.

  Consider Different Versions Of The OS

  Many Android devices will never be updated to the latest OS; it takes a couple of years for new versions to dominate the market. But users with newer devices won’t be pleased with apps whose looks or controls are outdated (as demonstrated by Microsoft’s Outlook app, mentioned earlier). So, deliver the most up to date experience possible. If you intend for the app to run on older platforms, create a separate version of the app for those devices.

  Expand Your App With Widgets and Live Wallpapers

  Take advantage of Android’s engaging features, such as widgets, live wallpapers and notifications. Widgets enable users to receive updates without running the app, and notifications are improving with each version of Android. Google is providing great support for designers and developers on how to notify users.

  Widgets are a convenient way to peek into an app without opening it. This enables you to focus a user’s attention on a small portion of information, which would then expand within the app.

  
  Widgets may have buttons and scrollable areas. Think of them as advanced app icons.

  
  Gmail’s widget offers a sneak peek into the mailbox and enables users to compose mail right from the home screen. Chrome’s grid-view widget displays favorites or history.

  Android users love to customize their devices and make them personal, and these items give them greater flexibility to do so.

  Properly Test on Devices You Support

  One of the most common reasons for negative reviews in the Play store is an app not functioning as promised. Target your design to the most popular devices, and release only for the ones you have tested; otherwise, you’ll end up with bad reviews from people frustrated by your app not working properly.

  The highly successful Dead Space game receives most of its one-star reviews because the game doesn’t run on certain devices.

  Design for Tablets, Too

  Although several great Android tablets are on the market, they are not as popular as competitors such as the iPad. But if your goal is to build a truly universal Android app, then you need to consider tablets as well. The guidelines advise designers to use multi-pane layouts for tablet UIs and to build their interface using fragments.

  Tablets use the same graphical assets as phones, but consider the context in which tablets are used. For instance, people usually hold tablets further away from their eyes than phones and, thus, are less precise in their tapping. So, the UI will require larger fonts, bigger buttons and more white space around elements.

  Don’t forget to run your app through the “Tablet App Quality Checklist” as well.

  Give Android A Chance

  Designing for Android might be challenging in the beginning — it’s not as simple as it looks — but by following these 10 steps, you’ll have a head start on delivering a fantastic user experience and building a truly great app.

  Give Android a chance. Designing for this newly matured platform is an interesting and educational process, and you’ll deliver a great-looking app while obtaining a new set of skills. You might find the experience to be very rewarding.

  Update: While we were writing this article, case study has been published by The Verge about the Facebook Home application — next big thing for Facebook. But this isn’t about Facebook anymore. Thought this particular application is quite controversial, with limited device support and experience far from perfect, Fb designers have proven that with enough effort 100% of your ideas can be implemented and delivered on Android with no compromise. They have revealed a great opportunity and may even have marked the beginning of a new trend of creating greater presence on Android.

  Examples of Great Android Apps for Inspiration

  • The Verge
  • doubleTwist Alarm
  • Skype
  • Evernote
  • Foursquare
  • Tumblr
  • New York Times
  • Path
  • Endomondo
  • Expedia

  (al) (ea)

  ---

  © Alexander Komarov and Nikita Yermolayev for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/09/brave-new-world-designing-for-a-maturing-android/feed/ 0 http://sayingitfirst.com/2013/05/08/psst-smashing-magazine-is-hiring-were-looking-for-a-senior-editor/?utm_source=rss&utm_medium=rss&utm_campaign=psst-smashing-magazine-is-hiring-were-looking-for-a-senior-editor http://sayingitfirst.com/2013/05/08/psst-smashing-magazine-is-hiring-were-looking-for-a-senior-editor/#comments Wed, 08 May 2013 17:23:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/08/psst-smashing-magazine-is-hiring-were-looking-for-a-senior-editor/ Editorial work at Smashing Magazine is a difficult, challenging process. It requires patience, focus and thoroughness. Our readers have high expectations, and our authors expect sophisticated editorial guidance. That’s what we are known for, and that’s where we could use your help. We’re looking for a hard-working [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Editorial work at Smashing Magazine is a difficult, challenging process. It requires patience, focus and thoroughness. Our readers have high expectations, and our authors expect sophisticated editorial guidance. That’s what we are known for, and that’s where we could use your help. We’re looking for a hard-working editor with technical experience to support and complement our team.

  Such an editor can’t be found on any of the innumerable job boards out there. Because the position is one of the most important to our publication, we are looking for the best editor from our community — someone who truly understands Smashing Magazine and what it stands for. We would never otherwise publish a job opening on our front page — in this case, we made an exception.

  Where? Freiburg, Germany.

  We’d love to welcome you onto our team in Freiburg, Germany (Google map). In addition to enjoying the beauty of this student city, with its medieval city center, lovely vineyards and proximity to the Black Forest, you’ll also have France and the Swiss Alps just around the corner. Of course, you’ll also enjoy the playful spirit and open-mindedness of Smashing Magazine’s international team members, who like to work as hard as they party.

  
  (Image: Björn Freiberg)

  Your Responsibilities

  We prefer that our team members focus on a few important tasks and do them well. Here are some of the tasks and responsibilities you will have:

  • Continually acquire and communicate with authors, in accordance with our editorial process and publishing policy.
  • Plan, edit, perform quality control on and publish articles on Smashing Magazine.
  • Shape and contribute to the editorial direction of the magazine.
  • Refine the content strategies for existing and future content.

  What We’re Looking For

  We are looking for professionals who know exactly what they’re doing. Here’s what we expect from you:

  • A strong sense of craftsmanship in your work — whether in writing, editing, communication or simple HTML.
  • Be curious to experiment and get creative with new forms of content and with design- and coding-related topics.
  • Know and understand what it takes to make high-quality content for the Web.
  • Be familiar with the Web design community and the industry in general.
  • Be willing to challenge authors to leave their comfort zone, and make every article stand out from the crowd by being interesting, engaging, appealing — perhaps even extraordinary.
  • Have excellent written and verbal communication skills in English. We’d love for you to have solid experience in copywriting as well, but that’s not necessary.
  • Knowledge of Web design is necessary, both technical and non-technical, but we don’t expect you to be a ninja in all of it — a jack of all trades is just fine!

  

  How to Apply

  Interested? Fantastic! Please send your cover letter, résumé, work samples and URLs of relevant websites to me, Vitaly Friedman, at the following email address:

  vitaly [at] smashingmagazine.com

  We have a lot of exciting ideas for the magazine — we just need people who we would love to work with and who we can trust to make these ideas a reality. With your help, we can make this magazine even better and richer than it has ever been.

  We look forward to your application.

  (al)

  ---

  © Vitaly Friedman for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/08/psst-smashing-magazine-is-hiring-were-looking-for-a-senior-editor/feed/ 0 http://sayingitfirst.com/2013/05/07/the-smashing-editors-choice-a-free-ebook/?utm_source=rss&utm_medium=rss&utm_campaign=the-smashing-editors-choice-a-free-ebook http://sayingitfirst.com/2013/05/07/the-smashing-editors-choice-a-free-ebook/#comments Tue, 07 May 2013 19:51:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/07/the-smashing-editors-choice-a-free-ebook/ Nearly half a year ago, we introduced our eBook subscription model, also known as the Smashing Library. We knew we were onto something good, realizing that the Smashing Library was the next step in offering quality content — at a price you’ll still be able to afford [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Nearly half a year ago, we introduced our eBook subscription model, also known as the Smashing Library. We knew we were onto something good, realizing that the Smashing Library was the next step in offering quality content — at a price you’ll still be able to afford all of the coffee you need to stay up long enough to read the entire library and, of course, the free eBooks.

  
  A subscription to the Smashing Library is only $99 a year.

  A subscription to the Smashing Library grants you unlimited access to all of the previously published Smashing eBooks, as well as a guaranteed 24 new eBooks throughout the year. This includes all digital versions of the Smashing Book series, including the The Mobile Book and the upcoming Smashing Book #4.

  And our library is getting even more smashing. We didn’t want to limit the library to just our own content, so we are now including a growing number of industry-related eBooks. These books are by authors who aren’t necessarily affiliated with Smashing Magazine but who produce great content. In addition to saving more than half off the regular bundle prices, as a subscriber to the Smashing Library, you will get the opportunity to vote on what we publish next and what new eBook downloads will be automatically available in your Smashing Shop dashboard.

  
  Download the “Smashing Library Catalog” (PDF, 4.7 MB) and get started today!

  The Smashing Editor’s Choice

  To give you a taste of what to expect from the eBooks in the Smashing Library, we are happy to present you with The Smashing Editor’s Choice: A Smashing Library Treat — a free eBook that contains a wide range of topics, including new coding techniques, user experience strategies, responsive design and mobile solutions by some incredibly prolific and knowledgeable authors. Well-known names such as Lea Verou, Christian Heilmann and Dmitry Fadeyev have contributed fascinating chapters on various subjects.

  
  Sign up below to receive your free copy of The Smashing Editor’s Choice.

  The Smashing Editor’s Choice eBook is only a sample of the kind of quality Smashing eBooks that are available in the library. We select only the best articles, wrap them in a user-friendly layout, and make them available in the three most common formats, PDF, EPUB and Kindle. And because we don’t want to impede your use of the eBooks, they’re all DRM-free.

  If you like this eBook, then you’ll love the Smashing Library. Just fill in your email address below, and you will receive an email containing a download link to your free eBook copy of The Smashing Editor’s Choice, as well as our bi-weekly Smashing Newsletter, which is full of useful tricks, techniques and tweaks.

  Sign up to receive a link to the free eBook:

  What Subscribers Think of the Smashing Library

  Coming up with the subscription library model took meticulous planning and careful editorial work. Adding eBooks on a monthly basis and keeping up with industry trends take passion. Luckily, we have a lot of that. From the beginning, we had a feeling that the library would be popular, and with the surprisingly positive launch, you proved us right:

  “A perfect resource for a full-service Web-dev company. I own and operate a Web development company. This provides a vast store of wisdom for daily operations across the board.”
  – Taylor Black

  “Unbelievable bargain! This is indeed a great offer if you’re thinking about purchasing several books and if you want to keep up with current developments. Very curious about what’s yet to come this year!”
  – Joachim

  “The best magazine is up with the best books. I recently received “The Mobile Book.” That was awesome, and I hope this will be 38X awesome. Worth reading!”
  – Erik Royall

  “Great books, nice offer! I already own Smashing Book #3 and was thinking about buying the mobile/coding bundle when I stumbled upon this offer. Been reading (almost) nonstop ever since, loving it so far! Thanks, Smashing!”
  – Bernd

  We try to make the Smashing Library worthwhile by adding new content regularly and by giving you, the subscriber, the choice of what we publish next. All downloads, eBook polls and news are accessible through your personal Smashing Shop dashboard. Have a look at what the library looks like when you’re logged in:

  
  A preview of the Smashing Shop dashboard.

  Thank you all for your support over the years, everyone! You’ve been truly smashing!

  (al) (il)

  ---

  © Jan Constantin for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/07/the-smashing-editors-choice-a-free-ebook/feed/ 0 http://sayingitfirst.com/2013/05/07/whiteboards-visions-and-banned-words-how-to-help-a-real-life-knight-achieve-his-goals/?utm_source=rss&utm_medium=rss&utm_campaign=whiteboards-visions-and-banned-words-how-to-help-a-real-life-knight-achieve-his-goals http://sayingitfirst.com/2013/05/07/whiteboards-visions-and-banned-words-how-to-help-a-real-life-knight-achieve-his-goals/#comments Tue, 07 May 2013 16:44:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/07/whiteboards-visions-and-banned-words-how-to-help-a-real-life-knight-achieve-his-goals/ This article is about design consultancy. It’s about wrangling that client who uses empty sentences like, “We want a snappy, simple experience,” or, “It should be on brand and should really pop.” It’s about commanding the room and setting a vision before moving on to wireframes and [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  This article is about design consultancy. It’s about wrangling that client who uses empty sentences like, “We want a snappy, simple experience,” or, “It should be on brand and should really pop.” It’s about commanding the room and setting a vision before moving on to wireframes and pixels.

  While I’ll talk in terms of consultation, these ideas can be applied to the design phase of any new project.

  Banned Words

  I start every consultation with this list on the whiteboard:

  • Clean
  • Simple
  • Fast
  • Snappy
  • Some
  • Most
  • Nice

  These words are banned. If anyone in the room says any of these words, it means we’ve lost our focus or forgotten that we’re in the room to solve problems. We stop, reframe the conversation, then move on.

  
  Any whiteboard is a weapon if you hold it right.

  Here are three steps I take to ensure that the words above are never uttered in the first place.

  1. Set A Vision

  The design process can get derailed right at the start by focusing on questions like, “What’s the best thing about our product?” or, “What differentiates our service from the competition?”

  Why This Is a Bad Idea

  • Real users have families, jobs and tax bills and are quite possibly drunk when they first experience your brand. Put bluntly, people don’t care about your product — yet.
  • Real people experience your idea on their terms, not yours.
  • Dumb mass marketing doesn’t work anymore; we’ve raised a generation of marketing-proofed humans. (Thanks, Coke.)

  Instead, let your audience define the project by explaining their needs to a friend, remembering that your brand is not what you say it is. Your brand is what people tell their friends it is.

  “As a ____, I need to ____, so that I can ____.”

  Let’s assume we’re selling ACME Dragon-Slayer Swords. Our audience might say:

  “As a white knight, I need to slay the dragon, so that I can save the princess.”

  
  Your brand is not what you say it is, but what your audience says it is.

  This is useful because it describes our audience’s impetus and why it’s important to them. However, our user is not yet textured, nor specific enough. We can do better.

  2. Narrow It Down

  Let’s start with some experiential texture:

  “As an inexperienced knight, I need to slay my first dragon so that I can prove my worth to the father of the princess.”

  Better. We’ve textured our knight, with corresponding depth to his reasoning. Experiment with different textures — such as technical nouns, age, income and geography.

  It’s easy to get lost in our idea and forget how it applies to the larger stage, so let’s delve further in time, before and after our idea:

  “As an inexperienced knight on my first quest, I need to impress the king, so that I might marry his daughter and live happily ever after.”

  In doing this, we’re taking our user from his real-world impetus, through our brand and back into real life again. We’ve realized that the dragon-slaying itself wouldn’t actually help a real knight achieve their goals. Might we consider selling ACME Dragon-Slayer Swords by how impressive they are to kings?

  Describe the brand from multiple viewpoints. For example, our princess may find dragon-slaying presumptuous. If we discover that she’s a more interesting audience, then put her center stage instead.

  
  Dragon-slaying princesses are DIY champions.

  3. Stick To Your Vision

  Once a scope is defined, remaining within its constraints is important. Thinking back to our banned words, let’s look at the scope-destroyers:

  • Some
  • Most
  • Nice

  The sentence, “It would be nice if some users could X” is almost as dangerous as, “Most of the time our users will Y.” This kind of thinking frays the edges of a good idea until it’s unrecognizable.

  That way madness lies. Remove all but undebatable assumptions:

  • Narrow down “some users” until you can say “every user.”
  • If the client says “most times,” remove fuzzy options until they can say “all of the time.”
  • Don’t waste time on “it would be nice” issues if you can fix a “we absolutely must” problem.

  For example, earlier we defined our knight as inexperienced.

  If anyone starts talking about experienced knights, we’d ask them to rephrase in terms of our defined audience. If we get sidetracked by knights who don’t want to impress kings, we’d jot that down on a “nice to have” list and forget about it entirely.

  In The Real World

  Here are some practical examples from real-world projects that I’ve led:

  • Clarity.io
    “As a young adult, I want to donate to charity with my Facebook account so that I can share my charitable identity with friends.”
  • The Fitzroy Academy of Getting Shit Done
    “I’ve lost faith in university education. I want an intense, condensed way to skill up and be industry-ready so that I can get out into the workforce soon.”
  • OurSay
    “Australian citizens need direct access to people in power so that they can have an impact on their political system.”
  • The Promo Bay
    “The Pirate Bay needs a way to centralize and sift through artists so that it can decide who to promote on the home page of The Pirate Bay.”

  While we’re thinking “real world,” let’s look at the consultation session itself.

  Sleight of Hand

  When performing, stage magicians use props and well-practiced patter to better engage the audience. As a consultant, the magic lies in your command of design, while some nuanced expression can transform a banal experience into an engaging one.

  
  One tablet makes you bigger, one tablet makes you smaller.

  Practically Speaking

  • Keep the vision written at the top of the whiteboard at all times. If anyone gets sidetracked, point at it meaningfully until they quiet down.
  • If you feel you personally don’t have the authority to command the room, explain the consultative process up front. People sometimes prefer to trust a well-explained process, especially if they’re older or smarter than you.
  • If a client uses terms like “drop-down” or “radio button,” ask them to rephrase without using those words. It’s also a good excuse to assert that the consultation is not about pixels and wireframes.
  • Build a personal library of real-world metaphors that explain UX situations. For example, a website that logs you back in without asking is a lot like an automatic door. An HTML prototype is like a car without the engine. Physical examples ground people in reality.
  • Your whiteboard marker is a conductor’s baton. This lizard-brain reaction harkens back to teachers in grade school. Note on the board something that a person says that you agree with, and people will suddenly speak on your terms just so you write down what they say.
  • Once a vision is established, ask every person in the room whether they agree with it. Put a big tick next to it for each person, in turn. It’s now set in stone, and you can use it as the “bad guy” to settle disputes later.
  • Pacing is one of the most important parts of consultation. Set time limits, and don’t be afraid to say, “OK, back to the process.” Consider having a clock in the room.
  • Use a banned word, then catch yourself and apologize profusely. It proves you are beholden to the same rules as the client.

  
  Always remember to keep your audience’s impetus in mind.

  Further Reading And Experience

  I’ve straddled the shoulders of two giants in writing this.

  Reading

  • The “As a ____, I need to ____, so that I can ____” technique is a simplification of a behaviour-driven development tool. See Bryan Helmkamp’s practical example over on SlideShare.
  • I highly recommend watching the “Feedback Without Frustration” video and accompanying article, “How to Run a Design Critique,” by Scott Berkun.
  • It may be old school, but a solid understanding of “Cognitive Walkthroughs” in Task-Centered User Interface Design is a good reference point for sticking to a vision.
  • The “your brand is what your users tell their friends” idea comes from brand tribalism, another ’90s idea recently popularized by Seth Godin. See his TED talk on the subject.

  Experience

  You needn’t score a top-dollar client to learn how to deliver solid consultation services. We use these same techniques at work for all of our internal projects.

  Try starting your next design sans-Photoshop. Instead, run a two-hour consultation with a coworker. Try again later with a really annoying person who hates your designs. Mixed experiences will help you find your own method in the madness.

  Charm is a learned skill.

  In Conclusion, re. Applicability

  This style of consultation isn’t so great for fixing large broken systems. It’s better for new projects, with a small audience. It also works for small, distinct portions of a larger problem.

  Extending the vision should happen after launch and testing, once you’ve won everyone’s heart.

  Or:

  “As the design lead of a new project, I need some consultative tricks to keep my clients in line and to craft a concise vision.”

  (al) (ea)

  ---

  © Will Dayble for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/07/whiteboards-visions-and-banned-words-how-to-help-a-real-life-knight-achieve-his-goals/feed/ 0 http://sayingitfirst.com/2013/05/06/new-defaults-in-web-design-how-much-has-the-web-really-changed/?utm_source=rss&utm_medium=rss&utm_campaign=new-defaults-in-web-design-how-much-has-the-web-really-changed http://sayingitfirst.com/2013/05/06/new-defaults-in-web-design-how-much-has-the-web-really-changed/#comments Mon, 06 May 2013 19:22:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/06/new-defaults-in-web-design-how-much-has-the-web-really-changed/ Responsive design is about more than just layout; it’s about designing for the Web, which means, mostly, for people with browsers. And that’s just about everything we know about the people who visit our websites: they are probably using a browser. All the rest we just don’t [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Responsive design is about more than just layout; it’s about designing for the Web, which means, mostly, for people with browsers. And that’s just about everything we know about the people who visit our websites: they are probably using a browser. All the rest we just don’t know.

  Up until not so long ago, we used to base our designs on some rather general assumptions about screen size and input type. With the rise of devices with various screen sizes and alternative ways to interact, these assumptions have turned out to be unreliable. We need to upgrade the defaults that we use when we start designing our websites.

  A Closer Look

  People keep saying that the Web has changed. But has it really? Let’s take a look at all of the stuff that changed.

  Screen Sizes

  In the 1990s, the Web was 640 pixels wide. In the early 2000s, it grew to 800 pixels. A few years later, we decided it should be 1024 pixels. But five years ago, all of a sudden, something strange happened. A device with a very small screen entered the market. Suddenly, our ideas about the size of the Web did not work anymore. Later on, tablets entered the market. People hold these things however they want. Today, the height of the viewport could be bigger than the width! But is that new? Not really.

  
  Screen sizes, shown in a non-flexible medium. (Photo and work: Aram Bartholl)

  We never really knew what size the window of our visitors would be. We just assumed it was at least the random pixel width that we felt comfortable with. These numbers were always arbitrary, and there were always people who could not see the entire website. We simply ignored them.

  “Everyone Has a Mouse”

  We’ve always assumed that everyone uses a mouse. Even though we knew that this was not always true, most designs completely ignored alternative ways of interacting. People who had to use a keyboard, for whatever reason, had a very hard time interacting with our websites.

  But because most people did use a mouse, and because back then many designers thought that designing only for the majority was OK, we created websites that were unusable for a lot of people. And this turned out to be a growing number. Many mouseover interactions are completely dysfunctional on a touch device. Because people love these devices, and even managers and designers use them, they are harder to ignore.

  “Everyone Has Broadband Internet”

  Another thing we always assumed was that everyone had a super-fast Internet connection, at least as fast as our own. And if they didn’t already have it, they’d have it soon. This was again mostly true; speeds were increasing. But today, more and more people use crappy, unreliable 3G connections all the time. If you’ve ever travelled on a train in The Netherlands, you know what I mean. And if you’ve ever had to rely on the mythical “free hotel Wi-Fi,” then you know for sure that the assumption about the ever-increasing speed of our Internet connections is just not true. This is a big change in our thinking; we really should consider these users. This will have a major impact on what our designs look like.

  “Everyone’s Computer Gets Faster Every Year”

  It used to be true that computers would get faster and faster. If you waited half a year before buying a computer, you would get one that was twice as fast, for the same price. This was true of new desktop computers, but mobile devices have priorities other than processor speed. The most important thing for a phone, for instance, is battery life: you really don’t want to have to charge it after every phone call.

  And there’s another trend: instead of creating ever-faster devices, many manufacturers are starting to sell ever-cheaper devices. Many people care about price and battery life more than about processor speed. This is also not new: what happened to your old computers? You probably sold them or gave them away. People keep using old stuff. Not everyone has the same hardware as we designers do.

  “All Monitors Are Calibrated”

  Well, we always knew this to be untrue, right? Only the monitors of visual professionals are calibrated. Most other monitors don’t display colors accurately, and many monitors are downright crappy. Most mobile phones that I’ve tested have pretty decent screens, until you start using them outside, in the sunshine. If you’re lucky, you can read the content, but you definitely cannot see the subtle gradients in low-contrast designs.

  I haven’t even mentioned “modern” black and white screens. These, too, are not new. People have always used crappy monitors, and people with bad eyesight have always visited your websites. It’s just that more and more people are seeing a subpar color palette. Instead of buying a state of the art monitor, buying a cheap monitor and several low-end devices to test your work on might be a better investment.

  All of these things are not new. In 2002, John Allsopp wrote the monumental article “A Dao of Web Design.” People such as Jeremy Keith and Roger Johansson have written about all of these facts for years and years. And yet, somehow, we’ve always managed to actively ignore them. But we really can’t anymore. The Web actually did change in the last five years, with new devices, new browsers and many, many cool new features. We need new defaults. The old ways of creating websites just don’t work anymore.

  
  This Is Responsive, the excellent resource about responsive design by Brad Frost.

  In the past few years, we’ve been actively researching new ways to deal with all of these different screen sizes. But apart from responsive design, there are many more challenges in today’s ever-growing pile of devices. We have to find new patterns of interaction: we need interfaces that work on any device. Maybe we have to reconsider that enormous photo carousel on the home page, now that we know that not everyone has a cheap and fast connection. New defaults are emerging, and I’ve collected a few for you here.

  The things in this article are not new. Many clever people have written about them in many articles and many books. But these ideas, like all good stories, have to be repeated many times so that people understand and remember them.

  New Default: Activate

  I initially titled this section “New Default: Touch.” But I came to realize that “touch” has a different meaning for everyone. Some people, like me, think of a single tap when we hear the word. Others think about swiping and complex gestures. That’s why I settled on the heading “New Defaults: Activate.” All devices, no matter what kind of input they offer, let the user activate something in some way.

  With a mouse, it’s a click; with a touch device, it’s a tap; on a keyboard, it’s the “Enter” key. There are ways to activate things by voice, and by waving your arms in the air. And many devices offer more than one way to interact. The only thing that all of these devices have in common is the action of activating. Most of them are capable of doing many other things, too, but all of them can activate stuff.

  Only recently have we really started thinking about alternative methods of user input. We used to assume that everyone uses a mouse. Hiding content and showing it on mouseover was considered to be a decent design pattern. And it used to work for most people — until all of these wonderful touch devices entered the market. What should a device without a mouse do when content can be revealed only with a mouse? Different devices have different solutions. Let’s look at a simple drop-down menu.

  
  See a live example of this navigation pattern.

  When you hover over a menu item, a submenu appears. But apart from hovering over an item, you can also simply click on it to follow the link. Now, what should happen when you tap on the item with a touch device? Should the submenus appear, or should the link activate? Or both? Or should something else happen? On iOS, something else happens. The first time you tap a link like that, the submenu appears; in other words, the hover event fires. You have to tap a second time to actually follow the link. This is confusing, and not many people will tap a second time. On Android, the submenu appears and the link is followed simultaneously. I don’t have to explain to you that this is confusing.

  It’s very well possible to think of complex solutions whereby you define different interactions for different input devices. But the better solution, I think, is to make sure that the default interaction, the activate event, just works for everybody. If you really need to, you could choose to enhance this default experience for certain users.

  For instance, if you are certain that someone is using a mouse, you could enable some mouseover interactions. Or if you’re sure that someone has fat fingers, you could make small buttons a bit bigger. But only do so in addition to the default activate interaction, and only if there’s no doubt about it, and only if the enhancement would really make things better. Those are quite a few ifs, and some of them, such as the mouse usage, are very hard to detect — especially on devices that offer more than one way to interact, such as a laptop with an optional mouse, touch pad, camera, microphone, keyboard and touchscreen. Give it some serious thought. Do you really need to optimize for a mouse?

  New Default: Small Screens

  Growing is easy. Most things grow. Babies grow, trees grow, curious minds grow. They don’t grow by themselves, but you don’t need much energy to make things bigger. This is just what things do when they live. While shrinking things is definitely possible, it’s also much harder. You could, for instance, compress a car to a fraction of its original size. A compressed car does have a certain aesthetic appeal to it, but it is definitely not as useful as it was before. The same goes for websites. Shrinking a desktop website does not always result in a pleasant experience on a small screen.

  
  Cedro di Versailles by Italian artist Giuseppe Penone clearly shows that things grow. On the other hand, the work Papalote Goliad by American artist John Chamberlain shows that shrinking can be aesthetically appealing but may result in less useful results.

  To build a responsive website that works on all kinds of screens, designing for a small screen first is easiest. It forces you to focus on what’s really important: if it doesn’t fit in this small square, it is probably not terribly important. It forces you to think better about hierarchy, about the right order of components on the page.

  The same principle that we follow for interactions — whereby we design the activate event first and enhance it later — applies to graphic design. We should start designing the things that we know everyone will see. That’s the content. No matter how big or small a screen is and no matter how minimal the feature set of a browser, it will be able to show letters. Because this is about the only thing we know for certain — since color is absent on most Kindles, most of the latest CSS doesn’t work on old browsers, and layout is of minor importance on small screens — starting with the text is logical.

  I wrote an in-depth article about defining breakpoints on the basis of typography, so I won’t repeat every detail here. But the basic idea is that you start by designing the relationship between the different font sizes. Almost everyone, no matter what device they have, will be able to see this. When the typography is done, you would start designing the layout for bigger screens; you can think of this as an enhancement for people with bigger screens. And after that, when the different layouts are done, you could add the paint. And by paint, I mean color, gradients, borders, etc.

  I’ve presented this as a very strict way of working; in real life, of course, things are not as rigid. I’m not talking about “activate only” or “small screen only.” When I say to start with typography, I don’t mean that you aren’t allowed to think about paint at the same time. Rather, I’m trying to find the things that all of these different devices, with all of their different screen sizes and all of their different features, have in common. It just seems logical to first design this shared core thoroughly. The strange thing is that this core is often overlooked: Web professionals tend to view their own creations with top-of-the-line devices with up-to-date browsers. They see only the enhancements. The shared core with the basic experience is often invisible.

  New Default: Content

  The way we designed our websites until recently was by putting a header with the logo and navigation at the top, putting the subnavigation on the left, putting some widgets on the right, and putting the footer at the bottom. When all of that was done, we’d cram the content into the little space that was left in the middle. All of the things we created first — the navigation, the widgets, the footer — they all helped the visitor to leave the page. But the visitor probably wanted to be there! That was weird. It was as if we were not so confident in our own content and tried our best to come up with something else that our guests might like.

  But rather than pollute the page with all kinds of links to get people out of there, we should really focus on that thing in the middle. Make sure it works. Make sure it looks good. Make sure it’s readable. Make sure people will understand it and find it useful. Perhaps even delight them with it!

  Once you’re done with the content, you can start to ask yourself whether this content needs a header. Or a logo. Or subnavigation. Does it need navigation at all? And does it really need all of those widgets? The answer to that last question is “No.” I’ve never understood what those widgets are for. I have never seen a useful widget. I have never seen a widget that’s better than white space.

  
  Compare a typical news website’s attention to widgets with Medium’s complete focus on content.

  By starting with the content first, you can come up with some very interesting solutions. For instance, does the logo really need to be at the top of every page? It could very well go in the footer on many websites; such as in digital style guides or on pages for registered users. Many links that we used to put in the subnavigation might work better in relevant spots in the main content.

  For instance, the option to add extra luggage to a flight booking might be most effective right there in the overview of the flight, instead of in the middle of a list of links somewhere on the left of the page. And when looking at the hierarchy of a page, does the main navigation look more important than the main content? Most of the time it shouldn’t be, and I usually consider the navigation to be footer content. A simple “skip” link at the top of the page could either take the visitor to the navigation or fetch the navigation and show it at the top of the page.

  In this era of responsive Web design, we need many new clever solutions. As we’ve seen here, our old defaults don’t work anymore. We need to reconsider how we work with interaction, how we approach design and how we shape our content. But we need to think about one other very important thing, and that is where our content comes from.

  New Default: The API

  Luke Wroblewski wrote a fantastic article about designing an application for the command line first, and then enhancing it for different needs. This is not just a nerdy idea, but a very practical idea, too. If you are able to design and develop your own application, you could test the functionality relatively easily before even starting to think about what it will look like on different devices. This requires designers to work with developers to design a feature that at first works only from the command line. If the feature does not work as expected, then you merely have to change the API, rather than also a bunch of visual designs. Once the API works as you want it to, enhancing it for all of the devices and screen sizes that you want to support becomes easier.

  Most of the time, you wouldn’t design the entire API of the application that you’re building. Most companies would choose a content management system (CMS) of sorts or a specialized tool to help them achieve what they want to do. I’ve always been amazed that CMSes are so often chosen only by technical people and business people. This causes many problems during the design process.

  Developers and business people have different goals than designers. Developers want stuff that is easy to develop on. Business people want stuff that’s cheap. But designers want to make the best and most beautiful things possible. These goals can easily conflict.

  I’m not saying that designers alone should choose the system, but they should definitely be a part of the decision-making process. I’m convinced that the selection of CMSes will improve. And I’m convinced that CMS makers will start to improve their products once designers get involved. Right now, all CMSes I know of deliver hostile cruft unless you tweak them extensively.

  But it works the other way around, too. If designers are involved in the selection process, they will have a say in the choice of tool and will understand how it works, what’s possible, what’s easy and what’s hard. This will result in designs that are based in part on the tool, not just on imagination. This is an important part of the design process that has not yet been optimized. Right now, the command line and the systems that deliver the content we design for are the domain of the developers, and designers have nothing to do with them. That is a pity. Just as you would want to take advantage of the knowledge of developers in the design process, you would want to take advantage of the knowledge of designers in the development process.

  Progressive Enhancement

  If you review the sections above, you’ll see that what I’ve described is nothing other than progressive enhancement. You start with the content, then design the content and optimize it for different screen sizes and devices, and after that you can further optimize for very specific features such as mouse usage and fat fingers. Many Web developers build websites according to this principle. They transform the beautiful Photoshop documents that they receive into all of the different layers described above.

  This can work out fine if the developer has a good sense of design and a delicate attention to detail. But if they don’t — which is often the case — this can easily result in crappy usability and ugly details. I’m not saying that designers shouldn’t use Photoshop anymore. If that’s your tool, go ahead and use it. But do remember that you’re designing the layers of the Web, not the layers in Photoshop. There’s much more to the Web than a single beautiful image. People will see our creations in innumerable ways. We design for all of these people — remember that. We don’t just design for the CEO with a laptop. We also design for the people on the train and the people with “free hotel Wi-Fi.”

  Tools

  I’ve mentioned Photoshop a few times because it’s still widely misused for designing websites. One reason we have a hard time with progressive enhancement in the design process is due to a lack of good Web design tools. The tools we use are built to wow; they mostly help you to create the “paint,” not to design the core. Fortunately, more tools are popping up with very specific functions in the design process. These are micro-tools such as the International Measure Slider, which helps you to define breakpoints in your grid; tools such as Gridset, which helps you to create grids for different screen sizes; and excellent tools that help you to define typography. By incorporating these tools into our design workflow, we might start making better stuff.

  Conclusion

  The Web has always been a weird, borderless, flexible medium. In the last couple of years, we’ve started to realize that designing for this medium is fundamentally different from the design work we’ve done previously. The fixed dimensions and the singular ways of interacting that formed the basis of all types of media that we’ve worked with for centuries just don’t work on the Web. This truly is a unique medium.

  We have to find new defaults, new starting points for our design process. I’ve explained some of these new defaults here, but of course there are many more. The way we work with forms, for instance, could probably use a whole series of articles by itself. Some new starting points are well established by now, but I’m sure many more will be invented in the near future. I am curious to hear about new patterns and new defaults that you have discovered and have used successfully in your projects.

  (al)

  ---

  © Vasilis van Gemert for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/06/new-defaults-in-web-design-how-much-has-the-web-really-changed/feed/ 0 http://sayingitfirst.com/2013/05/04/interview-how-i-work-ideos-duane-bray-on-creating-great-digital-experiences/?utm_source=rss&utm_medium=rss&utm_campaign=interview-how-i-work-ideos-duane-bray-on-creating-great-digital-experiences http://sayingitfirst.com/2013/05/04/interview-how-i-work-ideos-duane-bray-on-creating-great-digital-experiences/#comments Sat, 04 May 2013 17:32:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/04/interview-how-i-work-ideos-duane-bray-on-creating-great-digital-experiences/ Welcome to another interview in the series called “How I Work.” These interviews revolve around how leading thinkers and creators in the Web world design, code and create. The goal is not to get into the specific nuances of their craft (as that information already exists online), [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Welcome to another interview in the series called “How I Work.” These interviews revolve around how leading thinkers and creators in the Web world design, code and create. The goal is not to get into the specific nuances of their craft (as that information already exists online), but rather step back and learn a bit about their habits, philosophies and workflow for producing great work.

  You might want to have a look at the first interview as well, which features Doug Crockford, Yahoo’s JavaScript evangelist.

  Today we’ll talk to Duane Bray from IDEO, a firm that is consistently listed as one of the world’s most innovative companies due to its uncanny ability to constantly come up with great ideas for its clients. Duane Bray is a partner at IDEO and heads up the firm’s digital business from its New York City office.

  
  Duane Bray at IDEO’s New York City office

  Like all IDEOers you meet, Duane Bray is unfailingly nice, with a soft, well-spoken voice. He reminds you of the kid in the back of algebra class doodling away during lecture and still acing the tests.

  We recently sat down with Duane over a couple sessions to get his thoughts on Agile development, how you too can gather great user insights, tips for prototyping digital projects with clients and why he still sketches interfaces out on paper.

  Q: What has you excited about digital work these days?

  Duane: I’m particularly excited about the movement away from standards-based specifications towards real stuff. For us, we’ve been doing a lot more experimentation around Agile development processes and pairing up designers and developers side by side throughout the process from day one. The last thing you want to do is hire a designer who is really talented at conceptual thinking and say, “Okay, now you’re going to spend six weeks documenting everything with InDesign for the thing you did.”

  What’s funny though, is when you have a designer working with a developer on weekly builds, all that stuff still gets done. But from the designer’s perspective, they are constantly making. We’ve found our teams to be super excited to be working in this way.

  Certainly we’re not the first to discover Agile, but it’s made a big difference in our culture because we want people to get their ideas as real and tangible as soon as possible.

  Q: How does IDEO go about getting big, breakthrough insights?

  Duane: Well, for a lot of our clients, they come to us with these sort of vague questions, and they want us to help them figure that out. So, we want to start off by making sure we’re a bit exploratory — and that involves going out and being inspired by behaviors.

  For example, there might be a question around new forms of video consumption online. We want to go out and find people that are representative of some extreme form of behavior. This helps us get inspired and further shapes our strategy.

  One woman we found has two computers at work. One is displaying her work and the other one is displaying reality television. She needs both streams to do her job. The interesting thing is you can almost hit pause and ask her what’s going with the show and with her work and she can answer both.

  So it starts to suggest, what are some of the interesting forms of literacy that are coming through our digital tools? And how might we design for this? Are there new mental models we haven’t thought about before, rather than going with industry standards?

  
  A brainstorming session at IDEO

  Q: IDEO is famous for “thinking with your hands” via prototypes — how do you transfer this over to digital?

  Duane: For me I don’t see any distinction in how IDEO designs digital products compared to our other products. We’re still going to get out there and be inspired by what’s going on in the world.

  We always start our projects with some sort of investigation into what are people doing and how it impacts how they’re going to engage. And we get tangible quickly — and it’s not so very different from any other prototyping process. We do group sessions to generate ideas, we sketch together, we might have someone make a mock-up on a phone or tablet to test out a behavior. What’s most important for a prototype is to choose the right fidelity for the question you’re seeking to answer.

  Q: What’s this discovery process look like?

  Duane: Sometimes we’ll prototype something in the browser or on mobile to test some of these concepts out. We’ll also play around with paper prototypes because it’s an appropriate way to get client input.

  But I like to find ways to disrupt the conversation when we’re talking with consumers.

  For example, if something is very polished, consumers will feel they have to say they like it because it’s polished. So sometimes having hand-sketches, along with something on an iPad, we’re able to get very nice conversations going.

  Prototyping is about blending that low-fidelity and high-fidelity process and blending our thinking as we go along.

  Q: How would you make a case to a Smashing Magazine reader for adopting a prototyping process with their clients?

  Duane: Well, the client is going to be in a better position to make more informed decisions because they are seeing things that are real. I would also argue that it isn’t a massive investment anyway and there is a better payoff down the road because you’re getting more real (tangible) early on — which means you’re going to get better input from users.

  Imagine not going through that process: doing a bunch of sketches, building out a spec document, a developer builds it, you test it and people hate it.

  At that point there has been such a huge investment in producing that thing. So there is actually a lot of emotional attachment now and it’s either going to be financially impossible to correct it or people will be too wedded to the idea and it’s going to be impossible to change.

  Q: How do you show these prototypes?

  Duane: We do a lot of live work. We’ll recruit a panel of end users. Particularly in the early stages when we’re looking for inspiration, we’ll want to be in their (the users’) context. So instead of bringing them into a focus group, we might go into their homes or offices and observe them. We’ll also put stuff up on the web and blast out an SMS message and ask people to interact so we can get a more broad approach as well.

  Sometimes we’ll do a hybrid of both and have our developers do quick builds and mock-ups and then go back out into the field to get more insights with a select group.

  We want to know less about what percentage of people clicked on this or dropped off and more about their process of going through and using that experience. What are the specific things that are barriers and why?

  At some point, when we have a much more robust build, then we’ll push it out to more people. So there is definitely an interim phase. We tend to start high touch and stay that way for a while. We’re looking for finding the emotions around why people engage or why they don’t. If we understand those, it becomes a lot more powerful in how we tune the tools.

  Q: What’s your experience been with Agile Development processes?

  Duane: One of the things we’ve found when we’re working in an Agile process is that we can actually be incredibly fast.

  
  An iPhone app that IDEO created for Lincoln Center.

  To give you an example, we did a project here in New York for Lincoln Center, which was their first iPhone app, and we ran it as an Agile process. We went from kick-off to an app in the iTunes store in eight weeks. That’s concept, design and build (and I wouldn’t want to claim we can do every project on that timeline). But we had an amazing client that was able to make decisions very quickly, so we had a fast turnaround time there.

  But again, it was because we were getting very real, very fast.

  Q: Can you give us a step-by-step breakdown for creating this app in only eight weeks using Agile?

  Duane: Sure. First, we spent half a day with our designers and developers at Lincoln Center’s campus, and in advance we created briefs about what an app could look like around different themes. We broke up into teams and every group had to go and interview people at Lincoln Center and talk to them about the theme and do a tour themselves.

  We had clipboards of iPhone screen printouts, and they (the teams) had to sketch an experience and get feedback — all in four hours. It was a great way to get immersed: we talked to security guards, out-of-town tourists, locals who would hang out there, people at the information desk and we got a ton of insights.

  So, we had all these amazing stories to go back and work with for honing our hypothesis on what this experience should be and we started building it. We did a detailed sketch session, prioritized the feature set, mapped out the flow, did some wireframes and then did a planning session with our development team (from Pivotal Labs). The project was so fast; there were literally just screenshots on the iPhone to simulate the flow. We were sharing it with people quickly and got to the stage where there was a build a week.

  
  Screenshots of the iPhone app that IDEO created for Lincoln Center.

  But the reality about that process is that you couldn’t do waterfall in eight weeks. I would say it’s more efficient than an old-fashioned step process.

  Agile has been around for 20+ years, and we’re certainly not the first to discover it but now it’s finally getting traction. Designers and developers want to spend time making stuff and getting it out there and this process is all about that.

  Q: What habits or hang-ups do you see in great web designers and developers?

  Duane: Well, one of the things I think that is probably the most challenging for working in this more iterative, rapid-fire way is the ability to be more open and transparent with the work that you’re doing. Sometimes as designers we want to spend some time crafting, hiding in a corner and sketching and then do the “ta-da!” But some of this new way of working requires us to move beyond that.

  One of the things I’ve been thinking about is how do you encourage greater transparency of work that’s in progress? We’ve been prototyping with tools like Flowdock that allows for conversation to sit around the workflow. That is particularly important, if we’re talking about getting stuff out there really early. These are the certain things that aren’t to the nature to how a designer is trained.

  There is also this thing about great developers having curiosity. Being curious about the end user you’re designing for and involving the developers in that process for insights. Being able to imagine if they’ll use the thing you’re making.

  Some folks are really natural at that, and in other cases it takes a lot of work. But I think that’s where we’re going — working off of blended teams with people of different skill sets.

  Q: Any tips on how a small shop can get similar disruptive insights like IDEO does?

  Duane: As designers it’s easy to get blinders on because we know what we know and it’s easy to get caught up in it. So, take some time to start over like you’ve never done this before. Sign up for some new tools and track your progress and behavior as an end user. There is something about just getting out to find inspiration. Look for stuff going on, whether it’s a related conference or just inviting in some experts to talk over wine and cheese at your office.

  Even a small shop can reach out to friends of friends and watch them interact with some early prototypes or simply have a conversation. Say you’ll buy them drinks every other week and just show them stuff and see what you can learn from building that into your process.

  One thing I do is have a screen on my phone that is just apps I would never normally download. So, we might be doing a project around, say, video, and I’ll go try every app out there and use this as a great way to learn. Projects are often an opportunity to dive deeper into a subject area you’re not necessarily interested in but you could be super-inspired by it.

  Q: Now how do you capture those inspirations?

  Duane: I usually have my notebook open as I’m using all these apps and I’m sketching out ideas and patterns. You start to get a feel for trends and think about different ways to accomplish the same task.

  
  Sketchnotes in Duane Bray’s notebook.

  Q: Where and how do you do your best work and not get burned out?

  Duane: I usually get away from my desk. I’ll go sit up front on the couch with my laptop and my sketchbook. I force myself to move around. If you just sit at your desk you’re inclined to get into bad habits because everything is sitting around you. Some people have the zero inbox but I have 35,000 messages, so I just use the search box in email.

  I’m someone who runs on intuition and not organizational processes. I have a thousand sticky notes on my desk.

  But I’m pretty rigid about taking weekends off. I wasn’t always this way but I’ve learned that by being open to being inspired by stuff that has nothing to do with what I’m working on is really important.

  Otherwise, you’re not grounded enough to bring something original to the table.

  (cp) (ea)

  ---

  © Jacob Cook for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/04/interview-how-i-work-ideos-duane-bray-on-creating-great-digital-experiences/feed/ 0 http://sayingitfirst.com/2013/05/03/design-patterns-infinite-scrolling-lets-get-to-the-bottom-of-this/?utm_source=rss&utm_medium=rss&utm_campaign=design-patterns-infinite-scrolling-lets-get-to-the-bottom-of-this http://sayingitfirst.com/2013/05/03/design-patterns-infinite-scrolling-lets-get-to-the-bottom-of-this/#comments Fri, 03 May 2013 16:03:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/03/design-patterns-infinite-scrolling-lets-get-to-the-bottom-of-this/ Infinite scrolling promises a better experience for users. However, the good is often accompanied by the bad and the ugly. Once we understand the strengths and weaknesses of infinite scrolling, we can begin to use it to enhance our interfaces. Human nature demands hierarchy and structures that [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  Infinite scrolling promises a better experience for users. However, the good is often accompanied by the bad and the ugly. Once we understand the strengths and weaknesses of infinite scrolling, we can begin to use it to enhance our interfaces.

  Human nature demands hierarchy and structures that are easy to navigate. But infinite scrolling sometimes leaves users feeling disoriented as they travel down a page that never ends.

  

  The Good

  Long lists are not new, but the way in which we scroll these lists has fundamentally changed since the arrival of mobile interfaces. Due to the narrowness of mobile screens, list items are arranged vertically, requiring frequent scrolling.

  Infinite scrolling is highly trending as an interaction behavior on pages and lists. The basic functionality is that, as the user scrolls through content, more content is loaded automatically. With the popularity of social media, massive amounts of data are being consumed; infinite scrolling offers an efficient way to browse that ocean of information, without having to wait for pages to preload. Rather, the user enjoys a truly responsive experience, whatever device they’re using.

  
  Pagination versus infinite scrolling (Large version)

  Websites with lots of user-generated content today are using infinite scrolling to handle content that is being generated every second. By unspoken agreement, users are aware that they won’t get to see everything on these websites, because the content is updated too frequently. With infinite scrolling, social websites are doing their best to expose as much information as possible to the user.

  Twitter integrates infinite scrolling effectively. Its feed fits the criteria: a large amount of data (tweets) and a real-time platform. From the perspective of the user, all tweets are equally relevant, meaning that they have the same potential to be interesting or uninteresting; so, users will often scroll through all of the tweets in their feed. Being a real-time platform, Twitter is constantly being updated, even if the user leaves their feed unattended. Infinite scrolling seems to have been created especially for websites like Twitter, which successfully employs the technology.

  Infinite scrolling appears to have found its niche on the Web. However, there are also drawbacks that must be considered before assessing its value.

  The Bad And The Ugly

  With so much data to browse, users must stay focused on the information they are searching for. (Remember about being goal-oriented?) Do users always want a never-ending stream of data? Analytics show that when users search for information on Google, only 6% advance to the second page. So, 94% of users are satisfied with receiving only 10 results, which suggests that users find Google’s ranking of results to be relevant.

  To Click or Not to Click

  Google has implemented infinite scrolling for image search results but has yet to implement it for its general results. Doing so would eliminate the need for users to click to reach the second page. Google will probably maintain pagination because this pattern is quite symbolic for its brand. If it does switch to infinite scrolling, when would users typically stop scrolling? After 20 results? 50? When does an easy browsing experience become more complicated?

  Looking for the best search result could take a second or an hour, depending on your research. But when you decide to stop searching in Google’s current format, you know the exact number of search results. You can make an informed decision about where to stop or how many results to peruse because you know where the end is. According to studies conducted in the field of human-computer interaction, reaching an end point provides a sense of control; you know that you have received all relevant results, and you know whether the one you are looking for is there or not. Knowing the number of results available provides a sense of control and helps the user make a more informed decision, rather than be left to scour an infinitely scrolling list.

  
  Pagination is a barrier of clicks. (Large version)

  When items are distributed across Web pages, they are framed and indexed and have a start and end point. The information is presented clearly and orderly. If we select an item from a paginated list and are taken from that page, we know that clicking “Back” will return us to that page (probably to the same scroll position). Our Web search will continue right where it left off.

  If you scroll the same list of results with infinite scrolling, you are left without that sense of control because you are scrolling through a list that is conceptually infinite. Let’s say you count yourself among the 94% who stop reading after the first page (i.e. 10 results) of a Google search. When the list scrolls infinitely, there is essentially no end to the first page. Rather than look for the end of the page, which doesn’t exist anyway, you decide to stop scrolling at the 10th item. This poses a problem with infinite scrolling, because the 11th item is directly in sight. With a paginated list, on which you wouldn’t see the 11th result, deciding not to continue browsing is easier. However, when the next results are already there, you’d probably just keep on scrolling and scrolling.

  As Dmitry Fadeyev points out:

  “People will want to go back to the list of search results to check out the items they’ve just seen, comparing them to what else they’ve discovered somewhere else down the list. Having a paginated interface lets the user keep a mental location of the item. They may not necessarily know the exact page number, but they will remember roughly what it was, and the paginated links will let them get there easier.

  Not only does the infinite scroll break this dynamic, it also makes it difficult to move up and down the list, especially when you return to the page at another time and find yourself back at the top, being forced to scroll down the list once again and wait for the results to load. In this way the infinite scroll interface is actually slower than the paginated one.”

  — Dmitry Fadeyev, When Infinite Scroll Doesn’t Work

  When Infinite Scrolling Fails

  The best companies are constantly testing and studying new interactions with their users. Increasing numbers of these studies are showing that infinite scrolling does not resonate with users if it does not support their goal on the website.

  Temptation

  When you’re looking for that perfect search result and are tempted to continue scrolling into a wasteland of irrelevant results, time is wasted. Chances are that the best result will appear in the first 10 items. Therefore, infinite scrolling merely tempts you to continue reading, wasting time and decreasing productivity in the process.

  Optimism

  Even more annoying is that scroll bars do not reflect the actual amount of data available. You’ll scroll down happily assuming you are close to the bottom, which by itself tempts you to scroll that little bit more, only to find that the results have just doubled by the time you get there.

  Exhaustion

  Infinite scrolling overwhelms users with stimuli. Like playing a game that you can never win, no matter how far you scroll, you feel like you’ll never get to the end. The combination of temptation and optimism play a big role in exhausting the user.

  Pogosticking

  Infinite scrolling often causes your position on the page to get lost. “Pogosticking” happens when you click away from an infinitely scrolling list and, when you return by clicking “Back,” are brought to the top of the previous page, instead of to the point where you left off. This happens because the scroll position is lost when you navigate away from an infinitely scrolling page, forcing you to scroll back down each time.

  Loss of Control

  Infinite scrolling leaves you with the feeling that you might be missing out on information. You continue scrolling because the results are right there, but you feel overwhelmed because you’re losing control over the amount of data being shown. There is something nice about defined pages on which the amount of content is quantified, where you can comfortably choose whether to click to view more or to stop. With infinite scrolling, you don’t have control over the amount of data on the page, which becomes overwhelming.

  Distracting

  Etsy, the vintage e-commerce marketplace, implemented infinite scrolling, only to find that it led to fewer clicks from its users. Infinite scrolling was unsuccessful because users felt lost in the data and had difficulty sorting between relevant and irrelevant information. While infinite scrolling provided faster and more results, users were less willing to click on them, defeating its very purpose.

  
  Etsy’s home page (Large version)

  Unreachable

  Have you tried reaching the footer of Facebook lately? The footer block exists below the news feed, but because the feed scrolls infinitely, more data gets loaded as soon as you reach the bottom, pushing the footer out of view every time. Footers exist for a reason: they contain content that the user sometimes needs. In Facebook’s case, the user can’t reach it. The links are repeated elsewhere but are harder to find. Infinite scrolling impedes the user by making important information inaccessible.

  
  Facebook’s auto-loading news feed makes the footer unreachable. (Large version)

  Footers serve as a last resort. If users can’t find something or they have questions or want more information or explanation, they often go there. If they don’t find it there, they might leave the website altogether. Companies that implement infinite scrolling should either make the footer accessible by making it sticky or relocate the links to a sidebar.

  Not Exclusive

  Pinterest does not have a footer at all, which makes sense given the problem we just saw with Facebook. Through infinite scrolling, Pinterest emphasizes its profusion of data, an endless sea of inspiration taken from all over the Web.

  
  Pinterest’s ocean of pins (Large version)

  Images are faster and easier to scroll than text, so Pinterest and Google Images succeed with infinite scrolling to an extent. However, billions of images are on the Web, and users would prefer to see only the best of them. There is something to be said for exclusivity, which seems to be lacking in Pinterest’s layout.

  Limiting the number of images on Pinterest’s home page, with an “Editor’s picks” or “Most popular” list, might make the website more appealing. How exclusive can a pin be when a ton of other similar pins are next to it?

  Pinterest’s tactic of using infinite scrolling for its plethora of data suffers because it overwhelms users. The collection looks bottomless, but its immensity is somewhat daunting, and browsing it might seem a waste of time. Ultimately, Pinterest is trying to expose users to infinite inspiration, but that actually undermines the human need for control. The amount of data becomes intimidating, and users are left with mixed feelings.

  When Usability Wins

  As mentioned earlier, Twitter integrates infinite scrolling effectively. The user sees an infinitely growing list of tweets and can comfortably click on a tweet to expand it in place, preventing the page from refreshing and, as a result, maintaining their scroll position.

  
  Twitter’s torn feed (Large version)

  On its mobile version, Twitter even adds a “torn paper” marker, indicating to the user where to resume reading. This subtle and simple solution enables the user to scroll up and down the list, while having a recognizable point to return to. Psychologically, that marker reassures the reader by dividing read and unread content. Such markers give the user a sense of control and a better perception of the content’s depth and how far they’ve gotten into it.

  Twitter is not the only one. Discourse, an emerging discussion platform, also has infinite scrolling that empowers the user. The company considered the importance of infinite scrolling to its user experience and implemented an intriguing and unique progress indicator. The indicator appears when needed and remains in view (without interfering) while the user reads the content. The indicator numbers the item currently being viewed out of the total number of items. This is a great way to make the user feel in control, even with a lot of data.

  
  The smart progress indicator on Discourse (Large version)

  Go Hybrid

  A hybrid of infinite scrolling and pagination is also a good option in many cases. With this solution, you would show a “load more” button at the end of a preloaded list, which, when clicked, loads another batch of items onto the list. The same behavior that infinite scroll does automatically, this button does on demand. The interface gains some of the advantages of infinite scrolling, without some of its drawbacks.

  Because infinite scrolling requires the website to fetch so much content, the hybrid solution is used at times to control the data load. In Facebook’s news feed and Google’s image search, the infinite scrolling is automatic at first but becomes on-demand once a certain number of items have loaded. This maintains the interface while limiting the load on the server.

  
  Hybrid infinite pagination on Google Images (Large version)

  Infinite Pages

  Infinite pages take the concept of infinite scrolling to a new level. Websites that employ this concept are “one-pagers.” To remove the barrier of clicking to the next page, the designer turns the entire website into one long scrollable page. Examples are Unfold and Lost World’s Fairs.

  On these one-page websites, the sections are spread vertically, one after another. This makes the whole website less comprehensible — hence, less accessible. These websites might not have infinite scrolling, but the user might still have that feeling of a never-ending page.

  On infinite pages, the height of each section will vary according to its contents. Although the approach can make for some creative interactions, it can leave users disoriented and unsure where to scroll for the next piece of information. The scroll bar is hidden on many such pages, leaving users feeling lost as they unconsciously look for the scroll position to track their progress. Hidden scroll bars deprive users of that chance for rescue. Users shouldn’t be left helpless; the interface should clearly show them how to navigate the page.

  
  Not knowing where they stand can leave the users disoriented.

  UX engineers need to take extra care when designing infinite pages. They must take into account accessibility; tell users where they stand by showing the length of the page and how much they’ve viewed. Solutions could include a fixed menu, a map of the page or a scroll progress bar.

  Another trick is the parallax effect, whereby different layers on the page move at different speeds according to the user’s scrolling, creating the illusion of depth (as seen on Andrew McCarthy’s website). While it can help to create beautiful and innovative experiences, it is sometimes heavily overused, and users can get confused by how much they need to scroll for more content. When the parallax effect is combined with animation, the user can get confused about whether the page is being scrolled by their movement or is moving autonomously. It’s wise to use the technique to enhance content, not as the content itself.

  Let’s Get To The Bottom Of This

  Infinite scrolling can be an innovative feature that greatly improves an interface by exposing content and making performance more efficient. But it needs to be used correctly.

  Avoid the following sinkholes to achieve a strong infinite scrolling experience:

  • Users want immediate access to exclusive data.
    Users don’t want to be left to explore all of a website’s data on their own. When implementing infinite scrolling, identify what data is exclusive to your website and elevate it to the top of the page, and filter less relevant information.
  • Users want to feel in control.
    Infinite scrolling sabotages that feeling of control. Add a smart progress indicator, a fixed menu or a map.
  • Users often look for landmarks when scrolling.
    When scrolling through long lists, users expect to be able to easily distinguish between new and viewed data. Add landmarks along the interface to keep users oriented.
  • Consider conventional pagination or a hybrid solution.
    Good old pagination is always an alternative to infinite scrolling. And if that doesn’t fit the context, then a hybrid solution, using a “load more” button, could greatly enhance the interface.
  • Provide interesting content without an ambiguous interface.
    Having to traverse a never-ending list is logical only if the user leaves feeling that it was worthwhile.
  • Users often expect a footer.
    If footer-type information is functional to the interface, then it should appear at the bottom of the page. A fixed footer is usually the way to go with infinite scrolling.
  • An infinite list is still a list.
    Infinite scrolling still needs to meet common interface standards. Whether users take their eyes off the screen for a moment or click a link and then click “Back,” they expect to return to the exact point where they left off. Whatever your interface, make sure it meets users’ expectations.
  • Effects are nice to have but not a must.
    Many infinitely scrolling interfaces have various effects to show more data (whether by sliding in new content or another method). Be mindful not to focus more on effects than on presenting data in the most effective way possible.

  Use It Correctly

  Users are goal-oriented and find satisfaction in reaching the end of their exploration. To be effective, infinite scrolling has to account for this. Nothing is really infinite, not even these infinitely scrolling lists we’ve looked at. Users should always know where they stand, even when the content has not finished loading. They should know what the total amount of data is and be able to easily navigate the list. Infinite scrolling has to be implemented in the best possible way so that users can always find their way.

  (al)

  ---

  © Yogev Ahuvia for Smashing Magazine, 2013.

  Source: Smashing Magazine

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/03/design-patterns-infinite-scrolling-lets-get-to-the-bottom-of-this/feed/ 0 http://sayingitfirst.com/2013/05/02/5-tips-for-effective-social-media-time-management/?utm_source=rss&utm_medium=rss&utm_campaign=5-tips-for-effective-social-media-time-management http://sayingitfirst.com/2013/05/02/5-tips-for-effective-social-media-time-management/#comments Fri, 03 May 2013 04:01:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/02/5-tips-for-effective-social-media-time-management/ Most of us have experienced the social media time warp at least once. You remember that time; you sat down to spend 30 minutes checking in on your company’s social media accounts when you happened to catch the latest Kid President video. Next thing you knew, you [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> Most of us have experienced the social media time warp at least once. You remember that time; you sat down to spend 30 minutes checking in on your company’s social media accounts when you happened to catch the latest Kid President video. Next thing you knew, you looked up to find that you’d been watching that cute kid’s videos for over an hour. It hit an all-time low when you saw his Harlem Shake video and decided to watch 10 others to see if it was an actual dance, or just people wildly thrashing their bodies and pretending to be zombies. After a big palm slap to the forehead, you gather your things to head off to your next meeting, realizing you didn’t accomplish anything worthwhile. While you’ll never get that hour of your life back, it is possible to make sure you use the next hour more productively.

  Here are 5 tips to help you maximize your time in social media and avoid the time warp.

  1Create a Checklist

  The first step is to create a list of all the things you need to accomplish in a day, a week, and a month. Be sure to include bigger tasks like writing blog posts, e-books or producing a video. But also include the most medial tasks like writing and publishing status updates. When you create the list make sure to include the frequency of how often each task needs to be done and how many times the task will be performed. For example, create and publish 6 tweets per day. After a little work, this will become your master check list. You will look at this list every day, week and at the end of the month to make sure all tasks have been accomplished. But first we need to evaluate and optimize your check list.

  2Batch & Prioritize Tasks

  Now that you know what you need to get done, take a look and see if any similar items can be batched together and knocked-out all at once.  For example, if you know that 2 of the tweets each day will be promoting your company’s content, can you write several days’ worth all at once so they are ready to go? Are there a group of status updates that make sense to schedule ahead of time? If you publish 4 blog posts a month, can you write them all at once and have them done 30 days before? Many times, one of the biggest challenges with social media efficiency is that we aren’t working far enough ahead. Therefore, when we sit down to “manage” our social media channels we are trying to write a status update, publish the status update, review blog posts while we are sharing them and replying to anyone who has reached out.

  Tasks like writing status updates require a creative state while actually posting, and scheduling, requires a productive state. The biggest challenge is that these are two different mindsets and the process of transitioning between them can take up to 20 minutes. Do you know what happens in that 20 minutes? You guessed it, Grumpy Cat Meme delirium.  The best way to maximize your creative state is to group creative tasks together, and likewise for productive tasks. The last step is to assign a priority to each task. Let’s face it, there are things that MUST get done and things we’d LIKE to get done. Creating a prioritized list will help you know where to cut fat if you find yourself running out of time.

  3Develop a Schedule

  Now that you know what needs to be done, when it needs to be done, and the group of tasks you want to accomplish, it’s time to put together a daily, weekly and monthly schedule. Make sure your schedule reflects the tasks you have batched together. Keep in mind you can break up your daily tasks into convenient time slots during your day. This will help you manage your time more efficiently.

  You’ll find that some tasks have to be done every day in order to be an active participant in social media. This typically includes reading timely 3^rd party content to share with your network and responding to mentions. There will be another set of tasks that need to be completed once or twice a week. It’s best to pick a consistent day to complete these tasks so they don’t fall off the radar or monopolize time you didn’t plan for. Finally, other tasks will be completed once a month. Keep in mind some of these tasks may take a larger chunk of time such as writing blog posts and pulling reports, so it’s best to space them out on days you aren’t also doing other time intensive tasks.

  Here’s a sample daily and weekly task list for managing social media:
  

  Copy the embed code below to use this image on your site:

  <a class="colorbox" href="http://www.rignite.com/blog/5-tips-for-effective-social-media-time-management?utm_source=InfographicEmbed&utm_medium=EmbedReferral&utm_term=&utm_content=DailyWeeklyTasks&utm_campaign=Infographics" title="Social Media Time Management: Daily And Weekly Tasks" target="_blank"><img src="http://www.rignite.com/wp-content/uploads/2015/04/Time-Management-For-Social-Media-Infographic.jpg" alt="Manage Social Media More Efficiently With Rignite" style="width:540px;margin:0px auto" /></a></p> <p style="font-size:12px">Compliments of: <a class="colorbox" href="http://www.rignite.com/?utm_source=InfographicEmbed&utm_medium=EmbedReferral&utm_term=&utm_content=DailyWeeklyTasks&utm_campaign=Infographics" target="_blank" title="Social Media Time Management: Daily And Weekly Tasks">Rignite Inc.</a></p> <p>

  4Create a Workflow

  Have you ever noticed when you get ready in the morning you follow exactly the same process every day? My process is pretty simple, shower, brush teeth, put on makeup, fix hair, change into work clothes and eat breakfast. Each one of those steps has its own ritual. In fact, I’ve noticed if something interrupts my process, I’m very likely to be late. The same principle works for social media. It’s important to establish your workflow for how you will accomplish the tasks on your schedule. If Monday is the day you schedule your blog posts, find 4 articles to share, and respond to mentions, have a process for determining the order of those tasks and for how you will actually complete each one.

  For example, scheduling your blog post includes these steps:

  1. Load the post into blog platform
  2. Add images
  3. Add title tag, meta-description, and  keywords
  4. Select the category and tags
  5. Run it through SEO optimization plug-in and make necessary edits
  6. Preview post and make last minutes adjustments for formatting issues
  7. Select the date and time to publish
  8. Publish

  Having a consistent process for going through these steps makes you more efficient and helps to make sure you don’t forget a step. Don’t forget to document the process. This really helps if you ever need to ask someone to step in and help you. Further, don’t forget it is okay to separate tasks into batches and spread them into multiple chunks of time throughout the day, just make sure you document what that looks like and plan for it accordingly.

  5Set a Time Limit

  The last step is to determine how much time you will need for each batch of tasks. The reality is some days you will need 4 hours and some you may only need 30 minutes. Other days you may find that tasks can be broken up into two 30-minute chunks of time. The key is that once you sit down to complete that task, it’s important to set a time limit and stick to it. You could use an old fashioned kitchen timer or a free tool like Toggl to keep your time in check. If you have 30 minutes, sit down and knock out the tasks on your list. If you find yourself running over, maybe you have too many tasks in that batch or you haven’t allotted enough time. Once you get the hang of it, you’ll be busting through that task list. Occasionally you may even find 10 minutes left over. In that case, feel free to knock yourself out and go have some fun with the latest viral video.

  What are your tips for managing social media more efficiently? What are your biggest challenges? Or have some fun and share the most ridiculous thing got you trapped in the social media time warp? Leave a comment and join the conversation.

  Source: Rignite

    

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]> http://sayingitfirst.com/2013/05/02/5-tips-for-effective-social-media-time-management/feed/ 0 http://sayingitfirst.com/2013/05/02/freebie-ios-grid-system-a-free-extension-for-adobe-fireworks/?utm_source=rss&utm_medium=rss&utm_campaign=freebie-ios-grid-system-a-free-extension-for-adobe-fireworks http://sayingitfirst.com/2013/05/02/freebie-ios-grid-system-a-free-extension-for-adobe-fireworks/#comments Fri, 03 May 2013 00:36:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/02/freebie-ios-grid-system-a-free-extension-for-adobe-fireworks/ I’ll come right out and say it. I think the grid is the unsung hero of a good design. It gives structure and lets the design fall perfectly into place on the canvas. With a grid, adapting and building something new into your design is easy. Think [...]

  SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

  ]]>
  
  

  I’ll come right out and say it. I think the grid is the unsung hero of a good design. It gives structure and lets the design fall perfectly into place on the canvas. With a grid, adapting and building something new into your design is easy. Think of it like a house’s foundation. With a solid foundation, the house is stable, and building on it is easy. With a solid grid, your design can easily be adapted to accommodate whatever changes come along.

  Today, we’ll share iOS Grid System, which I’ve been using when designing apps in Adobe Fireworks. The extension is free for both personal and commercial use, and it works with all iOS devices as of March 2013.

  Installing and using the iOS grid extension in Fireworks is pretty easy. We’ll explain the process in detail, but you can jump to the download section and try the extension right away.

  
  

  Why Are Grids Useful?

  Before we continue, a bit about grids.

  I like consistency. It helps me feel like I can trust whatever I’m using at the moment. At a deeper level, users appreciate consistency because it builds trust — trust that you aren’t going to pull the rug out from under them in the middle of whatever they’re doing. They know what they’re going to get, and they’ll be more comfortable with you if everything lines up just right, rather than if elements look like spaghetti thrown against a wall. In the end, consistency improves trust and credibility through better design quality, and it improves usability by making a website or application more understandable, predictable and findable.

  As a designer, I like figuring out a system that makes updating easy for me. Grids help here because I don’t always have to worry about how a particular element should align with another; I’ve thought ahead and done that work already.

  Learning about grids helps you put out better designs. Grids — specifically, how to apply them so that a design can be consistent and grow into itself — are an essential topic for designers.

  Actually, they’re only essential if you want an interface that is:

  • consistent,
  • easy to update,
  • polished even after you’ve finished working on the interface. (I guess we needed to make that clear first.)

  Whether you work with clients or are on an internal team, grids are especially useful when those last-minute “Hey, can you just add this little button in somewhere? It’ll take only a second, I swear!” changes come in. Accommodating that request becomes much less trouble simply because a good grid is in place. Just pick the appropriate column (or columns), and boom — you’re done. Happy client, happy you!

  I like what Khoi Vinh has to say about grids in this short (but great) interview:

  “Khoi Vinh: On the Grid,” from The Color Machine

  “The grid is a tool for me to impose order and logic and law. There’s a framework. If you remove all subjectivity, then you get some essential truth, some core idea that’s not clouded by inaccuracies or approximations or subjective feelings.”

  Why Make An iOS Grid Extension For Adobe Fireworks?

  The easy answer is that most of my designs these days are for iOS, and a grid system is essential to every design I craft. I start using it early on in the design process, and having a solid grid in place when I design makes sense for me.

  I decided to build it after noticing how much time I spent making decisions that I could have easily automated. With this extension, I don’t have to spend time tediously clicking and dragging around to make sure my grid’s shapes and guides are pixel-perfect. This extension allows me spend more time on other important parts of the process (such as how the design works and looks).

  Now, I just open Adobe Fireworks, create a new project, and then select what iOS device I’ll be designing for and the number of columns I’ll need. Then, the grid appears on my canvas, along with some nicely sized gutters, which help my design breathe a little easier.

  Here’s what it looks like (notice the green overlay):

  
  The iOS grid in practice. (Large version)

  About The iOS Grid Extension

  The extension is made for Adobe Fireworks and is optimized to help you create designs for all of Apple’s mobile devices (in both portrait and landscape modes) as of March 2013. It will be updated as new iOS devices and resolutions arrive.

  
  iOS Grid System will build your grid automatically on any page in Adobe Fireworks. (Large version)

  Here’s what’s included in the extension package:

  • Non-Retina iPhone (3GS) grid command
    Grid size: 320

    SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

    ]]> http://sayingitfirst.com/2013/05/02/freebie-ios-grid-system-a-free-extension-for-adobe-fireworks/feed/ 0 http://sayingitfirst.com/2013/05/02/open-source-plugin-magnific-popup-a-truly-responsive-lightbox-for-jquery-and-zepto-js/?utm_source=rss&utm_medium=rss&utm_campaign=open-source-plugin-magnific-popup-a-truly-responsive-lightbox-for-jquery-and-zepto-js http://sayingitfirst.com/2013/05/02/open-source-plugin-magnific-popup-a-truly-responsive-lightbox-for-jquery-and-zepto-js/#comments Thu, 02 May 2013 17:48:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/05/02/open-source-plugin-magnific-popup-a-truly-responsive-lightbox-for-jquery-and-zepto-js/ A lightbox is one of those tools that work great on the desktop but often fail on small mobile devices. These days, finding a plugin that is responsive and that displays content right away is hard. For this reason, I created Magnific Popup, an open-source lightbox plugin [...]

    SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

    ]]>
    
    

    A lightbox is one of those tools that work great on the desktop but often fail on small mobile devices. These days, finding a plugin that is responsive and that displays content right away is hard. For this reason, I created Magnific Popup, an open-source lightbox plugin focused on performance.

    In this article, I’ll share the techniques I employed in creating this plugin, techniques that can make your lightbox much faster and easier to use, whatever the device being used.

    1. Speed

    We might not be able to speed up the loading time of an image with this lightbox plugin, but we can create the perception of a faster loading time.

    Progressive Loading of Images

    The majority of lightbox plugins will fully preload an image before displaying it. This is done to figure out the original size of the image and to center it with JavaScript. Because Magnific Popup centers the content with CSS, we can avoid preloading and instead display the image right away to take advantage of progressive image loading. It will render and show the image while the data is being received.

    You can speed this up even more by progressively rendering the JPEG. It is rendered not from top to bottom, but from low quality to full quality, so the user can discern the image even faster. The type of rendering to use is strictly a matter of preference.

    

    CSS-Based Resizing

    The CSS-only approach makes this lightbox extremely flexible. You can specify sizes in relative units such as ems, resize popups in media queries, and update popup content dynamically without having to worry about how it will be resized and centered. Try to avoid, or at least reduce, the number of resizing properties in a window’s resize event, because it will look much slower than resizing with just pure CSS.

    Vertically centering an element with unknown dimensions is probably the most horrifying topic in CSS layout. The main goal for me was to prevent the size of the content area from dynamically updating the contents of the lightbox, and to make it work in IE 8 and above.

    Following the principle of progressive enhancement, I decided to drop the vertical centering feature in IE 7 completely, because the only way to implement it was to use slow CSS expressions, which kill performance in old browsers. In contrast to modern browsers, the resolution of monitors on which IE 7 is being run is unusually easy to predict. We’d know that the user would be on an old PC, which typically has a resolution of somewhere between 800

    SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

    ]]> http://sayingitfirst.com/2013/05/02/open-source-plugin-magnific-popup-a-truly-responsive-lightbox-for-jquery-and-zepto-js/feed/ 0 http://sayingitfirst.com/2013/04/30/desktop-wallpaper-calendar-may-2013/?utm_source=rss&utm_medium=rss&utm_campaign=desktop-wallpaper-calendar-may-2013 http://sayingitfirst.com/2013/04/30/desktop-wallpaper-calendar-may-2013/#comments Tue, 30 Apr 2013 21:57:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/04/30/desktop-wallpaper-calendar-may-2013/ We always try our best to challenge your artistic abilities and produce some interesting, beautiful and creative artwork. And as designers we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered the best one—desktop wallpapers that are a little more distinctive than [...]

    SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

    ]]>
    
    

    We always try our best to challenge your artistic abilities and produce some interesting, beautiful and creative artwork. And as designers we usually turn to different sources of inspiration. As a matter of fact, we’ve discovered the best one—desktop wallpapers that are a little more distinctive than the usual crowd.

    This creativity mission has been going on for over five years now, and we are very thankful to all the designers who have contributed and are still diligently contributing each month. This post features free desktop wallpapers created by artists across the globe for May 2013. Both versions with a calendar and without a calendar can be downloaded for free. It’s time to freshen up your wallpaper!

    Please note that:

    • All images can be clicked on and lead to the preview of the wallpaper,
    • You can feature your work in our magazine by taking part in our Desktop Wallpaper Calendar series. We are regularly looking for creative designers and artists to be featured on Smashing Magazine. Are you one of them?

    The Green Bear

    Designed by Pedro Rolo from Portugal.

    

    • preview
    • with calendar: 1024
      

      SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

      ]]> http://sayingitfirst.com/2013/04/30/desktop-wallpaper-calendar-may-2013/feed/ 0 http://sayingitfirst.com/2013/04/29/more-than-just-lorem-ipsum-content-knowledge-is-power/?utm_source=rss&utm_medium=rss&utm_campaign=more-than-just-lorem-ipsum-content-knowledge-is-power http://sayingitfirst.com/2013/04/29/more-than-just-lorem-ipsum-content-knowledge-is-power/#comments Mon, 29 Apr 2013 19:20:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/04/29/more-than-just-lorem-ipsum-content-knowledge-is-power/ “Content matters!” “Comp with real copy!” “Have a plan!” By now, you’ve probably heard the refrain: making mobile work is hard if you don’t consider your content. But content knowledge isn’t just about ditching lorem ipsum in a couple of comps. Countless organizations now have a decade [...]

      SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

      ]]>
      
      

      “Content matters!” “Comp with real copy!” “Have a plan!” By now, you’ve probably heard the refrain: making mobile work is hard if you don’t consider your content. But content knowledge isn’t just about ditching lorem ipsum in a couple of comps.

      Countless organizations now have a decade or two’s worth of Web content — content that’s shoved somewhere underneath their redesigned-nine-times home page. Content that’s stuck in the crannies of some sub-sub-subnavigation. Content that’s clogging up a CMS with WYSIWYG-generated markup.

      Messy, right? Well, not as messy as it will be — because legacy content is the thing that loves to rear its ugly head late in the game, “breaking” your design and becoming the bane of your existence.

      But when you take the time to understand the content that already exists, not only will you be able to ensure that it’s supported in the new design, but you’ll actually make the entire design stronger because you’ll have realistic scenarios to design with and for — not to mention an opportunity to clean out the bad outdated muck before it obscures your sparkly new design.

      Today, we’re going to make existing content work for you, not against you.

      What You Don’t Know Will Hurt You

      When you’re working on something new and fun, ignoring the deep recesses of content is tempting. After all, you’ve got a lot to think about already: designing for touch, dealing with ever-changing screen sizes, adding geolocation features, maybe even blinging things out with a few badges.

      But if content parity matters to you (and it damn well should if you care one whit about the “large and growing minority of Internet users” who always or mostly access the Web on a mobile device), then at some point you’ll have to deal with the unruly content lurking underneath your website’s neat surface.

      Why? Because chances are there’ll be stuff out there that you’ve never thought about, much less designed for. And all that stuff has to go somewhere — too often, shoehorned into a layout it was never meant to inhabit, or perhaps not even migrated into a new template but instead left to wither in an outdated, mobile-unfriendly design.

      Take navigation. As Brad Frost has written, designing small-screen navigation for small websites is simply tricky, any way you slice it.

      Hard as it already is, it becomes downright impossible if you haven’t dealt with your legacy assets first. You’re sure to end up with problems, like a navigation system that only works for two levels of content when you actually have four levels to contend with, making all of that deeper information accessible only with hard to manage (and find) text links — or, worse, making it completely inaccessible except through search.

      There’s a better way.

      In The Belly Of The Beast

      Mark Boulton has written eloquently on content-out design — the concept of determining how your design should shift for varying displays by focusing not on screen sizes, but on where your content naturally breaks down. It’s excellent advice.

      But if you’re trying to work with a website with thousands of URLs — or anything more than a few dozen, really — you have to ask: Which content do I design with? Unless you’re relying on infinite monkeys designing infinite layouts to create custom solutions for every single page, you’re going to have to rely on representative content: a set of content that demonstrates the variety of information that the experience needs to support.

      So, how do you know what’s representative? You get your arms around the size, scope, structure and substance of your content.

      Yup. It’s time for the content audit.

      People have been talking about content audits and inventories for more than a decade — in fact, Jeffrey Veen wrote about them on Adaptive Path back in 2002, calling them a “mind-numbingly detailed odyssey through your web site.” At the time, people were starting to yank their websites from static hand-coded pages and pull them into content management systems, and someone needed to sit down and sort it all out.

      More than a decade later, I’d say content audits are more useful than ever — but in a slightly different way. Today, a content audit isn’t just an odyssey through your website; it’s a window into your content’s nature.

      What To Look For

      You could audit content for all kinds of things, depending on what you want to learn and be able to do with the information. Some audits focus on brand and voice consistency, others on assessing quality or identifying ROT.

      There’s nothing wrong — and quite a lot right — with these priorities. But if you want to ready your content to be more flexible and adaptable, then you can’t just look at each page individually. You need to start finding patterns in the content.

      It’s a simple question, really: What are we publishing? If your first answer is “a page,” look again. What’s the shape of this content? What is this content most essentially? Is it an interview, a feature story, a product, a bio, a recipe, an erotic poem, a manifesto? Asking these questions will help you see the natural pieces and parts that make up the content.

      When you do, you’ll have a structural model for the content that matches your users’ mental model — i.e. the way they perceive what they’re looking at and how they understand what it means.

      For example, I recently worked with a large publicly traded company whose website dates back to the early aughts. After a couple of responsive microsites, they’ve caught the bug and want to update everything. Problem is, the existing website’s a mess of subdomains, redirects and thousands of pages that are nowhere near ready for flexible layouts.

      Our first step was to dig deep, like a geologist — except that instead of unearthing strata of shale and sandstone marking bygone eras, we identified and documented all of the forgotten templates, lost content and abandoned initiatives we could.

      We ended up with a dozen or so content types that fit pretty much anything the company was producing. Sure, we still ended up with some general “pages.” But more often than not, our audit revealed something more specific — and useful — about the content’s nature. When it didn’t, that was often a sign that the content wasn’t serving a purpose — which put it on the fast track to retirement.

      Once you’ve taken stock of what you have, gotten rid of the garbage and identified the patterns, you’ll also need to decide which attributes each content type needs to include: Do articles have date stamps? Does this need a byline? What about images? Features? Benefits? Timelines? Ingredients? Pull quotes? This will enable you to turn all of those old shapeless pages — “blobs,” as Karen McGrane has so affectionately labeled them — into a system of content that’s defined and interconnected:

      
      This content model shows attributes for the “recipe” content type, and how recipes fit into a broader system.

      Each bit of structure you add gives you options: new abilities to control how and where content should be presented to best support its meaning and purpose.

      Regardless of what you want to do with your content — launch a responsive website, publish to multiple websites simultaneously, extract snippets of content for the home page, reuse the content in an app, mash it up with a third party’s content — this sort of structure will make it possible, because it enables you to pick and choose which bits should go where, when.

      Tools for Auditing Content

      The content audit may not be new, but some tools to help you get started are. Lately, I’ve been running initial reports with the Content Analysis Tool (CAT), which, for a few bucks, produces a detailed report of every single page of content that its spiders can find across your website.

      Using CAT’s Web interface, you can sift through the report and see details such as page types, titles, descriptions, images and even the content in


      tags — super-useful if you’re assessing content of murky origin, because a headline often gives you at least a glimmer of what a page is about.

      Here’s an excerpt of what it found for Smashing Magazine’s own “Guidelines for Mobile Web Development” page:

      
      The CAT report shows a thumbnail of the page, as well as some data about its content. See the full screenshot for more.

      While features such as screenshots of all pages and lists of links are useful for individual analysis, I prefer to export CAT’s reports into a big ol’ CSV file, where the raw data looks like this, with each row of the spreadsheet representing a single URL:

      
      CAT also spits out detailed CSVs chockfull of raw data about all pages of a website. See the full screenshot for all of the fields.

      It’s not perfect. For example, if content’s been abandoned and removed from navigation but left floating out there in the tubes, CAT typically won’t pick it up either. And if a website’s headlines aren’t marked up using


      (like Smashing Magazine, which uses


      s), then it won’t scrape them either.

      What it is great for, though, is getting a quick snapshot of an entire website. From here, I usually do the following:

      • Add fields for my own needs, such as qualitative rankings or keep/delete notations;
      • Set up filtering and sorting so that I can slice the data by whichever field I want, such as according to the section where it’s located;
      • Assess and rank each page according to whatever qualitative attributes we’ve settled on;
      • Note any patterns in the content types and structures used, as well as relationships to other content;
      • Define suggested meta-data types and tags that the content should have;
      • Use pivot tables, which summarize and sort data across multiple dimensions, to identify trends in the content.

      With this, I now have both the detailed information to drive specific page-level changes and the high-level patterns to inform structural recommendations, CMS updates, meta-data schema and other efforts to improve content portability and flexibility.

      I like using CAT because it was designed by and for content strategists — and improved features are rolling out all the time — but you can also use a similar tool from SEOmoz (although it tends to sell you on fancy-pants reporting features), or even grab a report from your CMS (depending on which one you use and how it collects information).

      Any of these tools will help you quickly collect raw data. But remember that they’re just a head start. Nothing replaces putting your eyes — and brain — on the content.

      The Secret To Scale

      You don’t have to love auditing content. You certainly don’t need to develop a sick addiction to pivot tables (but it’s totally OK if you do). What you will love, I promise, is what a deep knowledge of content enables you to do: create an extensible design system that doesn’t devolve at scale.

      For example, let’s look at some of the larger websites that have started using responsive design. There’s higher education, of course, where early adopters such as the University of Notre Dame were quickly followed by a rash of college websites.

      What do most of these websites have in common? Two things: a lot of complex content and a responsive system that carries through to only a handful of pages, like the UCLA’s website, where the home page and a few key pages are responsive, but the deeper content is not:

      
      UCLA’s home page is responsive, but most of the website, like this landing page, is not. Larger view.

      Why doesn’t that design go deeper? I’d bet it’s because making a responsive website scale takes work, as Nishant Kothary summed up brilliantly in his story of Microsoft’s new responsive home page from late 2012:

      “The Microsoft.com team built tools, guidelines, and processes to help localize everything from responsive images to responsive content into approximately 100 different markets… They adapted their CMS to allow Content Strategists to program content on the site.”

      In other words, a home page isn’t just a home page. You have to change both your content and the jobs of the people who manage it to make it happen.

      But one industry has had some luck in building responsively at scale: the media — including massive enterprises such as Time, People and, of course, the Boston Globe. These organizations manage as much or even more content than Microsoft and universities, but as publishers with a long history of creating professional, planned, organized content, they have a huge leg up: they know what they publish, whether it’s editorials or features or profiles or news briefs. Because of this, everything they publish fits into a system — making it much easier to apply responsive design patterns across all of their content.

      Making Tough Choices

      When you start breaking down your big, messy blobs of content and understanding how they really operate, you’ll realize there’s always more you could do: add more structure, more editing, more CMS customization. It never ends.

      That’s OK.

      When you understand the realities of what you’re dealing with, you’re better equipped to prioritize what you do — and what you choose not to do. You can make smart trade-offs — like deciding how much time you’re willing to invest now in order to have the flexibility to do more later, or what level of process change the current staff can handle versus the amount of flexibility you could use in the content.

      There are no right answers. All we can do is find the right balance for each project, team and audience — and recognize that some structure is going to serve us a whole lot longer than none will.

      Everyone’s Job

      I get it. Going through endless reams of content ain’t your thing. You’re a designer, a developer, a project manager, damn it. You just want to get on with it, right?

      We all do. But the more you seek to understand your content, the better your other work will be. The less often your project will go off the rails right around the time it’s supposed to launch. The fewer problems you’ll have with designs that “break” when real content gets inputted. The more the organization will be able to keep things in order after launch.

      Best of all, the more your users will get the content they need — wherever and however they want it.

      Thanks and credits go to Ricardo Gimenes, for preparing the front page image.

      (al)

      ---

      © Sara Wachter-Boettcher for Smashing Magazine, 2013.

      Source: Smashing Magazine

        

      SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

      ]]> http://sayingitfirst.com/2013/04/29/more-than-just-lorem-ipsum-content-knowledge-is-power/feed/ 0 http://sayingitfirst.com/2013/04/27/2779/?utm_source=rss&utm_medium=rss&utm_campaign=2779 http://sayingitfirst.com/2013/04/27/2779/#comments Sat, 27 Apr 2013 18:32:00 +0000 SayingItFirst http://sbkmconsulting.com/2013/04/27/2779/ Source: Random Acts of Progress   

      SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

      ]]>

      Source: Random Acts of Progress

        

      SayingItFirst | Naperville SEO/SEM Internet Marketing Technology Company

      ]]> http://sayingitfirst.com/2013/04/27/2779/feed/ 0