It was about five years ago that I first used the Web – and four-and-a-half that I started building my own Web pages using Claris Home Page. I’ve learned a lot along the way, some of it the hard way.
Don’t Move Files
One thing you never want to do is relocate a page that anyone has ever linked to. To avoid that, you need to plan ahead. It’s a lesson I learned the hard way.
Low End Mac and reformed.net (no longer online) both started on my personal Web space on Iserv.net. When I moved the content to new domains, I made sure to leave a page on the old server pointing to the new location. Low End Mac ended up moving twice, first to mactimes.com and later to lowendmac.com. Each time I moved it I also made some organizational changes.
That got messy, but part of it came from not planning ahead. For instance, I had all the compact Macs in a directory named “plus” for the Mac Plus and all the Centris and Quadra models in a “040” folder. Nowadays the compact Macs reside in “compact” and the Centris and Quadra models are in “quadra.”
I did send email to all the sites I could find. I detailed exactly how they could update all their lowendmac.com links. To this date there are undoubtedly bad links to the domains where LEM once resided.
When You Move Files, Redirect
The clever trick I learned this year (yeah, I’m a slow learner) is setting up an automatic redirect page. Here’s the code:
<HTML> <HEAD> <META HTTP-EQUIV=refresh CONTENT="0; URL=http://lowendmac.com/2000/beyond-the-box/"> </HEAD> <BODY> </BODY> </HTML>
Half of that is the minimum code you need to put an HTML page up, and the long line tells the browser to go to a specific page after 0 seconds. That way any link to the old location will automatically send a visitor to the new page.
Plan Ahead
A lot of the above could have been avoided by planning ahead, but I never had any idea things would get so big. (How big? Around 5,000 files.) I’m learning and making changes on the fly.
For instance, I used to just throw graphics into the same directory as the page itself. It works, but that also makes for unnecessary clutter. Now I generally create an “art” directory and keep all the GIFs and JPEGs in there.
I used to give all my editorials meaningful names, but go back after a year or three and try to recall when you wrote a piece and what it was about from the name “economy.html” – was I writing about the national economy, Apple’s economic outlook, or the economy of using a Mac?
After four years, I’ve about given up on that. When I started getting additional writers, I began numbering columns. Evan Kleiman‘s were evan01.shtml, evan02.shtml, etc. Still later I began using the date instead of the next sequential number, so an article going up today would be 010703.html of 2001, 7th month, 3rd day. It didn’t tell me what an article was about, but at least I knew when it had been posted. From there I could go to the index.
Not too long ago I began archiving old content to a separate folder on a separate partition on my Mac. For the dated articles, it was easy. For Charles W. Moore’s Miscellaneous Ramblings articles, I’d create a “misc” folder and fill it with folders for each year. Then I’d drop all files starting with 99 into the 1999 folder and all files starting with 2k into the 2000 folder.
For the other writers it was easy, but all of my files still had names. I had to open each article, check the date, then store it in the correct folder. That took quite a bit of time.
About a month ago I decided to go a step beyond that. I create an “01” directory as I post new content for my writers, storing new material in there for the rest of 2001. File names are shorter, since the year is no longer necessary. For instance, if this article were posted under Mac Musings, it would be inside the 01 directory within the musings directory. Each 01 folder also contains its own art directory. Once I’m ready to archive 2001, most of it will be simply dragging the 01 folders to the proper places in the archive.
I wish I’d thought of that a lot sooner!
[Since moving to WordPress in early 2013, everything got a lot easier. We no longer need be concerned with the length of file names or cryptically encoding the date as the file name. The format is domain – year – name of article. For instance, “iMac iMproved” by Evan Kleiman is at <http://lowendmac.com/1999/imac-improved/> That’s a lot less for me to deal with.]
Archive
Claris Home Page is a great program, but the more files you have, the longer it takes to open the upload window. That’s the reason I decided to archive old articles to another folder on another partition. By cutting the number of files in half, the upload window loads a heck of a lot faster.
Rant: Excessively Long URLs
I use a pretty flat structure for Low End Mac. Root directory : Content directories : Art and “01” directories : Art within 01 directories. I don’t think anything is more than three levels from the root. It not only makes it easy to find things, it also keeps the URLs short.
I’m not going to pick on anyone specifically here, but I just don’t understand URLs like these:
http://www.domain.com/oped/Editorials/Archives/ed_phils_schultz.html
We have the domain, an oped directory, an editorials directory, and then an archives directory. Then we get to the name of the page. It makes me wonder, is there a non-editorial directory within oped? Are there editorials that aren’t in the archive?
http://www.domain.com/bwdaily/dnflash/jun2001/nf20010627_874.htm
This one’s not too bad. I have to assume the publisher knows what bwdaily and dnflash mean. There seems to be some redundancy using a jun2001 folder and including “200106” within the filename, though.
http://www.domain.com/articles/2001/06/20010629135334.shtml
Except for the filename, I like this. It’s obviously an article published in June 2001. But why does the filename also include the year, month, and date, followed by six other digits? At the very least, “29135334.shtml” should be adequate here.
http://www.domain.com/v3/story/1,1017,6886,00.html?tag=81&sb=124
The above was obviously cobbled together by some sort of publishing system that doesn’t care if anyone has to actually type in the code or decipher things. It works, but it’s messy. And the above examples are nothing compared to some of the monstrous URLs I’ve seen.
I like compact URLs. If we ever go to a publishing system at Low End Mac (I’d like to do that someday), it will have to use short, meaningful URLs that have meaning to more than just a computer. [WordPress does that and gives you lots of options to customize things.]
Searching and Navigation
Create as logical a navigation system as possible, but realize that at some point your site might become so large that it’s hard to find things. At that point, you can try to simplify navigation (I’ve done that two or three times), hope for the best, or add a search engine.
I’ve used both PicoSearch and Master.com, free site indexing services, to index and facilitate searches of the site. Neither was perfect, but they generally did a very competent job of helping you find things. The price is right, although both hope you’ll grow to the point that you graduate to their paid service. [Google is even better.]
Rant: Navigation
Ever go to the IRS site looking for the address a business should use to mail in a payment? If it’s posted, you probably won’t find it. I certainly didn’t, nor was their search engine any help.
Working on digigraphica.com, my [defunct] digicam site, I found Sony’s site was also pretty messy to navigate. Using JavaScript or something, menus would pop up after I selected a main category and while the next page was loading. Not good.
Compact Code
I use an old program, Mizer 1.3, to compress the HTML generated by Claris Home Page (CHP). CHP is a nice program, creates very compatible code, but also generates a lot of bloat. An average Low End Mac page loses 25% of its size after Mizer removes unnecessary spaces, line feeds, and quote marks. (iCab may complain about the missing quote marks, but every browser displays the pages properly.)
Thanks to Mizer, I can upload files faster and you can view pages more quickly. Although Mizer is no longer available, there are other HTML optimizers on the market. Roughly 65% of our site content is text files, which was about 10.5 GB last month. Without Mizer, we would have server an additional 3.5 GB.
[We’ve been doing what we can to reduce the file size of images as long as there is no loss of quality using the excellent ImageOptim program. And since we’ve moved to WordPress, we have no control over the size of our text files.]
Recycled Code
Confession: I don’t know HTML. I just want to write, design, and publish, depending on Home Page to do all the tedious work for me. Well, at least most of it.
Some years ago I learned about Cascading Style Sheets (CSS) and Server Side Includes (SSI). Both have helped me create far more compact files.
With CSS, I can define the font, size, color, etc. for various types of text. I can put this in an external file and have any page on the site link to it. Any page so linked will display the same fonts, link colors, etc. Best of all, I no longer have to specify fonts within each individual file – which meant for each paragraph! By using CSS, I probably reduced file size by 25-30% just by removing all the font name tags.
It took some experimenting to find out what works across browsers and what doesn’t, but I learned the hard way what worked with both IE and Netscape – and what didn’t. Best of all, CSS doesn’t mess things up for older browsers that don’t support Cascading Style Sheets.
Server Side Includes are a different kind of file, fragments of HTML inserted into a page on the fly by the server. With SSI, every page on the site can link to the same footnote about copyright, ownership, and trademarks with just a short snippet of text. I can’t count how many ways I’ve used SSI, but examples include the footnote, the navigation menu on the right, and links to recent articles. It keeps files small and means just updating a single include file (sometimes two) to make a global site change.
Support Most Users
JavaScript is slow. Older browsers don’t support frames. Some people surf the Web with just text. A few even visit my site using the old compact Macs with 9″ black & white screens. For their sake (this is Low End Mac) I avoid anything that will break the site with older browsers.
Well, almost. There is a version of Netscape that has a problem when you have a table in front of a colored or patterned background. Other than that, I’ve done my best to support as broad a range of users as possible.
I have no way of testing the site under Windows or any version of Unix, but I figure they’ll let me know if there’s a problem. I don’t sweat the few WebTV, BeOS, Amiga, and OS/2 users out there. Here’s why:
- Macintosh, 48.5% of requests, 51.6% of bytes, 47.2% of pages
- Windows, 46.1% of requests, 40.8% of bytes, 44.1% of pages
- OS unknown, 3.2% of requests, 5.4% of bytes, 6.4% of pages
- Unix/Linux, 2.1% of requests, 1.9% of bytes, 2.0% of pages
- everything else: less than 0.2% of all requests, bytes, and pages
Who are “OS unknown”? Some of them are probably Palm users, since we create a daily “mobile edition” of new editorial content. This is created in a format similar to AvantGo’s, but without their restrictions. About 20-25 users upload the mobile edition of Low End Mac each day. [WordPress does the same thing for smartphones using the Jetpack by WordPress.com plugin. Recommended.]
These folks mostly get the same editorial content as Web surfers, but sometimes we strip out large graphics to speed up download times and make them work better on the small screens of Palms and PocketPCs.
Instead of creating “Best with Navigator” or “Best with IE” content, we’ve gone out of our way to use standard HTML to make the site broadly accessible. To the best of our knowledge, our design works for at least 99.8% of our visitors. We even try to avoid graphics wider than the 9″ screen on a Mac Plus can display. [No longer true, but you should have no trouble viewing any page on Low End Mac using an 800 x 600 or larger display.]
(And all of you who design and test exclusively on Windows, please avoid using text so small that Mac users can’t read it. Worse, if you designate it as a specific number of points or pixels in size, our browsers won’t enlarge it. Thanks!)
Rant: Frames
For the most part, frames are a wonderful tool. Where they fall down on the job is the one place that’s really important to a webmaster – links. Simply put, frames make it nearly impossible to easily link to a specific frame on a site you’re visiting.
Rant: Plug-Ins
I get a bit peeved at sites and ads that use JavaScript – they can really slow things down on a Mac or older PC. I don’t care for most of what’s done with Flash, either. Too much show; too little content.
Rant: Splash Screens
Finally, what’s up with splash screens? They look pretty, take time to download, and do nothing to improve the surfing experience. The best take themselves out of the way before automatically taking you to the real home page; the worst require you find whatever needs to be clicked to go forward.
Designers may think splash screens are great toys, but that’s all they are. If I want toys, I’ll buy a Gameboy or a Windows PC. If I want information, I want your real home page, not your “gee, we’re cool” splash screen.
Our Web Design Series
- Using Include Files
- Site Organization
- Cascading Style Sheets
- Site Graphics
- Web Content To Go
- Reading Your Web Log
- Redirects, Naming Files, and Some Rants
Keywords: #webdesign #html
Short link: https://goo.gl/5Z6aCV
searchword: #webdesign
