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.

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.

So why hasn’t the United States switched to metric yet?  There was a half-hearted attempt in the ’70’s which failed miserably.  I guess some people think that converting to metric constitutes being unpatriotic, giving up something distinctly American, and scandalously embracing heathen, Unchristian enemies in a New World Order.  Either that, or it’s too expensive.

Well, the most obvious thing to note is that our system isn’t American at all.  It’s British, and they abandoned it because it didn’t make sense.  Another thing to note is that in all the countries in the world, only the United States, Liberia, and Myanmar (Burma) haven’t adopted the metric system.  We’re keeping some bad company there.  Besides, the rest of the scientific and mathematics community seem to have moved on to the metric system, including NASA.  All of the competitive world trade and all international industry is conducted in metric.  So really, by not switching now, we’re reducing Americans’ competitiveness in the world, not enhancing it by being superior and different.  And has anyone noticed that 20 years ago America had the biggest everything?  Now (taking my references from “The Post-American World“) the tallest building in the world, the largest company in the world, the largest refinery in the world, the largest passenger airplane, the largest ferris wheel in the world, the largest casino in the world, and the largest mall in the world are all outside of the United States.  By stubbornly thinking that we stand alone, by not educating the American people on the system that everyone else is using, we’re hurting our competitiveness and stance in the world, not helping it.

So finance is a big one.  Since the math and science communities have already switched over, the biggest areas where I see measurements in a consumer’s daily life are: construction, weather, and road signage.  Construction seems to have partially taken the plunge, and I’m sure there exist tools to make conversions easier for workers, and if not, it wouldn’t take them long to adjust to this in their daily habits.  Weather is easy.  Weather is something that’s constantly updated, so it’s just a simple matter of changing what you’re publishing.  Road signage is probably the most expensive thing, but other countries (countries that successfully metrified themselves) found that a cold turkey solution was much better than maintaining a dual system.  Instead of replacing all the signs, why not just put stickers with new numbers over the existing signs, and then replace them as needed with fully metric signs?  Seems to work, and relatively inexpensive.  Of course, you’re always going to have the toothless hick that sees a sign that says the speed limit is 90 and revs his Bubba-mobile up to 90 miles per hour.

All that said, I’ve found a couple of ways to do my part to get more comfortable with metric (it’s officially supported in the United States, after all, just not common).  First, is to change the settings on my computer to Metric.  I’m not sure what settings OS X has that would make a difference one way or the other, but I suppose I’ll find out.  I’ve also switched the weather on my computer to report in Celcius, not hard.  I’ll also probably quickly rescale my house in Blender to be metric based… which will save me a lot of headache I’m sure.

Not that I intend to become an advocate or anything, but some useful sites to help promote awareness of the issue are Go Metric! and the US Metric Association.

It’s that time of year again.  Twice a year, in January and in July, something special happens.  Journalists’ and bloggers’ keyboards are aflutter, eye-strain headaches abound from staring at grainy “spy shots” of a certain theater in San Francisco, and the rumor mills swell uncontrollably with what Dear Leader, Steve Jobs, might unveil.

This year’s Apple Worldwide Developer’s Conference is obviously no different.  The past few days have seen the almost certain prediction of the iPhone 3G and the probably rebranding of .Mac to MobileMe.  But there’s always something that slips in unnoticed.  I originally thought that it was way too soon for us to be hearing anything about a new iWork update, since iWork ‘08 hasn’t been out for very long.  But all the speculation about a possible OS upgrade has me thinking otherwise since Leopard came out months after iWork ‘08.

Personally I hope (as I have anxiously hoped for the last two iWork releases) to see Apple get firmly behind the OpenDocument standard for its suite of programs so that iWork gains a TRUE place in a mixed platform corporate (and home) environment. OpenDocument makes a lot of sense for the following reasons:

1) Apple has a history of supporting open standards where it bolsters its business and reduces the complexity on their own developers,

2) it would be FAR easier for Apple to implement than native support for OOXML (heck, it’s even easier for Microsoft to implement in their OWN product than OOXML),

3) No more dialogs asking, “Do you want to save this in iWork ‘06 format, iWork ‘08 format, iWork…. ” What’s good for one is good for everyone.

4) OpenDocument is extensible so they could… possibly… implement such features as Numbers’ multi-table-on-a-single-sheet feature (not sure about the viability of this one), and

5) it will make Apple not look like they’re drinking Microsoft’s Kool-Aid, while, when native ODF support is added to MS Office next year, Apple will be totally compatible and competitive with not just most Windows users but Linux/open source advocates too.

6) Apple obviously has expressed interest in heating up competition with Microsoft on the desktop since the disaster called Vista.  If Apple ever hopes to bring iWork to Windows, joining iTunes and Safari, they’ll need to have a document format that’s not based on bundles.  A .pages file is just a folder as far as Windows is concerned.

Of course, the obvious argument against this is the tremendous effort that Apple has put into evolving its own XML document format.  It’s hard to see Apple just tossing all their work that brought them so far so fast in iWork’s three year life.  But for myself, I would love to see an ODF-native iWork so that I can use a program with Apple-pizaaz and not have to depend on the upcoming OpenOffice 3.0.  While it is the best ODF program on the market, they just don’t “get” the Mac platform.  Their clunky beta looks and feels like it belongs on a Windows ME installation, not on Mac OS X (or just OS X Leopard, as the new banners seem to have rebranded it).

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.

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!

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.

The Family Group screen is, arguably, the most important screen in the entire application.  This screen is where virtually all of the data entry is done and where the user spends most of his/her time.  I’ll begin by analyzing the interfaces of some popular existing software.

Family Tree Maker is the leading (or at least the best marketed) genealogy software on Windows.  The family group screen on it is, ironically, the least intuitive.  It provides extremely basic data entry functions.  You can enter information for a husband, wife, and birth, death, and burial dates/places.  You can also enter children.

Reunion 9 is the Family Tree Maker equivalent on the Mac.  Recently it has been rewritten as a Universal Binary application and has seen many improvements.  The Family Group screen in Reunion is more feature rich, allowing the user to enter and visualize more information.

GRAMPS is the open source Linux genealogy program, and the one with the most confusing and least useful interface.  There really isn’t a “family group” screen per se, but an individual screen that brings up information related to one individual.  There are advantages to this type of layout, however.  It features a tabbed interface that allows the user to quickly navigate information for the selected individual and see which areas have content.

So, what I’ve done is create a few quick mockups of how the interface might work.  These are quick Photoshop brainstorms, so a lot of the details are left to be worked out.  My main goal was to provide an interface to make sure that the user knows where there is more information to be had on an individual.  In the process, I also want to be able to show all spouses for the selected individuals and a way visualize all children related to them.  So, if Jane Doe married three times, all of her children should be displayed with all husbands (with the option of turning this off, perhaps).  I think this can be accomplished through some sort of color coding.

The first concept builds on the Reunion idea of displaying a father on the left side, a mother on the right, and some facts and children below.  This idea would more appropriately take advantage of increasingly-popular widescreen monitors and allow more space vertically to display more information.  Spouses are displayed with color codes and may be checked on or off.  This also allows some room for things like timelines or event summaries to be displayed.  Unfortunately, this takes an individual approach than a family group approach.  Events displayed here would display only for the selected individual.  Clicking on one of the spouses names would shift the darker blue background to the spouse side and focus on his/her information.

The second concept takes a horizontal approach, displayed the husband above the wife, tabs to the right of each to get to the fathers and mothers of the individuals, and spouse information at the bottom of the person’s box.  A solid colored background behind the spouse name indicates which spouse is currently active, where the active spouse’s information is also displayed.  Checkboxes could be added to show/not show children for these individuals.  There is obviously less vertical space to play with in this model.

Perhaps the best option is a hybrid between the two, since there tends to be a lot of horizontal space left over in the second approach, but I’m not sure about how much information could be displayed for both spouses.  More ideas to come later, comments and critiques very much appreciated.

Main Goals

There are two main goals of the user interface for Treefrog.  First is to take the best ideas of some popular genealogy programs and, without sacrificing function or usability, create a consistent user interface across platforms.  The second goal is to perhaps improve on the user interface to provide a better way to visualize data.  Genealogy software is generally lacking in this area, and it’s easy to see why.  Once you start factoring in complex family relationships (multiple spouses, children with reference to two different brothers as their father, adopted children, etc.), the challenges become clear.  However, I feel that the important goal first is to at least fill the gaps across platforms.

Navigating the Interface

My initial thought was to keep all of the navigation top-centric with a series of icons across the top to redraw the main window.  That is, switching between “Family Group” view, “Reports” view, “Multimedia” view, and “Tree” view, etc.  I started looking at arguably some of the best user interfaces designed, Apple’s, and found that there were very few cases where the navigation at the top of the screen actually redrew the main window.  As I looked to PC programs, I also found this to be the case.  Most of the options to redraw the main window were located in the left side of the screen, with the top of the screen being reserved for functions that enhanced or provided additional functionality to the main window.

This is consistent across all of the iLife apps.   In iTunes, the top navigation is reserved to indicate track progress and to provide different viewing options.  Down the left navigation you see different categories that are used to redraw the interface.  In iPhoto, there isn’t even a top navigation bar, instead leaving the different photo events, albums, and views to the left side, and providing a menu at the bottom of the main window that is context-sensitive to the photo/album you’re viewing.

So how does this apply to Treefrog?  Options that will redraw the main window include a Research Center/Summary page, Index (list of all individuals in the family file), Family Group, Reports, Multimedia, Maps, and Sources.  Functions that might enhance the views include an Index of individuals in the family file, a Search box, Sources, and Multimedia, all of which could be used to update the focus of the main window.  The latter two initially seem redundant, but my vision is that the left navigation will bring up a center where you can manage, tag, organize, etc. the sources and multimedia, whereas the top navigation source and multimedia links will open up drawers that you can use to drag sources and multimedia items onto persons and events.

With so little going into the top navigation, it may be a better idea to put a very small top navigation bar, or perhaps none at all and make the drawers sensitive to what’s in the main window.  That said, here is a first brainstorm in Photoshop (note: this is an extremely quickly done mockup, I know it’s quite amateurish).  Obiously this is very Mac, but there’s much room for Linux/Ubuntu and Windows native look and feel here.

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