3 - 7. Deployment and Maintenance

I've recorded all the design issues and completed execution. However, a funny thing happened on the way to the forum... No design or program is ever complete. It's always a step in a direction, maybe not the direction the original programmer envisioned, but it's always a step in some direction. The fact is that things rarely go the way they are intended. The future is unwritten and the gap between what's here today and what will be tomorrow is frequently where some pretty interesting stuff happens. With that in mind, I offer this page though I have nothing... at this moment, to report.

But I will...

Production Server Deployment

We're taking the design live. In theory, that's a straightforward matter of pushing buttons. Stay tuned.

I've started to do some analysis on Google Analytics. I've worked on a couple websites that were using it and the feedback on browser versions, flash / java, etc. is invaluable information. So I've finally bit, but I'm also conducting an experiment on this page to implement them better. The GA walk through for getting started, signs you up for an analytics account and gives you a pair of script tags that you simply copy and paste into the bottom of your webpage immediately before the </body> tag. However, inline JavaScript is a violation of best practices, specifically Separation of Concerns. This is my most important rule, so I've taken the first script and simply unescaped it into a direct call to the off site Google script ga.js. One down. The second script actually runs code, so I moved it to a new .js file, wrapped it in a function, and I'm calling it with an addLoadEvent, just like I call the clock in my Earth Chronicle Javascript library. We'll see how this goes. However, even if it works, I'm a little nervous. There are a number of websites that discuss unobtrusive analytics, each has their own take on it. And from one month to the next various ones "vanish" from the Google rankings... not on page 1, not on page 5, not "anywhere" that I can find. To say this makes me nervous is a bit of an understatement, so I'm conducting this test only on the 3-6 and 3-7 pages. Hopefully the limited scope will work in my favor as I try to query for a more official answer. I've posted on the blog run by Matt Cutts. I'm hoping he'll reply "Sure, you're fine." or "Good God! Don't do that!" or something. If you're interested in SEO, it's a fantastic, quasi-official Google resource.

Image Makeover

I've made several image related changes. First, the current crop of browsers are showing less content above the fold than the older versions I develop on. While I decreased whitespace in the header, I was able to dig a little more out, between the navbar and the header gallery. I also positioned the gallery and navbar in em so that they scale a little better; pixels worked well previously, but with them in such close proximity, ems gave me a more reliable cushion between the two, regardless of the zoom or text size. I hadn't been able to achieve this last page because the page border was riding over the gallery images. This time, instead of citing only the #headerWrapper div, I noted the selectors for the link (#siteId a) and the #gallery div explicitly in the z-index: 5; style rule. That seemed to do the trick.

The Ayer Stain just couldn't quite cut it. I like the touch it provides, but the execution just never quite came together... and I gave it more than a fair shot. This is a tricky thing to pull off in a fluid layout. So I went back to the drawing board, and tried to work with the bands of discoloration that occur in the Topkapi scroll.

I was surprised how quickly that came together. For one thing, the color is almost dead on for my bright ivory, almost too close considering that this is supposed to be a discoloration. Then I just needed to extend the right and left margin so that the image went pixel perfect from the edge of the page on one side to the other. Now that I'm using left and right margin, they balance and I don't need corresponding padding to keep the accessible page links centered. Of course, the IE6 specific style sheet still removes this background, so that I don't have to worry about that. However, to give IE6 (and monitors wider than 2000 pixels) some care, I revised the underwriting a bit. In large monitors (and IE6 has no page border so the background takes center stage), you can see noticeably how the underwriting lines up in columns. So I took two page backgrounds without text and stuck them next to each other as one image, and then blended underwriting much more subtly across that whole width. So the repeating columns in the design are now twice as wide and much less noticeable.

Validation

Note for the day. Only list items can be nested as first children of list tags. The credits section turned out to be completely invalid. I'd marked it up as a definition list, but I also needed to be able to group the dt / dd pairs inside a container in order to apply a smooth "row" background to them. I wrap them in a div which caused the W3C validator to freak out. So I turned the <dl> tags into <ul> tags and the container divs into list items. Then paired an h4 element (to declare the position title) with a cite element (to declare the person or date).

This is valid, semantic, and if anything looks nicer. I did cheat, I've applied custom margins for each side of the h4 and cite elements instead of the blanket 0.5em margin on everything. These changes also affected the typography. The h4 is styled like all other h4 elements, which is the same set of fonts that I had been using for the names and dates. Therefore, I'm using the standard body copy fonts for the names and dates. So far so good. However, the display as the browser becomes narrow quickly causes problems, at the original width of 45%, the #postingDates div drops underneath the #credits div. However, I was able to control this behavior cross-browser at all zoom and text sizes by resetting the width to Φ, 38.26%. Now, the divs stay side by side until the display is so narrow that it's better for them to stack one above the other.

I also had some h3 elements in other lists throughout the demo that were not nested inside an <li> tag, so I fixed those. Other than that, the validation tests went very well and amounted to correcting typos and silly things like that. The only items left are the tabindexes on my inpage link targets, and if you "fix" those, you lose keyboard navigation in Internet Explorer and to an extent in Firefox as well. Thanks, but no thanks.

As a last moment item, I also ran across a nice looking drop cap in a story book. The drop cap does not rise above the line, like the references I used; the rest of the word is aligned with the top of the drop cap allowing severl lines to wrap next to the drop cap. As I expected, I was able to achieve with look with a simple float: left; declaration. This gives me an attractive drop cap while matching up the real and apparent top of the content section. Unfortunately, the behavior in modern browsers is to creates a border a left padding that stretches to the left edge of the screen. On a hunch, I tried turning the text-indent property of an initial paragraph to zero, and it worked fine after that. I also tried lists again, and with the current CSS, I get bullets or numbers on top of gold leaf; I simply turned the list-style-type of any initial list to none. This isn't ideal, but for now, I want my drop cap. An initial list should be rare enough for an introduction that I'll have time to figure out a better styling solution before I actually have to do that.

Optimum words / characters per Line

I took the time to do some research on text readability. Graphic designers are notorious for citing "it's complicated" because of leading, text size, and many other issues. However, no one cites anything higher than 60 characters per line, which comes out to around 30em width for the body content container. In a web design this comes out... Narrow. The standard body content is just too narrow, no way around it, especially as monitor resolution increases the main body starts to look like a fixed width layout centered. This starts to create issues on a maximized 1024 pixel wide display which is the smallest thing in use. I tried a lot of variations, and I've settled on this. I have applied a 30em width on the #mainBody div, at ultra narrow widths, like mobile devices, the right and left margins of about 50px keeps the text on the scroll. I increased the body copy font-size to 1.3em which makes the layout look normal for 1024 to 1280 screen size ranges. They'll get lines of text which runs most of the width of the window and have line lengths just a bit larger than optimal (60 - 65 characters per line). This range will also be important for any browser not maximized in the monitor; conservatively this configuration is how 50% or more of visitors will see the website. I suspect that 80% is a more accurate figure so that's who I've optimized this technique for. However, as the design expands in high resolution monitors, the lonely column in the middle of the screen just looks awful. I've therefore used the golden ratio (Φ, phi) to apply a min-width: 61.73%; declaration, so that the design scales out to look nicer. I'm sacrificing optimal line length to adapt to the look of these large monitors, but I've accomodated ideal line lengths better than any other websites these users will be looking at, so it should still be "more readable" than what these users will typically find on the internet.

Subjects:

• Core,
• Core