Responses to email might be slow for the next week or so. Geoff is taking some well-deserved time off, Tonya’s battling article deadlines and a sore neck, and we have family coming to visit. In other words, real life once again intrudes on our little make-believe computer world, and it’s good to come up for air and work on keeping things in perspective. [ACE]

Mailing List Update — We recently added a Web form option for subscribing and unsubscribing from the TidBITS list, but since many people have trouble configuring their Web browser email preferences, those who use the form interface will receive an email confirmation, which must be replied to in order to confirm a subscription or signing off. In theory, this technique will ensure that subscribers use proper email addresses, thus reducing the hundreds of bounces we receive from sending out each week’s issue. [ACE]

<http://www.tidbits.com/about/list.html>

System 7.5.4 Update — According to a memo posted on Ric Ford’s MacInTouch site, Apple will release System 7.5.4 Update later this week on all the standard Apple Web and FTP sites. The memo says the update primarily consists of performance and reliability enhancements, and will only install on Macs currently running System 7.5.3. Most interesting for owners of older Macs is the statement that "With the release of System 7.5.4 Update, Apple is delivering its final system software release for the Macintosh Plus, SE, Classic, Portable, PowerBook 100, SE FDHD, SE/30, LC, II, IIx, and IIcx. These computers were not designed to support 32-bit memory addressing. Future Mac OS releases will require 32-bit memory addressing, which is supported by all other Macintosh models." [ACE]

<http://www.macintouch.com/754announce.html>

Microsoft Internet Explorer 2.1 — Last week, Microsoft made Internet Explorer 2.1 available. The new release adds support for frames, including floating frames, and (in a welcome move) adds an option to turn off frames and plug-ins. Most of the other enhancements focus on the History and Favorites features, along with feedback and performance enhancements. Useful features in Netscape Navigator that Internet Explorer still lacks include zooming the page only to the size of the largest page element, and Netscape’s URL guessing capability that allows users to enter "apple" and have the browser guess at "http://www.apple.com". Download sizes range from 1.7 MB to 2.3 MB, depending on the version. [ACE]

<http://www.microsoft.com/ie/download/>

<http://www.microsoft.com/ie/download/mac21.htm>

Cyberdog 1.1 — Apple has released Cyberdog 1.1, their set of OpenDoc-based integrated Internet tools. Cyberdog 1.1 requires the just-released OpenDoc 1.1. Changes and enhancements since Cyberdog 1.0 include 68K (68030 or better) support, support for AppleTalk browsing and mounting of AppleTalk volumes, support for Netscape plug-ins, minimal scriptability (including support for the GetURL AppleEvent), and numerous other minor interface and functionality enhancements. In an ironic twist for the document-centric OpenDoc, Cyberdog 1.1 includes a Cyberdog application that opens your default notebook, allows all Cyberdog 1.1 documents to open in a single process, and accepts drag & drop of Cyberdog documents. The Cyberdog 1.1 download is 3.4 MB, and OpenDoc 1.1 is another 2.8 MB. [ACE]

I’ve just found a neat little program that Macintosh webmasters might appreciate immensely. Written by Stephen Turner and called Analog, it’s a free Web log analysis program. That’s not unusual, but Analog stands out from others I’ve tried (WebStat and its newer cousin ServerStat Lite) by being blindingly fast. On a Power Mac 6150 that was running all my standard Internet servers, Analog processed a 17 MB log file in 2 minutes, 24 seconds.

<http://summary.net/soft/analog.html>

<http://www.statslab.cam.ac.uk/~sret1/analog/>

For those who don’t run a Web server or haven’t bothered to analyze their logs, a Web log analysis program scans through your Web log and provides basic reports, including (at least for Analog) the following:

• Number of pages requested per month
  
• Number of pages requested each week
  
• Number of pages requested each day of the week
  
• Number of pages requested each hour of the day
  
• Number of pages requested by each top-level domain
  
• Number of times each directory was hit
  
• Number of times each file type was hit
  
• Number of times each file was hit
  
• List of "referrers" – the URLs of pages that contain links to your pages
  
• A count of how many hits came from different Web browsers
  

You can see what Analog’s HTML output looks like (including some nice graphical bar graphs) by checking out the statistics for May through August on our Web server at the URL below. We used WebStat for the statistics for April and before, so check out those earlier months if you want to compare the output formats.

<http://www.tidbits.com/about/stats.html>

The utility of most of these reports should be evident, but I find some results especially interesting. For example, our Web site receives more hits on Tuesdays than any other day of the week. Since we publish on Monday night, that’s not surprising, but it’s good to know. Similarly, looking at the report of which hours of the day get the most hits, I can see that the low point is about 2:00 AM, so that’s when I have the server reboot itself each night. I like scanning through the list of files on the Web site along with the number of times they were hit, since it gives me an idea what people are doing when they come to the site. Since we’d been planning to rework our Web site (see "Rethinking a Web" below), seeing which pages are popular and which aren’t is educational.

August was the first month I turned on the REFERRER and AGENT options in WebSTAR’s log, so I was intrigued to see what Analog would tell me. The REFERRER option logs the URL of the site from which someone has come to your site, and the AGENT option records the specific Web browser they’re using. Unfortunately, the AGENT option isn’t particularly reliable, because a number of Web browsers (Microsoft Internet Explorer in particular) identify themselves as Netscape Navigator to ensure that they’re fed Netscape-compatible HTML from Web servers that can spit out different HTML to different browsers.

It struck me as interesting that only a few thousand of the 85,000 page requests on the TidBITS site in August came from external links. To an extent, that’s understandable, because the site takes a lot of hits from people who use the home pages from Internet Starter Kit for Macintosh, Second Edition, and Internet Starter Kit for Windows, Second Edition (those books also account for the disproportionate number of requests from people using MacWeb and NetManage Chameleon WebSurfer for Windows). Even still, I wonder what percentage of hits on other sites come from external referrers versus the number that are typed in directly.

Also interesting was the browser report, which told me that about 60 percent of the pages are requested via some version of Netscape Navigator. MacWeb came in at 24 percent, and "Netscape (compatible)," which is probably mostly Microsoft Internet Explorer, came in third at 5 percent. The vast majority of the MacWeb hits come from the home page for Internet Starter Kit for Macintosh, Second Edition, so it seems that many people who bought that book haven’t switched to new Web browsers, nor have they changed their home pages. Otherwise I wouldn’t expect nearly as many hits from the now-moribund MacWeb. Despite Netscape Navigator’s clear lead, I feel no inclination to use any Netscape extensions to HTML or other abominations like frames. It is nice to know that HTML 3.2 tags such as those for tables aren’t much of a problem, though.

When I ran Analog on my log file from August, I saw that all the references were internal to my site, so I set Analog to ignore all REFERRERs from my domain, thus restricting the list of REFERRERs to external sites. I tried, unsuccessfully, to better identify the different types of Web browsers as well, but I may have to spend some more time figuring out Analog’s configuration files.

Although Analog generally works fine with no additional configuration, you’ll probably want to tweak some parts of its report, and that’s the only place it falls down. Analog was ported to the Macintosh by Jason Linhart, and although it retains all the functionality and blazing speed of the original, it doesn’t yet have a Macintosh interface. Functionally, that’s not a problem, but it does make Analog more irritating to configure. I suspect you’ll fiddle with the two main configuration text files for a while the first time, and – once you’ve made them work – you won’t change them often. The only other problem I’ve had with Analog is that it likes a lot of memory if you feed it large log files. If it doesn’t have enough RAM, it quits with an error 25, which is an out of memory error. Each time I run into that, I give it more RAM and try again and it’s worked (the documentation notes this problem and suggests the solution).

The Macintosh version of Analog supports the MacHTTP and WebSTAR format logs, so if you use a different Web server, Analog may not work on your logs. Analog is worth a look, if only for its sheer speed in these days when so many programs trade interface for performance. If Analog doesn’t meet your needs, there are several other Macintosh utilities that analyze Web log files – check the page below for a list.

<http://arpp.carleton.ca/mac/tool/log.html>

Macintosh software is losing its identity. Many new Macintosh programs are ported from a Windows foundation to simplify the creation of a cross-platform product. In many cases, these ports have little or no support for the unique features of the Mac OS. Software reviewers tend to ignore this problem because these Apple technologies aren’t always obvious or because they aren’t technically equipped to evaluate and appreciate some of the more hard-core features. When was the last time you saw Netscape Navigator’s Apple event support mentioned in a review?

Apple has long allowed software vendors to put stickers on "approved" software packages to indicate when that program supports certain Apple technologies. Stickers for QuickTime and PowerPC-native code abound now, and consumers properly identify them with support for important platform-specific features. However, Apple implements such policies in a haphazard fashion, and even if they did have stickers for some features, it’s not hard to imagine a box cover overly festooned with brightly colored stickers proclaiming that product’s support for a large number of Apple technologies.

Happily, the Internet offers a better solution by providing a place where information can be readily shared. The Internet, and specifically, the Web, can enable informed consumer choice where stickers must perforce fail.

I have a proposal. I’d like to see a reputable member of the Macintosh community host a Web site dedicated to informing consumers about software support for important features of the Mac OS. This could be called the "MacFriendly" site (no rights reserved!).

The MacFriendly Web site could consist of a table (or more likely, a number of pages of tables), with the first column identifying the software product and the remaining columns noting the software’s support of Macintosh specific features. This table wouldn’t attempt to describe the software at all, though (for a fee) the software identifier could link to the vendor’s site.

What sorts of Macintosh specific features would belong at such a site? It’s easy to come up with a partial list:

• Apple events (standard and suite specific)
  
• Apple Guide
  
• AppleScript Recordable
  
• Balloon Help (yes, Balloon Help is good – check out Eudora.)
  
• Drag & Drop
  
• Multiple monitor support (a key Macintosh-specific feature)
  
• Open Transport
  
• OpenDoc
  
• Publish and Subscribe
  
• QuickDraw 3D
  
• QuickDraw GX
  
• QuickTime
  
• QuickTime VR
  
• Stationery files
  
• WorldScript
  

Of course, some of these features are utterly inappropriate for certain programs – a simple drag & drop utility like Chad Magendanz’s ShrinkWrap doesn’t need to support Open Transport since it’s not a networking application. A "Not Applicable" graphic or tag would solve that problem in the tables.

The MacFriendly Web site could also track other application features or problems commonly exhibited by programs ported from other platforms to give a partial measure of how "Mac-savvy" a program is. Consumers might be interested in items along these lines, including some of the following:

• Ability to run on MAE (Macintosh Application Environment) under Unix
  
• Don’t use System Folder to store files
  
• Fat binary, PowerPC, or 68K code
  
• Installation record (to aid uninstallation) or uninstallation options
  
• No "path dependencies" (use the Alias Manager)
  
• "Smart" installers that allow installation onto non-boot volumes
  
• Support for Internet Config
  

The trick would be to have software companies submit their MacFriendliness information through a secure route. Companies that fail to submit information might be listed with question marks under each heading; consumers could guess that these were not MacFriendly applications. If a software company lied about what their software supported, they’d simply be removed from the site. From a technical standpoint, setting up such a database-based Web site is easy.

The hardest part of creating a MacFriendly Web site would be working with software companies, since it can be extremely difficult to extract information from many companies. It’s unlikely that most companies would enter and maintain their own information with any sort of accuracy or regularity, if they got to it at all.

One alternative would be to turn the site into a money-making venture so it could afford to pay someone to coax the information out of software companies. A listing might be free, but having a link back to the software company’s site would cost money, and Web advertising could probably be worked in as well.

Another, more attractive alternative would be for Apple to run this site themselves. They already have a database of third party products so it would be less work to get it started than for someone else.

<http://www.devworld.apple.com/mkt/ thirdparty.html>

Either way, a MacFriendly Web site would be a great addition to the Macintosh Internet resources currently available. I reserve no rights to this idea; I only hope someone will build it. I know I’d be a regular visitor!

Voltaire said that if there were no God, man would have to invent Him. In a lesser but just as strong and pervasive sense, if there were no Apple Computer, mankind would have to invent it, for we are dreamers, and dreamers look up to the sky, always searching, thinking of what could be.

In contrast, most analysts look down into the murky swells of the business world when they analyze Apple. Sam Whitmore wrote a calm and accurate accounting of Apple’s problems in PC Week (22-Jul-96). An Apple fan couldn’t complain about his thesis, for it was even-tempered and to the (business) point. But the article, as with all the articles that suppose to articulate Apple’s demise, overlooked something very important. Sam forgot that there are those who have never been afraid to be different or be outcasts. The dreamers, the writers, the artists, the scientists – all those people who look to the future and say "why not?" – walk to the beat of a different drummer.

Now, with the further delay of Mac OS 8, one of the most challenging tasks Apple has undertaken, it will be all too tempting, even for the Macintosh supporters, to start casting the stones of fear, uncertainty, and doubt.

Do we ask more courage from Apple than we ask from ourselves?

Once upon a time, a man named Steve Jobs, filled with passion and fire, depicted PC users as zombies, walking stoically off the cliff of mediocrity. No one liked being compared to a mindless automaton, and indeed, Microsoft has made a good living by giving business people what they have dearly wanted most for the last ten years: respectability. The line that Windows 95 is "just as good as a Mac" is the anthem of those who, for years, never had the vision or courage to embrace something better. Microsoft’s strength is also its weakness.

There will always be those who are sparked by the glimmer of something just a little better, just a little cooler, just a little more inspiring. And there will always be Dilbert-esque managers who must exert their control by ignoring the advice of their technical people. Here’s an example from a Computer Weekly article from 1991, titled: "Reaction to 50 MHz 486 is lukewarm." It quotes a woman from Hughes Aircraft as saying, "many of our users have more power than they need right now [with 80386-based PCs]" A manager at Chevron concurs, noting, "Right now we could justify the price only as a server." To be fair, these people were using DOS, not a graphically-based system that demanded considerable horsepower. (And the Macintosh IIfx delivered just that at that time.) So where were these people looking? They were staring hard at their budgets.

Where are Macintosh users looking? Men like Douglas Adams and Arthur C. Clarke look to the stars. The spirit of Apple Computer is that of excellence and adventure. It embraces the future and everything positive that the minds of men can conceive of. We’ve often paid a little more, but we paid the money out of our own pockets. Some of us make a living by day with Windows so we can spend our own money on something that captures our imagination in the evening.

Apple lost its way in recent years. Apple forgot about inspiration and wonder. It got caught in price wars, desperately seeking acceptance at any price. Now, Apple’s destiny is to be the best. Truly, there may only be ten percent of the population that cares about the best. But if Apple gives up that ten percent, there are other dreamers and entrepreneurs standing quietly in the wings waiting to take up the cause. We cannot predict what they will do, but the spirit of the dreamers who want something more will always be with us. More than anything, we want Apple to know that.

I just put our new Web site online this Sunday, and since it was the product of quite a lot of thought and a few hours of HTML coding, I thought I’d pass on some of the things we considered and learned in the process.

<http://www.tidbits.com/>

Our previous Web site evolved, as many early sites did, organically. We had launched MacHTTP and needed a default page, so we put one together on the spot. As time went by, we thought of additional pages we needed, so we created them and linked them in, often right from the home page. All of this was well before HTML 3.0, much less the current HTML 3.2, so there wasn’t much we could to jazz it up visually while retaining the structured nature of good HTML (and avoiding Shockwave, JavaScript, loopy animated GIFs, background music, and 3-D Surround Smell). In addition, design that seemed reasonable two years ago now seems as stale as a month-old bagel and not much more edible.

So, this summer when we were driving to Ithaca, New York for our friend Oliver’s wedding after Macworld Boston, Tonya and I went over the site in our minds, jotting down notes about what pages we had versus those we wanted, what we wanted our site to do versus what it did then, and so on.

That sort of a brainstorming session is a necessity in any good Web site redesign. Think carefully about what message you’re trying to convey, and what visitors to your site both expect and will want to do. In the case of TidBITS, it seems quite clear that we publish a weekly electronic newsletter, so if someone visits our Web site, they’re probably interested in finding out what’s in latest issue. In the past, that required at least several navigational clicks, so we placed a copy of the issue blurb and table of contents right smack on the home page. Along with those two items, we created a simple Web form to make it easier for people to subscribe to the TidBITS mailing list and a line of links to provide quick access to the translations of TidBITS into a variety of languages. Again, those two items seemed to answer the question of "What would I want to see when I visit the TidBITS Web site?"

Those then are the primary elements of our home page, along with a TidBITS graphic and a plug for my book. However, since visitors’ questions don’t stop at "What’s in this week’s issue of TidBITS?" and "How do I subscribe?", we try to address other common questions as a textual navigation bar at the top of the home page. The navigation bar, which is repeated on all other pages, contains two lines. The first provides a direct link to the home page and a link to a page of links about TidBITS; the second line contains links to past issues, to a search engine for searching back issues, and to the page listing our many translations.

In the past, we had links to many of the less-important pages right on the home page, which provided too many choices to visitors and was a rather haphazard organization. The About TidBITS page one level down from the home page now takes over those duties, offering a centralized collection of information about TidBITS. If you’re wondering about who works on TidBITS, how it earns money, where it’s posted, or how to contact us, the answer should be an obvious link from the About TidBITS page.

On a number of pages, including About TidBITS, the page listing our translations, and the page listing the places you can find TidBITS, I adopted a "text block button" design that I feel works quite well. The goal was to avoid the confusion of graphical buttons, which are easily misinterpreted, especially by people from other cultures, and the overhead of creating and transferring additional graphics. Where possible, we stick with text (being writers, not graphic designers), so the combination of an unordered list inside a two-column table gives the visual impression of a button object with the clarity of a brief textual description (which carefully avoids saying "Click here…"). And, of course, the text block button design repeats where appropriate, unifying the list pages on the site.

Another unifying element I worked on for quite a while is the textual navigation bar. On the home page (and on the page that will provide access to TidBITS issues in the near future – it has to be merged with Geoff’s distribution automation), the navigation bar is on the top of the page because we felt that placing it on the bottom tended to hide it and make it more difficult to get into the site. It’s entirely likely that someone will want to find out where to get TidBITS on America Online, for instance, but will only know the URL to our home page. Placing the About TidBITS link at the top of the home page makes navigation easier. For all the rest of the pages, we felt that the user would have to read the entire page to know what was there anyway, so placing the navigation bar on the bottom of the page was more appropriate (and better graphically).

Many Web sites suffer from a lack of repeat visitors, and although I haven’t tried to analyze our Web logs to that extent, I suspect that our previous site had that problem. An excellent method of ensuring that people return is to have content that changes at regular intervals. Since we have a new issue of TidBITS each week, placing the blurb and table of contents on the home page not only provides what many visitors undoubtedly want, but also gives us the opportunity to change the home page on a weekly basis, thus encouraging people to visit regularly.

I’m sure that with all that Tonya has written about HTML authoring tools, WYSIWYG and not, that at least some of you are curious about what we used. The fact is that Tonya’s been extremely busy writing a magazine article about that very topic, so I went ahead and did all the work myself. I’m comfortable with HTML, but I haven’t done all that many pages in the past. Even still, since I had a good idea of what I wanted our pages to look like (white background, banner graphic, text block buttons, textual navigation bar), I decided that it would be easiest for me to work in a familiar environment, which for me means Nisus Writer with its HTML macros. It might not be the latest and greatest, but it does the job and I was able to use the Find/Replace across all open files whenever I discovered that I’d screwed up the relative URL to some page in the ubiquitous navigation bar. I would have appreciated an internal link checker, since I moved a lot of the pages from the root level into a sub-folder during the redesign, and that screwed up a lot of links. Still, I never quite found time to install Adobe SiteMill, and if I’ve made a mistake or two, I’m sure we’ll hear about them and fix them soon enough.

So take a look and see what you think. Let me know if you have some expectation of the information contained on the site that’s not met, if it fails to answer a question you may have. The answer may simply be the kind of thing we don’t publicize, or it may have slipped our minds when redesigning the site, at which point I’ll try to add it in. We do have additional work left to do, including the constantly updated page listing all the TidBITS issues and perhaps some new graphics, but the bulk of the changes are here until they too start to harden like an aging bagel.