Webinar on Managing EERE Web Projects (Text Version)
Below is the text version of the webinar on Managing EERE Web Projects presented on January 30, 2008.
Sarah Kirchen: I just want to thank all of you for participating this afternoon. We see a lot of Web sites come through our review and approval process and it's just mindblowing how much activity is taking place in the EERE portfolio of Web sites. And the Web team—both the team at NREL, which is hosting this webinar this afternoon, and the team at EES—which manages sites that are in the RedDot content management system—work very hard to be responsive to your needs in developing and producing a Web site. And it helps tremendously if we are able to walk through all the guidelines with you at a webinar like this and direct you to our standards so we can eliminate some of the confusion and create greater efficiencies of process in meeting your Web site needs. So I asked Allison Casey who is our standards manager to put together this webinar this afternoon to explain our process and approvals review process. And with that Allison, I'll turn the meeting over to you.
Allison Casey: Thank you Sarah. I'd like to welcome you all and thank you for listening in today on this webinar on Web project management. As Sarah said, my name is Allison Casey, and I'm a communicator at the National Renewable Energy Lab, also known as NREL. I work closely with Sarah as the EERE Web Corporate Content Coordinator. Among other things, I do a lot of work on standards, corporate sites such as the EERE Consumer Guide, and special requests from the front office.
One quick note: We have almost 60 people on the phone today, so if you could all put your phones on mute to eliminate background noise and also remember not to your phone on hold if you step away. Putting your phone on hold subjects us all to your hold music and makes it really difficult for everybody to hear.
Moving on...Those of you who refer to the EERE standards often for your Web projects have probably noticed many changes on the site over the past year. In addition to breaking the standards into management, content, and technical sections, we have added many new tools, templates, and a blog.
Many of you have heard the statistics that there are roughly 125 sites and over 40,000 documents across the EERE Web site. These numbers continue to grow, and as they do, these processes and standards become even more important as we strive to offer a high-quality experience for EERE visitors.
I also want to emphasize that the standards are really for you. While I know that standards and process are not always the most scintillating of topics, these tools are meant to ease the management of your projects and ultimately help you continue to offer high quality sites and content to your site visitors.
In addition, many of our standards are actually directives from DOE or OMB, and we've tried to compile them all in one place and even include them directly in our templates so they require little to no effort for you to implement.
If at any time while you're using the standards, something is unclear or seems incorrect, or you're just not sure why that standard exists, please don't hesitate to contact any one of us listed on the contacts page of the standards site. Or, go ahead and post your question as a comment in the blog. We'll either reply there, or make a new post covering your question and open it to the community for discussion.
<Slide with Process page screen shot>
One of our most important pages on the standards site, for you as Web Managers, is the Process and Approvals page, which you can see here. You can find this page by clicking on Web Management Guidelines, and then choosing Process & Approvals. This page is the framework for our discussion today, and you may want to find the page and examine it more closely after the webinar is over.
<Slide with Phase Graphic>
As you can see, we've broken the Web process into five phases: Concept Development, Content, Production, Approvals & Publishing, and Maintenance.
Several of these phases are more important than others from the perspective of a Web manager, but I will touch on all of them today.
I also want to note that I will stop briefly after discussing each phase to address any questions you have offhand, and I'm always happy to address more in-depth questions via email or phone.
<Slide with Phase 1 bullets>
One of these important phases for Web managers is the very first one, which we refer to as concept development. This is the phase where you'll plan the project, and hopefully identify all of your needs and issues up front so the project can move smoothly through the rest of the phases.
The steps in the concept development phase include a kick-off meeting, writing a charter, outlining your content, drafting the architecture for your graphical mockups, and determining the URL. Finally, within each phase we've included a review and approval checkpoint, which will help you ensure that you've completed the necessary steps in that phase.
<Slide with Kick-off Meeting elements>
To start, we recommend holding a kick-off meeting with all members of your team, and ideally that includes any writers and developers that you already know will be working on the project. It's fine to do some up-front high-level planning before meeting with these folks, but keeping them in the loop throughout the entire process will help you better identify potential issues, and also estimate time and costs, and begin planning for anything that my be out of the ordinary, including things like applications and databases.
During this meeting, you'll want to discuss things like the overall purpose of the project, who your audience is, the scope, and the budget and schedule.
You'll also want to discuss roles and responsibilities for each team member, and any special technical needs that you envision at this early stage, including statistics, news and events, or as I mentioned before, applications or databases.
Finally, we'd like you to notify the Web Template Coordinator, who is Leslie Gardner here at NREL, of your intention to build a site as soon as possible to ensure that resources and staff will be available when you need them. The Template Coordinator will help you determine who is coding your site and can work with the developers pencil it into their schedules.
You may already know the answers to these questions before you hold this meeting, or your meeting may be more of a brainstorming session to determine the plan with the entire team. Either way, this meeting will allow you to put the entire team on the same page and will help with the more formal planning in the next step.
Which brings me to charters. Charters are especially important when managing EERE Web projects, so I'll cover them in considerable detail today.
<Slide with Charter bullets>
A project charter is not only a documented plan for a project, but it's also an agreement between the team and the DOE project lead. It's useful to revisit the charter throughout a project to either reinforce project decisions, or to revise the plan as necessary as the project evolves. We do have a template available for charters.
<Slide with Charter screenshot>
The charter template that you see here and that you'll find on the standards site is something new in the past year, and we have already found it incredibly useful in planning projects. You can always find the latest version of this template available for download on the Communication Standards site. We do sometimes make tweaks to the charter based on your feedback and new project needs, so if it's been awhile since you've written one, you might want to check it out and download the latest version.
Essentially, by writing a charter, we're asking that you put on paper the decisions you've made in your kick-off meeting. You may even want to consider printing out this template and basing that meeting on the questions addressed in the charter, essentially combining the two steps.
<Slide with Charter Elements>
I'd like to go over the elements of the charter in more detail, as the questions covered in the charter are very important to the planning process. You'll notice that the charter doesn't jump right into the nitty-gritty of the project, but we ask you to step back and consider the need and the project in a larger context.
The first section you'll find on the template is background. This is where you can provide any history or other background information that is important for people to keep in mind throughout the project.
We'd then like you to form your statement of need. This should be a brief statement that answers the simple question, "What problem are you trying to solve?"
This statement should help you define the scope of your project. Here we'd like you to think about what the project will encompass as far as content and deliverables, and also what will NOT be included in this go-round.
The section we've labeled "Overall Purpose" encourages you to think about your project and content in the broader context of the entire EERE Web site. We want you to think about: How does it fit in? How is it different from existing content on other EERE sites, as well as on the program site and any subsites you might already have?
If you find, after a bit of research, the answer to this question alone is, "It isn't different," this may be the point where you reconsider whether a new project is really necessary at all. And whether you continue with your new project or not, we always want you to consider ways that you can leverage the content that is already out there, again, both on your own sites and across EERE, and this is where you would do some of that planning.
<Slide with Charter Elements, cont.>
The Site Goals section allows you to consider the project within the context of the program or other existing Web site that you may already be working with. Here we'd like you to think about how the project furthers the mission of the program. We'd also like you to think about the result you're hoping for in completing the project, as well as your criteria for success and how you will measure that success.
These questions actually prove quite difficult in some cases, and we'd really like you to consider the answers beyond something as simple as, "Success means that the Web site will be up and running." Well, the lack of a Web site itself isn't the problem; what do you want the new Web site to accomplish?
Let's use the Consumer's Calculator site as an example. If you're not familiar with this site, this is a subsite that was built a couple of years ago and essentially includes links to all of the calculators within EERE that we know about.
In building that site, our desired result might be that consumers can more easily find and use all of EERE's calculator resources for calculating energy costs and savings. Our criteria for success would be fewer inquiries requesting calculators, as well as noticeable traffic to the calculator subsite. We will measure this success by comparing the number of requests before and after the site has been live, as well as through site statistics.
This is a fairly simplistic example, and EERE's statistics manager can help you better understand what you can learn from site statistics and other analysis tools, but you understand that we do want you to carefully think about what success means to you and how you will figure out if you have been successful.
<Slide with remaining Charter Elements, cont.>
We'd also like you to provide details about your audience. Who will use the information or tools you are putting out there, and further, what are their needs? What tasks might they complete by visiting your site, and how can you make it easy for them to complete those tasks?
The project description and deliverables section is where we'd like you to provide all of the details of what you plan to do. We especially ask you to note, again, whether any special applications or databases are needed, as well as which template you will use. And again, the Web Template Coordinator, Leslie Gardner, can help you make template decisions and also help mobilize the resources for applications and databases as soon as these are known requirements.
Also be sure to consider any assumptions. EERE's assumption is that all sites will go into the EERE template and the RedDot content management system, unless otherwise authorized by Sarah Kirchen—this is written right in the charter template. What are your assumptions for the project? For example, is there a drop-dead date for completion? Does completion depend on funding, or on another project being completed? You'll want to detail all of that information here so everybody knows what the assumptions are.
And finally, the charter template provides a table for you to plan your schedule and costs.
<Slide — Identify Content>
After all of this heavy-duty planning, you're finally ready to move onto the next step and start doing some of the pre-thinking about your content. In this step in Phase I, we'd like you to start taking inventory of the content you have and the content you'll need. Think about what topics must be covered on your site? You don't really need to write the content yet; just start planning what you need.
This is one area where your charter will come in handy, because you will have already answered questions about your audience. What content does that audience need to complete their tasks on your site? In this phase, the charter can still be iterative. If your content gathering reveals some new assumption or changes the scope of the project, go ahead and revisit the charter and update it accordingly.
<Slide — Draft Architecture>
When you have an idea of what your content will cover, you can start drafting the architecture and navigation labels on your site, which is the next step in phase I. In this step, you'll want to consult the standards site for the approved navigation labels and common terms used on EERE. You may also consider working with EERE's Information Architect, but since the content is not yet completed, it's best not to think of this as the final architecture, and as just a draft for use in mockups.
Also in this step, if your project is a subsite of a Program Web site, work with the DOE Project Lead and the Project Team to determine how that subsite will be integrated into the Program Web site.
<Slide — Mockups>
Based on your content outline and the draft architecture that you've just completed, you'll then develop graphical mockups of the home page, as well as several second-level pages and any subsite pages you might have. As I mentioned earlier, all sites will go into one of the approved EERE Templates and the RedDot Content Management System unless otherwise authorized. For new sites and redesigns, you'll want to work again with Leslie Gardner, the Web Template Coordinator, to determine which of EERE's templates is best for your site.
<Slide — URL>
Finally, determine the URL of any new sites. We've been working hard to update standards for domains this year, so that full page in the standards is something you'll want to review closely when determining your URL. The basic overview is this:
The majority of EERE Web sites should have an eere.energy.gov URL. All new EERE Web sites (including conference sites) must be located on EERE's servers, unless there is a specific reason justifying an alternative location. Again, Sarah Kirchen must approve any URL exceptions and requests for sites not located on EERE servers.
<Slide — Review and Approval Checkpoint>
This is a lot of information to digest, especially for just Phase I, but again, it is all outlined on the process and approvals page on the standards site. In each phase are several review and approval checkpoints that you should complete before moving onto the next phase. For phase 1, you'll want to ensure that you've submitted your charter to Sarah Kirchen, and you'll probably want to distribute this to your project team as well.
Also, submit the URL, mockups of key pages or applications, and if applicable, any requirements for special applications or reasons for moving into a different template to the DOE Project Lead and the Web Template Coordinator, who again is Leslie Gardner here at NREL. Leslie will then coordinate any necessary approvals with Sarah Kirchen.
That's a lot to take in, and this is definitely the most in-depth phase for project managers. Let's pause here and I'll take any questions on this first "concept development" phase. Does anybody have any questions I can answer right now.
Renee Nault: This is Renee Nault from Argonne. It appears to me that not all EERE sites are in RedDot. Several that are not in RedDot have the fixed with on the screen, which makes it easier to do with videos and other things. Are there any plans to redo the template so it's fixed width and not fluid?
Allison Casey: Well, I'm not a technical person but I do know that a lot of our sites have been moving to fixed width. I can't answer for you right now whether that's an across-the-board plan, but I can find out for you.
Leslie Gardner: What Michael and I have been talking about is the possibility of doing that the next time there's a redesign and building it into that, but nothing has been scoped out yet, Renee. But good question.
Renee Nault: Okay, thank you.
Leslie Gardner: It's good to know that's the way you want to go.
Renee Nault: Yeah, it really makes it a lot easier to work with.
Leslie Gardner: You guys have that tricky home page, huh.
Renee Nault: Oh yeah, we do.
Allison Casey: Anybody else have any questions right now? Okay.
<Slide — Phase 2 Content>
Finally, after all of your careful pre-planning, you're ready to move onto the meat of your site: the content. I will briefly cover the steps in this phase, but I also want to invite you to our next webinar, which will be held in March and will cover the new content standards in more detail. We'll let you know details of that webinar as it gets closer. For now, I invite you to familiarize yourself with the Web Content Guidelines on the Communication Standards site.
What I really want to emphasize in this phase is that content drives architecture! We recommend completing your content before you finalize your architecture. This process may be a shift for some of you, but completing your content first allows you to determine which content is really essential without trying to shoehorn it into a pre-determined architecture. While you can always have your draft architecture in mind as you work, keeping it fluid while creating your content will result in better final architecture and content. We've found this across our sites.
As I mentioned, we do have an entire section of content standards that are a good resource for Web writers, and these include a style guide and a content QA checklist that we encourage you to use to ensure that your own content meets EERE standards.
Just so you know, we consider FY08 to be a "year of awareness" for these content standards, but following them will be a requirement in FY09, so it's really best to familiarize yourself now as you have the opportunity.
The next step is to optimize your content for better search engine rankings. We have guidelines for optimization on the standards site, and the EERE Search Specialist can also provide help with this.
Next, select and format any charts, graphs, photos, PDFs, or Word documents that will be used in your center content. And of course, we have standards for formatting and linking to these items. Also be sure to indicate in your content where these elements will live on a page to make it easy for the developer to incorporate it.
Finally, develop the final architecture and navigation labels based on final content. We've found that by following this process of writing first and finalizing architecture last, the navigation changes almost 95% of the time, and almost always for the better. So we do think it's worth it to wait until the content is ready to complete this step.
<Slide — Review and Approval Checkpoint>
We have one checkpoint for phase II, which is to submit the final navigation labels to the Web Template Coordinator, who will again coordinate approval with Sarah Kirchen.
I'm going to pause again here, because we've gotten through Phase II. Does anyone have any questions on this second phase focusing on content?
Okay.
<Slide — Phase 3 — Production>
Once your content is ready, you're ready to move onto Phase III, which is the production of the site. As Web managers, many of the tasks in this phase will not fall to you, but it's important to understand what happens here and the management involved. Just your knowledge of the information available in the standards can be valuable to the production team, as you'll be able to guide them to these resources. There's a lot available on the standards site.
The first step is to create header and navigation graphics. The Web Template Coordinator can help you determine whether NREL, EES, or another contractor would create these graphics. If they don't already know about the standards, you might point the people tasked with this work toward the standards for graphics, which are linked here and will be available to you later.
The next step is to prepare your content for coding. If EES is coding your site, request their requirements prior to sending them content and graphics. I know that some people complete this step as they write, which is fine, but unless you feel very comfortable doing this, we recommend focusing on writing good content in the content phase and saving any remaining formatting for this production phase.
Finally, you're ready to code the site in the RedDot Content Management System. You should have determined with the Web Template Coordinator back in the planning phase whether NREL, EES, or another contractor would code the site, so you can now provide those developers with all of your content and graphics.
<Slide — Review and Approval Checkpoint>
There are two items for the Production checkpoint. The first is to perform a self-assessment on the coding using the QA Checklist if you yourself are coding the site, or just ensure that the coders are aware that this checklist is out there for them.
Next, if you have applications that are not hosted on the central EERE infrastructure, you must ensure that these applications undergo a security scan. You can find information about this requirement on the Web Applications and Databases page in the standards.
I also want to note that Michael Thomas is the point of contact for EES, so if you have any questions about EES's processes, you can speak with him. I'd like to open it up now to Michael if he has any additional comments, or to the group if there are any additional questions on this phase.
Michael Thomas: This is Michael Thomas, and thank you very much, Allison. A lot of people don't necessarily know what we do, but basically we support in two major ways. One is we provide program sites everything from training and support, installing videos, broken link checks, quality assurance, those types of things. We also do a lot of the formatting of PDFs that Allison talked about. We also manage the RedDot system. Everything from managing the RedDot system to make sure it's working correctly, doing any troubleshooting. We also manage the workflow and all of the user accounts and account approval process. So we have quite a lot of stuff going on, both at the RedDot management level, but we also support several Web sites that are in RedDot as well.
Allison Casey: Thanks, Michael. There are a lot of details in the production phase that we haven't necessarily included here, so you'll want to work closely with whoever is coding your site to find out exactly what needs to be done. Are there any questions on this phase?
<Slide — Phase 4 — Approval and Site Publishing>
Finally, we've reached the point for approvals and site publishing. When coding is completed, contact the Web Template Coordinator to schedule quality assessments, or QAs. The necessary QAs include technical QA; template QA; content QA, which should be completed by the content provider or writer; and search and optimization QA. These generally will take about 5 business days.
After QAs are complete, go back and make changes based on the results, and then go on to coordinate any remaining Pre Go-Live Tasks. These tasks include notifying the Web Template Coordinator of any necessary bookmark notices or redirects you might need if you have new or changed URLs, and scheduling a go-live date.
Finally, send the site for Program Review and make any final changes based on their feedback.
<Slide — Review and Approval Checkpoint>
There are several important checkpoints in this phase, including ensuring that all critical changes identified in the QAs have been made, obtaining review and approval from DOE reviewers, and finally working with Leslie to obtain approval from Sarah Kirchen for the site to go live. Once these steps are completed, you can finally go live with the site!
Once again, I'll stop here for questions on the Approval and Publishing phase. Any questions?
Okay.
<Slide — Phase 5 Maintenance>
After all that, we are not quite done! Maintenance is a very important component of Web site management. Maintenance of EERE sites includes keeping content current, doing analysis to further improve your site, and staying up-to-date with the latest standards.
<Slide — Maintenance Plan screen shot>
The first thing you should do, as soon as possible after a site goes live, is write a maintenance plan. Maintenance plans must be submitted for all sites and subsites. If you have a maintenance plan but have added new subsites or sections, after each project review and update the plan as needed to ensure that it includes these new areas and any new maintenance requirements you might have. Here you can see the template for maintenance plans, which is available for download on the standards site.
<Slide — Write a Maintenance Plan>
When you write a maintenance plan, consider content-based tasks and technical tasks that will keep your site up to date. Determine how often those tasks should be completed and who will be responsible for them. For example, you might say that news is updated on an as-needed basis, contacts are reviewed every month, link scans are performed every quarter, and technical reviews are conducted every year.
These are just a few of the tasks you might include on a maintenance plan, but every site varies in the type of maintenance it requires. The template has a few ideas you might consider for your own site, as well as an example of how you might these spread tasks throughout the year on especially large sites, so I encourage you to download the template and look at the ideas that are presented there.
<Slide — Consider Further Site Analysis>
We also encourage you to conduct further analysis on your site as you're able. Usability testing and content analysis are just some of the tools that can help you improve your sites. Usability testing can help you refine a site's information architecture and navigation, while content analysis can help you identify content gaps, duplication, and other areas for improvement. We have an example of a high-level content analysis on the standards site, and more will be conducted in the future.
Where able, EERE will perform these tasks at the corporate level and share the findings and lessons learned with the entire EERE Web community.
<Slide — Stay Informed>
Which is one reason it is so important that you stay informed.
We hope you'll subscribe to the standards listserv if you haven't already, and read and comment on the blog, which is a new pilot project for us and where we'll post about any new updates to the standards site and hold discussions about the standards and other issues that arise in the EERE Web world.
<Slide — Blog screen shot>
In the coming months, we will be increasing activity on the blog, which you can see here, and we hope all of you will join in the discussion.
Some of you may have listened in on the task analysis that Brian Lamb conducted on the EERE Consumer site a few weeks ago, and we'd like to continue the discussion on some of the issues Brian brought up.
Our plan is this: Each month, for the next six months or so, we will be posting a topic that came up in the analysis, along with our reflections and thoughts about how the topic might apply or present any opportunities on the EERE Web site.
While Brian's analysis focused on the Consumer site, we want to expand the lessons to the broader EERE Web community, and we'll invite your ideas for how they might apply on your site, or if they do at all. Our hope is that the discussion on the blog will spark ideas and inspire you to conduct your own analysis on your sites.
<Slide — Review and Approval Checkpoint>
So our final checkpoint for this final maintenance phase is to ensure that you've submitted a maintenance plan to both Sarah Kirchen and myself after you've completed your project.
<Slide — Resources>
We have a lot of resources here, and we'll post this presentation with links to all of the resources I mentioned today on the standards site so you can review them further. I hope you'll examine this process and the standards more closely and let us know if you have any questions. Thank you for listening in today, this is a lot of information.
Does anyone have any questions we can address now?
Leslie Gardner: This is Leslie. Sarah do you want to talk a little about maintenance? There's been a lot of attention on maintenance in the Federal Web Managers community, and DOE wants more governance of sites as it continues forward.
Sarah Kirchen: Hi this is Sarah. What Leslie is alluding to is the fact that federal Web sites are getting increasing scrutiny on the quality of information provided there and the ease of navigation for that information. The only way Web managers can stay on top of that is by regular routine, and rigorous maintenance tasks. For example, one of the sites that I am personally responsible for is the Communication Standards site. And I review that site once a year. I take sections of it and review them by quarter so I don't have to review all 300 pages of it between September 1 and September 30. And every time I do this, I come up with new insights and new questions about the way we have got something constructed.
So that is one of the reasons why maintenance is so important. And there is really no substitute for the maintenance review that is conducted either by the program manager or the program manager's most trusted web coordinator. It's not something that can be delegated for the latest person who has been added to your team, although it can be a good way to get to know your Web site. But there are many judgment calls that are involved in maintenance. And in that regard, one of the reasons we are so rigorous in regard to project charters and the issue of reviewing the material that is available on the EERE Web site to see what can be coordinated with your new approach or what is redundant, is because there is getting to be an increasing amount of redundancy on the Web site. We are finding that the search engine is getting clogged as a result of the redundancy of information available on say, for example, on solar energy that is not just in the STP web site but is also in other program web sites and the Consumer site. So we at the corporate level really review our content to make sure that we are streamlining things wherever possible and the same thing holds true for the programs as well.
Any other comments?
Harriet Foster: This is Harriet Foster, and we help out with the Biomass Web site. Will this presentation be emailed out?
Allison Casey: It's pretty big to email out, but we will post it on the standards site and maybe we'll also make a blog post about it and send it out on the listserv so everybody knows where they can find it.
Harriet Foster: Great, thank you.
Sarah Kirchen: Allison, I had one question about the QA reviews that you listed. There are approximately 4-5 areas that require QA. Can all of those be done at the same time?
Allison Casey: Yes.
Sarah Kirchen: So even if they do take a few days, your site can be QAed for technical as well as template aspects at the same time.
Allison Casey: Yeah, and that's assuming that everything is completed. There could always be caveats if something's going on with search or statistics that those might have to be completed later, but in general they can be completed at the same time.
Sarah Kirchen: Right, and that's something else I want to mention, because this QA process is pretty rigorous, but I think if you talk to your colleagues you'll find that the EERE Web team has a pretty good track record of providing you with QA results and also being able to negotiate the completion of those corrections, so if there is a pressing need to get a site live on a particular date and not all of the corrections can be made by that date, we're willing to work with you as long we get a committed schedule from you that makes it possible for you to take care of those corrections after the site has gone live.
Allison Casey: Right, thanks Sarah. Any other questions or topics you'd like to go over.
Jimmy Jones: This is Jimmy Jones at NREL. I have a question for Sarah about how the search engine gets clogged up. We know what you mean we have so many pages out there. Have we thought at all about what we're going to do about that? Are we going to take down archive pages or archive them in a special way? What is your thinking on that?
Sarah Kirchen: The first thinking on that is that Web managers need to get a greater grip through maintenance reviews about what is the content on their site, so that they can make distinctions about pages that still need to be there as opposed to pages that can be archived. For example, there is one program that has a peer review meeting on its site that goes back to about 2005. That's just an isolated example, but if there have not been any other peer review meetings since that time, then the question is raised, is this an important enough piece of information for it to still be on the Web site.
In this current year, we are in the process of getting you used to these new tools, the project charter, maintenance plan, the use of content guidelines and content analysis. So we haven't created any enforcement techniques, per se, for requiring people to archive their sites on a regular basis. In 2009, we will begin to actively encourage you to streamline your sites as much as possible and provide more guidance where we see techniques or processes that work.
Allison Casey: And you might also think about including that component into your project charters. When you're planning new projects, it's probably tough to sell a project to take down content, but you might include it as a component to look at what's there and budget both timewise and moneywise to take down anything that might be outdated.
Leslie Gardner: This is Leslie. The other thing we're doing at the corporate level is... Marsha completed a corporate-level content analysis and we have identified places across EERE where there is a lot of overlap and gaps and we hope this year to start talking to folks about helping us fix the problems we are aware of. But this is an ongoing activity.
Jimmy Jones: I just want to support that, because sometimes we have especially old archived pages, news, newsletters, etc. and they show up. If we could find a way to archive some of them and get them off the search engine, without, sometimes you don't want to take something down because a project is still informative to people, but you know, you search on solar and get a million responses. What good is that.
Sarah Kirchen: Right. Well this is the year of awareness, and your questions and your suggestions are music to our ears, Jimmy.
Erik Ness: Is there a way that we could get some of those older pages to not show up in the search engine as a short-term measure?
Leslie Gardner: Yes, you can work with Marsha on that.
Erik Ness: There might be a way just to exclude what's returned.
Allison Casey: Any other questions or comments?
Sarah Kirchen: I just want to thank everybody again for their participation, and I hope this has been informative for you. Allison, I especially want to thank you for the excellent presentation that you did today, and all the preparation work that you did to make this possible.
Allison Casey: Thank you, Sarah. Thank you everyone for coming, and again, feel free to contact me if you have any other questions.
41:30.
