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.

Criticizing MOOCs: the Cartoon

MOOCs, like many educational innovations that have come before them, are a flashpoint for certain kinds of rather tired arguments about the supposed eternal verities about what schooling should be. It’s a feeble flap, particularly since we are in not just early days but minute 1 or 2 of the whole change that online education will foment. The anti-MOOC case is also full of the weird mash up of empirical and conceptual carping that fights over education seem prone to. Two of the strands:

1. The philosophical opposition seems to go something like: MOOCs do not provide sufficient texture of experience to count as education, and are, further, an effort to outsource teaching via a technological approach, something which, for ineffable reasons, has to be, or is at least optimally, delivered in person as part of a (preferably, super-exclusionary) community.

2. The empirical complaint seems to be: look, they don’t work anyway, as most people don’t “complete” them, so therefore they can’t have any merit.

Both of these I think are refutable on their own, but they are basically self-refuting when mashed together. Good things those completion rates are low, even though that is arguably a meaningless metric, because, we shouldn’t be doing these things anyway.

I’m sanguine to optimistic about MOOCs and what they may lead to, and certainly feel deserve their chance to weave their thread in the Internet tapestry. My guess is that some of the growing pains result not from any problem in online delivery per se, but the sort of sad effort to replicate the format of a “course,” and the attendant forced march through the curriculum. (Curricula, whatever else they do, instantiate ideology and culture, something I’ll blather on about another time.)

Diderot's Encyclopedia: The MOOC of its day?
Diderot’s Encyclopedia: The MOOC of its day?
Getting a topic into some 13-week chunk for in-person delivery including the duly required mid-term, final, and term paper, is already artificial: an historical reenactment of an approach that was creaky 100 years ago. Preserving it online has never made any sense to me, except for laziness and resistance to change that academic institutions, and truthfully teachers, often fall into.

The other thing I think is not just promising about MOOCs, but here now and heartening, is how much humanities content they offer. In a time when there’s much stewing about the ailing state of the arts & humanities, there are crowds joining MOOCs on humanities topics and participating with enthusiasm. (Once upon a time you could get this subject on public broadcasting, even sometimes on commercial TV, but priorities have shifted.) Two, of many, examples: a course on the Beethoven Piano Sonatas with Jonathan Biss, and on Modern and Contemporary American Poetry, which is the closest I’ve found to busting open the idea of a course, it is really more of a community event, and the better for it.

Still, to give the opposition their say, here’s a delightful animation taking up the contra side (including an argument that it’s all about money that I’ll hang fire on until another day). Daphne, Sebastian, and Anant make such adorable video game characters, I think they should consider that as an add on career.

Around the Web: Computeriana

A few things I’ve come across browsing recently for the (sometimes silly) computers & culture file.

1. Correlation is not causation: the picture book. As the saying goes, “torture the data and it will say anything,” apparently even that previously unknown lurking variable linking Nicholas Cage films and swimming pool deaths, or crude oil and chicken consumption.

Correlation is not CausationCheck out Tyler Vigen’s delightful “Spurious Correlations” site for many more and for his engaging video that will teach you something too.

 

2. Forget a dogged ability to search out “Who? What? When? Where? Why? and How? today’s reporters need to know the statistical language “R” and turn in their (now very figurative) Underwoods for a Computational Journalism Server, whatever that is. Kidding aside, given that data is oil of the 21st century, it makes sense that people should figure out how it is made, and how to use the tools it offers.

His_Girl_Friday
Rosalind Russell working on determining the “P Value” for a murder story she is writing in Howard Hawkes’ great newspaper comedy, “His Girl Friday.” (Itself a version of that classic newspaper play, “The Front Page.” )

Still, a dual Master of Science in M.S. in Computer Science and Journalism? A strange mash up, dare I say a forced correlation with no causal link? I’m a nerdy data guy, and I could, under duress, possibly become a (crappy) R programmer. I also wrote for newspapers for years, and grew up with a couple being published from my home. They really seem like very different mindsets. Yes, journalists need data scientists, but I’m not buying for a second that data scientists are journalists per se, any more than they are educators. They have an amazing tool set, but it’s not the whole game.

3. John Cage: The App Some enterprising soul has created 4′ 33″ for iOS. (I was tipped to this by an interesting web magazine on classical music, art and technology.) It is not, despite what you may think, a joke (neither was the original). I haven’t downloaded it yet, but it seems very true to part of Cage’s program (if I can be forgive that mundane word) of reorganizing how we think about sound and silence.

4_33

Nostalgic Words: BASIC

The programming language BASIC celebrates its 50th birthday this year, and Time has a nice piece about it by Harry McCracken.

I find the “everybody should learn to code” movement laudable. And yet it also leaves me wistful, even melancholy. Once upon a time, knowing how to use a computer was virtually synonymous with knowing how to program one. And the thing that made it possible was a programming language called BASIC.

Although the “everybody needs to code” trope seems a little debatable to me, I’m with him on the wistful melancholy. BASIC was the first computer language I ever encountered. I was in 6th grade and my science teacher gave me the manual, which I played with. Using the real computer required getting access to a time-share machine, waiting to use a few moments of a massive device that is less powerful than my iPod watch. All my later computer camps and courses through high school taught BASIC, but when I got to college the computer science teachers scoffed at BASIC, as a poor tool. Maybe true, but it lives on.

teletype
That’s paper tape at left. You put your program on it (or on punch cards, remember those?) took them to the technician and prayed to God that the damn thing would compile.

Disruptive Words: David Carr on the Aereo Case

Times media reporter David Carr has a great piece on the Aereo case

Color TV CardOne excerpt:

Aereo may be small — Mr. Diller called it “a pimple” — but it represents something mighty important. If Aereo is allowed to store and transmit signals without payment, the television industry will be profoundly reconfigured.

And this reconfiguration can’t come a second too soon. Telecom law is insanely complicated I’m sure, and probably ad hoc as all get out, but how the court could find that a scheme that lets you use a public good (the airwaves, granted via licenses by the government) is infringement, and also that retransmission fees and other behaviors of cable and network are in the consumers’ interest, is beyond me. It’s also an interesting case to see how a court that is sometimes seen to be pro-big business, will deal with a mouse (or as Barry Diller would say ‘a pimple’) that roars.

I agree with Carr, although Aereo may not be the case that rejiggers the industry, it’s at a minimum the “save the date” postcard. Their days are numbered. Some of us are not unhappy about that.

Reasonable Words: Mobile Web or just plain “Internet”?

The Web is only 25 years old, and now we’re worried about writing its obit. Mobile device use for Internet access (of the kind we once could only do on desktops) is building. And a staggering 90% of adult Americans have a cell phone (although smart phone penetration isn’t at that level yet).  So is this a bad thing for the plain ole web? A recent commentator is seeing this as a zero sum, if mobile, in specific, apps, win, the web loses.

browser
Mosaic, we hardly knew ye. They might have avoided the “tombstone” design for this historical marker at UI, although I suppose it is apt.

Jon Gruber at Daring Fireball has (as usual) an interesting take. It is, after all, all the Internet, and an open-ish ecology where there are a lot of channels, and the tool matches the task is a positive one.

Here is the beginning of Gruber’s post (which quotes Chris Dixon).

Chris Dixon, in a piece titled “The Decline of the Mobile Web”, citing stats from ComScore and Flurry:

People are spending more time on mobile vs desktop. And more of their mobile time using apps, not the web.

This is a worrisome trend for the web. Mobile is the future. What wins mobile, wins the Internet. Right now, apps are winning and the web is losing.

I think Dixon has it all wrong. We shouldn’t think of the “web” as only what renders inside a web browser. The web is HTTP, and the open Internet. What exactly are people doing with these mobile apps? Largely, using the same services, which, on the desktop, they use in a web browser.