Site input criteria
The following describes the technical format of input that is expected by the webmasters for inclusion in this site. These are guidelines, not rules. Deviations from them will usually mean more work for us and less certainty that the result will be what you intended.
- Input should be provided only after it has undergone all necessary reviews and is considered final. It is understood that once the material appears on the site, the need for further changes may be discovered, but such instances should be rare.
- All related material, such as an image and its caption, should be provided by a single individual at a single time, to ensure that there is consistency among them. The webmasters should not have to guess which caption goes with a photo, nor where it is to be placed on the site.
- If any of the criteria listed here cramp your creative style, please discuss the matter with the webmasters before submitting input in a way not defined here.
- Text should be provided verbatim as it is to appear on the site. If the webmasters detect obvious errors, (such as a misuse of 'there' vs. 'their') they will be corrected without comment. Less obvious, but not serious, errors will be left unchanged, but pointed out to the submitter for possible revision after the material has been posted on the site. Serious errors for which there is no obvious correction will be pointed out to the submitter and the material will not be posted on the site until they have been resolved.
- The preferred format for text is as a .txt file, with only an indication of where paragraph breaks are to occur (a blank line is sufficient). Text may also be submitted as Word .doc, or .rtf formats. Be aware, however, that formatting (fonts, colors, alignment in relation to other objects) will probably not be retained, although these formats do allow you to provide hints to us regarding which material should be headings, lists, etc. .pdf files should generally be avoided for submitting text. (To test such a file for acceptability, see if the 'Select Text' function of Adobe Reader can be used to select a single word or letter; if so, the file is OK. If not, it represents an image of text, which is useless to us in creating HTML.)
- Any instructions regarding placement or appearance of the text should be enclosed in square brackets, to distinguish them from actual text for the site. An example would be a pull quote intended to appear on the right side of the column, in which case the text should be preceded by something like [pull quote right]
Images should be accompanied by alternative text briefly describing what is in the image. Some users inhibit the display of images. Some users are blind and use devices that can read text to them, but cannot interpret images. The alternative text will give them an idea of what is in the hidden image. If you do not provide alternative text, we will do so, based on our interpretation of what the image contains, but that may not be as accurate as what you could provide. Images that are purely decorative do not need alternative text.
- Photographs should be submitted in JPEG format. We will reduce the size as necessary. If cropping is required, you must be VERY specific about where the cropping boundary should be. Since this can be hard to describe in words, it is best to crop photos before sending them.
- If possible, the name of the photographer should be provided, so we can give them credit. This will take the form of "Photo by xxxx yyyy", unless you specify something different.
- Photos should be accompanied by a photo caption.
Images of text, logos, drawings
- Images of text are discouraged because they are not indexed by search engines and cannot be read by screen readers (software used by those with impaired vision). There will be cases where such images are nonetheless appropriate.
- Images of text or other sharp-edged materials (such as a logo or drawing of a triangle) should be submitted in .gif or .png format. If these images are submitted as JPEGs, they may have fuzzy edges when displayed.
The ULA logo uses two shades of blue, one for the book image and another for the text. If you are trying to match those colors in another image, their RGB notation is:
- Lettering: #25368F
'Other files' are those that cannot be directly processed by a web browser without assistive code or 'plug-ins'. When a user selects one of these files, they must have the appropriate software (in addition to their web browser) in order to make use of the file. Because you cannot know what software the user has installed, other files should be used only when HTML cannot accomplish your objective, since some users may not be able to process them. If you contemplate using a file type not included here, it is wise to consult with the webmasters regarding the implications of such use.
'Other files' will not be edited by the webmasters. If revisions to these files are required, a complete replacement file should be provided.
The webmasters are not obligated to test 'other files', but will upload them unchanged. If any testing is done and problems are found, these will be reported to the submitter for correction.
Adobe .pdf documents
These files are appropriate where integrity of a printed page is important, i.e. where it should look the same no matter what software and hardware the user has. Most users cannot edit these files, i.e. change the content that you provide, however 'fillable forms' can be filled out by the user if they have Version 8 or later of the free Adobe Reader software (available since late 2006).
- .pdf files grow in size as revisions are made. Before submitting a .pdf file for the site, open it in Acrobat and then use Save As (with a slightly different file name) to save a copy for submission. This will remove all of the bloat introduced by prior revisions, leaving only the current content and thus providing a smaller, faster-loading, file. Your webmasters do not have the software (Adobe Acrobat or equivalent) required to do this.
Microsoft .doc and.rtf documents
DOC and Rich Text Format (.rtf) files can be opened and edited on most user systems. Their displayed and printed appearance may differ depending on what software is used to process them.
- To minimize formatting differences, it is best to create .rtf files in a low-function editor. Microsoft WordPad is a good choice. MS Word is not, because it tends to allow you to do things that will not be understood by lesser software and can result in garbled document layout when such software is used.
- .rtf documents should be tested, before submission, in multiple editors to be sure that they appear in a satisfactory manner in all of them. Suggested testing environments include MS Word, MS WordPad, and Apple MacIntosh TextEdit.
Banners and Flyers
If you are contemplating use of a custom banner or flyer, contact the webmasters before proceeding.
To attract visitor attention to changing information, we use a banner at the top of each page. Banners announce past or future events, alert visitors to our organizational needs, or simply provide inspiration. Banners are of two types:
- Self-contained. These banners provide complete information about something. Examples: inspirational quotes, weather closure.
These banners provide minimal information about something and include a link to complete information, sometimes in the form of an event flyer.
They should contain:
- WHAT the banner announces: training, a fund-raiser, news, an organizational need.
- If the banner describes a future event, the month and day it begins.
- A visible link to additional detail. Example: 'Click here for details'.
The objective of a teaser banner is to get the visitor to click on the link, nothing more. It should contain little other than the information listed above, as space for the banner is small.
To select from a list of currently-available banners, you can use our Banner Picker. Once you have selected an appropriate banner, you can provide the webmasters with just the number of that banner.
If none of the existing banners is suitable for your purposes, it may be necessary to design a custom banner, in which case the following information will be useful.
The banner resides in an area that is constrained both physically by the width of the display and esthetically by a desire to closely match the height of the logo at most window sizes. As a result, banners must be compact and have a lot of horizontal flexibility. The following guidelines may be helpful, but are not inclusive; only actual testing can determine if a specific banner design is satisfactory.
- The logo is 114 pixels high. Any image used in the banner should not exceed this height. If a background color (other than white) is specified, it will be minimally set to this height.
- Images should not contain text that is intended to be read. On a high-resolution display the image may be too small for the text to be read. (This is good advice for all images on web pages.)
- The width of the banner area is highly variable. Under best-case conditions (a wide window), the width of the banner area is 64em minus 208 pixels. This knowledge is of little use, since you don't know what font size the user has specified, so the width of an 'em' unit is unknown. On narrower windows there will be even less room.
- The more flexibility you can provide, the better. The best case uses only text, with short words, so the text can be broken up at many word boundaries. If images are used, they should be as narrow as possible; 114 pixels (i.e. equal to the maximum height) is a good upper limit.
- Font-size should always be specified in % of 'normal' text, where 100% (same as normal text) is the default. The larger the font-size, the fewer the number of lines of text that will fit without becoming higher than the logo.
- To accommodate iPad devices, banners should be tested by the webmasters, using the BannerTest page, at a display width of just 980 pixels. For an explanation of this limit, see Apple's documentation on Viewport.
- A good way to lay out a proposed banner design is to fit it onto a piece of paper that is 1 and 1/8" high and no more than 6.5" wide, making sure that it is readable at arm's length, then let the webmasters convert it into something that actually works on the site. If you prefer to work with pixels, stay within a 114 x 660 pixel space. You should expect that the result will not exactly match your original; it is helpful to identify the characteristics of your design that are most important (color codes, font names...), so that your wishes can be taken into consideration when making any necessary compromises. Finally, be aware that considerable work may be involved in realizing your design; if the banner is to be used only once it may be given less implementation effort than if it will have recurring use.
Flyers provide complete detail about an event and inducement for a visitor to attend. The data should include:
- A description of the event: class, party, sale, etc..
- The date and time of the event.
- The location.
- The cost to attend, if any. If admission is to be sold via PayPal, a statement like 'Click here to reserve seats'. The entire flyer will be made clickable and, when clicked, will take the visitor to Paypal. If this wording is absent (not recommended), the webmasters will create appropriate wording which will be displayed below the flyer.
The flyer should NOT include:
- Any statement like 'go to the website', since this version of the flyer will be displayed ON the website, hence the visitor is already there.
If the flyer contains nothing but text in the form of paragraphs, lists, headings, and the like, it can be provided as described under Text. The webmasters will convert this to HTML, thus providing automatic adaptation to different device sizes.
If the flyer contains images, specific positioning of words, specific colors, fancy borders, etc. it should be provided as an approximately 600 wide X 800 high pixel .png file. Webmasters will embed the png, unchanged, into a web page.
Your cooperation in adhering to these criteria will make the job of the webmasters easier and provide a better experience to our site visitors. Thank you.