Webinar on EERE Web Content Standards (Text Version)
Below is the text version of the EERE Content Standards Webinar, presented on March 26, 2008.
Conference Call Commentator: Excuse me. This is the conference call commentator. At this time the call is being recorded. If we have any objections, you may disconnect. Thank you, you may begin ma'am.
Allison Casey: Ok, thank you.
Drew: Hey guys, it's Drew.
Allison Casey: Hi Drew. Do we have Sarah with us yet?
Drew: Ah, I don't think so. I think she's calling in from home.
Allison Casey: Ok.
Joe Konrade: This is Joe Konrade.
Allison Casey: Hi Joe.
Joe Konrade: Hello Allison. Thank you for getting that to me. Sorry.
Allison Casey: No problem.
Joe Konrade: Had so many other things going on, I just—I had it on my calendar, but I just didn't have the finalized registration.
Allison Casey: Yeah, we had a lot of people sign up today.
Joe Konrade: Well, I had it on the calendar though.
Allison Casey: Well, we'll give Sarah a minute or two and hopefully she'll join us. I think she wants to say a few words to start.
Renee Nault: Allison, hi it's me Renee Nault from Argonne.
Allison Casey: Hi, Renee.
Renee Nault: I got <inaudible> and Else Tennessen with me.
Allison Casey: Great. Looks like Sarah is online now.
Michelle Mallory: Allison?
Allison Casey: Yeah.
Michelle Mallory: Let's see, Michelle Mallory, Rachel Sullivan, and Gail Warren, if you're keeping track.
Allison Casey: Do we have Sarah yet?
Susan: Susan just joined.
Allison Casey: Hi, Susan.
Janice Adkins: Hi. Janice Adkins just joined.
Allison Casey: Hi, Janice.
Connie: Hi, it's Connie.
Allison Casey: Hi, Connie.
Seema: Hi, this is Seema from the Biomass program
Allison Casey: Hi, Seema.
Seema: Hi.
Hanna: Hi this is Hanna from Blue Iceberg, in place of Richard Cacciato.
Janis Adkins: Also got Scott Shackleford and <inaudible> of my staff here.
Allison Casey: Ok.
Janis Adkins: We're all in one office.
John Lippert: This is John Lippert at EES, Allison.
Allison Casey: Hi, John.
Sarah Kirchen: Hi, this is Sarah Kirchen.
Allison Casey: Oh good, we've been waiting for you.
Sarah Kirchen: Oh, I'm sorry if I've kept you.
Allison Casey: Oh, not at all. People are still signing in so, we can get started whenever you'd like. I assume you want to say some words?
Sarah Kirchen: Well, all I want to say is that I'm glad people are participating in this conference. I know for many of you, you have been working on content, Web content, for many, many years, but others of you especially if you're in my position, being a DOE employee, a manager of a Web site, the structure for Web content is fairly new to you. And I think this presentation will be very helpful in helping you understand what your contractors are struggling with when they are repurposing content for the Web and we greatly appreciate the input that we get from our site owners about what the content needs to be, but don't be surprised when it comes back looking somewhat different from the way you gave it to contractors or lab personnel or other staffers because it's very important that it be configured for a Web page so that it's easy for our users to use. That's all I want to say.
Allison Casey: Ok. Great, thank you Sarah. I want to welcome everybody and thank you for listening in today on this Webinar on EERE's Web content standards. My name is Allison Casey and I'm a communicator at the National Renewable Energy Lab which is also known as NREL. I worked with Sarah on the content standards and also as the EERE Web corporate content coordinator. Just a quick reminder to please put your phones on mute to eliminate background noise and also remember to not put us on hold if you happen to step away from your phone. I'll give you the opportunity several times throughout the presentation to ask questions. So let's start.
<Slide — Outline of topics>
Ok, I want to briefly discuss the purpose of content standards and what they are and then I'll discuss the various elements of the standards including a sort of nitty-gritty requirements that apply to most every page and here we'll discuss the content QA checklist and then I'll go over the writing process, the EERE style guide and content maintenance.
<Slide — Purpose>
As we so often point out, EERE's Web site is growing by leaps and bounds and with more than 125 Web sites and over 43,000 documents on EERE, the Web team has worked really hard to develop a set of standards that can be applied to a full range of sites to provide visitors with a consistent and high quality experience when they visit EERE. And understandably the first standards were technical in nature. Once technical standards were in place, we turned to what we feel is actually the most important product of EERE's Web site, and the reason people visit us in the first place, and that is the content. The Web content needs certainly vary across EERE depending on the site's audiences and the tasks they need to complete. We thought it was important to acknowledge that writing for the Web is different than writing for print and standards provide a certain level of consistency in our content that make it easier for our visitors to use.
<Slide — What are content standards>
So what are content standards? Well, for the past couple of years, we've been educating ourselves on the best Web writing techniques and standards out there and we put together a short collection of the elements that we feel should be required across all the EERE. We've been learning from experts including Gerry McGovern, Jared Spool, Shel Holtz, The Neilson Norman Group, and also the federal government's Web content manager's forum and while all these experts and resources have been helpful to us, we've never really found one complete resource that meets all the needs of EERE's content, and if we knew of one, we would simply link to it. So we really found it instructive to think about the content needs for EERE used what we've learned from the experts and then base those standards on that education and our own needs. I want to note that the intent of these standards is not to limit your creativity or your ability to communicate those important messages and the information on your sites and we're really aren't trying to create more hoops for you to jump through. Our hope is that these guidelines will make it easier to understand, prepare, and maintain your Web site content while pursuing EERE's mission and helping the programs achieve their goals.
<Slide — Reaching the Communication Standards>
So to start, if you've never been to the EERE standards site, the URL is www.eere.energy.gov/communicationstandards and from the EERE homepage, the easiest way to reach the standards is to go to the Assistant Secretary's office Web site and from there click on communication standards, and you can kinda see that here.
<Slide — Screenshot of Content Standards>
You can find the EERE Web Content Guidelines on the communication standards site under its own section in the left navigation. I'll post this presentation on the standards site as well so you'll be able to get the links included in the PowerPoint.
<Slide — Content QA Checklist, Title Only>
I think that one of the best places to start when talking about standards is with the content QA checklist which is a tool that we've developed to help you quickly ensure that individual pages meet content standards. Now, as I mentioned earlier, the idea for requiring these elements isn't to make your writing prescriptive or to limit your creativity, and we hope that tools such as this checklist will actually streamline the process for you and introduce the elements that make it easier for visitors to use your content and keep them engaged on your site.
<Slide — Content QA Checklist topics>
There are eight items covered on this checklist including information architecture, section landing pages, and then each page as a whole, and then within that individual page elements including header text, introductory text, subheaders, the body of the content, links, and images.
<Slide — Content QA Checklist Screenshot>
So here you see what the content QA checklist looks like. I'm going to go to full screen here. OK. This checklist is available for download on the standards site and it's a short two page document that allows you to quickly check your own pages against these requirements to ensure that they're meeting standards. We encourage you to use this checklist as your writing to remind yourself of these elements and to double check after you've written a page that it meets standards.
<Slide — Page 2 of Content QA Checklist>
And here you see the second page of the checklist. The checklist is formatted so you can check up to eight pages on one document and as you see by doing the header of the word document you'll have access to edit this top row and you can then type in the filename or the titles of the pages you wish to check. An example is typed into this screenshot in blue. Since these titles are typed into the header, they'll show up on both pages of the checklist for you. How you actually use this checklist to indicate that the page meets your standards is up to you. You can use checkmarks, or writing yes or no, you might have notes to make in that right column. You can use this tool to review your own content or to provide feedback on content written by someone else. It's really for your own reference though. If there are other elements that are important in your own content, you might even consider adding them to the checklist that you use when you're checking your content.
Now, I'd like to go over the elements covered in this QA checklist in more detail.
<Slide — Elements of the Content QA Checklist, Link to Nav Labels Library>
The first item on this checklist is information architecture and here you see what you'll actually find when you use the checklist. Information architecture isn't really an element that can be checked on every page, but it is included on the checklist as a reminder that all navigation must be approved by Sarah Kirchen, the EERE Web site manager. A good place to start is the library of approved navigation labels, which you see here and you can find on the standards site.
<Slide — Screenshot of Library of Approved Navigation Labels>
In addition, while you're writing and checking your content, we want you to keep the big picture in mind and be sure that your content does not duplicate other content that already exists on the EERE; and if you were able to attend the project management Webinar in January, you'll remember that you initially planned to prevent duplicate content and take advantage of existing content when you're writing your project charters. And now obviously you can put these plans into action when you writing content. So we encourage you to leverage any existing content and link to related content on EERE as much as possible.
<Slide — Section Landing Pages>
The next item on the checklist is section landing pages. If you're not familiar with section landing pages, these are essentially the top level pages of a section of a site and they introduce at length the content that's below. The checklist shows that these pages should be short, concise, and easy to scan. It should make sense when found out of context, so if someone lands on the page through a search or from a link or bookmark, and the page should introduce the content within the section, and it should also link to all of the top levels of content within the section. As an example, let's look at the section landing page for the Web Content Guidelines.
<Slide — Screenshot of Content Guidelines Landing Page>
As you can see here, this page provides a very brief introduction to the content within the section as well links to other related sections. The main links on the page, however, lead to the content that exists within this entire section. In essence, this page sort of functions as a table of contents for the Web Content Guidelines and you'll note that the links on this page also appear in the left navigation. The content within the section is very briefly described under each link. You can see the descriptions of, like I mentioned to you, about one sentence. This is not a page that people really want to read in depth, but a page that they'll want to scan to get a sense of what's available to them. I'm gonna stop here and check in with you and see if there's any questions I can answer so far?
Any questions? OK, we'll move on then.
<Slide — Each Page As a Whole>
Well, we've pulled out section landing pages as its own section on the content QA checklist and in reality several of the elements there are important for any kind of page that you write, and this is where each page of the whole section comes in. If you're preparing and checking a regular page of content, ensure that this page is also short, concise, and easy to scan and that it makes sense when found out of context in case someone finds it through search, or links, or bookmarks. One of the most difficult aspects of Web writing is remembering how people use content on the Web. People tend not to read content so much as scan content and they can be quickly discouraged to delve into content that looks too long or complicated and this can lead them to hit the Back button before they even read your page. So if you have a lot of important content to present, what can you do to ensure people stick around and read your page?
<Slide — Page Elements>
This is actually where the rest of the elements in the checklist come in. Meeting these requirements can help you ensure that you meet the requirements that your page be short, concise, and easy to scan. And you can find further guidance about most of these pages on the standards page called Page Elements which you see here.
<Slide — Screenshot — Header>
So to start I want you to think about your page headers. The header is the large red text that describes the content on the entire page. You can see the header of the Web Content Guidelines page highlighted here.
<Slide — Headers>
Here we see what the checklist requires of a header. A header should uniquely and concisely describe exactly what a user will find on your page. You'll wanna make sure that you use keywords that are used in searches and help the page rank high in search results and also keywords that are important to users in your header. I want to elaborate on this briefly, because search optimization is something that permeates several of the checklist elements. Optimizing your content for search means taking steps, like identifying and using keywords, that ensure that both commercial search engines and EERE's internal search engines will find your content. As far as search goes, the header you write will also appear in search results so when you come with a header, think about whether its effective in that context. If you saw this header in a list of search results on, say, Google or the internal EERE search engine, would you know what you're getting before you click on it? Also, avoid using acronyms, abbreviations and ampersands in your headers. These elements can be confusing for users unfamiliar with them even if you think some acronyms are the most familiar in the world. Not everybody knows what they mean. A header should tell users exactly what they'll find on a page and if your page will help someone complete a task, let them know by writing a clear header which will subsequently be used in any links that go to your site. Also, don't be afraid to use longer headers to convey the content of a page. They don't need to be limited to just a couple of words. Strong headers will help ensure that the message your programs have conveyed on a page actually reaches that intended audience.
<Slide — Introductory Text>
Next on the checklist we have introductory text. This is the first text after the header and it's also important for ensuring that your page is found in searches. This text should describe the content on your page while using those important keywords in the first couple hundred characters of your page. Also in the intro text, avoid acronyms and abbreviations unless you first define them, and avoid using ampersands.
<Slide — Introductory Text Screenshot>
So as an example, here you see the intro text for the Page Elements page. You see that it's not long, but it describes what's exactly on the page and includes important keywords that would help anyone searching for information on what's covered on this page, which in this case is things like headers, subheaders, and introductory text.
<Slide — Subheaders>
So going back to the checklist, the next element covered is subheaders. The requirements for subheaders are very similar to those with headers and include using keywords not using acronyms and ampersands. But the most important thing about subheaders is that they're used at all. Remember that requirement that pages be concise and easy to scan? Well using subheaders to break up long blocks of text and describe sections or paragraphs on a page can help you accomplish just that.
<Slide — Subheaders Screenshot>
Here you again see the Page Elements page with the subheaders highlighted and a quick scan of this page will show anyone exactly what's covered. Descriptive subheaders help your readers find exactly what's on the page in one quick scan, but beyond that subheaders are extremely useful for people who have disabilities and who may be using a screen reader to access your content. Screen readers can actually scan your page as well and to accomplish this, users can set the screen readers to read back only the headers on the page and this gives them a sense of whether they want to read the entire page or not. You can imagine that these users especially want to be able to quickly find the information they need without having to listen to entire page.
<Slide — Body of Content>
The next section is the body of the content where you of course say whatever it is you need to say on the page. We again see that the checklist requires using keywords, avoiding acronyms and ampersands and spelling out the acronyms that you do use.
<Slide — Body of Content Screenshot>
Here again we see we have the requirements of the body of content be short, concise, and easy to scan. In this example from the EERE Consumer site, you can see some of the things that have been done to accomplish this, including using subheaders, keeping paragraphs short, and using bulleted lists.
<Slide - Links>
Moving on, links are obviously what makes the Web the Web. They connect documents to one another and good links are essential to good content. There is something of an art to writing good links, but there are several agreed upon characteristics of good links. Our two requirements for links are that visitors are notified when they are leaving EERE and that users are told where they're going.
<Slide — Links Talking Points>
To elaborate on this point a little bit, e-government standards actually require that users are notified when they are being linked to an external site. There is several ways to do this. We are actually looking into deploying a small graphic that will indicate when a link is external, but for now our standards say that the surrounding text needs to tell the users where they're headed, which means that this responsibility falls to people writing content. And as you can see here in this link, "See ENERGRY STAR's information on federal tax credits for energy efficiency." The surrounding content tells you that that link takes you to the ENERGY STAR's Web site. We also want you to avoid the phrase "Click here." It's always a tempting phrase to use and this phrase was used a lot in infancy of the Web, but when you think about it, it's really unnecessary and it really doesn't tell the user where they're going. Instead, try to link the part of the text that actually describes where the link leads and you can kind of see this in this last point where we show that links should be easy to use. Rather than linking long strings of text which kinda becomes hard to read and extinguish from one another, try techniques like putting your links in a bulleted list. And like you see here in these links about renewable energy information, you give visitors less to read and it's easier for them to scan and understand their options when you break it out like this.
<Slide — Images>
So, the last item on the content QA checklist is images. Images are indeed a content issue even though a graphic artist might prepare them for posting on the Web. One important section 508 requirement is that all images must have descriptive alt text. Alt text is a description of a photo that's included in the code of a site. The screen reader will read the alt text aloud so that the person, who can't see the image, can still gain an understanding of what's being displayed.
<Slide Showing Images with Alt Text>
To elaborate on that, here you see two images with their alt text and captions displayed beside them. The alt text is what appears in those yellow boxes when you mouse over an image and the purpose is actually not for someone who sees the mouse over to read the text, and if you've been frustrated in the past by that text disappearing too quickly, you should feel better now because you're not supposed to read it. The text is actually read aloud by a screen reader and should convey to the greatest extent possible what a sited person is seeing in the image. You'll notice in these examples that the alt text is simply descriptive while the captions include both information that both sighted and unsighted users would find useful. So last fiscal year, we had a Webinar covering accessibility requirements and techniques for writing alt text, and this presentation is available on the Standards site along with some other tips for writing good alt text. I encourage you check out those sections when you write your alt text. Also, you might consider checking out the photos in EERE Network News for some good examples of alt text. Kevin Eber's the editor of ENN, and I always find his alt text to be especially good and descriptive.
So that covers the full extent of the required elements for content and I hope you can see that it's actually pretty easy to integrate these requirements into your writing and then all these elements help you accomplish several things on your site. Good content will improve how your pages rank in search, it helps your visitors find your content and complete their tasks on your site, and it helps you also meet federal Web site requirements including those for section 508. And finally, good content will ultimately help the programs reach a larger audience and meet their business objectives. I hope you'll find that this QA checklist can be a useful tool for your own writing. So before we move on, can I address any questions about the information I've covered this far? Any questions so far?
Kristin: Hey, Allison?
Allison Casey: Yeah?
Kristin: It's Kristin.
Allison Casey: Hi!
Kristin: Hi. You know when you were talking about header text?
Allison Casey: Uh-huh.
Kristin: I wonder if you wanted to just talk a little bit about header text. And you were saying how header text can be longer so you might want to mention about left navs and the relationship.
Allison Casey: Ok. Yeah.
Kristin: How they don't have to be exactly the same.
Allison Casey: Yeah, left navs aren't always the same. If you have a really long header like say it says, "Ten reasons to insulate your attic for the winter;" something long like that. You might have a left navigation that says "Winter Attic Insulation" or "Attic Insulation," something shorter that still gets the point across and is using what's there, but the actual header is more descriptive so that header will come up in search and still provide the information. Does that answer your—
Kristin: Yeah, yeah.
Allison Casey: Great. Thanks Kristin. Anything else?
Lawrence: Yes, hi Allison, this is Lawrence Wiggins from EES.
Allison Casey: Hi, Lawrence.
Lawrence: Hi, how are you?
Allison Casey: Good, how are you?
Lawrence: To go back to the external links, for links that go to external sites, for content that has been written for a while, it may not be written in a way that was described in the example you gave. Could the users or could the writers use a URL that visually looks like www.the sitename.com as an alternative to writing out that whole "Visit this site page on this." Could they use that as an alternative to having to write out that whole example you used?
Allison Casey: That's not a really a recommended practice. Part of it I think is because of screen readers because screen readers will read out that entire URL if it's written like that. It also kind of clutters up a page. So where you can, if you're doing maintenance on a page and the page is old, and the links aren't written in a such a way, then I would say try to go back and correct those links. We're not saying you know we understand that all of these content standards aren't being deployed right now on older content. If you are maintaining you can go back and implement them where you can and certainly in new content, we want them to be followed. But I wouldn't recommend using a full URL as just a link.
Lawrence: Ok. Thank you.
John Lippert: Allison, this John Lippert, to follow up on what Lawrence just said.
Allison Casey: Uh-huh.
John Lippert: Especially like with NREL, there's an awful lot of things that might be NREL material that's not on the DOE server now so it's kind of hard even with the example that you gave that said, EPA's regulations or ENERGY STAR or something like that. I'm not even sure that all of those are necessarily on the EPA Web site that we may even have some here or you may even have some within your PDF's. It's kind of hard to distinguish just because you say the name of the program; they're not necessarily on that program's Web site. They may also be on the NREL server. They may be on the EERE server. We'll be very glad whenever you come up with an icon or something that's showing that you're going off the site because that's hardest, I think, standard to meet.
Allison Casey: Yeah, it is pretty difficult and we understand that. I mean that's partially, like you said, why we're looking into the icon. I think the answer, you know, there's no one right answer for any links; it's just kind of do it the best you can. If you're writing, try to indicate where somebody's going especially if they're very obviously heading off site. PDF's aren't quite as critical because people tend to navigate back anyway even though it is—if it is on a separate server and people follow links within the PDF they might be carried away from our site, but there's not a whole lot we can do to have one standard that fits all I guess.
John Lipburg: Sure, ok thanks.
Allison Casey: Any other questions?
Kristin: Hey Allison?
Allison Casey: Yeah.
Kristin: Hey, it's Kristin again. I was just thinking that the Consumer site links to a lot of other resources, and I think really does a good job of indicating what those other sites are in the right column so I just wanted to mention that.
Allison Casey: Yeah, on the Consumer site all of our external links are on the right column, like Kristin said, and that's actually managed through a database so all of the destination sites are indicated underneath each link. Whether the right column placement is the right place for them or not, whether users are actually finding them, is kind of up for debate, but a technique like that or just pulling out your external links in some way can also help you sort of easily define those sites without having to write a big long sentence about the link.
Anyone else? OK, so let's move on.
<Slide — Writing Process>
So now that we've gone over some of the required elements for content, I'd like to take a step back and think about the big picture of what we're writing. Any content we write will be part of a larger site, whether it's a program site or a corporate site, and those sites are part of the EERE Web site as a whole. To help keep this in mind, we developed a brief process for writing Web pages. And we recognize that everyone has their own writing process, but the things listed on the writing process page of the standards are considerations that we think everyone should keep in mind as you write.
<Slide — Writing Process Screenshot>
You can of course, find the writing process page on the standards site, as you can see here, and essentially we break it down into steps to complete before, during, and after writing.
<Slide — Before Writing>
Before writing we would like you to do some planning. Decide who the audience of your pages and think about the tasks that they will accomplish by visiting that page. Also consider whether there's any particular message related to your program or initiative or maybe even a technology that you need to convey on the page that you're writing. And finally, think about the scope of your page; what will it cover, what will not be included, and what content is out there already that you can link to. At this point it might be helpful to visit the project charter which again many of you heard about in our last Webinar. The charter should define the scope of a full project and the scope to find there can help you determine the scope of a page or a section of content.
<Slide — While Writing>
So once you've done this initial planning, obviously you can move on to your writing. While you're writing, refer back to the initial plan once in a while to ensure that the content you're creating still meets your objectives and is written for your intended audience. Also be sure that, and I'll cover this in more detail in a bit, but the style guide is another important tool for ensuring consistency in the EERE content along with the content QA checklist, which again you should keep handy while you're writing. By following the checklist, you'll also help ensure that you're optimizing your content for search and again that you do not duplicate any content that already exists on the EERE. Also try to add those links to other content when you can.
<Slide — After Writing>
And finally, after you've written a draft of a page, take a look at it again. Does it meet your objective and your audience's needs? Could they complete their tasks using this content? You might even want to run it by someone else and ask them if they can complete the task that you've identified for your audience or even hand them the checklist and have them check it over for you.
<Slide — Style Guide>
Now I'd briefly like to return to the EERE style guide. This is another tool that's been added as a standard in the last year and we now have a complete style guide for EERE Web content. When you come across questions of style when you write, always refer to the EERE style guide first. You can see the guide here.
<Slide — Style Guide Screenshot>
It's organized alphabetically by topics so you can either browse the list of topics and go directly to the topics you want or you can just browse the full text, and the full text is on one page so you could also print out this entire resource to keep at your desk.
<Slide — Style Guide points>
If your question is not answered by the style guide, we've also defined the hierarchy of resources as follows. Again refer to the EERE style guide first, the Associated Press Style Book from 2006 should be your next stop, and if that doesn't answer your questions, try the 11th edition of Merriam-Webster's Collegiate Dictionary for any issues that that resource can resolve, and finally if none of these address your style issues, try the 15th edition of the Chicago Manual of Style. If you have time, you might find it interesting to review the style guide in its entirety and take note of things that differ from your usual way of handling them. We certainly don't expect anyone to memorize all of the finer points of EERE's style. I actually keep the style guide bookmarked and when I'm writing I almost constantly just have it open. Even when I'm not deep in writing, I find that I refer to it almost daily, so it's actually a pretty good resource and a quick one at that right on the EERE Web site.
I also want to point out several elements that are commonly misused on EERE. The first is the use of ENERGY STAR. And on its first use on a page, ENERGY STAR should be in all caps and should be followed by a superscripted registered trademark symbol or the R with the circle around it, and on each subsequent use on a page it's acceptable to just use ENERGY STAR in all caps without the symbol. Another element is the use of the word Web, as in Web site or Web page, and everyone has their preference and we always have a big debate going on here about what's correct, but EERE style is to write these terms as two words with the word Web capitalized. Both of these items and a lot of others are covered in the style guide.
<Slide — Maintenance>
So finally as so many of our trainings ends these days, I'd like wrap up by discussing maintenance and we did just touch on maintenance plans during our last Webinar, and as we've said then every site requires a maintenance plan which details the content and elements of the site that will be maintained and when you plan to do that maintenance each year. Submitting these plans is a project management requirement, but actually initiating these tasks really falls to the content managers of every site.
<Slide — Maintenance points>
The content owners need to be aware of the content on your sites that needs to be updated on an as-needed basis, and this content includes contacts which is updated often on some sites, as well as news and events, organization charts, and things like funding announcements. Other content updates can be scheduled, including link fixes and content reviews and well link fixes do have a technical element, I want to emphasis broken links are really a content issue and the content owner should make the decisions about whether to remove broken links or whether to replace them with another link and what that link should be.
Content reviews are a more holistic look at the content on your site. What should stay, what should go, what is still relevant and can be kept, but needs to be updated or moved? What does statistics show, does anyone look at this page anymore? A good goal is to touch every page on your site at least once a year and if you have a large site, you might break up content reviews so that the site is reviewed in pieces through out the year. I want to stress also that removing old content is just as important as putting up new content. It can help improve search results and can help keep your Web sites stay relevant in the eyes of your users. Obviously you don't want to remove content that is still relevant just because it's old. They should review that old content periodically to make sure it still belongs on your site. You might even work this task into your project plans.
<Slide — Benefits of Content Standards>
Once again we've covered a lot today. I hope you're feeling like these standards are easy to implement and seeing how following them can help you accomplish various goals for your site. We think there are a lot of benefits to having and using these content standards.
<Slide — Benefits of Content Standards points>
First we think that having good content that you've thought out carefully makes it easier to maintain your site. Sloppiness does add up over time and cleaning up sloppy sites and pages can be a difficult process. Another benefit is improved search results. We all want our pages to show up high in search results and to be easy for people to find and a search engine doesn't make that happen, good content is what makes that happen. Good content also helps you achieve your program goals and ultimately it helps users find what they want and if they find what they want, they are more likely to return to your site.
<Slide — Summary>
So today we discussed the purpose of EERE content guidelines and the requirements for certain content elements and I hope you have an understanding of how the content QA checklist can help improve your content. We also went over some things to think about during the writing process, the EERE style guide, and considerations for maintaining content. I also want to add that these standards are evolving as we learn more about Web content and EERE's content needs so I hope you'll stay in touch and let us know what's working for you and what's not. We're always interested in your feedback on these standards and if you have any great success stories or before and after examples, also feel free to share those with us because we love hearing about them. And these content standards especially are here for your benefit and to help you meet your site and program goals.
<Slide — Resources>
Finally, I've collected some of the resources from the standard site and will post this presentation on the standard site so you'll have these links available to you. That about wraps it up, but does anyone have any questions I can address about the entire presentation?
Leslie: Allison, its Leslie. I have a comment.
Allison Casey: Uh-huh.
Leslie: When you talked about the writing process, you talked about referring back to the project charter and what I'm seeing a lot lately is a lot of onesie, twosie pages coming up that don't necessarily have charters. I just sort of wanted to make the note that the writing processes helpful even when it's a maintenance activity and not necessarily a full redesign or a full do site.
Allison Casey: Yes, that's true. A lot of these standards were sort of developed with kind of a larger project in mind, but they can certainly apply and sort of be scoped a little bit to maintenance activities.
Any other questions or comments?
Jimmy: Allison, this is Jimmy. I have a question, and this might be for Sarah Kirchen. You know on the old content, the content has been posted years ago and things have changed and maybe in a couple years, nobody has maintained it. Do we have any standard that says after a certain period of time, a certain amount of neglect let's say, that we can on a corporate basis just say that this content is no longer is meeting standards and can take it down?
Allison Casey: You know, we don't have any standard for what's too old. I think the content itself really needs to be reviewed because if there's something relevant there, even if it's not being maintained, maybe it needs pulled up to a higher level. But we were actually, some of us were discussing yesterday that we might want to think about developing some standards for removing—reviewing and removing old content. But there might be things on your own sites and it depends on how you use these items, things like old news or old conference sites, even old technical reports if you're sure that they're no longer relevant, maybe they can be taken down wholesale.
Jimmy: You know, related to that, you mentioned news and I don't know what other people do, but I wonder if you have a standard for the EERE news database for maintaining and checking old links. On the State sites, we typically leave the old—if it's in the EERE database, we don't kill those old broken links just because there's a lot new stories there and etc. If it's just a content page, we try to stay on top of that. I don't know if, well, I think that's what everybody else does, but I guess I'm not really sure and I just wanted to—wonder if here's the place to ask that question or at least put the question out there.
Allison Casey: Yeah, that is exactly what we do on the corporate level news site. We don't maintain those old links; it's just too big of a job. We are considering taking out some of the older stories from the search engine so they would still be available on the site for linking which happens a lot if there's a related story that you're writing now that it relates to an old story; you can still link back to that and the maintainers would still be able to find those stories. Taking them out of the search engine is something we're considering from beyond a certain point.
Jimmy: That would be a great idea.
Allison Casey: That actually just came up this week so we'll let you know what happens.
Any other questions or comments?
Leslie: The other thing, Allison, that we've talked about is that, this is a finer detail, but we know maintenance is hard for folks and it isn't really that fun. It's fun to put up a new site or do a redesign and maintenance, because it's not urgent and we don't have clients saying, "Go through and scrub your site," that that often gets neglected. So one thing to think about is as people are developing new sites is to really understand how much can I really realistically maintain this site and if I don't have time to really maintain it, then write it such that there doesn't have to be a lot of maintenance to a site. I think Jimmy knows probably more than anybody how dynamic sites are very involved in regard to maintenance. So something to think about as you guys are developing new content is really think about what you really can commit in regard to maintenance.
Allison Casey: I think that's a good point. There are a couple things to think about. Things like not using time references on your site or even using the word new or recent or including dates. If you know you're not going to touch those sites again or have the resources to touch those sites again, it will just look old sitting on your site. So that's a really good point.
Jimmy: Ya know since you mentioned my name and I apologize if I'm speaking up too much here, but you're absolutely right Leslie that ya know, maintenance is just unplanned. You know you think, "Oh, I'm just going to put this data up here," and you look back two months later and just looks terrible. And I think a bigger issue is that many of us would like to make our pages look as best they can, but when we explain to the client, "Boy, it's gonna take me 10, 15 hours to fix all this," and they say, "No way am I paying for you to do that." So I think you almost have to do your thinking for the client sometimes. What it is realistically going to take to keep some of these sites up. And thank you Leslie for recognizing that we have special challenges.
Leslie: It's true.
Allison Casey: Anything else?
Joe Konrade: Yeah, hi Allison this is Joe Konrade. I have a question on the—you talked about the handicap accessibility. Is there some kind of standard with that that according to the law that says we have to do it that way just for public access?
Allison Casey: Yeah, we do. Our sites are required by law to be accessible. Things like alt text on the images that I showed you that that's required. A lot of the 508 requirements—it's called section 508, the law—A lot of those are built into the template which is helpful on taking care of on the coding end and some of these content things like using subheaders, they're not necessarily required by law, but they are—it is always good to keep those users in mind because there are a lot of them out there and using these little techniques in our content makes it a lot easier for them.
Joe Konrade: OK. I just hadn't thought about it until you mentioned that and wanted to make sure we do that.
Allison Casey: Yep, and we always do accessibility QA checks too to make sure that it meets those standards.
Any other questions?
Drew: Allison, one thing that I'm thinking; this is Drew. Can we put some of these Webinars, like the presentations, I know they're made available on a couple of the drives. Is there any reason why we couldn't put them on the Web site itself?
Allison Casey: Yeah, actually the project management Webinar is available on the Web site. It's under project management guidelines or Web management guidelines and the audio is there and the full text is there and we've also been talking about making an entire section for training, so we'll put all of our training in one place. And right now that includes this Webinar, the content standards, the project management Webinar, the accessibility Webinar and then we'll also include some of those links that we've talked about off and on about from Webcontent.gov, Usability.gov, things like that so you can find them easily.
Drew: I think that would be great. I kinda knew the answer to that question already, but I wanted to get it out there in case there were other people that were sort of wondering.
Allison Casey: Yeah, thanks Drew. Thanks for bringing that up.
Drew: Sure.
Sarah Kirchen: This is Sarah. I just want to thank everybody for the questions that you've brought to our attention here because you are providing food for thought for future guidance to EERE project managers. For example, we have recently instituted a requirement for maintenance plans for sites, and we've recently instituted the project charters to make sure that sites when the go up match the needs of the organization and have the functionality that is required, but don't suffer from what we call "scope creep," where ya know at the 11th hour somebody comes in and says, "Oh, wouldn't it be great if we did all this in Flash," or something like that when it has not been previously planned as part of the project. And what I'm hearing you client reps and contractors suggesting is that we need to provide guidance to our EERE program people about segregating an element of the budget for maintenance purposes so that you have that fenced and you know that certain portion of the budget is going for maintenance and there doesn't need to be that quibbling over hours spent on maintenance as long as it is planned for. And you know we're trying to develop a system where as much as can be anticipated in the future can be planned for so that we are able to operate our Web site system as a smooth publishing operation and not as an emergency room.
Allison Casey: Right. Thanks Sarah, and I think a good thing to keep in mind is a phrase that Gerry McGovern actually uses: "We want to move away from being putter-uppers" and do this planning up front. It might feel like it takes more time in the front end, but it really pays off when you go back and again see the messy pages that have gone up on emergency basis.
Lawrence: Hi Allison this is Lawrence again. Have there been any standards established on adding video?
Allison Casey: Are video standards up?
Elizabeth: Not yet, they're almost up.
Allison Casey: Ok. Yeah, they're actually in process. We're right in the thick of them and I have Elizabeth here whose been working on them so they should be up I hope within the week actually and those will be under the technical standards. So there's a lot of information about Flash. And again something to keep in mind with audio and video is that they do need a text alternative and that is sort of the equivalent of the alt text for images. The text alternative is for people who aren't able to hear the audio.
Seema: Hi, this is Seema from the Biomass program. So text alternative, will there be a format for that, is that what she's working on right now?
Allison Casey: Well, we're working on some of the more technical standards. There are a couple of examples out there for the last Webinar because it was so long, I actually put the text alternative just in a word document. There are some examples out there of text alternatives as Web pages which I actually prefer and we sort of have a format that says "Text Version of"; I can't remember the exact phrasing—
Elizabeth: Actually, the video standards have a teeny-tiny little section on text standards. We were actually thinking about making a separate page just for how to write text versions for video. And it's pretty basic; you can have like the header of a text version will have the name of the video followed by "Text Version." If you include a link in the header text to the original video or the page the video is on and then you just include the text version in there. We have some examples of how to do that, but so far we don't have anything set in stone for like how to format the actual text version. So we do have some guidelines for the headers and the intro text.
Allison Casey: And we'll let everyone know over the listserv when those video standards are up. And beyond the text version, I also want to point out that the preferred way to actually do text versions of video especially is to do synchronized captioning and we do have that capability, and I think we also have some examples out there of what that looks like when we put the synchronized captions along with video. It's pretty slick actually.
Sarah Kirchen: And, this is Sarah again. I just want to add that one thing we are currently working on is establishing a transcription contract through NREL. We are doing this at the corporate level, but if anyone needs transcription services in the future, we'll figure out a way that you can use this transcription service rather than have to go find your own transcriber.
Allison Casey: Right, and when you get those transcriptions, they do tend to need a little bit of editing before you post them.
Sarah Kirchen: Exactly, that's another thing to just keep in mind for your program managers. When you get your transcription back from the service, it takes another four hours or so to take a look at the actual transcription to make sure that names are spelled correctly and all of the wordage that is unique to us is taken care of before that goes up.
Allison Casey: Right, great.
Joe Konrade: Yeah, this is Joe Konrade. For FEMP we did a couple of the information videos on our Energy Savings Contracts and Utility Contracts and they look pretty good and you might want to take a look on our Web site.
Allison Casey: I think we might have actually linked to you from the standards, so you guys are our example right now I think.
Joe Konrade: Yeah, actually if you really have a really neat project, what we did is we divided it up into five or six different sections about three or four minute blurbs like they do on CNN and different groups like that, and it kinda breaks down the whole project and gives everybody a kinda like here's how the project started and here's where we went, how we did these things and here's the results of it. It has interviews and really works out really good on that.
Allison Casey: Good. Thanks, Joe.
Anything else we want to address? We have about 5 minutes left.
Ok, I'm hearing chirping. So I want to just thank everybody again for attending and feel free to contact me if you have any questions and again we'll get this up on the standards site so you can review it again. And again let me know if you have any questions and thanks again for coming.
Sarah Kirchen: Thank you Allison.
[End of Audio]
