A Guide to Good Website Authoring
These notes are designed to ensure that all web pages to be viewed externally present a professional impression of Central Data Service . They are a key component of the web guidelines and should be read along with the initial pointers. The administrator has drafted this guide with a view to ensuring that the first impression others have of the site (and of course the organisation) is positive.
If you are in any dount as to the suitability of content, please contact me at the email address above; I will be happy to provide guidance. Small, even trivial, spelling errors or mistakes in presentation can have an impact on the overall impression of the company.
Perhaps the most needed piece of advice is to comply with internet standards, in order to avoid compatibility issues. Web authors should always be aware that they cannot control the page at which an external viewer will enter their site (e.g. they could arrive from any search engine or arbitrary link set up on another site) and so they must take steps to convey sufficient information on every page to identify the company.
Once a viewer has been attracted on to the DFDN site, we should try to ensure that they remain there ("stickability" in web jargon) by providing links to the home page, as well as to potential areas of associated interest.
Web authors have no control over the type of browser software that an end-user may be using to access their web pages, the size of window they have open, their screen resolution or the speed of their network connection. Pages should be designed to be as all-purpose as possible (in other words, compliant with internet standards) and also not rely upon non-standard features, proprietary HTML tags or plug-ins unless suitable alternatives are provided. For example, Apple IOS devices do not support Shockwave Flash, so this cannot be relied on to provide vital functionality, although non essential features can be provided in moderation.
In the detail that follows there is no desire to stifle the creativity of individual authors. However we have a combined responsibility to provide an attractive, authoritative and accessible site that enhances our overall reputation. For a (hopefully!) growing number of users the web site is in effect the "Worldwide Shop Window for Welcome to David Norris Central Data Service ".
Things to consider:
Total page size:
Page size in Kilobytes should always be considered. Remember that a page of 70 Kbytes will generally take ten seconds to download over a 56K modem. Even in 2014 there are people in rural areas who are stuck with modem connections. Download time may be checked before release by following instructions at www.netmechanic.com.
Technical Guidelines
1. All pages should have a meaningful title of not more than 70 characters contained within the
tags. This is widely used by search engines when crawling pages.
2. All pages should have a description included using a suitable metatag in the HTML header.
This is used by search engines and displayed as the result text on search results pages.
3. Insert keyword metatags to index the content and enhance your pages' ratings with some search engines.
4. All images and buttons should have an alternative text provided using the 'alt' attribute of the ![]()
tag. This is vital to aid navigation for visually impaired users' browsers; other users, especially overseas, or with ,modem connections, may have turned image display off on their browsers to speed up page download and reduce costs.
5. Do not use frames unless there is a compelling reason to do so. Frames-based pages cause difficulties for the visually impaired, search engines, when creating bookmarks, and printing pages (particularly in older browsers).
6. HTML files should be uploaded to the server in ASCII format; images as binary. If your FTP program. (e.g. wsFTP, LeechFTP, CuteFTP ) has an 'Auto' or 'Automatic transfer type' mode keep this switched on.
7. The default filename of the first page served within a directory is index.html or index.shtml depending on whether the webpage uses Server Side Includes (e.g. the headers and footers). This ensures that shorter URLs can be used e.g. dfdn.org.bf/webmaster rather than dfdn.org.bf/webmaster/firstpagename.html
8. Do not have any pages in your operational site displaying "Page under Construction" or similar wording, it looks unprofessional. A local directory on the server is available for testing as well as providing internal information; (this is available only to users within the DFDN domain).
9. If you are using any special techniques or methods, it is helpful to create a file in your top directory to act as an aide memoire to yourself and those others who may be involved in site maintenance. Name this file 'readme.txt'. Do not link it into your site.
10. Filenames should *NEVER, ever*, contain spaces. If you need to use a longer filename connect words using an underscore: '_'. It is also preferable to use lower case consistently rather than mixing upper and lower case. This will prevent possible problems when your content is transferred to a Unix/Linux file server. (These operating systems have case sensitive filesystems).
11. When using audio/video content it is best to consult the Webmaster before you begin, unless you are totally familiar with the technology. Iwill advise on suitable formats acting on current advice. Remember there are nowadays many different devices of widely differing types in use by the public to view video content.
12. A copyright statement, of the form © Welcome to David Norris Central Data Service, should generally be displayed at the bottom of every page.
The central Company web server currently runs under the Linux operating system with Apache web server. This is a non-proprietary combination and does not offer the proprietary Microsoft ASP, IIS or Front Page extensions. Perl and PHP are available together with MySQL. These products are unsupported currently due to resource constraints.
Design Guidelines
1. Certain core content is provided centrally. Links to these pages of core content should be incorporated where appropriate, into pages and not reinvented or copied into local pages. This will ensure consistency of information to our users. Content should be date-stamped to advise readers of its currency. Old content must be removed so that it is not presented as current, especially by search engines.
2. To prevent horizontal scrolling, pages should ideally be designed to work on a screen of width of 600 pixels. This will also provide a page which will print straight from the browser.
3. A consistent font type should be used, e.g sans serif for ease of reading, e.g. by using the tag: . It is recommended that you employ Cascading Style Sheets (CSS) if you wish to control the appearance of fonts. The main advantage of using CSS is the ability to update font colours, types and sizes 'globally' in a website by editing one or two lines of code in a single file as opposed to having to do this many times in every webpage!
4. Animation should generally be avoided unless there is an obvious advantage in their use. If used, animations should not loop indefinitely. Please also consult the webmaster for further advice here.
5. If you are new to web page design, seek advice from others before making your pages accessible to the general public. Invite comment internally when you believe that your site is fit for general release. While content is the key ingredient of your site, the first impression is created by the design. Credibility should be established at the first opportunity.
6. Every page should have a link to the dfdn Home page.
8. Images should be in either JPG or PNG (for photographs) or GIF format (for flat colour images such as buttons and small icons) and optimised for minimum filesize as appropriate.
9. Within a COMPANY site the visual identity should be consistent to reinforce the user's sense of location. Contact information for the company should appear at the bottom of every page and include the phone, fax (if used) and generic email addresses.
10. Navigation elements on a page are generally best placed on the left hand side or at the top, so that users gain a rapid impression of what's available without scrolling or extending their window size.
11. Use non-specialist language - avoid jargon if at all possible.
12. Always try to present a user's perspective of your site. External users should not be expected to know our internal arrangements to be able to access the information that they require.
13. Users tend to scan text rapidly on the web. Where text is transferred from printed documents to a webpage, it should as a general rule be reduced to about half the length of the printed version and be presented in smaller sections. Where appropriate, fuller printable/downloadable versions should be provided separately.
14. Every page should have a title and keyword metatags. These are commonly used in searches. Titles should provide a plain guide to the content on the page and relate clearly to the link text that the user would normally follow to reach there. This provides reassurance that they have reached their intended destination.
15. Link descriptions should be helpful - avoid using "click here". Link titles can help to provide further information to a user when a mouse is held over the link.
16. Email links (mailto:joe.blogs@dfdn.line.pm) should be displayed in the following format:
Further details are available by emailing joe.blogs@dfdn.line.pm
and not:
Further details are available by emailing myname (with mailto link in HTML only).
This allows users to note down the email address to allow for further contacts or if they are unable to use the mailto link.
18. If you are including a web-form -> email facility in your pages (i.e. you set up a web form and the fields and values are then sent in an email to the recipient of choice), then the following code at the head of this page should be used (with amended values as appropriate) :-
19. Do not use frames unless there is a compelling reason to do so! Frames-based pages cause difficulties for the visually impaired, search engines, when creating bookmarks and printing pages in older browsers. Yes, you're right you did read this one above! Reinforcement is a key ingredient of education.
Externally Sourced Web Content:
1. If you are engaging an external supplier to develop your website they are advised to contact the administrator before commencing work. Failure to do so may result in a quite unnecessary waste of time and possibly ultimate rejection of their content.
2. These guidelines should be supplied (by quoting the URL, http://dfdn.org.bf/guidelines.html ) to external developers. Any material supplied which fails to conform to the guidelines may be rejected for mounting on the central server. Content provided to the Webmaster will be mounted as supplied, since no direct FTP access is provided to the external supplier since doing so would present security risks. Subsequent page maintenance and correction of operational failures involving third-party content are not the responsibility of the Webmaster unless previously agreed in writing.
Technical Data
1. The core company web server (known as the Central Unix Server) provides a Unix Apache environment.
2. No direct access to the core cgi-bin is afforded to any developer outside the company.
3. File-naming should be consistent. Mixed upper and lower casing may cause problems if used carelessly; lower case is always advised. There should never be any spaces embedded in the filenames.
4. The default name for the home page on these servers in any directory should be index.html (or index.shtml if server side includes are used).
5. The company provides a formmail script as the standard method of emailing web forms-based information; details are as currently outlined in the guidelines on this page.
6. Insecure content will not be registered on the site. The company provides a single point of exit and entry for SMTP mail which is maintained by the administrator of the DFDN domain. The use of local SMTP servers for external mail services is not possible. This is part of our junk mail blocking policy. A mail server which is permitted to relay external mail is likely to be found and used by junk mailers; in which case others will understandably blame us. A server relaying spam is only going to be added to the various blacklists, which will result in other sites refusing to exchange mail with us. (There is therefore no sense in choosing to leave a mail server open to relaying).
7. perl, php, mysql and Unix shell scripting are available, but only supported at a minimal level. The use of Microsoft IIS, SQL Server and ASP is not supported.
8. Front Page extensions are not, and will not, become available on company web servers.
An important warning about Microsoft FrontPage and Word
Many people use Microsoft Office, i.e. FrontPage and Word to edit WebPages but there are some very good reasons why this is not a good idea.
Microsoft designed FrontPage to be a website management tool for absolute beginners. No knowledge of HTML is needed and everything from page design to publishing the site can be done within FrontPage. If this was as far as Bill Gates had gone then everything would have been fine. But Microsoft (being Microsoft!) went one step further and made FrontPage the virtual nightmare it is.
The management tools render a webpage so complex (and large) that it is near impossible to manage it outside of FrontPage. The publishing tools provide security risks, and worst of all the design tools generate HTML that won't even work on many web servers (the place your WebPages are eventually stored so people can access them via the World Wide Web!).
FrontPage can create many effects that are in-house only and not supported by HTML itself. Perhaps the most commonly encountered of these is the Marquee tag. This will only work if the user views your web page using Internet Explorer. The more advanced effects are known as FrontPage extensions. Many weird and wonderful effects can be created this way, but if the web server doesn't support FrontPage extensions, then none of it will work. The DFDN web server does not, and will never, support FrontPage extensions. It's just far too much hassle for something that will just end up creating far more problems than it will ever solve.
Microsoft are guilty again with their incarnations of Word. A great word-processing program it may be, but a good web authoring tool it is not. It's easy to create quick WebPages with Word but it will produce faulty HTML, unnecessarily long and complex HTML files, and the Auto-save functions on Word will play havoc with your WebPages.
Basically my advice is don't use these products. Especially when we have far superior tools dedicated to HTML design available. This page was created using Allycode HTML Editor, for example.
