The World Wide Web (WWW) is a hypertext, multimedia way to access and distribute information on campus and around the world on the Internet. Our main web server is at www.uky.edu and the complete URL (uniform resource locator) is:

    http://www.uky.edu/

University departments, faculty, classes, and organizations, including registered student organizations, can have space on the campus server. (Individual students can have web pages on the student web server - see sweb.uky.edu for more information.)

There is no charge for this service, but if your disk space requirements will exceed a few dozen megabytes, please let us know. The web server does not have the resources to act as a general file server, archive, or backup! When the amount of available disk space on www.uky.edu becomes low large files will be arbitrarily erased without notice.

Your use of the University's web servers must conform to the University's Web Services Policy and like all University computing resources, must comply with the Computing Resources Policy.

To become a web information provider you must request a web userid (a U-connect userid won't help) from user account services at the Help Desk in McVey Hall.

Each person who will be working on files on the web server must have their own web userid in their own name issued to them by user accounts services. The University computing policy generally prohibits sharing userids or passwords. The purpose of a web userid is to identify and authenticate an individual person with access to the server and not to define a URL.

To provide information for the web server you may need at least a little familiarity with Unix. You can do your editing and preparation on any system you prefer (Mac, VM/CMS, Windows, etc.), but the files will eventually be put on a Unix system and you will need to be able to use FTP (File Transfer Protocol) or log on there and use a few commands to prepare them for use by the server.

The recommended and supported web browser at the University of Kentucky is Netscape Navigator, which is available for Macintosh, Unix, and Windows systems. Microsoft Internet Explorer is also widely used on campus. Other browsers are also in use as well and you generally shouldn't use non-standard, browser-specific features.

Our web server is Apache running under Unix. It does not support Microsoft's Active Server Pages (ASP). PHP and Python are available.

We cannot support or recommend the use of any web page creation tools or HTML editors, such as Dreamweaver, Adobe Pagemill, Microsoft Front Page, Netscape Navigator Gold, etc., and we do not provide any server code that they may require. You can use these products with our server if you desire and can do so without assistance from Information Technology. Even server extensions that are available without charge would require maintenance by our staff and can unnecessarily complicate the work of our web providers who choose not to use them, therefore we do not make them available.

Departmental and Other Campus Web Servers

Some departments, colleges, and other organizations operate their own web servers (a recent survey located over 200 web servers on campus). We have no control over those servers or their contents, but we do have links from pages on www.uky.edu to other campus servers when appropriate. If you maintain pages for your organization on a server other than www.uky.edu and we have links to them (in the Site Index, for example), please inform us (by e-mail to webmaster@www.uky.edu) when a URL changes. Note that all University web servers must conform to the University's Web Services Policy.

HTML

You will need to learn some Hypertext Markup Language (HTML) - the language of web pages. A number of tutorials and references are available from the web. We provide a very simple skeleton HTML file that is suitable for departmental use.

Contact the Help Desk at helpdesk@uky.edu for information about HTML classes.

Your Information

Information for the web server is kept in files on the system at www.uky.edu. When you connect to www.uky.edu with your id and password (using SSH or FTP, for example), you should find in your default directory a subdirectory called "www" for your web files. (If a www subdirectory isn't already there, you can create one using your FTP client software or the Unix mkdir command.) You will put files for use by the web server in your www directory using FTP or whatever method that works best for you. You must make these files available to the server by setting the file access flags (the server system is set up to do this by default, but you should check to be sure they are correct).

Software is available on some systems that will allow you to use tools you are more familiar with for editing your HTML files and move them more-or-less automatically to the server. BBedit on the Macintosh and the Xftp command on VM/CMS are examples.

  http://www.uky.edu/~userid/typical.html

Don't advertise a URL on www.uky.edu using the ~userid form for other than testing, class, or personal purposes! This is very important! At some point in the development of your web project get in touch with us and we will set up a more permanent directory and URL for your publication-quality files leaving your www directory for testing and development. This arrangement facilitates the maintenance of the server and helps assure that your files will be handled correctly in the future.

Once you have pages ready to publish, contact webmaster@www.uky.edu and tell us the project you are working on, your department, the web userid or userids that will be used, and a phone number where we can reach you.

Mailing List

There is a mailing list for campus web providers - WebPubs-L. To join send a note to listserv@lsv.uky.edu with the following as the text:

   subscribe webpubs-l Your Name

There are several things you should keep in mind when designing your World-Wide Web pages. These points can help make your pages more useful to a larger audience.

Your pages should have clearly indicated a contact for additional information, comments and questions about the pages, etc. An e-mail address is very convenient for most using the web so it makes a good contact mechanism.

Try to use a unified design for your pages - make them look like they belong together. If you are making pages for a University department or unit you should try to follow the general style of the other University pages - they should all look like they came from the University of Kentucky. (The University's Web policy includes some page design requirements including rules regarding the use of the UK logo. Also see the University's Graphics Standards for more information.) See our sample HTML file for a simple starting point.

Generally a white or other light background with black or other dark, contrasting text will be the most legible and thus the most useful. On some systems, depending on the fonts available and the colors used, light text on a dark background is virtually illegible. As a web author you don't have any control over which fonts are available on a user's browser and how they are rendered. This point can't be overemphasized - just because it looks good on your screen doesn't mean it will on another.

When possible use the 216 colors that are most universally available to avoid dithering (see our images page for more details about color palettes).

Clearly identify what you are trying to communicate with your pages and concentrate on that. Avoid extraneous elements that detract from that goal. Maximize the amount of information on your pages. Strive for simplicity, elegance, and directness. Avoid splash pages that viewers must pass through to get to the actual information they need.

Provide a clear path from each of your pages back to your first page or other appropriate starting point. This can be as simple as a few links at the bottom of each page. People using search engines or following links from elsewhere can jump directly to any of your pages. (See our notes on searching for more on this.) A link back to the University's home page is often appropriate. The standard UK navigation bar is required at the top of all home pages for colleges, departments, and units. (See our sample HTML file for an easy way to include it if you are using www.uky.edu.)

An important consideration is how your audience will view your pages. On the UK campus in Lexington access will most likely be from a Macintosh or Windows PC with a fast ethernet connection, color monitor, and Netscape Navigator or Microsoft Internet Explorer. The speed and capability of the workstations can vary considerably however. The size and color resolution of the monitors will vary (some will even be black & white). Some people will be viewing your pages from VM/CMS or a Unix system with a text-only browser and won't be able to see graphics. Many will be accessing the web over a relatively slow modem connection and will at the least be irritated by unnecessarily large graphics and may well disable automatic loading of graphics. Some will be using a web browser other than Netscape's or Microsoft's, so reliance on their browser-specific extensions to HTML and other idiosyncrasies can cause problems. These considerations are even more important if a significant part of your audience will be located off the Lexington campus.

While graphics can be a valuable addition to a web page, consider what you are trying to communicate and avoid extensive graphics that convey little or no information. Animated images can add another valuable dimension to a page, but they are also often abused and are often more annoying than useful. "Under Construction" signs and logos from your favorite web browser company seldom add any value to a web page. (They have become dreaded web clichés.) Use the alt attribute of the img tag to provide a text alternative to your image for users who can't or aren't using graphics. See our images notes for more on using graphics.

Try to avoid excessive use of bold and italic text. On some workstations they are much less readable than plain text and too much makes a page harder to read in any case. The high-numbered HTML heading levels have the same problem - some browsers use very small, bold text that is virtually illegible for H5 and H6 headers. Some browsers support blinking text, but that is usually very difficult to read and will quickly induce visual fatigue and annoyance in readers. Some screen readers for the blind will have problems with it as well. Some browsers allow you to control the background and text colors or supply a background image. Keep in mind that some combinations of colors or complicated background images can make your text virtually illegible.

With HTML 3.2 and later you can specify type that is larger or smaller than the default with the font tag's size attribute or a style sheet. Some browsers also support a face attribute, but that is problematical.

To assure the widest compatibility your pages should use HTML that conforms to HTML 4.01 Transitional. This is basically HTML 3.2 with some common extensions. New versions of HTML will be specified as XML and the specifications of XHTML have been released. Keep in mind that some people will still be using older browser software that supports HTML 2.0 or some variant, although the numbers of these are very low. Most browsers have idiosyncrasies in their interpretation of the HTML standard and also include private extensions not supported by other browsers. This makes designing and testing web pages a complicated task.

An HTML Validation Service is available on the web.

Your pages may be used by people using screen readers or speech or Braille output devices. To better support them you should include descriptions with images, make careful use of tables, and take other steps. The W3C has accessibility guidelines and the Webxact web page analyzer can check some aspects automatically. Also see the Access Board web site and the General Services Administrataion's Section 508 site.

The growing use of hand-held, wireless devices with network access should be considered as well. Many of these devices support only text and have very small display screens.

Putting text into graphic elements makes your page useless for users in these situations.

Always respect the intellectual property rights of authors and artists. Don't use images or other material from someone else without permission. The University's Web policy includes information on intellectual property and copyright concerns and we have additional information on copyright and fair use considerations.

PDF is a file format that allows a document to be displayed by a web browser with very precise control over formatting - much more than is possible with HTML. With appropriate software PDF files are very simple to produce from existing word processing documents and other sources. However, they have several disadvantages. A browser plug-in is required to view the files, requiring some extra software to be installed by the potential users. The PDF viewer is very widely available, but not universal and some browsers and older systems are not able to use it at all, making PDF files unusable to some. PDF files are generally much larger than a simple HTML version of the same document, often by a factor of 10 or more, thus slowing the display. Many indexing systems cannot handle PDF files, so they will not be found by some search engines. PDF should be used only when very precise formatting is absolutely required, as when it is necessary to precisely match existing paper documents, or when other features available through PDF provide important benefits. Converting an existing document to good HTML is usually much more time consuming that generating a PDF file, but the time spent may be repaid many times over by that saved by the users of the page.

Support for Java and JavaScript, programming languages that allow programs to be downloaded from a web server and executed on the client workstation, are widely available, but aren't universal. Java and JavaScript should only be used when there is compelling need and an alternative method of accessing the function supplied that way should be provided. Reliance on Java or JavaScript can make your pages inaccessible to those relying on assistive technologies and may prevent them from being properly indexed by our search service. The addition of Java or JavaScript will make testing, debugging, and updating your pages much, much more complicated. Carefully weigh the costs and benefits. (Actually, because of unresolved security problems, it may even be best to disable JavaScript and particularly Java on browsers that support them.)