Some variation of these text tools have been included in CrystalClear Interface, as well as Crystal Black, since those applications were first released. However, the tools have nothing to do with the theming of buttons and windows, or with the general appearance of Mac OS X. I added them because they address a real need of mine, which no other software could do.

As a writer, I need ready access to a range of text functions, and I need them in whatever application in which I happen to be writing. In most of the rich text editors I use, those functions are available somewhere in the app’s menus, but typically they're in different places within each app. Some apps don’t include one or two key functions at all.

Mac OS X has a rich text framework that provides just the set of editing tools I require, and it would be extremely handy to be able to access those tools consistently across apps. This is precisely what the MarsThemes Text Tools do: Grant easy access to the key Cocoa text tools that writers and editors need but can’t find.

I recently released a major new version of CrystalClear Interface (CCI). Among the most significant enhancements in version 2.5 are its full compatibility with Mac OS X 10.6 ("Snow Leopard") and its ability to finally theme the Finder. Because of new limitations to system add-ons imposed by Apple, taming Snow Leopard has been a daunting challenge, but the final outcome is a version of CCI that's the most stable, robust, and compatible yet. The extended struggle with Snow Leopard over the winter is one of the primary reasons I've decided to require a license fee for CCI 2.5 ($12.00).

• Stay focused on the window you're working in, while
• Keep auxiliary windows handy and visible when needed,
• Avoid confusing any of these windows with those of other running applications, and
• Maintain some reasonable level of aesthetic quality to your computer desktop.

… is a nettle that keeps on pricking. At least, judging from continued user grumbling about it and the continued, less-than-satisfactory, though often valiant, solutions that user-interface experts keep offering users as the final salvation from this longstanding hindrance to productivity, I conclude that the nettle is alive and well.

That Window Clutter should still be a topic of conversation among engineers at Apple (I don't think Microsoft has any high-level staff who really care about or understand the issues surrounding interface usability, and Linux developers don't have the time to do so) is testament to their failure to stamp out a problem that appears from Mars to have a fairly simple solution, namely:

• Make it so that only one application's windows are visible at any one time.

Affectionately referred to as Single Application Mode, or SAM, this is the default desktop environment on Mars. It's also widespread on Earth, though its human adherents often practice SAM quietly or even in secret because it's not an official, supported Mac OS X desktop environment.

Still, we find SAM the best way of dealing with today's large monitors, huge RAM capacity, and equally huge software options—all of which spell Window Clutter at a scale never before experienced.

It's still somewhat difficult to get a handle on exactly what is meant by the "Semantic Web," and whether today's technologies are truly able to realize the vision of Tim Berners-Lee, who first articulated it back in 1999. From what I've read, I think there's general agreement that we aren't even close to being "there" yet, but that many of the ongoing Semantic Web activities, technologies, development platforms, and new applications are a big leap beyond the unstructured web that still dominates today.

There is a huge, seemingly endless amount of work being done by thousands of groups all trying to contribute to making the Semantic Web a reality. In my few weeks of research, I still feel as though I've just stepped my toe into that vast lake of semantic experimentation. Partly as a result of the many disparate projects, however, it does become rather difficult to see the entire forest for all the tiny trees. That said, these thousands of groups do appear to be working more or less together on the basis of consensus-based open standards, and they have set up mechanisms to keep everyone abreast of new ideas, solutions, and projects, under the general leadership of the World Wide Web Consortium (W3C)'s Semantic Web Activity.

As a starting point for exploration into this topic, the Wikipedia article that describes the Semantic Web Stack is quite good. Among its good overview and many useful links, the article includes the original conception of the Stack as designed by Berners-Lee.

Besides cataloguing the sheer number of different projects all tackling different aspects of building a Semantic Web, it's important to distinguish ongoing projects from those that expired years ago—a distinction that's not always readily apparent to those peering in from the outside. Even excluding these, there are far too many projects to read up on in a few weeks, so this snapshot is necessarily incomplete. But after having the content reviewed by some Semantic Web experts, I'm confident it includes all the most significant threads of this new web, which, as Berners-Lee envisioned it:

I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize.

In my tour of the Semantic Web as it exists today, it's interesting to note that most of the projects are geared not toward machine-to-machine interaction, but rather to the traditional human-to-machine. Humans being by nature anthropocentric, the first steps being taken toward Berners-Lee's vision are to build systems that are semantically neutral with respect to human-to-human communication. Once we can reliably discuss topics without drifting off into semantic misunderstandings, then perhaps we can start teaching machines "what we mean by" ...

This paper is an attempt to assess the current state of today's steps, while compiling a list of resources that would prove useful to someone thinking about building a Semantic Web application in 2009.

Recently, that seems to be the standard for virtually any online article that has something nice to say about Apple. Rather than commenting on the substance of the article, some anti-Apple type will immediately start dissing the company in a totally ignorant and offensive manner. Sometimes, such drivel will be met with commenters defending Apple, but quite often it merely attracts other Apple hecklers.

The Computerworld article cited above was no different, but there was one comment from a guy who, though claiming to have some positive feelings about Apple, levels a charge that comes straight from the Microsoft propaganda machine. This propaganda only started a few years ago, when Apple began to have success with non-computer products like iTunes, the iPod, and now the iPhone. Microsoft loved to spread the word that Apple's products were all "closed," while Microsoft's were "open," and many listeners, without actually thinking about this illogical line of thinking, bought the propaganda and are now spreading it themselves.

I just couldn't let this challenge go unanswered, so I didn't. The following is what I published in response on Computerworld. In a nutshell, it explains why this guy's line of reasoning is bunk, and why, no matter how much Microsoft would like folks to think so, Apple is absolutely not a monopolist in any sense of the term.

CrystalClear Interface 2.0 will soon enter a public beta release. This is a major step from the previous version, released in March 2008 and described in the Mars article:

CrystalClear Interface 1.9:
Going Where No Theme Has Gone Before

Those of you who found CCI 1.9 outlandish no doubt find that version 2.0 sets a new standard for outlandishness. :-)

This second part of my report on the iPhone application marketplace covers the class of software that, while still falling squarely in the overall eReader category, is designed primarily for storing and managing documents. The primary distinctions between this class and the one covered in Part 1 are that the eReader apps discussed here:

1. Handle a wide variety of common file formats found in the workplace, rather than just text and proprietary eBook formats,
2. Don't include controls for customizing fonts,
3. Don't let users do full-text search on documents,
4. Have good embedded browsers and follow web links,
5. More easily let users move files to and from their iPhones, and
6. Typically let users organize and rename files and folders within their interface.

It still surprises me how rapidly this market is evolving, and that evolution makes keeping tabs on the capabilities of each application--and even on the entire set of applications--quite challenging. As I was finalizing this report, a new application in this class came to market that, it turns out, I've found to have among the very best features of any that came before. I have no doubt that many of the applications reviewed here will continue to be refined, rendering this snapshot fairly obsolete fairly quickly. But the observations here accurately reflect the current state of iPhone eReaders.

The iPhone application marketplace now offers a tantalizing variety of tools that can be used as eBook readers and file managers. As I concluded in the September 2008 report, "Without Even Trying, Apple's iPhone Takes the eBook Reader Sweepstakes," the iPhone and iPod Touch hardware finally enables truly practical eBooks, and the software now available for the iPhone platform just clinches the deal.

Having worked with the growing number of these applications since the first started appearing in June, I've concluded that the market is clearly divided into two major objectives:

• Applications designed primarily for reading text (books), and
• Applications designed primarily for storing and managing documents.

As I compiled notes and usability data on this group of applications, it became clear that trying to cover all 19 different applications for the iPhone that can server as e-document readers in one article (a 20th was released just as I was finalizing this report) would be a bit much--for me as well as for readers. As a result, this will be the first of two installments of the overall report. (Note: All of these applications, with one exception, work equally well on both the iPhone and iPod Touch. For simplicity and brevity, I'll use "iPhone" to refer to both devices going forward.)

This first part covers the following iPhone applications, which are primarily aimed at reading text and HTML documents:

1. Bookshelf
2. Bookz
3. Reader
4. Evernote
5. Instapaper
6. iSilo
7. ReaddleDocs
8. Stanza

The second installment will cover applications that specialize in enabling document repositories on the iPhone: Air Sharing, Annotater, Caravan, DataCase, File Magnet, Files, Folders, iStorage, Mobile Finder, TextGuru, and TouchFS.

Of course, PDF turned out to be not particularly well suited to small viewing screens, since publishers would have to make a special layout for the PDF version. And so, years went by, with talk of E-Ink, electrowetting, electronic paper, and other exotic technologies appearing to be on the verge of practicality.

What most of the would-be designers of eBook readers have seemingly failed to grasp, however, is that to replace paper books, eBooks must be nearly as light and portable as a paperback. They must work without cords, and be compatible companions to one's daily trip to the little boy's room. (I've honestly never met a woman who reads in the john, but it seems nearly all men do.) They must be able to accompany you to the beach, the pool, or the mountains. I'd really like something I could read while holding it in one hand, like I do a paperback. I don't want a reader that will break the bank, either. And most of all, an eBook reader needs to be comfortable to use in bed or in your favorite armchair.

Even today, with devices shrinking towards the ideal size and weight, nearly all fail to meet my needs for one reason or another. Quite surprisingly, one device has in fact replaced books for me, and it's not one I ever thought would or could. Because I had bought the device for another purpose entirely, this eBook reader has actually cost me nothing whatsoever.

This article covers five eBook reader devices, including two that are full-fledged personal computers serving as an eBook reader by way of third-party software, and another that is a multifunction "smart phone" with eBook reader capabilities. All five devices have strongly positive characteristics, and two of of them possess the full range that would allow them to serve as portable eBook readers for organizations that need access to technical and policy documentation. Even though I personally need a reader that's useful for novels and such, I'm evaluating these based on their utility as devices for storing and reading technical and other documentation rather than literature, each of which have quite different requirements for eBook reading.

That this overwhelming trend toward advanced, desktop-like applications has happened at all is the result of the efforts of determined developers from the Mozilla project, which rose from the ashes of Netscape's demise to create the small, light, powerful and popular Firefox browser. The activity of the Mozilla group spurred innovation from other browser makers and eventually forced a trend towards open standards that made the emergence of Ajax possible.

This article starts with a brief history of web browsers and then jumps into a look at the feature set of the four primary "modern" web browsers in 2008. The comparison of browser features begins by listing the core features that all these browsers have in common. The bulk of the article lists in detail "special features" of each browser and each browser's good and bad points, as they relate to the core browser characteristics. Following that, I present some recent data on the comparative performance of these browsers. The article concludes with recommendations I would make to organizations interested in making the switch from IE6 in 2008.

However, the WebKit team continues to lead the pack, as they have since I first contemplated this article over a year ago. In the last 6 months, that team has not only adopted more of the CSS 3.0 specs ahead of the others, but they have proposed several exciting new specs of their own, which the W3C is taking up as draft recommendations.

In addition to updating the state of CSS 3.0 in WebKit/Safari, I've also added some new demos for the Backgrounds section.

Here are the CSS 3.0 features I wrote about in July 2007:

1. Box-shadow: Yes! Add drop shadows through CSS!
2. Multi-column layout: Can we really do this now? With HTML?
3. Resize: Give JavaScript hacks a rest and let users relax when typing input on web pages.
4. Rounded corners: Any
   can be made round.
5. Colors with transparency: There goes another ugly hack from way back!
6. Background image controls: Remember how great it was when you could add images as well as colors to an element's background CSS style? Well, it's about to get a whole lot better!

And since then, WebKit and Safari 3.1 have adopted the following new ones:

1. Adopted last October, WebKit introduced its first take at CSS Transforms, which it has submitted to the W3C for consideration. With CSS Transforms, <DIV>s can be scaled, rotated, skewed and translated... all without using JavaScript!
2. Announced at the same time is the equally exciting implementation of CSS Animations. At the moment, the only type of animation that's documented and demonstrated on the WebKit blog is based on CSS Transitions, which let you define how an object or attribute changes over time from one state to another.
3. Also in October, WebKit added the CSS Web Fonts feature, which lets designers beam fonts to users through CSS and HTML, approximating the capabilities of PDF in a much lighter-weight form.
4. Then, after a lull, things started to heat up again last month, when Apple released Safari 3.1. Safari 3.1 incorporated all of the CSS 3.0 features WebKit had pioneered earlier, plus it added a bunch of things the WebKit team hadn't blogged about. Chief among these was support for CSS Attribute Selectors. This is something of a holy grail to advanced web developers, since it opens up a whole world of possibilities for using the Document Object Model (DOM) to build better web interfaces. When released, WebKit was the first and only browser to support this geeky, but highly practical feature.
5. And then, just today, WebKit added support for CSS Gradients to its portfolio. Gradients are not yet a CSS 3.0 specification, but they are part of the HTML 5.0 spec. No doubt Apple's implementation will be referred to the W3C for consideration.