« February 2004 | Main | April 2004 »

March 26, 2004

Okay, this is a very odd title for an article, but before you get the flamethrowers fired up, hear me out.

Let's get one thing straight: I've never liked OmniWeb. I downloaded the latest beta for OmniWeb 5, and I still hate it. I may always hate it. But that's a good thing. Because I don't want all applications to solve a problem exactly the same way. It's bad for the applications I do like and use, and it's bad for the platform.

Because, even if I don't like some of the results, diversity is good.

First, I have tried to like OmniWeb. Really. I wanted to like it.

It's very pretty. There's no denying the inherent...well...prettieness of the application. There's a lot of UI love in OmniWeb.

But to me it's like being nibbled to death by baby ducks. The wrapping of the favorites links in the window. I hate that. If I make my window smaller horizontally, I shouldn't lose vertical space. But I do.

The preferences are tedious beyond words....click a pref, change a setting, click show all to get to the next pref. Or you can just click the arrows that rotate you through prefs. How nice.

I hate the way it uses drawers for everything, I despise its bookmarks implementation, and I really hate the new tabs. I don't want space that I can use for what I really want to look at lost to a bunch of over-Quartzed web page thumbnails. The whole "save workspace" thing is lost on me because I haven't changed my browser "workspace" in years, nor do I plan on it. I never know what the heck I'm going to do with the browser until I need to use it.

And so on.

But I'm not going to tell you, or Omni what I want changed. Because I don't want OmniWeb to become Safari or Mozilla or Firefox, (or whatever the hell it's called today). We already have those applications, we don't need clones of them. I want it to continue to apply it's own unique take on the browser problem. I may never use or even like Omni's take on tabbed browsers, but maybe someone will look at that and say "Hey, I hate that implementation, but what if I did something else with it?"

I mean, opinion aside, it's a pretty neat take on tabs, and for a lot of folks, Omni's version of tabs is going to make their lives a lot easier, where some other implementation wouldn't. I may hate it, but I have to respect the innovation there.

That's what diversity is all about: skinning the cat in a new way, which leads to other new ways. It's a real benefit to any platform. And not just with web browsers. I like Microsoft Word, but I'm glad that AbiWord finally got a proper Aqua interface. Because it may help out a lot of people that were just never going to use Word. They may be able to do something really cool because they finally got a tool they can use. A too they wouldn't get without a willingness to be different.

So yes, I hate OmniWeb, and I hope I hate it for the next ten years, and I hope I hate it in large quantities, and I hope it never changes so much that I would like it. I hate OmniWeb because it's different, but I love OmniWeb's difference. Because without it, I might not see a change to something I do like that would be very cool for me.

I love the diversity that OmniWeb brings to the browser table, because without diversity, the platform stagnates, and eventually dies of terminal boredom.

And I'd hate that a lot more than I hate OmniWeb.

| Comments ()

March 21, 2004

Recently, I was at the Apple Store online, and I had a rather depressing realization:

Almost none of the software that Apple sells is AppleScriptable.

Now, first, we should define some things:

1. AppleScriptable: Possessing an AppleScript dictionary. If the only way to AppleScript an application is via UI Scripting, or "do shell script", the it's not AppleScriptable.


2. Software that Apple Sells: Software products that you can buy from the Apple Store's "Apple Software" section. Things that ship with the OS only count separately if you can buy them separately. So for instance, iChat would count, Mail would not. (I know this is an arbitrary designation, but it makes sense. I can't buy Mail outside of Mac OS X, but I can buy iChat outside of Mac OS X.)

So now, onto the rather depressing bits...

Now, some will say "It's unfair to exclude the OS". This has some merit. The OS is scriptable, has many dictionaries, and you can do a lot with it just using AppleScript, and you can buy it as a separate product. Okay, done. We'll count Mac OS X. We will even include Mac OS X Server, because root code aside, it's a separate product, and includes features not in Mac OS X. We'll also include FileMaker Pro, but just once.

So, on the Apple Software section of the Apple Online Store, there are 15 products that we will look at for this article. There are more entries, but I'm excluding differently licensed versions of a single product, (Family packs, 10 - user vs Unlimited), different versions of the same package based on owning earlier products, (upgrades vs full installs), items that don't run on the Mac OS, (QuickTime Player Pro for Windows) add-on components for for other products, (QuickTime MPEG 2 Playback, Garage Band Jam Pack), and things that aren't really software packages at all, (.Mac).

Now of those 14 products, there are seven scriptable products, 9 unscriptable products, and one that I'm not sure of. (iLife '04 is both scriptable, for iTunes/iDVD/iPhoto, and unscriptable, for iMovie and Garage Band). I don't know if Quicktime VR Authoring Suite is scriptable or not. So not even half of Apple's commercial software products are definitely scriptable. If you want to break it down more, none of the Pro applications are scriptable.

That's right. None of Apple's crown jewels support AppleScript. (An argument can be made for Filemaker, but that is lumped in with AppleWorks, Final Cut Express, Keynote and Logic Express. So since Apple doesn't consider it a Pro application, why should anyone else?) In fact, If you look at Apple's Software page, and go by groupings, the only categories that are mostly scriptable are Mac OS X and iLife.

Keynote? Not scriptable.
Final Cut Express? Nope.
Logic Express? Nope.

I'll go even further here. Can you remember the last time Apple shipped a brand new product that was scriptable from v1.0? I could be wrong, but I'll say iTunes. I don't believe iDVD 1 was scriptable. Let's look at the impact of that statement.

Apple has not made AppleScript a part of a new product since iTunes, which is one of the oldest applications Apple ships!

This is beyond appalling. It's...well, the only word that makes sense here is "asinine", which if we look at the Webster's Revised Unabridged Dictionary definition:

\As"i*nine\, a. [L. asininus, fr. asinus ass. See Ass.] Of or belonging to, or having the qualities of, the ass, as stupidity and obstinacy. ``Asinine nature.'' --B. Jonson. ``Asinine feast.'' --Milton.

Seems to fit the attitude responsible for this.

It can't be that AppleScript has no inherent value for customers. AppleScript is an integral part of customer use of the Mac from small, single person scripters, such as yours truly, all the way to major companies that depend on AppleScript for theil livelyhood, such as The Boston Globe. There have been so many studies that show the advantages of system scripting languages, and of AppleScript in particular that the need for an easy to use, comprehensive system scripting language is a fact. No OS can be called "modern" without one.

It can't be that automation has no place in creative applications. Adobe, Quark, Stone Design, and Media 100 have proven this wrong. While you cannot automate creation, in any creative agency, regardless of final output media, there is an incredible amount of repetitive monkeywork that begs to be handed off to a script so that the humans can do the stuff that only humans can do. There's absolutely no sense in paying someone top dollar to resize every video by a factor of two.

It can't be that Apple sees no value in AppleScript. Considering the improvements in AppleScript in every OS release, and the amount of work this takes, if Apple didn't see a point in AppleScript, why bother?

I really can't tell you why. I can't even tell you for sure who's responsible. I can tell you who is not at fault: The Core AppleScript team. I'm pretty sure if they had the people, they'd just add the scripting implementations themselves. But honestly, i think the team that designs the UI for Final Cut Pro has more people than the entire AppleScript team. (I can't tell you for sure, but I'll bet a beer I'm right.) Sal and the team do the best they can to get the word out, but they can't force anyone to change their attitudes. And if I had to put a finger on the reason why Apple does the worst job of almost any mainline Mac software vendor in supporting AppleScript, I'd say it's an attitude issue.

(No really, once you get out of the OS, Apple does a simply crappy job of supporting AppleScript. Adobe, Microsoft, Quark, all do a FAR better job. It's really, really REALLY sad when MICROSOFT not only has better AppleScript support across its Mac product line than Apple, but in some cases, does a better job of it too.)

For some reason, there's a lot of people at Apple who don't see AppleScript as necessary. I won't say they all uniformly hate it, (although some encounters with the Pro application people make me think that in the gilded halls of Final Cut Pro, AppleScript is about as welcome as Charlton Heston at a PETA rally), but for whatever reason, they don't see the need for it. Maybe they don't WANT their users and customers doing things with their work that they didn't include. Okay, I can see that. Programmers can be just as egotistical as anyone else. But I cannot see a valid reason for not doing this. In fact, I'll state that it may be costing them hardware sales.

Here's an example:

I call it a Conversion Service. It's for people with masses of old home movies that want to convert them to DVD. This can be done manually, but it's a pain in the ass. Here's how it works.

1. Bring a box of tapes to the CS Store.


2. Pick out the templates you want to use for your tapes. You could use one template for all the disks, or a different one for each.


3. Decide on your output format. You can get more onto multilayer, but that will cost you more, and take longer, since making those is more complex, but hey, you want it, no problem.


4. Retail person takes the tapes and gives you a date to return. You return, and you have a nice set of DVDs of your old movies.

Of course, for you Far Side fans, you realize that step four is where a miracle happens. Only it's not a miracle, it's just automation.

The person takes the tapes into the production room. This has n A/D converters for various tape formats, x racks of Xserves, connected to the A/D converters, y DVD burners, and z DLT drives, (for the folks who just must have multilayer discs to be in with the kool kids. Hey, got money? Kinda stupid? I'm your best friend!).

Now, pay attention, because this gets cool, and fast. Put the tapes in as many drives as you can. Go to the master console, and click some boxes, fill in some data for customer type, template, output type, menu music, etc. Then hit go (if the output types are not loaded with blank media, worker gets fussed at about it.) Human intervention is now done for a while. The Xserves go to town, rewinding tapes, (that's right kids, you don't even have to do that.), and converting them to digital video. The video is then analyzed for file size. If it's too big for a single disk, it's broken into properly - sized chunks. Each bit of video is then inserted into the template. The other parts of the template are filled in with pertinent customer data. The projects are then rendered, and output to disk. If one project has an error, the worker is notified as to which machine, and what kind of error it is. (Since any possible automated response is taken care of, this is only for stuff that needs a human!). Now, we get burned to disk, and we're done, right? Heck no sparky, We got liners to print. That's right, once we're done, that color laser sets to printing up the nice inserts for the DVD cases. Hey, what good is a bunch of unidentifiable blank cases? Okay, now we're done, let's go ahead and get the human. What does the human do? Puts inserts in cases, puts disks in cases, puts disks and tapes in a nice box and sets them on a shelf.

That's it. If you can automate this, then you can have one person running racks of Xserves all busily chugging away and working. Unfortunately, you can't do any of this with Apple's software.

That's right.

Why?

Well, for one, Apple doesn't make any software that is scriptable and could run the A/D converters and dump this tape data to digital form. Now you can buy scriptable software that does this. My favorite is BTV Pro, from Ben Software. You want to know what this product costs? Well, an unlimited site license is $700, and a single copy is $40. That's right folks. A product that just destroys Final Cut Pro as a production tool is only $40 per copy, and for less than the cost of a single copy of Final Cut Pro, you can give it to your employees like prizes in Crackerjacks.

That, boys and girls, is sick.

Now, you can almost use iDVD for some of the last part, that is building the projects from a template, getting ready to burn. But iDVD, even in version 4, still lacks a "burn" command, (although I imagine you can work around that with some other tools.). However, if you want it output to DLT for multilayer DVDs, then you have to use DVD Studio Pro, and of course, that's not scriptable. Once again, we see how a supposedly "Pro" product gets its head handed to it in a production environment by a product that costs a tenth of what the pro product costs.

This is just silly. No, it's more than silly. It's asinine. It's costing Apple sales on products that will never exist because Apple is too shortsighted to enable their creation. It's costing Apple hardware sales to run these products that will never exist because of the unjustifiable resistance to automation in Apple software products.

It also makes Apple, and esp. Steve Jobs look stupid.

Steve can stand up there and talk about AppleScript, use AppleScript, have his minions push AppleScript all he wants. He can talk about "eating our own dogfood" until he's blue in the face. When it comes to AppleScript, all you have to do is look at the products that Apple really cares about to see what a flow of bovine excrement it all is. Impressions count, and the impression that people get from Apple on AppleScript is not good. It's not consistent. It's not "This is a critical technology that Apple supports 100%". Not even close. Instead it's, "Well, it's okay for other ISVs and some OS tricks, but if you think we're going to sully our crown jewels with it, you're nuts."

That is what is known in the industry as "bad".

It makes it very hard to get AppleScript into products, or to improve AppleScript support. "Why should we care, when Apple doesn't?" That's a perfectly legitimate stance. You don't lead by being behind, or by half-heartedly supporting something. There is only one way to lead. To be in front, and be fully committed. Until every single piece of software Apple sells is as scriptable as possible, then Apple is not doing anything close to eating its own dogfood.

Apple has been halfway supporting AppleScript for far too long now, and it's hurting not only the platform, but the people who pay for that platform, and they need to stop. This asinine attitude towards AppleScript is illogical, indefensible, and borders on dumb.

I've had a lot of adjectives for Apple, but "dumb" is not one I use often. I'd hate to have to change that.

| Comments ()

March 8, 2004

For many years now, HTML email has been the domain of cl00l3ss n00bi3z, AOL'ers, Spammers, etc. No one who really knows anything about email would use it. “It's useless”, “It's bloated”, “It's a sign that Microsloth is winning”...yadda...yaddaa...yadda. But of late, I've discovered something else about it.

When properly used, HTML email is a damned handy tool.

Face it, email has changed. Ten years ago, it was a way to convey simple messages. Most access was still dialup, and size counted. Email was used for what Instant Messaging is used for today. Short notifications, setting up real meetings, sending small, (or not so small) files, and the rest.

The only way to create HTML email was to use some tool like Netscape. (Eudora and MS Mail actually use Rich Text, which is a different way to get the same effect.) It was hated, and with good reason. Most of the people making HTML email were doing it for the email version of the early “Should Steve Shave” web sites. It was useless, poorly done, rife with sounds, ugly background colors and the rest. I hated it too.

But in the last few years, a funny thing has happened. Email has gone from a secondary to a primary business communications tool. In some cases, THE business communications tool. Along with this, the need for more than ASCII text went from something that only n00bs wanted to a requirement.

If nothing else, a huge chunk of the world can't use ASCII. Anyone with a double-byte character set, (Like most of Asia), can't use ASCII. So we have to use Unicode. Even within single byte character sets, ASCII's hardly reliable. A poorly set up email or list server will mangle such single - byte character sets like French, Norwegian, etc. So, to paraphrase Scott McNealy, ASCII's dead, get over it. We have to use Unicode.

Now, I'll agree that a lot of the implementations of HTML email...well...suck. Things like background colors, embedded multimedia files, inter-network links, javascript, etc., are not only a hindrance to proper communication, but can be a security hazard too. Even more advanced HTML features like CSS, dynamic features, etc., are even more useless.

But should we throw out the good with the bad? Are there no features of HTML that can enhance communication? Obviously there are some good formatting features in HTML that would be useful in an email context. I imagine that what we need to do is look at a mail client with limited HTML such as Microsoft Entourage, or a smaller word processor like TextEdit.

For example, Tabs. We can use HTML to allow for real tabs. Tabs are a valuable formatting construct, and the ability to just use the tab key would not suck. Tabs could easily be represented as either a series of nbsp entities, or a horizontal space 5 characters long. Tabs help indicate the beginning of a paragraph, at least in English, and as such enhance readability and communication.

Being able to easily change fonts and or font sizes. Yes, this does get abused, but usually not for long. The fact is, that in some cases, being able to easily change fonts and font sizes, (for example, being able to use a monospaced font for source code snippets, or a larger font size for a recipient you know has visual problems) enhances communication.

Basic font style formatting. While I am *very* adept at the ASCII trick of using characters such as the asterisk to show emphasis of a word, it's not as instantly obvious as italics, bold, or even both. Underlining is another great way to draw attention to things. Superscripts and subscripts are things that should be supported as well. I mean, it's MUCH nicer to represent gravitational acceleration on Earth as 9.8m/sec² is clearer than 9.8m/sec^2. How about alignments? Again, while not something that should be used constantly, there are times when it comes in handy.

I like centered alignment for things like quotes, or text I really want to set off from the rest of the message. It's a great way to grab attention and communicate a point more clearly. Lists...proper numbered or bulleted lists. With nice formatting that sets the numbers/bullets off properly. If I never had to try and manually do that again, it will be too soon. Even text colors.

Yes, that's right, colored text is not the work of the devil. Especially if, as I often do, you want to post code snippets from AppleScript or any other language. Being able to have my comments green, etc. helps set off the different parts of the code, increasing clarity. I'm not advocating every single part of HTML in email. That would be silly.

But I think that if the major email client vendors, such as Microsoft, Qualcomm, Lotus, Apple, Ximian, etc., would get together and create an email subset of HTML...perhaps emHTML? Then you could have a nice, standard, way to have increased formatting in emails without making it an internet version of Word. So I think I shall have to officially get off the “Email must be nothing but ASCII text” train. It's going to happen anyway folks, so how about dealing with it proactively, as opposed to the fingers-in-ears-and-yelling reaction that the 'Net Pharts have to change.

| Comments ()