My name is Doug Pfeffer. I'm going to 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. Oh, okay, that's fine. Okay. Let's 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 of any sophistication. Occasionally, I had to use WordPress for something, and that was kind of unpleasant.

So that's kind of new to the world of getting deep into CMS things. And I certainly never did a high-level 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, including a project we're talking about right now, which was the KCRW website. And KCRW, for those that do not know, is kind of a big West Coast music institution.

A lot of live bands come through, and Radiohead does a thing there and stuff like that. People like them. They're pretty legitimate in that world. But the website was kind of a weak, kind of old-fashioned, just homemade, like a local radio thing. It didn't really have the backbone

that 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, they, I'm not the designer, they did their whole discovery phase thing when they were out there,

sorted out 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 it ended up looking like this, which was just much nicer, right? And a big emphasis on this thing was, it was a real rich media player experience. The idea was it's not like a blog where you're just 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, 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, their dev team, would then be on the hook to kind of tease out the interactions from just these comps, which doesn't work. It barely worked before.

It 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 too much to convey if you just give someone a big JPEG. So what we started doing, what they started doing, was trying out, really building out, more than our prototype, was 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 screens, small screens, look at it on their web TV or whatever, and you get a much better sense of how this thing's 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 Carta folks might think otherwise, but 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. Technically, if I did my job okay enough, all the cross-browser stuff was mostly sorted out, and everything that had to be plugged in was mostly ready to go. That's what we got. That was the gist of it. 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. 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's going to work. I assume that there's going to be

some kind of response that comes back when you sign up for this thing. A lot of times for the sake of the demonstration and the feeling, I had to fake a lot of load times and submissions, like this newsletter sign-up button, just some jQuery. I kind of had to 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. 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's supposed to do. So an odd thing that comes with doing these kind of front-end, like blind front-end mock-ups is you have a lot of this kind of placeholder code where you're just like, yeah, this should really do something, put a loader indicator on there and just, I don't 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 they 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. That's just like a weird thing.

I don't know if, are you all front-end developers? Are you all Plone developers? I don't know. Anyone touch anything? Is anyone only your 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 Jez Carter to integrate into Plone. 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 today or it was... It was yesterday. It was yesterday?

Okay, was that the tool, the system? Was this static site generator? Yeah, it's a new one. Okay. Okay, there's a ton of them. I just, we've 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 an 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 Rails server side or even a Drupal thing or Plone 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 it with PHP and server side includes and stuff, but that's just weird and lame. And also 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 like out of your life. It's beautiful. So that lent itself to these kind of front-end only builds 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 kind of a somewhat development-y 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 files, a bunch of templates. So ERB, let's use the typo. ERB is like a Ruby-based templating 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.

SASS, do people know what SASS is? Yep, everyone knows what SASS is, right? It's like a compiled CSS thing because writing your CSS is kind of a pain, and it's not that great. So SASS lets you sit on top of CSS and compiles down to it. Compass is a really useful if you're doing a lot of SASS stuff,

Compass is a really useful kind of toolkit that you can use with it. It just gives you tons of utilities. 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 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, not just HTML at the end of it, but you don't want to sit there in a big C 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 the layout. This is 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 partials 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 your about, like the bio, like the author's byline is 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 the 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 a hundred times.

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, 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 images of something else. And you can kind of build that. So this is the live site.

Just for navigation purposes, we generally have a table of contents. So 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. And here'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 pull it up on their Amazon Kindle or whatever, however they're reviewing it. They're not looking at the three-day-old version. Otherwise you've got to be like, hey, can you please clear cache and reload? And that's a pain.

So version these things, host them. Everyone gets to see them. And everyone kind of gets a little taste of how the thing's actually going to work, which makes reviewing it easier. 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 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 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 stuff, miscommunications happen. You've got a working kind of prototype that 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 visual sake of the review experience, the content's got to differ because we have to show what happens if there's a blog post. You've got five blog posts in a row. What happens if one of them 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? You want to show it 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 module, and we could show if there's an audio player, it's going to look like this.

You've got what this looks like, right? And this 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's no question. Every blog post overview is going to look like this, and granted, yeah, in the code, if there's an audio player, this markup has to be kind of omitted,

but it's not on anyone to guess it. It's not a formal proof of how anything works. It's just all a suggestion, which is 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. Especially as it gets towards launch, things are going to change, and maybe Plone 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. We know it works good when 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?

So there we go. 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 how we built out almost everything as if it was going to be a real thing.

So we've got our spinning music player, and you have to make a lot of assumptions. This thing is technically, technically we wired it up to be a player. 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 all these widgets work, because then as far as the interface goes,

nothing is left to interpret when it comes time to do it. And if you're good, you can sneak in some Easter eggs. And Jess Carter let us get away with this for a while, but we've got, it's not there anymore, but I think we've got the Konami code in here too. It looks like, got a nice 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 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. 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 most importantly, the designers can sweat it out, so their heart's content. Because as I'm sitting in the middle here, the designers are also my client as well, because I'm a freelancer. So Heart Candy Shell was my client. The KCRW is technically, but in my mind, my clients are the designers that I'm trying to,

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 the nightly safari build,

because that's just 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 designer's going to be like, well, it worked in your demo. I'm like, well, it worked in your demo, because you have the 10K screen. It doesn't work for anyone else. So you kind of got to be that sense of reality,

being like, this is awesome. What you're suggesting is awesome. The real-time blur's not going to work. It's cool. It's working in our real prototype, and it's cool you found an example of the CSS online, but I'm not letting that go into 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 gets what's happening here. Highly recommend it. What else we got here? I don't know. Stuff. We got stuff. Let's go back to the slides.

Just a little bit about the beauty of doing this thing, this prototype. 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 Sketch,

whatever they're doing at all, and just jump right into prototypes in the browser, which is great, because then you're really... 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. This is 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 it's like, well, it worked on my browser. So many times I'll get a design, and I'll be like, well, what happens if the browser's wider? They're like, oh, the browser gets wider. Yeah, there's these implications, and you have to fight those things. You deal with those immediately when you have things in the browser,

and they can't 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. That's your problem, you know? And sometimes I can say, 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 design decisions are going to be actually just stupid. Like, say a fixed header in theory with a certain roll-out effect, say it sounds really cool. It's like, oh, as you scroll, you see, I don't know, something spins or something as you scroll, all this stuff. Like, oh, it's really useful and awesome. Then you can see it in the browser.

It's garbage. It's distracting and a nuisance. You can throw it out, and you haven't sunk hours into designs and hours into 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 a markup that's not fully vetted for too long. So if you're going to give them markup of a prototype,

you've got to take it offline immediately after the meeting, because otherwise it's going to be emailing it around, and they're going to be looking at it on their Kindle or something like that. It's some crazy thing that's just not ready for production. So there's a lot of hand-holding, I guess.

Yes, this is working in the browser, but just because it's in the browser, this is not what's going to be on the website. Just look at the header. Do you like this font? Okay, good. This is the way it's going to look, but leave it alone. You can't hit it that hard. And again, 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 right or in some stupid place, then I can blame the ploned people, the implementers. It's going to be like, I know the designs weren't really that big. This didn't happen, but in theory. I'm like, look, the CSS is here.

The markup is here. Technically, you know how this thing is supposed to work. You know I'm mobile. We have the momentum figured out. We have that easing animation that we had to sweat out with the designers. That's working in the browser here. 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. Yes, sir. I feel like a bunch of my questions are probably group questions.

How structurally and how close did what you guys launched with, how much did the code change? It might be useful for you to just do a little two minute. Yeah, that'd be awesome. Because it's not like it's both of us. It looked great. When it launched, it was like that. This is exactly it.

Except for things that I knew, everyone knew was going to change, like the streaming implementation. No one knew how it was going to go. Right, right. What we got from them was perfect for what we needed. That's nice. There was the middleman setup, which, you know, it's ERB, it's Ruby templates. It's a little weird for us, but obviously,

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 versions, so the compiled version where all this stuff had gotten pulled back, where there were little module elements and we just pulled that out. We made that a diazo thing. The compiled CSS that came out of SAS and Compass

put in the diazo thing. The diazo thing sounds awesome, by the way. That was like super impressive. I went through your email again. Did you 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 K0MD site, which I do kind of maintenance on and do development, to use that middleman tool to build our theme as we make changes to it. So we can test out front-end changes,

prototype them in the static site generator, which we keep using. 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 retina image thing

for all the team images. 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 IASO theme. It gives 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. So we just took that little modular snippet of code that was called show module dot ERB or something like that, and turned it into a ZPT, and made it a tile, and rendered it with the content provider.

So we already had these little HTML snippets that we could turn into ZPT and put a little class behind. And suddenly we have all these modular things that we can place wherever we need to in the page. Sometimes they'd be a portlet. But either way, we've got the HTML already for them. All the CSS is being built with the static site generator.

And so we used it pretty much unmodified. There are a few. What we did do is we went into, we were using collective dot cover for our sort of flexible page layout engine because Mosaic wasn't around at the time.

And so we had to add a custom grid layout engine and 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. 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 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 WordPress. 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. And it worked. It worked. 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 on the pages and how these little things that weren't thought of in the design process fit in place where this other thing was. And just abandoning functionality that it turned out they couldn't afford.

Yeah. A lot of times when we're building it out in the design side, the designers have these big ideas that they invented when they were 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 you can hop around. I don't know if the audio server supports this. But still, again, there's a funnel of feasibility as it goes through the layers to the final implementers and what the servers are running on and stuff like that. Where is it hosted? Do they have their own ops? Yeah, we host everything on AWS, so I manage the ops. Okay.

Anybody got another question? Great. Any clone CSS trickling through? What was the question? Can you repeat it? How much of clone CSS ends up impacting the design here?

We minimize it. So I think there's one or two CSS files from Plumb that we pull into the resource registry. The theme itself is coming through DDS, so we don't register any of the theme CSS.

Theme CSS is one huge CSS file that gets compiled, basically. So the Plumb 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 themed UI. So the UI you see when you visit kcrw.com.

That's what they edit in, and it's got the green edit bar on top. So it's Plumb. 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. This site specifically feels like it had a lot of tiny content chunks that just spread out everywhere.

And a lot of these popular episodes, that's a module, but it's filled with a whole, it's filled with four of one other module. Yeah, and it shows up multiple times. It's just like template reuse. There's nothing crazy, but this is like, this just helps us organize it, you know, and how it's ultimately implemented, I don't know, 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 homepage and seeing that there was just a one line that said build look at this module. It gave us a clue that we're going to need to build a reusable module for that purpose.

And so yeah, I think a good take away from this is like building something that's that exciting, generally, like that big thing. That's it. Anything else? Great.

You got it.