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:
Random Website Production Tips courtesy of Arthur Smith
- 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” can actually improve quality and it is also a godsend later when you are trying to track something down from an archive.
- 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.
- 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.
- 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 into their work ecosystem, and a vendor seldom has the leverage to make it happen. I try to ask how clients already provide copy, visual assets, and do review for existing project, and then work out a compromise 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.
- 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 usually cannot. If you have to keep looking up a date to see when something major is due, it’s a bad sign.
- 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, as 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 is 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 design or develop. 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.
- 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.
- For WordPress or other CMSs that offer a richtext editor with an HTML input option (most do), you have a little better control pasting in HTML and then apply more formatting if need be. (I happen to think a designer should give you a spec for how the typography should look, but that’s just me). I use a handy web tool that turns Markdown into legal HTML. Workflow is MS-Word (with some cleaning and then marking) cut and paste into the tool, and then you get flowable HTML text. Here’s the page: http://daringfireball.net/projects/markdown/dingus
And, of course, there are many more sophisticated ways to work with Markdown. This cut and paste does create some version control risk, so need to figure how to manage that (for instance, only letting one person be responsible for the initial text flow.)
- If you are in a WordPress world, don’t move to the theme choice stage. before 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.
- Do a weekly report email to clients with a PDF print of the 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).
- Document as you go. (Like flossing easy to say, hard to do).
- If some stage takes a lot more time than it was scheduled and budgeted for, after you have told yourself the “Just So story” that you will “catch up” later, make an alternate Plan-B version of the schedule that uses the delay as a factor for all remaining stages. That is, 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 if you have ice-water in your veins, (I don’t) 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, and still have to slog through the project, it is helpful to know for load balancing other projects, “worst case project A may go 2x over, that would mean that project B would move to this date.” It should also be done for problems that arise from other sources, within the team or you, or a new software release, etc. Hard though it is to face, events like this are much easier to at least note at the time they occur, than when you are deep in “overtime” trying to figure out what to do.