Encouraging Standards-Based Web Development

1. Encouraging Standards-BasedWeb Development Presented by: Shan Osborn and Geoffrey Elliott, Pacific Northwest National Laboratory

2. The evolving technical landscape • Originally, only a handful of Laboratory staff developed web sites. • HTML initially designed as a markup language to structure and describe content separate from presentation. • Companies eager to establish a unique, branded web presence wanted more. • Netscape/Microsoft responded by creating browser-specific presentational elements which were adopted by the W3C. • Developers subverted existing markup elements for presentational benefit. 2

3. Identifying the problems • Web developers were not cultivating a basic knowledge of the fundamental principles of web site development. • Isolated work environment did not allow for knowledge sharing and teaming. • Level of quality and consistency diminished. 3

4. Identifying our goals • To provide a set of standards that would enable staff to team effectively and learn from one another. • To provide the information and tools staff need to implement the standards in their work. • To provide a process for reviewing work to ensure staff are learning and using the new tools and methods. 4

5. Things to consider • The standards must be flexible enough to adequately support diverse customer/project needs. • The standards must focus on forward compatibility while still allowing pages to degrade gracefully for older browsers. • Adhering to the standards must not dramatically increase the time or cost of development. • The structure of the standards must allow for future updates without extensive staff re-training. 5

6. Things to consider (contd) • The standards must provide the means to measure staff performance and career development progress. • The standards must not conflict with existing Laboratory publication and information release policies. 6

7. Research and Discoveries • First action was to investigate how other institutions attacked the problem. • Our situation is not unique! • Similar institutions tended to go for a pre-defined look/feel for all pages/sites developed throughout their organizations. • Our only realistic option was to aim for code compliance with W3C recommendations and Section 508 requirements. 7

8. Determining the standards • The standards were divided into categories to help make implementation/compliance easier for staff. For example: • Syntax • Display/Browser Support • Scripts • Directories & Files • Site Documentation 8

9. Requirements: Syntax • Pages must validate against the included document type definition. • Images must include appropriate alt text. • Special characters must be encoded (e.g., ™). 9

10. Requirements: Browser Support • Pages should be designed for current (and future) browsers that support: • HTML 4.01 • CSS Level 1 • DOM Level 1 • Pages must degrade gracefully for older browsers such as Netscape 4.x. • Pages must be useable in text browsers, PDAs, cell phones, etc. 10

11. Requirements: Scripts • Scripts should function in all supported browsers. • If a browser lacks the necessary functionality, provide documentation to the peer reviewer and be sure to alert users. • Scripts must be appropriately commented (e.g., function descriptions, explanations of complex code, reasons for disabled code. 11

12. Requirements: Directories & Files • File and directory names should be descriptive of their content. • File and directory names should not include uppercase or special characters. • Files should be organized in separate directories to avoid clutter (e.g., images should be stored in an “images” or “media” directory). 12

13. Requirements: Documentation • A text file named “siteinfo.txt” will contain the names of the developer(s), content owner(s), server locations, and site URLs. • Each site must contain a directory named “site-info”, which will contain the siteinfo.txt document, and a copy of the completed Peer Review Checklist. • Staff must document any deviations from the standards along with the reason for the deviation (e.g., budget/time constraints, outside customer requirements). 13

14. Promoting quality • A Peer Review Process was developed to • Help staff develop good, consistent coding practices • Share knowledge and techniques • Give management a tool for measuring staff performance. • Staff are eligible to become peer reviewers after consistently demonstrating knowledge and compliance with the standards and best practices over a period of time. 14

15. Stepping through the process • Templates for each level of a web site are prepared and submitted complete with production or dummy content. • Reviewer checks code for validation and compliance with department standards. • Templates are tested on various platforms and browsers for functionality and browser-specific issues. • Completed Peer Review Checklist is returned to the developer for resolution of any non-compliance issues. 15

16. Example: Peer Review Checklist 16

17. Tools of the trade • We established a department web site with • Links to both internal and external developer resources, e.g., • Lab policies and procedures • W3C specifications • Instructional resources • Lab writing style guide • Sample HTML Template • Sample Stylesheet • Web Development Standards Checklist • Contacts. 17

18. A little training never hurt • One-on-one training: • Project-specific informal reviews and instruction • General career-development instruction • Brown Bag Presentations • One-hour overviews of the standards and what they mean • Hands-on classes: • Creating standards-compliant web pages • Designing for accessibility • Developing with Cascading Style Sheets 18

19. Our Work Has Just Begun • These standards are not static; they will be reviewed and updated as necessary to incorporate new technologies and industry practices. • Staff are expected to keep abreast of current industry trends. (Who are we kidding?) 19

20. Questions? Comments? • Shan Osbornshan.osborn@pnl.gov • Geoff Elliottgeoff.elliott@pnl.gov 20