Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm Jen Simmons and this is episode 101.

I first want to say thank you so much to today's sponsor, Squarespace. I'll talk more about them later. And I want to say thank you to Pantheon for powering The Web Ahead website. And to CacheFly, our CDN who is delivering all of the audio files to you.

I thought we'd start today with a listener question. I don't think I've ever done that on the show. This is a good question. It came in this morning. I was like, "I want to answer this question on the show." Then we're going to talk about content. Content structure, content strategy. Because people have been asking. Someone tweeted at me and said, "More on content structure please." My guest today is Eileen Webb. Hi Eileen.

Eileen

Hello Jen. Thanks for having me.

Jen

Your job title on Twitter is Director of Strategy & Livestock. [Laughs]

Eileen

That is my official job title. Yes. I take it very seriously.

Jen

Yeah. I like that strategy in livestock. Which livestock are you director of?

Eileen

We live on a farm and we have a flock of chickens and ducks and one very loud goose. During the summertime, depending on the year, we'll have pigs or sheep or other kinds of animals.

Jen

Nice. A white goose? I guess you don't have a Canadian goose as a domestic animal.

Eileen

I do not have a Canadian goose. We have a Chinese Weeder. She's white and has a big yellow knob on her beak. She will let you know if the mailman comes at any time of day.

Jen

[Laughs] I like geese, even though they're kind of scary.

Eileen

A lot of people have horrific childhood geese stories, where they were chased and harassed and attacked by geese. But our goose, whose name is Spruce — Spruce Goose — is pretty chill. She's loud but she has never attacked anyone.

Jen

You founded and run Web Meadow. You do a lot of content strategy with clients. Do you do beginning-to-end websites with people? Or do you focus mostly on content?

Eileen

We used to. We used to be a full development shop. My background is as a backend programmer — a PHP-CMS-developer kind of person. Then we specialized. I liked doing the content, strategy, and planning parts so much. I never really loved debugging JavaScript, oddly. [Both laugh] I know, weird, right? In the last couple of years, we've specialized and specialized. Now I do solely content and architecture planning stuff. My partner Aaron does project strategy and project management and running teams and things like that.

Jen

Nice. I'm going to read this question.

Mitch wrote in and said, "Your 100th episode with Jeffrey Zeldman was the first episode I ever heard." Awesome, welcome to the show! "One thing Jeffrey said really rung true with me, with how difficult it is to get new people into web development. I recently started working on a personal site in WordPress and decided that if I really wanted to get serious about it, I should learn coding. I got some lessons from Umedy, picked up some books, and found learning HTML and CSS was pretty straightforward. But from there it boggles my mind as to what to do next. Obviously, I should learn JavaScript and PHP. But beyond that, there are so many questions. Do I use a framework? If so, which one? Do I build a website from scratch or build it on top of a CMS? Which CMS? Python, Ruby, Perl. It can lead a person to a nervous breakdown. While it's awesome to have this wealth of information and resources, at the same time, I envy missing out on a time when I could have learned all of these various languages sequentially, as they came more into use. Anyway, I love the podcast."

I think this is probably a feeling that a lot of people have. There's so many different things happening right now. Especially if you're new, where do you even start? How to do you specialize in everything at the same time?

I thought I'd answer this. I'd love to have you, Eileen, jump in and answer this, too. As a person who's gone through a lot of this.

I was thinking about this before we started the show and I started writing stuff down. I'm like, "In '96, all you needed to know was HTML, FTP. You had to learn how to get a domain name — which was harder than it is now. You had to know how to hook up the domain name with DNS. Or at least get somebody else to do it. You had to know how to get a server space. If you knew those things, you were done. [Laughs] You were totally set. There was nothing else to know. Then CSS came along. Ok, learn CSS. Maybe some PHP. Use a content management system like WordPress or Drupal. I've got to learn how to set up a MySQL database, but I don't need to know SQL. I just need to know how to get the username and password for the database and give it to WordPress.

Many of us learned that level of complexity in the technical side. Mitch, it sounds like that's where you're at. You've learned that part.

Now, I think everybody should know Git and a little bit of the command line. Because those things will come in very handy. Especially if you want to just SSH into a remote server and pull a repo. There's a little bit of command line stuff to know. A lot of people use Git from the command line. But you can also use it from a Git GUI like GitTower. There's a couple of episodes about Git. You should look on the website, thewebahead.net, and find the shows about Git to hear hours and hours and hours about Git. [Episode 40: Git with John Albin Wilkins and Episode 79: Advanced Git with Tobias Günther.]

It seems like everybody should know a tiny bit of PHP. A tiny bit — if you're interested in being a developer. And a tiny bit of JavaScript. By tiny, I mean, enough so you can read it. You open a file, you look at it, and you go, "Yeah, I see that is written in some English words that I vaguely recognize. Here I am in WordPress, I'm trying to do something. Maybe if I cut this part and paste it over here, or if I take this and copy it, now there's two copies, and you just hit save and see if it works. No, that fails, don't do that. Yes, that does work, what did I do?" That level of messing around, you can alter WordPress templates. You can look up a JavaScript library someplace and paste it into your WordPress website. You can go to CodePen and look at other people's JavaScript. Copy and paste some things and alter them to make them your own. Or email your friend and say, "I need help with this thing. Can you write me a little bit of JavaScript?" Then you cut and paste their JavaScript. [That's the base minimum for everyone.]

[Mitch's] question really is, "Should I learn Ruby and Jekyll and Twig and Python?" Nobody does that. Well, maybe not nobody [but very few]. If you want to be a hardcore engineer, and you just want to code-code-code, probably you'll start with one of these languages. Get deep into it, then add a second language. Get deep into that. Add a third language. But many people, most people, don't ever get to all of them. People just end up becoming a Python person. You become a Ruby person, or you become a PHP person. Then you stick with that and perhaps only ever use that one language, or that lineage of languages.

I think the answer to, "Which one should I start with?" is follow what's fun for you. Follow what you're finding yourself being passionate about. If you do a little bit of CSS, JavaScript, PHP — on, say, WordPress templates — you might say, "Eh, the PHP is a little boring." But you love the CSS. Do that. Do more and more and more CSS. Or maybe you're like, "This CSS is really annoying. I like the PHP better because it makes more sense." Then do more PHP. "That must mean I like this kind of coding, so maybe I'll go from PHP to messing around with Jekyll and Ruby."

The other thing to follow is the money. [Laughs] Follow the money. Do real projects for real clients, for a real company, for a real employer. If you get a job doing a lot of WordPress, you're going to really know WordPress. I mean an employer job, where you're just building one WordPress site after another after another. You'll get really into it. Or maybe you just built the one site. Maybe you're still in school. Is there a club in school that needs a website? Maybe Squarespace is the best thing, so you totally get into Squarespace and you learn Squarespace really, really well.

I think for all of us, these things come and go. At best, an awesome tool lasts five or 10 years. Frequently, we're switching around five years. The process of learning is what you really need to know. How to look things up, how to search for things, how to notice what excites you and what you're good at and what you want to do more of. How to finagle your world, your life, and your job so you get to do more of what you want to do, and less of what you don't feel comfortable with or don't really like.

That's what I've done. I feel like that's what a lot of people do. You just find yourself doing one thing and less of another. After a while, you realize you don't even know that first thing anymore. It's not like you could learn it all and then know it all. You would learn it all and then you'd forget it all. [Laughs]

You're welcome to jump in here, Eileen. I don't know if you have any other, different advice.

Eileen

[00:11:21] Not different advice. I think that's great advice. I think a thing that is worth thinking about — especially if you're coming to the web world from the outside of the web world — is that was use this one single word, "developer," and it means a million different things. You can't be all of them.

I feel like the idea of being a full-stack developer is becoming more and more of a mythological creature. You can have a good surface-level knowledge of all of the pieces, from top to bottom. But would you want a house built by one person, or would you want a house where the plumbing was done by a person who only does plumbing? Electricity and wiring was done by an electrician, who's certified and an expert and continuing education, in their own particular niche.

There was a time — not that long ago — where it was completely reasonable to have one person. Remember web masters? There was a time when you could have a whole job that was just doing all of the parts of a website. I don't want to say that time has completely passed. But I don't think that is necessarily a good goal to go for. To try to know some of everything or all of everything. Like you were saying, you find some project. Because of that project, you end up needing to learn how to do CSS animations, because that's what will make this project work. Then you find out that you love them or you hate them. Either way, it narrows your path. You keep following a path based on the work that you want to do.

Jen

Yeah. CSS animations is a good example. You might do it for one project and you put so much time and effort into being able to complete that project. You do realize that you love it. Now you have a bunch of knowledge that not many people have. You go out and pursue more gigs to do that particular thing. You become one of the world's experts in CSS animations, perhaps. You write a blog. Or maybe you don't do all of that, but you're really enjoying it and really good at it and find more and more clients, or a job where that's what you're doing.

There are definitely people who can talk to a certain level of depth, knowing what they're talking about, about all of these things. That comes in time. Not that you could write code in Python, but you have a sense of, "Python is that language that tends to get taught a lot in computer science courses in school. The kinds of people who know it tend to be these kinds of people and they tend to use it for these kinds of applications." You have the flavor of the culture of Python, or you know how Python fits into the huge puzzle of the industry and why it gets chosen or when it gets used. But you're not going to write a program in Python.

That kind of knowledge can be really helpful if you're a CTO, or you're a C-level person, or you're making strategic decisions on a higher level. It can help to have a shallow understanding of a really big picture.

I feel like this myself. I think a lot of us feel like this. If I walk into a meeting and say, "Oh yeah, I totally know this, this, this, and this," [I fear that] the people in the meeting are going to be like, "Yeah, you're lying." [Laughs] "There's no way. What a lie."

There's no way you're a JavaScript and Ruby and Python developer. You're just not. There's no such thing.

Eileen

You could be a beginner in all of those things, but not the deep level, nerdy expert. When I was doing SQL stuff all the time, I would dream SQL queries. I would solve problems while I was sleeping. That doesn't happen anymore. That's totally fine with me. But you can't be that level while doing lots and lots of things at once. And also be a healthy, balanced person.

Jen

Yeah. Do you now claim to be a SQL expert? Or a person who knows SQL?

Eileen

No. Because of my old-timey expertise in SQL, I have the shallow stuff. I'm sure some of the SQL things that I used to do all the time, don't even exist anymore. Instead, I kept the bigger picture things. I know how relational databases are shaped. My brain works really well figuring out how things will go in tables and how relationships will happen between those pieces of data. But I couldn't write the queries anymore.

Jen

I'm sure that knowledge deeply affects how you approach content strategy.

Eileen

It totally does.

Jen

When you're thinking about structure of content, you're not just thinking about it from the perspective of the people who write the content. You're thinking about it from the perspective of the robots as well. What they're going to want out of the tables when they go to grab that content.

Eileen

Yeah. Those logical sequences. It feels like how when you get fluent in another language, you start to think in that language. If you're fluent in Russian or Spanish, it shapes your thoughts. It's not just a translation from English. It's a shaping of your thought formation. I feel like my thought formation around organization and content and things is flavored by my background in database knowledge.

Jen

Cool. Well, thanks Mitch for sending this. I hope that was helpful. I feel like, the answer is, "I don't have an answer." [Laughs]

Eileen

That's a good answer, too, though. I think it's nice to know that you can't be expected to do everything. And that's ok.

Jen

Yeah. I could see how someone who is new would feel like they're supposed to know it all. I really do. I feel like if I got a résumé on my desk that said, "I know all of these things," I'd be like, "You are totally a liar. There's no way." Shallow, but not to the depth that we're looking for right now.

If other people want to send in questions... if I get a lot of questions, maybe I'll even do a whole show of questions. That could be fun.

Let's talk content. Let's talk about content structure and strategy. We've talked about content strategy and content structure on other shows. In a way, I don't know where to start. We could start at the beginning, "What is content strategy?" Let me ask you this. How do you approach a project, when you're being brought in to fix the content?

Eileen

[Laughs] An important thing to know is that I don't do a lot of editorial work. A large percentage of content strategists are focused on the quality of the content. The piece of content strategy that is messaging, voice and tone, and the kinds of things that are like, what we're communicating the quality of the information that is being communicated. While I touch that a little bit, I specialize in structure and architecture. The deeper systems behind the creation of the content, as opposed to the actual words in it.

When I'm brought into projects, it is often because all of the content is stored in PDFs. [Jen laughs] You've never encountered that, right? It never happens.

Jen

Not the whole site. But great parts of it.

Eileen

Large chunks of it, yeah. Often all of the substantive content that people actually want to be sharing, that represents an organization's long-term value, is locked away in these PDFs. Especially old PDFs that aren't indexable, you can't copy and paste text from them. The old ones that were desktop publishing. Those kinds of PDFs.

When I'm brought into projects, we're often starting from a place like that. Not necessarily PDFs. Sometimes it's all plain old HTML pages. Or even in a CMS, but the content is all stored in a single body field. The giant, all-encompassing morass of a body field.

A lot of what I do is absorbing all of the different kinds of content that are used on the site and teasing out the patterns and the repeated pieces. Figuring out how we can break things down and structure them. Both for reuse — across channels, like if you want to have different mobile and desktop experiences. Also straightforward... sometimes people include teasers, sometimes they don't include teasers. Sometimes people forget to put the location of where the event is happening in the event listing.

A lot of content structure, from my point of view, is not even about the reuse and beautiful database relationships that happen behind it. It's about having really consistent content on the front end. It's not useful to have an event calendar if people can't find the events. Therefore, an event location should be a required field.

Jen

Right.

Eileen

That's a tiny, simple example. Expand that out to lots of different content types, and lots of different fields. Breaking them out into individual fields is one of the best ways to be able to direct lots of different authors — or even a single person over time — to create consistent content. To have a good experience. To make sure the cool things you build on the site work with all of the content. Not just with some of the content that someone bothered to pay attention to.

Jen

I'm thinking back to when websites were just HTML documents. You would make an HTML file, and you would paste in a bunch of HTML, or duplicate another file and start from a quasi-template. Then you would put the content right there, in the HTML file. It's like writing something in Microsoft Word. It's just a big blob of stuff.

We went from that era — where every page was like that — to an era where we were using tools like WordPress or other systems. You would click some buttons and sign in. You'd say, "Make a new thing." Whatever that is. New page, new blog post, new whatever. There would be the title field and a big, empty container. In a way, that empty container was almost the same thing as that HTML file. Except the HTML file had the header and footer and sidebar and navigation and everything in that HTML file.

It was a huge improvement, because the navigation was always the same. The navigation only existed in one place. If you needed to change or add a link, you could change it in one place. It would immediately exist everywhere. If you had a 500 page website, you could change it once, and it would just be changed. In the old days, you had to literally open 500 files and change it in 500 places. [Laughs]

Eileen

[00:24:15] It's funny. I feel like doing includes was one of the first innovations. Includes of little HTML pages and snippets. We did that with code right away. It was so useful to have a single location, canonical header. You change the image or logo or navigation in one place and it propagates everywhere. Yay!

We did that a long time ago, even pre-CMS or actual programming languages. We started doing includes. But we never quite got there with content. I feel like, just now, we're starting to get to the point where we're like, "Maybe there should be a canonical event listing for this event. If I want to pull the title of it, I can pull the title, rather than typing the title in 11 different pages across the site."

Jen

Yeah. Especially with some of these systems, there would be a field where you typed in the title, and the system with automatically capture who authored that content and when they authored that content. You'd have a date and an author field. And you'd have what Karen McGrane calls a big blob. It would just be everything else. An event is a perfect example. When you get this job at this college and you are in the department that adds events to the website, you go to training. In training, they teach you: You always need to write the date of the event first, and wrap that in an <h3>. Then type the location. Then type the address. It's painful and error-prone, like an oral tradition of how we're going to type content into our website. [Laughs]

You're expecting these employees to always do it the same way in this big blob. I can hear it in my voice, I'm being very judgmental, and I shouldn't be. Because I've built websites like this. I've trained my clients to do exactly this. Let me give you some HTML. Keep it in this file. When you're ready to make a post on this website that we built in WordPress, get this HTML, paste it here, and make sure you don't mess it up. If you accidentally erase the closing </div> at the end of this post, you'll break the entire layout for the page. [Laughs] It's just so fragile.

A) It's easily broken. B) You were alluding to this, but I'm just breaking it out and making it really obvious for anybody who might not understand or hasn't thought about this yet… You don't want the date to be the third line down, according to the oral tradition. And the location to be the fourth line down. Sometimes people include the address, sometimes they only put the name of the building. Sometimes they misspell the address. You want the date to be in a date field and you want the address to be in an address field. Two things happen. One is, the computer says, "There's no such thing as Grovember. It's either November or October. Please spell this properly." [The other is that the system can then do things like say] "Oh, look, we're in a different country. We want to format the date in a different order. Here we put the day before the month. Over there we put the month before the day." Well, guess what? Robots are smart enough to handle that for us. We'll just tell it the canonical date and we can have all sorts of flexibility around how that date is displayed. Here you want it to be the time, here you just want the day, here you want the list of everything from October. Here you want a list of everything from 2012." If it's a date field, then the robots become very smart because they know how to handle the date. Same with location, with maps and all of this stuff. You want to be able to require things. This one is required. You can't even make this content until you include this information.

Eileen

I feel like responsive has made this even more helpful. There are even more places where a developer will say, like what you were just saying with the copying and pasting of things. If you leave out this <div>, everything will break. The whole page will fail. When you're doing responsive stuff, even relatively simple things, where you want to float the image on the left when you're on a big screen, but you want to center it when you're on smaller screens. If you're relying on someone to remember to put a class in the <img> tag, even the simplest responsive layout rearrangements around breakpoints. They have to remember. You need to know what a class is, so you understand which one you're putting in. You have to remember to put the right kind of quotes around it. You're asking them to write HTML. That's fine if they want to, and it might be fine if it's your own site. But if that's not their job... and a university is a great example. If they are the assistant to the psychology department, they have a whole full-time job that does not involve learning and writing HTML for your website layout needs.

Give them the ability to put the information in, and then the smart robot in the website will spit that out in the right format, and include the classes and divide it up into <span>s and <div>s so you can rearrange around breakpoints. You have to have the consistency in code before you can do anything fancy and responsive.

Jen

A lot of sites are amazing, and they have a lot of great tools and well-planned things going on. When a site doesn't break the content into a bunch of fields like this, it doesn't have the ability to create alternative displays of that content.

You see these big media sites. You see on the homepage of the New York Times, at the top of the page you've got articles that are being highlighted. There's an image, a headline, and there's a long sentence. You scroll down the homepage and there are articles that aren't being promoted as highly. They've got a shorter headline and a shorter teaser sentence and no image. You scroll farther down and there's just a headline, no teaser at all. A really well-designed system will let you ingest a bunch of different options. Here's an image that will be used when a teaser image is used, if a teaser image is ever used for this kind of content. Here's a long version of the headline. Here's a short version of the headline. Here's a long teaser. Here's a short teaser. Here's all of the information that goes on the page for the article. The article itself is going to be displayed. It will only have one headline displayed in that view; you're not going to have two headlines there. You don't need the teasers on the main page, because they're already arrived at the main page. You have the article and sidebar and images that go with that article. That content can be highly structured, as well.

That gives you so much flexibility. You could have a page, deep in the archives, that's like, "Show me a list of all of the article titles from this month." Everything's been tagged. I want to see everything that's Fashion. If you don't have the content structured in a way like what described, then I don't know how you would possibly build a website where you could have displays like that. Or that kind of flexibility in creating displays.

Eileen

[00:32:26] You can also do really cool things around dates and times. Especially if you've got calendars. You can have things highlighted and automatically moved to the archives once the date has passed. I've been to a couple of conferences where the conference schedule updates and grays things out as the day goes on. When it's 2PM, all of the things from the morning are grayed out a little bit. Because that's not what you're paying attention to. You're trying to figure out what the next talk is. All of that stuff is only possible because the date and time are pulled out in a way that you can manipulate them with code.

Jen

Right. There's not someone logging in at 1PM and going, "Let me gray out all of the 11AM stuff. It's 2PM, let me log in and gray out all of the 1PM stuff. Oh, I forgot to do it!" You could do that, but that would be crazy. If you just put the time as a real number, the robots can do that.

Eileen

It's an interesting thing. I feel like in the last couple of years, there was a see-saw regarding the pros of having to build a system that could do that. You get to be able to do cool stuff, but it takes more work to build it. Versus your people needing to log in on a weekly basis to move the old things into the archives.

We've tipped. Especially with CMS'. But even with super lightweight CMS', like flat file CMS'. It's not any more work to build the smart systems that do those cool things. It's always been easier for authors and people who are admins and creating the actual content on the backend. It's always been easier for them to not have to log in and move stuff manually.

If you know from the beginning that you know you're going to be doing this, it's not any more work to build it this way. But you get all of the cool benefits of building it like this. Having fanciness.

Jen

It's true. We've both worked with Drupal. I know, for me, that's shaped deeply my thinking around this stuff. Because it's so easy to do this in Drupal. You just clickity-click and, "Look, I have another field! What kind of field do I want? Do I want a text, date, location, image, or file field?" There are flavors of fields. You can change the name, you can change the help text, you can rearrange the order, you can rearrange the order of the display. You can add filters and all sorts of fancy, complicated filers to make decisions about which content to display.

I find that fabulous. That's sometimes the most exciting things about a website, to me. Even though technically it's not very complicated in Drupal. It's where things can get really exciting.

When I've been doing complicated responsive layouts, and I want to do something innovative and dynamic, having all of the content on a page be in fields, instead of in one blob, means I can count on there being classes around particular things. I know exactly what the source order is going to be, every single time. You can write and design in CSS for a whole system around laying out all of those fields. Telling them where to be at certain breakpoints. Rather than only having a blob, and being like, "Well, where am I going to put the blob this time?"

I feel like I'm just talking, talking, talking, because this stuff excites me! [Laughs] But I want to know more about your perspective and how you do this.

Eileen

[00:36:33] One of the first pieces of any project for me, it's something like a content audit. Except when people talk about content audits, they're usually talking about judging the quality and measuring the quality of the content. I'm looking for patterns when I do a content audit. I sometimes call them structural audits, to distinguish between what I'm doing vs what someone would be doing if they're looking for whether or not there are too many words on this page.

A structural audit plays off my background and ability to find patterns. But that's also what humans are really good at. W're more likely to find a pattern that doesn't exist than to miss a pattern. Taking a whole bunch of content, lining it all up and reading it all. I don't mean reading-reading, but saying, "Here's a paragraph that's an introduction to this program. Here's the history of the program. Here's something about the founders." Chunking that all out and finding those relationships. It ends up looking like one of those post-it notes and red strings surrounding the room. [Jen laughs] Criss-crossing. A little bit of Beautiful Mind in there. Or sometimes I just do it on a piece of paper, which looks slightly less manic.

Jen

Can it be hard to figure out what a good structure is for a particular pile of content?

Eileen

Definitely. There's not a right answer. It's not a science. There are times when it would make sense to break some things down further, but business-wise, there aren't the resources to support the further breakdown. If information is being copy and pasted from another system, which happens a lot in larger enterprise things. The manufacturer sends us this spreadsheet and we're just copying stuff from the spreadsheet. It might be that the ideal setup would be a different organization than what the spreadsheet has. But it would be so much work to change it on an ongoing basis.

There's a lot of weighing of pros and cons. Sometimes you have two fields where you're like, "These two fields are functionally identical, but business-wise, they have two entirely different purposes." That happens less with fields, more often with content types. You might end up doing press releases and internal news. Internal news and external news have all of the same fields. Can't we just make one content type and have a toggle for internal or external news? That sounds awesome, but it only works if that lines up with what happens internally, governance-wise.

If the person who's building internal news on the site is in a completely different department, sits in a different area, and doesn't talk to the person who builds the external news, it might make way more sense to have those two things be separate. Even though, database and structure-wise, you'd be like, "This is awesome, we can use the same template for both of them." Business-decision-wise, there are reasons to keep them separate instead of unifying them.

When you're looking through a big pile of content, you can find lots of patterns and start seeing how the content types divide up. What fields are being reused and things like that. But there's a layer of checking with the real people who will actually be doing content maintenance moving forward. Saying, "Does this make sense to you?" It's not a good idea to hand down a content model without checking in with them. Saying, "This is how your content is structured." Because they'll come back to you, or they'll never come back you. It won't work for them. This doesn't line up with what they need to do with the content.

Jen

How much do you look to, "Email me your Excel spreadsheet. Give me a login to your old CMS. I want to look at the data, look at the content." How much do you rely on getting together and having a meeting and talking about who does what in the organization? Why do you hate your old CMS? What's the worst thing about it? Who's your boss? How do these teams collaborate or not collaborate together? How is the human structure set up? Which one do you start with usually?

Eileen

[00:41:09] It depends on the project. I usually start with some human stuff. Partly because it helps flavor the entire thing. If I ask a bunch of different people who touch content at different points in their job, "What are your pain points? What are the things that are terrible for you?" They tell me things like, "I have to enter the same event for our four different locations." In the back of my mind, I'm like, "That's what databases are for." [Laughs] You should just be able to check a box for each location it applies to.

It's really good to start by talking to the people who are going to be using and maintaining the content. To hear what it is that's terrible about their current CMS. So you can make sure that you're addressing problems that would make their lives better. Also, I feel like a lot of those people never get those questions asked of them. This is what they do, al day, every day. They work with this content. Or maybe it's only a piece of their job, they only spend half a morning a week. But they're the people who manage the content and no one ever asks them, "What parts of your job are terrible that we could fix with the magic of programming?"

It's really nice to start by saying, "One of the goals of this project is to make your work better. To make your life better. To get rid of the busywork and make sure that you understand what it is that we need this data for." Giving them a voice. You'd be surprised how many people will talk with us afterwards and be like, "It was so nice that you started out that project asking what we had problems with." Because other internal initiatives happened and handed things down without checking with stakeholders. Not executive stakeholders, but I do this as my everyday job stakeholders.

Jen

It seems like, as developers, we used to be like, "I'm going to build whatever I want and I don't care about anybody." Then we had this wave of realization, "Oh, we should care about users." There's been a decade of user experience design. Thinking about end users. Thinking about the high school students who are going to go to the university website and what they need.

A lot of the projects I've seen, design means drawing things in Visio or Omnigraffle and coloring them in using Photoshop. Making a PDF and emailing it to developers. Developers are the ones who are figuring out how the database structure should be done. They're naming the fields and content types. None of that is done with designers. But the developers are very far-removed from the client. They've never met anybody. They must make it up. Sometimes, they're not even able to communicate with each other. Sometimes the names are very similar because they didn't sit down and plan them all together. They made each one up as they grabbed a ticket. That gets shipped to the client.

Karen McGrane has been saying this for years now. She talks about the user experience of the folks who work at that university. We're using that as an example, but it could be any organization. The people whose job it is to add content to the website. Their user experience. The amount of money that's wasted with all of the busywork. With the copying and pasting the thing and putting it in four times because the system isn't letting them put it in once.

It feels like there's an arrogance there. "The content girls are dumb, anyway. The content folks don't know anything and they're all girls and we don't care. They don't need to come to this meeting. We're going to have this meeting with the important people and draw our Visio diagrams."

Eileen

There's almost historical precedent. This is about improving working conditions. Not to get super philosophical, but capitalism isn't really keen on improving working conditions for employees. It's not super excited about spending money and energy on making things nicer for the people who you are paying. It's like, "I'm paying you to do a job. I say that job is copying and pasting this field four times instead of having a computer do something smart with it."

We want our users — who pay us — to have a good experience. But I am paying you. So you're just going to do whatever I tell you.

Jen

Right.

Eileen

If you think about bigger picture, it's more efficient. People will be happier in their jobs. You'll have better employee retention. If the user experience of being a person working there is terrible, there are implications and repercussions if your stuff is terrible.

I was just reading an article today — I think in the Washington Post — about a new ambulance and fire dispatch system. I want to say it was in the DC area. It's been terrible. It launched two months ago. It hasn't worked out at all. The article was kind of blaming the users. There are so many support tickets and tech support calls. I was thinking. If it's one person or two people who are forgetting to enter fields or doing things wrong, you could blame it on user error. But if everyone across the whole system is saying this is confusing. This is literally a life and death situation. You need to put user experience attention on the people who are using it, on the administrators. The 911 dispatchers that are sitting there, at their desks, staring at these screens.

Do you remember that era... as if it's over. [Jen laughs] That era of DOS screens and cardboard overlays that you'd put over your function keys on the keyboard. There would be this teeny, tiny 6 point type. If you press command + shift + F5, that creates a new account.

Jen

And the three-ring notebook that sits next to your desk so you can look up the code.

Eileen

Yeah! The black with the green. The black and green interface. It's just all of the fields in one thing. I feel like we're only two steps past that right now. We looked at the front-end Bootstraps. Like all of the Squarespace templates. They're beautiful. The front-end is so pretty. You're like, "Oh my gosh. Beautiful, full-bleed images and cool responsive stuff." Then you look at the back-end the poor people working in hospital administration have to use. You're like, "Oh lord. I'm so sorry. I'm so sorry we have put all of our attention on the front-end stuff for pointless web apps. You, who are saving our lives, get the short shrift of all user experience energy in the whole world.

Eileen

[00:52:48] Uh, people actually caring about it? Paying attention to it.

So, there are lots and lots of projects out there. If you work for a giant organization, there is probably reason enough — through the various initiatives you're working on — to have a full-time content person. But I feel like a lot of projects don't warrant that. They don't have a reason to have a full-time content person on the team or dedicated to the project.

At that point, whose job is it to be like, "Hey... content? Let's not forget about the content." If you happen to be a person who has experienced the benefits of paying attention to the content, then you might take it on yourself.

Overall, the biggest sticking point is having someone whose job it is and feels justified in spending some of their time paying attention to it. It might be a designer, developer, or a project manager. It could be anyone on the project. I know designers who love having structured content because it makes it easier for them to design. Instead of designing this big blob, they've got nice little chunks to work with. It's much easier to make a beautiful collage when you've got 27 pieces than if you've got one big piece and one small piece and that's it.

I don't think not having a content person on your team means that you can't do structured content or the simple thinking ahead. If some client that you're working for says, "Ok, we're going to have a blog." Ok, who's going to write the blog posts? How often are they going to write them? Does anyone have the time to do that? If they do have the time to do it, or if they only have time to do it once every two months, is that the right thing to do? Is that the best use of your time? What will you feel like if six months from you, there's only been two posts on the blog?

Those aren't hard questions. Those aren't like, "I need a technical content background to ask those questions." Just thinking ahead. Just a little bit of thinking through. I feel like a lot of client people, whether you're working in client services of your client is an internal stakeholder because you work at a jobby-job. They ask for something because they want the end result. They say, "I want a blog." What they actually want is a place where they can put up relatively timely information and not have a lot of overhead. It's not a program page or a new biography for an executive. They just want to be able to put up some little news things. Maybe there are lots of ways to get that done. That they asked for a blog doesn't mean that a blog is the right thing for them. The goal behind asking for that was that they want a casual, easy place to put some timely information. Maybe that's something that could be done in the sidebar or with a banner on the homepage. Does it need to be a blog format? Does that also mean archives and multiple authors? There are so many implications. Thinking through them a little bit and asking the questions behind the requests can help simplify. There are lots of times where it's like, "Oh. You mean all you really want is a place where you can put up a little banner when someone gets an award? Ok. There are way easier ways to do that than a blog."

Jen

It almost sounds like there are two places to ask these questions. If you're in any sort of position working on a web project and there's not already a clear team that said, "We're bringing in a content strategist. We're definitely going to do any audit. We've got two weeks to figure out the content structure. If you're on a team, no one is thinking about that. No one is thinking about content structure.

One idea would be to try to introduce these ideas at the beginning of the project. While sitting there, talking to the client, talking to the people who want this website. What is it that they really want? Make that part of the design from the very beginning. Think about the user experience of the content entry folks as an important part of the puzzle. Applying everything we know about design to both sides of the project, from the very beginning.

But we live in the real world, and lots of times that's not going to happen. It seems like the other place to do this would be when, as one of the developers, you've been emailed a pile of PDFs. Wireframes of how the website is supposed to look when it's finished. Or maybe you're the project manager. To have someone on that team say, "Let's architect the content structure. Let's do that ahead of time, before we start building this thing. Let's not break each piece into a separate ticket and have everybody do their own tickets and never talk about this. As the development firm, let's sit down and plan out."

Reverse engineer a content structure and content strategy. Like you said, not the editorial side, but the structure side. Hopefully, go back to the client, or go back to the design company, and say, "We think that your designs mean this kind of content structure. We'd like to talk to the folks who enter content into the system and learn more about what they need. We'd like to have you review this and let us know if there are any changes. Let's change this and get this nailed before we start building this.

Does that sound like a possibility to you? Does that make sense?

Eileen

Definitely. If you think about Brad Frost and atomic design. That whole idea of creating design systems, design systems and content structure are BFFs. They go hand-in-hand. If you have a bunch of different kinds of content types, they all have authors. Every time you display an author, you're going to display their headshot and name and job title and a two-sentence version of their bio. You can do that on blogs and news articles. It depends on the format of your site.

When you think about content structure, one of the things that you get to do is find places to save work. We could make the layout and template for these two different content types exactly the same and just change the color scheme. Structure-wise, these are the same kinds of information.

Or, we can just format date once. We can figure out how we want dates to be formatted across the entire site, or maybe two different ways. Then you just pick one.

Design systems and content structures are such good partners. If you're doing any sort of atomic design or design system thinking for your templates and layouts and CSS, that's another place where your urge, as a developer or designer, is to reuse the designs that you've created. That's a place where that should be a flag for you. "If I'm reusing the design, is this being structured in a way that we can be reusing the database fields? Can we be creating relationships between these pieces of information? The same patterns that exist in the design are very often paralleled or echoed in the structure. That's another place where you can start to discern patterns, because of other pieces of the process.

Jen

It's true. A lot of people talking about a design library, pattern library, or a design system. The focus is on reusing CSS, object-orienting visual patterns. Efficiency in code. But you're right. It's not just about efficiency in code or a visual system. It's about the content itself be a part of that system. To not just plan, "Ok, visually, we'll use these patterns. We'll use purple in this way everywhere. We'll use this particular class in CSS everywhere." To extend that planning session, that effort, to the content and the way the content is structured.

Eileen

If you don't have anyone on your team who is already content-focused, that's a place where you can start paying attention to content without it disrupting your whole process. Without it being like, "Oh, great, another thing we have to pay attention to." It should integrate pretty well.

Jen

Do you see a trend happening, where more and more people are starting to do these kinds of things, in planning content structure?

Eileen

[01:02:50] We've talked about Drupal. Drupal makes content structuring really easy. There are lots of other CMS'. I know Craft makes it really easy. There are plenty of CMS' that don't start with anything beyond a title field. When you have to create from scratch, it's a lot easier to say, "I need a location, a date, and an author field." To create it from the ground up, rather than paring down or modifying a default set of fields.

I feel like people who get more and more familiar with those start to see the benefits of doing structured content. You get that feeling. I know you recently launched your newly built Drupal site. I know you get that feeling at some point where you're like, "I could fight against this, or I could do this the way the system wants me to do it." That's the decision to be made with each thing you want to display. But the times when those line up, and you're like, "The thing that I want to do is just how the system wants this to be organized." Everything is super smooth and you get to take advantage of existing libraries. That thing is so cool and powerful. You're like, "I just did something really fancy with hardly any work. That was awesome."

Jen

[Laughs] Yeah, it is awesome.

Eileen

Structured content with systems that are designed to work with structured content is one of those things. It's not any harder to build it because the system wants you to build it that way. Then you can do all kinds of fancy things because you're playing the way the system wants you to play.

Jen

I also feel like this kind of planning effort ends up with such a better end result. It is very satisfying. Both for the folks who are building it, when they get to the end and the folks who are going to be using it, into the future. When they get their hands on it and get to see, "We've been talking about this for months. What did we actually get? What does it actually look like?"

Eileen

I know there are definitely people who, if they work on lots of different teams and projects, if they work on one that has a dedicated content person, someone who really things through all of this stuff. Then they don't want to go back. They're like, "It was so good. Those are questions that always stick in the back of my mind. Should I just leave this help text blank? You had already written help text for these fields. It's so helpful." That kind of thing, it's a little bit like the 5th column. Content people are sneaking into the teams. Then people get so happy that someone thought about a bunch of things that otherwise are last-minute problems that come up. When you don't have those last-minute problems, the next time you're starting to plan a project, you're like, "Maybe we should actually put some attention on the content. That worked out pretty well last time."

Jen

There is something about it being very anxiety-inducing to try to be building part of a project and have these questions and have to make these decisions. "What is this content type going to be called? What is this field going to be called? What is the help text on this field? What is the order of the fields in the content entry form?" When there's no information and you're an individual developer on a project, you're probably not even doing the whole thing you're just doing a 1/5th of the project. It's maddening. You're lost and making things up. You know that you're making them up. You know they're not going to play very well with things that other people are making up at their desks without talking to you. You know it would be so easy if someone had just planned it all out already and emailed you an Excel spreadsheet. You'd be like, "Oh, I'm working on the 8th thing. Here's the name of the content type. Here's the name of the fields. Here's the help text. I'll just cut and paste." You're building a system that's really satisfying and makes a lot of sense, for the people building it and the people who are going to be using it in the future.

Eileen

[01:07:37] I think there's something to be said, also, for those kinds of tasks. The figuring out of the patterns. The naming and especially the writing of the help text. It's a little bit of a different piece of the brain, than the coding/building thing. You're context-switching the entire time. You're creating a content type, figuring out what the help text is, creating your next field, figuring out what the help text is. Certainly for me, those two things are very different kinds of energy and brain space.

When I was building Drupal sites, back in the day, I would create all of the content types and name everything. Then have a pass later, where I went back and changed the labels of the fields to make more sense and do help text. Not that I forgot it until the end, I just couldn't do it at the same time. If I'm building, it's a different piece of my brain than figuring out what author's need so when they replace this image, they will replace it with one that works with this design. Those are very different pieces of communications that have to happen.

Jen

Absolutely. In one of them, you're focused on a small piece of the whole system. In the other one, you're focused on the whole system. I think it's very hard. Even for people who are very good at both tasks. The development parts and planning/design/content structure parts. It's not possible to switch back and forth. I think that's part of the frustration for anyone who has been in that position. You know you're bad at what you're doing. You don't have a plan for the content. It's slowing down your ability to get development done. You can't get flow around your development and the CSS you're writing. You're getting stuck by these questions about the content structure. If you want to do a good job on the content structure, you don't have the information that you need. You didn't meet the people who are going to be entering content. You're only working on one or two content types. You're not working on all 17 content types. You don't have the authority to work on the other 17 content types. They've been given to other people to work on.

In the end, you know you end up delivering a product to the client where it's kind of a mess. They've been complaining for four months about how crappy their old CMS is. Everybody is so excited to start over with a new CMS. They're so excited to have a new content-entry system that maybe, finally, will make sense. You know that what you're giving them — on day one, when it's all fresh and clean — already doesn't make sense. It's the most frustrating thing.

Eileen

[01:10:32] Then if you're an internal person, working on an internal team, you go back months later and you're like, "What did you do? You broke my design. You put weird content in. You can't just copy this teaser from over here. That's not how it works." They feel like you did a bad job, because the site looks crappy and broken. You feel terrible because you're like, "They broke my stuff. I made a beautiful thing and gave it to them and they pooped all over it." No one is happy. Everyone feels like people aren't good at their jobs, even though everyone is pretty good at their jobs. It just needed different attention on it to communicate what needed to be communicated.

Jen

Right. Then add 10 years to that...

Eileen

Oh gosh.

Jen

... and everyone's walking around going, "____ is the worst content management system ever. We need to get rid of it. We should have picked a different one. Let's pick this other one." When it may not be the software that's the problem. You could switch from Drupal to Drupal and have it be better, simply because of the way it was planned and designed.

Eileen

That's totally how CMS vendors sell things, too, right? CMS vendors are like, "Our interface is so great and perfect. Look how snazzy it is. There's drag and drop stuff. You can edit in place." All kinds of things. It looks so fancy and so much better than whatever old, crappy system you're using. But if it's not customized for your uses and doesn't have the stuff that your team needs, then it's just not any good. It could be the fanciest system in the world. But the fanciest system for a generic demo user.

Jen

Right. There are three content types and they're very well-planned. The demo is gorgeous. If your site were that cleanly planned and elegantly implemented, it would be amazing, too, on their software.

Eileen

There's always a super widescreen image that looks beautiful at full-bleed and only 150 pixels tall. Then you go out in the world and you're like, "There are only three of those images in the entire world." [Both laugh] I can't replace this image with anything. You end up replacing it with something weird.

Jen

Content is really important. In the real world use cases, designing and planning with real content. Creating a system that normal people can use in their everyday jobs, with all of the chaos and confusion of a real job. Do so with a certain amount of elegance and success, because there are constraints and tools that are helping them succeed instead of tools helping them fail.

Eileen

Also, being realistic about what people can do, moving forward. Images are really easy to pick on. So often, if you look at comps, they're super beautiful. They have these beautiful images that represent the company or organization perfectly. They've got cheery, multicultural people smiling in a conference room.

But in the real world, it's like, this is a tiny nonprofit who does not have a photographer on staff. They don't have photos for their events. If you make a layout that's super beautiful, that requires a really beautiful photo, what are they going to do? They don't have photos for the next ten events they're going to list.

That's one of the things about having everyone on the team — designers, developers, QA people — be in contact with the client. Be involved in early decision-making. Understanding what the strategic plans are for the site. Also understanding what the limitations are. It's fine to have a known constraint. We are not going to have good images for this site. This can't be an image-heavy design — it's just not going to work. But you have to talk about that at the beginning. That's a piece of content, too. What are we going to do for images? We're not going to have nice images. We're going to pick one stock photo, and otherwise we're not doing images. That's fine. Designers can work around that make something amazing and gorgeous and compelling that is not image-based... if they know they need to do it.

Jen

Or say, "We'll have images. They're just going to look like regular people shot them with their phones. So let's design a website where it's kind of beautiful when you don't have $3,000 photographers shooting these gorgeous images."

Eileen

We built and launched a site — maybe a year and a half ago — that was based on being Instagram-looking. I think we actually used Instagram as part of the backend for applying filters. Designers looked through and said, "Use one of these three filters because that fits the mood of the site." There were some guidelines for it. It was like, "We're not going to be taking professional images. So let's design a site that looks really good with little square filtered Instagram images."

Jen

Yeah. What are some other success stories that you have? Ways that things have come together really well?

Eileen

[01:16:18] Let's see. [Laughs] It's kind of funny. I think some of the things that I am most proud of are times when we took content away. I don't mean that in the way that we dropped an entire section of the site. I work with a lot of nonprofits. They often have small budgets or are grant-funded.

Grant-funded is an interesting thing in itself. Sometimes the site has to have some random grant requirement. Proof of number of constituents reached or something like that. Even though that doesn't tie in to anything else that's on the site. But it's a known constraint. That is where our funding came from. They want that, we have to do that.

I think a lot of the stuff I'm happiest with are times when we were able to take a bunch of different things — we have this grant requirement, and we want people to take action and participate. We were able to combine those in smart ways and whittle them down. We would create one piece of content that would do triple or quadruple duty across the site. Which is really nice. I know these people don't have time for write-ups and videos of every event. The idea of creating one piece of content that will look cool on the homepage, will show in the featured events sidebar when you're looking at this category, will be used in a bunch of different places, and being able to save people work — all at the same time. That makes me very happy. Because they have better things to do with their time. They're saving the world and stuff.

Jen

Yeah. That's interesting. What do you think people should be doing that they're not doing? [Both laugh]

Eileen

Eat better. Exercise more. [Jen laughs]

Jen

Hang out with a chicken.

Eileen

That's right. Hang out with a chicken. Always a good plan.

What should people be doing? I feel like people should slow down a little bit. I was thinking the other day about project scheduling. My partner, Aaron, is in charge of scheduling and project management for all of the things that we're working on. He's really good at it. It's been a very long time since we've had a project that has gone over time because of anything on our end. Sometimes the client takes six weeks to get back to you with feedback instead of three, and that messes up the schedule.

He'll say to me, "Are you going to have Thing X ready at the end of next week?" I'm like, "Oh yeah, I'll have it ready tomorrow." Because he's done a really good job of being realistic with the schedule. I was thinking about how much space that gives me to do my job really well. It means I can follow loose threads and if I find something that seems interesting and maybe compelling and could be a really cool solution... if this was all due tomorrow, I would be like, "Yeah, that's cool. Whatever. I don't have time."

Building enough space into the schedule gives me the space to explore those things. Especially if you work in client services at an agency, or if you're a freelancer, our tendency is to be like, "You wanted this launch yesterday. We can do it in three or four weeks." When realistically, it's a six week project. If you're going to fit it in with other things — like having a family and running your house — maybe it should be an eight or nine week project. But they asked for it soon, so we tell them we can get it to them soon. It doesn't give us the space to explore these things that would make the site better. Also give us, personally, the energy to do that stuff. We don't feel like we're overworked. We have the space to breathe and do the things that keep us healthy.

If you were going to do one thing, know that it's ok to have a longer timeframe in your schedule. It is a good idea to pad things more than you think. No one is ever going to be unhappy that you finished early. For the most part, of course everyone wanted their site launched yesterday. I was talking to someone last week who was like, "Well, we were hoping we could launch at the end of April." I was like, "Uh, I'm having a really hard time not laughing in your face right now." [Laughs] End of April? That's absurd.

Given that everyone already wants all of that stuff, that doesn't mean that if you say, "This is a nine week project," that they're going to be like, "I'm going to go find someone else." They're going to work with the person they like. If you can demonstrate that you want to take nine weeks because it will give them the best product and result in a site that has the longest term usefulness for them, it's worth doing. It's worth taking the extra time. Giving yourself the leeway. Giving yourself the space to explore things. To do things right without feeling like you're super stressed out about it.

Jen

Yeah. Cool. Thanks for being on the show today.

Eileen

Thanks for having me!

Jen

People can find the show notes and transcript for this show at thewebahead.net/101. On Twitter, we're @thewebahead. And you can leave comments. If you have comments about this show, comments should be open. If you try to post a comment and it doesn't work, find me and tell me it's broken and make me go fix it.

Thanks for listening. Thanks to Squarespace for sponsoring the show, and 5by5, as always, for helping to make it possible. Until next week.