This guidance helps you determine the process for developing a new widget. A widget is a small bit of code that your readers can add to their own websites. When added to a site, this code displays EERE's content on their website. EERE encourages programs to create widgets.

When to Build a Widget

Depending on Web users to come to us to find your information is not the most efficient way to promote your content. Widgets are content that your visitors can put on their own websites. If you have content compelling enough that other people will want to

Before designing a widget, you need to think about what will be interesting to a given audience or audiences who will actually use your widget. Ask yourself some of the basic questions:

  • What is my intended audience or audiences for this widget?
  • What is my intended audience or audiences who will adopt the widget on their sites?
  • How do I facilitate use and adoption of the widget?
  • What resources can my program bring, and where do I need help from Communications in terms of its promotion?
  • How will I measure success?

Remember that the office that develops a widget is responsible for keeping it up to date—especially the data that's used in them. Be sure to identify what data you will use and decide how easy it will be to maintain a widget with this data.

Getting Approval for your Widget Concept

Once your office has decided to create a widget, development can be very fast. Launching your widget may only require two meetings with the Web Governance Team (WGT): an initial presentation meeting and a request to send the widget live.

However, offices are not allowed to implement or distribute widgets without explicit WGT approval.

You can schedule a meeting with the Web Governance Team as soon as you have a concept you wish to develop into a widget. Contact the Web Governance Team Facilitator to attend a meeting.

Wireframes or mockups are not necessary for the kickoff meeting, but are preferable. Other images or concept layouts are also acceptable if they provide sufficient information on the general approach.

During this meeting, please tell the WGT what platform you want to design your widget in. Our standard platform for widgets is FLITE. EERE supports and prefers this platform. The office will have to provide a full and reasonable justification for using any other platform.

Designing Your Widget

When creating your widget, follow the guidelines explained in the Widget Style Guide. All EERE widgets should follow this style. If you feel that your widget needs to be in a different template, please tell the WGT.

Coding Your Widgets in Flite

You will need to have an account in Flite to develop a widget. Most widgets are complicated enough that they will need a Web developer—and often, also a designer—to create the widget.

Have your Web developer contact mobiletools@ee.doe.gov to request an account. After you have an account, follow these steps to create your widget:

  1. Login to Flite.com with your individual account.
  2. Make a new widget.
  3. Drag it to your "Dev/Staging" folder for your Team. Only you and your team will have edit/view permissions for this widget.
  4. Test the widget.
  5. Get approval from the Web Governance Team to go live.
  6. Move your widget from the "Dev/Staging" folder, and move it under the correct folder(s) in the Production Widgets folder.
  7. Embed and distribute your widget embed code.

When creating your widget, remember that:

  • Moving your widgets to a folder does not in any way affect the way the public sees your widget. Moving it to a "Dev/Staging" folder does not take it offline. If your developers or the public have the embed code, it will be available for them to use.
  • If you want other EERE Flite.com users to be able to view your widget, you'll need to add it somewhere under the Production Widgets folder. We encourage you to move your finished widgets there.
  • Questions and support for Flite.com hosting should be referred to Flite.com support staff.

Sending a Widget Live

Before the widget goes live, the program should return to the WGT for final approval. Additionally, all widgets should go through a Technical QA to ensure that they meet EERE's technical requirements for websites, such as Section 508 compliance.

After your widget goes live, you should return to the WGT once every 3-6 months to review how the widget is performing. If the widget has performed up to expectations, the team can choose to make the decision as to whether to recreate it as a mobile application.

Promoting Your Widget

Before the program completes the widget construction, the program team is strongly encouraged to seek advice on its promotion plan with EERE's Communications Team. A sample plan might include one or more of the following approaches:

  • Sending out a Progress Alert
  • Announcing the widget on the EERE home page rotating news box
  • Creating an item for the EERE Facebook Wall or other such prominent temporary placement
  • Emailing select stakeholders with a request to amplify the message or adopt the widget
  • Calling select stakeholders to pitch the widget

Developing Mobile Applications from Widgets

Not every widget will, or should, necessarily become a mobile application. Before you decide to use the content in your widget for an application, consider some methods for success. Here are examples of criteria that can be used to determine success:

  • Number of installs on other websites
  • Reader responses to your widget. This includes positive and negative feedback from users or direct request from consumers for an application.
  • "Currency" of content. For example, will your information still in demand after 3-6 months?

A widget that is performing well in these ways may be a candidate for a mobile application.

Best Practices

Following these best practices can result in a higher-quality widget.

  • Remember the widget isn't a full website. Build lightweight, clean HTML and CSS for best the results.
  • Combine multiple CSS files into one if possible. In-HTML CSS may be used for small (< 100 lines) of CSS, and reduces the browser requests. This increases your widget's loading speed.
  • You can use CSS3 to improve the user interface and save time if it is acceptable for older browsers to have downgraded features.
  • If time and developer knowledge allows, consider building in HTML5. You may need HTML5SHIV to make this code work for versions of Internet Explorer lower than 9.
  • Use JavaScript for interactivity and functionality.
  • Consider using JavaScript frameworks such as jQuery when possible. Google makes these libraries available via their Content Delivery Network and chances are your visitors may already have the library in their browser cache.
  • Including a JavaScript framework for one line of interactivity may not make sense. Consider using straight JavaScript if there is little need for interactivity.
  • Plan for failure with AJAX requests. Your widget should gracefully degrade (i.e., be invisible to user) or produce a nice warning message if remote data is not available.
  • Use Web services when needed to update the application data. For example, the DSIRE widget searches for incentives based on a location provided by user.
  • Use any server-side components needed to support Web service requests, such as PHP, CFM, or ASP.
  • Don't use PHP, CFM, or ASP if HTML would work. Not doing so opens the possibility for security vulnerabilities and extra server load time.
  • To avoid blocking by common advertisement blocking software such as AdBlock Plus, use an HTML widget instead of a remote widget when it is possible to do so.
  • Uploading HTML to FLITE also increases how available your widget will be to other users.
  • Take advantage of tools such as YSlow and Page Speed to check your widget's load speed. Get rid of the GZIP (Deflate) and caching portions of the tip.
  • Remember to test in the EERE's supported browser suite.