Tag: kranthi

Removing Stumbling Blocks In Mobile Forms


  

A few weeks ago, I was quite surprised when I saw the pavement quickly approaching while I was out for a walk. Laying there stunned, I soon realized what had happened: I fell. Ouch. B-minus. I normally try to be as attentive as possible, but this time a big crack in the pavement caught my shoe and threw me completely off balance.

After reporting my clumsy accident to friends and family, I instantly received comments like: “be more carefulâ€� or “better watch out next timeâ€�. In the end, I started to defend myself—if that crack would not have been there, I most likely would not have been face-planted.

Mobile stumble

When it comes to filling out forms on a mobile phone, I have observed many users running into a similar experience, merely less painful in its physical aspect. Many elements within a mobile form affect how smoothly users will get to a service or product hiding behind a form of any kind.

There are several factors that can be considered to be stumbling blocks throughout the journey of filling out a form. Specifically on a portable device, this journey is complicated by the fact that we have to consider contextual parameters such as time, location, or limited input options, in comparison to a firm desktop experience. In this post we will look at the most common stumbling blocks for mobile devices. Moreover, I will discuss design strategies to avoid stumbling blocks and to facilitate a safe and quick stroll through forms for mobile users.

Help Users Stay On The Right Path

Some might say that elegantly designed forms can be compared to the likes of an efficient traffic system—as soon as you enter the road, you also enter a world of permanent and dynamic guidance that helps navigate you safely to your final destination. For example, the crosswalk signals tell you when it is okay to cross the street, just as the street signs signal the names of the streets that you are on.

Street lights are also provided to help you navigate through difficult terrain in the dark. Keeping in mind your ultimate destination, you ultimately decide where to go, step by step. Road signs present your options and point out limitations. You can follow the traffic, take a short cut, or obey the navigation system on your phone.

In this situation, comprehensible and timely feedback is vital. The same applies to mobile form design. Signposts and immediate feedback encourage users to complete a form. Although inputting data on a mobile device can be very cumbersome, many people happily key in vast amounts of information when using services such as Twitter, Facebook, or text messaging on their mobile devices. Such services are good examples of how seemingly poor interfaces will not stop people from using a much wanted service, as long as the return of their effort is evident. People who understand and trust the outcome of their journey are less likely to hesitate about wandering even down a difficult path.

However evident the effort of typing on a mobile device might be, inputting data can take some time and can also become frustrating very quickly. Letting your users know almost instantly that they provide data in the wrong format, or that their username is already taken, is important. In the same way, a form can tell them where they are within the form, to make sure they don’t type the right data into the wrong field.

Furthermore, portable devices are more likely to suffer from connection errors and slow connections than desktop devices. Client-side validation techniques, such as HTML5/CSS based or optimized JavaScript approaches, have proven to be advantageous in this case, as they reduce the amount of data transfer to easily allow UI enhancements while coping with less stable connections. But keep in mind when using JavaScript for form validation, that some mobile browsers (such as the Blackberry OS browsers—except of the most recent one), are not JavaScript enabled per default. Therefore, users who are unable or uninformed about how to change their settings will benefit from implementations following the concept of progressive enhancement. The less time users spend on retyping data or waiting for data to be validated the quicker and happier they will get through a form.

Minimize Steps And Crossroads

One of the biggest take-aways from the Keystroke-level model in form design is that navigating along interactive elements requires both physical as well as mental activity. This can have a severe impact, especially on a mobile phone, based on the natural way of interacting with a portable device. Every input field within a form requires users to scroll through it, understand its meaning, focus on it, and then provide the correct information.

Due to the fact that people use their devices in a lot of different ways and these devices vary “greatly”, form elements that are spread over several input fields are prone to be rendered on a mobile device in a way unintended by the designers. As an example, during user testing sessions, I sometimes see users getting stuck on providing their phone numbers when having zoomed in on the form. The typical behavior is to enter their entire number into the first box provided for the area-code, completely missing the second input field. After submitting the form, they are puzzled about why there are two fields and the corresponding error message.

Phone number example
Separated telephone number fields (left) in comparison to a unified field (right) with optmized input type and a label within the field to remind users about the area code.

To allow users to get through a form quickly, there are a variety of compression techniques to reduce the amount of fields needed to provide certain data. Many of them require more post-processing on the back-end. If you can’t dissect numbers on the back-end, smart defaults or clever instructions work just as good. Some of them simply require a thought about the way of keying information into a field. For example, using a predefined drop down to provide the date of birth, rather than a loose input field or htlm5 optimized input fields for numbers, mail addresses, or other types of data, when appropriate. Dynamic input masks can help users to provide even quite complicated types of data with ease. Moreover, it will just take you a minimal effort of scripting.

At other times, forms might benefit from rather unconventional approaches such as text input fields for a quick and easy country selection. Furthermore, there are a variety of libaries such as jQuery mobile to optimize input fields and to ease validation, even for complex data.

Overall, our goal is to allow people to navigate through the form, achieving the quickest possible success with the least necessary effort. At all times we want them to feel that they are doing the right thing, and that their time is well spent. Brevity is crucial. Some people get stressed when spending too much time on trying to find hidden checkboxes, switching between keyboard layouts, or attempting to understand skewed marketing questions. Some people get physically tired answering redundant questions, filling unnecessary blanks, or scrolling up and down to find a required field that they just missed. To reduce cognitive load as well as physical effort it is important to remove optional steps from a user’s radar of attention, simplify the way of inputting information wherever possible, and to create a comprehensible flow throughout the form. If the process is too complicated (or the effort too high) a dropout is quite likely.

In the end, fine-tuned and streamlined forms will save your company phone calls from frustrated users and lead to more and more happy ones as it requires them to spend less time navigating through input fields and figuring out their meanings.

Uitilize Signposts And Mark Paths Clearly

Another great design concept to exploit for form designs are the Gestalt laws of grouping to help support the orientation of users. Applying grouping principles to a multiple questions form allows us to structure content, to create a visual flow, and to group related form elements.

In many projects I have seen design teams arguing about whether to break down a rather long form for mobile devices into several short pages or rather for one long page. Either way, there are endless possibilities for both design approaches to elegantly confirm users about their progress. This helps them recover from their errors, and to make them feel confident that the data being saved will not have to be reentered (in case they loose the connection, or accidentily close the application).

Both design approaches have their individual benefits, the only spanning factor here is the breakdown of the long form into meaningful and manageable chunks. For single-page designs, this means that it should even be possible to visually distinguish the single steps from one another. Especially with portable devices, the longer a form page is, the faster users will be able to scroll through, in case they have to jump between fields. Poor visual guidance in this way will result in users missing to fill out fields, losing sight of fields, and/or getting frustrated by searching for them after being presented error messages. White space and general grouping techniques are therefore vital to create visual guidance throughout a form.

Visual differentiation example
Using color coding to highlight the active input field from other input fields (left) or to visually differentiate sections from one another in a long form (right).

Distinct grouping in interface design is a basic exercise because of its power for reducing processing speed and cognitive load. A while back, Matteo Penzo investigated the effect of different visual grouping techniques for a typical sign-up process. In his eye-tracking study, he analyzed the importance of label alignment for input fields and highlighted the superiority of top-aligned labels in many cases. Easy to distinguish input fields with top-aligned labels in close distance to one another allowed users to look at the label and the field in one go.

Other techniques required higher processing efforts, thus increasing the coginitve load and the time it takes to process the entire form. Less effort is good, and despite the granular example, we have to keep in mind that all these factors add up through input elements, the different sections, and the form as a whole within the website. The more complex the form, the bigger the effects of distinct grouping. Reducing the need for visual fixations allows a reduction in cognitive load, helping users to focus on their task and allowing your form to function almost like a navigation system—helping users to find their way to the goal.

By considering the effects of distinct groupings, we support our human capability to naturally perceive objects as organized patterns and take away the need for users to create an understanding about the form by reading the questions in depth, relating to the elements mentally. Naturally we want users to read through the questions. But similar to a vis-à-vis conversation, we can use facial expressions in combination with the words we say to underline our message and to get it across more easily.

Allow For Platform-Dependent Shortcuts

One of the major reasons that users get stuck on forms when filling them out on portable devices is limited visibility. Users, who are entering key information into a form’s field, usually have more than half of their screens covered with the keyboard, input suggestions, and other status information. To navigate between fields, and for general orientation, I see in many testing sessions where participants frequently try to disengage the onscreen keyboard, when looking for certain fields, or scrolling through the form to increase visibility.

However, many people will use the “return� button on the bottom right of the keyboard to disengage it after keying information into the field, or even to confirm their input for the single field. Although this approach helps many users to get rid of the keyboard (and to see the form on their whole screen), pressing the button also means, in many cases, that the form will be sent to the server straight away. Therefore, many users will be confused by a loading screen and the need to wait for a server response after pressing the “return� button.

Onscreen keyboard example
The return button on Android (left) and iOS (right) is very salient within Web forms, and pressed by many users without the intent to send off the form.

Using the keyboard to send off a form is very handy, when using a single field form such as a search box. However, for multiple question forms on portable devices, it is important to check the form on the client side before sending it off, when users press the “return� button (by accident) to avoid confusing loading times. To ensure that your form is not submitted by accident, there are plenty of client-side validation tools; jQuery plugins, for example, provide everything we need.

Provide Contextual And Personalized Guidance

In short, be a tour guide. After all, designing a good form is like planning a hike with friends or family. Not only do we need to find out who will be on the trek, we need to plan for breaks, points of interest, and unguided side-treks in order to make sure everybody gets the most of their hike. However, as most of you will know, most hikes are not free of problems, and difficulties are inevitable; people can wander off, some might need help or more time to get through challenging passages, weather conditions are bound to change, and general mistakes happen. It is seldom that all of these inevitable difficulties will evolve into a real problem as long as we are prepared. Similarly to a hike, difficult situations are all about awarness, clear communication, and guidance. All it takes is a good approach to inform users what their problem is and what they can do to fix it.

There are plenty of techniques to help strayed users find their way back to the right path. Putting messages under input fields, for example, has proven to be quite a solid approach for telling users what has gone wrong. In combination with noticeable color coding (i.e. red for errors, or green for confirmation) you can be sure to get the necessary attention.

Error message example
Two designs showing prominent error messages for misspelling hints (left) and general processing errors (right).

Another important aspect that is often neglected when it comes to messages within forms is the choice of words. On the one hand this refers to what we say, and on the other, it is about how we say it. Your error messages or instructions will most likely be read by a nontechnical human being. Let’s create messages as we would be talking directly to your user: avoid jargon, be tactful and brief. There are many useful recommendations on how to design effective error messages. Most importantly, we want our users to understand what happened and why it happened in a clear fashion.

On top of that, most users will not only appreciate clear notification, but also advice on how to fix the problem right away. Dyson, for example, managed to reduce support calls and increase the confidence in their products with a simple change in the way they display error messages. Rather then showing the problem (e.g. “Low Voltage Error”), they switched to displaying possible solutions (e.g. “Check Power Cable”). In this way, they are not only making their users aware of problems, they are also giving them guidance on how to fix them. On your form, many different users will possibly make similar mistakes. If possible, it is a good idea to analyze inputs to include a solution for the problem that helps users to recover them quickly. Ideally it even relates to the data they wrongly provided.

Wherever error messages pop up troughout the day, try to record them. At the end of the day, those records can tell us where stumbling blocks are still hiding, and what we need to improve to smooth out the path.

Conclusion

Mistakes happen—c’est la vie. Ideally though, we should aim to avoid most of the tripping hazards that delay so many users from filling out forms on a portable device. Similar to an uneventful stroll on the pavement, the smoother the path is to the destination, the more likely users will complete the journey. Easy orientation, no detours, clarity, and a little bit of guidance are a traveler’s best friends. And experience shows that the further users get before stumbling upon an error, the more likely they will put extra effort into completing the task.

Ultimately, other stumbling blocks may exist apart from the ones I discussed. So try to connect your analytics to the activity on the pages to find out where people drop out of the process. This will show where stumbling blocks may exist and help to remove one block after the other to ensure the user the smoothest journey.

(jvb)


© Robert Brauer for Smashing Magazine, 2012.


Make sure your HTML5 document outline is backwards compatible

This is just a short reminder of something I wrote about in On using h1 for all heading levels in HTML5: make sure your HTML5 document outline is backwards compatible.

The reason is simple. Browsers and assistive technology haven’t implemented the HTML5 outline algorithm yet (the only exception I’m aware of is JAWS, which gets it wrong, as Jason Kiss explains in JAWS, IE and Headings in HTML5).

Read full post

Posted in , .

Copyright © Roger Johansson



Applying Macrotypography For A More Readable Web Page


  

Any application of typography can be divided into two arenas: micro and macro. Understanding the difference between the two is especially useful when crafting a reading experience, because it allows the designer to know when to focus on legibility and when to focus on readability.

This article focuses mostly on a few simple macrotypographic techniques—with a dash of micro—and on how to combine them all to build a more harmonious, adaptable and, most importantly, readable Web page.

First, some definitions. Microtypography has to do with the details; setting the right glyph, getting the appropriate kerning and tracking, and making stylistic choices such as when to use small-caps. Micro techniques have received a lot of attention recently, as browser makers adopt new CSS attributes that allow for finer control over Web type. Microtypography deals mainly with legibility and can be thought of as the design of letters and words.

Macrotypography focuses on how type is arranged on the page. Most macro techniques have been achievable through CSS for quite some time, but because our understanding of the Web page is changing, the way we use these techniques must adapt. Macrotypography deals mainly with readability and can be thought of as the design of paragraphs and the page.

The Importance Of Readability

For the designer’s purpose, readability refers to the ease with which a body of text can be consumed, and it correlates closely to the reader’s eye strain. This should not be confused with legibility, which refers to the degree to which individual glyphs in text can be discerned. The techniques for creating a great reading experience are complementary to those for creating a great user experience (UX), and vice versa. They also both share the same symptoms of failure. Poor readability on a website can lead to confusion, frustration and ultimately abandonment, while a great reading experience is invisible, supportive and engaging.

As with UX design, every website design would benefit from some measure of concern for readability. For example, text-heavy websites—such as blogs, newspapers and magazines—should uphold readability as a priority, while websites for events and e-commerce might just need to tweak line heights and font sizes. Whatever level of importance you place on readability, you should undertake a continual process of refinement towards an effortless reading experience.

Techniques For Improving Readability

The foundation of great reading experiences on the Web lies in the study of book design. After all, books are where readable typography was honed. Personally, I hold The Form of the Book by Jan Tschichold as the ultimate resource for good taste in book design, and I am certainly not alone.

Many of the techniques we’ll cover here have been adapted for the Web page from lessons introduced in this book. Sadly, the book has been out of print for about 20 years (at least in the US), and a copy can cost around $150 on Amazon’s marketplace. I have created a digest of it, but if you want to read the full text, you could always try your local library or university (which is how I finally got my hands on it).

Now, let’s look at the various macro techniques—and a few micro techniques—to make your website’s content more readable. I have chosen an article that is typical of the kinds of reading experiences users encounter. I have removed the header and some branding elements, but it remains mostly as I found it.

In our example, important content (navigation, advertising, related links) lies on either side of the reading area. For optimum readability, a less obtrusive placement of these elements would be best, but this is not always possible. We will, therefore, not rearrange the layout, but work within it. Here is what we are starting with:

As we learn about each technique, we will apply it to our example. But keep in mind that this exercise is to improve only the reading experience, not the overall design.

Command Your Margins

Margins give the eye room to maneuver. They provide a buffer between the main content and ancillary elements—such as related links and ads—allowing the reader to focus on the text. Beyond this purely functional purpose, margins can also bring deeper harmony to the layout.

Margins comprise negative space; they afford the designer an opportunity to build a relationship between a body of text (the figure) and its surroundings (the ground). As Tschichold tells us, “Harmony between page size and the type area is achieved when both have the same proportions.� Now, the proportions of a page in a book are much different than those of most digital displays (especially ones in landscape orientation), so to adapt this concept to the Web, we can work towards a harmony between our text and its immediate visual container.

In Practice

On our example page, the margins are not very generous. Also, the main content is crammed in between two very loud columns. First, we can add more space to the right of the text, giving the reader room to go from the end of one line to the beginning of the next without being distracted by the secondary content on the right. And adding more margin to the left of the text allows the reader to easily find the start of the next line and to scan the article for topics they are interested in.

Margins can be set intuitively by increasing the amount on each side until the content feels comfortable. Applying this to our article element is easily achieved by adding padding in our CSS (rather than margin, in this case). For now, we will just double the padding on the left and right:

article {
   padding-left: 20px;
   padding-right: 40px;
}

In our adjustment of the margins, we can create still greater harmony between the copy and its surroundings, but first we must visualize an invisible container around the content. This will be our “page� with which to build harmony in the reading area:

The way to create harmonious proportion between text and its container is to give them the same shape. The content should have the same proportions—only smaller—as its containing element. Tschichold surveyed a mountain of book proportions and concluded that the most harmonious proportions for margins are roughly 2:3:4:6 (top:right:bottom:left) for the left-facing page (recto) of a book. Given that we do not have facing pages on the Web, we can make the margins symmetrical and adjust the ratio to 2:3:4:3 by shaving off a bit of the left margin. Web text does not need as much side margins as book text because Web pages do not need to accommodate the reader’s thumbs.

Though they may seem the obvious unit of measure, percentages for padding will only measure in relation to the width of our article element’s container, skewing our top, bottom and side proportions to an inappropriate degree. Therefore it’s best work with padding in ems or pixels until the reading area has the same proportions as its container. To keep things simple, let’s start with 2em for the top padding in our example. After applying our adjusted ratio from above, our article’s padding can be written as 2em 3em 4em 3em or 2em 3em 4em in CSS shorthand. Given the fluid nature of content on the Web, this is just an approximation of Tschichold’s proportions. For a typical body of text on the web—which is taller than it is wide—the margin should be generally less on top, even on the sides, and most at the bottom:

article {
   padding: 2em 3em 4em;
}

We can also move the lead image to the right. This allows the body copy to hold its shape better and allows for even easier scanning of the article. We can break this principle to draw attention to images and figures, of course, but for our example the image is too distracting on the left when placed early in the article.

If we want, we can bring the text forward on the z axis, putting even more focus on our copy and de-emphasizing the ancillary content by creating a visible container for our text. This is a tactic we can easily use in Web design that books do not need:

body {
   background: #fcfcfc;
}

article {
   background: #fff;
   border: 1px solid #eee;
   padding: 2em 3em 4em;
}

Our page already feels more balanced and less intimidating, but we can use more techniques in the body of the text to further enhance readability.

Choose Readable Fonts

Font selection is a micro concern, but it has a tremendous impact on the macro appearance. In Detail in Typography, Jost Hochuli best outlines this interdependence: “In typography, details can never be considered in isolation.�

The font for the body copy should be chosen for its on-screen readability, before any concern for style. The headings and pull quotes are perfect opportunities to flex your typographic creativity, but leave the long runs of copy to dependably readable workhorses such as Georgia, Arial and Myriad, which were all designed for optimal reading on a back-lit screen.

Fonts that are more readable on digital screens typically exhibit the following attributes:

  • Tall x-height;
  • Slightly wider em width, but not condensed or extended;
  • Mostly devoid of style;
  • Serifs for larger type, and sans-serif for smaller type.

All of these rules have exceptions, but they should be your guiding principles when choosing a font for the body copy. Here are some font stacks that I find give some flavor of style, provide appropriate fallbacks and are all highly readable:

In Practice

Let’s apply Myriad Pro to the body text on our page:

article {
   background: #fff;
   border: 1px solid #eee;
   font-family: "Myriad Pro", Arial, Helvetica, sans-serif;
   padding: 2em 3em 4em;
}

Keep It Measured

In setting any block of text, we must consider its measure. Measure is defined by either the number of characters per line or the number of words. I use words because they are easier to count, and I try to follow Tshichold’s suggestion of 8 to 12 words per line. If you base your measure on characters, then 45 to 85 characters per line is ideal. Once the margins and widths have been set, proper measure can be achieved through two attributes in the CSS, font-size and word-spacing.

When deciding on a size, strike a balance between making the font small enough that the reader is not too distracted when jumping to the next line, but big enough that they do not have to lean in to read the text on the screen. For most fonts, 16 pixels works well. Other factors might lead you to making it larger or smaller, but 16 pixels is a great place to begin. As for word spacing, most browsers do a decent job of setting this for you, but if you are having trouble getting an appropriate measure, cheating this attribute slightly either way can be handy.

In Practice

On our page, let’s add a 16-pixel font size, and cheat the word spacing in just a tiny bit to achieve a proper measure (word-spacing is supported in all major browsers). You might instead want to use ems or rems here so that the layout remains flexible whatever the font size set by the user as their default.

Until we set a new line height, our page will look like a jumbled mess, so let’s just look at the code at this point:

article {
   background: #fff;
   border: 1px solid #eee;
   font-family: "Myriad Pro", Arial, Helvetica, sans-serif;
   font-size: 16px;
   padding: 2em 3em 4em;
   word-spacing: -0.05em;
}

Set An Appropriate Line Height

Once the font size is set, you can determine the appropriate line height. On the Web, we work in terms of line height, which by default is an equal amount of space above and below text on a line. Not to be confused with leading in print design, which generally refers to the amount of space below a line of text. The governing rule for line height (and leading) is, the longer the line length, the taller the line height should be. And vice versa: the shorter the line length, the shorter the line height.

Find an appropriate line height by first determining the point at which the ascenders and descenders of the lines of text do not touch, yet the lines are close enough that the reader requires no effort to find the next line. Then adjust until the height feels balanced with the line length. Some may leave the line-height attribute to the browser’s default, while some may set a global line-height on the body element. Both approaches make sense because the line height would then stay proportional to the element’s font size; but both also assume that the line width of the content will stay consistent, which could lead to situations that violate our governing rule.

In Practice

Let’s add a line height of 1.3 ems to our example, using ems so that our line height stays proportional to the font size, and see how the font size and line height work together:

article {
   background: #fff;
   border: 1px solid #eee;
   font-family: "Myriad Pro", Arial, Helvetica, sans-serif;
   font-size: 16px;
   line-height: 1.3em;
   padding: 2em 3em 4em;
   word-spacing: -0.05em;
}

It is important to note that readable line heights can be especially tricky to keep consistent in responsive layouts, as line lengths will vary based on device widths. To solve this issue, Tim Brown has proposed an idea he calls “Molten Leading,� which would allow line heights to increase proportionally based on the screen width. His post links through to a couple of Javascript implementations of this idea. In lieu of Javascript intervention, you can also manually find the screen widths at which the line heights become uncomfortable, use a media query to target that width, and set a more readable line-height in the CSS.

Find The Proper Paragraph Styles

We need to figure out which paragraph style best fits the content. Jon Tan has done a fantastic job of outlining various styles and how to craft them with CSS. The appropriate style for a piece of content varies based on the flavor of the content and the rhythm of the paragraphs. I have written about my preference for using indents, rather than line breaks, when setting long-form text. This helps to keep the flow between ideas, but it can be distracting when the paragraphs are short or the line length is long. Deciding what constitutes the perfect paragraph for your content is up to you.

In Practice

Our page is a news article, where the flow between paragraphs is dictated more by chronology than by ideas, so line breaks are still appropriate. We could easily apply indents, if appropriate, to the paragraphs with one simple CSS rule:

article p + p {
   text-indent: 2em;
}

We specify p + p rather than just applying the rule to all p tags because we want to indent only those paragraphs that follow other paragraphs. Ones that follow headings, images and so on should not be indented.

Instead of indenting, though, we just want to shrink the line breaks a bit so that each paragraph is not so disconnected from the last. For our page, let’s use half of the line height:

article p {
   margin-bottom: 0.5em;
}

Balance The Text’s Contrast

One final consideration for content is text color. Contrast is a major contributing factor in eye strain and so greatly impacts readability. Low contrast between text and background causes more squinting and blinking among readers, a sure sign of strain. Black on yellow has the highest contrast, but we have been conditioned to view this as a sign of warning or alarm, thus increasing anxiety among readers. Black on white is high in contrast, too, but too harsh for extended reading on back-lit screens. For long-form text, I have found dark-gray text (around #333) on a white or light-gray background (no darker than #EEE) to be optimal. This is a gross simplification of color theory to suit the purposes of this article. To learn more about color, Mark Boulton has written a great primer on color theory for the Web; you can also find many great examples in Smashing Magazine’s series on color.

In Practice

Our article already has a white background (serving as a boundary for the margins), set against a wider light-gray background. We should probably keep the white, and lessen the darkness of the text to #444. We can then use #000 on the headings to give them slightly more emphasis:

article p {
   margin-bottom: 0.5em;
   color: #444;
}

article h1 {
   color: #000;
}

The Result

We now have a much more readable page that invites users into the content. We could employ many more techniques across the entire website, but we have focused here on the main content block. has written a great overview of these techniques and more for Smashing Magazine, which will give you a deeper understanding of everything covered here.

With a clean reading experience, people will better absorb the ideas being presented and will undoubtedly come back for more—that is, if your content is worth reading… but I can’t help you there.

Excellent Reading Experiences On The Web

Readability is not a new concept, of course. If you are just discovering what makes for a good reading experience, then congratulations, and welcome to all the discomforts of recognizing cramped and neglected type on the Web. It’s not all pain, though. Plenty of well-considered blocks of content are to be found. Let’s look at a few great ones and a couple that could be great with slight tweaks.

Please note: In the interest of showcasing only the reading experience, we have cropped each page to a scrolled view of the main content.

24 Ways
The reading experience on 24 Ways is quite nice. The text contrast is well balanced, the measure is not too long, and the font size is generous. At all responsive breakpoints, the design is a perfect example of a page with sufficient and balanced margins around the main reading area.

Desktop view

CNN
Long-form articles on CNN are good examples of how readability can work well on news websites. The layout does not show a visible container for the article—which in this case might have been distracting on a page already laden with so much content—but the margins are generous. Also, the line breaks for the paragraph styles are completely appropriate, because most online news stories are collated and updated from many sources and are not linear ideas. The font size (currently 14 pixels for the body copy) could stand to be a bit bigger, though.

Contents
The tablet view of Contents magazine is a wonderful experience all around. The measure is perfect, the line height and font size play together nicely, and the paragraph styles are perfectly suited to the content. The measure does get too long at desktop sizes, but with all of the other factors working so well, the effect on overall readability is negligible.

Tablet view

Desktop view

Elliot Jay Stocks
Elliot does quite a few things well on his website. The measure is right, the font (Skolar) is very readable and set at a comfortable size (16 pixels), and the line height is just tall enough to accommodate the link style. Generous margins create harmony between the main content and its container, while the side margins are uneven, making the page look like the recto of a book and giving the layout a unique character.

Esquire
Most articles on Esquire are great, but the reading experience is merely good. The margins are ample, the font is readable, and the contrast is high. All of these go a long way towards establishing good readability, but a few simple tweaks would make it great. Increasing the right padding would shorten the measure, which is a bit too long as it is. The font size could also be increased by a couple of pixels. And given that most Esquire articles are a linear progression of ideas, I would suggest paragraph indents rather than line breaks.

The Guardian
The design team over at The Guardian pays attention to crafting great all-around experiences. Readability is no exception. Measure, contrast and paragraph styles all work together to create a focused and comfortable reading experience in the midst of what could be an overwhelming amount of content.

A Working Library
A Working Library is one of the best reading experiences on the Web. Every aspect of readability discussed in this article has been well considered and executed. The harmony between text and its container is pitch perfect.

Refining Towards The Ideal

With the examples above, we have tried to show how readability can excel in a few different digital environments: blogs, news websites and online magazines. Some of these website do not have many of the constraints (such as ads and related content) of more commercial websites, so it could be argued that these designs exist in a vacuum, without pragmatic application or real-world pressures. We need these shining examples, though, to help us find the ideal reading experience for each project; and once we know that ideal, we should do our best to reach it.

In a recent talk on “What Is Reading For?� the famous typographer and poet Robert Bringhurst stated, “Books are and have to be utilitarian objects. They have to be used.� The same could be said of Web pages. Ideal reading experiences create better user experiences. Our job as designers is to refine the aesthetic qualities of the Web’s content in order to speed the process of consumption, thereby facilitating deeper understanding. Tired eyes all over the Web are counting on us.

(al)


© Nathan Ford for Smashing Magazine, 2012.


Desktop Wallpaper Calendar: May 2012


  

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 four years now, and we are very thankful to all designers who have contributed and are still diligently contributing each month.

We continue to nourish you with a monthly spoon of inspiration. This post features free desktop wallpapers created by artists across the globe for May 2012. 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?

You May Rain

Designed by Ioana Bitin (aka Yoot) from Romania.

Smashing Wallpaper - may 12

Flight Of The Owl

Designed by Katerina Bobkova from Ukraine.

Smashing Wallpaper - may 12

Colorful

Designed by Lotum from Germany.

Smashing Wallpaper - may 12

May Charts

"Charts of May weeks. Designed for working environment that helps classify desktop files into categories." Designed by Sherif Saleh from France.

Smashing Wallpaper - may 12

Yatta!

Designed by Alex Dovksha from Belarus.

Smashing Wallpaper - may 12

Food Of Love

"Love needs food too! And what can be better than music! The two most prescious gifts of life, love and music is expressed beautifullyin this quote by William Shakespeare." Designed by Adrija Mukhopadhyay from India.

Smashing Wallpaper - may 12

Sunny Hours

Designed by Christine Bradway from USA.

Smashing Wallpaper - may 12

Japan

"Japan is the land of the rising sun." Designed by Cheloveche.ru from Russia.

Smashing Wallpaper - may 12

Doodle Lizard

"Negative space lizard on a bed of doodles." Designed by James N Osborne from United Kingdom.

Smashing Wallpaper - may 12

Spring Dots

Designed by Pietje Precies from the Netherlands.

Smashing Wallpaper - may 12

Limundograd

"Limundograd (Limundocity) is an illustration for an e-commerce auction site called limundo.com, designed to show users what the site consists of, and much more!" Designed by Mrki from Serbia.

Smashing Wallpaper - may 12

Wishing On A Star

"Keep an eye out for those shooting stars during the clear summer nights. If you see one, make a wish and maybe it’ll come true…" Designed by Eddie Wong from Ireland.

Smashing Wallpaper - may 12

Be Like Him

"Inspired by a verse in the Bible." Designed by Lex Valishvili from Russia/USA.

Smashing Wallpaper - may 12

Thingvellir

"The photo was taken at Thingvellir national park, Iceland." Designed by Naioo from Germany.

Smashing Wallpaper - may 12

Justin Bbq

"It’s spring time, and we at JustLanded.com are celebrating with a BBQ!" Designed by Adelacreative from UK.

Smashing Wallpaper - may 12

Red Panda

Designed by Ingrid Cruz from USA.

Smashing Wallpaper - may 12

Mangolicious May

"In India, May is mostly known for summer holidays and the season of Mango- the best amongst all the fruits. Its the best in terms of flavour, richness and sweetness.As the scorching heat increases in this month, its the delicious mango which keeps us going and makes us look forward to summers. This wallpaper is dedicated to the King of Fruits-Mango." Designed by Charuta Puranik from India.

Smashing Wallpaper - may 12

Grunge Fairy

"May’s fairy is grungy and dark." Designed by Bobbie Killip from UK.

Smashing Wallpaper - may 12

Wonderful Island

"Wonderful Island is the annual meeting point for a unique community of various fairy creatures from different parts of the world. They come here every single year on the exact same day – May, 1 to talk with the old friends and have fun. The merriest guys are, certainly, Furst, the middle-aged Yeti from the North of Iceland and his best friend Charles Dooon, aka DJ Chuck-Chuck, who can’t imagine their lives without music." Designed by Maria S. from USA.

Smashing Wallpaper - may 12

Solitude Is Bliss

Designed by Mohammed Aaqib Ansari from India.

Smashing Wallpaper - may 12

Tentacles

Designed by Julie Lapointe from Canada.

Smashing Wallpaper - may 12

Come What May

Designed by Melissa Infantino from USA.

Smashing Wallpaper - may 12

Join In Next Month!

Please note that we respect and carefully consider the ideas and motivation behind each and every artist’s work. This is why we give all artists the full freedom to explore their creativity and express emotions and experience throughout their works. This is also why the themes of the wallpapers weren’t anyhow influenced by us, but rather designed from scratch by the artists themselves.

A big thank you to all designers for their participation. Join in next month!

What’s Your Favourite?

What’s your favorite theme or wallpaper for this month? Please let us know in the comment section below.

Stay creative and keep on smashing!

(il) (vf)


© Smashing Editorial for Smashing Magazine, 2012.


How I Work: Yahoo!’s Doug Crockford On JavaScript


  

Welcome to the first in a new series of interviews called “How I Work”. These interviews revolve around how 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.

Meet Doug Crockford

First up is Douglas Crockford who believes JavaScript might just be the most elegant language ever. Learn why he thinks you should study the history of computer science, the value of reading your code in front of other people, and that jQuery really is a good thing.

Douglas Crockford is known as The JavaScript Guy. He’s famous not only for his O’Reilly book JavaScript: The Good Parts but even more so as the visionary behind the JSON data format as well as the JSLint tool. He was featured in the book Coders at Work for his contributions and philosophies on what JavaScript got right, and what it didn’t.

As a native of Southern California, Doug has the build of a surfer; lean and tall with white hair and a beard. A veteran of Silicon Valley, he’s worked at Atari Labs, founded and worked at numerous software start-ups, was head of technology at Lucas Films and now has the enviable job of being a JavaScript evangelist at Yahoo!.

Douglas Crockford
Image credits go to Eric Miraglia.

Self-taught (as many of the greats are), he says his goal is simply to get more people coding in JavaScript, or any language for that matter. While his day job may be as a JavaScript evangelist, speaking with Doug you get the sense he really is an evangelist for programming in general.

Below is a conversation that took place in Bozeman, Montana prior to a talk at Montana State University. Doug freely shared his thoughts on great programmers, user empathy, and how JSON restored his faith in humanity.

Why do you feel programmers should study the history of Computer Science?

Well, first semester of physics is a history class. You study Galileo and Newton and all their contributions to the field and that gives us the overall view of physics. It’s a really nice place to start.

I wish CS would do that. It doesn’t seem to have enough value in its history and it’s a really amazing history that’s completely neglected. It’s rarely that the best idea won. So, we’ve taken different paths over the years and maybe haven’t realized why.

Ironically, despite the rate of change in technology, we see in the story of software that it takes a generation to retire or die off before we have a critical mass of bright young minds to embrace new ideas.

I think if people were more aware of their history, they could see these patterns more easily.

What were the traits of the weak programmers you’ve seen over your career?

That’s an easy one—lack of curiosity. They were so satisfied with the work that they were doing was good enough (without an understanding of what ‘good’ was) that they didn’t push themselves.

I’m much more impressed with people that are always learning. The brilliant programmers I’ve been around are always learning.

You see so many people get into one language and spend their entire career in that language, and as a result aren’t that great as programmers.

Do you feel that the pain a programmer goes through in learning a language contributes to this unhealthy attachment to using only one language?

My advice to programmers to avoid this trap is to learn lots of different languages. We’re in sort of a language renaissance right now and there are a ton of brilliant languages to learn from.

To learn new languages takes nights and weekends outside of work, and that’s a commitment. The great programmers are the people that are constantly picking a project and diving into it, learning a language that way.

In Coders at Work, you stress the importance of doing code readings with teams. Why do you feel it’s important to present your code in front of other people?

Well, over the years I noticed that there are some terrific programmers out there that are completely content to sit in their cave all day long writing brilliant code. But they don’t interact much with their team, which means it’s a lost opportunity for mentoring other members.

As you know, a lot of coders aren’t the most socially adept animals either.

So, my idea with code reading sessions is to provide a forum where people can come together and read for each other to get them out of their caves. The masters read for the beginners, and vice versa, as a team-building exercise.

The trick for success is to set up rules ahead of time so that nobody is going to get spanked and everyone is respectful in their feedback. It has to be a good learning experience for everyone. You have to be careful with a dysfunctional team, because it can quickly tear apart the group. But I always call the game before it gets that far.

The rules are that it’s about improving the quality of the code that we’re all responsible for, improving the quality of our team, and improving our individual capabilities.

Some people see this as a terrible time sink. Yet, I’ve found by doing this exercise, bugs are caught way ahead of time and you can prevent a team member from going off the tracks. But again, that’s not the goal, it’s about team building.

Over time the masters help pull up the beginners and the overall output from the team gets better.

Are programmers getting better at user empathy?

The best experience I had with empathy was working in marketing support. There were times I would go out into the field and hold hands with the customers and see the consequences firsthand of some of the crap we were delivering to them.

I was shocked when I moved into systems programming and how the programmers actually held the customer in contempt.

I think every programmer should work in customer support for the product they’re delivering.

It’s another case of over-specialization. “I just write the code,â€� is the response you get and the programmers don’t see it as a chance to improve peoples’ lives.

How much of a language do you need to know?

Virtually every programming language is too big. Language standards have difficulty removing unnecessary features but as users we can choose not to use it.

I would say you can do 100% with knowing 50% of the language.

The language that taught me that lesson the most was JavaScript, because it has more bad parts than good parts. It gave me a very strong motivation for figuring out what are the good parts and what are the bad parts, and what the criteria is for deciding what’s in or out.

And the good parts are just so good. Be sure to watch Doug’s Google Tech talk titled “JavaScript: The Good Parts.”

What approaches would you say a master has versus a beginner?

When I was a journeyman, I was a maximilist. I tried to use the whole language. While I don’t know if I would call myself a master now, I’m certainly a minimalist. I’ve tried to get good at using as little of the language as possible.

I place a lot of value in simplicity and minimalism.

What are your thoughts on jQuery? Some JS enthusiasts feel like it’s letting people off the hook from truly learning JS.

There is some really clever stuff in jQuery and I think John Resig did some very good work there.

I do have a problem with anybody doing anything without understanding what they’re doing. I’m not going to fault jQuery for attracting those sorts of people.

But I do think there are some other AJAX libraries that maybe doing a better job that aren’t quite as accessible. However, I think there is a place for all of these things.

When you were developing JSON was it tough to pull back and not put too much into it?

My design criteria were three things: minimal, contextual, and a subset of JavaScript.

The last constraint was to keep us from going off the rails and inventing new stuff. We had to only use stuff that was in JavaScript, which meant that our unicode handling wasn’t quite right because JS isn’t quite right, which was disappointing. We don’t have proper support for dates because JS didn’t have it. But we can work around both of these.

But it also meant that when somebody proposed, “Hey we should do this crazy thing� we could be like “Nope�. So, we had a really easy criteria for stopping extra features from being added.

One interesting story about leaving things out: as we got closer to releasing JSON I decided to take out the ability to do comments. When translating JSON into other languages, often times the commenting piece was the most complicated part. By taking the commenting out we reduced the complexity of the parsers by half—everything else was just too simple.

One of the best features of JSON is that it’s stable. If your program works now, it will work forever, and that is an attractive thing.

I still get notes from people saying they’ve got great ideas for the next version. But there isn’t going to be a next version. I always say you’re free to invent a new standard and promote it as much as you like.

How did JSON get adopted?

You know, the adoption of JSON sort of restored my faith in humanity because it was a good idea that won out, only because it was a good idea.

It was a case where there were no slick marketing campaigns. In 2001, I started working on it as a way to tie the browsers to the server. At the time, everyone thought XML had to be used or they’d say “that’s a great idea but JSON isn’t a standard”. So, I bought json.org, made a logo, threw up a Web page and it sat out on the Web for three years.

In the meantime, AJAX happened and when it became the way for writing applications JSON was there. There was counter promotion from the XML community, of course.

But when I arrived at Yahoo! some kids at the company started thinking it was okay to start shipping JSON API’s through Web services. And developers found the apps got faster and were easier to write.

It sort of took off from there—no slick campaigns. So a good idea based on simplicity won out for once.

Watch Doug Crockford At Google Speaking On “JavaScript: The Good Parts”

In this presentation from Google Tech Talks, Doug goes over the ideas behind his landmark book, JavaScript: The Good Parts, and dives into the areas of what JavaScript got right and what it didn’t. Learn about the history and common roadblocks programmers run into when developing with this language.

Learn About The JSON Saga

In this video, Doug tells the interesting tale of how JSON was discovered, and sheds some light on how it became a major standard for describing data in an interesting turn of events.

(jvb) (il)


© Jacob Cook for Smashing Magazine, 2012.


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