Early last May, over a year ago, we were working on Sandvox version 1.2.1, but we knew we needed to start working on a major new version of Sandvox that would eliminate a lot of the issues we were seeing with our initial architecture. So we split our code base into two branches: one for continued, minor updates to the shipping Sandvox, and another for a major rewrite of the application. Maybe not quite from the ground up, but at least from the knees up.
It's a big upgrade. It features major improvements to media processing, new and enhanced pagelets, fifty design templates, new blogging features, and for Sandvox Pro Edition, new Code Injection points. We'll let you read the press release for the overview, or you can even read the release notes if you are one of the twelve people who wants to get a more detailed change list. (And even that isn't particularly detailed: We counted 3,370 incremental updates to our program code for Sandvox since we started this branch!)
Doing a major rewrite like this was a huge undertaking, and normally a major new version like this would get a new major version number like "2.0," except that most of the work in this effort was under the hood, and a 2.0 version of an application needs to look like a big change. So we decided to call this version 1.5. Sure there would be plenty of new visible features but most of our work is not that obvious.
One of the biggest changes in Sandvox 1.5 is how the source document is stored. In 1.0 through 1.2.8, all the data — pages, images, even QuickTime movies — were stored in a single database file. It worked, except it was extremely fragile, as we discovered perhaps too late. The WebView, the component that is also used by Apple's Safari to display web pages, was loading pages and their subordinate images directly from our database, at the same time that we were trying to load information about the document. Behind the scenes, it was a mess! This might not be so bad, except that we found (to our surprise) that people were building websites of several hundred pages in size, not a few dozen as we had anticipated. So we needed to handle bigger, more complicated websites. Thanks to some helpful tips from our friends, we figured out how to store the data in a package — essentially, a folder that looks like a file. This simplified the whole process quite a bit and allowed for some big speedups and improvements in stability.
Another major change under the hood was the way we synchronized the changes that you, the Sandvox user made on the screen with the data stored in our database. The old way worked, more or less, but it was problematic and slow because we would load the entire WebView when anything changed. The new way is quite streamlined; we're very proud of it. What you'll notice is faster response to just about everything.
Because this was such a major rewrite, it took a long time — longer than we expected, naturally. We were finally able to share our first alpha versions starting with a tiny group of friends back in April, and then making beta versions of Sandvox to a wider audience in June when we made it available via our Yahoo! group. The people who tried out Sandvox in these stages and sent in countless feedback messages deserve our heartiest thanks.
We'd also like to take this opportunity to extend our special thanks to Mike Abdullah. Although some of you may have corresponded with Mike on support issues, he has made enormous, vital, and all too often unsung contributions directly to the engineering of Sandvox 1.5. We are very grateful for both his code and his good-natured approach. Thanks for joining the team, Mike!
What's ahead for Sandvox? We have some great plans for 2.0 that we started drafting out earlier this summer (when the three of us had the rare opportunity to be in the same room together). We think you'll like what we come up with. But, we expect that it will take longer than expected to finish.