Articles In Category
Apple's HomePod has been the underdog in the "smart speakers" category since its introduction last year. It's more expensive than the offerings from Google and Amazon, and Siri doesn't seem to be as powerful. I haven't used Alexa or the Google AI assistant, so I can't say what the difference may be. But let me just say that HomePod is a revelation in audio quality, and its "smart" features are more than adequate for my needs. The most surprising aspect of HomePod is that it has finally let me put together an audiophile listening room without taking out a second mortgage!
One of the main reasons to upgrade is to take advantage of iCloud, which has become a more serious need now that Apple took MobileMe away from us. I can no longer sync my Safari bookmarks automagically, for example. However, I'm still pissed that Apple hasn't made a version of iCloud available for the many folks still on Snow Leopard.
Speaking of which, what exactly is the breakdown of Mac users in August 2012? It's only been a month since Mountain Lion was released, but clearly upgrading is happening pretty quickly. According to the stats from NetApplications.com, Lion users account for about 35% of the market, Snow Leopard users about 34%, and Mountain Lion users about 20%. There are still about 10% of users hanging on to Leopard. That Snow Leopard figure is pretty damn high considering how long Lion has been out, and is one that Apple should be paying more attention to.
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.
In the past few years, Adobe Flash has become more than an annoyance that some of us have kept in check by using "block Flash" plugins for our web browsers. More and more, entire web sites are being built with Flash, and they have no HTML alternative at all! This goes way beyond annoying, into the realm of crippling.
I had noticed the trend building for quite awhile, but it only really hit home when I realized that Google, of all companies, had redesigned its formerly accessible Analytics site to rely heavily on Flash for displaying content. This wouldn't be absolutely horrible except for the fact that Google provides no HTML alternative. I tried to needle the company through its Analytics forums, but only received assurance that yes, indeed, one must have the Flash plugin running to view the site.
Keep in mind that content like that on Google Analytics is not mere marketing information, like the sales pitch on the Analytics home page.
Those of us who are disturbed by the trend need to be a bit more vocal about our opinion. Hence, I'm starting a "Just Say No To Flash!" campaign, with its own web page, graphics for a banner, and the CSS and HTML code to deploy it on your own web pages.
I've mentioned this to some of my family and friends, and they often come back with: "So, Why should I say no to Flash?" I admit that as a power browser and a programmer geek type who, shall we say, makes more efficient use of the web, I'm more keenly aware of the ways that Flash is chipping away at the foundation of web content.
In the beginning, it seemed harmless: Flash was an alternative to animated GIFs, and an easy way to embed movies on web pages. But then advertisers wrapped their meaty mitts around it, and that's when Flash started to be annoying. However, one could block Flash in the browser, as part of a strategy of shutting out obnoxious advertising.
But publishing content via Flash is just wrong, for a number of reasons.
Dark interface themes are extremely popular with a small, but very passionate, group of Mac users. Sadly, since Apple introduced Leopard (Mac OS X 10.5), the old, relatively simple method of creating such themes on the Mac can't be used, and it took the theming community a good year and a half to figure out the current, relatively hobbled tools to theme the few bits of the interface that can be themed.
Given the weakened state of theming on the Mac, it's not surprising that the number of themes available has dwindled to a mere handful. And even those only go part of the way compared with what we used to be able to achieve with ShapeShifter. Still, the yearning for Mac themes remains strong among this community, and black themes are virtually nonexistent now.
Black themes have always been a challenge, because the frameworks used to build applications were designed to assume that text would always be black and the color of windows and buttons always light. Apple introduced a dark-theme paradigm a few years ago with its Heads-Up Display window style, which, with its translucent black background actually assumes that text will be white.
So, why would anyone undertake an effort to introduce a fully black theme for Snow Leopard?
I suppose it's because we Martians just can't step back from a challenge. Not to mention the fact that we, too, are afflicted with the passion for dark themes that many Earthlings suffer from. I also have a good starting point, having developed some useful techniques for the challenge through building CrystalClear Interface.
To acknowledge the theme's heritage, I've dubbed the theme Crystal Black.
In other words, the Web Inspector tool is nothing but an intricate, sophisticated, and extremely well designed web page!
Having built a Crystal Black CSS file for web pages in general, and with my past expertise in CSS, I attacked this challenge with relish! It reminded me of the time I realized that Dashboard widgets are, at their core, nothing but little web pages (as are simply apps for the iPhone). In tackling this one, the main question was, How should the various elements look? And the hardest part was inspecting the various parts in of the Inspector in great detail to determine which CSS rules governed their default appearance and behavior.
As I discovered, the WebKit has a a sub-framework called "WebCore," which in turn has a folder of resources specifically for the Web Inspector. In the Inspector folder, among other things, is a suite of CSS files that handle different aspects of the Inspector's design and behavior. Of these, the primary one I needed to tweak was called simply "inspector.css."
I've observed that one of the most intractable problems bedeviling computer users, which makers of operating system software never seem to solve, is that of "Window Clutter." The inability to …
- 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.
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:
- Handle a wide variety of common file formats found in the workplace, rather than just text and proprietary eBook formats,
- Don't include controls for customizing fonts,
- Don't let users do full-text search on documents,
- Have good embedded browsers and follow web links,
- More easily let users move files to and from their iPhones, and
- 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:
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.
I recently decided it was time to look again at the state-of-the-art in eBook reader hardware. It seems like I've waited forever for a company to design one I could really use in place of the traditional paper-filled parallelepiped. I first got excited by the possibility while implementing the PDF format for a magazine on CD-ROM back in 1995. "Wow!," I thought, "Whoever wrestles PDF onto a small electronic device is going to make a mint!"
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.