The Changelog: Software Development, Open Source - Foundation and Other Zurb Goodies (Interview)

Episode Date: December 7, 2011

Wynn caught up with Jonathan and Matt from Zurb to talk about Foundation, their HTML5 front end scaffold and many projects from the Zurb playground.

Welcome to the Changelog episode 0.7.0. I'm Adam Stachowiak. And I am Winn Netherland. This is the Changelog. We cover what's fresh and new in open source. If you found us on iTunes, we're also on the web at the changelog.com we're also up on github and github.com slash explore you'll find some trending reposts some feature reposts from our blog as well as the audio podcasts if you're on twitter follow changelog show and me adam stack and i'm penguin p-e-n-g-w-i-n-n fun episode this week i caught up with the guys over at zerb and talked about foundation and all of the projects in the Zurb playground. You've got a lot of fun stuff they work on, really.

I mean, everything from Joyride to Flickr Bomb, some fun names, too. A lot of personality in these projects. I love what they do with the project pages. We talked about some of the backstories for Foundation and Joyride and Orbit Reveal, the whole arsenal. I'm bummed I didn't go on this call. Actually, I was working with Chris to kind of rev Foundation into the SaaS world, so I was giving him some advice. But I'm glad you guys caught up with him, or at least that you caught up with him

and had a good conversation with him. Pretty good technical discussion on this one. But look for another episode on Founders Talk to get the business side of Zurb. Yeah, absolutely. I'm talking to Brian. I had him scheduled a week or so ago. I had to reschedule it, but he'll be on the show soon. So if you're a fan of Founders Talk, definitely catch Brian there soon and learn about the backstory and I guess how Zurb got started. We'll see. Keep an eye out for that. Fun episode. Should we get to it? Let's do it.

We're chatting today with the team over at Zurb. So Jonathan, Matt, why don't you guys introduce yourselves a little bit about your role at Zurb? Cool. So my name is Jonathan Smiley. I'm a design lead at Zurb. I've been with Zurb for a few years now. I work on a lot of our client projects as a design lead. I'm also involved a lot in our product efforts as well as in some of our open source efforts like Foundation. Cool. And I'm Matt Kelly. I'm the engineering lead here at Zurb. I've been here for about almost three years now, and I work mostly on the product stuff here at Zurb, so Notable and Verify. I do stuff on the back end, Ruby on Rails, and then on the frontend, jQuery, Backbone, all that good JavaScripty stuff. Why don't one of you introduce Zurb and a little bit about what Zurb does?

Okay. Sure. So Zurb is an interaction design agency in Campbell, California, in Silicon Valley. We work with a lot of startups as well as with a lot of larger kind of Silicon Valley companies like Facebook, eBay, Yahoo, Netflix. While back,

we did the website for britneyspears.com. So we hang our hat on that for a little bit, but we do interaction design and design strategy. So we work on, we work on front to end basic or sorry, front. What am I trying to say here? This is one of those brain fart things that can be edited out later. All the end.

Or we'll just leave it in for comic relief. Yeah, we'll just leave it in to make fun of us. But we do basically beginning to end for a lot of our startup clients, from business strategy stuff all the way through to tactical pieces like wireframing into front-end code, basically solving design problems for our clients. So it's a little unusual to have so much open source for a design agency. Talk a little bit about how that plays into your strategy. So we kind of got into it because for a lot of our clients,

it's helpful for us to know as much as we can about what the capabilities are on the front end and on the back end, for that matter, so that we can design things that aren't just, I don't know, design eye candy kind of stuff, things that can actually be implemented and built. So in the course of knowing as much as we can about that, as well as in the course of designing and building our own products, of which we have a number, we did a lot of work on really researching JavaScript and getting much more into that, doing a lot more work on, you know, really researching JavaScript and getting much more into that, doing a lot more work on the back end, really kind of pushing the envelope on front-end

pieces like CSS3 or stuff that we can do with HTML5. And in order to learn how to do some of that, we put together the Playground, the Zurb Playground, which is where we could do all these experiments and kind of like just screw around with things like we wanted to, you know, we wanted to figure out what's a better way to do image uploads or what's a better way to do specific kind of JavaScript stuff. I know Matt could probably talk more authoritatively about a lot of those pieces. And we figured, you know, why keep all that to ourselves? Our mission is kind of to bring design to everybody.

So if we're going to be bringing the work that we're doing to everybody, we may as well expose it as much as we can. We're going to jump into the playground in just a minute. A lot of goodies in the playground, but I wanted to start with Foundation. Talk a bit about Foundation and what it does. So Foundation was actually born out of what we used to call the Zurb style guide, the Zurb CSS style guide, which was a set of resets and common styles and sort of layout affordances that helped us get, get running much more quickly when we were doing front end code for our clients. And we realized as we were going through that, that not only was it pretty poorly documented and not really, it was, it was a little difficult to get going with. It was also, it didn't

have all the best practices we could have in it. and it wasn't as good of a starting point as it could be. So we started to build it out into something much more full-featured with a lot more documentation, and that's what eventually became the first version of Foundation, which actually nobody outside of Zurb ever really saw, which was for fixed-width websites. It was for desktop only. It had a lot of best practices, and it had a lot of good code in it, but it wasn't everything that it needed to be for it to really be useful going forward. So about six months ago, nine months ago, we started adapting it into a really responsive framework, something that we could really rapidly prototype with and actually build sites that work for desktops, tablets, phones, any kind of device really.

Since mobile devices are definitely the future, mobile devices are already huge. Within the next couple of years, they'll account for more Internet traffic than desktops in the U.S. Since that's what's kind of coming down the pipe, we want to make sure we're ready for that. And since we're building out this huge framework and we were building out all the pieces that we needed for this and we were documenting everything, it made pretty good sense to open it up to everybody. And that's kind of the genesis of Foundation. Talk a bit about, maybe draw some distinctions between it and, say, Twitter Bootstrap. So Twitter Bootstrap, we actually know the guys who work on Bootstrap. They're good guys. There's a lot of good code actually in Bootstrap. They have a lot of really nice styles,

especially for forms. They really went above and beyond for doing stuff like forms. Probably the biggest distinction between Foundation and Bootstrap is that Bootstrap today certainly and for the indeterminate future is still designed exclusively for desktops. It's purely fixed width. It doesn't really have any affordances to do any kind of responsive design.

They are working on that. There's no real timeline on when that's going to actually happen. And from the work in progress stuff, it looks like their approach is going to differ a bit from ours. But at the moment, that's probably the biggest delineation between Foundation and Bootstrap. Foundation was also designed to be a little bit more agnostic in terms of style and in terms of what you're going to do with it. Bootstrap is really phenomenal if what you want to do is build a desktop site that looks a lot like Twitter.

It's more of a style guide than Foundation is. Foundation is built to be extensible and modified and be more of a baseline than a final solution, I guess, for what you want to build. Would it be closer then to, say, HTML5 boilerplate? It actually incorporates a number of aspects of HTML5 boilerplate. We actually included a number of pieces from that, and you can find those in the code. Those are actually credited in the code. Boiler plate is kind of the other end of the spectrum,

which is that it's absolutely just a baseline in order to build all of your stuff on top of. Foundation includes, the grid is probably the biggest piece that it includes that boiler plate omits, which is a construct for really quickly doing layouts, nestable, flexible layouts. It also includes, Foundation also includes a lot of just common elements like tabs and pagination, things that Boilerplate omits because their intention isn't really to build a framework that you can use to completely prototype a site and completely move that into production code. It's really just a great way to start coding that has a lot of sort of best practices around really low-level stuff.

You provide a Rails gem out of the box, and I see that it's been ported to WordPress and.NET, ASP.NET MVC. Any other server-side frameworks in the works? Not by us. We know a lot of people are working on other things. We're a Rails shop here, so we did the Rails asset gem, and we're going to continue to maintain that. But in terms of the WordPress gem and the.NET MVC gem, those are all done by people

who are outside of Zurb who are contributing to this kind of stuff. So we've heard from a lot of people. They're doing stuff in pretty much every framework. Someone's got something that they're working on. But if anybody out there wants to do one for their favorite framework, we're more than willing to answer any questions and give you the support and help that you need to do that. But here, our wheelhouse is more Ruby on Rails, JavaScript, jQuery,

so we're going to stick with maintaining the Rails asset gem, but then help anybody else in the community who wants to do gems for their own favorite framework. We've been trying to get through these episodes without mentioning Compass or Sass because we get so much flack on the Twitter when we do that. But couldn't help but ask, you know, why just static CSS only? Why not a pre-cessed flavor of it?

I mean, we want to make Foundation accessible to everyone. So we kind of wanted to code at least the baseline that's on GitHub that we're going to maintain needs to be at the, you know, the base language or the base markup language that everyone understands, right? So we want to steer clear of Haml and Sass and Compass, at least for the version that we're going to put out there. Again, we're totally encouraging people, if they love Sass, if they love Haml, then totally do your own port of that and keep up to date, and that's awesome. But for us, we want to make sure that everyone can use Foundation and we don't want to get into some kind of holy war about Sass is the best or Haml rocks, forget HTML. We're just going to go with the one thing that everybody knows

so that it's accessible to everyone. We don't want that to be a barrier that you have to learn Haml. We're not super opinionated about, like, yes, everything has to be in Haml, everything has to be in Sass. That's kind of the way we feel about it. Do you use those tools in your projects? Some of us do. We have kind of a varied shop.

I mean, we have various designers. I know Chris is one of our designers. He likes to use Sass, which actually I think he's even working, I think he's working kind of on the shop. I mean, we have various designers. I know Chris is one of our designers. He likes to use SAS, which actually I think he's even working. I think he's working kind of on the side on like a SAS gem for Foundation. So he's a SAS proponent, but I think he's the only one in the office. We've played around with less before trying to use that. We kind of, I don't know, we poke our noses into all these different things. But at the end of the day, I always come back to just using vanilla CSS.

I feel like I have more control, but that's just maybe I'm a curmudgeon that way. It's an accessibility problem, right? If you use a language that not everybody knows, then you're saying, well, I don't really want you to work on this project. It puts a barrier up. If someone new joins a team, if you want to get somebody outside the organization to contribute to it, if they don't know Hamlet, if they don't know SAST, then it's a barrier for them to get in there,

and they can't quite as quickly get in there and have it go. So we're all about making this stuff accessible for everyone and having everyone on the team be able to contribute to every project. So again, for some of the smaller pet stuff, if somebody here wants to use Hamill, more power to them. But as a company, we haven't said, this is the way. We haven't standardized on, we're all going to use Hamill, we're all going to use SAS. We just stick with the vanilla stuff. So I guess as a design agency, do you find yourself having to hand off assets to external teams quite a bit in Project Lifecycle? Oh yeah, absolutely.

For almost all of our client projects, at the end of most of our projects, what we end up handing over is front-end, either style guide or templates, coded style guides or coded templates that they need to be able to implement. That's actually another reason that we don't delve too much into LESS or SAS. We don't have a lot of clients who are comfortable with any kind of additional frameworks like

that. So it's difficult for them to integrate into their workflows. It's easier if we can give them CSS that we understand, that we wrote, that's all organized correctly and organized logically for us and for them. So almost 1,600 watchers on GitHub. How long has it been out? About a month. That's impressive.

I think about four weeks now. Yeah, it really, really took off there. So we're pretty stoked about that. So I wanted to jump into some of the projects in the Playground. So over in Foundation, a lot of the layouts that you've got, it looks like you're using the Placeholdit web service that will return assets on the fly, the images on the fly, but I noticed you have another project in

the playground called Flickr Bomb, which does almost the same thing except with Flickr images. Talk about that. Yeah, same thing but different. It's the same problem that Placeholdit solves, but when we're doing, and mostly same problem that placeholder solves but when we're doing mostly this came from our client work we're doing client work we kind of have to go out and grab some images from stock uh what's that website called the stock photo i stock yeah whatever you

go to i stock and get the um the watermark image thrown in there but the placeholder images are great but if we're trying to convey like a mood or a feeling for the page without having actual final images, you still have to go out there and find them and hunt them down. So we thought, how cool would it be, because what we usually do is we just go to Flickr, search for something by a keyword, and then pull in an image. How cool would it be to just be able to do that in a similar way that placeholder works? So instead of specifying a regular SRC attribute on your image tag. You specify one, but instead of it being like an HTTP URL, you specify it like Flickr colon slash slash, and you put in the Flickr keywords, and you just drop the Flickr bomb script somewhere on your page. And then all those placeholder

images where you specified the width and the height, they get this little control button on them. So you go to your image, it pulls in the first image from Flickr that has that keyword in it. And so you can just see that. So for example, I'm prototyping a Britney Spears site, and I got a bunch of Britney Spears placeholder images on there. When I load it up with Flickr Bomb, they'll just pull the first Britney Spears image for each one of those. And if I don't like that image, I can click on the little tool icon in that image and pull in a different one. And it uses local storage to persist whatever image that I chose down in my local machine. So it's a really quick way to

do some fast prototyping, but have actual images in there rather than just those kind of gray placeholder images. This has got to be the first time we've ever mentioned Britney Spears twice in an episode. Yeah. Is that what's usually on loop in the office? Not as much as it used to be. It pops up every once in a while. We're more likely to be listening to Kesha than Britney Spears.

Yeah, that's a true story. Britney Spears was really hot back when we were working on a client, right? You really have to do your research. Exactly. We still got a picture of her up in the office. We do. Kesha has not been a client of ours yet, though. We're holding out hope.

If she's listening, we'd love to do her website. If you're listening, probably not to this podcast. Talk to me about Joyride. Joyride, so Joyride was kind of fun. Joyride popped up because since we do product development here, since we have a number of products that we've released and that we

continue to work on, Notable and Verify are the ones that are out right now. We ran into an issue where basically we make changes to the application based on customer feedback, based on internal review and things of that nature, but we didn't have a great way to actually communicate to our users what was happening. We were never doing a spectacular job of actually showing what was changing, of showing where they should be going or how they should be interacting with these new pieces. So it occurred to us that the simplest way to deal

with this would be to have a plugin that we could use and that other people could use to very quickly just attach a little tour, a little joyride on the page to take you from step to step. And we wanted to make it really easy to use. So you can basically drop in the plugin and you just attach these steps. You create them as sort of an So you can basically drop in the plugin and you just attach these steps. You create them as sort of an ordered list at the bottom of the page. And you attach them to just elements that have individual IDs. So you just can get, you know, a lot of your elements on it, especially in an application,

a lot of your elements on the page already have IDs. So you don't really have to do anything for that. Or adding IDs is very simple. So it's really easy to just create a very quick, very easy to use tour that'll take you down the page and will actually show you all the new stuff. We used it in Notable fairly recently for one of our releases and we got a lot of good feedback from that. A lot of people were really pleased to see that when things changed, we were actually telling them what changed and how they changed and how they work now. It helped a lot with engagement. And also it was just, you know. It helped a lot with engagement.

And also it was just, you know, as with a lot of our Playground pages, it was a whole lot of fun to actually put together the Playground piece itself. You can check out the Joyride page on the Playground and see us playing around with imagery and big flashing headlights. And if you punch in the Konami code, you can have some fun with that too. I'll have to try that. You guys put so much design into your project pages. I mean, how much time does that take? As much as the code?

It takes some time. It doesn't usually take as much time as the code because we've gotten pretty good at doing it fairly quickly. But it's also just fun. I mean, all the stuff on the Playground, it's literally that. It's really a Playground for us. Other than the listings of our actual products on the Playground, it's literally that. It's really a Playground for us. Other than the listings of our actual products on the Playground, everything we've done on the Playground is just open code. It's just stuff that people can use and stuff that we thought was cool.

It was really born out of a few years ago when we were first getting into CSS3 and what you could do with that with transitions and transformations and some of those other pieces. The first thing we put together for the playground was actually a, it's a gallery of Polaroid, Polaroid looking images. And we wanted to see what all we could do with CSS3 to make images look like Polaroids without doing a whole lot of extra work. And, you know, we're putting it together and we realized it doesn't really sell it as being

as cool as it is unless it looks really nice. So we took the time to, you know, give it a nice background and, you know, play around with text shadows and make inset text and do all this fun stuff. And that was kind of the genesis of really, really, at times almost over the top, Playground Pages. Because it's fun for us to mess around with the code, but it's also fun for us to mess around with the display of all this stuff. I think it's always become like a one-upmanship type thing, too. The Playground stuff, it's not like somebody tells you, like, you need to do this plugin, like John was saying. It's always something that you want to do that's really cool.

So different people do different pages, and it's kind of their baby as they're growing. And some of the competition, we're like, well, all right. We did the really crazy radioactive flashing buttons with the awesome background, and now for the next one, it has to be even bigger and more exciting. So they kind of continue to get more elaborate and more ridiculous. Speaking of, so Zurb buttons, I think, is the gateway that most folks have into landing on a Zurb page. So talk a bit about Zurb buttons and what they are.

We love buttons. I couldn't even, I'm not even sure we could tell you exactly what the impetus behind all of that was. But when we were first getting going, I think what really kicked it off was there's a page on the playground day that with some of this new CSS3 stuff we didn't have to mess around with sliding doors like you used to have to with these crappy sprites where you had all these problems and it was just a huge pain in the ass for different browsers. We realized you can actually make really nice looking buttons with really intelligent stuff

with very simple markup and fairly simple CSS. So we were really excited about that, so we put together this page for super awesome buttons, and we put together a blog post, and it just took off like almost nothing else that we've seen. Just tremendous numbers of views. It's been used all over the place. For a while, we had some fun looking at all of the sites

that had hotlinked our overlay images, which was pretty entertaining. Oh, man. Yeah, there's... Very popular among adult sites. Yeah. There's some interesting URLs in there. So that kind of started a little love affair with us for buttons, and we still have a tremendous

amount of fun just making really refined buttons that require almost as little markup and as little CSS as humanly possible. And some of the stuff is just silly. I mean, you can check out like the radioactive buttons, which are great to play around with until you realize that if you keep that page up, eventually your fan will kick on and your processor will spike to 100% and it just kind of goes crazy. But it was fun to look at and fun to play around with. And then Google was starting in on doing buttons using just CSS for production stuff, so we figured, hey, let's show how you roll your own Google buttons. And now that's become somewhat commonplace, but at the time it was pretty cutting edge. So I guess that was kind of what kicked off our love affair with buttons.

We still just love buttons. Anytime anybody asks us about buttons, we're like, ooh, let us tell you about buttons. Speaking of buttons and Google, what do you think of the new UI direction over at Google? I provisionally like it. I like some aspects of it. In a few of their applications, it falls apart a little bit because they've almost gone a little too far in that direction. They've lost a little bit of structure in a few places. Well, the buttons in Gmail got a lot of play when they first came out, as you said, but

now it seems like they've just gone to flat, square, divs everywhere. Yeah, it's very minimal, and parts of it I really like. I mean, in terms of the first place I saw it, I think, was actually when Google Plus first came out, which it works pretty well for that. It's pretty simple, and it's still got a pretty good structure to it. In a few places, it doesn't adapt quite as well. It's mostly nice to see that they're working on design at all, actually, that they're bringing design into their products or into their process at all, since traditionally Google's been,

and no offense to engineers who are in the room with me or listening, but it's traditionally been an engineer-driven society over there, which is basically function well over form or usability. So it's nice to see some aspects of that. I don't know. That's my take on it. Matt's just bobbing his head next to me. Yeah, designers. Another popular project of yours is Orbit.

Yes, Orbit, our jQuery image slider. That was kind of just created as we wanted to do our own image slider. It was one of those things where we're like, there's a thousand image sliders out there, but we're just going to make our own. We have some specific needs. I think it was more as a development exercise and us specifically saying, no, no,

this slide's going to be a little different. So we were very opinionated about a couple things we wanted to do with the slider. We wanted to make sure that, first of all, we didn't want you to have to set the width and the height of it. So Orbit does look at the images that it has and it sets its own width and height based on that. Or if you do want

to do it automatically. The way we slide images through the slider you can position controls without them being hidden. So we're not doing like an overflow hidden on the container. So we did a lot of small things differently. It came out with a fairly simplistic, at least to use slider, that a lot

of people like. On the jQuery side, it's actually by far our most complicated jQuery plugin or jQuery tool that we've done. It dominates everything else in terms of lines of code and complexity, but it does offer a lot more simplicity for the user side, but on the backend invitation side, it's pretty crazy going as we have going on in there. It also easily dominates in terms of emails and support requests received. Yeah, yeah. By far, we get the most people asking, like, why doesn't it work in this crazy situation?

Just because, again, it is so complex and it is so accessible, people are using it in all kinds of different crazy ways they could have never imagined. We did have a lot of fun, though, adapting Orbit to work with Foundation because originally Orbit was not a responsive image slider, and now it is within Foundation. We're still working on porting the original one that will work both in responsive and non-responsive layouts, but we have a branch of it in Foundation that's fully responsive and implements the responsive portion of it in a different way

than the other image sliders out there. So it doesn't use quite as much JavaScript on the resizing and detecting sites. It's almost all CSS tricks to try to maintain the ethic ratio. It's also responsive with content as well. So you can put in a div and resize that. You just literally grab your window, resize it, and we will resize that div, keep the same aspect ratio without using JavaScript to take the window resize. It's pretty fun. Some great, cool technical challenges to make things work inside of the responsive world. I know across all your open source projects, it's hard to pick a favorite,

but if I had to, I think reveal would be mine. Yeah? Okay. It seems like it's just a UI pattern that you have in almost every project now and just makes it so darn simple to add a dialog box. You would think we would have something like this baked into the spec by now, you know? Yeah, you might think so. Reveal was fun.

I mean, Reveal had a similar genesis, I suppose, to like Orbit, which was basically there's other solutions out there for it, but we didn't have any particularly strong feelings about one or another, so we figured we'd just roll our own and have control over it, and it would do the things we wanted it to do. We wanted something really simple. We're also having a lot of fun with data attributes. I don't know if you've gone through our jQuery stuff, but that's kind of been our preferred

way of hooking stuff in. So rather than having to call a JavaScript function at the end of your script tag or at the bottom, we like to just use data attributes and have the scripts just, you know, look at the DOM and say, what should I do? So that way you don't have to actually write any jockey code. You just include our script, you add some data attributes, and everything works. So Reveal was, you know, we were starting to play with the attributes. We're like, let's just do a, you know, really easy dialog box

that just is driven totally out of data attributes and really simple, a couple animations, and just get it done. And the difference between Orbit is very complex. Reveal is actually pretty straightforward on the jQuery site. We just tried to make it a very minimalist API and really easy to hook in. You just drop in the code and go. Outside of your open source, you still have a number of free apps that I guess some of these are hosted services and not open source projects.

What about Axe? Axe was fun. Axe is a tablet-only web app, which made it fairly interesting from the get-go. But it's basically a way to capture a website and then sort of axe out, basically scribble out or cross out the things that you don't want or the things that you want to change. And then quickly add notes about what you would change and then take that and share it with somebody else. I know we had a lot of fun doing the design of it actually was pretty cool, especially the visual design, which if you look at all of our different feeder apps, we call them feeder apps, the free apps that we provide. But if you look at all of our different free apps,

Axe is definitely the most aggressive and bloody of all of them, which was pretty fun. They're pretty valid. Axe, Chop, Strike. Yeah, I know. I guess we could have gone a little more violent with some of those other ones, but Axe is a really aggressive one. I know with Axe, a lot of the fun with Axe came in terms of just the technical challenges of it, which were pretty interesting. There was a lot of weird stuff going on there. Yeah, we wanted to do a native app for tablet devices,

so really kind of getting into the touch events. You've seen a lot of other, I'm sorry, not native, but like browser apps for mobile devices. Seen a lot of limitations. It seems like browser apps kind of felt sluggish in general, so we wanted to go in and see what the limitations were in terms of how good of an experience could we build. We didn't want it to look like a native app.

We just wanted it to perform well and feel like a nice web app. So it was a pretty decent amount of work to get all the little moments right on the apps, but I think he got pretty happy with what we got running on that, at least on the iPad. We didn't spend that much. I mean, we spent some time we got running on that, at least on the iPad. We didn't spend that much. I mean, we spent some time. It works on tablet Android devices, but, I mean, the performance is not that great, and it doesn't feel nearly as fluid.

There's some weird edges, but it certainly works on Android tablet devices. But what on the iPad is where it seems to run really well and performs very well for a browser app. So we were pretty stoked about that. You guys have mentioned mobile quite a few times, so what sort of applications are you creating? Pretty much everything we're working on right now has some sort of mobile component.

We're definitely on a mobile warpath right now, which was a lot of the impetus behind Foundation, but we're working on a couple of paid applications, so paid services that we're going to be releasing in the coming months, both of which have fairly strong mobile components in terms of bringing mobile development into your workflow and doing more with mobile, because we definitely believe that doing things for mobile is really a requirement at this point in terms of development for the web or for applications. For all of our recent free applications, so Reel, Spur, and Axe, all three of those have mobile components to them.

They're all responsive. Basically, each of those works on phones, tablets, desktops. In Axe's case, it restricts the actual functionality to tablets. We did that. That was just a decision that we made in terms of what would be the best experience but Spur and Reel are both completely responsive and for both of those, in fact for all three of those

we didn't write three different code bases for different categories of device just like with Foundation we wrote one code base and we did the adaptation and did the changes that we needed to make that a good experience on the different categories of device, I suppose. But even for client projects and stuff now, we're bringing in a fairly strong mobile component to really everything that we're working on. So you mentioned responsive layout, and I guess access the touch events and touch APIs. What other sort of device capabilities are you taking advantage of? So right now, at least on the web side, we're still somewhat limited in terms of what we can take advantage of.

You can take advantage of location now through web applications on mobile devices. We haven't had occasion to do that just yet. It just hasn't really made sense in terms of decisions that we're making for the current applications that we're working on. We certainly could. It might pop up in the future probably for a client application. So there's definitely some stuff that we could do there. In terms of other capabilities of mobile devices, things like orientation, most of our stuff right now is designed to be agnostic in terms of the orientation you use it in,

whether it's landscape or portrait on tablets or phones. We try to make sure everything just works. We have gotten into a little bit of using media queries and CSS to do specific things for one orientation over the other. I don't know.

Thus far, it's mostly been the adaptation of screen size that's really made an impact for us for touch-based devices for smartphones or tablets or things like that. Axe is probably the best example of taking advantage of actual touch events and different gestures and such. And using Canvas to draw the annotations on there. So this is the part of the show where we kind of turn it around and ask you what's got you excited in the open source world? What's on your radar that you just can't wait to play with? That's a good question. That is a good question.

Exciting in the open source world right now. It's always fun to, I know, I know I have a, I think I have a tab open right now, which I'm pretty sure it's open source, which is Inuit, which is a new CSS framework. I've got a tab open to play around with that and kind of tear that apart. I'm always curious to see what

other CSS frameworks are doing, what their best practices are, and what they're implementing as far as layout, or as far as device specific code. I had a lot of fun messing around with Golden Grid system, which has been out for a little bit. I know that's on GitHub.

But Golden Grid was really cool because I actually like their approach to the grid. Conceptually, I like their approach to doing layout with a grid a little better than what we even do in Foundation. They make some really smart decisions about that. What they trade is total lack of support for any version of Internet Explorer before 9,

which we're not really willing to give up in Foundation just yet. So we can't do exactly what they've done, but I do like what they did. And yeah, I'm interested in tearing into Inuit and seeing what they put together. But it's always fun to see all the different frameworks that people are working on because doing things more quickly with CSS is definitely a growing trend right now,

and there's some good stuff right there. But that's me. I don't know about Matt. I'm pretty excited to see what's coming out on the JavaScript front-end world. I mean, I'm a big fan of Backbone, but there's a lot of other front-end libraries that are kind of on the rise still, so I'm just kind of sitting around and waiting until some more exciting stuff comes out. I'm really interested to see where SproutCore goes, where Backbone continues to go, or a bunch of the other frameworks like that.

So it seems like it's still really early, but there's some very exciting things that are on the horizon. So I'm just really excited next year to see what other kind of Backbone-type libraries we have to make our lives a lot easier for doing the more client-side heavy applications. So you're up to eight projects on your GitHub account. Is Git used company-wide? Yes, absolutely. Yeah, that was kind of something after, a little while after I started, we were there using, we were using SVN for everything, and that was one area where I felt like we just really needed to company-wide make the decision, do the cutoff, bite the bullet, teach everybody Git and just standardize on Git straight up.

We've done that and we've been very happy overall. For the designers, some of the command line stuff is pretty rough, but the GUI client made life much easier for everybody. I wanted to thank you guys for joining us today. I want to do a quick plug for, Adam couldn't join us,

but he's going to be interviewing your boss, Dimitri, I guess, on Founders Talk. Nope, he's Brian. He's going to interview Brian. Brian, okay. Be sure and catch that if you want to see the business side of Zurb on the 5x5 Network with Adam in the very near future. Thanks, guys. Hey, thanks for having us.

It was a lot of fun.