I was an early adopter of Macaw, the code savvy web design tool. During their Kickstarter campaign, I believed we were finally hitting a point in web design were an intuitive visual design tool finally could create a solid code base in which to build interactive websites and applications. No matter how you feel about auto-generated front end code, the plethora of options in the market to create for the web is great thing.
This past weekend, I participated in the second WordCamp Lancaster and I gave a presentation on how you can use Macaw to create responsive WordPress themes. I knew that this talk was going to make friends and enemies. Visual editors for front end web development are usually talked about with pure disdain from developers and a good bit of web designers. The reason for this is because most visual editors (aka WYSIWYG editors) historically are shit. They don’t write good code behind the scenes and they often encourage designers that you really don’t need to understand HTML and CSS, rather just focus on the visual design. Preferably, if you want to design for the web you need to know and understand the constraints to design for. This means learning HTML and CSS. I have said it many times in the past, designers need to know and understand how to write HTML and CSS. At this point in time in our industry, it’s not even optional anymore. It’s a necessity.
So why would I talk about a visual web editor then? Because I see that they can help streamline workflows and improve process. For instance, you can use an editor like this to create wireframes and mockups that you can show clients and begin a discussion with. From there, once you work on the visual design and tighten it up, you can pass off your work straight to a developer who can then use your work and begin to further develop your code and build out other features. The benefit is that you are not passing on a static file with no information whatsoever on development but rather a responsive mockup with code written behind that gives a decent starting for developers.
Macaw and WordPress
Using Macaw to create responsive mockups and static pages is one thing, but use for WordPress in theme development is an exciting option. Though there is no direct output from Macaw to WordPress, it can be a viable option in building responsive templates. The process from Macaw to WordPress works like this.
- Build your Macaw project
- Publish your Macaw project to get your code. Move to a code editor.
- Start version control
- Clean up your HTML and CSS, add in JS components as needed. Get WordPress ready
- Convert static HTML into theme templates files, create basic parent theme
- Test theme
Phased Work for Theme Development and Version Control
What I really enjoy about Macaw is being able to skip having to use Photoshop, Illustrator or Sketch for web design purposes. Using Macaw in your design process is a pretty efficient and seamless way to work in phases. Macaw can be used for the design phase and the code created can easily be handed off for development prep phase and from there the code is good to go for WordPress theme development phase. The issue of version control then becomes an issue right after the design phase. A Macaw project is saved as .mcw file, a packaged zip file that opens directly in to Macaw. When you publish a Macaw Project, you get a folder with the .mcw file and your output site in the standard folder structure we all know and love. This folder and .mcw file are linked so when you save publish and save your project, the output of HTML and CSS will also change. This is an issue because to do theme development you need to be able to take those files and edit them. At this point, you will need to make a copy of your folder and save that for editing for WordPress theme development. This now has broken any sort of backwards compatibility and essential you have two projects now, a static template project from Macaw and a WordPress theme dev project. At this point, you should take your WordPress theme dev project and begin version control there. Your Macaw project can serve as a master file of sorts, but now essentially the project phase has moved squarely into development. It should be noted that if you edit the HTML and CSS in your Macaw project folder, it will not be implemented when you open up your Macaw project file. This is waterfall development practice; make edits to the .mcw project, publish, output new saved .mcw, output new HTML and CSS. This kind of development isn’t always the best practice, but necessary for how Macaw works. That’s why it’s so important to establish best practices from the beginning to output as succinct and production worthy code so you can have a good base to work on.
Once you are ready to begin theme development, fire up your favorite code editor or IDE and begin work on cleaning up any issues with your HTML. When you are working in Macaw, you want to have the mindset of designing templates and components; repeatable areas that use the same rules and assets. Once you have normalized your entire HTML across your page templates, then I would suggest moving into CSS. Macaw kicks out a lot of CSS and a lot of it repeated. Because of the design to code engine that Macaw runs on, each page is treated with it’s own CSS. This bloat of CSS can be refined and boiled down to utilize in one file, your style.css. If you are building your theme with SASS or LESS, you can easily take the Macaw produced CSS and convert it over to SASS or LESS with any free converter. At this point, any other CSS additions you would like to add, like web and icon fonts, you can pull them in as well. The point of the all of this is to boil down your CSS to the essentials and be able to use in WordPress themes.
Visual Web Editors and the Future
Visual Web Editors have had a pretty rough history. Poor design capabilities with even poorer web code rendering has made them a joke. Developers see them and laugh, and I can’t honestly blame them. Some of the early visual web editors were dominant in the field and with their poor output, many abandoned their use and moved into learning how to code their designs. This approach is great. I strong believe that designers need to understand the basics of HTML and CSS so that they can understand the constraints and possibilities for designing for the web.
The recent renewed interest in visual web editors has seen a number new options crop up as well as revamping older systems. Adobe has a number of options and there are competitors that are leveling the playing field. Macaw’s strength is that it’s very focused on design and ease of use. First and foremost, it’s a tool that allows you create beautiful, high fidelity responsive wireframes and layouts. The fact is that you can use it as the building blocks for WordPress or other CMS’s and that makes it a flexible tool. Does it have its drawbacks? Of course, but then again, no one system or process is perfect.
The future of design in any digital medium is going to be much more focused on user experience and interaction, and good design is crucial to creating those experiences. If programs like Macaw can help designers create for the web in a more meaningful and informed manner, then it can’t all be bad. The important thing is this post about using Macaw for WordPress is not the only workflow, it’s just a workflow. As Macaw and programs like it begin to become more powerful and robust, we could start seeing that line of distinction between front-end development and design blur even further. Is that for everyone? No it’s not but if you are working in that area wouldn’t you like to see more disruption for the better? I am a designer who codes, or a developer who can design. My tools don’t define me.
The Future of Macaw
It’s pretty obvious that I like Macaw, but even I have my own issues with it. I should, everyone should. No software is perfect. The only way it’s going to get better is with community involvement and demand. Macaw has to understand that they truly are a product company and with that mindset, they will need to become more attentive to their customers and begin to work on feature requests that can make it much more accessible and elastic. One thing that everyone has to remember though is that this software is pretty much brand spanking new. It’s been our a little more than a year right now and they are up to version 1.5.14 at the time of this post. If you want to help make Macaw a more viable product and help shape its development, apply the open source mentality to its use. I’m not saying make an open source version of Macaw (though that might be interesting) what I am saying is get involved with sharing projects that can teach others how to use it on GitHub or Dropbox. You can write tutorials and walk-throughs that teach others how to best use it. Record a screencast of your process of using Macaw. Participate in the forums (responsibly) and get interest from colleagues on requesting various features and updates that can help make it a much more viable product.
Currently, the Macaw team has announced that version 2 is codenamed Scarlet and that many of the features and updates that users have asked for on the forums is going to be included. What exactly those features and updates…not sure. The vagueness of the post from the team has excited and put off many users. For myself, I am going to keep an open mind and see what happens in the ensuing months.
Validity for WordPress
Again, I stated that using Macaw for WordPress theme development isn’t the only workflow, it’s just a workflow. Regardless, if you want start creating your own themes for WordPress, you’re going to need serious skills in HTML, CSS, JS, and PHP. There is no way getting around that. There is not going to be easy out of the box solution. Deal with it.
The WordPress Community is truly one of the greatest open source communities out there and to bring up the use of a proprietary software solution to use in you workflow with open-source software sounds a bit counter-intuitive and even, almost, plain blasphemous. To many developers, the idea of a visual web editor writing succinct code is ludicrous. So already, there are two groups that won’t see any value in using a tool like Macaw…and that’s OK. You shouldn’t let tools and process completely define you.
I’ve been following Macaw since its inception and I have been slowing building my own list resources to help me learn the best practices and what it’s capable of doing. Here’s my list.
Macaw Documentation – Handy instructions on how to get started with Macaw, from the Macaw team.
Schonne Eldridge – Probably the preeminent name Macaw use and best practices. Schonne is a developer and designer who wrote a free book on how to use Macaw. He has videos up on youtube that walk you through how to use different tools and features as well how to integrate SASS, LESS, and JS into your post-Macaw phase. I highly recommend getting his book.
Emelyn Baker – Emelyn, in true open source fashion, blogged her project workflow on Medium from beginning to end. There’s not much more that needs to be said, you just need to check it out.
Nicholas Genty – Parisian fellow I spoke with on Twitter who has several projects and tutorials up on his GitHub page that are quite handy.
Andrew Raynes – British designer and developer who has a series of different Macaw projects on up GitHub.
Chris Vernon – I’m going to say American (Mostly because his project is called Hipster) designer who also has a cool Macaw Project you can play around with on GitHub.
Smashing Magazine – Brian Wood wrote an in-depth review of several new visual web editors; webflow, Adobe Edge Reflow CC, and Macaw. This review is pretty lengthy and definitely worth the read.
Me – If you feel like reading my earlier post on Macaw, please have at it.
I stated earlier that I had given a presentation on this topic at the 2015 WordCamp Lancaster. Below you can check out my slides from the talk.