+ All Categories
Home > Documents > DOE/EERE Web Standardization

DOE/EERE Web Standardization

Date post: 25-Jan-2016
Category:
Upload: wirt
View: 43 times
Download: 0 times
Share this document with a friend
Description:
DOE/EERE Web Standardization. Part 2: Implementation. Template Requirements. Maintain control of the formatting with CSS Make the site work in all resolutions with liquid design Make it accessible using relative font sizes Include a printable version - PowerPoint PPT Presentation
35
DOE/EERE Web Standardization Part 2: Implementation
Transcript
Page 1: DOE/EERE Web Standardization

DOE/EERE Web Standardization

Part 2: Implementation

Page 2: DOE/EERE Web Standardization

Template Requirements

• Maintain control of the formatting with CSS• Make the site work in all resolutions with liquid

design• Make it accessible using relative font sizes• Include a printable version• Implement as much modular code as possible• Stop duplication of effort and consolidate resources• Make it all work for multiple contractors/labs

Page 3: DOE/EERE Web Standardization

Formatting with Cascading Style Sheets

• Maintains integrity of EERE brand, standards

• Make global formatting changes to a site in just a few seconds

• Enables structure to be separated from presentation

Page 4: DOE/EERE Web Standardization

EERE Styles

• Created EERE styles for all standard elements including– Headings - H1, H2, etc.– Site utilities - search, site map, glossary– Dynamic content - news and events– Feature Boxes– Image Captions

Page 5: DOE/EERE Web Standardization

Liquid Design

• Liquid design allows a Web page to resize itself depending on the viewer's browser resolution.

• The Web site adapts itself to the available space the same way water takes the shape of the glass that it is in.

• http://www.eere.energy.gov/

Page 6: DOE/EERE Web Standardization

Why Liquid?

• Browser resolution stats showed a big divide in standard resolution– 1024 x 768 or higher - 57.84%– 800 x 600 or lower - 42.16%

• (Statmarket August 2003)

Page 7: DOE/EERE Web Standardization

Liquid Issues

• Choosing what resolution to optimize for– Optimized for 1024 X 768, works in 800 x 600– Chose to make it work best for the future instead

of going with lowest common denominator

Page 8: DOE/EERE Web Standardization

Liquid Issues

• Making the design look good in general– 3 columns, but with the ability to stretch text into two

columns– Prevent reading line length from getting too long– Header photos that worked in both low and high

resolution• http://www.eere.energy.gov/

Page 9: DOE/EERE Web Standardization

Liquid Issues

• Making the design look good in all browsers– Netscape 4, Netscape 7 for the PC

• DOE Clients still widely used Netscape 4

– IE 5, 5.5, and 6 for the PC– IE 5.1, 5.2 for the Mac

Page 10: DOE/EERE Web Standardization

Relative Font Sizing

• Allows users to increase the size of text in the browser

• Fixed font-sizes (points, pixels) cannot be made larger in IE

Page 11: DOE/EERE Web Standardization

Why Relative Font Sizing?

• Accessibility is a big deal on government sites– Population is aging– http://www.cnn.com/– http://www.eere.energy.gov/

Page 12: DOE/EERE Web Standardization

Which Relative Font Size to Go With?

• Basic choices were ems and percentages

• Netscape 4 and ems did not work properly at all

Page 13: DOE/EERE Web Standardization

How Percentages Work

• Font sizes on the site are set at a percentage of the parent element, in our case, the default font in the browser

• Default browser font size for most browsers is 16px

• Our standard paragraph font is 80% or 12.8 px

Page 14: DOE/EERE Web Standardization

Relative Font Size Issues• Need clean syntax, closing all block level elements

• Clean syntax is a best practice and will be required in future applications that utilize XML

Page 15: DOE/EERE Web Standardization

Relative Font Size Issues• Nested items get hosed

Page 16: DOE/EERE Web Standardization

Printable Version

• Allows a user to print a page without including headers and navigation or anything else that distracts from the content

• Information prints “portrait”

Page 17: DOE/EERE Web Standardization

Why a Printable Version?

• The Way it Was – Pre-liquid standard was fixed-width design of 750 pixels

– Allowed us to optimize design for 800 x 600 resolution

– Printed correctly in landscape only

– Decided in favor of online experience

Page 18: DOE/EERE Web Standardization

Doesn’t Liquid Solve the Problem?

• Liquid design inherently allows pages to collapse for the printer, if your fixed graphics and tables widths are small enough– Creating a design that would collapse to a portrait size

compromised the online experience– Adding a printable version allowed us to use a better

design, but still allow users to print the main content.

Page 19: DOE/EERE Web Standardization

Creating a Printable Version

• Create a duplicate version of every page and manually remove all non-printer friendly information such as headers, navigation, and features

• Write a style sheet for print – not workable in Netscape 4• Use scripting, in this case, SSI, to remove the non-printer

friendly stuff on the fly

Page 20: DOE/EERE Web Standardization

Implementing Modular Code – Server Side Includes• Common code such as headers and navigation are kept in a

separate files• SSI files are pulled into any HTML document that calls them• Can make global changes quickly

– program name changes, logo changes, tagline changes

• Enables easy implementation of "noindex" tags to keep navigation from being indexed by our internal search engine

Page 21: DOE/EERE Web Standardization

SSI Conditional Logic

• Use if/elseif,/else statements to tell the page what to display. – Show or not show menu choices

– Account for "on" and "off" states of navigation buttons depending on the page you are on

– "Printable Version"

Page 22: DOE/EERE Web Standardization

SSI Conditional Logic Sample Code

• Assign a variable to a page. On the "About" page add <!--#set var="about" value="1" --> to the top.

• On the "mission" page, in the "About" section add <!--#set var="aboutmenu" value="1" --> This indicates that the page uses the "About" menu, but is not the "About" page.

• Then, in your navigation “include” file, use code like the following page.

Page 23: DOE/EERE Web Standardization

SSI Conditional Logic Sample CodeCode<!--#if expr="$about" --><img

src="images/about_on.gif" alt="About the Program">

<!--#elif expr="$aboutmenu"--><a href="about.html"><img

src="images/about_on.gif" alt="About the Program"></a>

<!--#else --><a href="about.html"><img src="images/about_off.gif" alt="About the

Program"></a>

<!--#endif -->

         LogicIf you are on the about page - the "about" button in the top navigation should be "on" but not linked.

If you are on the "mission" page in the "about" section - the "about" button in the top navigation should be "on" and linked.

If you are on a page that has nothing to do with the "about" page or section, the "about" button in the top nav should be "off" and linked.

 End the conditional statement

Page 24: DOE/EERE Web Standardization

Coding EERE's Printable Version • Set a variable to tell the browser whether it is on the printable page or not.

– <!--#set var="VAR_printable" value="no" --><!--#if expr="($QUERY_STRING=/print/)" --><!--#set var="VAR_printable" value="yes" --><!--#endif -->

• If it is not the printable version, display all headers and navigation– <!-- exclude this content if printer version -->

<!--#if expr="($VAR_printable=/no/)" -->– Top Navigation Code…– Left navigation Code..– <!--#else -->

<!-- information to be included on printable page -->• If it is, don't display them.• Set up link to "flip the switch"

– <p class="small"><a href="<!--#echo var="DOCUMENT_NAME" -->?print">Printable Version</a></p>

Page 25: DOE/EERE Web Standardization

Stop Duplication of Efforts and Consolidate Resources

• Many subsites across the EERE site were duplicating news and events information– Same press release coded by different coders and posted

on several sites

• Cash and resource-poor subsites let content lapse– Frustrated by having to wait for an available coder – Limited budget

Page 26: DOE/EERE Web Standardization

Stop Duplication of Efforts and Consolidate Resources – The Solution• A central database for news and events

– Existing EERE news database for the corporate site• Home page news

• Technology portal pages news

– Other subsites also adding news and events information for their programs via a database

Page 27: DOE/EERE Web Standardization

Decentralized Content Contribution

• Empower all subsites to enter their own news through a Web interface

• Allow subsites to borrow from each other– Subsites can subscribe to DOE press releases and to news other

programs generate• They can choose whether these stories should be added automatically to their

sites (a totally hands off approach)• Or they can choose to be notified when new stories have been entered that

they can choose to add or not to their site

Page 28: DOE/EERE Web Standardization

Database Template Benefits

• Standardize the look of news and events– Same place, same experience on all sites

• Empower content providers to keep sites fresh

Page 29: DOE/EERE Web Standardization

Had to Work for all Contractors/Labs

• Chose HTML 4.01 transitional using a combination of CSS for visual style and tables to position content

• Still testing on Netscape 4

• Wanted to make it easy to use

Page 30: DOE/EERE Web Standardization

Had to Work for all Contractors/Labs

• Two choices for contractors/labs• NREL would code a few sample pages

• Let them wing it– Standards site as a guide

– Read me files

– Issue - Web developers don’t read standards sites!

Page 31: DOE/EERE Web Standardization

Did it Work?

• Many contractors/labs have used template – ANL, ORNL, and several private contractors

• When we coded a few sample pages it went very smoothly

• When we didn't they still figured it out

Page 32: DOE/EERE Web Standardization

Summary

• We faced a number of requirements when creating the EERE template including– A design that was flexible and accessible and that would work

for many different developers– One that would ease maintenance in the here and now, yet get

us ready for the future– And a design that would enable content providers to update

their own sites

Page 33: DOE/EERE Web Standardization

Template Benefits

• Enables Faster Development– Already have code to start with– Code is clean and standardized

• Pretested in our standard browser set• Tested in various resolutions• Validated against the W3C

Page 34: DOE/EERE Web Standardization

Template Benefits

• Eases Maintenance – All developers are using the same set of code

– Style sheets keep formatting standard and make updates fast and easy

– Use of Server Side Includes (SSI) consolidates common code into a few files which means less code to update

Page 35: DOE/EERE Web Standardization

Conclusions

• Technology is making it easier and cheaper to manage large sites by introducing standardization and modularity

• Even if you are not working on the enterprise level, you can use these same techniques to streamline production on smaller sites

• If you don't have the money for a commercial content management system you can still automate portions of your process and get yourself ready for the next phase


Recommended