Headway WordPress Framework Review

The Headway Framework

Headway works on a system of layout inheritance. You start with a single layout which is inherited by every page and post on the site. If you add a new layout and assign it to “Single”, it gets applied to pages and posts instead. You can mirror blocks between designs to save time which comes in handy if items are universal, like headers and footers, and you can also tweak them for layouts further down the chain. Need to create a custom layout for a single post or page? Just create it and assign it to that item.

Headway’s layout inheritance makes designing faster but at times more complex.

It’s a simple and effective way to manage layouts, but it’s not quite as straightforward as Gantry’s assignment based system. Headway regularly prompts you asking if you want to edit the inherited layout which gets a bit confusing until you thoroughly understand the system. Some tweaks to the menu system in the grid editor would go a long way to clearing up which layout is being used when. It would get very cumbersome on larger sites.

The grid layout system, and Headway in general, is a bit rough around the edges. At first the simplicity is appealing, but you soon find yourself wishing you could have more detailed information presented.

The ability to draw your layout certainly opens up a lot of possibilities, especially if you’re looking to design a site with uneven rows of content. The drawback is that it can be difficult to get started with a blank canvas, and when you do, it’s sometimes tricky to make sure things are aligned properly because there is no ruler/grid to indicate the distance between blocks. Maybe some people don’t care if there is 10 or 11 pixels between rows, but we do.

The grid layout creator is half of the system. The other half is the style editor. This to has pros and cons. While the visual style editor makes some tasks easy, it complicates others, and the inheritance system makes things much more complex here as styles are inherited from layouts higher up the chain.

Changing styles using the visual editor can lead to unexpected results, as well. I applied a horizontal box shadow effect which was applied vertically for some reason, and when I changed the header font to Copperplate that didn’t work on the live site either as it isn’t included. It didn’t display the correct font in the visual editor, either. Why list fonts that aren’t included with the template or framework?

Let’s say you want to change the font color of the copyright text in the footer. You edit the instance of the block in question, which shows you the options. It also has a tab showing the existing styling, but it doesn’t show where that’s coming from, and when you click to edit the existing setting you are taken to the previous screen to customize it rather than the origin. It’s just confusing and would be tedious to work with when layouts start to get complicated and responsive designs are brought in to play.

Speaking of responsive design, that’s one of Headway’s weakest areas. In order to gain more control over the mobile/tablet design of your website, you must manually set breakpoints on each block and specify how they act on different devices. Divi simply shows a toggle for desktop, tablet, and mobile and you just choose which one you want your content to appear on. With Headway you have to specify the breakpoint manually, set min or max requirements, and choose whether or not to hide the block. This merely hides the content with a style rule which could put you in danger of taking SEO and performance hits if you’re hiding large blocks of content.  If you’re using a parallax design that includes dynamic content blocks you basically can’t use the grid/style editors because they populate the content and you can’t get to the bottom blocks to edit them.

On the plus side, it’s very easy to add widget areas of any size in any part of the design. This adds a lot of flexibility in displaying content and using third party plugins, though adding a lot of them would likely make the widgets area in WordPress a bit overwhelming since they all appear there.

Headway’s grid editor doesn’t give a lot of information about the blocks.

Whether or not the layout system is efficient is somewhat subjective. On the one hand, the inheritance system can make it easy to quickly build out numerous layouts with certain universals elements shared between them. On the other, it requires developers to spend a lot of time building layouts and you have to go back to adjust them in the future because most of the functionality of Headway is in its visual editors, not in WordPress’ Admin interface or default content editor.

Digging deeper into the Headway framework you discover how limited the included blocks are. For example, the social icons only have three options – Peel, Soft, and custom. Peel aren’t actually “peel” images and “soft” are just standard rectangle social icons with rounded corners. If you setup Peel and switch to Soft, you’ll have to re-configure all of your icons because those settings are stored separately. Slider blocks are very limited; you can’t dynamically populate them at all. In the Advanced options for the slider you’re given a marketing message saying the slider is only capable of displaying images and if you want more functionality you’ll need to pony up for a plugin. Of course you could setup a widget block and use any plugin you’d like, but why even include such a limited slider in the first place?

Headway Templates

To speed up testing of Headway we chose their White Wash template. This let us get an idea of how the developers use the framework and what it’s capable of. When choosing a template we were looking for a simple design with a few rows of content, some images, a header and a footer. This gave us comparable testing results and helps make it easier to review the frameworks equally. We also built some designs from scratch and tried another template, Whiteboard.

Conclusions

Headway’s unique feature, allowing you to draw your layout, is very attractive to those developers who are looking to create unique layouts without manually coding them completely. It’s an idea that’s great in theory but in practice can be difficult to use and at times actually slow down the design process because let’s face it; a blank canvas can be intimidating.

Drawing your layout is as simple as advertised, but making it look great and work well on mobile devices is another story. The included modules are limited in number and features, forcing you to either purchase Headway’s enhanced versions or third party plugins. That would be acceptable if other frameworks didn’t include far superior modules.

Headway’s templates also leave a lot to be desired. They are more work to setup than the others we tested and the two we worked with were missing functionality and/or partially broken out of the box. We’re also concerned that they aren’t fully compatible with the latest version of WordPress as the demos are running on WordPress 4.0 and there are numerous issues when they are setup in WordPress 4.4. Running the WordPress theme check tool against the Headway Base theme throws dozens of errors and warnings, though some of the notices could be due to the framework not technically being a WordPress theme.

We’d only recommend Headway to developers looking for a framework that you can freehand your design with. Once you acclimate to Headway’s interface and if you’re comfortable doing a bit of coding, you may be happy with your results. Stay away from their pre-made templates and build from scratch.