Designing for a Strange CMS
Pfeffer, Doug
When designing the new KCRW website, the design firm had to hand off the complex design to be integrated into a CMS (Plone) they knew nothing about. Doug explains the process and tools that made this transition go smoothly. KCRW is Southern California's flagship National Public Radio station. The redesign by Hard Candy Shell of this multimedia site won the 2015 Webby for best radio and podcast website.
 My name is Doug Feffer. We'll be talking about a front end build that ended up sitting on top of Plone without knowing anything about Plone. I'd know nothing about Plone. Oh, this thing's not going to work, huh? Oh, it's a line of sight thing? Yeah. Maybe it just doesn't want to work. Well, okay, that's fine. Okay, I'll stay over here. Yeah, it worked like when we first hooked it up. That's all right, we will survive. No, that's all right. That's a little too needy. I can do that. Oh, there we go. Okay, cool. All right, back to Plone. Don't know anything about it. Still don't, except that I looked it up the other day when this thing came up in my email box. So I've done a lot of front end only work, front end work, a lot of server side stuff, mostly custom builds, rarely had to use CMS in any sophistication. Occasionally, I had to use WordPress for something that was kind of unpleasant. So I'm not, it's kind of new to the world of, you know, getting deep into CMS things. And I certainly never did a high level like integration effort like a big custom site would require. So what we did, I was working with a company at the time called Hard Candy Shell, it's a design strategy company. They do a lot of app work and big content site redesigns. They did the slate rebranding redesign, which a lot of people had opinions about New Republic, a bunch of things like that. The next thing, probably what we're talking about right now, which was the KSDRW website. And KSDRW, for those that do not know, it's kind of a big West Coast music institution, a lot of live bands come through and they radio head does like a thing there and stuff like that. People like them, pretty like legitimate in that world. And but the website was kind of a weak, like kind of old fashioned, just homemade, like a local radio thing. It didn't really have the backbone that like a nicer musical kind of platform should have. So Hard Candy Shell was contracted to kind of rebrand it, kind of reposition it, redesign it, shuffle the content around. And we really made it, or they, I'm not the designer, they just, you know, did their whole discovery phase thing and they were out there. So they had the new Look and Feel and they worked with a branding company to come up with a new actual brand and we lost that one and ended up looking like this, which was just much nicer, right? And a big emphasis on this thing was like, it was a real rich media player experience. The idea was like it's not like a blog, readers reading about the fact that Radiohead came. It's like Radiohead was there and there's all these archives, interviews and things like that. So you should be able to go back and listen to the live show, which they always have, but also dig into all their archives they got. So that was kind of the premise of that. And what I was doing with Hard Candy Shell at the time was a lot of these companies, a lot of these design companies, their deliverables after the end of all its research process and working with designers and the brand people, their deliverables to their clients, in this case, KCRW, might have been just Photoshop files. This is like four or five years ago. This is much more common. They would just give these companies Photoshop files and be like, yeah, this is what the website should look like. There's a hover effect probably, you know, figure it out. Here's a slide show also. You can also figure that out. And so we would drop these things off, or the designers would drop these off with the client and these CMS people or database people, whoever, their dev team, would that be on the hook to kind of tease out the interactions from just these comps, which doesn't work. It barely worked before, especially doesn't work now, because you have to take responsive stuff into account. People want things to touch and slide right. And there's just like too much to convey if you just give someone like a big JPEG. So what we started doing, what they started doing was trying out, really building out, like more than our prototype, it was like really building out the whole front end shell sort of, complete with all the hover effects, interactive effects, and responsive processes, and kind of faking all the different interactions in the client, in the browser, so everyone could take a look at it and see it on their phones, see it on their big screen, small screen, look at it on their web TV, whatever. And you get a much better sense of like how this thing is going to work. And also the people that are actually on the hook to implement it, in theory it saves them a little bit of work. The jazz cart of folks might think otherwise, but in theory, like, in theory it saves them a little bit of work because they don't have to actually then go pull in front end guys to figure it all out. They don't have to sit down and hash out the structure because it's already been done. And technically, you know, if I did my job okay enough, all the cross browser stuff was mostly sorted out and everything that was like, how to be plugged in was like mostly ready to go. That's what we got. That's kind of, that was the gist of it. So what I was tasked with was building out this front end for this thing and I didn't know anything about what was going to be actually, how this thing was supposed to run, how this thing was supposed to operate. Yeah, I had no idea Plone was behind it. I didn't know what was going to be behind it, but it wasn't really my problem, which is kind of a weird position to be in because I also, as a server side developer, sometimes I'm going through the front end and I'm just like, I guess this is how the data is going to work. I assume like, I assume that there's going to be some kind of response comes back when you sign up for this thing. So like a lot of times for the sake of the demonstration and the feeling, I had to fake a lot of like load times and submissions. Like this newsletter sign up button, just some jQuery. I kind of had to like fake a loader and stuff and fake this kind of confirmation message that would come back. And it was just full of comments like, you know, server side folks, this is where you're actually going to want to hook into some kind of API. This is going to be some JSON or some XML is going to be coming back. I'm going to get good luck with it. And I felt a little funny about doing that because I'm like, well, someone's got to figure that out. But it's, again, in this case, luckily it turned out and this is the magic of Plone. Apparently it was just fine because the website works really good. We're just like the demo is supposed to do. So an odd thing that comes with doing these kind of front end like blind front end mockups is you have a lot of this kind of place to hold the code where you just like, we're just like, yeah, this should really do something. Put a loader indicator on there and just, I don't know, you know, toss it over the fence and someone else is going to figure it out. And I guess it works out. I kind of always was wondering if I was going to get jumped by the server side people because they had to deal with all these assets and JavaScript and piles of garbage that had to send over to them to figure it out. But it seems to be okay. So thanks, guys. So that was a weird thing. It just, that's like a weird thing. I don't know if, are you all front end developers or you all clone developers? I don't know. Anyone touch anything? Is anyone only a front end developer? No. Okay, great. That doesn't really matter. It's pretty interesting. It's a mix, right? Everyone, you have to touch it all. So okay. So let's talk about the workflow sort of and how like what we actually, what I delivered to Jessica to integrate into clone. So I found using these static site generators. I saw there was another talk actually about static site stuff. I missed. I don't know if it was there. It was yesterday. It was yesterday. Okay. Was that the tool, the system? Was this static site generator? Yeah. Okay. Okay. There's a ton of them. I just looked it up. There's like two, at least two just listings of these things, which is great. Now, so what is that for those that do not know? A static site generator is just like some toolkit. If you need to make entire, a lot of content sites, for example, like if you're trying to make, if you've got archives of articles and content and streaming videos and stuff like that, most of the time you don't really need like a rail server side or even a Drupal thing or a clone or whatever on the back end. You can just pretty much just dump out. It's just HTML, right? It's all you really need most of the time. But the difficulty is not like serving it because there's just a bunch of HTML. The difficulty is as someone who's actually producing it and you've got to update the header because it's like, there's a promotion coming along. You obviously don't want to go and update 3,000 HTML files. You don't need PHP. You could just do with PHP and server side includes and stuff. That's just weird and lame. And also then you've got to host it anyway. If it's just all static stuff, you can just put it on S3 bucket or some host and it doesn't matter. It's out of your life. It's beautiful. So that lent itself to these kind of front end only bills because I could have the tooling to not just be playing with plain HTML files and plain JavaScript files and CSS. I would get the tooling of a somewhat developmenty environment on my end. But the deliverable was actually a stack of HTML files we could all put online and review in real life. And also I had the artifacts of the build that the server side people could then kind of leverage, which I will get into. I used one called Middleman. There's a lot of them three or four years ago. This is the one that I kind of liked. It's Ruby-based, which I like. I like Ruby. This is some of the stuff that it kind of gives you. Basically, you can put a bunch of HTML, a bunch of templates. So ERB, excuse the typo, ERB is like a template language, a Ruby-based template language. And you can just kind of use your includes and you can loop through stuff and there's some image helpers. It just kind of makes it handy. It gives you a bunch of helpers. SAS, do people know what SAS is? Yeah, everyone knows what SAS is, right? It's like a compiled CSS thing because writing just CSS is kind of a pain and it's not that great. So SAS lets you, like, sits on top of CSS and compiles down to it. This is a really useful, if you're doing a lot of SAS stuff, Compos is a really useful kind of toolkit that you can use with it. It just gives you tons of utilities. Like it will take care of weird server side hacks so you don't have to copy and paste the same stupid CSS, like seven lines of CSS for your different float fixes or whatever or vendor prefixes. It does a lot of that stuff for you. So this all makes it pretty easy to go about building out this front end because, again, the end result is just HTML, just HTML at the end of it, but you don't want to sit there in a big sea of HTML because that's a nightmare. So it kind of looks like this. What I ended up with as I'm building this is pretty much a page for every page, an HTML page for every page. It's not entirely HTML. So this is like the layout. This is like the big master template, basically the header that all the other stuff gets plugged into. And it's mostly HTML. We've got some helpers and stuff like that. We've got the partial, as I mentioned, which are just shared components that we can use all across the site. And a lot of content sites do have that because you've got the authors' bylines on every article. If you've got seven variations of the article, you don't want to actually be copying and pasting the HTML. One, because it's a headache for you as a developer. Two, it's a jerk move to the people that are implementing it because they've got to go fish out the same HTML 100 times and try and just, I don't want anyone looking at it. Being like, is this footer indented differently on page X than page Y because it's a different footer or just because he forgot to tab it? So this way you can kind of mandate, like, just trust me, this is the same markup. You can use this everywhere we're using a footer. This is the footer. So it gives you some amount of organization that's nice. You have directories for things. People like directories. You put your fonts in one thing and your image is something else. And you can kind of build that. So this is like the live site. Just for navigation purposes, we generally have a table of contents. So when we host this thing so everyone can review it, it's client review time, we can be like, okay, everybody, go to the staging server and let's review the music episode page. Everyone can go and click on it. It's an easy way to make sure everyone's on the same page. I find it's helpful to version the directories. So the person that dialed in three days ago, they pulled up on their Amazon Kindle or whatever they're reviewing it. They're not looking at the three-day old version. We just, otherwise, you go and be like, hey, please clear cash and reload. And that's a pain. So version of these things, host them. You guys can see them and everyone kind of gets a little taste of what, how the thing is actually going to work, which makes reviewing it easier. It makes like, it just makes feedback easier because otherwise you've got these JPEGs and you've got a slider and you've got a carousel on there and no one really knows how it's going to work. And you go through all the effort to build this carousel out or some like inane thing. And the client's like, I don't like it sliding like that. I want it to slide like this. And then you've got to go back and code it again. So this way, if it's out the gate, it's a working prototype. You just are farther along that approval flow and you spend less time looking back around because there's less surprises. Especially if you were starting the prototype stage, there's like no real room for the client to be like, I didn't know this thing was a vertical thing. I thought it was a left to right, I don't know. Whatever, you know, whatever stuff miscommunications happen. If you've got a working kind of prototype, it just makes it easier. So this again is an example of using the shared code thing. It's easier for me because I've got a little blog post kind of a module and I don't want to be copying and pasting that code 100 times. Plus for the sake of the visual, sake of the review experience, the content's got to differ because we have to show like what happens if there's a blog post, you've got five blog posts in a row. What happens if one of them, you know, has 300 characters in it? What happens if one of them is like, I don't know, has some other blur on top of it or something like that? It's all, but you don't want to just keep copying and pasting that. So that ends up looking like this. This was like a standard like module and we could show like this is like if there's an audio player, it's going to look like this, you know, you got what this looks like, right? And it just kind of provides that framework so you're not actually doing that and then other people that have to implement it come along and they see like, oh, clearly there, there's no question. Every blog post overview is going to look like this and granted, yeah, in the code like if there's an audio player, this markup has to be kind of emitted, but it's not on anyone to guess it. It's like it's not a formal, it's not a formal proof of like how anything works. It's just all a suggestion, which is kind of a funny, it's kind of a weird thing to be providing this markup and being like, I swear this is pretty much how it's going to work in the browser, but it's still on you to actually make it happen in the browser. So especially as it gets to its launch, like things are going to change and maybe blown or whatever you're working isn't really going to want you to do a certain thing. So in the best case, you get the stack of HTML and it's kind of like a suggestion. It's like you really ought to do it like this. Like we know it works good in the client approved it, but it's up to you how you want to do it. So we can even click around a little bit just like for the sake of it, because why not? Can I open this? No. I can't even get out of this thing. Let's see. How do you do this? Great. So, there we go. Right. So this is just the thing of, this is what we delivered. This isn't what necessarily went live, but it's an example of like how we built out almost everything as if it was going to be a real thing. So we've got our spinning music player. You have to make a lot of assumptions. This thing is technically, technically we wired it up to be a player. Like it went through the trouble of making sure you could drag and drop it, making sure the timer is ticking, making sure there's a mute state and always we just work is then as far as the interface goes, nothing is left to interpret when it comes time to do it. If you're good, you can sneak in some Easter eggs. This card will let us get away with this for a while, but we got a, I think it's not there anymore, but I think we got the Konami code in here too. It looks like, got my spinning egg in there. Because it's like an actual Easter egg. It wasn't my idea, but I'm like, they're like, do you think we have time to put in the spinning egg? And I'm like, I think so. I think we can make that happen. So this is cool because everyone just, you know exactly what the music player is going to look like. You know how the progress indicator works. It's not bulletproof because it's not a real player. And the more like complex the functionality gets, kind of the goofier the prototype gets because I really have no, I don't even know if the media player can stream in this way. Like it might turn out just not to work at all, but it's like a best case scenario. You get this kind of working functional thing. The client likes it because they understand it. They're like, yeah, this is what the media player should look like. The implementers kind of get a sense of it too. And the design, most importantly, the designers can sweat it out to their heart's content because as I'm sitting in the middle here, like the designers are also my client as well because I'm a freelancer. So Hart Canny-Shell was my client. Like the KCRW is technically, but like in my mind, my clients are the designers that I'm trying to, you know, I have to please them. So they're not like this guy's not giving us any support because we're trying to make this thing look good. It's got to be good. It's got to build good. So this guy's got to do it. But I also know in the back of my mind, my client is the plowing people in this case because I can't really in good conscience build a crazy unworkable thing that is only going to work on like the nightly safari built because that's just like, that's just like not, it's not fair. I don't know. No one's going to be happy with that because then the client's finally going to get it. KCRW is going to have this thing and the designers are going to be like, well, it worked in your demo. I'm like, well, it worked in your demo because you have like the 10K screen. Like it doesn't work for anyone else. So you kind of got to be like that sense of reality, being like, this is awesome. Like what you're suggesting is awesome. Like there's no real time blurs not going to work. It's cool. It's working in our like real prototype. And it's cool. You found an example of a CSS online, but like I'm not letting that go into like production code. So you kind of got to be the bad guy too like that when you're in this position. So it's useful. It's useful because everyone just like gets what gets what's happening here. I highly recommend it. What else we got here? I don't know. Stuff. We got stuff. Let's go back to the slides. There's just a little bit about like the beauty of kind of doing this thing, this prototype. Like you could, I know a lot of people will forgo, depending on the technical chops of the design shop, they might forgo doing a lot in Photoshop or sketching. Whatever they're doing at all and just jump right into prototypes in the browser, which is great because then you're really, you, I mean this isn't like novel. This isn't a brilliant observation I'm going to make. Other people have written books about it. Like this people's lives, like the prototyping workflow. But you get a lot more out of that kind of thing because everyone's looking at a working thing immediately. You don't go down a weird rabbit hole of someone's fantasy that only works in this strange limited resolution in Photoshop. And like, it's like, well, it worked on my browser. Like so many times I'll get a design and I'll be like, well, what happens to the browser? It's wider. They're like, oh, what, I mean, like, you, the browser gets wider? Yeah, there's just these implications and you have to fight those things. You deal with those immediately when your thing's in the browser and they can't like hide from it because a lot of times when it's just a design file, they can kind of just dodge the bullet a little bit. They can be like, I don't know, like, that's your problem, you know? And sometimes I can say like, well, it's the implementer, it's the clone people's real problem but I don't want to do that. So you kind of have to fight it out. You kind of got to get it done earlier. You see pretty easily like design decisions are going to be actually just stupid. Like, say a fixed header in theory with a certain rollout effect, say it's like, it sounds really cool. It's like, oh, as you scroll, you see like the, I don't know, something spins or something as you scroll all the stuff. Like, oh, it's really useful and awesome. Then you can see it in the browser, it's just like, it's garbage, just distracting and a nuisance. You can throw it out and you haven't sunk hours into designs and hours into like multiple responsive versions of it just to find out that it's going to be an unhelpful feature. The client likes it too because they can sit at home and look at it in the computer, which is dicey too because you don't want the client to play with the markup that's not fully vetted for too long. So if you give them markup of a prototype, you got to take it offline immediately after the meeting. So otherwise it's going to be emailing, because otherwise it's going to be emailing it around and they're going to be looking at it on their, on their Kindle or something like that, some crazy thing that's just not ready for production. So you've got to, you've got to, there's a lot of like, hand holding I guess, like you are, yes, this is working in the browser, but this is not, just because it's in the browser, this is not what's going to be on the website. Like, just look at this, just look at the header. Do you like this font? Like, okay, good. This is the way it's going to look, but leave it alone, but you can't hit it that hard. And again, like, when you have the markup and the thing launches and the slideshow is just broken or the hover effects don't work or the loading indicator is off to the rider in some stupid place, then I can blame the clone people, the implementers, can be like, look, I know the designs, like the designs weren't really that big, this didn't happen, but in theory. I'm like, look, the CSS is here, like the markup is here, like technically, like technically you know how this thing is supposed to work, you know on mobile, like we have the momentum figured out, like we have that easing animation that we had to sweat out with the designers, like that's working in the browser here. Like how come it's not working in the production thing? So that's something you can kind of, you can't really, no one can fake a certain amount of it or say, I didn't understand it or I didn't know it. When you've got the actual markup. I'm trying to think what else we got. That's it. That's all I got. Are there any questions? About the Internet? But yes, sir. I feel like a bunch of my questions are probably like group questions, like structurally and how close did what you guys launched with, you know, like how much did the code change? It might be useful for you to just do a two minute. Yeah, that'd be awesome. Because it's not like it's both of us. Yeah, yeah. Yeah, okay. It looked great. When it launched, it was like that's exactly it. Except for like things that like I knew, like everyone knew was going to change, like the streaming implementation, no one knew how that was going to go. Right. So what we got from that was perfect for what we needed. That's nice. There's the middleman setup, which you know, it's ERB, it's Ruby templates, it's a little weird for us by now because it's a templating language, right? And there was a SAS setup, there was all this stuff. We just took that index.html that you saw there. The one that generated version, so the compiled version where all this stuff they'd get and pull back. Where there were low module elements, we pulled that up. We made that a D-AZO thing. The compiled CSS, they came out of SAS and composed, put in a D-AZO thing. The D-AZO thing sounds awesome by the way. That was like super impressive. I wrote one of the email again. You can just take a regular markup and make the CMS understand it. Is that what you're telling me? Yeah. More or less? Yeah, you take the markup and you have this intermediate thing that takes the CMS markup and your markup and uses rules to put the CMS content into your markup. And so that's what we did. And we continue to this day, for the KCRW site, which I do kind of maintenance on and new development, to use that middleman tool to build our theme as we make changes to it. So we can test out frontend changes, prototype them in the static site generator, which we keep using. And we're working from that same repo, we just have a branch on it that we use for the production site. And just continue making these changes. It generates sprites for us. It compresses all the images. It does some special Ratne image thing for all the team images. Right. It just does all of this great, magical, wonderful stuff that us back-end developers don't normally think about. And then that's the D-AZO theme. It gets you sort of the wrapping of the site. And then for the dynamic things like this, in some cases, these are tiles, in the clone sense of tiles. There was already a piece of HTML behind this that she put data into. Right. So we just took that little modular snippet of code that was called like show.showmodule.erb or something like that and turned it into a ZPD and made it a tile and rendered it with a content provider. And so we already had these little HTML snippets that we could turn into ZPD and put a little class behind. And so we have all these modular things that we can place wherever we need to in the page. Sometimes they'd be affordly. But either way, we've got the HTML already for them. All the CSS is being built with this static site generator. And so we use that pretty much unmodified. There are a few, what we did do is we went into, we're using collective.cover for our sort of flexible page layout engine because it wasn't around at the time. And so we had to add like a custom grid layout engine because it's got some portable grid layout. To use the grid layout, it was implied here by the CSS and all that. And we probably could have done it the other way around and modified all of his stuff and the grid that it used. But why? That's the point. Because we already sweated it all out. So the hope is that it's workable enough. And it sounds like, to bring back to Plone, I guess, it sounds like you're able to do that. I think if I gave this to like a word, I don't know, what's the laughing stock of CMSs from the Plone point of view? What do you all make fun of? It's probably word pressing. That's pretty much it for everyone. I would imagine it would be unpleasant to try to bend this around. I'm sure it's doable. People do whatever they want. But I imagine it would be unpleasant. But it sounds like you were able to, Plone, was variable enough that you made it happen. We did our best. Yeah. It worked. It worked. It was, you know, most of the difficulties had nothing to do with, sorry, most of the difficulties had nothing to do with the front end itself. It was more about the logic of getting things and fetching things and what shows and pages of the design process fit in place where this other thing was. And just abandoning functionality that it turned out to be cut to four. Yeah. Yeah. A lot of times when we were building it out in the design size, the designers have these big ideas that they invented when they were like, out for drinks with the client. And then it comes to me to build it out. And I'm like, I don't know if this is going to happen. I don't know if this is technically feasible if they had this data even. Or if they can stream it like that. Or if you can hop around like, I don't know if the audio servers support this. But still, again, like there's like a funnel of feasibility as it goes through the layers to like the final implementers and what the servers are running on and stuff like that. Where is it hosted? They have their own ops? Yeah. We host everything on AWS so I managed the ops. Okay. So, yeah. Anybody got another question? Great. Any clones CSS trickling through or is it all? That's a good question. What's the question here, Peter? How much of clones CSS ends up impacting the design here? We minimize it. So I think there's like one or two CSS files from clones that we call in through the resource registry. The theme itself is coming through DS. We don't register any of the themes CSS. Theme CSS is one huge CSS file that gets compiled basically. So the clones CSS is in there. Most of it is only there for logged in users. The only logged in users are the content managers. But yeah, they edit in the theme UI. So the UI you see when you visit kcrw.com. That's what they edit in and it's got the green editor on top. So there's a clone with the music player on top. A bunch of past-of-blocks and tiles and things. A lot of tiles. A lot of blocks. There's a lot of modules in this thing. Yeah. Oh yeah. They shared. So Doug just popped this up. These are the modular elements that he developed for us that we were able to use in various places and reuse. There's like a million of them. There's so many. There's so many. This site specifically feels like I had a lot of tiny content chunks that just spread out everywhere. Right. And a lot of these popular episodes, that's a module but it's filled with a whole, it's filled with one other module. Yeah. And it shows up multiple times. I mean, it's just like template reuse. It's nothing crazy. But this is like, this just helped us organize it. And how it's ultimately implemented. So it's like, oh, but it sounds like having it cut up like this ahead of time at least gave some kind of guidance for how you folks might share it. Yeah. Absolutely. Seeing that like looking within say the home page and seeing that there was just a one line that said, build look at this module. Right. It's a clue that we're going to need to build a reusable module for that purpose. And so, yeah, I think a good takeaway from this is like building something in a static environment like that. So it's a really helping thing. What goes into pages and how to use that. Cool. How's it? Anything else? Great. Great. You got it. Thank you.
 My name is Doug Feffer.  We'll be talking about a front end build that ended up sitting on top of Plone without  knowing anything about Plone.  I'd know nothing about Plone.  Oh, this thing's not going to work, huh?  Oh, it's a line of sight thing?  Yeah.  Maybe it just doesn't want to work.  Well, okay, that's fine.  Okay, I'll stay over here.  Yeah, it worked like when we first hooked it up.  That's all right, we will survive.  No, that's all right.  That's a little too needy.  I can do that.  Oh, there we go.  Okay, cool.  All right, back to Plone.  Don't know anything about it.  Still don't, except that I looked it up the other day when this thing came up in my email  box.  So I've done a lot of front end only work, front end work, a lot of server side stuff,  mostly custom builds, rarely had to use CMS in any sophistication.  Occasionally, I had to use WordPress for something that was kind of unpleasant.  So I'm not, it's kind of new to the world of, you know, getting deep into CMS things.  And I certainly never did a high level like integration effort like a big custom site  would require.  So what we did, I was working with a company at the time called Hard Candy Shell, it's  a design strategy company.  They do a lot of app work and big content site redesigns.  They did the slate rebranding redesign, which a lot of people had opinions about New Republic,  a bunch of things like that.  The next thing, probably what we're talking about right now, which was the KSDRW website.  And KSDRW, for those that do not know, it's kind of a big West Coast music institution,  a lot of live bands come through and they radio head does like a thing there and stuff  like that.  People like them, pretty like legitimate in that world.  And but the website was kind of a weak, like kind of old fashioned, just homemade, like  a local radio thing.  It didn't really have the backbone that like a nicer musical kind of platform should have.  So Hard Candy Shell was contracted to kind of rebrand it, kind of reposition it, redesign  it, shuffle the content around.  And we really made it, or they, I'm not the designer, they just, you know, did their whole  discovery phase thing and they were out there.  So they had the new Look and Feel and they worked with a branding company to come up  with a new actual brand and we lost that one and ended up looking like this, which was  just much nicer, right?  And a big emphasis on this thing was like, it was a real rich media player experience.  The idea was like it's not like a blog, readers reading about the fact that Radiohead came.  It's like Radiohead was there and there's all these archives, interviews and things  like that.  So you should be able to go back and listen to the live show, which they always have,  but also dig into all their archives they got.  So that was kind of the premise of that.  And what I was doing with Hard Candy Shell at the time was a lot of these companies,  a lot of these design companies, their deliverables after the end of all its research process  and working with designers and the brand people, their deliverables to their clients, in this  case, KCRW, might have been just Photoshop files.  This is like four or five years ago.  This is much more common.  They would just give these companies Photoshop files and be like, yeah, this is what the  website should look like.  There's a hover effect probably, you know, figure it out.  Here's a slide show also.  You can also figure that out.  And so we would drop these things off, or the designers would drop these off with the  client and these CMS people or database people, whoever, their dev team, would that be on  the hook to kind of tease out the interactions from just these comps, which doesn't work.  It barely worked before, especially doesn't work now, because you have to take responsive  stuff into account.  People want things to touch and slide right.  And there's just like too much to convey if you just give someone like a big JPEG.  So what we started doing, what they started doing was trying out, really building out,  like more than our prototype, it was like really building out the whole front end shell  sort of, complete with all the hover effects, interactive effects, and responsive processes,  and kind of faking all the different interactions in the client, in the browser, so everyone  could take a look at it and see it on their phones, see it on their big screen, small  screen, look at it on their web TV, whatever.  And you get a much better sense of like how this thing is going to work.  And also the people that are actually on the hook to implement it, in theory it saves them  a little bit of work.  The jazz cart of folks might think otherwise, but in theory, like, in theory it saves them  a little bit of work because they don't have to actually then go pull in front end guys  to figure it all out.  They don't have to sit down and hash out the structure because it's already been done.  And technically, you know, if I did my job okay enough, all the cross browser stuff was  mostly sorted out and everything that was like, how to be plugged in was like mostly  ready to go.  That's what we got.  That's kind of, that was the gist of it.  So what I was tasked with was building out this front end for this thing and I didn't  know anything about what was going to be actually, how this thing was supposed to run, how this  thing was supposed to operate.  Yeah, I had no idea Plone was behind it.  I didn't know what was going to be behind it, but it wasn't really my problem, which  is kind of a weird position to be in because I also, as a server side developer, sometimes  I'm going through the front end and I'm just like, I guess this is how the data is going  to work.  I assume like, I assume that there's going to be some kind of response comes back when  you sign up for this thing.  So like a lot of times for the sake of the demonstration and the feeling, I had to fake  a lot of like load times and submissions.  Like this newsletter sign up button, just some jQuery.  I kind of had to like fake a loader and stuff and fake this kind of confirmation message  that would come back.  And it was just full of comments like, you know, server side folks, this is where you're  actually going to want to hook into some kind of API.  This is going to be some JSON or some XML is going to be coming back.  I'm going to get good luck with it.  And I felt a little funny about doing that because I'm like, well, someone's got to figure  that out.  But it's, again, in this case, luckily it turned out and this is the magic of Plone.  Apparently it was just fine because the website works really good.  We're just like the demo is supposed to do.  So an odd thing that comes with doing these kind of front end like blind front end mockups  is you have a lot of this kind of place to hold the code where you just like, we're just  like, yeah, this should really do something.  Put a loader indicator on there and just, I don't know, you know, toss it over the fence  and someone else is going to figure it out.  And I guess it works out.  I kind of always was wondering if I was going to get jumped by the server side people because  they had to deal with all these assets and JavaScript and piles of garbage that had to  send over to them to figure it out.  But it seems to be okay.  So thanks, guys.  So that was a weird thing.  It just, that's like a weird thing.  I don't know if, are you all front end developers or you all clone developers?  I don't know.  Anyone touch anything?  Is anyone only a front end developer?  No.  Okay, great.  That doesn't really matter.  It's pretty interesting.  It's a mix, right?  Everyone, you have to touch it all.  So okay.  So let's talk about the workflow sort of and how like what we actually, what I delivered  to Jessica to integrate into clone.  So I found using these static site generators.  I saw there was another talk actually about static site stuff.  I missed.  I don't know if it was there.  It was yesterday.  It was yesterday.  Okay.  Was that the tool, the system?  Was this static site generator?  Yeah.  Okay.  Okay.  There's a ton of them.  I just looked it up.  There's like two, at least two just listings of these things, which is great.  Now, so what is that for those that do not know?  A static site generator is just like some toolkit.  If you need to make entire, a lot of content sites, for example, like if you're trying to  make, if you've got archives of articles and content and streaming videos and stuff like  that, most of the time you don't really need like a rail server side or even a Drupal thing  or a clone or whatever on the back end.  You can just pretty much just dump out.  It's just HTML, right?  It's all you really need most of the time.  But the difficulty is not like serving it because there's just a bunch of HTML.  The difficulty is as someone who's actually producing it and you've got to update the  header because it's like, there's a promotion coming along.  You obviously don't want to go and update 3,000 HTML files.  You don't need PHP.  You could just do with PHP and server side includes and stuff.  That's just weird and lame.  And also then you've got to host it anyway.  If it's just all static stuff, you can just put it on S3 bucket or some host and it doesn't  matter.  It's out of your life.  It's beautiful.  So that lent itself to these kind of front end only bills because I could have the tooling  to not just be playing with plain HTML files and plain JavaScript files and CSS.  I would get the tooling of a somewhat developmenty environment on my end.  But the deliverable was actually a stack of HTML files we could all put online and review  in real life.  And also I had the artifacts of the build that the server side people could then kind  of leverage, which I will get into.  I used one called Middleman.  There's a lot of them three or four years ago.  This is the one that I kind of liked.  It's Ruby-based, which I like.  I like Ruby.  This is some of the stuff that it kind of gives you.  Basically, you can put a bunch of HTML, a bunch of templates.  So ERB, excuse the typo, ERB is like a template language, a Ruby-based template language.  And you can just kind of use your includes and you can loop through stuff and there's  some image helpers.  It just kind of makes it handy.  It gives you a bunch of helpers.  SAS, do people know what SAS is?  Yeah, everyone knows what SAS is, right?  It's like a compiled CSS thing because writing just CSS is kind of a pain and it's not that  great.  So SAS lets you, like, sits on top of CSS and compiles down to it.  This is a really useful, if you're doing a lot of SAS stuff, Compos is a really useful  kind of toolkit that you can use with it.  It just gives you tons of utilities.  Like it will take care of weird server side hacks so you don't have to copy and paste the  same stupid CSS, like seven lines of CSS for your different float fixes or whatever or  vendor prefixes.  It does a lot of that stuff for you.  So this all makes it pretty easy to go about building out this front end because, again,  the end result is just HTML, just HTML at the end of it, but you don't want to sit there  in a big sea of HTML because that's a nightmare.  So it kind of looks like this.  What I ended up with as I'm building this is pretty much a page for every page, an HTML  page for every page.  It's not entirely HTML.  So this is like the layout.  This is like the big master template, basically the header that all the other stuff gets plugged  into.  And it's mostly HTML.  We've got some helpers and stuff like that.  We've got the partial, as I mentioned, which are just shared components that we can use  all across the site.  And a lot of content sites do have that because you've got the authors' bylines on every article.  If you've got seven variations of the article, you don't want to actually be copying and  pasting the HTML.  One, because it's a headache for you as a developer.  Two, it's a jerk move to the people that are implementing it because they've got to  go fish out the same HTML 100 times and try and just, I don't want anyone looking at it.  Being like, is this footer indented differently on page X than page Y because it's a different  footer or just because he forgot to tab it?  So this way you can kind of mandate, like, just trust me, this is the same markup.  You can use this everywhere we're using a footer.  This is the footer.  So it gives you some amount of organization that's nice.  You have directories for things.  People like directories.  You put your fonts in one thing and your image is something else.  And you can kind of build that.  So this is like the live site.  Just for navigation purposes, we generally have a table of contents.  So when we host this thing so everyone can review it, it's client review time, we can  be like, okay, everybody, go to the staging server and let's review the music episode  page.  Everyone can go and click on it.  It's an easy way to make sure everyone's on the same page.  I find it's helpful to version the directories.  So the person that dialed in three days ago, they pulled up on their Amazon Kindle or whatever  they're reviewing it.  They're not looking at the three-day old version.  We just, otherwise, you go and be like, hey, please clear cash and reload.  And that's a pain.  So version of these things, host them.  You guys can see them and everyone kind of gets a little taste of what, how the thing  is actually going to work, which makes reviewing it easier.  It makes like, it just makes feedback easier because otherwise you've got these JPEGs and  you've got a slider and you've got a carousel on there and no one really knows how it's  going to work.  And you go through all the effort to build this carousel out or some like inane thing.  And the client's like, I don't like it sliding like that.  I want it to slide like this.  And then you've got to go back and code it again.  So this way, if it's out the gate, it's a working prototype.  You just are farther along that approval flow and you spend less time looking back around  because there's less surprises.  Especially if you were starting the prototype stage, there's like no real room for the client  to be like, I didn't know this thing was a vertical thing.  I thought it was a left to right, I don't know.  Whatever, you know, whatever stuff miscommunications happen.  If you've got a working kind of prototype, it just makes it easier.  So this again is an example of using the shared code thing.  It's easier for me because I've got a little blog post kind of a module and I don't want  to be copying and pasting that code 100 times.  Plus for the sake of the visual, sake of the review experience, the content's got to differ  because we have to show like what happens if there's a blog post, you've got five blog  posts in a row.  What happens if one of them, you know, has 300 characters in it?  What happens if one of them is like, I don't know, has some other blur on top of it or  something like that?  It's all, but you don't want to just keep copying and pasting that.  So that ends up looking like this.  This was like a standard like module and we could show like this is like if there's an  audio player, it's going to look like this, you know, you got what this looks like, right?  And it just kind of provides that framework so you're not actually doing that and then  other people that have to implement it come along and they see like, oh, clearly there,  there's no question.  Every blog post overview is going to look like this and granted, yeah, in the code like  if there's an audio player, this markup has to be kind of emitted, but it's not on anyone  to guess it.  It's like it's not a formal, it's not a formal proof of like how anything works.  It's just all a suggestion, which is kind of a funny, it's kind of a weird thing to  be providing this markup and being like, I swear this is pretty much how it's going to  work in the browser, but it's still on you to actually make it happen in the browser.  So especially as it gets to its launch, like things are going to change and maybe blown  or whatever you're working isn't really going to want you to do a certain thing.  So in the best case, you get the stack of HTML and it's kind of like a suggestion.  It's like you really ought to do it like this.  Like we know it works good in the client approved it, but it's up to you how you want to do  it.  So we can even click around a little bit just like for the sake of it, because why not?  Can I open this?  No.  I can't even get out of this thing.  Let's see.  How do you do this?  Great.  So, there we go.  Right.  So this is just the thing of, this is what we delivered.  This isn't what necessarily went live, but it's an example of like how we built out almost  everything as if it was going to be a real thing.  So we've got our spinning music player.  You have to make a lot of assumptions.  This thing is technically, technically we wired it up to be a player.  Like it went through the trouble of making sure you could drag and drop it, making sure  the timer is ticking, making sure there's a mute state and always we just work is then  as far as the interface goes, nothing is left to interpret when it comes time to do it.  If you're good, you can sneak in some Easter eggs.  This card will let us get away with this for a while, but we got a, I think it's not there  anymore, but I think we got the Konami code in here too.  It looks like, got my spinning egg in there.  Because it's like an actual Easter egg.  It wasn't my idea, but I'm like, they're like, do you think we have time to put in the spinning  egg?  And I'm like, I think so.  I think we can make that happen.  So this is cool because everyone just, you know exactly what the music player is going  to look like.  You know how the progress indicator works.  It's not bulletproof because it's not a real player.  And the more like complex the functionality gets, kind of the goofier the prototype gets  because I really have no, I don't even know if the media player can stream in this way.  Like it might turn out just not to work at all, but it's like a best case scenario.  You get this kind of working functional thing.  The client likes it because they understand it.  They're like, yeah, this is what the media player should look like.  The implementers kind of get a sense of it too.  And the design, most importantly, the designers can sweat it out to their heart's content  because as I'm sitting in the middle here, like the designers are also my client as well  because I'm a freelancer.  So Hart Canny-Shell was my client.  Like the KCRW is technically, but like in my mind, my clients are the designers that  I'm trying to, you know, I have to please them.  So they're not like this guy's not giving us any support because we're trying to make  this thing look good.  It's got to be good.  It's got to build good.  So this guy's got to do it.  But I also know in the back of my mind, my client is the plowing people in this case  because I can't really in good conscience build a crazy unworkable thing that is only  going to work on like the nightly safari built because that's just like, that's just like  not, it's not fair.  I don't know.  No one's going to be happy with that because then the client's finally going to get it.  KCRW is going to have this thing and the designers are going to be like, well, it worked  in your demo.  I'm like, well, it worked in your demo because you have like the 10K screen.  Like it doesn't work for anyone else.  So you kind of got to be like that sense of reality, being like, this is awesome.  Like what you're suggesting is awesome.  Like there's no real time blurs not going to work.  It's cool.  It's working in our like real prototype.  And it's cool.  You found an example of a CSS online, but like I'm not letting that go into like production  code.  So you kind of got to be the bad guy too like that when you're in this position.  So it's useful.  It's useful because everyone just like gets what gets what's happening here.  I highly recommend it.  What else we got here?  I don't know.  Stuff.  We got stuff.  Let's go back to the slides.  There's just a little bit about like the beauty of kind of doing this thing, this prototype.  Like you could, I know a lot of people will forgo, depending on the technical chops of  the design shop, they might forgo doing a lot in Photoshop or sketching.  Whatever they're doing at all and just jump right into prototypes in the browser, which  is great because then you're really, you, I mean this isn't like novel.  This isn't a brilliant observation I'm going to make.  Other people have written books about it.  Like this people's lives, like the prototyping workflow.  But you get a lot more out of that kind of thing because everyone's looking at a working  thing immediately.  You don't go down a weird rabbit hole of someone's fantasy that only works in this strange limited  resolution in Photoshop.  And like, it's like, well, it worked on my browser.  Like so many times I'll get a design and I'll be like, well, what happens to the browser?  It's wider.  They're like, oh, what, I mean, like, you, the browser gets wider?  Yeah, there's just these implications and you have to fight those things.  You deal with those immediately when your thing's in the browser and they can't like hide from  it because a lot of times when it's just a design file, they can kind of just dodge the  bullet a little bit.  They can be like, I don't know, like, that's your problem, you know?  And sometimes I can say like, well, it's the implementer, it's the clone people's real  problem but I don't want to do that.  So you kind of have to fight it out.  You kind of got to get it done earlier.  You see pretty easily like design decisions are going to be actually just stupid.  Like, say a fixed header in theory with a certain rollout effect, say it's like, it  sounds really cool.  It's like, oh, as you scroll, you see like the, I don't know, something spins or something  as you scroll all the stuff.  Like, oh, it's really useful and awesome.  Then you can see it in the browser, it's just like, it's garbage, just distracting and a  nuisance.  You can throw it out and you haven't sunk hours into designs and hours into like multiple  responsive versions of it just to find out that it's going to be an unhelpful feature.  The client likes it too because they can sit at home and look at it in the computer, which  is dicey too because you don't want the client to play with the markup that's not fully vetted  for too long.  So if you give them markup of a prototype, you got to take it offline immediately after  the meeting.  So otherwise it's going to be emailing, because otherwise it's going to be emailing it around  and they're going to be looking at it on their, on their Kindle or something like that, some  crazy thing that's just not ready for production.  So you've got to, you've got to, there's a lot of like, hand holding I guess, like you  are, yes, this is working in the browser, but this is not, just because it's in the browser,  this is not what's going to be on the website.  Like, just look at this, just look at the header.  Do you like this font?  Like, okay, good.  This is the way it's going to look, but leave it alone, but you can't hit it that hard.  And again, like, when you have the markup and the thing launches and the slideshow is  just broken or the hover effects don't work or the loading indicator is off to the rider  in some stupid place, then I can blame the clone people, the implementers, can be like,  look, I know the designs, like the designs weren't really that big, this didn't happen,  but in theory.  I'm like, look, the CSS is here, like the markup is here, like technically, like technically  you know how this thing is supposed to work, you know on mobile, like we have the momentum  figured out, like we have that easing animation that we had to sweat out with the designers,  like that's working in the browser here.  Like how come it's not working in the production thing?  So that's something you can kind of, you can't really, no one can fake a certain amount of  it or say, I didn't understand it or I didn't know it.  When you've got the actual markup.  I'm trying to think what else we got.  That's it.  That's all I got.  Are there any questions?  About the Internet?  But yes, sir.  I feel like a bunch of my questions are probably like group questions, like structurally and  how close did what you guys launched with, you know, like how much did the code change?  It might be useful for you to just do a two minute.  Yeah, that'd be awesome.  Because it's not like it's both of us.  Yeah, yeah.  Yeah, okay.  It looked great.  When it launched, it was like that's exactly it.  Except for like things that like I knew, like everyone knew was going to change, like  the streaming implementation, no one knew how that was going to go.  Right.  So what we got from that was perfect for what we needed.  That's nice.  There's the middleman setup, which you know, it's ERB, it's Ruby templates, it's a little  weird for us by now because it's a templating language, right?  And there was a SAS setup, there was all this stuff.  We just took that index.html that you saw there.  The one that generated version, so the compiled version where all this stuff they'd get and  pull back.  Where there were low module elements, we pulled that up.  We made that a D-AZO thing.  The compiled CSS, they came out of SAS and composed, put in a D-AZO thing.  The D-AZO thing sounds awesome by the way.  That was like super impressive.  I wrote one of the email again.  You can just take a regular markup and make the CMS understand it.  Is that what you're telling me?  Yeah.  More or less?  Yeah, you take the markup and you have this intermediate thing that takes the CMS markup  and your markup and uses rules to put the CMS content into your markup.  And so that's what we did.  And we continue to this day, for the KCRW site, which I do kind of maintenance on and  new development, to use that middleman tool to build our theme as we make changes to  it.  So we can test out frontend changes, prototype them in the static site generator, which we  keep using.  And we're working from that same repo, we just have a branch on it that we use for the  production site.  And just continue making these changes.  It generates sprites for us.  It compresses all the images.  It does some special Ratne image thing for all the team images.  Right.  It just does all of this great, magical, wonderful stuff that us back-end developers don't normally  think about.  And then that's the D-AZO theme.  It gets you sort of the wrapping of the site.  And then for the dynamic things like this, in some cases, these are tiles, in the clone  sense of tiles.  There was already a piece of HTML behind this that she put data into.  Right.  So we just took that little modular snippet of code that was called like show.showmodule.erb  or something like that and turned it into a ZPD and made it a tile and rendered it with  a content provider.  And so we already had these little HTML snippets that we could turn into ZPD and put a little  class behind.  And so we have all these modular things that we can place wherever we need to in the page.  Sometimes they'd be affordly.  But either way, we've got the HTML already for them.  All the CSS is being built with this static site generator.  And so we use that pretty much unmodified.  There are a few, what we did do is we went into, we're using collective.cover for our  sort of flexible page layout engine because it wasn't around at the time.  And so we had to add like a custom grid layout engine because it's got some portable grid  layout.  To use the grid layout, it was implied here by the CSS and all that.  And we probably could have done it the other way around and modified all of his stuff and  the grid that it used.  But why?  That's the point.  Because we already sweated it all out.  So the hope is that it's workable enough.  And it sounds like, to bring back to Plone, I guess, it sounds like you're able to do  that.  I think if I gave this to like a word, I don't know, what's the laughing stock of CMSs from  the Plone point of view?  What do you all make fun of?  It's probably word pressing.  That's pretty much it for everyone.  I would imagine it would be unpleasant to try to bend this around.  I'm sure it's doable.  People do whatever they want.  But I imagine it would be unpleasant.  But it sounds like you were able to, Plone, was variable enough that you made it happen.  We did our best.  Yeah.  It worked.  It worked.  It was, you know, most of the difficulties had nothing to do with, sorry, most of the  difficulties had nothing to do with the front end itself.  It was more about the logic of getting things and fetching things and what shows and pages  of the design process fit in place where this other thing was.  And just abandoning functionality that it turned out to be cut to four.  Yeah.  Yeah.  A lot of times when we were building it out in the design size, the designers have these  big ideas that they invented when they were like, out for drinks with the client.  And then it comes to me to build it out.  And I'm like, I don't know if this is going to happen.  I don't know if this is technically feasible if they had this data even.  Or if they can stream it like that.  Or if you can hop around like, I don't know if the audio servers support this.  But still, again, like there's like a funnel of feasibility as it goes through the layers  to like the final implementers and what the servers are running on and stuff like that.  Where is it hosted?  They have their own ops?  Yeah.  We host everything on AWS so I managed the ops.  Okay.  So, yeah.  Anybody got another question?  Great.  Any clones CSS trickling through or is it all?  That's a good question.  What's the question here, Peter?  How much of clones CSS ends up impacting the design here?  We minimize it.  So I think there's like one or two CSS files from clones that we call in through the resource  registry.  The theme itself is coming through DS.  We don't register any of the themes CSS.  Theme CSS is one huge CSS file that gets compiled basically.  So the clones CSS is in there.  Most of it is only there for logged in users.  The only logged in users are the content managers.  But yeah, they edit in the theme UI.  So the UI you see when you visit kcrw.com.  That's what they edit in and it's got the green editor on top.  So there's a clone with the music player on top.  A bunch of past-of-blocks and tiles and things.  A lot of tiles.  A lot of blocks.  There's a lot of modules in this thing.  Yeah.  Oh yeah.  They shared.  So Doug just popped this up.  These are the modular elements that he developed for us that we were able to use in various  places and reuse.  There's like a million of them.  There's so many.  There's so many.  This site specifically feels like I had a lot of tiny content chunks that just spread out everywhere.  Right.  And a lot of these popular episodes, that's a module but it's filled with a whole, it's  filled with one other module.  Yeah.  And it shows up multiple times.  I mean, it's just like template reuse.  It's nothing crazy.  But this is like, this just helped us organize it.  And how it's ultimately implemented.  So it's like, oh, but it sounds like having it cut up like this ahead of time at least  gave some kind of guidance for how you folks might share it.  Yeah.  Absolutely.  Seeing that like looking within say the home page and seeing that there was just a one line  that said, build look at this module.  Right.  It's a clue that we're going to need to build a reusable module for that purpose.  And so, yeah, I think a good takeaway from this is like building something in a static  environment like that.  So it's a really helping thing.  What goes into pages and how to use that.  Cool.  How's it?  Anything else?  Great.  Great.  You got it.  Thank you.
Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_0_71.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_72_167.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_168_1127.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_1128_1307.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_1308_1403.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_1404_2351.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_2352_2855.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_2856_3335.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_3336_4175.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_4176_8003.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_8004_8183.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_8184_8399.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_8400_8507.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_8508_14171.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_14172_14459.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_14460_16319.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_16320_18419.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_18420_20855.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_20856_21755.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_21756_23723.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_23724_24347.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_24348_24695.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_24696_24743.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_24744_24791.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_24792_25031.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_25032_29315.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_29316_29375.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_29376_29423.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_29424_29507.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_29508_29627.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_29628_34727.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_34728_35147.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_35148_36191.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_36192_36239.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_36240_36311.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_36312_36371.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_36372_38735.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_38736_38867.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_38868_39491.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_39492_39623.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_39624_40043.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_40044_45059.png Day_3__Designing_for_a_Strange_CMS__by_Doug_Pfeffe_02mRt3LJZjA_45060_47068.png
My name is Doug Feffer. We'll be talking about a front end build that ended up sitting on top of Plone without knowing anything about Plone. I'd know nothing about Plone. Oh, this thing's not going to work, huh? Oh, it's a line of sight thing? Yeah. Maybe it just doesn't want to work. Well, okay, that's fine. Okay, I'll stay over here. Yeah, it worked like when we first hooked it up. That's all right, we will survive. No, that's all right. That's a little too needy. I can do that. Oh, there we go. Okay, cool. All right, back to Plone. Don't know anything about it. Still don't, except that I looked it up the other day when this thing came up in my email box. So I've done a lot of front end only work, front end work, a lot of server side stuff, mostly custom builds, rarely had to use CMS in any sophistication. Occasionally, I had to use WordPress for something that was kind of unpleasant. So I'm not, it's kind of new to the world of, you know, getting deep into CMS things. And I certainly never did a high level like integration effort like a big custom site would require. So what we did, I was working with a company at the time called Hard Candy Shell, it's a design strategy company. They do a lot of app work and big content site redesigns. They did the slate rebranding redesign, which a lot of people had opinions about New Republic, a bunch of things like that. The next thing, probably what we're talking about right now, which was the KSDRW website. And KSDRW, for those that do not know, it's kind of a big West Coast music institution, a lot of live bands come through and they radio head does like a thing there and stuff like that. People like them, pretty like legitimate in that world. And but the website was kind of a weak, like kind of old fashioned, just homemade, like a local radio thing. It didn't really have the backbone that like a nicer musical kind of platform should have. So Hard Candy Shell was contracted to kind of rebrand it, kind of reposition it, redesign it, shuffle the content around. And we really made it, or they, I'm not the designer, they just, you know, did their whole discovery phase thing and they were out there. So they had the new Look and Feel and they worked with a branding company to come up with a new actual brand and we lost that one and ended up looking like this, which was just much nicer, right? And a big emphasis on this thing was like, it was a real rich media player experience. The idea was like it's not like a blog, readers reading about the fact that Radiohead came. It's like Radiohead was there and there's all these archives, interviews and things like that. So you should be able to go back and listen to the live show, which they always have, but also dig into all their archives they got. So that was kind of the premise of that. And what I was doing with Hard Candy Shell at the time was a lot of these companies, a lot of these design companies, their deliverables after the end of all its research process and working with designers and the brand people, their deliverables to their clients, in this case, KCRW, might have been just Photoshop files. This is like four or five years ago. This is much more common. They would just give these companies Photoshop files and be like, yeah, this is what the website should look like. There's a hover effect probably, you know, figure it out. Here's a slide show also. You can also figure that out. And so we would drop these things off, or the designers would drop these off with the client and these CMS people or database people, whoever, their dev team, would that be on the hook to kind of tease out the interactions from just these comps, which doesn't work. It barely worked before, especially doesn't work now, because you have to take responsive stuff into account. People want things to touch and slide right. And there's just like too much to convey if you just give someone like a big JPEG. So what we started doing, what they started doing was trying out, really building out, like more than our prototype, it was like really building out the whole front end shell sort of, complete with all the hover effects, interactive effects, and responsive processes, and kind of faking all the different interactions in the client, in the browser, so everyone could take a look at it and see it on their phones, see it on their big screen, small screen, look at it on their web TV, whatever. And you get a much better sense of like how this thing is going to work. And also the people that are actually on the hook to implement it, in theory it saves them a little bit of work. The jazz cart of folks might think otherwise, but in theory, like, in theory it saves them a little bit of work because they don't have to actually then go pull in front end guys to figure it all out. They don't have to sit down and hash out the structure because it's already been done. And technically, you know, if I did my job okay enough, all the cross browser stuff was mostly sorted out and everything that was like, how to be plugged in was like mostly ready to go. That's what we got. That's kind of, that was the gist of it. So what I was tasked with was building out this front end for this thing and I didn't know anything about what was going to be actually, how this thing was supposed to run, how this thing was supposed to operate. Yeah, I had no idea Plone was behind it. I didn't know what was going to be behind it, but it wasn't really my problem, which is kind of a weird position to be in because I also, as a server side developer, sometimes I'm going through the front end and I'm just like, I guess this is how the data is going to work. I assume like, I assume that there's going to be some kind of response comes back when you sign up for this thing. So like a lot of times for the sake of the demonstration and the feeling, I had to fake a lot of like load times and submissions. Like this newsletter sign up button, just some jQuery. I kind of had to like fake a loader and stuff and fake this kind of confirmation message that would come back. And it was just full of comments like, you know, server side folks, this is where you're actually going to want to hook into some kind of API. This is going to be some JSON or some XML is going to be coming back. I'm going to get good luck with it. And I felt a little funny about doing that because I'm like, well, someone's got to figure that out. But it's, again, in this case, luckily it turned out and this is the magic of Plone. Apparently it was just fine because the website works really good. We're just like the demo is supposed to do. So an odd thing that comes with doing these kind of front end like blind front end mockups is you have a lot of this kind of place to hold the code where you just like, we're just like, yeah, this should really do something. Put a loader indicator on there and just, I don't know, you know, toss it over the fence and someone else is going to figure it out. And I guess it works out. I kind of always was wondering if I was going to get jumped by the server side people because they had to deal with all these assets and JavaScript and piles of garbage that had to send over to them to figure it out. But it seems to be okay. So thanks, guys. So that was a weird thing. It just, that's like a weird thing. I don't know if, are you all front end developers or you all clone developers? I don't know. Anyone touch anything? Is anyone only a front end developer? No. Okay, great. That doesn't really matter. It's pretty interesting. It's a mix, right? Everyone, you have to touch it all. So okay. So let's talk about the workflow sort of and how like what we actually, what I delivered to Jessica to integrate into clone. So I found using these static site generators. I saw there was another talk actually about static site stuff. I missed. I don't know if it was there. It was yesterday. It was yesterday. Okay. Was that the tool, the system? Was this static site generator? Yeah. Okay. Okay. There's a ton of them. I just looked it up. There's like two, at least two just listings of these things, which is great. Now, so what is that for those that do not know? A static site generator is just like some toolkit. If you need to make entire, a lot of content sites, for example, like if you're trying to make, if you've got archives of articles and content and streaming videos and stuff like that, most of the time you don't really need like a rail server side or even a Drupal thing or a clone or whatever on the back end. You can just pretty much just dump out. It's just HTML, right? It's all you really need most of the time. But the difficulty is not like serving it because there's just a bunch of HTML. The difficulty is as someone who's actually producing it and you've got to update the header because it's like, there's a promotion coming along. You obviously don't want to go and update 3,000 HTML files. You don't need PHP. You could just do with PHP and server side includes and stuff. That's just weird and lame. And also then you've got to host it anyway. If it's just all static stuff, you can just put it on S3 bucket or some host and it doesn't matter. It's out of your life. It's beautiful. So that lent itself to these kind of front end only bills because I could have the tooling to not just be playing with plain HTML files and plain JavaScript files and CSS. I would get the tooling of a somewhat developmenty environment on my end. But the deliverable was actually a stack of HTML files we could all put online and review in real life. And also I had the artifacts of the build that the server side people could then kind of leverage, which I will get into. I used one called Middleman. There's a lot of them three or four years ago. This is the one that I kind of liked. It's Ruby-based, which I like. I like Ruby. This is some of the stuff that it kind of gives you. Basically, you can put a bunch of HTML, a bunch of templates. So ERB, excuse the typo, ERB is like a template language, a Ruby-based template language. And you can just kind of use your includes and you can loop through stuff and there's some image helpers. It just kind of makes it handy. It gives you a bunch of helpers. SAS, do people know what SAS is? Yeah, everyone knows what SAS is, right? It's like a compiled CSS thing because writing just CSS is kind of a pain and it's not that great. So SAS lets you, like, sits on top of CSS and compiles down to it. This is a really useful, if you're doing a lot of SAS stuff, Compos is a really useful kind of toolkit that you can use with it. It just gives you tons of utilities. Like it will take care of weird server side hacks so you don't have to copy and paste the same stupid CSS, like seven lines of CSS for your different float fixes or whatever or vendor prefixes. It does a lot of that stuff for you. So this all makes it pretty easy to go about building out this front end because, again, the end result is just HTML, just HTML at the end of it, but you don't want to sit there in a big sea of HTML because that's a nightmare. So it kind of looks like this. What I ended up with as I'm building this is pretty much a page for every page, an HTML page for every page. It's not entirely HTML. So this is like the layout. This is like the big master template, basically the header that all the other stuff gets plugged into. And it's mostly HTML. We've got some helpers and stuff like that. We've got the partial, as I mentioned, which are just shared components that we can use all across the site. And a lot of content sites do have that because you've got the authors' bylines on every article. If you've got seven variations of the article, you don't want to actually be copying and pasting the HTML. One, because it's a headache for you as a developer. Two, it's a jerk move to the people that are implementing it because they've got to go fish out the same HTML 100 times and try and just, I don't want anyone looking at it. Being like, is this footer indented differently on page X than page Y because it's a different footer or just because he forgot to tab it? So this way you can kind of mandate, like, just trust me, this is the same markup. You can use this everywhere we're using a footer. This is the footer. So it gives you some amount of organization that's nice. You have directories for things. People like directories. You put your fonts in one thing and your image is something else. And you can kind of build that. So this is like the live site. Just for navigation purposes, we generally have a table of contents. So when we host this thing so everyone can review it, it's client review time, we can be like, okay, everybody, go to the staging server and let's review the music episode page. Everyone can go and click on it. It's an easy way to make sure everyone's on the same page. I find it's helpful to version the directories. So the person that dialed in three days ago, they pulled up on their Amazon Kindle or whatever they're reviewing it. They're not looking at the three-day old version. We just, otherwise, you go and be like, hey, please clear cash and reload. And that's a pain. So version of these things, host them. You guys can see them and everyone kind of gets a little taste of what, how the thing is actually going to work, which makes reviewing it easier. It makes like, it just makes feedback easier because otherwise you've got these JPEGs and you've got a slider and you've got a carousel on there and no one really knows how it's going to work. And you go through all the effort to build this carousel out or some like inane thing. And the client's like, I don't like it sliding like that. I want it to slide like this. And then you've got to go back and code it again. So this way, if it's out the gate, it's a working prototype. You just are farther along that approval flow and you spend less time looking back around because there's less surprises. Especially if you were starting the prototype stage, there's like no real room for the client to be like, I didn't know this thing was a vertical thing. I thought it was a left to right, I don't know. Whatever, you know, whatever stuff miscommunications happen. If you've got a working kind of prototype, it just makes it easier. So this again is an example of using the shared code thing. It's easier for me because I've got a little blog post kind of a module and I don't want to be copying and pasting that code 100 times. Plus for the sake of the visual, sake of the review experience, the content's got to differ because we have to show like what happens if there's a blog post, you've got five blog posts in a row. What happens if one of them, you know, has 300 characters in it? What happens if one of them is like, I don't know, has some other blur on top of it or something like that? It's all, but you don't want to just keep copying and pasting that. So that ends up looking like this. This was like a standard like module and we could show like this is like if there's an audio player, it's going to look like this, you know, you got what this looks like, right? And it just kind of provides that framework so you're not actually doing that and then other people that have to implement it come along and they see like, oh, clearly there, there's no question. Every blog post overview is going to look like this and granted, yeah, in the code like if there's an audio player, this markup has to be kind of emitted, but it's not on anyone to guess it. It's like it's not a formal, it's not a formal proof of like how anything works. It's just all a suggestion, which is kind of a funny, it's kind of a weird thing to be providing this markup and being like, I swear this is pretty much how it's going to work in the browser, but it's still on you to actually make it happen in the browser. So especially as it gets to its launch, like things are going to change and maybe blown or whatever you're working isn't really going to want you to do a certain thing. So in the best case, you get the stack of HTML and it's kind of like a suggestion. It's like you really ought to do it like this. Like we know it works good in the client approved it, but it's up to you how you want to do it. So we can even click around a little bit just like for the sake of it, because why not? Can I open this? No. I can't even get out of this thing. Let's see. How do you do this? Great. So, there we go. Right. So this is just the thing of, this is what we delivered. This isn't what necessarily went live, but it's an example of like how we built out almost everything as if it was going to be a real thing. So we've got our spinning music player. You have to make a lot of assumptions. This thing is technically, technically we wired it up to be a player. Like it went through the trouble of making sure you could drag and drop it, making sure the timer is ticking, making sure there's a mute state and always we just work is then as far as the interface goes, nothing is left to interpret when it comes time to do it. If you're good, you can sneak in some Easter eggs. This card will let us get away with this for a while, but we got a, I think it's not there anymore, but I think we got the Konami code in here too. It looks like, got my spinning egg in there. Because it's like an actual Easter egg. It wasn't my idea, but I'm like, they're like, do you think we have time to put in the spinning egg? And I'm like, I think so. I think we can make that happen. So this is cool because everyone just, you know exactly what the music player is going to look like. You know how the progress indicator works. It's not bulletproof because it's not a real player. And the more like complex the functionality gets, kind of the goofier the prototype gets because I really have no, I don't even know if the media player can stream in this way. Like it might turn out just not to work at all, but it's like a best case scenario. You get this kind of working functional thing. The client likes it because they understand it. They're like, yeah, this is what the media player should look like. The implementers kind of get a sense of it too. And the design, most importantly, the designers can sweat it out to their heart's content because as I'm sitting in the middle here, like the designers are also my client as well because I'm a freelancer. So Hart Canny-Shell was my client. Like the KCRW is technically, but like in my mind, my clients are the designers that I'm trying to, you know, I have to please them. So they're not like this guy's not giving us any support because we're trying to make this thing look good. It's got to be good. It's got to build good. So this guy's got to do it. But I also know in the back of my mind, my client is the plowing people in this case because I can't really in good conscience build a crazy unworkable thing that is only going to work on like the nightly safari built because that's just like, that's just like not, it's not fair. I don't know. No one's going to be happy with that because then the client's finally going to get it. KCRW is going to have this thing and the designers are going to be like, well, it worked in your demo. I'm like, well, it worked in your demo because you have like the 10K screen. Like it doesn't work for anyone else. So you kind of got to be like that sense of reality, being like, this is awesome. Like what you're suggesting is awesome. Like there's no real time blurs not going to work. It's cool. It's working in our like real prototype. And it's cool. You found an example of a CSS online, but like I'm not letting that go into like production code. So you kind of got to be the bad guy too like that when you're in this position. So it's useful. It's useful because everyone just like gets what gets what's happening here. I highly recommend it. What else we got here? I don't know. Stuff. We got stuff. Let's go back to the slides. There's just a little bit about like the beauty of kind of doing this thing, this prototype. Like you could, I know a lot of people will forgo, depending on the technical chops of the design shop, they might forgo doing a lot in Photoshop or sketching. Whatever they're doing at all and just jump right into prototypes in the browser, which is great because then you're really, you, I mean this isn't like novel. This isn't a brilliant observation I'm going to make. Other people have written books about it. Like this people's lives, like the prototyping workflow. But you get a lot more out of that kind of thing because everyone's looking at a working thing immediately. You don't go down a weird rabbit hole of someone's fantasy that only works in this strange limited resolution in Photoshop. And like, it's like, well, it worked on my browser. Like so many times I'll get a design and I'll be like, well, what happens to the browser? It's wider. They're like, oh, what, I mean, like, you, the browser gets wider? Yeah, there's just these implications and you have to fight those things. You deal with those immediately when your thing's in the browser and they can't like hide from it because a lot of times when it's just a design file, they can kind of just dodge the bullet a little bit. They can be like, I don't know, like, that's your problem, you know? And sometimes I can say like, well, it's the implementer, it's the clone people's real problem but I don't want to do that. So you kind of have to fight it out. You kind of got to get it done earlier. You see pretty easily like design decisions are going to be actually just stupid. Like, say a fixed header in theory with a certain rollout effect, say it's like, it sounds really cool. It's like, oh, as you scroll, you see like the, I don't know, something spins or something as you scroll all the stuff. Like, oh, it's really useful and awesome. Then you can see it in the browser, it's just like, it's garbage, just distracting and a nuisance. You can throw it out and you haven't sunk hours into designs and hours into like multiple responsive versions of it just to find out that it's going to be an unhelpful feature. The client likes it too because they can sit at home and look at it in the computer, which is dicey too because you don't want the client to play with the markup that's not fully vetted for too long. So if you give them markup of a prototype, you got to take it offline immediately after the meeting. So otherwise it's going to be emailing, because otherwise it's going to be emailing it around and they're going to be looking at it on their, on their Kindle or something like that, some crazy thing that's just not ready for production. So you've got to, you've got to, there's a lot of like, hand holding I guess, like you are, yes, this is working in the browser, but this is not, just because it's in the browser, this is not what's going to be on the website. Like, just look at this, just look at the header. Do you like this font? Like, okay, good. This is the way it's going to look, but leave it alone, but you can't hit it that hard. And again, like, when you have the markup and the thing launches and the slideshow is just broken or the hover effects don't work or the loading indicator is off to the rider in some stupid place, then I can blame the clone people, the implementers, can be like, look, I know the designs, like the designs weren't really that big, this didn't happen, but in theory. I'm like, look, the CSS is here, like the markup is here, like technically, like technically you know how this thing is supposed to work, you know on mobile, like we have the momentum figured out, like we have that easing animation that we had to sweat out with the designers, like that's working in the browser here. Like how come it's not working in the production thing? So that's something you can kind of, you can't really, no one can fake a certain amount of it or say, I didn't understand it or I didn't know it. When you've got the actual markup. I'm trying to think what else we got. That's it. That's all I got. Are there any questions? About the Internet? But yes, sir. I feel like a bunch of my questions are probably like group questions, like structurally and how close did what you guys launched with, you know, like how much did the code change? It might be useful for you to just do a two minute. Yeah, that'd be awesome. Because it's not like it's both of us. Yeah, yeah. Yeah, okay. It looked great. When it launched, it was like that's exactly it. Except for like things that like I knew, like everyone knew was going to change, like the streaming implementation, no one knew how that was going to go. Right. So what we got from that was perfect for what we needed. That's nice. There's the middleman setup, which you know, it's ERB, it's Ruby templates, it's a little weird for us by now because it's a templating language, right? And there was a SAS setup, there was all this stuff. We just took that index.html that you saw there. The one that generated version, so the compiled version where all this stuff they'd get and pull back. Where there were low module elements, we pulled that up. We made that a D-AZO thing. The compiled CSS, they came out of SAS and composed, put in a D-AZO thing. The D-AZO thing sounds awesome by the way. That was like super impressive. I wrote one of the email again. You can just take a regular markup and make the CMS understand it. Is that what you're telling me? Yeah. More or less? Yeah, you take the markup and you have this intermediate thing that takes the CMS markup and your markup and uses rules to put the CMS content into your markup. And so that's what we did. And we continue to this day, for the KCRW site, which I do kind of maintenance on and new development, to use that middleman tool to build our theme as we make changes to it. So we can test out frontend changes, prototype them in the static site generator, which we keep using. And we're working from that same repo, we just have a branch on it that we use for the production site. And just continue making these changes. It generates sprites for us. It compresses all the images. It does some special Ratne image thing for all the team images. Right. It just does all of this great, magical, wonderful stuff that us back-end developers don't normally think about. And then that's the D-AZO theme. It gets you sort of the wrapping of the site. And then for the dynamic things like this, in some cases, these are tiles, in the clone sense of tiles. There was already a piece of HTML behind this that she put data into. Right. So we just took that little modular snippet of code that was called like show.showmodule.erb or something like that and turned it into a ZPD and made it a tile and rendered it with a content provider. And so we already had these little HTML snippets that we could turn into ZPD and put a little class behind. And so we have all these modular things that we can place wherever we need to in the page. Sometimes they'd be affordly. But either way, we've got the HTML already for them. All the CSS is being built with this static site generator. And so we use that pretty much unmodified. There are a few, what we did do is we went into, we're using collective.cover for our sort of flexible page layout engine because it wasn't around at the time. And so we had to add like a custom grid layout engine because it's got some portable grid layout. To use the grid layout, it was implied here by the CSS and all that. And we probably could have done it the other way around and modified all of his stuff and the grid that it used. But why? That's the point. Because we already sweated it all out. So the hope is that it's workable enough. And it sounds like, to bring back to Plone, I guess, it sounds like you're able to do that. I think if I gave this to like a word, I don't know, what's the laughing stock of CMSs from the Plone point of view? What do you all make fun of? It's probably word pressing. That's pretty much it for everyone. I would imagine it would be unpleasant to try to bend this around. I'm sure it's doable. People do whatever they want. But I imagine it would be unpleasant. But it sounds like you were able to, Plone, was variable enough that you made it happen. We did our best. Yeah. It worked. It worked. It was, you know, most of the difficulties had nothing to do with, sorry, most of the difficulties had nothing to do with the front end itself. It was more about the logic of getting things and fetching things and what shows and pages of the design process fit in place where this other thing was. And just abandoning functionality that it turned out to be cut to four. Yeah. Yeah. A lot of times when we were building it out in the design size, the designers have these big ideas that they invented when they were like, out for drinks with the client. And then it comes to me to build it out. And I'm like, I don't know if this is going to happen. I don't know if this is technically feasible if they had this data even. Or if they can stream it like that. Or if you can hop around like, I don't know if the audio servers support this. But still, again, like there's like a funnel of feasibility as it goes through the layers to like the final implementers and what the servers are running on and stuff like that. Where is it hosted? They have their own ops? Yeah. We host everything on AWS so I managed the ops. Okay. So, yeah. Anybody got another question? Great. Any clones CSS trickling through or is it all? That's a good question. What's the question here, Peter? How much of clones CSS ends up impacting the design here? We minimize it. So I think there's like one or two CSS files from clones that we call in through the resource registry. The theme itself is coming through DS. We don't register any of the themes CSS. Theme CSS is one huge CSS file that gets compiled basically. So the clones CSS is in there. Most of it is only there for logged in users. The only logged in users are the content managers. But yeah, they edit in the theme UI. So the UI you see when you visit kcrw.com. That's what they edit in and it's got the green editor on top. So there's a clone with the music player on top. A bunch of past-of-blocks and tiles and things. A lot of tiles. A lot of blocks. There's a lot of modules in this thing. Yeah. Oh yeah. They shared. So Doug just popped this up. These are the modular elements that he developed for us that we were able to use in various places and reuse. There's like a million of them. There's so many. There's so many. This site specifically feels like I had a lot of tiny content chunks that just spread out everywhere. Right. And a lot of these popular episodes, that's a module but it's filled with a whole, it's filled with one other module. Yeah. And it shows up multiple times. I mean, it's just like template reuse. It's nothing crazy. But this is like, this just helped us organize it. And how it's ultimately implemented. So it's like, oh, but it sounds like having it cut up like this ahead of time at least gave some kind of guidance for how you folks might share it. Yeah. Absolutely. Seeing that like looking within say the home page and seeing that there was just a one line that said, build look at this module. Right. It's a clue that we're going to need to build a reusable module for that purpose. And so, yeah, I think a good takeaway from this is like building something in a static environment like that. So it's a really helping thing. What goes into pages and how to use that. Cool. How's it? Anything else? Great. Great. You got it. Thank you.
know nothing about Plone. Oh, this thing's not mostly custom builds, rarely had to use CMS in out there. So they had the new Look and Feel and was doing with Hard Candy Shell at the time was a Canny-Shell was my client. Like the KCRW is going to be on the website. Like, just look at branch on it that we use for the production site. turned it into a ZPD and made it a tile and and pages of the design process fit in place