Paradise Road: Ken’s Blog

So I’ve been using the OpenOffice 3.0 betas on my Mac and I just can’t get past the feeling that the folks at Sun are just trying to keep up with the 1990’s.  While it is nice that the latest version runs under OS X without using X11, it must also be realized that it remains slow and cludgey to the point of frustration.  There weren’t enough features added to justify a major version jump, although somehow OpenOffice has taken a major jump down with performance.  Grant it that these are betas and somewhat better performance is to be expected from the final release, but NeoOffice compares only slightly better.  Scroll speed is very jerky (sometimes freezing between page switches), text appears poorly antialiased and poorly kerned on Windows and Mac (and downright abominable on Linux), images appear jagged and seem to move around the page inexplicably, manually positioning images and text frames within a page of text is guesswork at best, and the interface… well let’s just not start on that.  

And yet, OpenOffice.org is the poster child for open source office suites.  It’s included by default in nearly every single Linux distribution and is proclaimed as the Microsoft Office alternative on Windows.  It, and derivatives of it, remain the only viable implementations of the OpenDocument format.

Certainly there must be a better way to do this.  Certainly there is a way to get consistent cross-platform performance with high quality text and image rendering and support for networking and the impending eventual move to cloud-based applications?  I think there is, and the answer lies with Mozilla.  Mozilla stormed onto the scene several years ago and today has become the cornerstone for BOTH open standards advocation on the web AND for intuitive, navigable, and ultimately usable user interfaces.  Why not make a Mozilla Office Suite?  There are many arguments in favor of this:

• Gecko is a mature platform that claims 140 million Firefox users as of February 2008 (probably many more now that Firefox 3 has been released) and 48 million Thunderbird downloads, versus 98 million OpenOffice.org downloads.
• The ethos surrounding Mozilla is one of providing the end user the best experience, not necessarily the most options.  This has led them to develop a platform that is extremely light weight and focused on performance.
• Much of Mozilla’s products are written in JavaScript, which would seem to be a hindrance on a large scale office suite, but the most recent builds of an optimized JavaScript interpreter approaches native code speeds, with even more improvements on the way.
• All of the networking components, text rendering/kerning components, and image rendering and scaling components  are already in place and are well tested across all major platforms.
• There is a proven extension system with automatic checking for updates polished and in place.
• A lot of the basic composition functionality is already contained in the Thunderbird project.
• Mozilla is now working to support open and platform specific multimedia frameworks more tightly into their products, with the inclusion of Ogg Theora native support in the browser right alongside support for the video framework for whatever platform it’s running on (Quicktime for OS X, DirectShow for Windows, GStreamer, etc., for Linux).  This would be a boon to those using embedded video in documents, or more practically, in presentations.
• Since OpenDocument is DOM based, it would be an easy transition to make native rendering of OpenDocument files available for viewing and collaboration on the web.  Imagine the maturity of Google Documents if you could leverage Mozilla Office’s capabilities?  It would be the single best way to turn XUL-runner into the ultimate stand-alone platform like some have recently talked about doing.
• Not anything specific to Mozilla here, but the user interface could be optimized with tabs for different documents, a platform-specific look and feel that feels at home regardless of what platform you’re on, smooth scrolling through documents (I pasted 150+ pages into Thunderbird, albeit without images, and it scrolled through it satisfyingly smoothly), and much, much more.

I’ve always wanted to be a Linux guy, using and supporting as much as possible the philosophy of Free, Libre Open Source Software, but every time I’ve been put off by the amount of time involved in getting simple things done (one should NOT have to go to Google to figure out how to add fonts to the system) and the fact that the graphical experience was either too mundane or so effusive that it actually got in the way of the user experience.  Don’t get me wrong, I’m a developer and a power user, but I’d much rather be spending my time being productive than tweaking in a terminal to infinity.

So a few years back, Ubuntu came onto the scene declaring that the user should never have to go into the command line to do routine stuff and, over the past few years of releases, has slowly made Linux easier and more intuitive to use.  Now they’re setting themselves the lofty goal of targeting Apple in terms of user experience.

The idea of a freely available operating system fostering the growth of technology in the developing world and the embrace of open standards has always intrigued me.  The more I read about Mark Shuttleworth, the more I like him.  My favorite quote from his recent OSCON keynote: “The great task in front of us over the next two years is to lift the experience of the Linux desktop from something that is stable and robust and not so pretty, into something that is art.” Art!  From a Linux guy!  This guy really should be on Apple’s Think Different commercial.  He’s one of those people who’s crazy enough to think he can change the world.

Now, don’t get me wrong.  I love my Apple computer and doubt I’ll be switching my primary OS any time soon.  Apple has set a wonderful precedent in user experience that others will be hard pressed to exceed and also embraces some of the same open source philosophies that I do.  But I’ll definitely continue to keep my eye on Ubuntu and the inspiration that Mark Shuttleworth brings.  After all, Steve Jobs has never been to space.

OpenOffice.org beta was released today.  I think I can already post about it since it appears to be the same build as the BEA300m2 developer snapshot that I had been using.  Overall, it feels like a lackluster release that hasn’t received much usability love.  Really, you’d expect a lot more from a product that has broad corporate support from Sun Microsystems and IBM and is the de facto standard cross-platform office suite.  There’s a problem when your main version release takes upwards of two years to make and the big features that you highlight are “the new ‘Start Centre’, new fresh-looking icons, and a new zoom control in the status bar”.

I hate to tell the OpenOffice devs, but these ‘new fresh-looking icons’ passed the point of being either new or fresh looking around 2001. I know I’m a Mac guy and probably vain about my user interface, but seriously… these icons are unattractive at the small size, and downright hideous at the large size.  Tango icons look much better, and Tango is nothing to write home about.  Thing is, if it weren’t for those icons you wouldn’t even be able to tell the difference between 2.x and 3.x.

There seem to have been very few, if any, usability improvements.  Apple is doing innovative stuff with iWork Pages in simplifying the UI and adding context sensitive formatting; IBM is doing some innovative stuff with Symphony by putting all of the context-sensitive editing on the right side of the screen to take better advantage of documents being vertical and most new monitors being widescreen; Microsoft is doing usability studies and trying to find a way that works better for their users, although there have been some issues with the “Ribbon,” at least they’re trying.  I understand OpenOffice.org’s philosophy is ‘looks like Word ‘97′, but can’t they find a better key selling point than “you should use our product because we don’t evolve from a familiar, crufty old interface.”

Some months ago, one of the developers was arguing against critics of OpenOffice.org’s look and feel, saying that it could and would be made to look native on platforms, OS X in particular.  And one person posted on the 3.0 roadmap wiki extolling the merits of taking the approach that IBM was with Symphony.  I guess these persons weren’t very high up on the food chain.

I’m a strong supporter of open standards, OASIS OpenDocument in particular.  I whole heartedly believe that OOXML is wrong to be a standard because of the lack of attention to technical flaws, complexity, and less-than-a-single-vendor implementation (not to mention how the whole standardization process went down).  But, given the ISO’s approval of OOXML and the fact that this new OpenOffice.org represents the “best of” breed in ODF suites, I’m afraid that we’d all better start learning to speak Chinese… that is… recognizing OOXML.  Actually, I guess everyone else already has.

I realize that this is a lot of criticism for a fresh out of the oven Beta, but I also realize that there’s not likely to be many UI changes between now and OpenOffice.org 3.0 final in September.  At least I can count on some performance improvements though, because the Beta that I’m using runs like a crippled dog on a quad-core Mac Pro.

Lightning is supposed to reach 0.9 in the August timeframe, and it’s going to be a long wait.  I haven’t used Lightning because the interface was so kludgy to me that I didn’t feel like it was making me productive (yeah, superficial of me, whatever).  But at the recent Calendar face to face the developers put a lot of spit and polish into how the calendar works and addressed some real usability issues, focusing on giving the user the most important information (and no more) in a modern, attractive way.  God bless them, they even removed the 2px border on the months and replaced it with something less fugly.

A developer’s outline of some of the changes can be found on Bryan Clark’s blog here, and additional interface mockups can be found on the Mozilla Wiki here and here.

Now, I’m hopeful that the Thunderbird devs will also apply the spit and polish to the 3.0 release due out at the end of the year or (more likely) early next year.  I’d love to see Thunderbird come into the modern age of email and set defaults that people actually USE instead of being idealistic about how email SHOULD function.  Specifically

• The account setup is a mess, and there are way too many redundant options between Options and Accounts
• All modern email programs just assume that you’re going to be using HTML.  I don’t know of any other (popular) program that would assume that you’re sending plain text or put up an annoying prompt to send in plain text, html, or both.  I know that email *should* be in plain text and there’s no reason for it not to, but people just don’t use it that way.
• All modern email programs also assume a sans serif font for message composition.  While serifs are great for printed documents, it doesn’t have as usable place in the world of electronic, on-screen purposes.
• Why is the default behavior set to put the reply BELOW the message being replied to?  I mean, I understand that as a holdout from the newsgroup days it makes more logical sense for the conversation to flow properly from top to bottom with the more recent stuff at the bottom of the page.  But seriously… who uses email like that?
• Nearly every email program I’ve ever seen that people actually use forwards messages inline and not as attachments.  Why does Thunderbird insist on the default being to forward as an attachment?

I know those are a couple of items that have been controversial within the developer community before, but whenever I recommend Thunderbird to someone else I find that they either stop using it or ask me to change it to work like Outlook Express.  I know those options can be changed, but it’s a confusing process to do so in the plethora of options menus.  It’s time to do to Thunderbird what Mozilla did to Firefox: Simply, simplify, simplify, and add better defaults!

I’ve just created my first simple XULRunner-based application.  In order to make creating the application work in OS X, a number of different steps have to be taken from the Windows version.  Unfortunately, there doesn’t seem to be a comprehensive guide for newbies to do so, so I created my own based on several resources.  Since much of what follows is direct quotes or slightly modified, I want to be sure to give credit where credit is due:

http://developer.mozilla.org/en/docs/Getting_started_with_XULRunner
http://groups.google.pt/group/mozilla.dev.tech.xul/browse_thread/thread/d8c0127036615492
http://rcrowley.org/2007/07/17/cross-platform-xpcom-a-howto/
http://developer.mozilla.org/en/docs/XULRunner:Deploying_XULRunner_1.8

Step 1: Install the XULRunner Framework

The first step is to download and install the XULRunner Framework.  XULRunner may be downloaded from here: http://developer.mozilla.org/en/docs/XULRunner.  On the Mac, just run the installer, which installs XULRunner as XUL.Framework in the /Library/Frameworks directory.

Step 2: Set up the Application Directory Structure

I created the root in a new /Users/{username}/Desktop/approotfolder folder, but you can create it wherever you like. Here is the subfolder structure:

../approotfolder
…./myapp
……/chrome
……../content
……….main.xul
……chrome.manifest
…./defaults
……/preferences
……..prefs.js
….application.ini

Notice that there are 4 files in the folder structure: application.ini, chrome.manifest, prefs.js, and main.xul.

Step 3: Set up the XUL Application Files

Application.ini

The application.ini file acts as the XULRunner entry point for your application. It specifies how your application intends to use the XULRunner platform as well as configure some information that XULRunner uses to run your application. Here is mine:

[App]
Vendor=Finkle
Name=Test App
Version=1.0
BuildID=20060101
Copyright=Copyright (c) 2006 Mark Finkle
ID=xulapp@starkravingfinkle.org

[Gecko]
MinVersion=1.8
MaxVersion=1.9.0.*

chrome.manifest

The chrome manifest file is used by XULRunner to define specific URIs which in turn are used to locate application resources. This will become clearer when we see how the “chrome://” URI is used. Application chrome can be in a single or a few JAR files or uncompressed as folders and files. I am using the uncompressed method for now. Here is my manifest:

content myapp file:content/

prefs.js

The prefs.js file tells XULRunner the name of the XUL file to use as the main window. Here is mine:
pref(”toolkit.defaultChromeURI”, “chrome://myapp/content/main.xul”);

XULRunner preferences include:
toolkit.defaultChromeURI
Specifies the default window to open when the application is launched.
toolkit.defaultChromeFeatures
Specifies the features passed to window.open() when the main application window is opened.
toolkit.singletonWindowType
Allows configuring the application to allow only one instance at a time.

This is described in further detail in XULRunner:Specifying Startup Chrome Window.

main.xul

Finally, we need to create a simple XUL window, which is described in the file main.xul. Nothing fancy here, just the minimum we need to make a window. No menus or anything:

<?xml version=”1.0″?>
<?xml-stylesheet href=”chrome://global/skin/” type=”text/css”?>

<window id=”main” title=”My App” width=”300″ height=”300″
xmlns=”http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul”>
<caption label=”Hello World”/>
</window>

Note: Make sure there is no extra whitespace at the beginning of the XML/XUL file

Step 4: Set up the OS X .app directory structure.

XULRunner for Mac is slightly more complicated because of strict requirements for GUI apps running in OS X. First, go download XULRunner and install the package. It will create itself deep within /Library/Frameworks (quite separate from the Windows version). In myapp, create a new directory called MacApp.app or something else ending in .app. Within this directory create one called Contents (capitalization is important), and within Contents create Frameworks and MacOS. Now create three symbolic links to complete the Mac directory structure:

ln -s /Library/Frameworks/XUL.framework MacApp.app/Contents/Frameworks/XUL.framework
ln -s ../../../myapp MacApp.app/Contents/MacOS/Resources
ln -s /Library/Frameworks/XUL.framework/Versions/Current/xulrunner MacApp.app/Contents/MacOS/xulrunner

If you would like to ship the application on a private install of XULRunner, you could always just copy the respective files into the XUL.framework and the MacOS/xulrunner directories.

Now create MacApp.app/Contents/Info.plist and dump this in, making sure to change things in ALL CAPS. I am almost certain this is not optimal as it repeats itself a lot. But it is functional.  Note: when using XULRunner 1.9, it doesn’t seem to matter what is in this file, or even that it exists.  XULRunner generates its own Info.plist file.

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>xulrunner</string>
<key>CFBundleGetInfoString</key>
<string>3.0</string>
<key>CFBundleIdentifier</key>
<string>YOUR_APP_ID</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>YOUR_APP_VERSION</string>
<key>CFBundleName</key>
<string>YOUR_APP_NAME</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>YOUR_APP_VERSION</string>
<key>CFBundleSignature</key>
<string>YOUR_APP_ID</string>
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLName</key>
<string>YOUR_APP_NAME</string>
<key>CFBundleURLSchemes</key>
<array>
<string>chrome</string>
</array>
</dict>
</array>
<key>CFBundleVersion</key>
<string>YOUR_APP_VERSION</string>
</dict>
</plist>

Review Directory Structure:

As a review, here’s how our tree looks now:
/approotfolder
.. /myapp
…. /chrome
…. /content
…… main.xul
…. chrome.manifest
…. /defaults
…… /preferences
…….. prefs.js
…. application.ini
.. /MacApp.app
…. /Contents
…. /Frameworks
…… XUL.framework→/Library/Frameworks/XUL.framework
…. Info.plist
…. /MacOS
…… /xulrunner→/Library/Frameworks/XUL.framework/Versions/Current/xulrunner
…… /Resources→../../../myapp

Step 5: Run the Application

The moment of truth. We need to get XULRunner to launch the bare-bones application.  Before you can run a XULRunner application, you must install it using the –install-app xulrunner commandline flag. Installing the application creates an OS X application bundle:

/Library/Frameworks/XUL.framework/xulrunner-bin –install-app /<path>/<to>/myapp.zip

Once installed, you can run the application:

/Library/Frameworks/XUL.framework/xulrunner-bin “/Applications/Finkle/Test App.app/Contents/Resources/application.ini”

You should now see a window that looks something like this:

This application will output to Applications/Vendor Name/App Name (as specified in the application.ini).

Since XULRunner 1.9 seems to generate its own plist file (disregarding anything in the custom one), I’m not sure how to add application icons yet.  I’m sure there’s a way to specify this in the application.ini somehow, but since I’m brand new to XUL/XULRunner I can’t really speak to that.

Treefrog, that is, the name that a friend has coined for my project “Genzilla,” a Mozilla/XUL-based, cross-platform genealogy application, is starting to take some shape.  I’m still very early in the would-be development of it and have a lot to learn about developing Real Applications (TM) before I make any progress, but at least I’m starting to define a goal.  Over the next several blog posts, I’m going to spend some time thinking through how this should work.

Desktop App or Web App?

The big question is whether or not to develop Treefrog as a standalone desktop application or as a web-application.  There are major benefits to developing it as a web application, beyond web applications being hip since everyone seems to be moving to the cloud computing/software as a service ideal these days.  And there are the obvious benefits in doing so: maintained control over upgrades and bug fixes, instantly visible by everyone on the domain; no installation or platform-specific glitches (other than browser JavaScript issues); easy ability to roll out the application to a variety of non-traditional platforms such as mobile devices (I could see an awesome iPhone app here); the ability to tap into social networking to enhance the collection and organization of data; perhaps most importantly, I already know how to develop web applications.  I’ve been doing that for a while.

We’re on the verge of ubiquitous Internet access.  Many phone carriers are shipping with unlimited data Internet plans these days, and I can foresee a day in the not-too-distant future where all laptops have carrier-independent cellular Internet connectivity built right in.  Unlike the days where you had to worry about offline access, we’ll be at a point where having a computer and having Internet access are synonyms.  Mozilla, like Google, is quick to promote the web as a platform for all things.  A Mozilla affiliate recently said (paraphrasing) that Mozilla isn’t really going to focus on XULRunner as a desktop app development platform and that it’s a much better idea to focus on promoting a healthy, open Internet with web applications. 

But on the desktop side, there are benefits as well.  First and foremost is that there really isn’t a good, quality genealogy program that works cross-platform.  Mac users have Reunion, Linux users have GRAMPS, and Windows users have Family Tree Maker, but there’s no good program intended to make a researcher’s genealogy portable across platforms.  It would be much easier to deal with privacy issues on the desktop rather than the web.  There are opportunities to take advantage of native platform look and feel, extensions to further manipulate the data, and the ability to work with large media files such as high-resolution photo and source document scans.  Let’s face it, many genealogists are older in age and may not be keen on the idea of using some Internet app to store all of their research.  Finally, a personal reason to do a desktop app is for the sheer challenge of it.  I’ve never done a desktop application and have always been interested in this arcane world.

Besides, Treefrog is such a trendy name for a Mozilla-based application!  It fits right in with Firefox, Thunderbird, Songbird, etc.  But, if the desktop truly does become obsolete in a few years as some predict I suppose that another benefit would be that, by choosing to develop on XULRunner, my application would be largely developed in the language of the web and should I decide to take it to the web or tie into the Mozilla Weave API’s in the future it wouldn’t be as difficult.

Launchpad Page: https://launchpad.net/treefrog

There is an important vote coming up in the International Organization for Standardization on whether or not to promote Microsoft’s in-house developed Office Open XML (OOXML) to the status of being an accepted international standard. Should Microsoft’s format receive this blessing, it will be free and clear to lean heavily on its corporate girth in the direction of government and other agencies that require the formats that they are saving data in to be fully documented and open.

I’m not whole-heartedly opposing this standpoint as an anti-Microsoft or pro-underdog statement, but rather because this move puts a terrible risk on the long-term viability of very important data. I am an amateur genealogist. Preserving my research is extremely important to me. I need to know that in thirty years or if I migrate to another platform I will be able to open the word processing documents containing my research. For government agencies, the issue is clear. The government already has hundreds of thousands of records dating to the 1970’s that are inaccessible due to obsolete data storage formats on tape. There simply no longer exists a device that will read them. It is inexcusable for this to happen again.

Microsoft claims that its own format is an open spec, meeting the needs of government agencies. However, the same company has demonstrated behaviors that are monopolistic, often resulting in vendor lock-in. It also retains the only chair on the technical committee overseeing the development of OOXML, and has reserved the right to make its own custom version of the specification (should it not agree with the recommendations of the technical committee). This has already happened with Microsoft Office 2007, which uses a variation of the OOXML spec that is already obsoleted by the changes Microsoft has had to make to the format since it failed the fast-track vote last year after being considered dangerously flawed. The clearest reasoning that the body developing the OOXML spec cannot and should not be trusted is the clearly cited evidence that Microsoft tried to buy votes for OOXML in Sweden and exhibited strong-arm pressure amongst other voting bodies.

In order for a specification to be considered “open,” in my opinion it must be vendor neutral, easy to understand, and openly implemented or implementable on a variety of platforms. To date, the Microsoft specification consists of over 6,000 pages, some of which is incomplete and encompasses older, binary specs from Microsoft’s former Office suite formats. It pushes techniques using the .NET framework and VisualBasic, neither of which are open or implemented on other platforms.

This next point should be separate from this post, because this post is primarily about the format. There is a separation between the format (OOXML) and the application implementing the format (Microsoft Office). Let’s divulge and use the application as a case in point. Microsoft says that the complexity of and inclusion of binary blobs in OOXML are primarily to facilitate backwards compatibility. In theory this is a good thing. This whole post is about being able to open documents saved thirty years in the past. In reality, though, Microsoft has demonstrated the exact opposite of this behavior by disabling the ability to open no less than twenty four older file formats in Microsoft Office 2007, calling them inferior. This included Microsoft’s own default format of the then-current Microsoft Office for Mac release. It later apologized and said that what it really meant was it’s way of opening the files was inferior, but the spin couldn’t deny the fact that Microsoft had willfully removed a function from a program that allowed it to work with competing formats and even some of its own. It has already been demonstrated that most of the functionality can be converted without the tie-down to proprietary technology. Virtually all functionality could be converted were Microsoft to open up the specification to their binary formats, as has been requested.

There are alternatives already in place and here today. The current format war puts Microsoft’s OOXML in competition with OpenDocument format, or ODF. ODF is a vendor-neutral specification based on an easily readable syntax that has already gone through the standards process. It was approved as an international standard two years ago, in fact. It is developed and maintained by OASIS, an organization composed of 600 member organizations, the largest of which are IBM, Sun, Novell, and Google. Until recently, Microsoft was also a member of the organization.

There are tools to read and write ODF already implemented in multi-platform solutions, primarily in OpenOffice.org but the specification is evolving independently. A rapidly growing list of other applications are implementing the specification (including Microsoft Office) in large part due to the clarity and elegance of the specification. What OOXML accomplishes in 6,000+ pages, ODF accomplishes and exceeds in 2,500+. OpenDocument includes clear specifications for word processing documents, spreadsheets, presentations, graphics, and formulas. What’s more, it’s rapidly becoming a specification to build other specifications on. There is currently an effort to develop an OpenDocument-compatible raster graphics storage format called OpenRaster.

In closing, I would urge readers to not subscribe to the FUD that Microsoft is spreading and not follow blindly along a path just because it’s easy to say, “Well, Microsoft and Office are big enough that there will always be a way to open the files.” Think about where we were just ten years ago, about how much has changed. Look at the diminishing market share of Microsoft to rivals such as Apple and Firefox. Think about how important the long term viability of your information is. And think about data portability. Support open formats with open and clear direction.

A report was recently published by the Burton Group that collects nearly all of the misconceptions about ODF that Microsoft is spreading, a report that was completely debunked by the OpenDocument Alliance. It’s worth reading simply to know the facts.

So, Steve Jobs just concluded his Macworld keynote speech. Biggest news: the iPhone is now official. All I can say is: dang. That thing is going to be awesome. It’s the combination of three devices: a widescreen video iPod (not so exciting), a cellular phone (moderately exciting), and a productivity suite running a full OS (very exciting).

Obviously, what I’m most interested in is the fact that this thing runs Mac OS X. Yes, it RUNS Mac OS X. It’s got mobile versions of Mail.app and Safari, and Jobs claims you can run desktop-class applications on it. Sweet. Sadly, I’m sure that internet access will require the $40/month Internet fee (something I doubt I’d use enough to justify the cost), but there’s good news: it does Wi-fi and Bluetooth. So, given that the places that I would use it also have WiFi access, I’d be set. It’s supposed to make it really easy to navigate and dial people, but I didn’t quite visualize there have only been text descriptions of it. I’m sure the video will be available this evening or tomorrow. It has integration with Google Maps and GPS functions, so it’s aware of where you are. It doesn’t use a stylus, but rather the finger as a pointing device. In fact, it has multitouch, so you can use more than one finger to do gestures and navigate. All that said, the iPhone sounds close to the perfect organizational device I’ve wanted for some time now. Sadly, it’s not cheap at $499 (4GB) and $599 (8GB). But it’s not going to be released until June, so I’ve got time to save back my money if I decide I want it.
Apple also debuted their iTV device, now called appletv. Seems nice enough, HD video playback, a 40GB drive, and wireless 802.11n access to a Mac/PC that otherwise serves as a storage device for larger videos. Compared to Tivo’s Series3, which is like $800, it seems a value at $299. That said, I don’t think it’s really worth the money. If it recorded television shows also, maybe.
I was shocked at the lack of a few things though. First and foremost, where is Leopard? I mean, let’s see some new secret features, demos, or at least a release date announced for the thing! There was no iWork or iLife announcements, even though Amazon accidentally linked them on their site. On the iPhone, how automatic is the synchronization with the Mac?  Will they sync if they realize each other’s presence via bluetooth?  Will it sync over the Internet without requiring a .Mac subscription?  Will it sync with multiple Macs easily?  How easy is note taking on the Mac?  Can I take a note and turn it into a To Do or add it to my Calendar, akin to what was demoed for Leopard?  Another biggie is, what about iTunes? They’ve announced that the appletv plays HD video, which implies that HD video would be available on iTunes. Where’s the beef?  A number of questions remain.

Two days ago I had an epiphany: I hate Quicken for Mac. Actually, that’s something I’ve known for a while now, but I’ve continued in hopes that perhaps some day Intuit would release a truly cross platform solution with feature parity with Windows. Reality sets in when you realize that they’re still using OS9-era code, have become pretty much the only company not to release a major software as Universal Binary, and the Intuit CEO is even saying that Quicken Mac’s future is in question. They probably get more money for Quicken by bundling it with new Macs than they do upgraders, there’s just no compelling reason for anyone to use it. But my issues with Quicken for Mac are for another post.

Friday I set in to convert my data to an alternative: MoneyDance from Reilly Technologies. MoneyDance is probably the highest rated Quicken alternative for Mac. Let me throw this out first: it also has one of the ugliest interfaces of all of the alternatives. I was put off several times by it, but then decided to jump right in. So far, I’m very pleased with it. It takes a simpler approach to finance management than any of the programs I’ve used, and still manages to pack in features that other alternatives miss, especially online banking.

My own pros and cons list:

Pros:

• It’s built in Java, and is completely cross platform! Not only does this program run on Windows and Mac, but Linux to boot! While it’s not open source, it is open standards-based. That counts for a lot in my book (especially having gone through the rigors of trying to migrate my data from Money to Quicken for Mac).
• It can handle most accounts that you can throw at it: banking, credit card, loan, investments… you name it.
• It’s got a simple, double entry accounting model that simply works, contrasting with other programs that have way too much focus on making displaying your transactions seem like some kind of arcane, black magic, and usually fouling up in the process.
• Reports are not the best, but are nice. I feel much more in control of my financial picture than trying to use Quicken for Mac’s.
• Tagging for transactions. I’ve not used it yet, but in my book tagging is the best thing since sliced bread!
• Online banking. This is the main feature that made me consider this over iBank.
• More of a minor thing, but this is the only financial management program that can correctly determine my payment amount for my home mortgage and other loans. Even MS Money got that one wrong.

Cons:

• For me, the butt-ugly interface. I have to commend them for producing a product that works natively so well across so many platforms, but in this day and age of information presented with smooth colors and in useful ways, there’s no excuse for the first thing you see being a calendar with Java-shade-of-grey colors.
• Reports are lacking somewhat in what they can produce. I’d kill to see the equivalent of MS Money’s “Monthly Report”. Heck, if I could just run reports on specific Payees (or even see a list of Payees) I’d be happy.
• Online Banking, I believe, is new to this release of MoneyDance. As such, it still feels “tacked on”. I’ve not found a way to enter an online transaction from the account register itself. Instead, it has to be done via an online dialog box that asks for your password every time. I haven’t used it yet, but I suspect that this will cause some confusion when I go to pay an online payment that I have a reminder set up for–I’ll probably wind up with two entries in my register. I’d love to be able to send an online payment from the account register, or at least have my financial data automatically, periodically downloaded without having to ask for my password every time!
• Help documentation is sparse and largley incomplete. When it’s important to find out if I’m doing things the way MoneyDance thinks I should be doing them, I often have to go to the help forums.
• Paycheck Manger to track my pre-tax deductions, salary, bonus, etc. More cool points if they could make it to where I could easily run reports on my Paycheck vs. my wife’s Paycheck to compare notes for W2 forms.
• 401k Manager is desperately needed. Although it’s flexible enough to work very capably with Investment Accounts, I’m far from a financial wiz and don’t understand the inner workings of Investment or 401k accounts. Those things truly are arcane, black magic! Give me a wizard!

All in all, I like MoneyDance and feel more in control and informed of my finances than over the past year using Quicken for Mac. Slack must be cut for MoneyDance’s faults; compared to Quicken it’s still a fledgling lil’ fella. I’m hopeful that they’ll continue to make improvements in the program’s usability and help documentation, and continue to become a solid performer across all platforms, especially Linux.