Good Help is Hard to Find

Good Help is Hard to Find

One of the most fundamental rules of user experience on the web is that developers arerarely qualified to evaluate it. As developers, we know far too much about the web in general, and intuitively grasp details that mystify people who spend their days contributing to society in other ways. For this reason, it’s all too easy for us to build websites and applications that are hard to use. Good user testing during the development process can mitigate the problem, but in many projects, the testing budget is limited if present at all.

A person who has trouble using a website to accomplish a task will quickly grow frustrated. At best, a frustrated person will leave the site; at worst, they will complain about the experience to others. When our users hit a roadblock within a website or application, effective help content is our last chance to transform a negative experience into a positive one.

If content is the red-headed stepchild of web development, help content is even less popular. No one wants to create it or maintain it. When it does exist, it’s frequently hard to find, poorly written, and not terribly helpful. But done well, help content offers tremendous potential to earn customer loyalty.

Best practices

Effective help content is a greater challenge than we might assume. Developing a strategy means thinking beyond writing simple instructions to accomplish a task.


First, we need to understand that anyone who’s reading help content is already frustrated. Our goal is to de-escalate those feelings. The tone must be sensitive, not condescending. Never blame the customer for problems. Consider the following scenario: A web application requires users to click a confirmation link in an e-mail before allowing them to sign in, but the e-mail never lands in the user’s inbox. Imagine reading the following help message addressing the issue:

If you did not receive a confirmation e-mail, check your spam filter. Your e-mail program may have misidentified the confirmation as spam. If you still can’t find it, see the topic “You did not receive an expected e-mail.”

This language, slightly modified from real-world help text, could certainly be worse, but note how possible explanations assume the user’s at fault: “your e-mail program” and “if you still can’t find it.” This text strikes a defensive tone. The issue may well be on the user’s end, but stating it doesn’t make them feel better. Consider this alternative:

If you haven’t already, check to see if our message landed in your spam folder. If it’s not there, give us a call and we’ll be happy to help you activate your account.

This message is much more conciliatory. It implies that it’s the web application’s responsibility to get an e-mail to the user, not the user’s responsibility to find it. It also concedes that the user might have been wise enough to check the spam folder. Finally, it offers a way to solve the problem immediately, not just a link to another page.

When developers write their own help content (or even error message text), it’s easy to take a condescending tone because we’re so close to the subject matter. If at all possible, help content should be produced by a writer familiar with the usage of an application or website but not necessarily intimate with its inner workings.


Help content does not exist for its own sake. It supports someone who tried, but was unable to perform a task. People follow the path of least resistance to a goal, and if task instructions take too long to process, they’re likely to abandon the quest. Help content should be brief, containing just enough detail to address the problem and get the user back on task.


Help content references the form and function of an underlying application. This dependency may not be obvious to developers, who are focusing their efforts on the application itself. Designate someone to take responsibility for evaluating changes to determine if they affect the help section. For example, a simple application interface change has far-reaching consequences if your help content includes screen captures. If a link that previously said “Back to listings” now reads “Cancel,” you will need to update dozens of references. Once help content gets out of sync with the website or application it references, it becomes decidedly unhelpful. A website’s content strategy—or an application’s maintenance workflow—must include a procedure to review and update help content as the source material changes.

Embedded help

Help content can be rendered in many ways, but if possible, embedding it directly within the feature it serves is almost always the best choice. When help is offered in context, affordanceis high: That is, the help is obvious to the user. Even better, context-based help is the least disruptive to workflow, as it doesn’t require the reader to view a separate page. Additionally, it doesn’t rely on screen captures or illustrations, so it’s easier to maintain. At a technical level, embedded help should be tightly coupled to the code that it supports, making it much less likely that changes to the application will creep in independently.


Embedded help can be as simple as inline guidance on what to enter in a web form, as seen below in Twitter’s account signup process. Here, some explanatory text appears parallel to each form input as it receives focus.

Twitter's signup page displays format requirements next to the passsword field

Twitter’s signup page displays format requirements next to the passsword field.

This approach works well for simple instructions or term definitions—items that likely apply to all users—but it isn’t practical unless the help content is extremely short.


The “tooltip” pattern is another unobtrusive way to embed help. With this approach, a link or icon indicates help is available, but the details are only revealed on mouseover. The effect can be achieved in most web browsers by using the title attribute of an anchor or image element. However, this technique doesn’t offer any control over text formatting, and there’s often a delay between the mouseover action and content rendering, which may be undesirable. Consider CSS and/or JavaScript to create more sophisticated tooltips.

Like inline help, tooltips should be tightly coupled with application content and have strong affordance. An additional advantage is that they keep content out of the way for those who don’t need it. However, they are still only useful to present short text segments with minimal styling. Also, this pattern may not work well outside a traditional desktop browser—in a touch interface, for example.

Realtime analytics software Chartbeat uses tooltips in its dashboard display to explain the meaning of individual metrics:

This tooltip defines what Chartbeat considers an active visit

This tooltip defines what Chartbeat considers an active visit.


With modal dialogs, you can present longer or more complex content (including illustrations, for example) without taking a user out of the current workflow. Consider that web interaction often occurs through forms. If a user partially completes a form and needs help to finish the task, a standard link to content on another page can present a major problem. Unless the link opens a new window, the person loses everything they’ve typed into the form. And, opening a separate window introduces additional complexity that we’ll consider shortly. Modal dialogs bring compromise, allowing us to overlay longer content on the current page. This pattern does come with some caveats, however. It depends on JavaScript and thus needs a fallback behavior when scripting is unavailable. And although a modal dialog may be able to hold more information than a tooltip, content length is still limited.

In this example, Facebook uses a modal dialog to answer a common question on its signup page:

Facebook's modal dialog explains why users must supply their birthdate when signing up

Facebook’s modal dialog explains why users must supply their birthdate when signing up.

Non-embedded help

Sometimes, help content must be lengthy to be effective. When this is the case, the content strategist and developers face a number of important decisions. How will users interact with the information? Will they access it independently from the application it references, requiring separate navigation or a search tool? And, critically, how will we manage updates and additions? Be sure to establish workflow policies from the outset of a project.


Popup windows have a well-deserved reputation as one of the web’s most sorely abused technologies. Conventional usability industry wisdom asserts that users want to control the experience. If they want a new browser window or tab, they’ll open one, and developers shouldn’t make the decision for them. But there are exceptions to this rule, such as links that point to non-HTML documents. When these are opened in the main browser window and rendered through a plugin, users are prone to inadvertently closing the browser instead of returning to the previous page.

Help content is another strong candidate for opening new windows, to avoid disrupting the user’s workflow. However, this practice carries some risk. Power users may be comfortable managing multiple windows, but they’re the least likely to need help. New windows can confuse less technical individuals. If the new window overlays the old one and contains the browser’s default chrome, that new window may not be obvious, and the back button will be useless to return the user to the original page.

Using JavaScript instead of a link target can help address this issue. We can control the size of a new window to ensure that it doesn’t completely obscure the original page, and we can disable the navigation bar and other chrome that isn’t relevant. But, this places a greater burden on developers to manage multiple windows well. Consider the following common scenario:

  1. A new window is created with:'widget-1-help.html','help_window','width=450')
  2. The user reads the content and then clicks back to the original page without closing the help window.
  3. The user clicks a second help link with:'widget-2-help.html','help_window','width=450')

In many browsers (Safari being an exception), the second click will appear to do nothing at all. In reality, the new content was loaded into the existing window (because the same name was specified in the second argument to the function). But, the window doesn’t automatically gain focus when it updates. Thus each call to must either specify a unique name for the window or explicity focus it after loading.

Window management is but one of the complexities long-form help content introduces, and issues like these make a compelling argument for using embedded help whenever feasible. But even when this isn’t possible, help content links should be context-sensitive. It’s much more effective to provide links to specific topics than a general “Help” button that requires the user to re-navigate.

In the example below, Github informs a new user that he must generate SSH keys to publish code. Key generation is not a simple topic, so the site links to instructions. The link opens a separate window to a long-form help page, but beyond that, it auto-detects MacOS or Windows and displays a system-specific set of intructions—an excellent example of sensitivity to context.

Github links to instructions for creating SSH keys

Github links to instructions for creating SSH keys.


Many websites structure help content in a question-and-answer format, even when they don’t explicity use the label “FAQ.” Although the FAQ pattern has been discussed at lengthelsewhere, it’s interesting to consider why it works.

When written in question form, help content automatically gains a conversational, informal tone. If the user identifies with one of the questions, he feels understood—the company has anticipated his questions and doesn’t think he’s stupid. Clearly, the key here lies in writing good questions—and even if the text isn’t written as a question, informality is disarming. Help content is the last place for marketing messages. A question such as “Why are Acme widgets the very best widgets in the world?” is unlikely to help either the user or the business.

It may be challenging, however, to organize questions so that a user can easily sort through them when the writer’s phrasing doesn’t exactly match the user’s. Again, it’s helpful to link to specific topics in context rather than offer up a large pile of questions to a user who’s only asking one.

Raving fans

Frustrated users can become a company’s biggest fans. People who have no trouble using a system may not give the experience a great deal of thought. But someone who has difficulty and then finds that the system anticipated their need for help (and met it effectively) is much more likely to appreciate the thoughtfulness of the system’s developers—and of the business itself. Effective help content is a powerful and underused tool to make that experience possible. 


Making Geotargeted Content Findable For the Right Searchers

By Vanessa Fox

A few weeks ago, I organized and moderated several sessions at SMX London. One of those sessions was about international SEO, which in part, touched on the issues related to having content available for multiple countries and languages. What’s the best way to make sure that searchers in a particular country or speaking a particular language are able to easily find the content you have available for them?

Last week, I was reading Eric Ward’s column Now Is the Winter of Linking’s Discontent, where he writes:

Personalized search results have been with us for a while, but this patent [about Google’s personalized search patent that Bill Hartzer discssuses on his blog] is chock full of link building implications.  I’d say this is especially true for web sites trying to do business in multiple countries but offering their content in only one language.   And if you take the time and effort to truly make your content available in other languages, do you also need to host that other language content on a server based in that country if you want to rank well for searches originating from that country?  What about duplicate content? Aren’t French and German versions of a site, if hosted in France and Germany, duplicate? Hmmm.

These questions came up at SMX London as well. How do search engines sort out content targeted for particular languages and regions and what are the best practices for making sure you’re being seen by your target audience?

How search engines determine the geographic intent of the searcher

Search engines try to display the most relevant results possible to a searcher. The language of the searcher, the searcher’s geographic location, way the searcher accesses the search engine, and language or regional intent in the query are all factors the search engines consider when determining relevance. Since queries are generally three to four words long, search engines use all the signals they can beyond the query to figure out what searchers are really looking for.

For instance, if a searcher is in Ireland searches for [airline booking], they’ll likely get a very different list of results than a searcher in the United States, as the results will skew towards Irish airlines. But this doesn’t just happen at the country level. If a searcher in Seattle searches for [pizza], they’ll likely get more Seattle-based pizza listings than a searcher in Boston would. And for Google in particular, a searcher who’s logged into a Google account and has set a default location in Google maps may get even more targeted results. Google has made this option more visible lately, and for queries they think may have local intent, they offer a zip code option:

In addition, a searcher will get get different results:

  • Searching from the US.
  • Searching from France.
  • Searching and choosing “French pages”
  • Searching and choosing “pages from France”

And, as you might imagine, including a geographic location in the query impacts results as well. A search for [restaurant in Dublin] returns different results than [restaurant], regardless of the other signals. And searching in a particular language will generally return results in that language. For instance, look at the results for the query [donde esta los cabos] from a US IP address on

So, to recap, some ways search engines determine regional intent include:

  • Domain accessed ( vs.
  • Language-restriction (only search French pages)
  • Country-restriction (only search pages in France)
  • Location of searcher (at the country level, as well as more local levels, such as the city)
  • Locational or language intent in the query
  • Searcher’s default location (such as set in Google Maps)
  • The language the query was composed in

Remember  that search engines make slight tweaks to their algorithms all the time as they test what changes improve results. As personalized search becomes more important, it would make sense that if a searcher generally clicks on results in a particular language or country, pages in that language or from that country may start to appear more often for that searcher.

Note that I’m mixing language and region together a bit for the purposes of this article, although they are, of course different. And issues can crop up because there’s not a one-to-one mapping between language and country. For instance, if someone is searching for Spanish pages, should a search engine return pages from both Mexico and Spain? (Probably if the query is language-specific but not regional; and perhaps search engines should use the country associated with the site as a signal for the language the site is in.) Conversely, if you have a site that targets Spanish speakers, do you need separate sites for both Mexico and Spain? (Maybe not if your content isn’t regional, but how then do you ensure your content is returned for searchers in both Mexico and Spain?)

How search engines determine the relevance of the page

Once a search engine decides what is relevant for the query, what signals from the pages come into play? They include the following:

  • Top-level domain (TLD): Many domains can only be used for a particular country. For instance, .fr always signifies a domain in France. TLD could potentially be used as a signal in determining language as well. a .fr domain is likely to have French content.Many domains, however, aren’t country-specific. .com, .net, and .org are well-known examples, but some countries allow their domains to be used by anyone. For instance, .tv is the TLD for Tuvalu, but that country has negotiated an agreement to make the TLD available for anyone ).The exception to the standard seems to be .us. While it’s intended for US-based domains, it hasn’t really taken off, and .com is much more commonly used.
  • Server location: For domains that are not country-specific (such as .com or .tv), search engines use the geographic location of the server where the site is hosted to determine country. For instance, a .com hosted in Canada is seen as a Canadian site and a .com hosted in Australia is seen as an Australian site.
  • Google Webmaster Tools setting: Google Webmaster Tools includes an option for specifying the geographic location of a site. This option isn’t available if the TLD is country-specific. This setting basically replaces the server hosting location signal. This option is useful not only because you can host your domain anywhere and still set a location, but also because you can set each subdomain and subfolder of your site separately, if you’d like. For instance, you can set or to Spain and or to the United Kingdom. The disadvantage to this solution is that it only works for Google.
  • Location of incoming links: If 90% of the incoming links to a site are from Germany, then search engines figure the site is German, or at the very least, of interest to German searchers.
  • Language of pages: Again, language is technically a different relevance factor than country, but the two go hand in hand. If a site is in French, then it’s likely a site from France. The biggest signal used here is probably (as you might imagine), the language of the text on the pages. This criteria isn’t foolproof. What if the page includes multiple languages, for instance? The meta data and character encoding can help here. For instance, if you are translating your English pages into other languages, don’t forget to translate your title tag and meta description tag as well.
  • Address: For local queries (for instance, that [pizza] query from a Seattle searcher, search engines might use the physical address it finds on the page, as well as any information from the search engine’s local index (for example, Google’s Local Business Center). If your site is for a local business, make sure you include your full address and register with each engine’s local index.Even if your site isn’t specifically for a local business, you may want to include regional signals on your site. For instance, if your site is, and you have a page about each Chicago restaurant, you might assume that anyone coming to the site understands the context is Chicago, and that you don’t need to include “Chicago, IL” in each restaurant’s address. However, when a search engine sees “Joe’s Pizza, 123 Main St.”, there’s no indication that this restaurant is in Chicago. This can cause a usability issue with visitors coming to the site from search as well. Those visitors aren’t coming to the page from the home page that may say “Reviews of all Chicago Restaurants”. They may go directly from search to the page about Joe’s Pizza, and would need confirmation that 123 Main St. is indeed in Chicago.

How should  a site owner architect a geographically targeted site?

Ideally, a company should maintain separate sites for each country, each with the correct TLD. When you do this, search engines can easily determine which page to show for searchers in different countries.

What about duplicate content?

Even if the content is the same across each site, you don’t need to worry about duplicate content. Remember that search engines generally don’t penalize for duplicate content, they filter. And in this case, filtering is exactly what you want. You want the search engine to show the UK page to searchers in the UK and filter out the US page. And that’s what search engines typically do.

If you are targeting only one country and have the .com rather than the correct TLD, make sure it’s hosted in the target country. (Check with your hosting company, if you use one, to verify where the server is actually located.)

Sounds easy enough, but this solution doesn’t work for everyone. You may not be able to get the TLD for every country you operate in, or for other infrastructure-related reasons, you may need to host all the content on the same domain. In that case, I would recommend the following:

  • Putting content for each country on a subdomain or subfolder. (Either is fine; but  if you’re starting from scratch and have a choice, I’d generally suggest going with a subdomain.)
  • Ensuring all content (including title tag and meta description) is localized.
  • Focusing on regional link-building efforts. For instance, make sure that your PR team is targeting newspapers in local regions, not just near the corporate office.
  • Including location-specific terms in internal anchor text. For instance, you might want to create an HTML site map that links to each country’s “home page” on the domain.
More strength in one domain?

At SMX London, there was some debate about if it was better to have a single domain for all countries to consolidate PageRank, and if multiple domains (one for each country) would dilute the overall strength.  Remember that relevance is a critical factor for search engine ranking and PageRank alone doesn’t equal relevance.  A page that is deemed highly relevant for a query, but has low PageRank is going to rank above a page that has high PageRank but has low relevance.

With that in mind, TLD is a strong relevance factor for results in a particular country. As for the argument that it’s more work to build links to multiple sites than to one, I content it’s around the same, since even if you had the country-specific information on subdomains or in subfolders instead, you’d still want to build regional links to each. So, I would generally recommend TLDs if you can get them.

However, if you have a .com (for instance), with separate subdomains that you’ve been maintaining for a period of time, it probably makes sense to leave things as is and consider the other relevance factors (regional links, language of content, etc.). If you radically change your site structure (for instance, from subdomains to separate TLDs), you’ll need to have the content recrawled, reindexed, and reranked, and may need to change user perception, branding, link building efforts, among other things. And that may take some time. In a situation like this, I would recommend changing only if you’re having substantial problems getting the right content to be returned for the right country indices.

What about targeting multiple countries?

What if you want results returned to everyone? Or you have German content you want returned in Germany, Switzerland, and Austria? Unfortunately, there’s no perfect solution. In some cases, you’ll have to rely on the search engines to understand what results your pages are relevant for, but keep in mind that a more specific site may be seen as more relevant.

In some cases, other sites may be more relevant. For instance, if you have a US site in English that targets tourists worldwide, your content won’t be shown to searchers in France who select “only French pages”. And even if searchers don’t filter using that option, a site that has created content in French, targeted to tourists in France who are planning a visit to the US is likely to be seen as more relevant than your site targeting the world.

What about IP-Targeting?

Some sites detect the location of the visitor based on IP address, and redirect them to a country (or other location)-specific page. While this seems to be a user-friendly solution, some issues exist:

  • The location may be incorrect. For instance, many AOL users appear to be coming from Virginia.
  • The searcher may want a different location. For instance, when I was in Zurich, I still wanted the US Hertz site, but Hertz sent me to the Swiss site automatically and gave me no options for navigating elsewhere.
  • Search engines need unique URLs in order to index content separately.
  • Search engines crawl your site from a particular location, but you want all locations indexed.

If you have your site set to detect a visitor’s location and show content based on that, I would recommend the following:

  • Serve a unique URL for distinct content. For instance, don’t show English content to US visitors on and French content to French visitors on Instead, redirect English visitors to and French visitors to T hat way search engines can index the French content using the URL and can index English content using the URL.
  • Provide links to enable visitors (and seach engines) to access other language/country content. For instance, if I’m in Zurich, you might redirect me to the Swiss page, but provide a link to the US version of the page. Or, simply present visitors with a home page that enables them to choose the country. You can always store the selection in a cookie so vistors are redirected automatically after the first time.

Google isn’t the only search engine

Of course, Google and Yahoo and Live aren’t the only search engines. If you’re targeting other countries, research who the dominant search players are there and how to best optimize for them. Mona Elesseily recently wrote an article on Search Engine Land about international search markets, and while she was focusing on paid search, the players and numbers are similar for organic search.

An international strategy is about more than targeting

Of course, a lot more goes into creating localized content. You should localize, not just translate, the content. Searcher behavior and customer needs may be different from country to country. Even simple phrasing may be slightly different. Different PR efforts may be need to build awareness and links. And there are conversion factors to consider. At SMX London, several panelists pointed out that searchers are more likely to click search results that had their local TLDs in the domain, because they felt more confident those domains would give them localized content.

Hopefully, this article can help sort out some of the issues that arise when planning a global site strategy, but it’s certainly only a starting point.

More information

(By Vanessa, who clearly is still working through technical blog issues.)



Speak to any seasoned designer long enough and the topic of copywriting comes up. Any designer worth their salt knows the value of great copywriting and how it can transform a dull, routine web experience into a delightful one.
But what exactly does it mean to write great copy? How do we know when we’ve achieved it? Is this something that we can learn as part of the design process, or should we have a dedicated copywriter (if we don’t already)?
A good case study for the power of copy comes from the white-hot startup Groupon. Groupon is a collective buying service that offer daily deal coupons in most major cities around the world. By some estimates Groupon is the fastest growing company ever.
If you’ve ever read a Groupon deal (and chances are you have) you may have been struck with how friendly and informal the writing is. They take great pains to make even the most mundane services sound exciting. Here’s an excerpt from a recent Groupon I received for a deal on a dentist: 
The Tooth Fairy is a burglarizing fetishist specializing in black-market ivory trade, and she must be stopped. Today’s Groupon helps keep teeth in mouths and out of the hands of maniacal, winged phantasms: for $49, you get a cleaning, an exam, and x-rays at Longwood Dental Group in Brookline (a $356 value). The office is easily reachable from the C Line’s Englewood Avenue stop on Beacon Street.
Now, anybody who can make a visit to the dentist at least interesting is writing some impressive copy. And the thing is, Groupon makes this look easy. You barely realize they’re sucking you into another daily deal for an everyday service when you’re already clicking through to take advantage of it. That’s the power of great copy…when it’s really good you barely notice it’s there. 
It turns out that Groupon has lots of writers on staff. (as of September 2010 they had 70) And they also have an entire style guide that helps writers adhere to the friendly Groupon voice: 
Public Groupon Editorial Manual
Reading through this manual is a wonderful exercise in decoding what makes Groupon’s writing work. I highly recommend it. Here’s an example of how Groupon uses counter-intuitive imagery to draw readers in:
Use Absurd images. Sweeping, dramatic nonsense. The absurd narrator.
e.g. Humankind has been playing with fire for years; now we can harness the bronzing essence of the fiery sun in a gentle mist, proving once and for all our dominance over the weak, inanimate solar system.
There is lots of talk of whether Groupon can keep their advantage over new competitors. But the competitors I have seen don’t have the copywriting chops that Groupon does, at least right now. As long as Groupon continues to write such great copy, they’ll have a big advantage over their competitors. That’s the value of copywriting…an integral part of the user’s experience. 


Recently I was reading a list of copywriting guidelines on how to make web pages attract and keep a reader’s attention. The list contained familiar items you’ve probably seen before: write a catchy headline, talk benefits vs features, and focus on a single message instead of many.
One recommendation, however, rang false to me: keep your text short. The author recommends this because “People don’t read on the Web”. Instead, the author claimed, they “scan” text instead. 
There are several problems with this assumption, however. First, people do actually read on the Web…scanning is simply the first step in the process. Second, short text can be just as poorly written as long text (and often is). Third, people actually seek out and enjoy reading longer texts. 
People Scan First, then Read
The fact that people scan when on the Web has little to do with length of text. The act of scanning, or glancing through and quickly examining headlines, subheadlines and other emphasized text, is not a substitute for reading: it’s merely the first step of reading. People scan quickly to find the good stuff…it’s the most efficient way to find it. 
Despite feeling overwhelmed, we are incredibly efficient at finding information on the Web. Once the scanning bears fruit and we find a headline delivering the promise we’re looking for, we slow down and begin reading word for word for more detail. We dive in. We might not read long…only long enough to find an answer…but we are “reading” at this point. And if the piece is longer, such as a piece from a newspaper or magazine, we might read all of it.
It’s not so much that people don’t read, it’s that we start by scanning large amounts of information for the good stuff. Then, and only then, do we dive in and read. 
Text Length doesn’t Equal Quality 
For a bad writer short copy is easier to write than long copy. They simply stop writing sooner. All things being equal short text is preferable to long text, but since when are all things equal?
It is important how short text gets short. If text is kept short merely to stay within the guideline, chances are it doesn’t do all that it needs to do. But if text is short as the result of careful writing and revision, with a strict adherence to saying all that is necessary as briefly as possible, then your text won’t just be short, it will also be good. (and thus read)
Short copy shouldn’t be a goal, it should be an ideal. Like Einstein’s famous quip “make it as simple as possible, but not simpler”, in writing we want to “write as concisely as possible, but don’t leave anything out”. 
People Enjoy Longer Texts
Finally, people often enjoy longer texts. Given the choice between a well-written short piece of text and a well-written longer piece of text, many would choose the longer version because it naturally has more of what the reader wants to know. It answers more questions. It goes in depth and provides context and detail. People who are truly interested in a topic will read everything they can about it. How often do you hear people say things like Sunday is my time to sit down with the paper (or an iPad) and read what I didn’t have time to read before? 
Additionally, e-readers like the Kindle, the Nook, and the iPad are exploding in use, while services like Instapaper also suggest that people desire to read longer texts with less distraction. In this way longer text can become a powerful differentiator…if you are telling an interesting story and your competitor isn’t then you’ve got an upper hand. Take, for example, the power of writing in Groupon.    
In conclusion, explaining people’s behavior on the web as simply “scanning” is too simplistic. Short text can be as poorly written as long text, and in some cases short text is less desirable than longer, well-written text.
Writing well often means writing short text. But writing short text doesn’t mean you’re writing well.