Transcript

Jen

This is The Web Ahead, a weekly conversation about changing technologies and the future of the web. I'm your host, Jen Simmons, and this is episode 57. I want to first say thank you so much to the sponsors of today's show: HostGator, Artifact Conference and the JavaScript Summit. I'll talk about each of those later in the show. This week, my guest today is Steve Fisher. Hi Steve.

Steve

Hi Jen.

Jen

Steve is a designer, a user experience designer, web designer, who I've worked with off and on over the years. He presents at a lot of conferences and we were both at the Future of Web Design last week. He was presenting on content structure and has been doing a lot of thinking lately about, "How do you work with clients?", "How do you think about a project?", "How do you plan a project so that you can figure out your content and figure out the structure of the content?", and "Why do you need to figure out the structure of your content?". I thought that'd be a great topic. It's a little bit like, I mean, we talked a little bit, a gazillion years ago now, when Karen McGrane was on the show. I think she was on episode 6.

Steve

Wow.

Jen

So, October 19, 2011. That's five days short of two years ago. We talked about content. So, still, there's a lot to say about how to think about a project and why you have to think about structures of content. So, hello Steve, thank you for joining me today.

Steve

I'm happy to be on the show, Jen, thanks for inviting me.

Jen

Yeah. So what have you been thinking about this stuff? I mean, what's been your experience, why is this important, structured content?

Steve

Well, I'm sure that anyone who has worked on any type of content-related project, which is most projects on the web, especially working with a content management system, you get to that point in the project where you realize that everything is going horribly wrong. And it's usually because we haven't thought about our content early and often enough. Or, really, often the people who will be interacting with the content and the people who will be creating the content. And so a lot of what I've been thinking about and working on over the last six months at The Republic of Quality is helping people understand that bit. The human side of content modeling, content structure, on these content management projects.

Jen

Yeah, I think you're right in saying that we think so much about the technology and about the, "Oh, should we use [onomatopoeia] or [onomatopoeia] for a tool," or "How do I write better CSS?" or "How do I use progressive enhancement?". But lots of times what really ends up mattering in the success of a project, or the failure of a project, is the humans.

Steve

Yeah.

Jen

... The people.

Steve

Completely. I just recently, someone we both know, Jeff Eaton, he gave a talk at a content management conference. He was talking about content models. I think he said, "No model survives contact with real content." That's generally true. When that happens, all of a sudden the model breaks and you have to re-work it. But there was a follow-up article by Cleve Gibbon, where he talked about, "No model survives first contact with real content." And I really loved both of their perspectives. But one thing that I always felt was lacking was that they talk about the technology, the audience, the content, and all of that, but they don't talk a lot about the people interacting with the content. Or the people, even more importantly at times, creating the content. The content authors and their teams. They're the ones that are going to make this site sing, make it come alive. Really, a website is a black hole without its content.

Jen

Yeah, I've worked on so many projects, especially, not recently but back when I was working on smaller projects and I would work with clients. I would have all kinds of amazing ideas about what their website could be, and how it would be awesome, and how it would help them do their business better. Especially, this was years ago when I was working with people who were not professionals on the web. They were people who were doing something else and I was helping them build their website. It was almost like, my ideas were way bigger than their ideas, because I do this for a job, and I didn't realize that I had run away, I had run down the road without them. And I would launch their site and they wouldn't use it. They wouldn't do what I had imagined. They wouldn't add the kind of content that I had made a plan for. It made me realize, ok, it's really important to figure out where the client really is. Not just what the site can be for their customers or for their users or for whoever is going to be using the website that we're building, but to figure out where the people who are actually going to make the content for the website; where are they, really? What, realistically, can they do in making content for this website? What are they actually going to do? Do they have time in their jobs to make more content? Or are they already making content that exists that we could use on the website? How can we build the backend of the website to make it really easy to get the content into two places at once? Or, even better, into one place and have it go to two destinations?

Steve

Yeah, exactly. What you're talking about there is the content authors, the people who are creating the content for the sites, they're actually really good at what they do. They understand their subject matter. They probably have a good idea, too, of their audience, but sometimes we tend to forget that they don't know web technology. That they're not familiar with writing for that. That used to be something that we would try get around. We've shove content into these fancy buckets, these websites that we had built, right? One thing that I love about responsive web design coming about is it's forced the conversation to take another step. Because suddenly, your content is living across multiple devices. It could be hundreds, thousands of devices, and you don't even know for sure where it will live in the future. To work out the structure and priority of the content and how the content author will insert and create that, has become even more important. Honestly, some of the process that I've been working with on clients and projects, when we go through this, they have this "Ah-ha!" moment where they see why we're prioritizing the content, why we have all of these discrete elements of content, and the way that input it so they can see their content live across all of these devices without having to necessarily test it across all of these devices themselves.

Jen

What's some of the process that you do when you work with a client? What kind of process do you walk through? What exercises do you do? How do you get them to a place where you can figure out what they have, where they're at, and get them to where you want to be? And have this "Ah-ha!" moment?

Steve

Well, some of the things we've always been doing or should have always been doing, at least, knowing the content. Inventorying what's there, if it's an existing website, which, in most cases for me, that's what's happening. We're moving from an existing site to an update. Auditing that, understanding the quality of it, where things maybe need to be removed, whether outdated, trivial, all of that kind of thing. Understanding audiences. But some of the most helpful things beyond that is when we sit down, collaboratively, as a team. I don't believe in working as a web designer, developer, vendor, separately from the client. I believe in working collaboratively together. When we sit down and create a user experience vision for the project, the design principles for the project, these guide posts that will help us understand when we're making the right decisions, and when we're making the wrong ones, and then the goals for the project. When we do all of these things together, we start to be able to frame the next bit of the conversation, which is this more human side of content modeling. A couple of people have talked about this, and I loved this term, "atomic content". This woman I worked with on a couple of projects, Lyn [last name unintelligible], she's the UX on Twitter, she mentioned once this "atomic piece of content" and that triggered a memory from a conversation I had with Brad Frost where he was talking about "atomic design", but then also Clinton [last name unintelligible] had talked about "atomic content". How we find this central piece of content, in this case it's a content type on a particular view, and find out how everything else orbits around that nucleus, that central bit that becomes the connective, magnetic piece for everything else. But of this is done together. What happens, practically, at this moment, once we have all of the audits, all of the inventories, we've audited of the things, we break out all of the discrete pieces of content, these content types that could exist in our particular view. When I say "view", I'm talking about what people would call a "page". This might be a landing page, a content page, something like that. Break out all of these individual, discrete pieces of content. We then prioritize them into three separate groups: Priority 1, 2 or 3. Everything has to make it into a group. Priority 1 is essential; this view cannot exist without these content types. That might be navigation, the heading for the page, page title, things like that. Priority 2 are things that are really going to support the message of this view. Priority 3 are "nice to have" but some of these didn't make it, that would probably be ok. Then we go back and do the hard work. The hard work is everything in each one of those groups has to be given a priority itself. Something is Priority 1 within Group 1. Typically, those first two things within Group 1 become your atomic piece of content. The "thing" that everything on that view orbits around. That helps us establish this multi-device, responsive design content model. In a very human way. Because people are doing this together, they're wrestling with this decision, they're trying to think about their audiences, what the inventories and audits have told us, and what their goals are for the future of the project, and saying, "This piece of intro copy on a content page for a government is the most important thing right now." Because it will tell us that the user they found the right service, the thing that they're looking for, or it won't, they'll need to start over.

Jen

You're working on an existing site, you make a list of everything that's on the whole site and every bit of content that's on the site, take an "inventory", as you called it. If the goal is to come to figure out what the "atomic content" is, is it that you're trying to figure out the most important sub-piece, the most important field or detail inside a single piece of content? Or is it that you're trying to figure out, "We've got seven flavors of content on this website. This one flavor is the most important flavor out of the whole website." If we translated to Drupal-speak, are you trying to figure out which content type is most important or are you trying to figure out which field in each content type is most important?

Steve

Well, it's a bit of both. We're trying to get it down to the most granular level that we can, where we say, "This is the most important." It may be a field within that content type. But it's difference per view, or unique template. I want to be careful how I use "views", especially thinking about the Drupal world. If we think about a content template. I most recently worked on this government site here in Canada. They had, I think it was a dozen, unique content templates that they could use throughout the site. From the homepage to a landing page to a listing to a content page, things like that. Within each one of those we're looking for, "What is that central bit of content type for that particular view?" On a homepage, which holds less and less importance as we go on, it might have something to do with establishing trust. It could be a featured image that helps people understand they've landed on the right site. But on a detailed content page, where they've drilled down to this specific type of content they're looking for, it could be that intro paragraph and all of the metadata that goes with it, too, that helps people search for it, understand what it is that they're about to read, know that they're in the right place. And then all of the related bits, whether that be actual related content or other advertising or modules or things like that, that are within that view, they support what's happening here and help the user explore further beyond that. But they're related to that central content type.

Jen

It sounds like you like to get together, have some meetings, exercises, whatever process, to discuss as a group and the make decisions as a group as to what the hierarchy is on any particular web URL. If you're on a URL for a web "view", as you called it, or a page, or a template, you know, it's a URL, then what's the hierarchy here? What's the most important thing? What is it that people really came to this page to do? What are they looking for? What are we going to serve to them?

Steve

Yeah, that's it. Where this becomes really important for a responsive project, which is really any project for me now, is what happens when the content goes out to a standard desktop? That's one of the easier scenarios, right? Then maybe it gets a little more difficult when we're dealing with a smaller screen and we're having to prioritize things. It's good that we've set this priority. What happens when content goes out to a Pebble watch? Right? Or something like that, that is extremely limited? Or even a future device that we don't see now, that's a combination of a watch and an audio interface? What gets served first? What helps the user understand what it is that they're getting and why it's important to them? And that's why all of this prioritization is really key to that. But I think the other side of all of this, which has been the best part of all of the projects I've worked on recently, is the collaborative bit. That we do this together. I actually do get client stakeholders and myself and anyone else that's on the team that's appropriate for this exercise, the maybe 5 or 6 of us, locked into a room essentially for 2, 3, 4 days, where we go through essentially a design sprint, where we're talking about all of this content and priorities and eventually get to some loose sketches of the interface to help us understand what these priorities mean in a practical sense when we're displaying the content. It's very intense but in pretty much every case, every client, and these are from startups to governments to enterprise clients, they just have this "Ah-ha!" moment where they just feel like the work that they're doing just completely makes the project make sense to them. I think that's because they're in the room together and they begin to understand how their content is going to live.

Jen

Helping the client, and the multiple people who together make up the client, to focus on content and to focus on hierarchy, content hierarchies, is great because then other things like, "How big should this type be?" or "Which thing should be on the top of the page?" or "Why is this black and this other thing is grey?". There are just so many visual decisions that get made that are typically made with understanding content and the importance of content and the hierarchy of the content is an assumption. It hasn't been articulated verbally and everybody's focusing on which color blue the thing is going to be, and people are like, "I like this blue better!", "No, I like this blue better!" "I think that should be bigger!" "No, I think that should be smaller!" "I think that should be on the top!" "No, I think this should be on the top!" It can get really down in the weeds and really frustrating. It sounds like you're talking about laying a groundwork that will help make all of the rest of that fall into place if everyone's agreed that this is the most important thing on this page, this is what's going to need to be at the top. And to bring a group of people into that process instead of having it just simply be designers doing that, sort of off doing that by themselves.

Steve

It's a good moment in a project, too. Because some of the earlier work we do collaborate on. But, honestly, doing an inventory of all of your content is just doing an inventory. You just have to dig in and get it done. It is what it is. But at this point, we can start to make these decisions that you're talking about, and you're right. It makes every step after this easier. Because we're on the same team. We can't get out of this exercise without agreeing and we understand why things should be first, and why they should be higher in the hierarchy and so all these future design decisions are based on the content and its priorities. And we know which content we're working with. It's not this mystery. All of the feature content may not be written yet, most likely it's not, but we have an understanding of real content and how it will really live and it's transformative.

Jen

How do you know what goes on each "view", or page, or at each URL? Are you just typically taking that from what already exists, or are you thinking about that stuff, too, and making decisions about, "Should that be a single page by itself?" or "Should this be a module or a block on a landing page?" or "Should these three things actually live together?" You know what I mean?

Steve

No, I do know what you mean. And some of that does come up. And some of it isn't dealt with here. There are moments, and I think I mentioned this earlier, but just how, if you're working with a pre-existing site, it's easy to fall into the trap of just defining the content types that are there already, but we need to push past that a little bit to say, "Okay, if we have this goal of reaching this audience, what do we really need to do?" To have a bit of brainstorming of that. Based upon the real goals for the project, the real principles that we're moving towards. But then, within that... sorry, I just got totally distracted for a second! [Both laugh] You know, we're really working on trying to help push the project forward with an understanding here.

Jen

So. Content. Designing content. It's interesting to me because when you say to people, "I'm going to do web design. Here, hire me, it's for web design," I think a lot of people, the first thing they think about is the color. "Okay, you're the one who picks the colors and the fonts." And then maybe they have a sense of, "Oh yeah, designers just figure out information architecture and user experience stuff." But content seems to be living in another world. It used to be that we would ignore that content until the end. [Laughs] We'd use a lot of "lorem ipsum" and then we'd try to fill it in. But it feels like in this transition where we're moving from older ways of doing things to new ways of doing things, it feels like content has... I shouldn't say it feels like, absolutely it has, content has become front and center. We're talking, content-first, a lot more emphasis in the web design community around content strategy, planning content, thinking about how content could live in one place and then get poured into multiple different places. Content is really becoming an integral part of the design. Designing the words, figuring out not just what color a button should be but, what's the word on the button to really help the user interface work?

Steve, what do you think about content being a part of the design and needing to know what the content is in order to do design work?

Steve

I actually think that we can't do our design work properly without knowing the content. I started out way back in 1994 as a graphic designer, right? And someone asks me to create a piece, whether that would be a poster for a show or something. I might have some ideas in mind, but those ideas are formed around what the content of that poster was going to be and what the message was, what it was supposed to communicate, right? And I find it so fascinating that we have, as an industry, spent so many years focusing on the visual design of things and forgetting about the message. What is it supposed to communicate? How is it going to communicate that? If we focus on our audience, our content, whether that's existing or needs to be created, first, it helps makes all of these design decisions easier, or at least informed. And I'm a big believer in informed design. I don't think the responsive web or anything like that has changed what we should do, it's just part of us becoming a more mature industry and recognizing what is important, how to be successful.

Jen

I agree. I did a zillion postcards like that back in the day and the first thing was, "Well, what's the show?", "It's going to be a concert", "Well, who's the artist? What's their press kit? What kind of art do they already have? What is the feeling of this event, what do we want to convey?" And usually we never had content, so I would sit down and re-write everything and then it was about making that content fit very specifically onto a piece of paper.

Steve

That's the other part. I think it's totally reasonable that the early years of the web were us grappling with this medium and how do we, as designers, work with it. All of the things we've gone through, I think, are just normal. Whether that's going through building a site in tables, then understanding web standards, coming to grips with our medium is what's happened to us here. But it's still the same thing. We're still trying to communicate through this. This is connecting people to people. It's not just a bunch of machines that are taking over the world, I hope. I think it actually comes down to us saying, "I want to connect my website to this audience." And "this audience" is a bunch of people. They need to hear and see the things that will allow that to happen. Without understanding our content, our designs are just guesses. Often they're good enough guesses, but I believe in a better web, that we can do that. This is part of the process, is really understanding your content.

Jen

We talked about this a bit on episode 54, I think it was 54, when the folks who were on Development Seed, Dave Han and Dave Cole were on to talk about Jekyll and CMS. How to build a website without a CMS. It feels like we're going through a bit of a transition. Think about content modeling. Originally, we would just make a website by making a bunch of HTML pages. There was no CSS, there was no JavaScript, you just made HTML pages and everything having to do with the styling was jammed together into one file. We had these crazy font tags, and later table layout, and everything was just sort of smashed together. Each page was hand-built. Each page was made. Maybe we used a tool like Dreamweaver or something to help you make that. But it was made by a human, a person. Then we went into a phase where it was like, "Hey! Let's use a content management system!" Something like WordPress, or, of course, there's many others that were enterprise or proprietary or something. Many, many, many of them. But they all had the same thing going on, which was: You logged in. You said, "Oh, I want to make a new thing." Click a button. And it made a new entry and you would put in a title. It would automatically save the date of when this thing was made, and the author, and maybe have a place where you could put tags or something. And then it would have just one big empty box. And you'd just put everything in the one big empty box.

Steve

Mm-hm.

Jen

That worked great for, like, say, a blog. Okay, well, I'm writing my blog post, here it goes: "boom, boom, boom, boom, boom", it's text, text, text, text, text, oh, look, I inserted an image! More text, more text. Everything into one big giant... what Karen McGrane called, "the blobs", right? Like a big blob. The cool thing about that was that you didn't have to hand-make each page. Click a couple buttons and "bam!" a webpage would get generated for you. It became much easier to add content to the website and it enabled us to start separating out the content from the styling of the content. You could change the header of the website, you could change the background of the website, you could change a navigation item and add, maybe, a new item to the menu. All of that would get generated by robots and you didn't have to hand-make new navigation on every other previous existing page on your website. It started one of these main principles of how to build a good website, which is, separate your content from your styling. But it didn't go far enough with that. Because you still had that one body, that one blob of stuff, and I think many of us have worked with clients that have been left with a legacy from that era. Where they have 4,000 pieces of content in their database, in their CMS, and every one of them, they've got a title, an author, a date, some metadata, and then a big blob. There's been a big, big push now for many years, and Karen McGrane had this amazing talk, I could not stop ranting about how awesome it is. I'll put a link in the show notes, too, if people haven't seen it before, where she talks about blobs versus chunks and why it's important to "chunk" your content and actually make your content into separate, individual fields, separate, individual "chunks". The idea with that is, you can log into a website where it's not been designed where there's one giant form. There's a whole bunch of smaller forms. If you're adding an event, you have to fill out the date, you have to fill out the place, the place is actually going to make a map automatically, you fill out a whole bunch of different fields. You're filling out a form that has a bunch of questions to answer. Oh, look over here! You're making a different kind of content. You're making, something else. That seemed like a big revolution, and one that you would think that everybody has already bought into, everybody's already doing. But a lot of places are not. But if you do, you switch to a system where you're like, okay, we're going to add a film to our film festival website. The film is a content type. You click a button that says "Make new film page" and you get a form to fill out that says "Title of the film", "Length of the film", "Country that film is from", and then each of those individual fields, because they go into separate parts of the database and they come back out as separate items, they can be styled specifically. Every time there's a country named, it's in black and it's got this font on it. And then, oh, look, next year we want to change the design, so we have the same model, the same content structure, but we can, instead of making it black and 14 point, we can make it blue and 16 point and change the font. Or years later you can go in and redesign and apply a new visual style, and you can do that to old content and change the order of the fields on the page and make the country be at the bottom instead of the top.

Steve

There's this classic example that's been floating around that I've used in a few presentations, of when Starbucks redesigned their site. I've never actually looking into this though. I should make sure this is accurate. [Both laugh] Because I know that they've updated, for sure, but when they first created their responsive site, they had these product pages. They had this really important, a typical structure, but it was more the blobs. There's the giant HTML blob of main content, and then there was their secondary, or which they were calling their "sidebar", that had this important call to action at the top of it. On a standard desktop view, or widescreen, or bigger tablet even, everything was there for you to see. But most of us use our phones, or devices like that, when we're actually in Starbucks. That's how I pay for my Starbucks coffee, with my phone. Because they had these two giants blobs of the main area and this secondary area, this "sidebar", they just floating one blob underneath the other blob and their call to action was lost in the middle of everything. Since then they've corrected, they have these more discrete pieces of content, understanding those priorities, so they can essentially bubble up that call to action on any device. The truth is, we don't know where our content is going to live in the future. We don't really know now, actually, because it's basically impossible to test on every single device out there. We just do our best with device labs and cover the spread, so to speak. But if we have this really well-structured content that goes beyond the blobs to, at least, discrete "chunks", we can then have a better hope of sending out the content in a more useful way to more devices. Maybe even all devices. But it is impossible with these giant blobs. And you're right. I think it must be so hard to design a CMS. I've worked on some of that with the Drupal community, and the Joomla community, and others. You're creating something for every type of content that might exist. And yet you don't know what any of it will be.

Jen

Yeah.

Steve

It's really hard. I think on more and more projects, at least for myself, because I'm working on these larger-scale projects, we're actually designing a system as much as designing a website. We're designing a system for this content to be displayed consistently, in a beautiful fashion that makes sense to everyone. But where the individuality comes out is in the writing of the content. We don't really talk too much about the content authoring experience, but when we have these discrete chunks... Let's say we're using Drupal. We set out particular fields for, hey, here's your title. That's just the no-brainer, right? Here's your metadata around that. Here's your deck or intro or clarity copy or whatever you're calling it. Maybe there is a larger "chunk" of body copy in there. But maybe there's also, some sort of eCommerce site, so there's an ad and there's related items, and there's all these other pieces of content that the content author goes through in a structured way and makes sure is entered. At this point, I believe we should be abstracting the content creation process from the design. That doesn't mean that it doesn't flow into the design and the design isn't based on the content, but the content author shouldn't have to think about layout. They shouldn't have to think about colors. They should think about priority, hierarchy. What is the message of this? How is this well-written, well-structured?

Jen

That is one of the things that Drupal is really good at. You can design the content entry form to have the order of the blobs be a specific order. And then have the display be a completely different order. Also break up the sense of, we're building this website, and one of the content types is "Event". Each time a new event is coming up, you need to go add it to the system. But when you add it to the system, you're filling out a form, and when you fill that form out, the robots are asking, "Hey! I need three different images. One of them is going to be the teaser image. One's going to be the main image to the main page and another one's going to be the tiny image." Then the person making the content can say, "You know what? I'm going to use the same image for all three," or "No, I'm going to design a different image for one of these three use cases." But when they add it into the system, they're not adding it in a single page. They're not making one webpage. They're adding this content into a system and some of those bits are going to get used on the main page for that content. But some of those other bits are going to be held and only used on landing pages or teasers or on sidebars on other pages. To think about it as a system like that instead of just to think about it as pages...

Steve

I think it's essential on most websites, right? There are always exceptions to these things but, yeah, you're right. I was working with another organization where they needed to know, "What piece of our existing content," is how they were framing it, "... is going to be what shows up within our search engine on our site, internally?" They realized that their content wasn't structured that way yet. That they didn't know whether they were going to use their teaser copy, whether it was going to be the metadata description, what it was going to be. But once you make that decision, that piece of content not only functions on that particular page, but it functions elsewhere, throughout the whole system. It just makes it that much easier for both the content authors to do things consistently, but also for the people that are coming to consume the content. The people that we're actually creating all of this for. It becomes this living thing that's so useful to them.

Jen

I love designing these things and I love thinking about them, not in terms of what people are asking for right now, but in terms of, what seems to be the best sense of how this is going to best function for this organization over the next two to five years. And we don't know. You build a website or a design or help create a website for a group. You don't know what they're going to do with it five years from now. But it feels part of the job, it's my job to come in and kind of access. And make a guess. And build them a system, a kind of a foundation for a house, where that foundation can take them someplace really great. And to not build anything in a quick-and-dirty, crappy way here, "Oh, well, we built it that way because you asked for this one particular display and this one particular thing and so we built this thing." And it's all janky. "Oh, you changed your mind? You don't want that display anymore? Well now you're going to have to live with this hack for the next 10 years." And no one will know why." Even little things. What do you name the fields? What do you name the labels when people add content to the system? Because I think, more and more and more, especially for bigger budget sites, especially for professional companies, it's a media corporation whose job it is to make content and put it on the web. They're going to change their mind about what they're doing. They're going to pivot. Like you said, a watch is going to come out. They're going to want to build a whole new site. They're going to realize that they though these teaser paragraphs would help people chose when they're looking at a landing page what to click on. It turns that nobody clicks on anything. So they completely redesign the landing page eight months in. So they're throwing away the whole design of that page and they're going to re-do it. They need to be able to grab the content out of the system that was built and create a landing page that looks completely different than we thought it was going to be. That structure and the design of that structure is not just about the current idea of what the website is going to be, but it's about something much, much bigger. Something much more long term.

Steve

I remember making this shift from working in just CSS layouts. How helpful it was for a guy like Dave Shea who created the CSS Zen Garden and be able to play around with that to realize the possibilities. That really helped sell doing web standards, CSS layouts, to a broad part of the industry. That CSS Zen Garden. The understanding that I could create all of these different layouts that still have the core HTML. Now I'm looking at content in a similar way. Because you're right, there will become a moment where all of a sudden, your site is going to change. We couldn't have planned for absolutely everything. Or there's been a shift within the corporate culture. Who knows what it is. But to be able to say, "Well, we can shift our design now. We can update that CSS. Or maybe even the HTML structure. But our content is what now is going to flow through that." Because it's so well-structured, it's so well "chunked-out", as Karen would say. An organization that maybe has hundreds of content authors, or even one that just has a couple, can actually refresh their site without having to re-think all of their content again. They may need to. But I love that that's the possibility that we can create for people in the future. I feel like I'm not doing my job right unless they get to that point, where we're essentially creating this future-friendly system.

Jen

What are we going to talk about? I feel like I'm in a bit of a whiny mood or something. I apologize. [Both laugh] I'm just like, "You should do it like this. This is how you should structure content." What I've found, in my own career recently, is I'm not doing that. We've just been talking about for the last 40 minutes. It feels like there's some other things happening as well. If I'm going to build a big website on a CMS for a company that has a lot of employees, or even a small number of employees, who are adding content to the site. That's the purpose of this website. This stuff should be structured up the ying-yang. It should be completely structured and robots are going to make everything. They're going to make every page, they're going to make every sidebar. But it's interesting because I have been working on a very, very small site recently that is just one person going to add content and that person knows how to make HTML and CSS. I've begun to not think about a website in that way of structured content for the first time in years. It's a big of a relief, honestly, to be able to say, "Okay, I'm going to design this one particular page and have this layout and this other particular page to have this different layout." Even though they're similar and even if I were building a CMS I would make them the same content type and I would force them to have the same layout. It's interesting to be like, "Oh yeah, there's a limit. Those constraints do impose constraints." Designing to constraints is awesome but also even with this little bitty project I should just go ahead and do everything by hand. Hand-built HTML. That will allow me to break out of the constraints.

Steve

It's interesting. My own site, The Republic of Quality, is based on no CMS. At all. That was partially intentional and partially unintentional, if I'm honest. I originally had it on WordPress, actually, the first iteration of it. It went in and that was just for me to go in and dig in further into creating my own custom WordPress theme, to be thinking about these things. Then I broke it out of that, and decided to just, essentially, build it all by hand. "It's just me and one other person updating this. This will be no problem." The best part of it, for me... it sounds like I had the opposite experience... was thinking about the structure of the content and all the little pieces that I take for granted within an existing CMS. All of a sudden, I had to go, "Oh, right. I need a RSS feed. I need to make that," or "How is this content going to relate?" This isn't just some plug-in or module that I'm adding onto this. I'm making every little piece. It made my hyper-focused on the structure of the content and how it would all work. Honestly, it's been a bit of an experiment as I go along, too. I do find that, at times, it can be quite heavy to go through some of this structure and everything and becoming, what seems to be, rigid. I recently worked on a very small project with a friend and it was actually a relief for them to have this structured content because they stopped thinking about the design of it. They started thinking about the writing. Getting the right images. Making sure that the right types of content existed up there. They found it to be freeing. I don't think think that everyone would find it that way.

I saw a great quote today. There's a project management summit, digital summit, maybe it's put on by Happy Cog. I'm not sure. Jefrey Zeldman was the keynote of it. Someone tweeted that a quote from it. "Designers thin-skinned pre-madonnas." Something like that, right? I immediately want to respond to that, "Oh wait, I've just fallen into that." Part of that is I want to have more control, right? I want the things to live the way I want them to live because I feel like I know better. That's why I think all this content creation structure, all this needs to happen as a team. Because none of us knows best. But together we can actually come to this better solution. Which makes it, when you're doing something with a very small project, a little harder, but I still overall find it to be quite freeing. To have this structure.

Jen

It's definitely understandable. It is the thing that is most important. The content on the site and how it's going to be organized and how it's going to be presented.

Steve

But you're right. It's not the only thing. There are so many other things to consider. I'm not really a believer in the... there's lots of phrases out there. "Hey, let's be mobile-first," "Let's be content-first," "Let's be something-else-first," right? A user experience friend of mine just said, "I believe in people-first!" I'm like, "Yes, yeah." Really we should believe in doing the right things at the right time, right? I feel like once we understand a project, what exists, then understanding the content and how it will live and then moving into other phases, is really important. I'm not a believer in any one thing first. I focus a lot on this recently because I've seen it help organizations more than anything else I've been doing. That's what I'm hired to do. Help people have these really great experiences online. This has been the number one thing that has helped me help others.

The great part about this, too, is that everyone can be involved in doing this. Whether it's a content author, a web engineer, front-end developer, user experience designer, content strategist, the business owner, they can all jump in to pieces of this and be involved in a meaningful way. There aren't many other parts of the project where you can do that. It's a unifying thing. That atomic piece actually becomes this bonding moment for the team, too.

Jen

Get everybody in a room and get them all to agree on what the content's going to be. [Laughs]

Steve

Yeah, it's not easy! [Laughs]

Jen

We said this before, but that's a lot. Once that's accomplished, you're a good halfway through getting decisions made around what's important. And preemptively preventing people swooping in later and saying, "My thing should be on the top of the homepage."

Steve

A big key to this is the actual documentation of that process as it happens. For the people who can't participate, it's exposed to them. They can see things as it moves along. That's another big part of working collaboratively. Making sure that there's regular updates. You can communicate too much. It can get annoying sometimes if too many updates are going out. Realistically, that's the only way some people will ever know what's going on. You can't fit an entire project team in one room for four days. That's not going to happen. But they can jump in for part of that. Or they can have an email update system, a lunch and learn about what's going on. Those are the things we sometimes don't budget for in projects. Those are the moments that help us make it a successful project. We've all been part of projects that get derailed, or you're just sitting there, everyone's crying in the corner, wondering, "How did we get here?" It's usually because someone's very upset about where things are at. Or they don't understand and they want to design it their way. If they had been a part of the discussion in an ongoing way, this moment may not have happened.

Jen

What are some of the tools you like to use, that you find helpful?

Steve

That's a good question. During the sprint, one of the biggest things is actually just a whiteboard and marker. We actually make sure that everybody's ideas are captured. That's a big part that gets missing in meetings. We don't capture things and we don't have actions that come out of them. We can toss away the things that don't matter and keep the things that do. Along with that, just simply having your iPhone or a camera or things like that there to document and get those pictures out. Following up after some of these initial content modeling, atomic content process thing, getting this into the browser right away is really, really important. Because you can't sketch out all of the moments of how this content will live. We need to take these real pieces of content. Whether someone wants to use Foundation or Bootstrap or Drupal or their own system or just hand-coding it all, it needs to get into this grey box system where the people can see this living prototype. They can open it up on different devices and understand how the content will or won't work. Because we've made some assumptions as we're going along and we need to test those. Very quickly after that, I love to get the actual visual designs starting to be applied to it. Sorry, I should backup. Having people actually test it is crucial. That's another collaborative process. I don't believe, even though I'm the user experience professional they've hired, that I should be the one doing all of the testing. Most recently, I trained a municipality on how to do their own testing. They sat with me for the first few sessions, saw how it was happening, then I set up with them the next few sessions, allowing them to do it. They can do this on an ongoing basis to see how the content will live. The key to all these steps isn't necessarily tools, it's the process. It's it being open and having people in the organization understand it and work with it.

Jen

Where do the things break down? What do you find to be most challenging?

Steve

I wish that I could say nowhere. Let's say the people that are going to be developing the site aren't involved enough in the process, it really breaks down when it moves into that part of it. When someone is actually digging into... whether they're working with Oracle or Drupal or anything. They're going to build this thing and if that conversation hasn't been ongoing, that's where it starts to just totally fall apart. There may be things that the project team that was working on everything else up until then didn't understand about that system. Or the development team that will be working on it, they haven't been involved, don't understand some of the decisions being made and why they're being made that way. Do they continue to do things how they've done it in the past, or how they think is best? It's almost always with good intentions. Everybody wants this to be successful. But if we're not collaborating as we go along and bringing in the right people, things do just tend to fall apart when it changes hands. You can't have the knowledge locked up in one person's head, or even one department's head, or one team's head. It needs to belong to the project and somehow be accessible. I really believe that means involving the right people throughout. Whether that's a tech lead that is involved through the entire thing, so he or she can communicate it to their team. Or maybe the actual people that are going to be building, it's a small development team, and they're there throughout. As well as having content and user experience and business people as the site's being developed. There's give and take that way, too.

Another place it can fall apart is if we didn't do some of the foundational work. We just jump in and say, "We know our audience. We just know them." Or, "We know our content. We don't need to inventory the majority of it." Every time we do an inventory and people look at it, they're surprised. "Oh! We didn't realize we had that many redundant pages on our site." Or, "We never thought about this particular audience and how important they actually are to our organization."

Jen

Do you find it hard to bid with that kind of work, that kind of preparation? Do clients push back on that and wonder, "Hey, how come? I don't want to do this. Let's save some money. Let's skip these first steps. We're just go straight to picking out which color blue." [Both laugh]

Steve

I'd be lying if I said there wasn't some pushback. That's why I'm pretty careful to talk about how I do what I do. This is just me, personally, so I can get hired to do those things, that there's a right fit from the start. When there is pushback, whether I've already been hired... this is for anyone. A great thing is to be [inaudible] and say, "This is what you want to accomplish. Here's how these things will help you save effort and be more successful and have a better bottom line when we come out the other end." There is a certain element of trust by saying, "If we do these things right, it will be better." It's pretty easy to demonstrate that. To say, "We're going to spend a week doing this inventory." But we'll actually be able to bring your content down from 20,000 pages to 8,000 pages and archive the rest and people will find what they're looking for with greater ease because there's more signal to noise. One thing that I have found that designers aren't very good at, at times, is understanding business. Not just designers or content strategists. Anyone, right? Why this is so important to this business. How we can talk about that in a common language. It's almost like we need to do an inventory of the things we talk about and come up with that.

Jen

What else do I want to say about all of this? Content, designing structures for content...

Steve

One thing that I've found pretty interesting, and this is both over my personal career, but a trend I'm seeing happening in the industry is... I remember when I started at the last company I was at, Pencil. We would have a content strategist and we would have myself as user experience designer and we would work on projects a bit separately and then over time we worked more and more hand-in-hand. To the point now where myself, as a user experience designer, so that's I'd been for years, I find myself doing more and more content strategy. Focusing in on that as one of my core things. Every content strategist I work with together is doing what I would consider, in the past, more user experience design work. I find that to be such an interesting trend within the industry. There is very little separation at times between these two disciplines. It's the opposite of what I expected. I thought people would get more and more specialized as the web became more and more mature. That does happen. But I also see a lot more people working together on these things. Becoming more multidisciplinary and making sure if they can't do that, that they're on multidisciplinary teams. I'm not sure if that's something other people are seeing or maybe that's just in my realm of things.

Jen

I think that's true. I think that's also among designers and developers. Where it used to be very separate. The designers went off into a meeting with business folks and did some kind of secret something-something and put everything into Photoshop. All the decisions they ever made, ever, were in Photoshop. Then they just email all that stuff to the developers who didn't get a chance to meet the client, didn't get a chance to meet the designers, and the developers were supposed to just figure out everything and if anything was missing just sort of magically know what it is supposed to be. That's really changed. That's really not workable. Not that it really ever working very well anyway. But now the pain of it not working is so strong that we see more and more... a design team that brings in a developer to work on things and create prototypes. A lot more back and forth, a lot more iteration, a lot more, "We have these ideas for design but we aren't really sure what's going to be possible for development. Why don't we talk about some practical realities within our budget that we can do so we can innovate and do some interesting new ideas." A lot more back and forth. I think it's just one of these other things, many many things, where back in the day, there was no specialization. You were a webmaster. [Laughs].

Steve

Yeah, you did everything! [Both laugh]

Jen

You did all of the things! Then we went through this period where things got very specialized and very separated as things got bigger and bigger and bigger. You went from having a handmade website with 12 pages to building a CMS out with 12 million pages. There is something about the medium itself that's requiring us to go back. Maybe we're still working on a site with 12 million pages and there's still a big team and people need to specialize on that team. You can't have 12 people all doing the asme job. You need to have roles and say, "This person's going to work on this and this person's going to come at it from this perspective. This person has these talents. They're going to best contribute in this way." But it feels a bit like, what that looks like, and who does what, is a little less formulaic and a little more created for that particular project, for that particular group, for that particular period of time.

Steve

When it became obvious that responsive design was just becoming web design, it's part of what we do, I question whether companies like Adobe could adapt to this. I changed our hiring practice at the company where I was at. I was responsible for helping build that team of designers. I wouldn't hire a designer that couldn't code. At least to a certain level. I wasn't looking for someone that was the most brilliant web engineer in the world. But they needed to be able to make their designs come alive in the browser, right? They didn't have to make all the decisions there or anything like that. But they need to be able to, essentially, prototype. It's really changed how our industry is starting to look at that. There's lots of companies struggling with this. There's tools coming out like Reflow for Adobe and I'm really impressed with what the team there is doing, but it's hard to predict what the future of that tool will be like and how designers will work with it. Will they be able to change their workflow? Will they take time to learn something new? How easy can Adobe make that transition? Often we're quite fickle with learning tools. If it doesn't impress us within the first five minutes, we give up. That's something I heard the project manager from Adobe talk about. That's a struggle they're working past. I love how this has forced us all to think about our medium in a different way, right? We kind of assumed in the past that we could just deal with it and what we had, whether that's print design or any other type of design. In this responsive world, this multi device we're in now is forcing us to look at our content differently, our design process differently. Even the tools that we use. How effective is Photoshop anymore for certain things? Or Illustrator? Anything like that. Honestly, I'm really excited about that. I'm excited about the new web designers that are coming out that just assume they need to code. It's forcing some of the old guard, like myself, let's say, to re-think our own process and re-work that and to talk about it. If I could encourage everyone to do one thing, it would be to talk about their process, so that we can actually as a community learn from that. For me, it's still revolving around this inter disciplinary, becoming less of a specialist for myself. A little bit less. I still don't want to be building the backend of a CMS or something like that. That's not that I want and not what I'm best at. I'm a big believer in learning a few more things but also working on an interdisciplinary team. It's something I'm really impressed with about Frog Design, as a company. Their teams are never made up of, "Here's a bunch of designers. Here's a bunch of developers. Here's a bunch of other disciplines." It is a developer with a designer with a content strategist with a business analyst, all working together, all the time on these projects. It's really a healthy and impressive way of doing things.

Jen

It really is something... as individual people go looking for jobs or someone is starting a company and wants to be competitive or you have a company and you want to become or remain competitive, to look for opportunities to work on a cross disciplinary team and to not end up in a silo. Having a wide range of skills will help people. IT will help you get a job if you lose a job, it helps you get the next job. If you're just like, "I already know what web design is," or "I already know user experience design. I learned these five things in a book 8 years ago and that's exactly how we always do it." That's just not going to fly. The web is only 20 years old. Everybody keeps saying this, every conference I go to, there's somebody who gives a talk that's another variation, and frequently it's me, on "Where are we at? Oh, look, we thought we knew what this was and then everything has changed in the last 3 or 4 years. And now we need to change our processes and shake things up because of that." But, film. Film-making. The movie camera was invented in the late 1880s. The silent film era was from, like, mid-1890s to 1919. There was 15 years of people inventing ways for pictures to go into a strip in order to make something that got projected. Then there was ones that kind of got worked out. There was 25 years of people running around, making films, making short films, making feature films. Hollywood getting started. The whole thing. In no audio. Twenty five years of silent movies. You look at the movies from the 1920s and you look at the movie from the 1950s, you look at a movie from the 1970s, and they seem so weird and antiquated and the storyline is so slow and they're boring and the car crashes look dumb. The plot is completely predictable and the romance is completely trite. Film-making, 130 years in, is still innovating, quickly. We think we know what the web is 20 years in. We just don't. We don't even know. Maybe we're in the middle of our silent film era and there will be something that comes along that disrupts us. The way that adding audio to film disrupted the silent... whole groups of people lost their careers when audio showed up because they had no... there would be a silent film actor who was really about doing pantomime and looking a certain way. Then being an actor once people were talking out loud, their voices mattered. You'd start acting with your voice. A lot of people didn't make that transition. They couldn't make the switch. I think that one of the most important skills to have, for any of us, who are doing in some sort of a career or a job, is the ability to continue to learn and to adapt. Which anybody who listens to the end of this episode is totally interested in. [Both laugh] That's clearly already you if you're listening to the show in the first place. The people who refuse to adapt, who are like, "I already know everything. I learned this last year when I took that class and I'm done learning." We all have to keep learning. We all have to reexamine our process. We all have to try something else out, something new on a new project and see where it might take us.

Steve

That's a really important thing to keep in mind. People talk about it as the beginner's mind or the child's mind and that we can look at things and go, "What's another possibility here?" or "What can I learn now?" I'm always impressed with people who I respect and look up to and when they'll say, "I don't know how this works. Can we talk about this?" That's one of the things that has excited me most about my career. And it's terrified me, at times, too, is realizing, "I have to keep learning. Every month. Every day. Every year." In order for myself to really understand what's coming up. And not just do my job well. I think that's one of the reasons I've latched on, over the last while, to this atomic content, this moment within the web process, because it's the one thing that I feel like, "This is going to remain in some form." Whether that's just the bringing the team together so we really understand our message. Or the structure of the content that's going out and really understanding that. We don't know where that will go out to, but we know what we're going to be trying to communicate. I've really found that to be something that, I hope, will help every project that I work on in the future. As we as an industry focus in on some of these things, too, that I would hope that we're making a better web. Sometimes I go to some sites and I don't believe we are. [Both laugh] But every once in a while, I'll come across a site and think, "Wow! They just really got this. I completely understand from first glance what all of this is about and you've allowed me to do what I need to do immediately." Those are the moments where I go, "Ah! There's hope from this. I'm going to learn from this moment." And so should we all.

Jen

People can check out your company, right? At republicofquality.com.

Steve

Yeah, definitely.

Jen

if they want to track you down. And they can follow you on Twitter. @hellofisher is your account on Twitter, yeah?

Steve

That's "Fisher" without a "c", though.

Jen

I know, I always want to put a "c" in your name for some reason.

Steve

Everyone does, and that's okay.

Jen

Is it because you're Canadian that I think there should be a "c" in that? [Laughs]

Steve

Actually, I think the "c" is German.

Jen

Yeah, that's why I'm laughing at myself, because that makes no sense. [Both laugh] "I don't know, he says a couple of words weird, there must be a 'c' in his Fisher name." [Both laugh]

Steve

You can blame Canada, I'm okay with that. If anyone's ever up in Vancouver, I'm always up to go for a coffee or a drink.

Jen

Nice. Alright. I want to say thank you again to Artifact Conference, JavaScript Summit and HostGator for supporting the show. People can following me on Twitter @jensimmons. They can follow the show on Twitter @thewebahead. You can also sign up for a Web Ahead newsletter at 5by5.tv/webahead/newsletter? Let me look. Yeah. /newsletter/. I don't think this newsletter is actually working. I've mentioned it a couple of times on past shows and then I realized, I am subscribed and I get no email. I will track that down. I'll go find out what's going on and get this thing rolling. But if you want to, meanwhile, sign up, you will be there when it does start working. What it will do, is email you every time there's a new show and send you the show notes in your email box. Which can be handy. Especially since we haven't had a show every week. For a little while there, we were not having a show every week. People weren't really sure when there's a new show, this would be a great way to find out when there's a new show. I do have a show scheduled that will come out next week and one coming out the week after. If you're interested in listening live, you can go to 5by5.tv/schedule and look and see when The Web Ahead will be. Then you can listen to the show live while we record it. Thanks, everyone, for listening, and until next time.