St. Germain is a medium sized investment firm with offices in Springfield, MA and Hartford, CT. Their internal marketing team realized that their existing site wasn’t portraying the right image. The existing site was not only old, but needed to be updated to make sure the company was adhering to all the required requirements.

The new web site is what you might consider a “standard” web site for 2007. A few dynamic elements (like news and file management for the client), and a solid standards-based web design. Our goal was to create a site that looked clean and professional and pulled elements from their marketing materials.

Responsibilities

From the project kick-off I handled all of the responsibilities of this project including project management, graphic design, database design, and PHP programming.

Visit the St. Germain web site

The core need of a CSS scripting system is the need for a color substitution system that would streamline color selection for the web sites I’m working on. Most of the other scriptable CSS systems do exactly that, so we’re not breaking new ground here. Since many of the sites I work on are high bandwidth, heavy usage sites, I need to minimize the server hit as much as possible. Reducing external files, and limiting the calls to the database and PHP are the name of the game here. My tertiary concern is to make the editing of my scripting system as easy and transparent as possible.

Avoiding the Overhead

The issue with many of the other “CSS scripting” systems is that since they rely on PHP at run-time the files need to be processed through PHP each time they are loaded (which means there is additional server load, as well as additional non-CSS code buried in the file). Another (minor) issue is that all of your CSS files also end with “.php” which can make management problematic (especially because chances are your text editor is going to use its PHP syntax highlighter instead of its CSS highlighter). I wanted to avoid all of these issues. The solution here is simple, we compile to CSS once and load the “true” CSS file each time the page is loaded.

How Does it Work?

The core of the CSS scripting is a file I called the “FCSS” file. Because this file is not a PHP file, I can set a rule inside of BBEdit (or other editor) to use CSS syntax highlighting. I built a PHP helper function for my XHTML pages that inserts the correct XHTML code on the page to load my CSS file. I do this because my scripting system runs in two modes: “production” and “testing”. In testing mode my script attempts to compile the FCSS to a normal CSS file. In production the system circumvents the FCSS file and loads the compiled CSS file. This means that PHP is only loaded when I’m testing the CSS on the site, but when the pages get rolled out to production only the compiled CSS pages get called.

Syntax

The syntax inside the FCSS file is simple. I have adopted a function style syntax that allows me to use regular expressions inside my scripting engine to find data that I need to act upon. To support my primary goal, I have created a function called “color”.

Color Substitution

At the most basic level I wanted a system that would allow me to create a named color that I could use across all of my CSS files. For instance I may want to assign the hex color #c312F0 to the named color “background”. This would allow me to create a dictionary of color for each site that would allow me to quickly select the right color (and make global changes easily).

Within the config file for my web site I define an array of name/value pairs for colors I want to use for this particular site. The colors are passed off to the CSS scripting engine to be used

Color Calculations

Having a dictionary of colors used on a site is handy, but really not super useful (how many times will you really need to know the color of the background?) Being able to modify those colors on the fly would be very helpful. For instance perhaps I might want to make a popup box a darker version of the background color, or maybe I want to take the link color, rotate the hue and set that color to the link visited color. You can see how powerful having the ability to calculate colors would be.

Why stop there though? Why not give the author the ability to mix two colors together? Maybe take your background color and mix in a little bit of the link color to give the site credits a subtle look?

Instead of opening up Photoshop (or some other tool) and mixing the colors together, putting it into your CSS file, then testing it, you can write:

p.credits{color:color(background,m:link:25);}

…and if it’s not quite right, you can tweak the colors, and refresh the page until it’s perfect.

That is the power of scriptable CSS.

Down Sides

There are a few negative side effects of this system. The biggest issue is that you need to make sure that Apache has write access to create (or change) the compiled CSS files. Part of my script checks this and attempts to alert the user if there is an issue. A secondary issue (although only for some) is that using this compiled css, you lose the ability for run-time changes (although this can be easily overcome with a trigger on my PHP helper function). Honestly though, CSS doesn’t need real-time scripting. It’s not its job. That is what JavaScript is for.

ForeSite has partnered with the Hartford Business Journal on a variety of projects over the last few years, so when the HBJ decided to build a new web site from the ground up, ForeSite was there to lay the groundwork.

The original HBJ web site was a simple affair. The design stood, unchanged, for more then five years. Every page was still manually edited, and the content was very limited. Working with ForeSite, a specification was built to create something special that was more befitting the newspaper. The new site was built to be managed dynamically so that the HBJ staff doesn’t need to write a single line of HTML to keep it updated. In addition, it was the goal of the HBJ to move from weekly information (where they’d update two articles each week), to daily and even hourly information.

Features

The HBJ site was an ambitious piece of programming. Although we could have found an off-the-shelf CMS system that could have done some of the things we wanted it to, we decided to write everything from scratch. In the end, this was the right decision. The system isn’t overloaded with features the client doesn’t use, and the interface is straight forward and written specifically with the HBJ in mind.

News articles can be automatically important from the source Quark documents. This means that the HBJ staff doesn’t have to spend time copying and pasting text. The system manages a lot of the grunt work for them (although human oversight is needed for verification).

Responsibilities

ForeSite built everything end-to-end, including a user-friendly CMS back end to allow modification of the site. I was responsible for the front-end look-and-feel including: site design, XHTML & CSS coding, and the majority of the JavaScript work. I was also worked with the primary developer on some of the back-end PHP coding.

Although it can be frustrating and annoying, it also gives a designer/developer the freedom to avoid getting mired in the details of the interface (even though many of us love designing interfaces). Taking a page from the corporate world (no pun intended), establishing a set of rules can make a developer’s life easier.

These rules should be created for two important reasons. First, working with other designers and developers becomes easier if they are all working from the same playbook. Second, by providing the rule book to the client before work begins, the client can feel better about the decisions of the developer (they will know that the process has been well thought out, and that there is a reason for the decisions of the developer).

Starting Out

Any developer that has been asked by their client to explain why he/she did something in particular already knows a number of the rules that should be established. I broke my own rule book into six main sections:

• Overview
• Design
• Accessibility
• Usability
• Browser Compatibility
• Coding Practices

Coding Practices is by far the largest section. It includes six sub-sections (General, HTML, CSS, JavaScript, Database, and PHP).

Building on a bad thing

Every time that I run into a conflict with a client or another developer that isn’t covered in my manual, I/we decide on a solution, and it goes into the manual for future reference.

Evolve the rules

Every so often (3-6 months) I read through my rule book to make sure I agree with everything in the rule book. For instance, one of my rules is minimum screen size. In my last read-through, after a little investigation, I decided that 1024×768 is the new minimum size that I would begin working within.

Samples

Here are a few rules from my book:

• All code/layout for publicly accessible pages should be built so that Internet Explorer 6.0, Firefox 1.0, and Safari 1.5 all act similarly.
• CSS styling should only be implemented using linked files.
  • Inline styles should not be used
  • Style definitions in the head of the document should be avoided.
• Forms should always be validated on the server side.
  • JavaScript form validation is a nice extra, but data from the client should never be trusted to be valid.

When the Hartford Stage needed someone to redesign their aged web site, ForeSite answered the call. I designed a new look for their site, before ForeSite had even presented a bid for work. In the end, ForeSite lost the bid for the design work, but were kept onboard for the heavy lifting.

We teamed with the highly creative Adams & Knight to develop the new site. Adams & Knight were responsible for the design of the web site and the team at ForeSite did everything else. We built a variety of systems that allowed the staff at The Hartford Stage to easily modify content (the content of the entire site can be changed easily, most of it from the web-based tool that we built).

My primary responsibility was to act as the bridge between Adams & Knight’s design and ForeSite’s development. Most of this work was turning a design (built in Quark) into a proper web based template that matched the vision of the designer at Adams & Knight but didn’t resort to hacking and tables to make it work.

Responsibilities

ForeSite’s main responsibility was the “heavy lifting”, we had no control over graphic design and very little latitude for “coloring outside of the lines”. We just had to “make it work”.

I was responsible for the layout of the site and a significant amount of the PHP/mySQL work.

Visit the Hartford Stage Company web site

The Tennant Capital Partners site was a joy to work on. The client knew exactly what they wanted, and was able to communicate this to the team at ForeSite. Without hesitation I was able to craft a design that fit the client’s vision. From design to template to final web site happened in less than two weeks. Although the design is unadorned, it perfectly matches the company image of no-nonsense and getting straight to the point.

Responsibilities

Because the vision from the client was so clear, the mockup of the Tennant Capital site came together fairly easily. Since the site was static (I only used PHP as a template engine), it also came together without significant difficulty. This may have been one of the easiest projects I’ve ever worked on.

Visit Tennant Capital Partners web site

One of the challenges for Marathon is that the corporation is still very young (and yet very large). The company has been wildly successful, and concentrating on the business has been the overriding priority. As a freshman company, Marathon’s image was undefined and finding it has proved to be a difficult process.

Marathon hired a 3rd party design firm to build marketing materials, but asked ForeSite to design the web site (but requested that the site be based on the look of the marketing materials). I suggested that we start simple and proactively build (or rebuild) the site as the requirements arose.

The Intranet

Possibly more important than an external marketing web site, was the need for a company intranet to share information across eight locations and hundreds of employees. Although we could have picked an off-the-shelf solution, it seemed as though none fit the requirements, particularly the idea of simplicity.

Expanding on original ideas I had built for Skinovative, the team at ForeSite built a custom intranet solution.

Responsibilities

I was responsible for all the front-end graphic design, XHTML construction, Flash development, and JavaScript programming. Additionally I wrote a significant amount of the PHP code.

Visit the Marathon Healthcare web site

In 2006, Skinovative decided to spin-off its internal training classes into a secondary business. The curriculum was mostly written over the years training Skinovative employees, but now a marketing site needed to be created. Of course, the site also needed to allow students to register and pay for classes online.

Building the classroom

As a second part of the process, I needed to take the existing training system that I built for Skinovative, add a number of features and re-brand it.

Responsibilities

I was responsible for all the front-end graphic design, XHTML construction, and JavaScript programming. Additionally I designed the database (mySQL) structure and wrote a significant amount of the PHP code. This was one of many sites that I was also acted as the project manager.

Lately I’ve been working for a unique client that understands the importance of accessibility, but they view it as a black and white issue. It’s not entirely their fault, but that’s a rant for another day. The core problem is that they equate accessibility to making a site usable by people using a screen reader. If only real accessibility were that easy.

Making a web site accessible for those who can’t see pixels on the screen is important, but for every blind person using a computer, there are (probably) dozens more that we also need to think about, the gray area. These are the people who may have difficulty reading the average well-designed web site. Accessibility for these people is as important as accessibility for the sightless.

These are the people who don’t need a “skip to content” link, but need high contrast, large text pages that are easy to navigate. Liquid layouts and clever design will get you part of the way there, but ultimately, to provide real accessibility you’ll probably have to create an alternate format that these users can use.

So, in the interest of accessibliity, you’ve carefully crafted a primary style and it’s gray area cousin. Your code is clean and accessible, so finally you can step back and admire your beautifuly accessible site right?

Well… almost. You’ve done the legwork, but there is still one major accessibility (and usability) problem. How do you get your gray area users to their version of the site? It’s doubtful the client is going to go for the idea of putting a big black and white button next to their logo advertising the alternate version of the site (it’s not that important to them). There’s really not a place for an accessible link in your standard site design. If only there was a way that we could detect those users that would require the alternate version of the site without the requirement of a link to initiate the switchover.

Introducing Auto Style Switching.

Most average users tend to keep their browsers set to the default font size because this is what most developers design for (or maybe it’s the other way around). Our gray area users have the option to increase the font size globally on all web sites. Those who need a larger font only need to tell their browser to user a larger font.

Using a bit of Javascript we can detect the size of 1em in pixels and judge it’s size relative to the default. This isn’t an exact science since there will always be a variation between browsers and configurations, but we don’t need to be pixel accurate here. If it is beyond a threshold we trigger our high contrast style sheet (using the script by Pault Sowden).

See it in action

Handling the Resize

Although the majority of users will be entering our site with their font size already set to their liking, it is certainly possible that a user might change their font setting after already loading the page.

In Internet Explorer, changing the text size reloads the page (therefore trigering the window.onresize event). So, we could just add that to our initialization:

 window.onresize = window.onload = checkContrast;

Of course it’s never that easy. Safari and Firefox don’t seem to trigger any DOM event so there is no way for us to find out if the text size has been changed.

We could call it a day and accept that we’ve provided support for the majority of users, or we could use setInterval to check our text size a few times a second as a work around. It’s not very elegant, and it almost crosses the line into what might be considered a “hack”, but the setInterval solution is the only one that works for all browsers.

In the end I opted to be as accessable to as many people as possible, which means using the setInterval solution. I check the test area five times a second which should be often enough to provide reasonable feedback, but not so often as to make much impact on our available processor cycles.

See it in action

Allowing Users the Choice

As a last step we should add a link to our site that allows the user to toggle the style that they are presented with. We can work this into our design now without too much fear that those who need it won’t be able to find it. This has been covered in many places, so it’s not really worth reexamining it here.

Variations On a Theme

You don’t need to use the text size to trigger style sheet changes, you could trigger any other interface. Perhaps instead of switching styles, you present a dialog notifying the user of the alternate style, or even send them to a different location.

Additionally, we don’t need to create a binary switch between normal and alternate versions of the site. We really are in the gray area of accessibility. A clever developer can use the realative size difference to adjust the site, triggering variations based on font size using different style sheets, or directly changing the styles of elements. What would you do?

Advertising agencies, PR firms and graphic artists are talented people with creative ideas. They are knowledgeable in their field, and produce quality work, however they are not web designers*.

The problem

The core of the issue is the reinforcement of bad habits. They think they know how to design a web site, because they’ve done it (they think successfully) a dozen times before. The typical top-down flow doesn’t allow for these bad habits to change. At the bottom of the work flow is the web designer that is saddled with a poor layout that must be implemented as outlined (because it’s been approved by the client).

The lose-lose situation

Because the web developer is usually forced to “make it work”, the agencies aren’t required to make changes (or learn what is the “right way”). A poorly designed format can force a developer to spend much more time trying to meet the expectations of the client and the agency.

Beyond that the final design will be weaker because the DNA was transplanted from a brochure or a newspaper ad. Vital concepts like usability and accessibility are ignored.

How it should work

Building a web site should be a collaborative effort, not a top-down hierarchy. If working with an agency is required, the agency should be responsible for the overall branding, but the web designer should be responsible for the specifics.

The web designer needs to be part of the creative process from the project kick-off, so that any issues or pitfalls that occur in the process can be solved before the client approves the format design. The greater input the web designer has in the development of the format, the easier it will be to develop the rest of the site (and the better the site will be).

Disclaimer

I know that there are advertising agencies and graphic artists that do understand how to design for the web (properly). It is too bad that those agencies are the exception and not the rule.

* In this case, I am defining the web designer as someone with the ability to create a look for a web site and turn that into valid HTML/XHTML code.