Thank you. Good afternoon. How did you like Mathias's talk? Good? I enjoyed that. [applause]

He is one of the smart people that always make me feel stupid, so I guess that's good. Before I start, I would like to share something with you that has nothing to do with my talk. Is that OK? Every once in a while, you come across something on the web that just kind of gets you angry, and makes you realize why you're doing the work you do.

I think everyone here, in your own little way, you're trying to make the web better, or at least do the work you do as well as you can, but I don't think everyone who works on the web thinks the same way. This is something I came across, and I'll explain it to the people who don't understand Dutch. Last week, I went to Portugal, and I had to do an online check-in. I won't say which airline, because you could probably figure it out for yourself, but...

...Here is a point. This was a page where you get these options that you can choose, because this is an airline that's really cheap, so everything is an option. "Do you want to eat? Do you want to go to the bathroom?" That kind of thing. It says, "After choosing your options, click 'Add the selected items.'" That's this button right here.

And then it says, this is another option, I guess, "Leave the booking as it was," and this says, "On second thought, don't," and this says, "No, thank you." This kind of made me angry, because I thought, "I don't want to do this, so I don't have to click this button. I just want to leave it as it, so do I click on this button, or do I click on that button, and what button does that do? I don't want to do that, can I do that? I... fuck... shit." [applause]

So this is why we do what we do. That had nothing to do with my talk, but it just angered me so much I thought 'Bring you into my anger.'

Four years ago, Andy Clark started talking about designing in the browser. I thought, "That's a bunch of malarkey. Designing in the browser, that's now how creative things work, you can't do that." Basically, he found that it was helpful to his business to start designing in the browser, because the clients were unpleasantly surprised when they saw the difference between Photoshop and the browser.

So a year later, he came up with this presentation, "The Walls Come Tumbling Down." He kind of outlined his idea for designing in the browser. He wanted to come up with a new and better workflow. This was three years ago. Design in the browser, learn to live with the constraints of the web, and then design systems instead of web pages.

He often says we design websites, not pictures of websites. This rings true to me. At that time I really disagreed with him. So this presentation is kind of eating my words from then.

Photoshop is impractical for design mockups, especially now, now that we have responsive design. You'll find that there are a lot of disadvantages to Photoshop comps now, changes are very time-consuming. If you have a static Photoshop comp and the client says "Well, I would like the type bigger. I just want the headlines bigger," you'll have to change each of those individually.

It doesn't matter to me that Adobe is apparently working on something new, and I'm not insulting Photoshop per se. It could be GIMP, it could be Fireworks, or any image editor, anything that's not a browser. It's too much manual work. It just takes way too much time to do. You need Photoshop to be able to do your work. Photoshop costs money. I guess most people could pay for it, but still, it's something you have to depend on.

You're at the mercy of Adobe and what they decide to do, and responsive design means that you won't just have one page. The page will be different sizes depending on the device you're looking at, and you could never really know for sure if the mockups you make for a smartphone in Photoshop are really going to look that way on an actual smartphone, so you're kind of setting yourself up for problems.

This is the reality that we have today. These were screenshots taken with a very useful Adobe tool. I'm not anti-Adobe. This is what formerly Adobe Shadow was, Adobe Edge Inspect, and this is the same website in all kinds of different browsers, actual devices. This application makes actual screenshots on actual devices, which is the best way to test. You could see these different things.

I can't imagine, especially this one here, that you design that, six different things, in Photoshop for one page. What happens when you have several different page types? That's the reality. It's very tough to deal with.

Web technology, on the other hand, is perfect for making design mockups. How many actual just plain designers are in the room? OK, you do nothing else except design? I know Wes, yeah. So there are few. I didn't expect very many at Fronteers, to be honest. How many people are kind of designer, coder, hybrid types? Yeah, a lot more. So this might appeal more to you.

I might actually piss the real designers off, so please don't come and find me at the beer thing, OK? But this is why I think web-based comps are really, really good. It doesn't have to take much longer than Photoshop. There is a little learning curve, because if you're not familiar with HTML and CSS, you have to learn it, but we'll come back to that. That's not a bad thing.

You can automate trivial tasks because developers have this thing. You've noticed that a lot of the talks today are about tools. This is about tools. This is about tools and process. But developers are lazy. They just want to keep coming up with little tools, right? Like Mathias. And they want to make things easier for themselves, so they invest some time to make a tool to make things easier later on.

And that's something that designers really don't get to do, so it's something that we should look at and take advantage of. You don't get much more of a realistic presentation of your web design than you would in an actual browser. Even font rendering issues are something that when the client sees it from the very beginning, they're not surprised when the type looks the same in the browser because they've already seen it, right?

So state changes, hover. Hover is just a basic one, so you don't have to make a layer in Photoshop that implies what the hover should be, but other types of complex state changes. What about logged in versus not logged in, for example? You can show those state changes very, very easily in a web-based mockup.

These are great things to think about. The best thing about these kinds of comps is they can be responsive, so you can make one page design and have it be responsive right away. If you want, you can take screenshots of those, different screen widths. You can test them in browsers.

There are few things more impressive lately than when I go to a client and I use Adobe Shadow, and have some devices, and put them on the table, and invite the client to put his or her devices on the table as well, and then navigate to the page on my laptop, and the page just shows up on all those devices. They can see exactly what the design should look like.

It seems like you're already building the site, but you're not. It's an interesting way to look at it. You'll have to find shortcuts so that it's not like building a static website. If you're smart about it, you could make code which could be used for development, but that's not the goal. Developers are going to write their own code, or they use their own process. So if you can work together with the developers, you can do that, but it's not really necessary. It's just instead of Photoshop.

So, the whole thing I'm trying to say is we should get rid of Photoshop. OK? Don't hurt me. We don't need to get rid of Photoshop completely. Photoshop is great for things like image editing, for example. It's great for creating image assets. I know people who think in Photoshop. I tend to sketch on paper, but other people like to think and play around in Photoshop. That's great. Just consider not using it as a design tool to do a complete mock-up for your clients.

And I think we need two things to replace them. One of them is the mock-up, which I'm not going to talk about today, surprisingly enough, because it's probably one of the big things I could talk about. I'll save that for sometime in the future.

Another thing that we need, next to the mock-up, is a style guide. OK? Oops, style guides. That was quick.

Style guides are a takeover from the print world. Style manuals or branding guidelines or corporate identity guidelines. These are all books, usually. The first one I ever saw when I was in design school was a book from, I think, early '80s. It was from Apple Computer. It was pretty thick, I would say at least two centimeters thick, all the guidelines about anything having to do with Apple.

And the thing about a style guide is it doesn't just show you what's available, like logos and typefaces and things like that. It also tells you when you should use these things, and when you do, how you should use these things. So you use this logo in these cases, at this size, with that much space around it, with that typeface, et cetera.

Everything was described. Grids. It was just incredible. I couldn't imagine anyone liking doing that type of work, until later on, when I became a designer and I started doing some of that work myself, which I still hated to do, honestly.

But there is a good thing about style guides for your team. If you create a style guide and you pass that on to a developer with a mock up, they don't have to go into Photoshop and measure. Because there are a lot of developers here. Who loves that part? Who loves going into Photoshop and measuring stuff? And now you have to measure stuff and you have to think, OK, that's 15 pixels, but it's responsive so now it's got to be percentages, or wait, should it be ems.

Then you have to do all this kind of stupid math and the designer will say well, that's not what I meant. That's not what I designed. Go back and look at the Photoshop thing. Terrible. Stop, OK? State and break point changes can be included. So you can put in a style guide what should a hover look like? What will this look like when you're logged in this block? OK.

It's for designers to remember what they decided upon. It's for developers so that they'll know how to implement these design things. It's for the client. You can write a style guide in a language that's client-understandable, and it's also for anyone else who might come on the team later on.

It also helps you maintain design consistency. So you might've heard about style guides recently because a lot of people talk about them. Anna Debenham had an article on 24 Ways last year about it, and people quote things like Twitter Bootstrap, which I don't consider to be a style guide, I consider it to be a pattern library.

They have all these elements. They don't tell you when to use them and how to use them specifically. It's general, so it can't really be a style guide because it's used for all different types of projects. So here are some. Apple identity guidelines. This is one set of Apple guidelines. There are presumably a lot more. These are for retailers, I guess, resellers. So you get this kind of thing.

This is the logo you should use and how much space in between. And there is a lot of text here. And that's the difference between things like bootstrap and a lot of the pattern primers and stuff that you see today, is that this is just human readable text, which tells you some background information and how to use this and when to use this.

So it's not just putting all the different types of buttons that you have on there, OK? This is a really well known one, the guidelines for the BBC. I think a lot of you have probably seen this. This goes so far as to outline the grids that you should use. It doesn't say exactly when you need to use these grids compared to other ones. It's just like, "This is the grid, and there are different ways to go about using it," and they do describe those. So this is brilliant.

For those who are interested in these types of things, Anna Debenham has this collection, the links up there, I think...Yeah. This is a collection not only of style guides. There are style guides in there, but there are also pattern primers, tools to help you make your own style guide or pattern primer, so if you're interested at all in making style guides, this is a good place to look. It's a pretty good resource.

I went through here, and being the stubborn person that I am, I have specific things that I want in a style guide. They're not that easy to come by. I didn't find any of the style guides or pattern primers that did what I want to do specifically. So first thing is I want this to be free form writable.

If you're familiar with things like Kyle Neath's KSS or Jeremy Keith's pattern primer, you'll know that you have to do certain things in a certain way. It's not that you can just write a document and then have that become a style guide. If you're writing a style guide, the chances are that you're not the one who's going to be doing the writing. You might be the one determining what the design is, but the person who does the design is not always the person who writes the style guide.

Sometimes there is a documentation person doing that or some other type of copy writer who is doing that or an editor. So I wanted it to be free form writable and not that I have to ask some editor to go into a CSS file and in the comments, in a certain comment syntax, write out all the text, which is just ridiculous. I want to use something like Markdown and just have them write whatever they want.

Another thing is that I want to take screen shots of the mock-up that I've made, at different viewport widths, and be able to automatically have those screen shots pulled into the documentation. OK? I'm pretty demanding. Code snippets. When you change the CSS in your mock-up, I want that CSS or the HTML to automatically be updated into the style guide. I don't want someone to have to go in and change the style guide.

So these screen shots should also be updated automatically when something changes. So they should not only be made automatically, they should also be automatically updated. The pattern primer that Jeremy Keith has, which was the inspiration for me thinking about style guides in this way at all, was really interesting to me, except for the fact that you had to split each component of your page into separate HTML files.

And I know you can automate that, but it didn't fit right with me. So, if I made navigation, I would have to have the navigation as a separate HTML file. I would have to split all these things out. So it didn't appeal to me, even though the idea really appealed to me.

I want syntax highlighting for the code. I propose, in the style guides that I do...CSS is pretty readable, actually. It's very human-readable, especially for developers who are used to it. So why not let the CSS tell you what the styling is for an element? Instead of going into Photoshop and measuring things and selecting text and seeing how big the text is, you could see the font size in the CSS.

Why not put the CSS right next to the object that you're describing and have the CSS become the technical part of the documentation? And I want that syntax highlighted, because it's easier to read.

So, is this too demanding? Am I asking too much? This is weird, isn't it? I couldn't find a tool to do this. I couldn't find one tool, because Mathias obviously had not made one. So, what are you to do? And that's this weird thing about these tools. I was introduced to Unix when I was a kid, and I thought it was really interesting because you had these little, just simple applications that did one tiny thing. I thought "Well, that's kind of stupid, just one thing."

But the idea of chaining these things together, which you're all familiar with if you work on a Mac, that can be immensely powerful.So why do we need one tool, anyway? Why not chain a bunch of tools that do their thing well together? Because otherwise, you're going to end up with this:

a sporf. Right? People actually use these. But this is trying to be a fork and a knife and a spoon at the same time. So you can imagine, you can make all these monstrous tools that are part hammer, part nail, part wrench, just crazy stuff. Why? We don't need to do that when we have all these separate tools available. Just put them together, OK?

So I did find one tool that was the basic building block of this whole idea, and that's called Dexy. Dexy, I guess it's a fairly new open-source project. And I've come to know the author, Ana Nelson, who is just brilliant. This is a Python application, and it's just recently changed.

She did that on purpose just to mess me up. So I'm going to show you the old version today, but she has a newer one out. So good luck applying anything I'm talking about, because she said, "Well, I rewrote the whole thing." It's going to be a little bit different.

Dexy is a free-form-writable documentation software application. So you can write something. If you want to show what things look like in a console, you can actually have Dexy do the commands that you have in your documentation in the console, show the console output, and you can also just do all the calculations and everything. You could just run your application and show each section automatically in your documentation. It's brilliant. So I thought, "Maybe I can use this." And that's what I use now for the documentation part. For screen shots, Addy Osmani this morning was talking about PhantomJS. And everyone knows what Phantom is, I assume, now? A headless web browser. Which is cool:

a browser that you can't see, but that you can make do things for you and you can script.

And CasperJS, for me, as not a programmer, just a design guy who tries to do his best with code, Casper is pretty good. It's like the jQuery for Phantom, I guess. What you can do is make a little script that tells the viewport to be a certain width in Phantom, take a screen shot, OK, and then go to another element, take a screen shot of that element, go to another page, take a screen shot of that whole page. You can script all that with Casper. And you could probably do it in a different way, but lazy me, right?

Code and screen-shot updating. I use templating for this, which I'm sure the developers are familiar with. For the designer people here, it's placeholders. If you have an HTML document, you can say, "I want that picture. When that picture exists, pull that picture in and put it right here." So it's placeholders, basically.

So I use this Python templating because Dexy is a Python-based piece of software. I use this templating to pull in the screen shots and to pull in the CSS code that describes the thing in the screen shots. For syntax highlighting, also a Python version of this. And I know that any of you could do exactly the same thing with Ruby if you know this. This is just one syntax-highlighting library for Python, Pygments.

So, what does this all mean? This means that we have to go into the command line, right? As designers. Don't be scared. OK? I don't get it, actually. Why are designers so afraid of the command line? Anyone?

No UI.

I'm sorry? No UI. Well, there is a UI. It's just not a graphical UI, right?

OK. So that's one opinion, that it's not natural. You would like to just drag things around, like a designer would normally do. Yeah, I'll get back to that.

This is the command line. OK? We're not talking about designing right now. We're talking about using a tool to generate documentation. OK? But this is the command line. It's really friendly, right? It's not scary at all. See, there is my name, right there. It's like it's saying, "Hello, Stephen. Good morning. Enjoy your cup of coffee. When you're ready, tell me what you want me to do."

It's kind of like your butler. It's brilliant. I love this. OK? I'm a designer, and I love this. It's simple. It's minimal. And why would you be afraid of the command line if you can work with something like this?

This is Photoshop, right? Let's get in there, a closeup. See that? You know what all that is? Some of you do. If you do, then it should be no problem to learn one or two commands for the command line. OK? You don't even have to remember them. You do what I do, have this little snippet library of things. I always forget how to do SCP, for example. Why is a designer doing SCP in the first place? I don't know.

See? Photoshop. Photoshop has this color space called LAB. And to give you an idea of how complex Photoshop is, just the LAB color space has a book that was made for it, which is huge. It's like 600 pages, for one color space. It's like one menu item in Photoshop. OK? A book, 600 pages. That's complex. In fact, if you use Photoshop, you're using one of the most complex and sophisticated pieces of software that have been made for consumers. OK?

The command line is not a scary thing. See? Look. That. That. See? [ applause]

OK? So it's very friendly.

The command line does have some problems. So, give me a chance to grab a glass of water. How does this process work that I'm describing? By the way, I'm describing a process to you that I've developed out of necessity over the past two years. I talked at Mobilism about my responsive-design workflow, which is my answer to the problems I had in designing for the responsive world that we live in right now.

So, this is just one of the steps in that workflow. I am working on a book, which should come out sometime around March, which describes this whole workflow. But just because I'm writing a book about it and talking about it here doesn't mean that I'm right. It doesn't mean that it works for you.

It's just my way of doing things, and hopefully you'll get at least one thing out of this that you might think, "Hey, that's a cool idea. I would like to take that and do my own thing with it." Because that is the whole idea. It's not like this is a workflow you should follow. It's just my thing. OK?

So what we do here is we just take an HTML and CSS mock-up and then take screen shots of that, code snippets out of the CSS. Someone else, or me, it depends, writes a style guide in Markdown, with templates, with placeholders in there, for pulling in the screen shots. And then those things are combined by Dexy to become the style guide.

When you go through these steps, it looks like this. You just create your web-based mock-up, which is using HTML, CSS, and JavaScript to make the same thing that you would make in Photoshop, only now you're doing it in a browser. And it seems like it takes a long time, until the client comes with changes and you only have to change one line of CSS, compared to a half a day in Photoshop manually changing things and then moving them around the screen because something had to become bigger.

OK? And doing that for five different files for one page because you're trying to show what it looks like responsively. OK? So this is just so much easier to do.

The CSS that you write for this type of thing shouldn't be production CSS. It could be, but it doesn't have to be. In fact, if you're going to pull out these pieces of CSS, it's better to have redundant CSS, to have things that are repetitive, so that the blocks that you pull out will contain all the CSS that you need for a certain component. OK?

So I like Jonathan Snook's method, SMACSS. Anyone familiar with SMACSS? This is a really good little book. I don't know why he has a lumberjack on the cover, but it is pretty cool. It's about setting up your CSS in a modular way, which kind of fits with the way I put these style guides together. Then you install Dexy and any dependencies that you might have, Phantom and Casper.

This kind of installation, it's like the things that Addy was talking about this morning. For a designer, that's daunting. You've got to install this stuff, and there are dependencies and stuff like that. This is why I think the way that we've been working in silos...Interaction designer makes wire-frames, gives them to a visual designer, who gets to put colors on top, color by numbers, and then give that to a developer, who then does the developer thing; that's just such a bad, obsolete way of working.

When you're a designer and you want to do something more efficient, that requires tools that you don't know how to install, get together with a developer who would love to show you how to install these things or do it for you.

And developers who want to know something about design should get together with the designers and talk about the things they need from the designer, and interaction designer; the same way. I won't even get into it today, but I think interaction designers should not make wireframes at all, OK? Don't hurt me for that one.

You write your markdown. This is an example. You've got your little placeholders here. This is going to be a button, and here I'm pulling in the CSS for the button. This looks complicated, but five minutes of explanation, and it's not longer complicated, and you'll know exactly how to do it. OK? It's no more complicated than undercover removal or curves in Photoshop.

You script your screenshots in Casper. Now, I am a designer. Do not judge my JavaScript. This is very simple, and what I'll do, to the chagrin of all the Javascripters here, is I'll just repeat. I'll put like 50 Casper then functions in here, right? I'll put one in for each screenshot that I want because it's easier, OK? And it's not going into production, so it doesn't matter, right?

Here is the CSS, and I just marked the sections with comments. This is the button CSS. This is what it looks like when you hover it, OK? And then go into the folder that you want in the command line and type the word "Dexy". I think everyone can do that. And then style guide. Done. Ding. I could do a demo if I have time, but I'm not sure if I have time. Do you want to see a demo?

Yes.

OK. My grandfather said, when I was a kid, "Don't do live demos. Bad things can happen." We'll try it out. Let's say we've got this fantastic web page. Wow. This is our mockup, and...Wait a minute. I'm seeing something you're not seeing. See, that's what I mean. Two minutes into the demo, and...

This is your web page. We're keeping it simple, because there are less things that I can mess up in public. This is a button. Obviously, without the pointer, which I know someone was going to point out. Here is the command line. Let's get that up there. LS means "list," for you designers, you three designers in the audience. LS is "list." You can imagine that BR would be "beer." If I went home...

That would be great, if you could just go home and say, "BR," and the beer would be given to you. I would get the shit slapped out of me. What we've got here is footer and header. Those are headers and footers of the style guide. I want one header and footer. If I have multiple pages, there is no reason to repeat those, so I just have one, and then I have index markdown, which you just saw. Don't laugh that I'm using Vim, please.

This is pretty simple, right? And then we have the screenshots, which you also just saw. Ignore the lint thing. What I'm saying is, make the viewport 800 wide, and then take a picture of that button. If I had more elements, and if it was an actual page, I could take all kinds of screenshots of different elements at different viewport widths, but let's keep it simple, because it's less for me to mess up.

In mockup, I have the HTML file that you just saw here, and the CSS for it. What I'll do now is just set up Dexy, and then run Dexy. Now I've got some other things in this directory, and in output, if we go in there, then you'll see I've got a screenshot of the button, I've got index.html and then the mockup. So what is that index.html? That's the style guide, this should be next to this, but the screen is pretty small right now, and I didn't do it responsively.

The interesting part about this is if we were to go back up and let's say we wanted to change something in our mock up in the CSS. Was it Facides who asked me to use Papaya Whip? It's going to be hard, because in the last conference, I did this talk, I missed spelled the word orange like 27 times.

Those are the types of things that can go wrong. Let's get that out. Then, let's take the border radius out, for fun. So we save that, go back up. Now, we just changed something which means that we want to get rid of the stuff that Dexy did last time. So we did the clean up and then we do Dexy set up. These are really simple commands. Then run Dexy again. Then, you get that. [applause]

This is a very simple example. I like simple examples because I believe simple examples don't introduce a lot of complexity, which detract from what you're learning. So you can imagine, because everyone here is probably smarter than I am, you can do a whole style guide with all these different sections, log in blocks, when you should use them, what should they look like at different screens widths.

And anytime you change anything, whether it's the code or whether it's the element itself, or even complete pages, you can just update your style guide as easy as this. So that's that. Let's get back here, and I'm probably running really late, because Christian's really getting angry. I hear him growling. So it's got a learning curve, but everything does. It's not that bad. You don't have to use everything. You don't have to use any of this. But if you do, you don't have to use everything at once.

There might be one thing that appeals to you, just do that. Just start thinking about how you can make your workflow better and choose what works for you. But just realize that we're in a new time with all different types of devices and we can't even think in terms of smartphone and tablets and desktops anymore, because there are televisions and refrigerators and cars with Internet...Game consoles.

We don't know what we're going to be designing for, so just start thinking about that workflow and seeing what you can change. Have fun with it and keep learning. Thank you. [applause]

Oh god. I've seen it before.

Actually, we don't have much time, so I'm going through the feedback that I got from people, mostly. I loved it last time. I saw it at Smashing Mag. I think it's a good idea, what we're doing here. I think there should be more talks about designers talk about code-y things and coders talk about design-y things, or both of them together, how we work together. And that kind of automation basically means you don't build lots and lots of documentation that nobody reads or wants.

Right.

So, a good question, though, well, except for a lot of people whinging that the CLI is still scary, but you can talk to them in the break, I think. A lot of people said, seeing that you do web-page comps anyways, why not just include the HTML element in an IFrame or something like that rather than generate images?

That's a good question. I actually did that first, because Dexy had no support, itself, for screen shots. So I did have HTML. What I had was I had them, I guess, in iFrames, I think, that I did. So I had all these iFrames in the page. I didn't like it. I didn't like the way it looked, mainly, as a designer. I don't know. I just didn't like that sometimes you would have the scroll-y bits. It was just too much work to tweak.

And also, you would have to split out the files again. So you would have to have all these separate HTML files for the navigation. I guess you could pull them in. I don't know. I'm probably just not much of a programmer to be able to do that myself.

Well, you would have a client that looks at it in IE6 and wonders why there are no rounded corners.

Yeah. I think that's what the mock-up is for. The style guide is to describe how you wanted the design, and the mock-up is to show how the design works in reality. So these two things work together.

One question was, why would a style guide include CSS code? It's just a way of having an element and having the properties that describe what this thing is made of, what font it uses, how big it should be. Developers understand that. You could hide that for clients, for example, and then developers could then just open it up and take a look at it. It's easier to see what the margins should be by looking at the CSS. It's already in the CSS, because you already have your mock-up. So why type that out again, when the developer can understand it just as easily?

So instead of just putting arrows and "This is that much," you just put the code under it and people should understand it.

Yeah. Yeah.

Yeah, that's a good point. A very interesting one here is how do you explain to your client that the mock-up prototype in the browser is not production-ready? Because as soon as I showed stuff to people in a browser, they thought, "Oh, cool. I can reuse 90 percent of that. Why do you need another three weeks to build this website?"

Yeah, exactly. That's one of the big problems. I call that "Presentation psychology." There is a point when you can show a mock-up in the browser, but it's not in the very beginning. So what I do is I make the mock-up and then I take screen shots, and I'll automate those sometimes with Casper and Phantom, or just even take screen shots with your screen-shot tool.

And I'll present the screen shots and I'll say, "These are some pictures of what the design will look like." And then, when they say, "Oh, we like it," then I'll say, "OK, well, we're going to get to work on that, and we'll get back to you with a mock-up."

"Here is my bill." I tried reverse psychology and basically made three really ugly things and one thing that we wanted to give them. And sadly enough, we had to implement one of the ugly ones. So it's really dangerous, at times, to go with design and HTML for people already. Somebody was asking if there is a live one already out there for a site that we could look at, that you built with Dexy?

No, unfortunately. These types of things and most of my clients are clients who don't appreciate it that much if I publicize materials that I used for them, so a lot of NDA stuff. I'll probably just have to make an example one. That's probably the best thing to do, or take an existing site and just make an example of that. First, have to get the book done.

One earlier question was how do you get the client to write down feedback when the design is in the browser? Could that be extended to allow for an annotations system with Google Docs, or something like that? That's a great question. In fact, I was talking with Ana about this. That is a request that she has, so we'll probably be working together on doing some kind of annotation system on top of Dexy, where we use... Dexy is all plugins, so we're going to see if we can make a plugin that allows you to annotate. We might use SVG to draw the annotations, or whatever. We'll have to see. It's just something we talked about last week, but it's definitely something we want to do.

One question is how do I generate the style guide for production uses? This is partly what this is about, but you just had a small demo to show how it works.

I don't know if I would do a style guide. The style guide is about the design. It's not necessarily about documentation for production of CSS, especially if you use things like Sass, you're going to have heavily optimized CSS, which won't always lend itself to this.

If you have a button, you might have a lot of the styles that you use for the button like in other selectors, or like in a mix-in, so you would have to include the mix-in styles and any specific styles for that button within a certain module. It can get really complex. So if you want to document production things, I see that more as production documentation and not really a style guide. You could do that. You could use Dexy for that if you want. Dexy is great for all types of documentation.

If it doesn't change from under you? If it doesn't change from under... Well, I'm aware of a lot of the changes. It's not all that bad. It should even be easier for non-coders to work with.

One last one. How do you store a style guide like that? You can put it somewhere on a website. But if a client wants to have it as one file, do you have to zip it up?

I think there is even a Dexy filter for generating a PDF. What do I use? I use...

Ghost script? No. It's another mark down converter. I can't come up with the name. It's fantastic. From John McFarland.

Whatever.

Whatever. I'll look it up. I forgot what it is. But yeah, just generate a PDF that way.

Cool. That's it from Stephen Hay. Thank you again.

Thanks. [applause]