By means of our web content, we present the UCLA Mathematics Department to the global community and to our internal users professionally, attractively, and in a manner that demonstrates our status as a premier Mathematics Department.
We present our message while flexibly accommodating the needs of non-mainstream users, such as:
We design our pages and policies to reduce, not increase, the amount of work needed to get content onto the web attractively and coherently.
We are flexible enough in our policies to accommodate unusual presentation needs, yet strict enough in adherence to avoid clutter, user confusion and expensive maintenance.
These goals can be translated to the following normative statements:
All pages created by the Mathematics Computing Group shall conform to the applicable HTML standards. Reasons:
Delivering our content requires cooperation between the provider (us) and the consumer. The standard is a meeting place in which we know what we need to provide to get our message across, and they know what markup we will be sending over that they need to put on the screen. If we send nonstandard material the client will work around it in ways never to our advantage.
When mathematicians compare the web offerings of different departments, if ours are incorrect in meeting standards, they will know that we are not professionals.
There are several applicable standards.
We use the UTF-8 charset in all our pages. Reason: This is a Mathematics department, and we and our users often need to put mathematical symbols and non-Latin letters (e.g. Greek and Hebrew) on the page, which can be represented by UTF-8 but none of the others.
code points. It includes Greek beta and mu and simple math symbols such as the division sign, but is not adequate for actual mathematics.
A retro browser from before UTF-8 was invented will not be able to display the symbols. If jsmath is used, a browser incapable or unwilling to do Javascript will not be able to display the symbols. (Selection of UTF-8 does not preclude use of jsmath.)
What editor and what input method will we use to get the UTF-8 symbols into the files? That issue hasn't even been thought about.
We use the HTML 4.01 Transitional Document Type Definition (DTD).
We use CSS version 2.1.
Design Rule: Every web page shall be run through the validator, and shall pass, before being posted publicly.
Design Rule: Every web page shall have a DOCTYPE statement, and a meta tag for the charset. These are required for the client to display the page correctly, and for the correctness to be confirmed by the validator. (There is no explicit declaration of the CSS version.)
Mathnet follows guidelines for accessible
web pages, that is,
pages which can successfully convey our message to users who are visually
impaired, or blind, or have motor issues. Reasons: Charity requires helping
those less fortunate than ourselves, and in particular for web design, avoiding
to actively get in the way of their strategies to mitigate their disabilities.
Campus policy is to make reasonable accomodations for the disabled. All
entities in the United States, and particularly federally funded entities like
our Department, are required to comply with the Americans with Disabilites Act.
Design Rule: Mathnet never sets the font-size of the body element, relying on the client to set it big or small enough to be readable with his own eyes and monitor.
Design Rule: All images shall have ALT attributes (to be shown on a non-imaging browser as used by blind people). Similarly, all tables shall have descriptive attributes.
Design Rule: Since blind people generally use a text-only browser together with a screen reader, all our pages need to be functional in this context.
We should obtain and install screen reader software, for checking web pages.
Design Rule: It is beyond our resources to create a duplicate set of pages that are accessible. All our pages shall be accessible.
Mathnet adapts to the screen and window that the client provides us. Mathnet does not insist that our pages be viewed on a particularly sized monitor. Reason: We cannot know on what screen our material will have to fit or fill, but just within our department we know of screens ranging from 2560x1920px to 320x320px and 75 to 250 dpi. It isn't professional if we require a SVGA (800x600px) monitor at 75 dpi for our pages to look right. This principle implies several design rules:
Design Rule: Mathnet uses exclusively relative dimensions, never pixels, points or inches. In particular:
Design Rule: Images must have an explicit width attribute. (If none is given, the default is the picture's intrinsic width in pixels.) Most often, the width is a percent of the containing object's width, typically the browser's window. Exception: small icon-type images (such as the HTML compliance logos) may appear at their intrinsic width if they will be readable on all expected screens and if they do not disrupt the page formatting on small screens.
Design Rule: Text-associated dimensions,
such as margins, shall scale with the font-size. A unit of em
(the nominal line-spacing of the font) is most useful here.
Design Rule: When the font-size is set on
a special element, it shall be a percent (of the prevailing font-size) or an
equivalent relative specification such as ems
. Mathnet encourages
page authors to use <BIG> or <SMALL> instead of setting
the font-size explicitly, even if relative.
Design Rule: Table column widths shall be percentages (of the table width), never pixels. Often the table itself needs a width, and this shall be a percentage (generally 100% of the containing object's width), never pixels. These rules apply equally to tabular content and to tables used merely for layout effects.
When the screen resolution is denser or sparser than usual, we rely on the client to adapt his default font size to be readable on his monitor, not overriding the font size of the body element. This also allows visually impaired clients to improve readability by enlarging the font-size.
Mathnet does not use plugins of any kind, e.g. Adobe (Shockwave) Flash, and rarely if ever uses Javascript or Ajax technology. Reasons:
Web browsers, particularly on mobile devices, have a range of capabilities, and the desired plugin often is not available, so our message could not be delivered.
Blind users generally use a text-only browser with a screen reader, and few if any text-only browsers can run plugins, even Javascript. Thus our message could not be delivered to blind people.
Some users are concerned about the security implications of running programmatic scripts from unknown sources on their machine. Particularly, the Mathematics Department includes faculty active in the cryptographic community. Such users would turn off scripting languages even if available, and Mathnet accomodates their security rules.
While scripting languages can produce interesting and attractive web pages for people willing to use them, these take a lot of work for the web author, which it is not appropriate for us to expend.
Design Rule: If we did have scripts, which we don't, every script element shall have a functioning and professionally crafted <NOSCRIPT> alternative for when the plugin is not available. Thus the script is added to the effort to make the conventional page, not replacing any of it.
Several exceptions are made to the no-plugin rule, but this list should not be added to without serious thought of the consequences.
A large number of preprints are offered in PDF format. The viewer is a plugin. When feasible, the Mathematics Department should offer preprints in HTML format (as well as PDF).
Some instructors have used Java applets effectively to illustrate mathematical points. But they must understand that not all students will be able to execute the applet, and that it is not accessible to blind students.
The jsmath system uses Javascript to show mathematical symbols (as little pictures). Javascript may be unavailable or broken on some browsers. (Strictly speaking it is not a plugin, but it suffers from the same issues.)
Although our emphasis is on standard-compliant pages to be shown by standard-compliant browsers, Mathnet accomodates retro (ancient) web browsers within reason, as well as idiosyncracies of a few common browsers.
Design Rule: Mathnet produces web pages which are functional on noncompliant browsers, even if more features or a nicer appearance may be had by a standard-compliant browser. Particularly, blind people often use text-only browsers that do not do CSS, with a screen reader. For example, the drop-down menus do not drop on some browsers, but as a fall-back, they are themselves links to separate category pages containing the same set of links.
Design Rule: If a browser is used in less than 5% of our hits, and if the browser has an upgraded version which came out 3 years ago or more, then it will no longer get special treatment. In particular, special kludges for Microsoft Internet Explorer version 6 will be removed in 2009 if the 5% rule is satisfied.
Design Rule: Our pages shall be tested on the current versions of Firefox, MSIE, Safari, Konqueror, and Opera, as well as on MSIE-6.x. (List is current as of 2007-10-xx.)
Design Rule: Conditional code for particular browsers (MSIE) is strongly discouraged. At present it is limited to the drop-down menus in the page header, and no further conditionals should be added.
Mathnet writes pages that work equally well on all operating systems. The main vendor-specific issue for us is fonts.
Design Rule: Mathnet uses only font families known to be present on the client's browser. This means we limit ourselves to the CSS generic families: Serif, Sans-Serif, and Monospace. (Few users have useful settings for Cursive or Fantasy.) We rely on the user (or his operating system defaults) to map these families to some useful font that is actually installed.
Design Rule: Mathnet presents our message as text, not as pictures of text. Reason: Browsers are designed to render text on the screen. Search engines interpret the text of the document as its main payload. Some sites want a visually striking special font which few if any clients will have, and so their web designer renders the message into a picture of the text using this font, but even with careful crafting by the web designer it is very hard for such presentation to be decently accessible to blind users (even with ALT attributes stuck on an endless stream of separate images), or to scale without pixellation to fit the font size needed by a user with visual limitations, or to scale to attractively fit large or small screens.
Inevitably, exceptions to this rule creep in. In particular, corporate logos very commonly include a picture of the company's name in a unique font, and Mathnet has followed the same strategy. Exceptions should be kept to an absolute minimum, and the value of breaking this design rule should be thoroughly debated by the Mathematics Computing Group if ever proposed.
In order to present a professional, coherent and efficient web design, we adhere to several additional rules:
Design Rule: We use a uniform style in these areas:
uniform stylein general will be to build from the client's default values according to his special needs. In particular, we do not set the font-family or font-size on the body element. Thus the documents will appear uniform (fontwise) to any one client, but will vary from one client to the next, e.g. Windows vs. Linux vs. Mac.
Design Rule: We use relative links whenever possible, so they will work if directories are reorganized or the server name changes (as in an emergency). Specifically:
Bad: <a href="http://www.math.ucla.edu/computing/support/printing/index.html">
From alternate webserver, leads back to main one.So-so: <a href="/computing/support/printing/index.html">
Stays on original server, but directories are immutable.Better: <a href="../printing/index.html">
Allows for easiest restructuring.Best: <a href="../printing/">
Best to let the webserver pick the index from its list of variants -- and this takes the least typing too.Good: <a href="http://www.pic.ucla.edu/piclab/">
Absolute path is fine when leading to a different server.Good: <a href="/~staffsearch/positions.html">
A link to an unrelated directory should start at top level.
Design Rule: Images should be pre-scaled (reduced in size on the server) so the browser does not need to magnify them even on the largest expected screen. Overly big images slow down page loading and are a particular burden to mobile devices; however if the image has to be magnified a lot it will look blurry, blocky and pixellated, which we don't want.
Design Rule: Most body content (except tabular data) is at the top level in a single column. Reason: a screen reader for blind people may jumble multiple columns together, and on the small screen of a mobile device the content will be squeezed so you get only one or two words per line in each column, which looks really bad.
Design Rule: We use server-side includes and detached style sheets to bring in content and styles that apply to all pages, such as header and footer content. We do not handcraft these items similarly but separately for each page.
Design Rule: Our preferred way to guide our users and ourselves to produce web pages that are coherent in style, is to provide template pages and to encourage the users to copy them, then edit them with the desired content. Thus the users will rarely need to even deal with styles.
Design Rule: Because we have agreed on standards and design rules, we need not, and will not, debate these issues repeatedly on every web page.
We need to pick a HTML editor, install it for our users, and provide documentation. We have considered these editors:
This is widely used, there are University H.R. classes on it, and several web people in the department use it. However, it is only available on Microsoft Windows, and it costs money. We are currently evaluating whether it will write out a compliant web page if we prime it with a compliant template.
It is the same kind of full-featured editor as Dreamweaver. Preliminary experience with this program suggests that it is pretty good. Versions are available for Linux and Windows; it is in the SuSE distro. It has been tested and produces compliant output if given compliant input (if some default behaviors are headed off, such as dimensioning table columns in pixels).
The problem with a HTML editor is training naive users to use it. The user training issues are much less if we have them edit a flat file. If the replaceable elements of the template page are sufficiently simple and few, the flat file solution could be feasible. On the other hand, in complex documents only an expert produces decent HTML and CSS with a flat file editor.
This program is intended to lay out pages on
print media, which is opposite what a web browser has to accomplish. Word
does, however, have a feature to save as web page
. The resulting file
violates all the principles in this document, because the program is fixated on
print media. In fact, much of this document was produced by listing what had
to be fixed in a Microsoft Word web page. When we want to just solve the
user's problem
, it is very tempting to offer him Microsoft Word, but we
will forever regret allowing such bad HTML on our system.
In addition, if our pages are in the UTF-8 charset, we need to (and have not yet) identify an editor that will insert UTF-8 extended characters. Undoubtedly the editor will want to use a generic Unicode input method, which we need to learn about, install, and document.