Web
Standards for OPO Development
(Version 6.0 - Changes since 5.0 are marked as such: New Removed)
1. Site Management
1.1 Web Site Conventions
1.2 Site Structure/File Naming
1.3 Production Process
1.4 Site Managers
2. HTML Standards
2.1 Browser/OS Targets
2.2 OS Targets
2.2 Bandwidth Targets
2.3 Screen Targets
2.4 CSS/Layout Targets
2.5 Page Printing Targets
2.6 Other
3. Programming
3.1 Javascript
3.2 Java
3.3 Shockwave/Flash
3.4 CGI Coding
3.5 PHP Coding
4. Graphics
5. Testing Suite
- All development work for servers on OPOSITE a production site (OPOSITE or STEEL) shall be done on FORGE, not on OPOSITE the production site itself.
- Every web site on a production site OPOSITE will have a 'dev' version of itself on FORGE (ex. hubble vs. hubbledev).
- Web sites that reside on INGOT can/should be directly edited.
- Each web site has it's own requirements for possible copyright footers, and you should contact the Site Manager for each site you need to know this information for.
- Any Web Server configuration issues should be directed to the OPO Web Server Administrator.
- The current OPO Web Server Administrator is Eli White (ewhite@stsci.edu)
1.2 Site Structure/File Naming
- If you are making a new module/area, simply create the new directory that it will exist in and begin to work there. As this is a 'new' area, there will be no naming problems.
- If you need to make a change to an existing file on a production site OPOSITE, then you must may directly edit that file on FORGE (the 'dev' site) to make your changes.
- In the case that you are performing work, such as a FAR future module, whose work could impact the current site while other changes are happening, this it is permissible to completely copy a whole directory over and name it: 'directoryname-dev' and to do all work in that directory.
- If you are working on a website that has an automatic footer added (such as a copyright statement), and you have an HTML page in which you do not want this statement to appear (a pop-up window, a navigation frame, etc.) then make sure the the filename ends with: _nf.html (which stands for: No Footer). Any file ending in this manner will not have the footer added to it.
- If you use any kind of server-side includes (such as virtual includes of a file within a web page), the file must be saved with a .shtml extension on it. Also note that the automatic footer will currently not be included on these files, and must be dealt with, although the server CAN be configured to put the footer on all files in the future if so desired.
- All filenames should NOT have any upper-case letters
- Safe characters to use in filenames are: all letters, all digits, '_' (underscore), '-' (dash), and '.' (period), DO NOT use any other symbols (such as &'s or spaces).
- In general, any module should be self contained within it's own directory, and with a directory named: 'graphics' underneath of it that holds all related graphics. Any part of the module that is deemed large enough (such as a very long detailed java applet) may be given their own directory, made in similar fashion.
- Any server side includes should be placed within an 'includes' directory at the highest level at which the include will be used.
- Most OPO servers have the ability to execute PHP server side scripting. PHP files need to be saved with a .phtml or a .php extension to execute properly (.php is preferred as Dreamweaver understands it better). Saving a file with a .phps extension will cause it's source to be color-coded and displayed.
- When web pages are ready to be moved to the from a development server to a production site (OPOSITE), then the project chief for that module will need to contact that site's Site Manager. When doing this you will need to provide a COMPLETE list of all files (HTML, graphics, etc) that need to be moved over, or at least the directory names of any directory that needs moved in its entirity.
- The project chief & Site Manager will together arrange for the web pages to be run through the test & verification process.
- Only the Site Manager for a website, or their appointed designee, should move files from the development server, to the live server.
- The Site Managers for each web site are in charge of knowing all that happens on that site, and knowing the configuration details for their site.
- Before any work is done on a site, the Site Manager should know about it, and give any details that are needed.
- The current Site Managers are:
- oposite.stsci.edu - Kelly Williamson (kellys@stsci.edu)
- amazing-space.stsci.edu - Jonathan Eisenhamer (eisenham@stsci.edu)
- hubblesite.org - Eli White (ewhite@stsci.edu)
- sites.stsci.edu - Stratis Kakadelis (stratis@stsci.edu)
- newsmedia.stsci.edu - Stratis Kakadelis (stratis@stsci.edu)
- outreachoffice.stsci.edu - Stratis Kakadelis (stratis@stsci.edu)
- origins.stsci.edu - Jonathan Eisenhamer (eisenham@stsci.edu) Kevin D'Augustine (daugust@stsci.edu)
- ideas.stsci.edu - Jonathan Eisenhamer (eisenham@stsci.edu) Kevin D'Augustine (daugust@stsci.edu)
- oss-ecosystem.stsci.edu - Jonathan Eisenhamer (eisenham@stsci.edu) Kevin D'Augustine (daugust@stsci.edu)
- bboard.stsci.edu - Eli White (ewhite@stsci.edu)
- cycle-epo.stsci.edu - Jonathan Eisenhamer (eisenham@stsci.edu) Kevin D'Augustine (daugust@stsci.edu)
- nm-private.stsci.edu - Zolt Levay (levay@stsci.edu)
- hstexhibit.stsci.edu - Eli White (ewhite@stsci.edu)
- oops.stsci.edu - Eli White (ewhite@stsci.edu)
- oss.stsci.edu - Jonathan Eisenhamer (eisenham@stsci.edu) Kevin D'Augustine (daugust@stsci.edu)
- informal-sci.stsci.edu - Jonathan Eisenhamer (eisenham@stsci.edu)
- nextgen.stsci.edu - Eli White (ewhite@stsci.edu)
(OPO evaluates it's standards based upon specific 'browser' version usage. The definition of a specific browser being one that is substantially different than another. This can mean the same browser on a different OS (such as IE, which is vastly different on PC vs. Mac), or a single browser might supported on all OS's because it behaves the same on all (such as Mozilla). The current method of determining what we support, is a human process of looking at multiple factors of usage. First of all, we try to support the 90th or higher percentage of browsers as possible. However, we also recognize that at times this may not be feasible. Therefore we look at the specific browser usage, and tend to definately support any browser with around 5% usage or more, as they are being used significantly enough that they cannot be ignored. Beyond that, we look at lesser used browsers as such. We will consider any browser at around 1-2% usage, if it has shown around that level of usage for the last 3 months of statistics, and is 'up and coming'. We will consider also supporting browsers with less than that usage, if it is known/expected that they will soon be highly used (such as a new version of an old browser that we do support). We will as a rule not support any browser, with significantly less than 5% usage, if it is unsupported technology at that point by the software company/group that made it. In other words, if the software is dead, and it's usage is declining, we will be less apt to include it in our standards, than a lesser used browser, that appears to be moving upwards in usage. It should also be noted that this will officially give us a 'supported' standard that is less than the 90th or 95th percentiles. However, in practice, supporting this number of browsers, will in fact allow other, less used browsers to work, thus helping our actual supported percentage go higher. As a general note, OPO will try to design its content to the 95th percentile of current users based upon web statistics that are gathered. On that the below listed standards will be constantly reevaluated - approximately once every 6 months to a year. When the term 'degrade to' is used, it means that the content of the page must be somehow viewable; however, it doesn't have to look good, just be viewable. Also note that specific websites with pocket audiences (such as Amazing Space) may need to design to a broader range of browsers/specification than listed below to hit the 95% mark, this should be determined by specific site's Site Manager.)
- For all content, the idea exists of making a page look it's best in the most popular browsers, and having it look 'a bit different' in other browsers that we support. This is acceptible, and even normal occurance. Therefore browser support will be listed in order of importance, based upon how much usage they are receiving.
- For BASE/CORE content: Pages should be designed for, in order of importance: IE 6.0/Windows, IE 5.5/Windows, IE 5.0/Windows, Mozilla 1.6/Any OS (also known as Firefox 0.8), Mozilla 1.4/Any OS (also known as Netscape 7.1), and Safari 125.1/Macintosh (the version that comes with Panther) IE 5.0, IE 5.5, IE 6.0, and Mozilla 5.x (Known as Mozilla 1.x or Netscape 6.x/7.x) . It can use any technology that is guaranteed to exist within the confines of these browsers (Javascript, Java 1.0.2, CSS, etc.), and any technology provided on the server side (Server side includes, PHP, CGI, etc.), but cannot use other technologies.
- For MULTIMEDIA content: Pages should be designed for the same browsers as BASE/CORE content. However you may also require the user to download a single plugin to access a particular 'module'. You may require any plugin, but again, only one - so requiring Realplayer for example, precludes you from using Shockwave.
- NOTE: This does not mean that we absolutely shouldn't care to know what the page looks like on other browsers, that is always a good thing to know, hence the reason for the other browsers in the testbed - however we are not concerned with it from a design standpoint. Also, the no plugins for CORE, and one plugin for MULTIMEDIA shouldn't be construed to stop you from offering multiple formats of particular content, nor from offering 'extras' that might require another plugin. The rules only refer to the 'base content' of that website.
2.2 Operating System Targets
- For BASE/CORE content: Pages should be designed for Windows 95/98/ME/NT/2000/XP machines.
- For MULTIMEDIA content: Pages should be designed for Windows 95/98/ME/NT/2000/XP machines.
- We are designing our web pages with modem users in mind (with a 56k modem being the assumed middleground currently.) Current research by ourselves and many others on the web has shown that in actual practice (not theoretics) that you can only rely on a modem user getting a download rate of just under 2k per second (for graphics & other binary files). And we would also like to keep a user waiting no longer than 30 seconds, therefore the following triple tier time scale was developed:
- Web pages should be designed to be under 50k in combined size (as defined by the HTML, graphics, programming files, and all supplimental files added together)
- IF a web page should have the need to grow to a size between 50k and 100k , that is allowable; however within the first 50k of downloading, the web page must 'display' fully, and give a 'Please wait while we continue to download ...' message or something similar and then may continue to download the additional information.
- IF a web page should have the need to grow to a size above 100k , which should only be the case of very interactive pages, then within the first 50k (30 seconds) of downloading, the user should be given a 'toy' to play with for the remainder of the time. This can consist of a little game (pong, breakout), trivia (hubble facts to scroll & click through), or other interactive gem to keep them occupied.
- Finally all web pages should strive even under the last rule to remain under 300k in complete size, or in the very least, for the 'toy' to stop, and for the actual activity to begin within the 300k (3.5 minute) limit.
- Web design should be done towards looking optimum on an 800x600 screen with a maximized browser (which gives 760x420 viewable space).
- Given the large range of resolutions being run, ranging from below 640x480, up through 1600x1200, emphasis should be placed on creating liquid designs that fill the screen no matter what the browser resolution.
- Currently, the screen specifications have gone up, with 640x480 being almost never used (around 1%), and resolutions 1024x768 and higher occupying over 60% of the browser usage. Therefore there is less need to worry about resolutions lower than 800x600, other than hopefully trying to ensure that the page doesn't completely break at lower resolutions - a hallmark of some CSS designs. And more emphasis should be placed on ensuring that the liquid design stretches nicely wider to 1024 or 1280 wide without major problems.
- At this point in time, emphasis should be placed on creating XHTML 1.0 compliant webpages.
- Layout & display of the design should be controlled via CSS that works in all browser targets to the highest extent feasible.
- Stylesheets should either be designed to work with Netscape 4 acceptably, or be @import'ed to hide them from Netscape 4's buggy CSS implementation and other older buggy CSS browsers.
- Following these standards will allow for the content of webpages to be viewable on any browser.
- For any BASE/CORE content, some amount of effort should be made to ensure that the page prints out satisfactorily.
- For the purpose of meeting this requirement, the page is only required to be legible when printed, with all body copy visible, and any major/relevant graphics. The layout need not be perfect.
- The printing must also be mindful of paper (not to print to an excessive number of pages for a small amount of data), and mindful of ink (not to force itself into printing a black background or similar).
- The use of CSS print-only styles is encouraged when needed to ensure decent looking print-outs, and is encouraged over having a 'print this' button on the page.
- It as perfectly acceptible to have the printed version of a page differ greatly from the visual version of the page, especially if it will suit the content better, and with preference given to being minimalistic.
- Macromedia Dreamweaver MX is the HTML editor of choice.
- In Dreamweaver, edit your preferences, then select HTML Format, and choose LF (Unix) for the Line Breaks, and lowercase for the two case questions.
- While we have set minimum browser targets above, that does not completely preclude one from using HTML that is for a higher version of a browser, or only for a specific version. However, If so, the HTML must still gracefully degrade itself to look good on the platforms listed in the 'design to' specification. What does this mean? This means that for all browsers in the 'design to' list, you do not notice anything 'wrong' with the page when you are viewing it. Noone, designer, programmer, or layman, should notice anything 'wierd' about the way the page looks.
- Care should be taken to ensure that webpages conform to the Section 508 Accessibility Standards. For our purposes, this involves the following:
- Information conveyed through animation, should also provide a non-animated presentation mode.
- Color coding should not be used as the only method of conveying any information.
- When graphics or text are set to flash or blink, they need to repeat at a rate either slower than 2 times per second, or faster than 55 times per second.
- Form elements should be appropriately labeled to allow for a text browser to fill out the forms in context.
- All graphical elements will have a text representation, through 'alt', as well as through 'longdesc' or element context if needed.
- Equivilant alternatives for any multimedia presentation must be synchronized with the original.
- Document will be organized to be readable without it's style sheet.
- Do not use server-side image maps.
- Data tables will have row and column headers identified in the HTML appropriately (through 'TH' and 'scope'). Similar care must be taken to appropriately mark up complicated tables with multiple levels of headers.
- If used, Frames must be appropriately titled to help with navigation between them in a non-frames browser.
- If a text-only page is provided as a method of compliance, it must be kept up to date with the original page.
- When a page requires any type of plug-in or application, a link must be provided to download the software needed.
- A method will be provided to permit users to skip repetitive navigation links.
- If a timed response if required, you must alert the user when the time is near, and allow them to request more time.
- Javascript must be coded with the predefined browser targets kept in mind.
- Javascript 'extras' that can gracefully degrade may be used, as long as the design works fine without the extra javascript and it is simply a 'visual enhancement'.
- When available, pre-written Dreamweaver extensions should be used in place of custom programming to help standardize all our coding. When custom coding is performed and used in multiple places, it should be incorporated into a Dreamweaver object and added to our library.
- Java applets should be compiled with the JDK 1.0.2
- JAR, ZIP, and CAB compression methods should all be used and given as download choices.
- Applets must be CPU friendly on lower end machines (Pentiums, etc.)
- The source file should be stored on the server right beside the compiled version for ease of retrieval.
- Efforts must be made to keep the size of the files as low as possible & programs should be designed to take use of the streaming features built into these products.
- The source file should be stored on the server right beside the compiled version for ease of retrieval.
- Unless otherwise directed all CGI scripts should be written in Perl for ease of maintanence.
- They should be checked with the -w switch, as well as run through taintperl.
- CGI scripts should in general be placed within the same directory structure as the web pages it deals with & be given a .cgi extension such that the web server will know how to deal with it.
- All PHP code should be written to PHP 4.x
- PHP pages should be thoroughly checked for security holes via the automatic globals feature.
- PHP files should be stored in their most logical locations. A PHP script that generates HTML should sit alongside other HTML files of it's section; PHP that generates a graphic should reside in the graphics directory, etc.
- Any page being created by PHP, but not needing to be dynamically created for each user, should use the 'jcache' caching mechanism installed to reduce server load. Note that jcache, while existing on forge, is disabled there. You may wish to re-enable it during testing.
Following is a list of what browser/OS combinations all web pages should actually be tested against, based upon the above standards, and some additional statistical digging to determine what browsers are used on what OS. These lists should be seen as the MINIMUM testing requirements. Other OS/Browser combinations are available on the testbed if one wishes to test further. (NOTE: Not all versions of Windows have been listed to be tested. Since the executables are the same for the different versions of Windows, we are going to assume that they will act the same. Therefore, any version of Windows can be used for the testing. Most should happen on the 'most popular' version of Windows, which is currently Windows XP. Feel free when testing to use other versions/other machines to simplify the task. The combinations given below are just the suggested optimal setup, given the layout of the testbed)