Recent and Coming Changes at Low End Mac

Over the past few months we've made some small changes at Low End Mac that we hope you've found helpful. Most of these are designed to make the site easier to navigate, and we're working on one that may give readers more control over text size.

The biggest changes over the past year have been related to ads. Where some websites are best viewed at 1024 x 768 or 800 x 600, Low End Mac has worked to keep the site accessible on lower resolution displays. We try to limit graphics to no wider than 512 pixels so they fit comfortably on a 640 x 480 display.

We have special versions of our content for Palms (160 x 160 pixels), WebTV (512 pixels and not too sharp), and printed output. We try to make sure that the site will be usable on Color Classics and SE/30s with their 512 pixel wide monitors. We deliberately stick with a white background behind our text to accommodate some older browsers as well as display on 1-bit b&w screens.

And then they go and create huge new ads - some wider than 640 pixels, some taller than 480 pixels. The skyscraper ads weren't hard to accommodate, but the megawide ones meant overhauling every page on the site. We used to display banner ads in the same space as our articles, but the new ads made that impractical if we wanted to support older, lower resolution displays.

So we moved the top banner ad, which changed the whole balance of the page. In some ways, it's a better balance now, and the page design flows to the width of your browser window - even if that's narrower than the megawide banners.

To make the design work, we ended up placing a blue bar between the banner ad and the rest of the page. This was strictly a visual device to keep the white space surrounding the ad separated from the white cell with our headline links.

About a week ago I was reading an article on website navigation, and it occurred to me that we could make good use of that space. Instead of a simple blue bar, we could create links to the most visited parts of the website. After a quick examination of our web logs over the past few months, I added links for Home, Power Macs, 'Books, and the others you can see in the above graphic. These are six of the most visited pages on our site, and now they're easier to get to than ever.

At this point, that blue strip of navigation links (which is imported using as an include file) appears on most pages on the site. In conjunction with the search box and the navigation bar on the right, we're trying to make our content as easy to find as possible - not easy with over 2,000 articles on the site.

A while back we also changed the header on our content pages, making it look sort of like a folder tab, yet not like the tabs used on the Apple website and so many copycats. We try to be a bit different at Low End Mac, and this design ties into the graphic on our home page. (We'll also be implementing a similar appearance on other Cobweb Publishing sites as time permits.)

We have the same functionality and links above the article that we have on the home page, but with an even cleaner design. Most pages inside the website have this appearance, although in some cases we might have a black background (The Apple Archive) or use a colored background at the top of the text column (Miscellaneous Ramblings) where the blue bar isn't used. (One more thing to address in the future.)

There are two other items you'll see on the above graphic. Just right of the bottom center is our new logo, a minimized graphic reminiscent of Apple's "Picasso" graphic and the happy Mac icon that disappeared in Mac OS X 10.2. We also use a smaller version of this with the letters LEM as a bullet at the end of our articles. Over time you'll be seeing more of this logo.

The second new item is something called bread crumb navigation. It appears right below the blue bar and provides quick links back to the home page, the editorial index, and (in this case) the Low End Mac Mailbag index. We're slowly adding this navigation system to various parts of the site, although it may takes months to finish the project. And once it's finished, we will probably dispense with the Home link in the blue bar, since it will be redundant.

The Text

A few times a year we get negative feedback on the monstrously huge type we use on Low End Mac - as though it's somehow our fault that some visitors find their default font size so offensive. Because that's what we display, the default font size set by your browser.

We chose to do that several years ago after a few complaints from the bifocals crowd about our text being too small. At one point we had specified the type at 12 points, and that simply didn't meet the needs of some of our visitors. Examining the issues - Macs at 12 point default, Windows at 16 in those days - we decided that the best way to accommodate users and let them resize the type (using the Bigger and Smaller buttons that most modern browsers have) was to simply use whatever default font size they had selected.

And if that didn't work for them, hey, they can change the preferences on their browser if they don't like them. We wanted to put control in the reader's hands, not predetermine how everyone should see the site.

And now we get a few letters a year complaining that our type is too big. Is it our fault that so many sites design with such small fonts that you have to set your default so big?

Still, I want to find a way to accommodate readers, just as we've already done with WebTV, Palms, and small screened Macs. And I've almost succeeded. Almost. Nearly. Just about.

I'm still tweaking things, but I've got a workable system with only one significant flaw - sometimes it displays type that should be smaller than body type incorrectly, actually making it bigger than body type. That's not good, but except for that glitch (which impacts things like our copyright notice at the bottom of the page), it works beautifully.

Best of all, it doesn't do any browser sniffing that would let us automatically determine the best type size for your setup. We don't know what's best for you. We don't care what's best for you. We want to provide a half dozen options ranging from 10 pixel to 18 pixel body type, with the rest of the styles (headers, etc.) adjusted accordingly. (For the record, although some older browsers didn't support it, modern browsers will make text larger or smaller in response to the Bigger and Smaller buttons when you specify type in pixels, making this the best way to specify type size on the Web if you're going to do so.)

The system is only in use on a handful of test pages right now, and it will remain there until we address the smaller font glitch.

We think we understand the cause of the glitch. Low End Mac is a curiously functional hybrid of old fashioned HTML and modern style sheets. The style sheets set the default font, specify the color for headlines, create links that aren't underlined, etc. Except for some of our test pages, they don't specify font size at all.

In a given paragraph, we might discuss the Apple IIGS, and the letters GS really should be set in small caps. But that's something Claris Home Page doesn't support, and I don't think it's supported by older browsers, either, so the solution is to type "GS" and set those two letters smaller with SIZE="-1" or SIZE="-2" - and that's what's causing our problem. Using SIZE="small" is no better.

Our theory is that Internet Explorer and Safari don't interpret this relative to the pixel height set in our new style sheets; instead, they seem to interpret this relative to the default font size set in the browser's preferences. This is not the kind of behavior we expected, but after seeing two browsers do exactly the same thing, we're pretty sure this is what's going on.

That said, these SIZE commands work perfectly with all the browsers we've tested as long as we don't specify a default size (whether in pixels, points, or anything else), so there's no need to change them for those who have no objections to the way our pages display at present.

The solution will be to keep doing things exactly as we've been doing them for six years now - and use the power of Cascading Style Sheets and PHP to modify things on the fly for those who choose not to use our default (no sizes set anywhere) style sheet. My second oldest son, who is something of a PHP wizard, tells me that we can have PHP parse the text files it imports and change SIZE="-1" to something else on the fly.

Style Sheets

Here's the crucial part style sheet for 14 pixel body text where we set type sizes:

BODY, H4, P, OL, DL, UL {font-size: 14px}
H1 {font-size: 24px}
H2 {font-size: 20px}
H3 {font-size: 17px}
H5 {font-size: 12px}
H6 {font-size: 10px}

Everything except headers (excluding H4) is set to 14 pixel type. Headers are a bit larger or smaller relative to the base font and each other - and we may tweak these once we've had some experience with them.

Next we need to create classes for smaller type - and we may as well add one for larger type, just in case we ever use it (which I consider unlikely):

.small {font-size: 12px}
.smaller {font-size: 10px}
.big {font-size: 17px}

And then we'll have a PHP script parse the text on our page, changing every instance of SIZE="-1" to <CLASS=small> and SIZE=+-2" to <CLASS=smaller>. If and when we have this implemented, expect another installation of our ongoing PHP and MySQL series.

Preliminary tests with our hand modified test pages look promising.

What Next?

Right now we have four versions of most of our pages. The main version is what you usually see when visiting the site. Then we have a printer friendly version, which dispenses with some of the navigation stuff and uses a different typeface that's easier to read on paper. Then there's the Mobile Edition, which is a subscriber-only option that doesn't display any ads. Our most recent edition is for WebTV, which doesn't dispense with ads or navigation, but does rearrange things to better accommodate a 512 pixel wide display on a television screen.

That's four different templates, each accessing the same text file to display the same article. It's messy. It's time consuming. It's cobbled together. And it's the next thing I want to overhaul.

The goal is to create a system using PHP that can pull together a page on the fly in any of these formats. This will have to integrate with our subscription system, too. Best of all, instead of four separate pages, each with a unique URL, the system will be able to use cookies to determine which way to serve up the page.

I've got the concept worked out in my head, and now that I know how we'll be proceeding with user controlled type sizes, I want to do this next. And, of course, share all the things we learn in our PHP and MySQL series.