Jul 2

I upgraded our support incident handling system about 10 days ago. Unfortunately, I only discovered yesterday that it has failed badly, not only is it not handling support emails properly but it also dumped almost 5GB of garbage data onto our web host’s server, which has not gone down well.

I am working on fixing the problem at present but it may take a day or so before it’s up and running again. If you have sent us a support query in the last week or so and have not had a response, I apologize profusely. We will respond to your enquiry as soon as is humanly possible.

Update July 2, 2009: We have moved to a new support platform, (FogBugz, if you’re interested), which should mean that support is back to normal for Chelmsford Locks. We’re handling the support queries that have slipped through the cracks on a case by case basis. Please let me know if you have any problems with the new system, although hopefully you won’t really notice a difference. Please also let me know if you have a support issue that has not been responded to.

Jun 16

I’ve had quite a few emails from many of you about the beta program for the new version of MenuMachine. We anticipate releasing the first beta to some of you in the next week or so, with more people added to the testing program as we proceed.

If you have contacted me about the beta, please be assured that you are on the list but do not be alarmed if you are not in the very first round of outside testing.

Mar 26

As you will have noticed, the blog hasn’t been updated for a while and some of you have been asking about what the state of MenuMachine is, and even if we are still working on it.

I can tell you that we are currently working extremely hard on getting it out the door.

We did hope to have it ready by the end of this quarter but unfortunately due to several unfortunate and non-development-related problems we have not been able to meet that estimate. We are currently looking at a release by mid-year.

Jan 3

This is just a quick post to provide a permanent link to another little plug-in for Coda, Tabster:


All Tabster does is map Tab and Shift-Tab to Command-] and Command-[, which allows you to indent blocks of text using the Tab key and outdent them by using Shift-Tab. Users of other editors that use these key combinations for block indenting will find this makes switching to Coda a lot easier.

The plug-in requires Mac OS 10.5 and is open source under the MIT license. Source code is inside the bundle and at Google Code.


Update: Some users with non-English keyboards were reporting issues when pressing certain symbol keys. Version 1.02 should resolve this problem.

Update 2: Will Cosgrove from Panic pointed out some issues with the key press handling in another plug-in, Wrapster, that apply to Tabster also. I have modified the Tabster code to make things safer.

Update 3: I’ve fixed a bug introduced in 1.2 which caused shift-arrow to trigger Tabster. I’ve revved the version to 1.3 and moved the project to Google Code.

Update 4: Added a minor fix that works around an issue on Snow Leopard where the plug-in would stop working after a period of time.

Dec 15

While working on an upcoming site with Panic’s excellent Coda application, I was constantly frustrated by its lack of a separate live web preview window. Coda is a “one window app” and all content, including the preview, is accessed via tabs in a single window.

I am so used to having a live web preview window available (Dreamweaver has one, as do BBEdit, TextMate, CSSEdit and others) that I found Coda’s lack of one to be the single most frustrating thing about the otherwise excellent application.

So, this last weekend I decided to do something about it and quickly wrote a Live Preview plug-in for Coda, again using the new Cocoa API that I first used with Wrapster.

The result is called Lively and you can grab it here:


Please note that you must be running Mac OS 10.5 (Leopard) in order to use this plugin.

The plug-in is open source and released under the MIT License. You can find the source in the plug-in’s bundle wrapper by selecting the plug-in in the Finder and choosing “Open Package Contents” from the Finder’s contextual menu.

More cleverer

It was very easy to create a separate HTML window to display the current HTML source. The real trick is working with CSS files, which is what I primarily wanted to edit. It turns out this is more complex than I originally thought, and the final result is still not ideal.

With Lively installed, you can open a preview window by choosing the Open Lively Preview Window menu item under the Plug-ins menu, or just press Control-P.

When you begin editing an HTML file, the preview window will show the current page as rendered by WebKit (the same renderer used by Coda). If you then begin editing the code of any CSS file that is linked by the HTML page, the preview will display your current, live CSS edits by overriding the stylesheet on disk.

You can switch back to the HTML view and change the code and the preview will retain your live edits. If you want to revert to the original CSS with no overrides, just click the Reload Page button in the preview window.

Lively tries to be clever about what files it tries to preview. There is a file extension exclusion list embedded in the bundle, which currently blocks the following file extensions from loading in the preview window:

 js rb py pl java c cpp m h txt cgi sh
It doesn’t make much sense to preview these file types for most users. You can of course add or remove from this list by editing the IgnoredFileExtensions.plist file in the plugin’s bundle.



You knew there would be some. At present Coda’s plug-in API does not allow developers access to any view except the main code editor window. This means that Lively cannot detect any edits you make in the CSS editor unless you switch to the Edit tab after making your changes. Yes, this is annoying but I can’t do anything about it at present.

Also, preview probably won’t work properly for remote files. It won’t pre-process .php and other files, so if you have that code in your page it will be dumped into the preview window. Again, this is a limitation of the Coda API in that plug-ins can’t access the site settings and therefore cannot know which server-side URLs to look at. It would be possible to add some configuration to Lively to add this, but I don’t have time at present to do that.

I hope that Lively is useful for some of you, as always feedback is much appreciated.

(Oh, and MenuMachine users: I haven’t forgotten about you. This tool is extremely useful for me in developing MenuMachine 3).

Update: Thanks to James Bisset, who reported a problem rendering certain pages. It turns out I’d neglected to turn on the UTF-8 support when compiling the PCRE regular expression engine, which was causing a crash (exception) whenever a page containing non-ASCII characters was loaded. I’ve fixed this in version 1.0b2.

Update 2: I’ve revved Lively to 1.0. The changes include:

  • CSS overriding is improved so that the original CSS file is no longer used at all in the rendered output, only the modified CSS
  • image resources and other linked items in CSS files now display correctly
  • the CSS overrides are correctly flushed if the current site changes
Nov 13

I am pretty excited at the release of the new Coda plug-in SDK and I have been investigating it in preparation for building a Coda integration plugin for MenuMachine 3. As an exercise, I decided to try building a small, useful plug-in. I noticed that several people on the coda-users mailing list were bemoaning the fact that there was no “smart symbol wrapping” functionality in Coda, such as exists in TextMate.

Smart symbol wrapping is a neat feature for coders. The way it works is that you select some text in the editor and then press a particular symbol key, such as a square bracket. This key press is intercepted and the selected text is automatically wrapped in a pair of square brackets. Smart symbol wrapping handles all the various types of paired symbols, such as braces, parentheses and several other types of symbols such as quote marks.

I decided to write a Coda plug-in using the Cocoa API to implement this feature, which turned out to be reasonably straightforward. The resulting plugin, Wrapster, can be downloaded here.

Please note that you must be running Mac OS 10.5 (Leopard) in order to use this plugin.

The plug-in is open source and released under the MIT License. You can find the source in the plug-in’s bundle wrapper by selecting the plug-in in the Finder and choosing “Open Package Contents” from the Finder’s contextual menu.

The plugin uses a simple property list file (WrapOptions.plist, again in the wrapper) to configure the replacement characters so you can add to or modify the replacements that ship with it, which are:

{ } [ ] ( ) < > " '  “ ” ‘ ’ `

The WrapOptions.plist file contains a comment with instructions for how to edit the file.

You can enable and disable Wrapster in the Plug-Ins menu in Coda.

In terms of implementation, the only slightly tricky thing was finding a way to detect key events before Coda gets hold of them. It turns out that the only way to do this without having access to the internals of Coda is to use an Event Tap, which allows the plugin to capture the raw events posted from the keyboard before Coda’s NSApplication instance gets a chance to process those events. This does mean that in order to use the plug-in, you need to enable “Access for assistive devices” in the Universal Access System Preferences pane, as shown below. If you don’t do this, Wrapster cannot get access to any key events.

The Universal Access Preferences pane

The Universal Access Preferences pane

I hope you find this plug-in useful. It certainly has served its purpose for me, I’m pretty familiar now with the Coda SDK and what can be done with it. The guys at Panic have done a great job with the API which is simple and well thought out.

I’d love to hear your feedback about the plug-in (good and bad!).

Update: It seems that Wrapster was preventing Command-] and Command-[ from working. I’ve updated it to version 1.1 and it will now not replace the text if either the Control or Command keys are down, it will just pass the key press through to Coda.

Update 2: Justin on the coda-users mailing list pointed out that Wrapster would activate if text was selected in the page and you entered one of the special characters in the search field. I’ve fixed this now with version 1.2, Wrapster will now only activate when you are actually editing text. Get the update here.

Update 3: Thanks to Rainer Brockerhoff who alerted me in the comments to a more efficient way of handling the Quartz Event Tap that Wrapster uses to capture key events. I’ve updated Wrapster to 1.2.1 and incorporated his suggestions. There is no real need to update to this latest version unless you just absolutely must have shiny new stuff :-) .

Update 4:Thanks to Will Cosgrove from Panic who pointed out that one of the Apple methods I was using to intercept key press events is buggy and can cause a hang in the window server (this means a total UI lockup, very bad!). I have modified the code to make things safer. All users should update to the new version 1.3.

Nov 12

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.

Oct 10

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.

Aug 14

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.

Aug 7

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:

  1. do nothing, keep the status quo and just continue development of MenuMachine for GoLive
  2. continue development of MenuMachine for GoLive and also create a version of MenuMachine as a plugin for Dreamweaver
  3. drop MenuMachine for GoLive and build a MenuMachine plugin for Dreamweaver
  4. 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.

Next Entries »