Web Production Tips, Redux

A while back, I got asked for tips on Web production, a little random but offered what it’s worth. Slightly updated from an earlier post, 2/20/2018. Feel free to share with those in the web game.

Random Website Production Tips courtesy of Arthur Smith

  • Sign your work: I’ve found it useful to make sure people put their names (or at least initials) on all concept stage and later docs (specs, treatments, mission statements, wireframes, page designs, whatever). I used to only ask for dates, but “signing your work” may actually improve quality and it is also a godsend later when you are trying to track something down from an archive.
  • Number wireframes: Decimal numbering navigation trees on wireframes/screen comps has been helpful. (That is, assigning a number to each path (Home page =1, a sub-page like “about us” = 1.1 etc.) although as complicated hierarchies become less prevalent on sites, may not be as important.
  • Responsive from the get go: Checking responsive view compatibility really early and being psychologically prepared to clip the wings of a really nice design solution and content strategy if it’s not feasible.
  • Workflow realism: Be prepared for clients’ (or partners) non-use of proposed workflow tools for content, delivery and review etc. To paraphrase Dorothy Parker, you can lead a client to BaseCamp, Google Drive, DropBox, SharePoint or whatever, but you can’t make them click. Most people are reluctant to add another tool to their work ecosystem, and a vendor seldom has the leverage to persuade them to do so. I ask how clients already work with copy, visual assets, and do review for existing projects, and then work out an approach based on that that’s bearable for the web team. It is often email attachments, the bane of any web producer, but then I put them in the tool I need and name them using the production convention. I work on small sites, and I realize something this ad hoc may not scale.
  • Milestones: Rally around a fixed external event to shape client schedules and expectations (even if it’s a sort of made up event). It’s best if there is a plausible date to tie production milestones to, but even if not, designate one based on something on the calendar. For instance, end of a semester for an academic client, annual meeting for a non-profit, etc. Some public version of a deliverable should be tied to this., “e.g., we will focus group the alpha at the next regional meeting.” What’s key is that be such a date be front of mind for client and feasible for you. End of contract dates don’t necessarily work this way. For one thing, they can be amended, but dates of public meetings cannot. If you have to keep looking up a date to see when something major is due, it’s a bad sign.
  • Presentation tools for sketches: Consider Keynote, (or if you must, PowerPoint ) for concept and design stage work. If your designers are comfortable with it and particularly if you are working from a family of templates, have designers create plausible Keynote “page shells” that then can be updated by producers and writers to iterate content strategy. This is sort of a hack, and it’s not what Keynote is for, per se, but it is much more convenient (and less costly) that working on content revisions in a designer/Photoshop workflow. For one thing, text in Keynote is much easier to move around and chunk, and the graphics tools are sufficient at least to wireframe, or even do simple page design. Photoshop (or other image tools, are not text friendly). Don’t leave the designer and developer out of this phase, though. It’s possible to create something in Keynote that is insane to execute. Periodic check ins on feasibility and implications are good, as is working from a shell that both the designer and developer have seen and ok’d, or better participated in.
  • Start early on copy and other content: Also, if you are careful, you can get a jump on cleaning up the copy, and sort out images, rights etc., in this Keynote stage, not just resolve the content strategy problems. Interestingly enough, now that I work mostly in WordPress, I still find that this Keynote workflow helps. WordPress sort of tempts you to think you can do iterative content development if you have chosen the right theme etc. This hasn’t worked for me: it’s a publishing content management approach (presentation and content wrangling) it’s not a content creation tool, at least for anything editorially intensive. Google docs or DropBox Paper/Hackpad can be your friend here, but most of all choose a tool that your team is likely to use.
  • Map editorial workflows: figure out in advance how copy (and other assets) are getting from the client or the writer to the site, and how revisions, proofreading/copyediting and publishing will be done. Note who’s job it is, and do a ‘pre-flight’ to make sure this approach will work. Particularly important for big sites or conversion jobs.
  • Restrain your theme addiction: If you are in a WordPress world, or other theme-based platform, don’t move to the theme choice stage until content strategy is established. (This is really hard for me, and others I’m betting. There are so many themes, and it’s fun to think in a preliminary way about your project and then go “theme shopping”.) The danger is you start thinking about the project in terms of what the theme will do, rather than what the project goals are. (It’s a version of having all those typefaces available in a design program: sort of irresistible to try them out early on.) It’s also a waste of time learning a theme and its quirks, only to find out you won’t use it later. (Although this only happens once in my experience!) If you are building a theme from scratch, or redoing most or all of the CSS, then this would not necessarily apply. Still good to have a clear idea of what success looks like for your content first.
  • Stay in touch: Do a weekly report email to clients, include milestones from your project spreadsheet or PM tool, and color code tasks: on time (green), behind, (red) ahead (blue), not started (black), so it can be glanced at (but not edited).
  • Keep track: Document as you go. (Like flossing easy to say, hard to do).
  • If timelines change, be realistic: If some stage takes a lot more time than it was scheduled and budgeted for, the natural tendency is to believe the “Just So story” that you will “catch up” later. If the first stage took twice as long, it’s likely that the other stages will take twice as long. Make an alternate Plan-B version of the schedule that uses this delay as a factor for all remaining stages. For example, if it took the client 10 weeks instead of 5 to provide copy and signoff on concept spec, multiply all remaining stages (page designs, alpha, testing, whatever) by 2 and see where that gets you. Figure out how you could manage such a schedule, and find a professional and respectful way to address this with your client. This isn’t very comfortable, but even if you are just thinking through it yourself is useful. As difficult as it may be to bring up a delay like this with a client, it is easier than trying miraculously do work in half the time. Even if you end up eating the time, your client and team may well respect you for being realistic about it.
Web site don'ts: Labeling everything in dingbats!
Web production don’ts: Labeling everything in dingbats on your sitemap!

• Love your content: Finally, it’s my experience that if you like the content and do right by it, many workflow problems either don’t occur or are easier to solve. Even neutral professional content that isn’t your particular specialty can be rewarding to work on, and if everybody believes it is valuable to get it out to the people who need it, that gives you some basis for working together and solving problems when they come up.  On the other hand, content that hasn’t been worked out pushes back, and chokes workflows.

Words of Advice: The Tragedy of Theme Addiction

WordPress, despite my carping about it, is a wonderful platform. It pulls together underlying technologies, provides workflows, and establishes standards & conventions that bridge the gap between flexibility and ease of use fairly well, with the result that a wide range of people can use it successfully (not just coders, or designers, but even writers).

But of course, it has a dark side, a scourge that you rarely hear mentioned: I’m talking about “theme addiction” something that even the Jesus-like Matt Mullenweg himself cannot offer salvation from.

Matt Mullenweg, the fount of all things WordPress. (
Matt Mullenweg, the fount of all things WordPress. (“Matt Mullenweg 01” by Ronny Siegel – Own work. Licensed under CC BY 3.0 via Wikimedia Commons.)

What’s a theme anyway? WordPress, like most modern software, separates the guts (for instance, the database engine that manages all the content) from presentation to the user, that is, the visual design. If you have ever customized your browser to have a sports logo, or a kitten, or like mine with the Royal Opera House you’ve used a theme. They show up in operating systems, programs, and mobile devices just to name a few, and they are an integral part of WordPress.

WordPress themes control the visual appearance of your site, layout, color, type, etc., and also have big implications for the functionality–themes work with (or don’t) key features (e.g, responsive design, sidebars, animated backgrounds, featured images, whatever). All that is to the good, and themes are even fairly easy to build from scratch, also on the whole a good thing.

But here comes the problem: there are now many thousands of these buggers. There is a whole “theme ecosystem” with themes for every purpose under http (although rule 34 of the Internet does not seem to yet apply, there is no porn about WordPress themes, at least not yet). WordPress.com offers 359 just for their hosted service. Themeforest (which admittedly handles more than just WP themes) boasts over 19,000; put “unique” in as a search term for WordPress themes and you get a cool 978. WooThemes, now part of the WordPress mother ship Automattic, has 50 odd, and Elegant Themes, of which I’m particularly fond has more than a dozen. And this is just the beginning.

This slideshow requires JavaScript.

If you are not surfeited with this, you can always build your own theme based on one of the many, many frameworks. It’s not hard if you know a little CSS, and even if you don’t the world is full of themes and variations (technically called “child themes”) to explore.

It’s the web in classic form: solutions in search of a problem. Faced with the simple task of starting a blog, it is easy, nay almost inevitable, to get sucked into theme shopping and never return. (If this is combined with Battlestar Galactica addiction, the results could be dire).

Now, the sane thing to do with this paradox of choice, is to follow the advice on the WordPress codex: if you are thinking about starting a blog, start with your content goals, think about your audience, pull together some sample content (photos, posts, whatever), work through that, spending the majority of your time planning and doing content (be that writing, taking pictures, doing your podcasts, whatever.)

The graph should look something like this.

Content V. Theme
Good! More time planning than theme shopping.

But instead, this happens: you say to yourself, “I’m going to do a travel blog, yeeessss!” which pretty much counts as your entire planning phase and you immediately plunge into a whirlwind of theme shopping. You find the “Adventure ” theme, the “El Greco” theme, there’s “Magellan,” and “Voyage,” and, as Mrs. Lovett says, “I’ve only just begun…”

And your graph suddenly looks like this.

You have been sucked into the theme shopping vortex, beware.
You have been sucked into the theme shopping vortex, beware.

Once you have been sucked in there is very little escape, for you see even after you have “chosen” a theme (or themes, you can download as many as you like and test them out), then a whole new hall of mirrors opens up and you can start dicking around, oops I mean “configuring” your themes because almost any theme comes with seemingly endless bobs and bits that you can customize. If that’s not enough to feed the craving–born of the delusion that you are actually doing productive work–you can probably often mess around with the CSS too, download some fonts, work out a background image…

This, like infinite scroll, can go on and on, and at the end of it, you are naturally too exhausted to write, photograph, or record a podcast, so you step gingerly away, and “Hello, World!” is all your blog has, and may have, for days.

Reader, I have been there. I have a ‘sandbox’ WordPress installation on my laptop using MAMP, which I tell myself is just my little safe test bed for screwing around with all things WordPress, but in truth, it’s my little “theme meth lab” where I can download theme after theme, those I buy, the freebies, frameworks for child themes, tools for building your own, and tinker away and away and away. (I do this for my blog, even though I’m hosted on WordPress.com, which gives you perfectly good themes, many for FREE, and in any case limits you to those that are safe and compatible with the current release.)

And safe too…this is another little dark chapter of theme addiction. There are some themes that are easy to hack, (and it’s wise to consider any site on the web fodder for pretty much constant automated attack). There are also some that come pre-loaded with malicious code, programmed to use your site as a zombie, harvest user info, or worse. So this adds a soupçon of spy thriller to the hunt, what lurks behind that glamorous and oh-so-responsive slider? Could it be a dark past and back end that will send your users’ data to Minsk or a dank basement in Cleveland?

The mind, or at least, my mind, reels. In truth, you shouldn’t get any free theme from a sketchy site, or one without a user community and support. If you don’t understand how to use the theme checker, you shouldn’t fool with any but the built in themes or those on WP.com to start with.

So that’s a taste of theme addiction. If you’ve been involved in WP and avoided it, congratulations! We won’t be looking for you at the next Theme-aholics Anonymous WordPress Meet-Up. But if you have fallen prey to this timewaster, here is advice courtesy of a graphic designer I know. Now in his 80s, Mo Obermann taught and practiced graphic design in NYC for many years, running his own firm in the Mad Men era. One summer, I helped the now self-styled “artist in reticence”  get Photoshop on his computer, and when we looked at the long list of typefaces available he asked me how many fonts I thought he used in his 40 plus year career. Before I could answer, he shouted, “Four!” “Pick a type face, learn it, and do your work with it.”

So follow Mo’s advice, slightly updated for the WordPress world: do your content plan first. (Really, don’t do anything until you have your plan down in some kind of form that makes sense to you–the codex recommends ink and paper, something I endorse. At a minimum write out what your editorial goal is and who your audience is.) Then make a list of characteristics and requirements for the way you want your site to appear and what you need it to do. (For example, clean type design, light color-neutral background, display photos and texts, work on mobile etc.)

Now take a deep breath, and search on one source (WordPress.com is my recommendation, even if you are self-hosting, you can generally still get those themes, and you know Automattic has blessed them so the hacker in Cleveland is out of luck), and pick three. (Okay okay, if you really can’t help yourself, go for four.)

With your three (or four) give yourself a day or two total to audition all of these, working with your sample content. Then commit to one and implement it by the end of that week. Make a deal with yourself that it will be on your site for at least 30 days. Sign “the pledge” that you will not have “a drink from the theme shopping bar” during that period.

(It’s also really good to commit to posting something every day for the first thirty days. I’m a little erratic now, but the fact that I’m able to keep up my blog at all is due in no small part to making sure I posted regularly in the first few months).

Then, if you get to the end of the month, and you are thinking, “jeez-o-flip, I really wish I had a better theme,” then write down what “better” means in practical terms, and, with this in hand, go search for no more than three more candidates. Audition, then implement within the week, just as before.

Whatever happens, do as I say, not as I do: don’t spend time theme shopping that you could be writing, photographing, producing video, or whatever it is that floats your blogging boat. WordPress is a content management and publishing tool, give it some content to manage and publish! Don’t give in to that siren song of … wait, just a sec, I just got an email about a new theme called Cyanotype…gotta check it out, it’s got this ‘old photo’ vibe going, and I love that….

Web Production Tips

A forum I am on for Web Producers asked for tips on Web site management. I, being the prolix sort I am, generated more than LinkedIn could take, so here is the full list, of interest only to people who create or look after web sites, but offered to them for what it’s worth. Slightly updated, 2/20/2018.

Random Website Production Tips courtesy of Arthur Smith

  • Sign your work: I’ve found it useful to make sure people put their names (or at least initials) on all concept stage and later docs (specs, treatments, mission statements, wireframes, page designs, whatever). I used to only ask for dates, but “signing your work” may actually improve quality and it is also a godsend later when you are trying to track something down from an archive.
  • Number wireframes: Decimal numbering navigation trees on wireframes/screen comps has been helpful. (That is, assigning a number to each path (Home page =1, a sub-page like “about us” = 1.1 etc.) although as complicated hierarchies become less prevalent on sites, may not be as important.
  • Responsive from the get go: Checking responsive view compatibility really early and being psychologically prepared to clip the wings of a really nice design solution and content strategy if it’s not feasible.
  • Workflow realism: Be prepared for clients’ (or partners) non-use of proposed workflow tools for content, delivery and review etc. To paraphrase Dorothy Parker, you can lead a client to BaseCamp, Google Drive, DropBox, SharePoint or whatever, but you can’t make them click. Most people are reluctant to add another tool to their work ecosystem, and a vendor seldom has the leverage to persuade them to do so. I ask how clients already work with copy, visual assets, and do review for existing projects, and then work out an approach based on that that’s bearable for the web team. It is often email attachments, the bane of any web producer, but then I put them in the tool I need and name them using the production convention. I work on small sites, and I realize something this ad hoc may not scale.
  • Milestones: Rally around a fixed external event to shape client schedules and expectations (even if it’s a sort of made up event). It’s best if there is a plausible date to tie production milestones to, but even if not, designate one based on something on the calendar. For instance, end of a semester for an academic client, annual meeting for a non-profit, etc. Some public version of a deliverable should be tied to this., “e.g., we will focus group the alpha at the next regional meeting.” What’s key is that be such a date be front of mind for client and feasible for you. End of contract dates don’t necessarily work this way. For one thing, they can be amended, but dates of public meetings cannot. If you have to keep looking up a date to see when something major is due, it’s a bad sign.
  • Presentation tools for sketches: Consider Keynote, (or if you must, PowerPoint ) for concept and design stage work. If your designers are comfortable with it and particularly if you are working from a family of templates, have designers create plausible Keynote “page shells” that then can be updated by producers and writers to iterate content strategy. This is sort of a hack, and it’s not what Keynote is for, per se, but it is much more convenient (and less costly) that working on content revisions in a designer/Photoshop workflow. For one thing, text in Keynote is much easier to move around and chunk, and the graphics tools are sufficient at least to wireframe, or even do simple page design. Photoshop (or other image tools, are not text friendly). Don’t leave the designer and developer out of this phase, though. It’s possible to create something in Keynote that is insane to execute. Periodic check ins on feasibility and implications are good, as is working from a shell that both the designer and developer have seen and ok’d, or better participated in.
  • Start early on copy and other content: Also, if you are careful, you can get a jump on cleaning up the copy, and sort out images, rights etc., in this Keynote stage, not just resolve the content strategy problems. Interestingly enough, now that I work mostly in WordPress, I still find that this Keynote workflow helps. WordPress sort of tempts you to think you can do iterative content development if you have chosen the right theme etc. This hasn’t worked for me: it’s a publishing content management approach (presentation and content wrangling) it’s not a content creation tool, at least for anything editorially intensive. I think there still really isn’t a good content creation tool—a sort of github for editorial would be part of it, but some 10 year old is probably creating one. I know people have had success with iA Writer, and Medium is making a big splash, although I’m not sure that it is designed to work inside other workflows.
  • Map editorial workflows: figure out in advance how copy (and other assets) are getting from the client or the writer to the site, and how revisions, proofreading/copyediting and publishing will be done. Note who’s job it is, and do a ‘pre-flight’ to make sure this approach will work. Particularly important for big sites or conversion jobs.
  • Restrain your theme addiction: If you are in a WordPress world, or other theme-based platform, don’t move to the theme choice stage until content strategy is established. (This is really hard for me, and others I’m betting. There are so many themes, and it’s fun to think in a preliminary way about your project and then go “theme shopping”.) The danger is you start thinking about the project in terms of what the theme will do, rather than what the project goals are. (It’s a version of having all those typefaces available in a design program: sort of irresistible to try them out early on.) It’s also a waste of time learning a theme and its quirks, only to find out you won’t use it later. (Although this only happens once in my experience!) If you are building a theme from scratch, or redoing most or all of the CSS, then this would not necessarily apply. Still good to have a clear idea of what success looks like for your content first.
  • Stay in touch: Do a weekly report email to clients, include milestones from your project spreadsheet or PM tool, and color code tasks: on time (green), behind, (red) ahead (blue), not started (black), so it can be glanced at (but not edited).
  • Keep track: Document as you go. (Like flossing easy to say, hard to do).
  • If timelines change, be realistic: If some stage takes a lot more time than it was scheduled and budgeted for, the natural tendency is to believe the “Just So story” that you will “catch up” later. If the first stage took twice as long, it’s likely that the other stages will take twice as long. Make an alternate Plan-B version of the schedule that uses this delay as a factor for all remaining stages. For example, if it took the client 10 weeks instead of 5 to provide copy and signoff on concept spec, multiply all remaining stages (page designs, alpha, testing, whatever) by 2 and see where that gets you. Figure out how you could manage such a schedule, and find a professional and respectful way to address this with your client. This isn’t very comfortable, but even if you are just thinking through it yourself is useful. As difficult as it may be to bring up a delay like this with a client, it is easier than trying miraculously do work in half the time. Even if you end up eating the time, your client and team may well respect you for being realistic about it.
Web site don'ts: Labeling everything in dingbats!
Web production don’ts: Labeling everything in dingbats on your sitemap!

• Love your content: Finally, it’s my experience that if you like the content and do right by it, many workflow problems either don’t occur or are easier to solve. Even neutral professional content that isn’t your particular specialty can be rewarding to work on, and if everybody believes it is valuable to get it out to the people who need it, that gives you some basis for working together and solving problems when they come up.  On the other hand, content that hasn’t been worked out pushes back, and chokes workflows.

A Writer at WordCamp Baltimore

This blog and thousands of others (or more) uses WordPress, picked mostly because I knew it a bit from a blog (and hosting company) I like, Laughing Squid, which used it. It is open source, and had that “do it yourself” feel of the early web (pitching their “5 second install”), and I was able to put up a little site for an inn keeper friend of mine in about a weekend a few years back. (I later moved it to wordpress.com and it’s still up, if looking its age a bit.)

In the intervening years, WordPress has grown up into more than a blogging tool, providing a platform for a lot of web publishing and building a large developer (and designer and user) community. It has become an ecosystem, perhaps not to the level of Linux (the open source operating system that is used on many web servers), but it is now providing platform infrastructure for between 18 and 20% of the Web.

That is among the tidbits I gleaned at WordCamp Baltimore, a meeting for WordPress types last weekend at the University of Baltimore. For $20 and a train ride up and back it was worth it to see both who attended and the texture of the presentations. It was, in the way of many a tech conference, pleasantly shaggy when it came to organization. No sign on the conference building itself, and confusing ones inside, which meant I ended up in sessions I didn’t intend to attend. But a certain amount of conference chaos means both serendipity and that you have to talk to people to find out where things are, not a bad thing.

Some random notes from the sessions I attended: Russell Heimlich from Pew talked about caching. (Would that I had enough readers to worry about caching or even moving off wordpress.com), but did speak to WordPress’ ability to scale for big sites.

A lawyer turned WordPress entrepreneur Byron Warnken, who has done several successful digital projects relating to law, did a session on content marketing. This was, understandably, focused on commercial uses of WP, but had some intriguing tidbits even for somebody like me who has made his career mostly in not-for-profits. First, “content marketing” pre-dates the web. Byron’s example was “The Furrow,” a magazine from the John Deere tractor company, which gives “relevant content to customers” –that is, content marketing. Wikipedia dates its founding to 1895 and notes a million plus subscribers. Wikipedia lists the Michelin Guide as another preweb example of content marketing, & I assume that beloved book of my youth, The Guinness Book of World Records, would qualify as well.

This was eye-opening for me as previously I saw the whole content marketing idea as separate from “real content” — that is, not influenced mostly by the desire to sell you something, therefore not objective. That still seems broadly true, but it gets usefully blurry around the edges, at least got me to wonder about what content the various companies and non-profits I am involved with can offer as legitimately helpful and engaging (versus what is to sell, I suppose). Byron was engaging and provocative, a very good presenter.

(One provocative (if flaky) observation to fall out of this: what are MOOCs if not Content Marketing on a massive scale? If that logic is correct, when do John Deere, Guide Michelin, and Guinness start their first MOOC? I bet their production values and UX will be an improvement on what is out there from the mighty Coursera and edX. If the Guinness people need an instructional designer for a MOOC-based drinking game, I am at the ready!)

Also worth noting:
Really good session on SEO (that’s search engine optimization, for the two of you who get my blog via parchment scroll in Latin) by principals at WebMechanix, a Columbia, Maryland, company that does optimization for your site (good content marketing gizmo on their home page, as an aside). A lot of familiar stuff (which is like being reminded by the dentist to floss):

  • Meaningful page titles, correct use of title tags.
  • Metadescriptions
  • Meaningful file names for images, alt-tags, good captions
  • Page headings (and logic of the page) even more important than it used to be.

Other: “thou shalls” from them:

  • Overall: Think about your page from a “how easy it is to index this?” perspective. That is, produce sites from an “easy to index” mindset.
  • Religiously share your content on social networks.
  • Think about off and on page SEO (corollary to the one above)
  • Benchmark
  • Use plug-ins for SEO
  • Use the Google site map generator thingie and make xml site maps and give them to the Google beast for ingest.

New to me (although it’s not that I really do any of those ordinary things very diligently) was thinking about various implications of schemas in search (schemas are tagging schemes, sort of like cataloging that makes content more recognizable to search algorithms (and by implication to APIs or for other uses). It reminds me of headings in library catalogs (except that schema go beyond subject to include type etc).

Schema.org has an explanation and a bunch of already existing schema (one is for instance ratings stars). Google has an “author snippet” akin to a schema, which hooks a comment to a profile, and is important in search. Somebody is probably working out schema for education topics and formats now (or if they aren’t they should be). But more on that later.

The notion that giving search engines more about the semantic structure and content of your pages helps in SEO is really thought provoking–in both directions. You start thinking about this structure as a writer and Google as a reader. The guys who were presenting seemed so positive about this–and were also great presenters–that it was easy to forget it’s slightly freaky to think about Google as your number 1 reader, now telling you how to organize your writing.

Arthur’s WordCamp t-shirt selfie.

Given that I (and probably a lot of others) think about SEO as a question of how do I get a site to show up on the first page of Google and then get people there, this idea of Google as a reader, and everything you write as content, eye-opening. Starts with using snippets and schema, and soon morphs to considering your (or your company’s) digital presence as not just your web site or app, but all these bits and piece

s of content out in the web eco-system. It makes me want to have a lie-down and listen to some very calm Palestrina, who, as yet, has not been the subject of a WordCamp session, (although if I ever present at one, I’ll be sure to work him in.)

So overall my first WP was a great experience, and if you are at all in this WordPress cult, check out one in your area, or watch them on WordCamp.TV, which gives you a feel for what they are about. I enjoyed the WordPress for writers out of the Providence WC by Jess Jurick and there are lots more.