Greg Boone

Tag: Communications

The Lasting Power of WYSIWYG

Jekyll has become one of my favorite things lately. At 18F we’re using it to power our website but also our Hub project which includes serving up snippets, our weekly team updates submitted by Google Form, as well as a tremendous amount of information that is a mix of pages restricted to our team and some that is public. The Hub uses Prose to allow people less comfortable with GitHub and Markdown to edit Jekyll pages with something closer to a What you See is What You Get (WYSIWYG) interface than a typical markdown document has. Prose is a great tool, and I’m not just saying that because we use it. But for many static sites haven’t quite gone far enough, and that’s okay.

Early adopters like static sites a lot. People who bought one of the first Blackberries or used WordPress in 2006, for example, might like static site generators a lot. People who like Markdown or other markup languages enjoy static site generators. And some appreciate the simplicity of configuration found in static sites, especially the lack of a database. For many people like me it is a refreshing focus on writing without the complications of The Admin UI that have plagued even the best CMS platforms.

An example of these complications? I recently helped my wife with some settings on her blog and was reminded how confusing the WordPress Admin can be. Where do you think you should go to set your front page to display a page instead of latest posts? Settings > General? Settings > Writing? Settings > Media? The answer: None of the above. It’s Settings > Reading. I guess when I think about it that makes sense, you’re changing a setting that changes the experience for someone reading your site.

At the same time, there are still some things that a CMS does really well that static site generators
lack
. At least to me, Jekyll’s simplicity is a feature that forces me to think about the value of, for example, a tag archive or automatic image formatting before implementing it. With a CMS these features are there waiting for you to use or extend. WordPress for example provides a really simple API to extend the WYSIWYG interface with ‘shortcodes.’ All of this comes in handy when you need to create a blog post with images floated left and right and center, or when building that tag archive (easy as it may
be
) means taking away time from publishing real content.

If I’m not a developer, needing to become one or hire one just to start writing a blog post is a pretty high barrier to entry. Feeling like I need to become one just to write a blog post is even higher. The reason I became a developer in the first place was that in 2006 when I needed to reboot my college radio station’s website WordPress was insanely easy to install and configure and gave us almost everything we needed (with the right theme and plugins), and in 2009 when I built the first version of HarmsBoone.org and International Underground I didn’t need to learn much beyond CSS and a few WordPress methods. When I eventually needed to know more it was still a fairly low barrier to entry and we always had a website that everybody could edit. In particular, Child themeing is particularly useful for learning WordPress on the fly.

Static sites, for all their simplicies and technical advantages, still have a pretty high barrier to entry, especially if you need to overcome the limitations GitHub pages puts on Jekyll sites. And to be fair, WordPress has significant (read: 8-10 year) head start over Jekyll plus the entire WordPress Core and Automattic teams nurturing the developer base.

Nevertheless, without lowering that bar and adding some of those features it will be really hard to get broader adoption among people who want a Just Start Writing Already. For many, logging in to the WordPress Admin and using the WYSIWYG either to write or to paste in copied text will always be preferable to editing monospaced text with strange formatting signals around it, even if there are buttons to help them out. (Let’s not belittle the bar-lowering power or Prose, Dillinger, and other Markdown helpers, though, for some they may be exactly the right tool.)

It will remain preferable even if they rely on a bookmark in their browser, or an icon on their desktop to get them to the admin screen. Clicking “Preview” will be preferable to navigating to running a shell command and then heading to localhost:4000 because what’s a localhost? What’s that colon all about? And what’s so special about 4000? And clicking “Publish” will definitely be preferable over committing a git workflow to memory.

These are problems Static Site Generators can solve, and part of what makes them beautiful is how they are malleable to each user’s needs. And if you put
a developer on the comms team
you’ll be able to build the site you need on the platform that works because you’ll ask your users what they need and how they work. If your users need to
copy and paste blog posts from Google Docs, give them that. If they want a WYSIWYG editor for writing and collaborating on posts, give them that. If the need the full WordPress UI, give them that. I’m not trying to sound flippant. Building a WYSIWYG on top of Jekyll would be a difficult problem, but it’s not
impossible
. Using Google Drive as a CMS will also take work, it’s not impossible. Building GUI applications to abstract away the command line is difficult, but not impossible.

There are hundreds of content management
systems
and static site generators operating on nearly every language in existence (including FORTRAN). And there are WordPress plugins for nearly everything imaginable at this point, and usually there are three of four of them to choose from. Your mileage will almost certainly vary from one solution to another but go with the solution that will make your content creators most comfortable.

Your Comms Team Needs A Developer

I recently started working at 18F as their first “comms person” which in a startup environment means you’re the person who does everything, just like everyone else, but you focus on writing blogs, publishing the website, and pitching new ideas for how we might communicate about what we do. Most of my work has been on the
website
and a dashboard of all the work we do which has taught me a really important lesson: your website and how it is made, is just as much a communications artifact as anything else your comms team produces.

Despite being on a communications team, I still write a lot of code. Writing code, or being able to jump in and learn some, is increasingly important in all kinds of jobs where people never used to have to write any code, and
communications is no different if only for the simple fact that communications teams often end up owning most of the content and design of their organization’s website and if that website can’t meet their needs it causes rifts of trust between throughout the organization. Be they operational, managerial, or customer facing, a breakdown in trust is toxic and results in the web seeming useless to everyone.

Often this happens because the website was designed and developed to spec by a freelancer or consultant on a one-time contract. An “expert” stands up a shiny looking website that does everything the organization wants it to do, trains a few people how to use it and leaves. Months (days?) later when somebody wants to put more than one photo on a page, they contact the IT
department and are told “pages may only have one picture and it cannot be larger or smaller than x by y dimensions.” (True story.) Software is not static, as people use it, they discover how it can do more for them. Imagine if Microsoft stopped developing Word after it’s initial release. Nobody would use it because it would no longer be valuable.

What an organization can do with its website is mission critical, not just for the communications team. Having a developer available who can make it possible to have more than one photo on your page is as important as having someone who can shoot and edit the photos.

Communications teams should have developers baked in from the start, and not just for adding new features to the website. Having a developer on your communications team means you have someone who  an think about and build other artifacts to augment your message. A developer might think to host your website’s code on GitHub, allowing other developers to learn from it and offer feedback, or build an app to go along with a new initiative the team is rolling out, or identify and fix usability problems with some existing piece of the site.

What your website is made of and how it works speaks volumes about your organization, both internally and externally. Internally, it makes your communications team a “yes first” team, or at least one where the reason for saying no to, say, putting more than one image on a page, is a communications one, not a technical limitation. And when there is a technical limitation, you can realistically evaluate whether it’s possible to overcome it.

This doesn’t mean fire your entire comms team or only hire developers, nor does it mean hiring one developer will be your silver bullet. Instead, focus on fostering your team as one that is equal parts traditional communications and software development. Build a team ready to say yes to what your organization needs and not dependent on some piece of technology nobody understands.