Development is proceeding at a steady pace, at present we’re finalizing the code that allows the MenuMachine application to seamlessly interoperate with the plug-ins for Dreamweaver and Coda. We have implemented the import of MenuMachine 2 for GoLive menus and I’m pleased to report it’s working really well, so those of you with legacy menus will hopefully be able to transition with minimal issues.

Work on the new web site is well advanced, we’re implementing it completely in HTML5 and it’s looking good. We may open it up to beta testers very soon.

I’ll be posting here more often from now on in the run-up to release day.

I know that many of you are keen to know the current status of our new version of MenuMachine. As noted in my last post about this, we ran into some issues that made things more difficult than anticipated.

MenuMachine’s data model (the information that is stored in memory and on disk) is surprisingly complicated, and due to various issues we were having with reliability and performance, I decided to move the internals of MenuMachine over to Apple’s Core Data framework.

This was not an easy decision as it meant ripping out the guts of the app and replacing them with new plumbing. The good news is that I’m pretty much finished this task now, with the result that the app is now much, much more reliable and much faster. This change to the core of the application will also make future changes to the data model (such as adding new menu types, for example) much, much easier. I’m really pleased with the result.

This done, we’re now back on track. Although we won’t be releasing the new version this year, it’s not that far away now.

Panic have just released a new version of Coda, their excellent web development app. The big news for us is that it now includes a very nice plug-in extension API, so we are looking seriously at including full support for Coda in the initial release of MenuMachine 3. It looks like the new API supports everything we need to provide first-class support for MenuMachine, which is great.

Thanks for all your comments regarding other editors, we are certainly looking at all the options that you have suggested. Someone mentioned that it would be nice to have support for GoLive 9. We are not going to be targeting GoLive with the initial release as it simply doesn’t make business sense for us to pour development resources into a discontinued product. I’m not saying we won’t support it (I personally would like to see a GoLive extension, since I’ve spent a lot of time in that environment!) but it won’t be in the initial release.

Firstly, since several of you have asked, I want to give you a general idea of our release schedule. We are aiming for a release towards the end of Q1 2009 and are fairly confident of our ability to hit that target. I know this is probably later than many of you were hoping, but we still have a lot to do. However, we are progressing well and are slightly ahead of schedule. At this stage it’s too early to say when we’ll have a release ready for beta testing.

Back to the main topic. When we were designing the new version of MenuMachine, we wanted to provide users with a choice of multiple menu types. MenuMachine 2 allowed users to select vertically-expanding or cascading menus, but we realize that there are many more menu types that users might like to create, and there are also new menu types that we wanted to implement for the first time.

For this reason, menu types in MenuMachine 3 have been implemented as plugins to the main application. This means that we can easily add new menu types to MenuMachine without having to alter the base application code. We anticipate shipping MenuMachine 3 with a variety of useful menu types and we then expect to release new menu types as we are able to develop them. This means that MenuMachine 3 should become more powerful and useful over time.

We have also implemented our external editor support using a plug-in architecture. This will allow us to easily add support for other editor platforms. We will definitely be supporting Dreamweaver at launch and if we have time the initial release might support some other editors. We anticipate creating editor support modules for BBEdit, TextMate and possibly Coda and Espresso initially, with more to follow. If you have any suggestions for editors that you’d like to see support for, please let me know either via email or in the comments.

I’ve had a fair amount of feedback since my initial post which contained the news that MenuMachine is to become a Mac-only application. Windows users are unhappy with our decision which is perfectly understandable, whereas Mac users have been overwhelmingly positive with their reactions, which is great.

I thought I’d explain a little more about what the new version of MenuMachine will do and what technologies we’ll be implementing, since that’s what many of you have asked about. In this article I’ll call the new version MenuMachine 3, but as yet we haven’t decided on the final name.

When we first designed MenuMachine 2, one of the primary design goals was to make it as easy as possible for users to manage updates to the menus across the entire site. In order to do this, we implemented MenuMachine 2 to use a single menu definition, stored once for the whole site. This menu definition was then interpreted by the browser when a page containing a menu was loaded and the relative links were calculated to be correct for the current page. For the most part this works well — if the browser has JavaScript enabled. We looked at several ways to incorporate accessible content into the page as well as the JavaScript-generated links and eventually settled on a simple link to a menu map page, with the option to customise the code.

Many users really loved the simplicity of updating a web site’s menus that this technique provided, but it obviously was not ideal from an accessibility or SEO standpoint. Several things have changed in the web landscape in the last few years, and overwhelmingly the recommended way of creating navigation these days is to use a simple unordered list incorporating <ul> and <li> tags to form the menu structure, with the menu’s appearance created using CSS. This results in a very fast loading menu as the menu code does not have to be created on-the fly using JavaScript as the page loads.

MenuMachine 3 will use HTML list syntax styled with CSS for all the menu types it creates. If JavaScript is enabled, the menus will be enhanced but they will work even if JavaScript is disabled. This is the best outcome for accessibility and search engine optimisation. Obviously, it makes it a bit more tricky as far as site-wide updating goes as the code is hard-wired into each page that contains a menu, however if you use Dreamweaver this will be handled automatically thanks to some magic in our Dreamweaver plugin. For those who would still like the MenuMachine 2 site-wide updating behaviour, we will support this by using AJAX techniques to allow the menu to be injected into the page on the fly.

The other big advance in the last few years is with JavaScript frameworks. Basically, these are blocks of JavaScript code that are used as building blocks to make creating cross-platform JavaScript code faster and much more robust. There are several of these libraries available as open source and they are used by many, many developers. I spent a huge amount of time with MenuMachine 2 tracking down obscure bugs in various browsers to create a cross-browser JavaScript library to support the menus. A large proportion of our support issues, especially in the early days of MenuMachine 2, were all related to problems in the browser support code, largely due to its complexity and the vast array of browser differences and bugs. These days, MenuMachine 2 code is very stable in a wide range of browsers (thanks to a lot of hard slog) but now that people are using some of the more complex JavaScript frameworks in their sites we are having a few compatibility issues that we could not have anticipated.

What we’ve decided with MenuMachine 3 is to use one of these standard open-source frameworks ourselves. This means that you can be assured that the foundation code for your menus will have been battle tested by thousands of developers and will work in a wide variety of browsers. The library we are basing the MenuMachine 3 browser code on is a modified version of jQuery. We are using a customised, stripped-back version of this library that allows us to reduce the footprint for MenuMachine 3 so that it is significantly smaller than the MenuMachine 2 support library while also being faster and more stable. One of the great advantages of jQuery is that it does not conflict with other JavaScript code in the page, including other complex frameworks like prototype, dojo or mootools. Those of you that have had problems using MenuMachine with Lightbox and similar effects will greatly benefit from this.

Most importantly, switching to a robust open-source base for our browser code will free up the time that we would otherwise be spending debugging obscure cross-browser issues so that we can spend more time adding exciting functionality to MenuMachine. We have already been able to expand the number of menu types that can be created with MenuMachine 3 by using this framework and thanks to the plug-in nature of MenuMachine 3, we can easily add new menu types in future.

From the user’s point of view, all of this will be essentially invisible. MenuMachine will handle all the code creation and link management behind the scenes so you can just get on with creating beautiful, functional navigation systems for your web sites, secure in the knowledge that the code will be fast and compatible with a wide variety of browsers.

Update: Check out this link which discusses JavaScript frameworks and basically reinforces our decision to use one.

Many of you have written to us wanting news of where we’re heading now that GoLive is no more. As some of you may have noticed, I’ve posted a small amount of information about our future plans already but I wanted to let all our customers know a bit more about the general direction in which we’re headed, as well as some rationale behind the decisions that we’ve made. For that reason, I’ve started this blog which I hope to use as a way to keep up a dialog with you, our loyal users.

Very shortly after we released MenuMachine 2 in 2005, Adobe dropped the bombshell that they were purchasing Macromedia, which of course included GoLive’s direct competitor, Dreamweaver. While we initially didn’t know how this would affect GoLive, we certainly suspected that it might throw a spanner in the works.

Despite my best efforts to try and obtain some sort of information from Adobe about their future plans for GoLive, I drew a blank, even after earnestly pleading to various contacts in the know. Some of you undoubtedly think that we must have been given advance warning that GoLive was being shut down, but unfortunately all we got from Adobe was stony silence. We found out about the discontinuation of GoLive the same way you did. I must admit to being pretty annoyed about this, given the level of support and that I have given Adobe and GoLive over the years, as well as the huge number of bug reports and feedback I gave them about GoLive and the GoLive SDK. Nevertheless, that’s how it went down and we have to live with it.

Anyway, after the initial flurry of support requests and bug fixes following MenuMachine 2′s release, we started investigating what we should do in order to avoid getting caught out if GoLive went the way of the Dodo.

We basically concluded that we had four options:

do nothing, keep the status quo and just continue development of MenuMachine for GoLive

continue development of MenuMachine for GoLive and also create a version of MenuMachine as a plugin for Dreamweaver

drop MenuMachine for GoLive and build a MenuMachine plugin for Dreamweaver

build MenuMachine as a stand-alone application, with plugin support for Dreamweaver and possibly other HTML tools

We determined that option 1 was not feasible, as the likelihood that Dreamweaver would supplant GoLive was not insignificant. To investigate options 2 and 3, I had already done some preliminary prototype work with Dreamweaver and basically determined that there was no way to build a version of MenuMachine for Dreamweaver that would work anywhere near as well as the GoLive version, due to several major deficiencies in the Dreamweaver extensibility APIs. While I could have probably built something that worked, it would not have been something I was proud of and you, our customers, would likely have been disappointed.

So, I can announce today that we decided on option 4. The next version of MenuMachine will be a totally standalone application, with plugin support for Dreamweaver at launch and other HTML editors to follow. The next version of MenuMachine will also be built for and will only run on Mac OS X.

I am very sorry to say to our Windows-using customers that unfortunately this is the end of the line, we will no longer be developing a Windows-compatible version of MenuMachine. We simply do not have the resources to develop both Mac and Windows versions simultaneously. This was a very hard decision and not one we took lightly.

To help make this decision, we had a good look at our user base. As part of our sales process, we record the platform that each customer is using and this information is also recorded when MenuMachine is downloaded. We were thus able to determine that close to 70% of our users are using Macs and we therefore hope that we’re making the best decision for the majority of our users. We are very passionate about the Mac and will be delivering a first-class Mac OS X user experience.

There are many, many advantages to MenuMachine running as a standalone application, for example:

The user interface can now be totally integrated with the OS, with support for keyboard shortcuts, copy and paste, drag and drop and so on.

We can access the full power of the Mac OS X APIs which allows us to do many things that would be difficult or impossible when running as a plugin in either GoLive or Dreamweaver.

We get massive performance improvements due to the fact that the code is compiled as a native binary rather than interpreted JavaScript.

We can support multiple HTML editors, including text editors which will allow hand-coders to use MenuMachine to rapidly develop sophisticated navigation UIs for their sites.

You as the user are not locked to using one HTML tool if you want to use MenuMachine, you are free to change HTML editors as your needs evolve.

We do not want the WYSIWYG editor user experience to suffer from the fact that the MenuMachine editor is now standalone. We are incorporating first-class support for Dreamweaver with a set of extensions that will allow menus to be inserted into pages and previewed just like MenuMachine 2 for GoLive. You will still be able to drag menus to position them and also easily and automatically update the links in your pages when a menu is updated. We have spent a lot of time ensuring that the Dreamweaver support is top-notch. We will also be making available a free Dreamweaver extension that allows Dreamweaver users running Windows or users without a copy of MenuMachine to preview the menus in their Dreamweaver layouts.

We intend to provide support for other Mac HTML editors in future. The new version of MenuMachine is very extensible and uses a plugin architecture that allows us to easily add support for other editors.

Rewriting MenuMachine as a standalone application from scratch has been a major effort for us and while it’s not ready to go just yet, we are working very hard to deliver it as soon as we possibly can. I am very excited about the new version and I’m certain you’ll be pleased with the finished product. I will be posting more details about what we are planning for the new version soon.