Jared Spool: Welcome, everybody. My name is Jared Spool, and I have a wonderful treat for us today. I have with me Bryan Veloso and Dan Rubin, who are two of the amazing parts of the Sidebar collective group. And they are putting on the Sidebar Workshops, which are going to be in Austin, Philadelphia, and Los Angeles in 2011.
Hello, Bryan. Hello, Dan. How are you all doing?
Dan Rubin: Hey, Jared.
Bryan Veloso: Doing fine, thank you.
Dan: Doing Well.
Jared: Good, good. You guys have put together this really cool workshop that's sort of like a brain dump of the tricks and techniques and things that you've learned over the years.
So why don't we start with Dan? Dan, what was it that happened that made you guys decide, "You know what? We've got to talk about this"?
Dan: We'd been working together for about a year after we decided to form our little creative collective, back in 2007. And the reason that we all got together in the first place was because we shared a lot of the same values and also a lot of the same ideas of best practices with code and design.
So once we started actually getting the opportunity to work on both our own projects and a couple of client projects together, as a group, we realized that we're learning a lot from each other.
So even though we did the same things, and we'd all been doing this stuff for well over 10 years, that whenever we were in the same room together and were watching one of the other do their thing in Photoshop or in a text editor, we'd all learn something.
It started to become a common thing, where we'd go, "Oh, hang on. Back up a little bit. Do that again. What was that keyboard shortcut? How did you just use that layer mask?" We found this was happening quite a lot.
And that, I think, started us all asking similar questions of other people that we knew whenever we ran into them, like, "OK, so how do you do this? What do you do when you do this thing? OK, here's how I do it."
And that conversation, over the period of a few months, led us to realize that there's all this hidden knowledge that people who are practitioners, who work more than they teach, we all come up with our own little ways of improving our work flow, saving time, and getting the job done, in ways that allow us to get the tools more and more out of the way so we can focus on the creativity and the problem-solving.
And through that conversation that that led to, we all went, "Well, why don't we figure out a way that we can share this stuff?"
It doesn't seem to ever come across in blog posts or in written tutorials in quite the same way, that you learn these things when you're actually speaking to someone, or you get the opportunity to learn from looking at someone else's files and having them actually there to tell you why they did it this way and why that's better than the other way and ask those questions.
And at the time - this was back in the beginning of 2008 that we thought about putting workshops together - there weren't really a lot going around.
Now, the idea of a workshop is becoming more and more popular, which is great, but no one was really doing small, focused teaching sessions.
And we just thought it would be a great idea to be able to share what we knew, but instead of doing it from behind our computer screens and our keyboards, actually getting together, having the opportunity for the four of us to get together, because we were spread out across the country and also in Canada, so that didn't always happen on a regular basis.
So this was an opportunity for us to get together as friends and coworkers and share what we knew with anyone who was interested in learning and advancing what they knew.
As anyone who'd been following the history of the idea and interested in over the last few years, we did run a couple on our own before we figured out that we didn't know how to run events.
What we found was that the people who attended loved it, absolutely loved it.
It was like feeding candy to kids, because we all really enjoy getting to just sit down and learn how someone else who does what we do does what they do, especially when they've been doing it for a long time and they can share that kind of expertise, right in the same room.
Jared: It feels like the stuff that you're putting into this workshop is stuff that comes right out of the work that you've been doing and these techniques you've been learning over the years.
It's really an advanced level of stuff that helps you guys produce code much faster. That's what I'm taking away from the materials that you've been sharing with me about what's in the workshop, right?
Bryan: It's not even exactly that. It's the stuff that you have to read between the lines to get. We did a few talks at a few conferences together.
And some of the comments that we would get back were the things that were between the lines, not necessarily the things that were on our slides or that we were meaning to say, but things that would just come up in the discussion between Dan and I about, like what Dan said, shortcuts that we would use.
And those would be the nuggets of information that people would take away and they would tweet about or spread themselves or pass it forward.
So, it's the stuff that you won't find in the fundamentals at, say, South By, or even in some of the larger overview at, say, A List Apart. It's really the stuff that, when you're in the trenches, these are the things that'll help you get by.
And they're not necessarily advanced; they're just using two or three fingers to save you a few mouse clicks. And we've found that people just geek out when it comes to that kind of stuff.
Jared: So, what are some of the things that people have been geeking out about lately?
Dan: Well, let's see. I think that we've got two different categories here of teaching. One is the front end, development, the programming, the markup, the CSS. And the other side is on the design side, which is both thinking and theory and also tools and work flow.
Of course, the great thing about the four of us in Sidebar is that we all do both.
Bryan and I tend to focus more on the front end, on the design, even though we can build pretty much anything as well on the front end, and Bryan as well, on the back-end development as well. So the great thing is that there's always something new for people to geek out over and get excited about.
On the code side, it's funny. As a designer, for me, I started out as a designer before the web existed, but I was also a computer geek. So when the web came along, I was on it right away.
And eventually, because of the tools evolving, the idea of a web designer came out and was born probably before there was even a term, and it allowed my design side to kind of coexist with my geek side.
And at the beginning, there was a lot to be excited about because of that. And there were a lot of designers who flocked to the web initially and thought, "Wow, here's this new medium we can play with. Isn't it great how accessible all these tools are to us? We can view source. We can find out how other people are doing things in a way we've never been able to do before."
And that was great for a number of years, especially with the web-standards movement in its early days.
And then, for a good number of years, things calmed down as far as what designers could get excited about on the web. It just became this production line. You were all doing the same kind of thing, focusing on best practices, making sure that you make things usable and functional.
And those are all great things, but they don't tend to be exciting. The industry's focus, especially for designers, had shifted for the last, maybe, four or five years at least, to taking everything we'd learned prior to that and just making sure that we become consistent and do good things.
Thankfully now, in the last year or so, since the latest wave of browser versions have started to support all of this new CSS3 magic and wizardry, it's opened up...
Bryan: The new Renaissance, pretty much. Yeah, it's pretty much that.
Dan: That's a great way to put it. It's given designers, in addition to front-end developers, but especially designers, something on the code side to get excited about again.
Because, when it comes to creating interfaces for the web - Bryan, I'm sure that you've found this - the more visual you are, the more time you tend to spend in Photoshop creating things and honing the detail, especially in the old days where we couldn't do things, even simple things like drop shadows and rounded corners, which keep getting referred to.
But those are simple things that we would do all the time, and then have to take a lot of extra time in the code and the production to actually convert them into something that could be viewed in a web browser.
And so that's why seemingly simple things like that are so exciting to designers now, because we know that we don't have to make that decision, necessarily, anymore of, well, should we include this in our design or not? Because it's going to add to our production time, which means it's going to cost more.
Now those things don't add any effective production cost.
So it means that not only are they OK and we have this permission to use these things, even in subtle ways, but they're so easy to implement and so easy to change and to update that it means that we can start spending more of our thinking time on the bigger design problems and how we can use these new tools to push ourselves, rather than...
In the past, we'd spend a lot of time thinking about the best way to slice up our design so that we could implement some of those tiny, little, almost superfluous and useless things, like drop shadows.
We wasted a lot of time as an industry on figuring out how to make those things work. And now they just work, so we can actually spend our time on other things. So it's a combination of points of excitement.
All four of us have worked at different levels. Jon now works at Yahoo as a developer. And Steve has worked at Notre Dame before starting his own consultancy, does all sort of stuff. And Bryan, you've worked as far back as early days of Facebook and Automattic, the WordPress folks.
Your experience brings something even more interesting, I think, in a lot of ways, than Steve's, Jon's, and mine, in that you've had the opportunity to practice your skills at what would be considered almost a super-high level, especially at early days of some of these organizations.
I know I'm excited by these things because I've tended to always be someone who's done everything myself. I'm a wearer of many hats, because of running my own company for so long. With your background and the arc that you've been on, does it excite you in the same way?
Bryan: It really depends on what it is. It's more like flavor of the week. I find more excitement when I'm working with the technologies when I'm working on my own stuff, mainly because, when we're working at companies - and I'm sure Jon and Steve know this as well as I do -you're put in a box.
And that box has restrictions: browser restrictions, accessibility restrictions, things that you can't be an artist with your designs when you have to support IE6. And the company doesn't necessarily completely understand the concepts of progressive enhancement, graceful degradation. I'll throw buzzwords out there.
But when it comes to personal stuff, stuff I've done with Revyver, for instance, I'm beginning to find that when you're talking about making drop shadows and things of that nature easier, it's not just that we're excited about now that we were excited about then.
It's also a cross between code, the backend making it our jobs easier as well. CSS pre processors are a great example of that. I'm a huge user of the SAS pre processor.
And I use Compass on a regular basis just because I don't have to worry about the simple things of writing four border radius properties for each browser prefix, you know. I just write include border radius in the border radius and I'm done.
So code, the programming languages that designers have strayed away from, are now helping us do our jobs easier, in which technologies back when we were first getting excited about web standards, weren't able to do that. Or they weren't as mature or people just didn't have those ideas yet.
Because we needed that I guess downtime, for lack of a better term, to notice the inefficiencies in our workflows.
And now everything is exciting, both on the front end and the design side with CSS3 and also being able to implement it easily, from the front end development standpoint, with the pre processors and a lot of the frameworks that have come out too.
It has made our jobs a hell of a lot easier and that's enough to geek out about in its self.
Jared: These new technologies, the pre processors, all this stuff. Is this really hard stuff to learn for somebody? Or is this something that if you're relatively proficient and someone shows you how to do it, you can pick it up pretty quick?
Bryan: I think it is something that people can easily grasp. But I do think that the need has to be there.
If you're building a two-page workshop site, for instance, then I wouldn't recommend using something like that unless you're already using that as your language. Say OK, it's like I'm going to build a two-page site but I won't use Jango or Rails to host that. I'll just type out the HTML.
But as soon as you get past a certain threshold, than it just makes your job that much easier, using variables or mix ins, for instance. So you can change colors, you know, at the.
Jared: The drop of a hat?
Bryan: Drop of a hat, yes.
Dan: I can attest to how easy they are as well. I've always been a designer first and anything else second. So of the four of us, for instance, I'm the only one who's never really taking very well to any backend development in proper programming languages. Where John, Steve and Bryan all...
Bryan: I tried.
Dan: You succeeded quite well with Jango. So something like SAS or LISP, as an example of a pre-processor, initially can be very off putting.
Because it feels like it's taking something that already feels a little bit more like programming than we'd like, for a lot of purely designers, and makes it even more programmatic. And introduces math in various statements and equations and we start to see X and Y and variables and we get confused and we run away.
But what Bryan said was exactly dead on. It becomes easier once you have a need for it. Once you realize the need for it.
For instance, I remember looking at LISP and SAS a year and a half ago. And understanding what they were meant to do, appreciating it from the side of my brain that understands programmatic logic. And I knew what it would do.
But none of the projects I was working on at the time would benefit from it. So the time I spent looking into it was more like research without a point to it.
And by comparison, a couple months ago, I looked into specifically the LISP pre processor. Again, because I'd come on a project that required it. Or at least I knew it would make my life easier. And the minute I started looking into it, having a purpose for it, it all made sense and I got really excited to use it.
And the benefit of things like SAS and LISP is that the syntax is so similar, on purpose, to existing CSS, that's it's actually not that hard to understand. And especially if you're a front end developer or designer who's getting into CSS3 which actually has a lot more variables.
And if you're using some of the advanced selectors or pseudo selectors, you end up having to do some new things that aren't traditional CSS. You know, being able to select using any of the Nth of type selectors, for instance, that you actually have to do a little bit of math.
But it's OK because when you're using it you understand the context and doesn't feel like a big deal. And that's the same with any of these pre processors.
So it is kind of wonderful, I think, that the industry has caught up with itself, almost. That the development side of the industry is starting to really pay attention to what makes it easy to build a really great front end, and not just build it but maintain it as well.
It shows that the two sides of our industry, the development and the visual design, are really starting to work together and understanding that they exist to achieve the same goal.
I'm going to go back to something you said a few minutes ago Bryan, where you were talking about the kind of older days of your employment with the larger corporate environments and the restrictions that they put into place.
A lot of the time those restrictions, I think, at least based on work that I've done clients, were based on the browsers, what the browsers and the languages were capable of. The restrictions were there to create consistent output.
And especially when we were always dealing with IE6 as a mainline browser, we had to play to what always worked there and never broke.
And a lot of people that I've spoken with and run into at conferences and workshops in the last year, who are starting to actually use CSS3 in particular, are loving the fact that because we're at a point now where the current browsers all supported in the same way, with very few exceptions.
The versions before the current most previous versions support a lot of it.
And then older browsers, like IE6 and older versions of Safari and Netscape and Firefox and so on, rather than breaking when we use these new tools. They actually just ignore them entirely. Which is this, I think, wonderfully consistent behavior, again because consistency is the thing that we all look for.
It's suddenly given us, this is something else to be excited about, it's given us this environment where the idea of progressive enhancement or progressive enrichment, depending on what you want to call it, is now tangible and possible.
Because the work involved to understand how those things we're adding progressively fails in older browsers has suddenly become easy. Because it doesn't fail, it just doesn't exist.
So you can use things like CSS pseudo elements, because only the browsers that understand them will show them. It's not that they'll break in older browsers, they just won't be there.
And knowing that, you can use those pseudo elements to add things to through CSS, whether it's visual or actually generated content, what ever it happens to be. You can add it to your designs knowing that you're only going to add things that aren't required for the design.
But you don't have to really do any exhaustive testing either. You just know that it won't show up, period.
And that's exciting because, I think, in those larger corporate environments especially, that means that we're a stage now where we can introduce new things, new technology, right away, without any worry of compatibility because we already know exactly how it behaves.
Bryan: And I think more than that, it's a mental thing. We've evolved, our mindsets have evolved since, we last held our workshop. It doesn't matter anymore to have a site look the same in all browsers.
And I think breaking that wall down was imperative to getting to the point that Dan was talking about. Because, you know, hell if I have to get some of my new sites, the CSS3 sites, to look like they do in Safari and in IE6.
It's not possible and people have finally accepted that as a truth and they're OK with it and we can all move on.
And with that fact in mind, people have been innovating more than they've been repairing. And it's all contributed to what we see going on now around us.
Jared: I want to come back to something that you guys were saying. That there's this sort of tipping point where the project that you're working on becomes large enough and grand enough that these tools really kick in, in their value. How do you figure out what the tipping point is?
Dan: That's a great question. I think that's a question that is best answered with that annoying, it depends. But it really does. It depends on, not necessarily just your site and project. Because, for instance, if you're an agency, every project you work on is different in some way, even if you specialize in one type.
I mean, that's one of the things, I think, that most of us in this industry love and thrive on, is that even the same kind of project again and again isn't boring, because there's always some new problem to solve, a new way to solve it, whether it's on the design side or development side.
I think it comes down more to how you do your work. One of the things that a lot of people get hung up on is the tools, rather than focusing on getting the tools out of the way as much as possible.
When you've worked in a given industry for long enough, you start to realize that it's not about the tools. It's about making the tool work as efficiently as possible for the way that you work and the way that you get things done and the results that you want.
So realizing where that exact tipping point is, using CSS pre processors, as an example. You don't realize the value of them and decide that you want them and need them until you realize why you need them or that you need them.
So that tipping point is at a specific point where you or your organization has to be doing the type of work that will benefit from a pre processor and save you a whole lot of time on the front end development, for instance.
Once you realize that, you've found the tipping point and you'll start using it and your life will be better. And you'll save a whole bunch of time that can either be spent with your family, out of the office, or solving more important problems than typing the same hex code 70,000 times.
Bryan, do you feel like it's the same? I'm not entirely sure so I'm asking. When it comes to the front end, like the visual design tools like with Photoshop, like if there's a particular tipping point there.
Bryan: That's also a horrible it depends. I mean, when you get to the visual tools, there hasn't been much. We've been talking about all of this great implementations stuff. But when it comes to the visual design tools, we're really working with the same things we've worked with, you know, since 2003, to be completely honest.
Jared: Really? CS5 didn't rock your world?
Bryan: CS5, I mean content aware fill? When would I need that? I don't work on pictures, you know. I can make space in between guys smaller, no. You know, it's.
Dan: I think you're being kind saying that were working with the same tools that we've had since 2003 because that was when the first CS came out. But, it's worse than that, to be honest.
Bryan: It is a lot worse than that.
Dan: I mean heck, vector shapes maybe were a big deal. Layers, obviously, were the biggest deal, but that was back at what, Photoshop three in the mid 90s? Then we had adjustment layers and then editable type, and that was as the web was coming around to be.
We really haven't had web tools. What was the biggest thing that Photoshop gave us, Save for Web. We don't even have to talk about Image Ready because that came and went.
So we got Save for Web in like Photoshop 5.5. That was 1999. We've almost not gotten any major improvements to this tool that most web designers probably use for their visual design.
So yeah, we are in a little bit of a predicament. Adobe, if you're listening, help us.
Bryan: It's not much of a predicament as much as it is we're just using the same hammer for new nails. There's this whole movement towards Fireworks. That's really just using a different tool for the same job. A shinier hammer or what have you.
Dan: It's worth pointing out that John and Steve are both avid Fireworks users. Yeah, they know the app inside and out. Bryan and I are Photoshop users.
I think it's akin to artists saying one prefers oil paints and the other prefers acrylics. You're trying to achieve the same result and you're doing it in a slightly different way that adjusts your workflow slightly. But essentially, you're still using your eyes, and your hands, and your brain to solve the problems.
Bryan: While we're having fun with metaphors, I wouldn't even say it's that. I would say it's more like I prefer a different brand of paint because that's how similar the tools are. The means to the end are different, but the end is still the same.
So on that end, not much has happened. But again, it's a point where, I guess singularity comes to mind, where we don't know what the next big thing will be on this end.
Adobe Photoshop, they were going to have their eyes out for the photographers because, that's their biggest market. They know that not a lot is changing on our end because; the implementation is still trying to catch-up to Photoshop to what we do in Photoshop rather.
So I really can't say where the tipping point on that end is. There are a lot of things that I wish Photoshop could do better. There are a lot of things I wish any image editor could do better.
Font rendering, for instance. None of the things I've seen out there, whether it's Acorn, Drawit, or all of the alternatives that have been pimped to there and back, to the apps' fans, they all do text rendering horribly.
Take an idea from me, if you wanted to create a web design tool that I'd use over Photoshop, make sure text rendering is correct. If you can get that done, you have my money.
Dan: That points out one of the major differences between the development side. Whether it's front-end or back-end, where the tools, they're improving at the rate that we all think that the industry is progressing, very, very quickly.
There's iteration constantly there. On the design side though, the tools have been fairly stagnant, for better or for worse. But, that takes me back to something I said earlier which is there has to be, should be, the separation between the tools we use and how they affect our workflow and the theory of design.
The application and theory in the thinking process of visual design, if we take that and draw a parallel to product design. People have been doing this kind of thinking and creative problem solving for a lot longer than the web's been around. Those processes haven't really changed.
If we look then to another parallel for graphic design. Well, that's been around for decades and decades, since before World War II in various forms. So we're coming close to graphic design as a recognized field being around for nearly a century.
The basic principles of form and white space and flow and typography and color and shape and hierarchy, they've changed in tiny little ways. But, the great thing is, that they haven't really had to change in massive ways.
We have different movements and historically different preferences that come in with each decade. But, those are all stylistic and we should embrace them.
Our tipping point is a different thing. When we're looking at the tools, we have to be focused on not what they can do. Not feature lists, but how they can work best to serve us in our workflow and our needs.
If it's the wrong tool for the job, find a different tool. If there isn't a different tool, figure out how many different ways you can bend, twist, and break that existing tool. Basically hack something like Photoshop and the features it provides, to do the job you need it to do.
That's where I think the excitement is on the tool side for people like us. We look at a tool like Photoshop which has always been built for photographers. We look for all the different ways where we can subvert its features to do what we want to do.
Bryan and I have always been huge proponents since the tool would let us, of this kind of non-destructive editing. So using vector shapes and vector masks and layer blending modes and every single possible tool that Photoshop gives us with each version that allows us to make edits and changes that aren't fixed in pixels. This is something we love to talk to about.
Dan: I don't think we get tired talking about non-destructive editing. And that's actually something that keeps getting somehow, slowly, easier with each version.
Bryan: That's very true. That is very true. And speaking of that, Dan, you had an awesome point about the theory of design is our bar and again, it's going back to something I had said, it's all about implementation catching up to those principles.
When you're talking about people hacking tools, I wish I had the link to this or somebody to credit, but an article I saw about using Illustrator to design websites, full websites, and just the amount of content that was on there, it almost converted me.
If I didn't find Illustrator a complete pain to work with when it came to using vector shapes-I find Photoshop a lot easier-then I probably would do it just because when it comes to say resizing boxes with rounded corners, keeping the radius of the rounded corners, apparently you can do that in Illustrator and apparently that makes it a lot easier to work with those types of designs.
I found an article; I guess it's on Google or your local blog somewhere. I would highly recommend that read if you're looking for another tool to hack.
Dan: That's a good point that we always have to be on the lookout for a tool that can help us do our job better. It's not about whether you prefer Photoshop or Fireworks, it's about why you prefer Photoshop or Fireworks, or Pixelmator, or Acorn, or Illustrator.
If the why doesn't tie directly into how easily it allows you to achieve your creative vision and do your job, then it's not a good enough reason. You're probably not looking hard enough.
I read that same article, Bryan, and the number of things that jumped out to me that I was saying yeah, oh man, wouldn't it be great it Photoshop did that, wouldn't it be great it Photoshop did this, which tells me probably that there are some cases where I really need to start using Illustrator.
And I use Illustrator a lot but always for prints things, so now I'm going to start actually experimenting when I can on using Illustrator for Web things and see how it works because who knows, maybe it will become this fantastic tool for me.
That's one of the things that throughout the day of the workshop we actually all like to teach.
We all like to share the experiments that we're currently performing on ourselves in our own work flows in the hopes that maybe someone in the audience will have done the same thing and be able to share with us.
Or that our experiment, our willingness to stretch will inspire someone else to go in and say, well I never even thought of firing up Illustrator to do that, or so on and so forth.
Bryan: Yeah, we're all inherently masochists.
Bryan: No, I think the Web as a whole, anybody who works on the Web is inherently masochist because day in and day out they're always stressing themselves out.
To answer the question about the tipping point, the tipping point comes when you can find a way to not be masochists. When is it that I don't have to write a hex code 7, 000 times anymore? Then that's the tipping point for preprocessors.
Bryan: It's just about being comfortable and not being stressed. It's just the really basic element of a tipping point in anything really but I think more when it comes to the Web.
The implementation tools have been moving a lot faster because you have a lot of independent development around these implementation tools, and the browsers are finally starting to get it, whereas with Photoshop and Illustrator you have the almighty Adobe who loves to say they listen to us, and I'll leave it at that.
But yes, we're all inherently masochists is my point.
Jared: That's funny.
Bryan: It's just a matter of getting past that in little subtle ways that will make technologies succeed.
Jared: I grew up in the world of programmers and I always thought that programmers were inherently lazy people, that they would rather write code to do a chore than to do the chore themselves.
So maybe that's the difference between programmers and designers is that designers are masochists and programmers are lazy.
Bryan: And now you have hybrids.
Jared: Hybrid, lazy masochists?
Bryan: Yes, I am a lazy masochist. Well, I'm as close to one as possible because I've been doing back end development for almost, gosh, four years now. So yeah, I would, Steve and Jon, probably lazy masochists as well.
Jared: [laughs] That is what really defines a master of their craft is how lazy and how masochistic are they.
Jared: [laughs] Well, with that I think we'll wrap up this little discussion here but people can check out the Sidebar workshops at of course the wonderful URL Sidebarworkshops.com where you will find the program details, everything that's going to be covered at the event and the fact that it's going to be in Austin in April, and Philadelphia in June, and Los Angeles in August.
You want to sign up there and get to see these tricks and techniques that Bryan, Steve, Jon and Dan have to offer.
Bryan and Dan, this has been awesome today. Thank you very much for participating with us.
Dan: Thank you.
Bryan: Thank you for having us.
Jared: Great. Thank you, everyone, for listening to today's show and we'll talk to you soon. Take care.