1 / 20

Encouraging Standards-Based Web Development

Encouraging Standards-Based Web Development. Presented by: Shan Osborn and Geoffrey Elliott, Pacific Northwest National Laboratory. The evolving technical landscape. Originally, only a handful of Laboratory staff developed web sites.

PamelaLan
Download Presentation

Encouraging Standards-Based Web Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related