Still, I figure there are enough people out there interested in Web design and in tech-geeky stuff these days that we at Multiactive might as well let you know the basics of what's going on. That's what this page is for. If you have no interest in the hardware and software behind our Web site, then head back to the home page. If you're interested, read on.

Contents

Web Servers

Spudwebb (main Web site)

Necromancer and Evoker (database servers)

Web Development Platforms

Mac OS

Windows

Web Design Principles

What this site is for

Page dimensions and frames

Plug-ins and compatibility

Colours and fonts

Size, tags, and testing

NOTE: Right now, this page discusses only those sites within the maximizer.com and MaximizerEnterprise.com domains, not other sites hosted overseas or recently brought into the Multiactive Software fold, such as Multiactive Software U.K. and Australia, the Multiactive home page, ecPlace, ecBuilder, List Merchant, Maximizer BusinessNet, the Brainium, or Sharkware. As we coordinate our various Web efforts more closely, I'll update this page to let you know more about those sites.

DISCLAIMER: The following text represents my opinions, not those of Multiactive Software Inc. or any other of its employees (except me) or associates, nor any kind of received wisdom. If you disagree with me, that's fine.

The main public Web server, which runs both www.maximizer.com and www.MaximizerEnterprise.com (as well as a few other things), is affectionately called Spudwebb (it also recently replaced our old server, "Shalmaneser," which was named after a computer in John Brunner's novel Stand on Zanzibar). We named Spudwebb after a basketball player who's good, but isn't especially tall.

Anyway, Spudwebb consists of a lowly cobbled-together PC, with a 200MHz AMD K6 processor, 128 MB of RAM, and a 6 GB Ultra DMA hard drive, all packed into a half-height tower case. It is connected to the Internet with an Ethernet card through our company router and a T1 connection, and lives in our lovely air conditioned server room with a lot of other computers.

How is it that such a relatively small and cheap PC can run a substantial commercial Web site that receives thousands of hits every day? Shouldn't we be using some hopped-up dual-450 MHz Pentium III Xeon box or SPARCstation or SGI or something?

Well, Spudwebb does just fine because it runs the Red Hat distribution of Linux, a free (yes, free) operating system developed cooperatively worldwide by a huge number of programmers, under the supervision of Linus Thorvalds of Finland, after whom it is named. (That's right, even though all Maximizer software runs under Windows, our main Web server doesn't. We try to pick the best system for a given job, and in this case Linux gives us great bang for the buck.)

Linux is a free variant of UNIX, the operating system standard that has been around for decades. Because of that, it is pretty obscure to use and administer, but it is also much smaller, more efficient, and stable than, say, Windows NT.

You can read a pretty good story about Linux and its inventor from Wired magazine, or an analysis column from CNN on why many geeks prefer Linux to Windows NT. And of course, Linux and Open Source Software and all that stuff are all over the tech news these days anyway, so you've probably heard some of this before.



The software that actually does the job of serving Web pages is the Apache Web server, which is also free. It's called Apache because it was originally some pre-existing Web server code modified with "patch files." So it was "a patchy" server. Ha ha.

Since I slagged Windows NT when discussing Spudwebb, you might be surprised to discover that we do run part of our Web site using NT. (Indeed, many of our other lower-volume sites, such as ecBuilder.com, are hosted on NT entirely, at least for now.) There are some things for which we find NT easier to use, such as dynamically serving database-generated information to the Web -- largely because our programmers are more familiar with the Windows environment than with UNIX. Database stuff is what two of our Web servers, Necromancer and Evoker, do.

For example, if you search for a Maximizer Third Party Product, you are actually searching a Maximizer Enterprise database on necromancer.maximizer.com.

Some spiffy code written by our MIS department turns the request from the Web page form into a search in Maximizer Enterprise, and then takes Maximizer Enterprise's results and turns them into hypertext markup language (HTML) for display on the Web (or, as we like to call it here, the "Weeb").

Necromancer runs Windows NT Server 4.0 on a standard, single-processor PC with a 200MHz AMD K6 processor, and a bunch of RAM and hard drive space. It uses Microsoft's Internet Information Server (IIS) to serve pages, as well Microsoft's Active Server Pages (ASP) technology and some custom code written in-house to interact with Maximizer Enterprise and its Btrieve client/server database engine.

Our secure Online Store runs on our secure server at evoker.maximizer.com.

That computer also runs NT Server 4.0 and IIS on a single 200MHz AMD K6 microprocessor, but uses Microsoft's SQL Server as its database engine. All the application code for the Online Store was written in-house by Multiactive Software's programmers. We hope to have some of the technology we've built there available for sale to our customers in the near future.

Power Macintosh
computers

Despite the Maximizer product line's being entirely Windows-based, some of our Web development happens on Macintosh computers. Partially that's because I've used them myself for a number of years, and I like them -- there are a number of other people at Multiactive Software who like Macs and have them at home, but somehow we only have one at the office. We may get more as our Web team grows (probably wishful thinking on my part, though).

It's also because some Web development software (see below) is only available for Macs; because we need a Mac around for dealing with files from contract designers and others who use Macs for our brochures, boxes, and packaging; and because they're easy to set up and use, especially for graphics and Web design. Besides, it's much more difficult for other people in the office to steal components from our computers when those components won't work on their Windows machines.

The Mac at the office is not made by Apple Computer, but is a SuperMac C600/200 made by UMAX, who were forced out as the last Mac clone maker by Apple in early 1998. Too bad -- the SuperMac is a nice machine. It has a 200 MHz PowerPC 603e processor, a 4 GB IDE hard drive, and 48 MB of RAM.

At home, where I spend a lot of time taking care of my toddler daughter (born Valentine's Day, 1998) as well as working, I use an Apple Power Macintosh G3/266 DT, which has a 266 MHz PowerPC 750 (a.k.a. G3) processor, 96 MB of RAM, a 4 GB IDE hard drive, and two monitors (one for HTML work, one for browser previews). Johnny, our Web graphics guy, uses a Power Computing PowerCenter 150, also a Mac clone, at home.

Both Macs run Mac OS 8.5. Software we use for Web development includes BBEdit from Bare Bones Software, SiteManager from Digital Comet, Adobe Photoshop, Adobe ImageReady and Illustrator, GraphicCoverter from Lemke Software, Macromedia FreeHand, Fetch by Jim Matthews, BetterTelnet by Rolf Braun, Nisus Writer, Netscape Navigator, Microsoft Internet Explorer, NCSA Mosaic, MacLynx, Cyberdog, and Connectix Virtual PC (which runs Windows 95 under emulation, mostly for version control and running Maximizer).

Windows 95/98/NT
computers

We also do quite a bit of our Web work on Windows machines. (Most of it, really. I only put the Macs first because that's what I use, that's my bias and, hey, I'm writing this, after all. I'll shut up now.)

None of the Windows computers we use for Web development is particularly exciting, since, except for the odd bit of Photoshopping, Web development doesn't demand very much from a computer. The machines have pretty much all been assembled by our PC Support crew and are in nondescript tower cases.

Mine, for instance, has an Intel Pentium 133 microprocessor (without MMX!), 24 MB of RAM, and a total of 3 GB of hard disk space -- very little of which is free. We use Windows 95, seeing no reason to get Windows 98.

Our main HTML editor is HomeSite by Allaire Corp., about the closest Windows equivalent to BBEdit, with some cool features of its own. In a pinch, though, we'll use NotePad or WordPad instead. For version control (keeping track of old versions of pages and preventing two people from working on a page at once), we use Microsoft's Visual SourceSafe.

Other software we use on our Windows PCs includes Adobe Photoshop, Adobe ImageReady, Adobe Acrobat, Macromedia FreeHand, Netscape Navigator, Microsoft Internet Explorer, NCSA Mosaic, Opera, WinZip, Aladdin Expander, askSam Professional, JASC Paint Shop Pro, CommNet, CuteFTP, WebTrends, and -- of course -- Maximizer and Maximizer Enterprise.

From my point of view, and it's by no means the only one, our site has several interrelated purposes (in no particular order):

1. To tell people who we are and what we do.

2. To provide information about the specific products we make (and those made by others to work with them).

3. To encourage people to buy our products through each of the means available: Business Partners, Inside Sales, Online Sales, Retail, etc.

4. To GIVE visitors information, such as FAQs, tips, specs, examples, and downloads, so that they can use our products more effectively and solve their own problems when possible.

5. To GET information from our visitors about who and where they are, so we can keep our databases of users and partners up to date.

6. To be visible and useful to as many people as possible -- and thus be optimized for different browsers, platforms, and connection speeds, as well as be well designed so people can find what they need easily.

7. To make people feel good about our company and products, so that they will come back to the site and buy more stuff from us in the future, as well as recommend our stuff to others.

As an imperfect beast, the site does some of these things well, some of them adequately, and others poorly or not at all. That is the nature of Web sites, and why all good sites are always being revised, updated, and changed. (Thus, "under construction" signs are really quite useless.)

I designed the Maximizer home page to fit into a 640x480 screen by restricting the key content of the page to a 600x300 window (to allow for browser and OS stuff in the remaining space).

It's currently in two frames: a 125-pixel-wide button bar on the left, and a full-width frame on the right. Most pages that appear in the right-hand frame use a 470-pixel-wide invisible table to limit their width, so that the total page width stays within 600 pixels or so at all times. Some content pages (mostly older ones) are wider than this, and may have to scroll left-to-right on smaller screens. We should fix that if we get time.

The right-hand content frame is not limited in length, so it scrolls. The button bar is restricted from scrolling, and thus ALL of its content MUST fit within the 300-pixel-high limit (less if possible).

The entire Multiactive Group shares a small, non-scrolling top frame on all our sites (like the "multiactive" black bar currently at the top of this page). It provides consistency across all of our sites, and links to the company home page at www.multiactive.com.

So, on our site, there are three frames: the inconspicuous non-scrolling top black bar, the non-scrolling left button bar, and the scrollable right content frame. The main content frame, therefore, should fit into a space of 475x275 pixels at first view, with room for vertical (but not horizontal) scrolling. Not a lot of room, but it's workable.

In general, links to external sites get rid of the frames, because of the danger of nesting frames-within-frames, especially if those sites link back to us. Similarly, our link to our own online store does not use frames so that security information (the https:// URL and the "locked" icon in the lower corner of the browser window) is easily visible to our visitors.

The Maximizer Enterprise site is slightly different, but works essentially the same way.

So far, the site is pretty much all HTML, GIF graphics, and JPEG images, with a few scripts (such as the JavaScript that makes the navigation buttons to the left change when you put your mouse over them) and dynamic database-generated stuff here and there. We currently use no Shockwave, QuickTime, DHTML, Cascading Style Sheets, etc.

We recently added JavaScript because of its now-broad support, but I'd like to keep it so that the site is at least useable in as wide a range of browsers as possible. You can even view it tolerably in Lynx (a text-only browser) if you like.

I'm Canadian, so I spell colour with a U, just so you know. Anyway, there are four main colours we're using these days: black, white, PMS Red 200 (rough Web-safe equivalents: #CC0000 (which I generally prefer) or #CC0033), and PMS Blue 294 (rough Web-safe equivalents: #003366 or #003399).

Web page text and background colours are a little different: before the background graphic loads, the page background is either white or a light slate blue (#6699CC). Text is black, with links a medium blue (#333399), visited links a dark grey (#330033), and clicked links silver. (That's the idea, anyway. We're sometimes inconsistent here, but generally you should be able to tell what's a link and what isn't!)

Most graphics are GIFs (CompuServe Graphic Interchange Format). Whenever possible for GIFs and all other colours such as those above, I've used Web-safe colours for flat graphics (such as buttons and banners), and either a Web-safe or a small adaptive palette for continuous-tone graphics (such as the Maximizer product box). See www.lynda.com/hex.html for details on Web colours.

The few JPEGs on the site (such as the home page header) are compressed as much as possible without losing significant image quality.

The keys to this approach to graphics are small small small size, and visibility at low bit-depths on multiple platforms and browsers. The fewer colours, the simpler the graphic, the less animation, and the more transparency used, the smaller the file. Web-safe colours look good (i.e. they don't do that nasty pixillated dithering) in most environments.

Basic body text is in a sans serif font, most often Verdana, size 2 (if Verdana is not present, I ask for Arial and Helvetica instead). Some older text is Arial/Helvetica size 3. Most headlines are in Arial or Helvetica, and if they're red, it's the old #CC0000.

Other fonts we use -- when converted to graphics only -- include Helvetica Inserat (for the Maximizer logo and other such text), Officina Sans (for text in the button bar and elsewhere), Univers Condensed and Frutiger (for some headlines and subheads), and Adobe Caslon (for rare serif-font text).

In general, I've tried to keep pages as small as possible in file size so they load fast. A good rule of thumb is to keep pages below 50K total, below 30K if possible. I break this rule on the home page, but it still loads fast enough, for reasons outlined below. Using the same graphics repeatedly is also a good trick, since each only needs to load over the network once.

I test the page from home on a 14.4 or 28.8 modem as often as possible; in case I miss some huge, bandwidth-chewing page on our speedy LAN at work, I'll spot it there. It's a good idea, in fact, to look at any page you build at 14.4 or 28.8 kbps, at 640x480 resolution and 256 colours, in both Netscape and Internet Explorer, at least, as a "worst case scenario". You can try 16 colours or 2-bit black and white too, just to horrify yourself.

We ALWAYS (unless we're dumb and forget, which is more often than I'd like) use HEIGHT, WIDTH, and ALT attributes on images. Without height and width specified for EVERY graphic on a page, the browser will wait until ALL graphics are loaded before rendering the page -- which is annoying for users. With height and width, text can flow in first, with boxes for graphics to load as they can. That way, even in the graphics are bloated and slow, people can get reading right away.

ALT attributes are useful for two reasons: (1) people who surf with graphics turned off (there are more than you might think), with text-only browsers (not very many), or who have visual impairments can use these tags to find out what images are, even if they can't see them; and (2) they provide nice little tooltip text when you mouse over graphics (at least on Windows systems). Without them, viewers might see nothing, or an uninformative message like [INLINE] or [LINK].

I'm moving towards using text links rather than graphics in a lot of places. This is partly for surfing-with-graphics-off people, partly because text loads faster than graphics, and largely because people seem to be able to find text links more easily than graphical buttons. You might not expect this to be true, but it is.

As an example, on our old home page (up to mid-1998) we had a big flashing yellow button that read "Register Your Software: CLICK HERE NOW!" (I'm not kidding -- it really was flashing yellow and said that.) At least once every week or so I would get an e-mail from someone saying, "You know, it would be really nice to have a button to register my software on your home page."

Argh.

Since the design changed and registration is now a subtle (and, you would think, much harder to see) "Register your software" text link, I haven't got a single such e-mail.

Not one.

Go figure. (See www.uie.com and www.useit.com/alertbox for more information on this sort of useability thing.)

That's all for now. If you got this far, I hope you enjoyed reading. I'm certainly glad to get all of that off my chest. If you have comments, e-mail me at webmaster@maximizer.com.