Episode 63: Disco Mode
June 28, 2013
Running time: 42:45
Jonathan and Kelli talk about responsive design, progressive enhancement, and development tools in the context of a big huge site redesign.
- Brad Frost
- Josh Clark
- Dan Mall
- SVG Support
- Steve Souders
- Fixed Positioning in Mobile Browsers
- The Asset Pipeline — Ruby on Rails Guides
- Happily Jumping On Bandwagons
- Dalai Lama of Performance
- Disco Mode
- Baby 2.0
JS: Hello and welcome to the Nitch podcast for Friday, June 28, 2013. I’m Jonathan Stark…
KS: And I’m Kelli Shaver.
JS: We’re here to talk about building apps that run everywhere. This week we talk about responsive design, progressive enhancement and development tools in the context of a big, huge site redesign. Please stay tuned, the Nitch podcast is next.
KS: I almost didn’t get my name out there.
JS: Sometimes it’s hard, I know. How’s it going?
KS: I’m here.
JS: More barbecued chicken disease, that’s no good. Hey, you got a free I-Mac or something.
KS: Until they figure out they haven’t charged me for it yet, probably yes.
KS: They shipped it before processing the payment.
JS: Oopsy, hopefully they don’t listen to the podcast.
KS: If they don’t process it in a week or two, I’ll give them a call. Give them a chance to catch it first so it doesn’t screw it up and charge twice.
JS: Yes, that recently happened to me, that exact same thing. Not with a product, but where the fix was worse than the original problem. Six months later I finally get it worked out.
KS: I’m the person that stole garbage collection for seven years, but that’s another story for another day.
JS: I don’t know where to go with that.
KS: It wasn’t intentional.
JS: It never is when you steal garbage collection, anyway.
KS: Moving on.
JS: Moving right along you mentioned before the show you’re going to do a Rails 4 project. I guess Rails 4 was announced today.
KS: I think it was yesterday it was released. I haven’t really done anything with it yet, but yes I’m going to dive in and work on a silly little weekend project and go ahead and do it in Rails 4 I think. We had planned, me and a friend had planned to work on it this weekend anyway and then with the Rails 4 announcement yesterday, what the heck dive in and do it in Rails 4.
JS: Any particular big changes.
KS: To be honest, I haven’t really had a chance to keep up with it that much. I’m not the right person to ask that question right now. I need to go through and read some of the changes. I believe they just… I’ve done more towards toward decoupling some things and things that were built into Rails by default. Now you can include via gems if you use them or down, that kind of thing.
JS: A little more modular maybe.
KS: Yes, I think active record is one of those. I assume with various different data base types and [Inaudible 00:03:06] stores and all that, that not everyone using Rails needs active record.
JS: Good point. I was going to say active records seems like the main attraction of Rails. That’s a good point. I look forward to hearing all about it on a future episode.
JS: Some quick housekeeping before we blast into the content. If you’ve been following along dear listener, you know that last week and the week before, loosely speaking, the last two episodes I should say. We’ve been doing a screen cast, two or three; we’ve done three so far haven’t we?
KS: We’ve done three. I don’t know, are they all three up?
JS: Yes, I think; yes the one I posted this morning is the third one. I’ve done screen casts in what looks like it will be a four-part series on building a Rails API, sorry a rest API with Rails, which now will probably be out of date with Rails 4. We have to take a break from that this week and do a regular podcast. Then we’ll probably next week get back to that fourth installment, hopefully, final installment of that. The last few weeks for me have been totally crazy. Sleeping three hours a night if at all and working on these two projects where the schedules ended up colliding. They were supposed to be back to back but they ended up simultaneous for a variety of reasons. They were both very similar projects with almost the identical team. I was working with Josh Clark and Brad Frost and Dan Mall and few other folks on a couple of big, big publishing websites. Since a lot of this stuff that we’ve talked about on this show has been smaller sites, I thought it would be cool to do a little bit of a postmortem about how our Nitch schpiel applies to a larger context and how well it works or doesn’t work or what might be different, that kind of thing.
KS: Yes, that would be interesting because we talk about building a lot of small sites, but interesting to see what bits of the things we talked about you put in practice on the big ones.
JS: There were a couple of exceptions but TLDR, it basically all works, so that’s good.
KS: That’s good to know. And doing this next week for…
JS: That’s our show for this week. I don’t know if we need to go into too much depth on each one of these. I’ll go in and blast through and if you have questions I guess we can expand on some of the points. I think it falls into three big categories; responsive design, progressive enhancement and development tools. All of those, I learned a lot about each of those things in the context of these projects. I should say they haven’t gone live yet because they’re in the integration phase now which another company is doing. I totally cannot wait to announce these because I’m super proud of both sites.
KS: Yes, I’m really looking forward to them.
JS: They’re both such huge improvements. I think the clients in both cases, I know that they agree. It’s like the existing sites, in one case it’s going to completely replace the current desktop site, which is a super radical change. In the other case it’s going to; the new site is going to replace the M-dot and T-dot sites and potentially become the new desktop site, but not quite yet.
KS: Yes, I’m really jealous that I didn’t get to help you out with those, but I was writing a bit of my own things when you had that going on.
KS: Twenty or thirty people.
JS: Easy 20 maybe 30 people. With that context set, just a couple of points about responsive design. Both projects were pure responsive design. That was the whole point of the project to take a situation where companies had two or three versions of the website and turn it into one or two. Like I teased a minute ago, it totally works. Responsive design completely it’s awesome. We say this all the time, but sometimes it’s arguable. Yes but if you have this huge site with tons of different page templates does it really scale so to speak. The answer is yes, it totally works. You do have to start small and work your way up. We’ve said that tons of times. It’s even more true on a really complicated site. Both sites are extremely complicated from a design standpoint. They change radically, the different screen sizes. It can feel like extra work, especially when you’re testing. Every time you make a change you’ve got to pull out your Android 2.3 device, you’ve got to pull out a Kindle Fire. We were testing a Nook, Kindle E-readers. We were testing on Windows phone, you name it. That feels really hard. I don’t think it’s really any extra work because you only have one site. You would have had to do all that testing anyway, but it would have been on three different sites.
KS: Then you would have been trying to track bugs between them.
JS: It feels a little wackamolish at times no doubt, but that’s web design anyway. I don’t know if it’s specific to responsive. The good news is that browsers are getting really good. We used a ton of really advanced techniques in the progressively enhanced versions of the sites that I’ll talk about more when we get to that. Really the big exceptions right now in terms of popular browsers that have still a reasonably significant market share; the Android 2.3 device browsers, the stock browser on Android 2.3 is really awful at some of the more advanced things. Obviously IE 8 and lower is a little rough. Totally, you can totally make it work. Those are the ones you have to watch out for, but things like basically any modern IOS browser, all of the Android stuff that’s 4.1.1 is a little wonky but not too bad. As soon as you get up to 4.2.2 I think it is Android 4.2, the browser is really good. Windows phone browser has been good from the start. I have mobile version of IE 10. Blackberry, you know Blackberry’s rough. Sort of depressingly I suppose for them. Nobody even cared about testing on Blackberry.
JS: They ignored reality for too long. I guess the only things I… From a technical standpoint the only thing I want to mention is that I am frequently quoted or frequently heard saying that you always do min-width media queries. When you’re doing responsive web design a big tool in the box of responsive web design in media queries. As the saying goes, the first media query is no media query so you assume that you create a default non media query experience. Or a default experience outside of media queries that should be targeted to a narrow screen or small screen width. You enhance it from there using min-width media queries which we’ve talked about at length, so I won’t go into the logic behind that.
KS: I wish max-width didn’t even exist because people…
JS: People use usually and I’m going to say 80% of the time when you see somebody using max-width it’s them trying to…
KS: It started with the desktop.
JS: Right, they started with the desktop and they’re trying to reverse engineer or shoehorn it into a mobile site. I’m not really against that. I just think it’s very difficult to do and it’s a lot harder. If you know that’s what you’re doing and you have a desktop site and you just want to do some tweaks to make it a little bit better on mobile then fine, run some max-width media queries. If you’re starting a project from scratch you’re almost always making a mistake by using max-width because it indicates that you’re going from big to small.
KS: My very first project that I did with media queries, I did that right. At the time I didn’t know any better and the desktop layout was what I’d been handed by the designer. The end result was there was a lot, there ended up being a lot of duplication in the CSS, and CSS [Inaudible 00:13:15] ended up a lot larger than they needed to be.
JS: It was very noticeable to me during this project at one point when I decided I needed to use a max-width media query. I was like wow, this is a good…
KS: This never happens.
JS: This is… I tried and tried to do it with min-width and then I was like what am I doing, just max-width this thing and be done. I wanted to pay close special attention to that. The situation was that in the small screen there are basically three major breakpoints. They’re not really specific but for the situation I’m thinking of, the site that I’m thinking of there were basically three major breakpoints. There were small screens, which were like your small to medium size phones. Then you had big screens, which were seven inch tablety; then bigger than that was I-pad and bigger. Their search functionality at the top that was really, really complicated, it was designed drastically different on the small screen than on the large screens. Interestingly, the bulk of the CSS applied to the small screen, had to do tons of clever stuff to hide the small screen version. Also, there was a popup on it to changed the scope of the search, like on Amazon where can search just inside of books, or just inside of vacuum cleaners or whatever. There’s a ton of CSS applied to that that was for styling that popup that you could do much more easily on larger screens or desktop screens. I had all of the CSS that I put in as a default, so I start small and put in all the CSS and then as I was going up to the larger break points I was trying to remove it all. Whenever you’re trying to override a lot of CSS that was defined higher up in the document it’s a nightmare. All of the CSS really only applies to this small screen situation and so I did a max-width and then as soon as I popped over, I don’t remember exactly but let’s say it was 320; 320 pixels or whatever we did in M’s whatever the M’s were, that was around 18 M’s. Then all those things were gone. All that very, very small screen specific stuff was gone, never had to worry about it again and you could move on to your higher up media queries.
KS: Those were the places where the max-width is really useful.
KS: It seems like it was not that well supported and not that long ago.
KS: Then you just add classes.
JS: Yes, I page load. Modernizer would add either SVG or no SVG class to the HTML element. He wrote CSS to…
KS: Keep the backgrounds in those classes.
KS: Ok, makes sense.
JS: Honestly the way that he did it is really a graceful degradation approach because he assumed SVG support and then failed back to PNG then.
KS: It would have worked out the same either way.
JS: Yes I think so. The only issue I suppose would be on the… for content images. The actual image tags not CSS. You’d be serving the PNG until the page loaded and then you’d be grabbing the SVG. Since a lot of the mobile browsers that we were targeting do support SVG we defaulted to that.
JS: Anyway, SVG’s definitely ready for prime time in your project. I am convinced after doing this project that it’s something to use on probably every project.
KS: That’s a bandwagon I will heavily jump on.
JS: Don’t ask me how they made the SVG, I have no idea. I assume it’s something that you can…
KS: You can do in Illustrator. Illustrator can export as SVG.
KS: [Inaudible 00:24:28]
JS: With the real URL, yes.
KS: Then as you scroll down replacing the…
JS: We didn’t do it on scroll although we talked about it. We actually, Josh actually talked to Steve Suiters about this he’s like the Dali Llama of performance. He was like; yes you could do that but really just load up the page. Get the top of the page loaded and then as soon as you’re done with that then have the Script go through and pull, swap out all that stuff.
KS: You’re not waiting for it load as you scroll. It’s just quietly doing it after the first top of the page is loaded.
JS: Right and there is a way to do it that’s slicker than what we did, which would be to go through and define in each of the image tags what the height and width is going to be.
KS: I [Inaudible 00:25:18] to say, I assumed you had done that.
JS: That’s the slick way to do it, but there was no way for them to author that in their current back in system and it would be too much work. They wouldn’t do it. That was another reason to not do on scroll, because as you scrolled down these 1x1 pixel images would all of sudden be expanding into their natural size. That wasn’t going to fly. We just said get the page loaded so people can start looking at the top 1000 pixels or 2000 pixels, get all that stuff loaded. It’s like bang fast. It cut a lot of time off the load. Then if they look at that even for a couple seconds, then by the time they scroll down everything else is loaded. It was really easy to implement. You can imagine it was like [Crosstalk 00:26:07]
KS: Yes it doesn’t sound difficult at all.
JS: We used a… let’s see SVG we used feature detection, a lot of feature detection for things like touch handling and SVG. What were some of the other things? I don’t think modernizer detects support for position fix but we did it. We had to do user agent sniffing for some things.
KS: Most things support position fix now, some of the newer stuff.
JS: It’s Android 2.3 that causes a problem. A lot of them do support fixed positioning. Some a little wonkier than others and some of them have some weird rules around it, it’s mobile we’re talking about here in those that we have the problem. Some of them force, you have to disable zoom on the page. There’s a couple of surprise gotchas. Oddly enough the Kindle E-reader supports fixed positioning if you can believe that.
KS: Of all things.
JS: Yes it was awesome.
KS: I can’t wait to see these.
JS: I can’t wait to share them. That’s a good segway into tools that we used that were super, super useful. I guess the first two dimensions go without saying but they’re worth mentioning. Basecamp and GitHub were critically important pieces of our infrastructure. Not having either one of those would have been a disaster.
KS: That brings up a question. Have you tried Code Base?
JS: I don’t think so. It sounds familiar.
KS: Code Base is like what you would get if you took GitHub and Basecamp and squished them together. It’s basically project management with source control.
KS: You can reference open tickets in your get commits and they’ll show you, your commits will show up in your ticket thread for your project and that kind of stuff.
JS: I will say that I found myself doing a lot of this. I’ll describe the work flow that I had a lot of. We had internal, so for each client we had an internal project that was communication between the art team of five to seven people depending on what stage of the process we were in. Then there was a public version of the project where the client was potentially in the loop. We would have a ton of internal discussion and then that would usually result in one post by Josh in the public site. They didn’t have to listen to the entire thread. Here’s the work flow that could have been improved. It wasn’t’ too painful. We would put all the to do’s in the internal Basecamp project. Then as I would go down and knock them off I would pretty much commit per to do depending on how complicated the to do was. If the to do’s were appropriately sized then I’d go fix it or I’d go add it and then I’d do the commit. Then almost always the commit message, I would copy it. Go over into Basecamp, comment on the to do, paste in the commit message and it would have been really cool if I could have linked the to do’s to the commits.
KS: You could have used Codebase for that and link them up.
JS: That’s good to know. That would be… I think is I was going to… I think if we were doing maintenance, long term maintenance on a project that would be even more attractive. It would wear on your overtime. [Crosstalk 00:31:44]
KS: It would support tickets and that kind of stuff.
KS: I’m looking at it right now.
JS: It’s pretty interesting. I don’t know how different the one he released is from the one that we’ve been using. It’s like a PHP thing so you create your stuff with PHP behind the scenes, but I’m sure you could import it to [Inaudible 00:34:13] without too much difficulty. There’s only really one real function that does the [Inaudible 00:34:21], I’m sure you should import it really easily. It doesn’t look like much but when you’re working on a project for weeks and weeks and weeks it does become pretty convenient and adds up over time. The last thing I think you’ll be very interested to know is that since the project was… I mean the style sheets are enormous. There’s like, it’s easily hands down the largest style sheet I’ve ever had to go near in terms of work. Brad used SAS for it so when it came time for me to do my CSS, I generally created my own CSS file, included that in the page and I’d do all my work in there to try and avoid SAS. Eventually I’d have to take that and integrate it into the SAS files if he didn’t have time to do it. I have to say I’m not as anti-SAS as I have been on previous episodes. I still don’t love it. There are certain things about it that are cool, but I don’t think they’re SAS things. I don’t really care for… the syntax is ok. The nesting syntax is ok. I could go either way on it. Sometimes it’s convenient, sometimes it’s a pain. I used your favorite tool, maybe not your favorite but CodeKit to make this easier for me. It worked great sometimes and other times it would crash my computer, so I don’t know what the story was with that.
KS: It must have been big.
JS: It was huge, yes.
KS: I haven’t actually used CodeKit in a while. That’s mainly because I’ve been dealing with Rails applications and Rails has all of that asset management built in with the sprockets gem.
JS: It was definitely, there were times when I would want to do work on a remote server. It was like you can’t just change it because then you have to recompile everything. I had to learn how to compile at the command line which actually is far easier once you know how to do it. The SAS syntax, the nesting and the variables, I could take or leave that, whatever. The things that awesome is the way the he had this one master SCSS file that included all the other ones and there were 40 or 50 other little files that got included. It became so manageable having that stuff in separate files. I don’t know if that’s really a SAS thing or a Compass thing, but you can do that with regular CSS right? I’ve never gone to the trouble.
KS: You could, yes. You just use import stations.
JS: You use import stations, right?
JS: That wouldn’t compile it; this compiles it into one file.
KS: It wouldn’t have it all compiled into one.
KS: Yes I do like that about it but really I have only used CodeKit on small projects. The last time I tried it on a big project I did have some issues with slowness and a couple of crashes.
JS: It literally wiped out my computer on multiple occasions.
KS: It should probably handle those better, but at the same time I get the feeling that it’s not designed for the really big stuff. They figure the really big stuff you’re going to be using something; some sort of command line, build tool.
JS: Yes I suppose. For a project of this size, I don’t know if we would have been able to manage it without having the CSS broken out into individual files like that. How you decide to scrunch them all together, it doesn’t matter to me. I loved it, it was great. Even though with some blind text you can get that mini-map view and you can really easily see a huge file and navigate it. Forget it, having them in individual files is awesome; huge fan of that. It requires some discipline. You have to adhere to the logic.
KS: Right, whatever structure you’ve decided on.
JS: There were a couple times when I was like dam I don’t know; this is in the header but its search so should I be putting it in nav or in header or?
JS: Right, so where do I put it, or in forms because it’s a search form. Brad had in the main file, the include file, the SCS file that did nothing but import all the other stuff. He wrote this huge table of contents with basically instructions on what should go where, it was genius. It was so obvious but it was genius. It was great. I think everything that we talk about and advocate was totally validated on this project, these projects. It was so great. It was so much fun.
KS: I wish I had gotten the chance to help you out with them. I know at one point you asked me. I think there were a couple times where you probably could have used a hand. At that point it was too late, too far along for me to really jump in and save time. I was extremely busy with a couple of things of my own at the beginning.
JS: Yes, I feel like I’m ready to have a baby in October after this.
KS: Fortunately you’re going to.
JS: Yes, baby 2.0 is set to ship in October. I definitely, I haven’t in my life have not pulled that many all nighters; not in college ever, ever. I’m trying to get back on my regular schedule.
KS: You had a month there where you didn’t sleep.
JS: I would sleep; I would grab an hour or two on the floor or go try and... It was crazy. I didn’t ever sleep I just napped occasionally.
KS: I talked to you at 5:30 in the morning. I have to be up at seven, I’m going to bed now.
JS: It was rad. It was so great; I get to wrap up. It was so great working with this team because as dear listener will know [Inaudible 00:41:21], I don’t normally care that much about the more advanced CSS things. I’m just like eh, you know. Since I got drug into it by these guys who totally know what they’re doing and they know what works and that even a small benefit on a huge project is a big optimization. It really pulled me kicking and screaming into some of the more futuristic CSS at least. Definitely into some of these newer tools, so that was awesome, really cool. I had an excuse to buy a couple of devices in the process to do testing so that’s always good.
KS: You had to pay for yours though.
JS: Yes, but as long as I have an excuse I don’t mind.
KS: I don’t get charged for mine, yet.
JS: Speaking of which, I can’t sign off without sharing with the dear listener your big news.
KS: You have to share it fast. I have to leave in one minute.
JS: Sorry, we’ll hold. I was going talk about your [Inaudible 00:42:29] light bulbs.
KS: Oh yes, yes. We’ll have to get those next week.
JS: Excellent, so we’ll talk about that. Alright, so that’s our show for this week. I’m Jonathan Stark.
KS: I’m Kelli Shaver.
JS: We hope you join us again next week for the Nitch podcast. Bye.