Tag Archives: hammer4mac

Hammer For Mac static website generator

I prefer static websites to a CMS for simple product websites because:

  • Static websites are fast.
  • I have more low-level control over the HTML/CSS.
  • I don’t have to worry about the very-real threat of a CMS being hacked.

Obviously writing every page separately in raw HTML/CSS would go against one of the cardinal rules of development, Don’t Repeat Yourself. But you can avoid this using a static website generator such as Hammer for Mac.

hammer

Hammer uses a simple syntax embedded in HTML comments to ‘compile’ a website from source files. I have now used Hammer to create several static HTML/CSS websites, including my perfecttableplan.com and hyperplan.com websites.

I like the simple syntax of Hammer. For example:

I can put the HTML for a page header in an _header.html file and then each page just needs to start with:

<!-- @include _header.html -->

I can define and use variables:

<!-- $current_year 2016 -->
..
<p>Copyright <!-- $current_year -->.</p>

And I can let Hammer work out relative paths:

<img src="@path image.png" />

If Hammer can’t make sense of a source file (e.g. it can’t find the image file), it generates a compilation error.

Because everything is text based I can easily manage all the source in a version control system. Also, if I have to move away from Hammer, it should be relatively straightforward to change the syntax to another static generator (or even write a replacement for Hammer!).

Overall I like Hammer. But it does have a number of shortcomings:

1. The user interface is very limited. Hammer shows you a list of source files and you can click on a source file to see the compiled version or edit the source. But the source files are listed in the order they were edited and you can’t filter or sort the list. This seems such a simple and basic feature, that I can’t understand why the developers have omitted it.

2. Hammer takes a dumb, brute force approach to compilation. If you change any file in a source folder, it recompiles *everything*, without checking if other source files include that file. This is a pain if you have 100+ source files. Surely it wouldn’t be that hard to work out which files depend on which and only recompile the files that need recompiling?

3. You can’t nest variables. For example you can’t do this:

<!-- $current_year 2016 -->
<!-- $copyright_message Copyright <!-- $current_year --> -->

This might sound minor. But it limits the expressiveness of variables significantly.

4. The vendor doesn’t do email support. If you want to communicate with them you have to use Slack or Twitter. I am old fashioned, I like email.

5. It only runs on Mac OS X (the clue is in the name).

At one point Hammer looked like abandonware, but owner riothq.com sold it to beach.io and active development has resumed.

Currently Hammer is priced at £15.39 (and presumably some round number of US dollars). That seems way too cheap. I wish they would price it a bit higher and fix some of the issues above.

 

Updating the PerfectTablePlan website

I created the website for PerfectTablePlan back in 2005, using a dreadfully buggy piece of software called NetObjects Fusion (NOF). The sorry story of why I ended up using NOF is told here.

Until recently the front page looked like this.

old-website-design

I had done a fair amount of A/B test tweaking and it converted visitors to downloads and sales relatively well compared to other downloadable product websites. But it had that ‘designed by a programmer’ look and it wasn’t responsive, so it didn’t work on well on mobile devices. My software only runs on Windows and Mac, but I still want to appear in mobile searches. The HTML generated by NOF was also pretty horrible. Frankly, I was a bit embarrassed by it when I looked at websites for other products. I kept on meaning to update it, but there was always something more urgent or (to be honest) more interesting to do. I finally bit the bullet and had it redesigned in 2015. The front page now looks like this:

new-website-design

The process was:

  1. I wrote a specification for the new design.
  2. I ran a 99Designs.com competition to design a new home page based on the spec.
  3. I selected the winning designer and paid them to design 3 additional pages in the same style.
  4. I paid pixelcrayons.com to code up the 4 pages in responsive CSS/HTML.
  5. I poured all the old content into the new design. Being careful to maintain the existing page names, titles, text and images etc, so as not to lose existing organic traffic.

The whole process didn’t cost a great deal (somewhere around $2k), but it took quite a lot of my time, spread over 5 months. Especially the final step. This wasn’t helped by the size (some 128 pages were converted) and general cruftiness of the old website, and my lack of knowledge of CSS and responsive design.

I didn’t want to be locked in to a CMS, so I used Mac static website generator Hammer4Mac to generate the HTML. It goes without saying that I wrote a program to help me pull all the content out of the old website and into Hammer4Mac! While Hammer4Mac isn’t without flaws, I found it a vast improvement over NOF and the new website is now much easier to update and maintain than the old one.

The new website went live on 16-Dec-2015.

So how much difference did the redesign make? Here are the changes based on comparing 25 weeks of data before the change and 25 weeks of data after the change:

bounce rate +1.5%
time on page +16.0%
traffic +6.5%
        desktop traffic -2.2%
        mobile & tablet traffic +40.0%
completed installs +1.4%
sales transactions +11.4%
total sales value +21.8%
visit to sale conversion ratio +4.6%
average order value +9.4%

The increase in mobile traffic as a proportion of total traffic is pretty clear from analytics (the dip in December is seasonal):

traffic

I believe  a 21.8% improvement in sales is a lot more than I would have got by spending the same amount of time and money improving the product itself, which is pretty mature after 11 years of work.

Overall it looks pretty positive. But, as analytics data is fairly dirty (e.g. due to analytics spam) and I didn’t run a split test, I can’t definitely say that the changes above were due to the website changes. I wasn’t able to compare all the above data with the same time period for the previous year due to some missing analytics data. But the sales data for 25 weeks before and after 16-Dec in the previous year was:

sales transactions -9.9%
total sales value -2.7%
average order value +8.1%

Which implies that the sales changes are unlikely to be due to seasonal factors.

Best of all, I never have to use NetObjects Fusion again!