Writing for the Web – Highlights from the Nielsen Norman Group Conference

Last week I spent 2 days in a class called “Writing for the Web,” put on by the Nielsen Norman Group (NNG). They are usability experts on all aspects of the web experience, from accessibility to visual design to content. I wanted their take on how web writing fits in to the overall scheme of effective website design. Here are a few highlights.

Highlights

Reading on the web really is different from print. NNG’s research and eye-tracking studies show that people who read online find it:

• Harder
• Slower
• Less effective in terms of comprehending what they read

The NNG instructor used the term “information foraging” to describe how people read online. To attract and keep the hurried web reader, web writing has to be shorter, simpler and clearer.

Written content is key. Despite what your graphic designer might tell you (and I love the ones I work with), it’s the words on the page that have the most impact on users – not color, not format, not layout. Not blinking boxes or popups or videos. Words are the quickest, simplest way to communicate clearly with users. And they are by far the most effective element on a website for building trust and credibility.

Clarity beats cleverness. People are very task-oriented on the web. They want to conserve their mental energy. So encountering your newly-coined term, inside joke, or cultural reference is more likely to make them click away. If your meaning is unclear, they won’t stay to figure it out.

Surprises (to me)

People don’t mind scrolling. Previously, I thought it was best to avoid creating pages where users had to scroll. According to NNG’s research, clicking around is more disruptive to people’s web experience than scrolling down a long page. That’s why we take these classes!

Simpler writing helps everyone. I was stunned to learn that 43% of people in the US read at a lower level of literacy. Meaning they read more slowly than average and have more difficulty understanding what they read.

Simpler writing – meaning fewer words per sentence and fewer syllables per word – benefits everyone. Reading speed and comprehension increase enormously, even for high literacy readers. When you consider the time saved, and the greater satisfaction people feel when they can understand and make decisions more easily, it’s a no-brainer to take the time to simplify your copy.

MS Word has a grade level indicator. As in, “this copy is written at a 6th grade reading level.” Who knew? Probably you did. But if you want to achieve a target grade level for your audience, this is ONE data point that shows how close your copy comes. I now have this feature turned on in my copy of Word 2010.

Thumbs-up for the Yahoo Style Guide. NNG confirms that this is a good style guide to use on the web. It’s a guide – not the gospel – and NNG is quick to point out that part of a web writer’s job is to exercise judgment in applying any style guide.

Bottom line: Pardon the cliche but, “It’s the content, stupid.” No matter what neat, new technology comes along, it’s still the words that matter most to your audience. So take a bow, all you web writers and editors. Your ability to find those few, right words that resonate with your audience and compel them to act is a skill and an art to be proud of.

Responsive Design: Optimizing Web Content to Device Screens

Remember mainframe computers? Desktop computers? How quickly times change. Now people are accessing the Internet via PCs, laptops, tablets, smartphones, and coming up rather quickly now – glasses and watches. Who knows what is on the horizon? In other words, more challenges to presenting our content in a meaningful way will continue to be developed. We are in another tumultuous time for keeping pace with a rapidly evolving environment, and how we respond to this challenging environment can be very tricky.

A new report from Pew Research Center, “Teens and Technology 2013” states that “Smartphone adoption among teens has increased substantially and mobile access to the internet is pervasive. One in four teens are ‘cell-mostly’ internet users, who say they mostly go online using their phone.” Adults aren’t quite there yet, only 15 percent of adults are ‘cell mostly.’

Even with the proliferation of cell phones, and the multitude of other devices with which you can access a website, it’s a wonder most servers haven’t exploded in trying to please each device’s screen (or the screen’s owner). We in the web business tend to be eager-to-please people. We want you to have the best experience you can have on our website, no matter which device you use to view our website, and even if it keeps us awake at night trying to figure out just how to do that.

So how do you serve up your content to adapt to those very different sizes of screens? If you have ever tried to go to a “full” website (PC version) on your smartphone, you know how tiny the text can look, and you have to scroll left and right, or pinch or expand the page to be able to read or click on something. Mobile versions of websites can be equally annoying because they are laid out differently, can lack certain features that are available on traditional websites, and may not feature the full content of the website. Usually they have an escape route that will take you back to the full website, but then you are back to scrolling, pinching and expanding.

You have probably heard of HTML 5. It is also known as “responsive web design” or “responsive design.” It is a website design that enables a server to respond to the particular device you are using to view the website and serve up your content in the most optimal fashion. If you want to try out an example of a website built with HTML 5, check out www.boston.com, home of the Boston Globe newspaper. Depending on which device you access the site with will determine what you see. It responds to the device, the size of your browser (you can minimize or maximize your window) and even the orientation. If you are exploring what to do with advertising locations on your web pages in such an environment, you can see that there also.

Flexible construction, coding and design make for content that can be presented to all types of devices. This makes more sense than creating various websites (and duplicating efforts) for various devices. It is not without its challenges, though.

• If you still use tables to present and contain data, their rigid structure can be prohibitive to “flexible” page construction. Deconstructing the data and presenting it in a text format can be cumbersome and not as easily digestible, especially in this age of readers who scan pages. Presenting it in a Word document or PDF via a link on the page requires someone to click on a link to get information that is normally presented within the body of the content.
• Wide images can also challenge a smaller screen’s width. Some solutions include creating smaller images for smaller screens, or to hide the image when a smaller screen accesses it.
• Advertising, with its premium locations “above the fold” (or viewable in the first screen) can sometimes be sacrificed to a floating position at the bottom of a phone screen, or shoved to the bottom of a tablet’s page – not really an ideal location for someone paying to be seen.

How web content is displayed will continue to evolve. For more reading about Responsive Design, check out the following stories. Feel free to list your favorite resources in the comments.

•  “Why 2013 is the Year of the Responsive Web Design,” Mashable.com, December 11, 2012. http://mashable.com/2012/12/11/responsive-web-design/
• Responsive Design Newsletter, http://responsivedesignweekly.com/
• Responsive Web Design, http://responsivedesign.ca/
• Responsive Web Design Guidelines and Tutorials, http://www.smashingmagazine.com/responsive-web-design-guidelines-tutorials/

Are You Using Webmaster Tools and Google Analytics? You Should!

by Alan Eggleston

Two tools you should consider adopting for your web editor’s toolbox are Webmaster Tools and Google Analytics. Both are free from Google with a free gmail account.

Google Analytics

Let me start with the latter: Google Analytics. It tracks activity on your website or blog, including how many visits your site gets, how many are new or returning, how long visitors stay, how they got to your site, what they searched to find you, and more. There is a ton of information there if you mine it well, which can help you determine how to maintain your site. Google Analytics is easy to install: All you need to do is insert some code into your site and verify ownership.

Webmaster Tools

The former is equally informative: Webmaster Tools. It provides both data on your site and hints and tips on how to make it better for searches, which as we all know is key to finding you on the Web. The name may make you think this is only for a webmaster, but really, it’s meant for website decision makers. Whoever sets up the account can add users, so even if your webmaster initiates it, he or she can add you as web editor – or the reverse.

Webmaster Tools is a way for Google to alert the site owner to trouble: Are they having trouble reading any pages? You can fix it and have Google re-index them. Have they identified “unnatural” links? You can examine your links and fix the problem so they don’t damage your ranking. Has Google found malware on your site? You can locate and eliminate it. They can also look at your structured data to make sure it isn’t messing up the way Google reads and displays it.

More Useful Tools

In addition, Webmaster Tools allows you to tie your articles into your Google+ Profile for search ranking to help highlight your authorship. They also offer Google Places to make it easier for searchers to find local businesses and the Google Merchant Center to make finding products easier in a Google search.

There is so much more. Both Google Analytics and Webmaster Tools have blogs to help explain the services and forums for finding help. All can contribute to making life easier and more productive for web editors and their teams.

The Agile Editor

If you’re a web editor, you might already work in a company that practices agile software development. But even if your company or your clients haven’t made the transition to agile, they probably will. Agile has been increasing in popularity over the past few years, so it’s a good idea to have an understanding of how agile works and how you can champion content and editorial best practices within this new framework.

What is agile development?
Basically, agile is a faster and more flexible way of managing software and web development projects. Traditional software development involves a “waterfall” approach, with defined phases that move from one to another without overlap: from requirements gathering to design to development to testing to launch. In waterfall, project phases tend to happen in silos (development does not involve feedback from designers, etc.) and can take a considerably long time. And requirements usually can’t be changed until the project is complete.

The agile movement started with the agile manifesto. A group of IT professionals created the manifesto in response to the issues they had with the negative aspects of the waterfall process:

• Project roles are isolated and communication between the business owner (and the customer) and the team is non-existent.
• The products take too long to get to the end customer.
• There is no method for adapting to changing business or customer priorities.
• A focus on lengthy, technical project and spec documentation is time-consuming and produces documentation that is difficult to utilize.
• QA and bug-testing are often rushed, so products are frequently released with many bugs.

Agile aims to address these negatives by:

• Giving the team a voice in making decisions
• Releasing the product frequently (usually every two weeks or once a month)
• Focusing on product features that are the most important instead of just features that have been approved, allowing for priorities – and requirements – to change
• Using short, easy-to-understand documentation (or no documentation at all)
• Performing frequent QA testing.

Agile encompasses many different methodologies (for example, extreme programming or DSDM), and all of them follow these basic concepts. But the version of agile that seems to be the most popular is Scrum. Scrum (the term comes from rugby) focuses on “sprints”, which are short work periods used to plan software releases. The length of a sprint may vary; I’ve usually worked on projects with 2-week sprints.

Scrum teams usually consist of the Scrummaster, who records the decisions the team makes and brokers issues between team members; the customer (often the business sponsor), developers, product and project managers, UX and visual designers, copywriters, and the QA team. At the beginning of each sprint, the team holds a meeting to prioritize the product features to be developed. The priorities are broken down into tasks (groups of related tasks are called “stories”), and these tasks must be completed within the sprint. Any product features that are not part of the sprint are relegated to the ‘backlog’, essentially a master list of all of the features that need to be developed and tested. The backlog may grow as new requirements and issues are added or discovered.

Each day the teams holds a “stand up”, a 15-minute check-in meeting. On some agile teams, members will actually stand up to ensure the meeting does not go over the time allotted. Members are asked to describe what they completed the day before, what they will be focused on today, and if there is anything blocking their work that the Scrummaster needs to address.

So how does a Scrum project affect a web editor?
In my experience, working on a Scrum project means an editor needs to work harder to ensure that editorial priorities are being met. One of the challenges of agile is that the focus on individual tasks and stories can cause the team to lose sight of the big picture of the overall user experience. Additionally, UX and content deliverables like wireframes and copy and are often rushed at the beginning of a sprint so that developers can start coding, QA can test, and the team can launch the updated product by the end of the sprint. So a careful review of user interactions, copy, and design elements often does not take place; the team is focused on functionality, not content or UX.

On the plus side, the fact that there are frequent releases means that when you do surface an issue, it can get resolved far more quickly than it would if you were working on a waterfall project and had to put your request into a long queue.

Here are some tips on how web editors can work within an agile environment:

• Focus on relationships. Agile development is built around communication. Team members are encouraged to work together directly instead of through documents, group meetings, or project managers. Get to know the developers and the QA team. You want them to come to you when they have questions about content rather than make guesses or ignore issues (which some people will do if they’re not encouraged to ask questions).
• Go to the standups. Sometimes project managers will go as proxies for their team, or certain team members will sit out sprints if they don’t have a specific task assigned to them. But make sure you attend the sprint planning meeting and as many standups as you can so you can advocate for the product features from an editorial point of view. Inevitably, questions will arise as developers work on new features, and if you’re involved, you can help ensure that the end user and your editorial vision are represented. You can also help steer the team away from solutions that stray from your content strategy, necessitate an inordinate amount of explanatory or directional copy, or don’t align with your brand.
• Train the QA team on content and style. You can’t expect your QA team to be proofreading; their focus is on testing functionality across platforms and browsers. But take the time to give your QA team some background on style guides, design standards, and content requirements. This will increase the possibility that they will help you catch inconsistencies. And, if you’re building relationships as noted in #1, the QA team will be comfortable coming to you with questions.
• Scour the backlog before the end of every sprint. Revisit end-to-end functionality – for example, a sign-on process or a site search.  Perform every step to make sure that the interactions are intuitive and consistent. Review your product with a focus on the user experience and on your business objectives, annual goals, editorial calendar, etc. This will help you determine what the team should focus on in the upcoming sprint, and you want to go to the next sprint planning meeting with these priorities already in hand, because work will begin immediately. Also remember that when reviewing the backlog, changing priorities might mean tasks should be removed from the backlog and replaced with new ones.
• Volunteer to test whenever possible, including on launch night. Unexpected things can happen during testing, and you want to be there to help advocate for the best solution.
• Master the bug tracking system. Many content and marketing people will avoid bug-tracking; it’s not the most exciting activity, and some see it as the QA team’s job. But as an editor, you’re already trained to look out for inconsistencies and imperfections. Ask for access to your QA team’s bug tracker if you don’t already have it, and record any bugs you find. That way you can ensure that any editorial problems are tracked and assigned to the right team members for resolution.

Agile can be daunting when you’re accustomed to traditional software development. But be open to its positive attributes, and you’ll find opportunities to educate your team on why editorial review and high-quality content is important for the products you all care about.

Redesign: Staging and Mapping Your Way to Success

By Cathy Hodson

You have a huge company website, and you have a matter of weeks to move content from your current site to your new site. How do you get a handle on how to move your content and figure out all the logistics involved? If your website has more than a hundred or so pages, or even thousands of pages, with all the associated documents and images, how do you get organized enough to know where your content is currently and how to get it to where it will be going on the new site?

By staging and mapping your content.

Staging your content
Staging is really prioritizing. What do you absolutely have to have on your new site when it launches? This is your first stage of content to be moved, before the launch, and the highest priority.

The second stage is the next level of content that – yes, it would be nice to have it on the site when you launch, but if it’s not, it will be the first content to go up after the launch.

The third stage is the final stage of content to be moved. Usually this consists of back issues of publications or content that could be considered “filling in” – background information, links to other resources, more of what you already have up, the finer details that fill in and embellish on what is already there.

What is mission-critical content? Mission critical defined: your business will suffer and your staff will have to scramble (in a bad way) to help your customers or members if this content is not on your website when you launch.

The actual timeline for all three stages depends on how quickly you need to have everything out of your current/old website. Usually all three stages should take about nine months to one year. To have all your content moved within six months of launch is a good benchmark.

Mapping your content
Once you have your content prioritized, you need to map it. Where does it reside on your site now? Where will it be moving to – most redesigned sites have also reorganized. So the content that might be listed under “Professional Development” on your current site might be split up among 2 or 3 different sections on your new site – Education, Continuing Education, Meetings. Somehow you have to note this for  someone who might not have detailed knowledge of your site (such as a temporary worker or consultant)  – where they would find the original content and where they need to put it on the new site.

The first website redesign I was a part of, the consultant that was building the website gave me a spreadsheet to use to map this process. It had columns for the new site location, the current site location, the status of the content (“testing,” “intro done”), a place for information about the content (such as “content needed” or “6 files, public side”), comments (“under construction” “is this the same as federal section on public side?”), and any changes (“name of section changed from X to Y”), and even a showing of which page(s) on the site link to each page or document listed. You can and should adjust the structure of your mapping document to whatever makes sense to you and your team. Is it better to list your content by the structure of the new site, or the structure from your current site? Up to you. Ask the people who will be moving the content which would make more sense to them? Or make an executive decision and decide for yourself which makes more sense.

Links
Something else that is helpful for content movers, especially if they are not part of your company’s staff, is to print out the pages on the current site, and mark up the page with notations for each of the links found on that page. Does this link go to a page on the same website (internal) or does it point to another company’s website (external site)? The internal site’s links may change, and that should  be noted – either on the page you printed or in the mapping document. If the page being linked to is from another department or division, and perhaps they have prioritized that page to be added at a different stage than when your page is going up, that should also be noted so the link can be added when the other department’s page goes up.

If it is an external site link – does it still work or does it need to be updated? If it no longer exists (or can’t be found), do you have instructions in place on what the content mover should do? Remove the link entirely, replace it with something else, or just leave it as is?

Once the plans for the staging and mapping have been completed, it gives you and your team parameters and guidelines for moving the content.

Content management systems
If you are keeping the same content management system, there may not be as much to do with mapping, prioritizing or moving content. It may be a matter of simply moving files across your system, adapting your content to a new page layout, or reclassifying the content. If you haven’t been using a content management system, but will be using one with the new website, you may pretty much have to reconstruct your pages – reformatting, linking to where new pages are, updating headline and other codes. You will have to do the same if you are changing content management systems.

Other considerations
Perhaps your URLs will change also. This is something that can be noted in the mapping document. A change of URL can be problematic – internally, for the sites that link to you, and for any links you publish on stationery or in publications – either those you print yourself or publications you submit materials to for articles or ads. Business cards may need to be updated, as well as signatures in email.

Any specialized domain names that point to deeper areas of your site may have to be repointed to the new location. For instance, our foundation has its own domain name, but it forwards to a deeper page within our association’s website. That location changed when we redesigned in 2011, and the DNS (domain name service) had to be updated to forward to the new location.

A successful redesign depends implicitly on how organized your team is, how much forethought and planning goes into the moving and launching processes, and nailing down the details. If you have never been part of a redesign before, choose your consultant carefully. You should hire a company that can walk you through the process and support you from both a development and an editorial standpoint. This is paramount to the success of the redesign. A redesign for a large website can take anywhere from one to three or four years, depending on how big your website is, what has to be done – a major overhaul of systems and the website, a simple reorganization and facelift, or anything in between.

Plan, prioritize and map. Iron out the details and make sure everyone understands what needs to be accomplished, when it needs to be accomplished by, and what the ramifications and consequences are if deadlines and project milestones are not met.