Full Transcript

Adam Churchill: Welcome, everyone, to another edition of the SpoolCast. Earlier this fall, Jason Cranford Teague joined us for his virtual seminar, Prototyping a Responsive Design.

In the seminar, Jason got attendees to think about expanding their design skills beyond sketches, wireframes and visual comps and exploring the rich interactions possible in today's real world web.

Hello, Jason, welcome back.

Jason Cranford Teague: Hey, Adam, thanks for having me.

Adam: Sure. You've had some changes. What's going on with you these days?

Jason: Well, recently, I left the agency I was working with and I've started doing my own freelance thing, trying to broaden my horizons and helping people with Internet strategies and working on this responsive design stuff and reaching out and doing a lot more educational type stuff. As well as just working to get a little bit more high level with the people, helping them understand what they need to do in order to really communicate effectively on the web.

I've been working with Lou Rosenfeld over at Rosenfeld Media -- I'm one of his experts now, he's got me on the website -- teaching some classes, doing some daylong seminars for different groups and just having a great time doing that.

Also, just had a new book come out, "CSS3 Visual Quick Start Guide," Sixth Edition. It's the sixth time I've tackled this. Actually, the funny thing is, the book started out, the original title was "DHTML for the World Wide Web." But after a few editions of that we kind of realized no one was really talking about DHTML anymore.

[laughter]

Jason: I know, right? I wonder if anybody even remembers what the D in DHTML stands for anymore.

Adam: I don't.

Jason: [laughs] Dynamic, for you trivia buffs out there. And so in the last edition, we just focused the book on CSS3 and this is an update. We went all color with this one. It had been a black and white or one color, it had red in it.

Adam: Nice, nice.

Jason: Because full color, yeah. I was real excited. It did mean I had to go back and redo every example in the book so that it was more colorful.

Adam: Oh.

Jason: You have fun doing stuff like that.

Adam: Sure.

Jason: That's what I've been up to, and then doing a lot of writing. I'm trying to work on some magazine articles for different places and just working hard.

Adam: Excellent. Well, listen, you gave a great virtual seminar back several weeks ago. Maybe for some folks that weren't listening in that weren't with us, can you give us an overview?

Jason: Yeah. The idea originally behind the seminar was to present some of the real-world experiences I've had with prototyping over the years and the evolution of thought of where I've gotten to with prototyping, especially with the emergence of responsive design.

One of the things I've found in the last couple of years was that when responsive design came along, some of our older techniques, sketching out wireframes, using programs to draw what the website was going to look like before we made it, were going to become really difficult to maintain.

It's one thing to do a wireframe in Visio or OmniGraffle of a single Web page and then replicate that for all these other Web pages. Then when you've got to actually do that for a medium version, for a small version, you've at least tripled your work, if really not more.

I realized there had to be a better way. What I did in the seminar is I went back to my days when I was working at Marriott and showed how I used some early prototyping techniques I was developing.

I actually took the final design and then tried to show how it would be developed in the real world to show some of the inherent problems that we were going to face. I was able to show my group that the way it was designed just wasn't going to be sustainable on the web. The file sizes were going to be too large.

But I was then able to take that and modify the design slightly. In my prototype, I showed how much more smoothly that was going to work. I could show my team exactly what the differences were and exactly how it would act and interact. That was kind of the beginning of my journey towards a more full development of prototyping as a way to document your design.

I then went from there to my last agency, Forum One, where we ran into similar problems where we wanted to show the client how, especially responsive designs were going to work. We were just getting into the responsive design world about two years ago.

Our clients were having a really hard time understanding what this stuff looked like. I mean, we could show them sketches all day long, but they didn't really get how it went from one to the other to the other in terms of size.

I had a client say, "I really want to see this, can you wireframe it out?" I went home and I started working on paper wireframes, and I thought, why don't I just do it out? I know how to code this. I just coded the CSS and made it so that when you shrank the browser window, it would flip to the next size for responsive design.

I took that into the client and they could literally see where the break points were, what would happen to the design when it went from large to medium to small. It was a really effective way of explaining it to the client. It didn't touch any of the core information architecture software that we've come to rely on. Instead, I was just using HTML and CSS.

But I realize a lot of designers and information architects, they're not as comfortable with the coding side of things. I don't want to say, well, you've got to learn coding. I've started working with my team to figure out a way we could come up with some sort of program or something, some sort of design studio, if you will, that would allow anybody with only just a very minimal amount of coding knowledge to quickly throw together these responsive design prototypes.

That's where I came up with the idea for what would eventually become Proty. Proty is a prototyping, it's hard to say. It's a plugin to Firefox right now, is what it is. Due to some realities of the skillset we had in house and how applications get made, we found it was easiest just to create this thing as a plugin for Firefox.

You load it and what you do is, you pull up a template page and then you can start placing your components, you can start placing your modules on the page and start laying out your page from kind of these pre-built components.

You can work with a developer and have them, or front end developer and have them develop more components for you if you want. If you've got even a little bit of knowledge, though, you can get in there and start adjusting them the way you want them or even build your own.

We found it was a quick way to kind of throw together these responsive design prototypes, because it had the responsive design basics built in from scratch. You could click a button and you could see what the design would look like on a tablet. You could click a button and you could see what the design would look like on a smart phone.

You could even show and hide different elements depending on the view that was being shown. If you didn't want a particular module to show up on the smart phone, you simply hid it from the smart phone view.

We started using this with clients and really found it to be a great way to get the point across. The thing about doing this type of web design is that clients really have a hard time imagining how something static becomes something dynamic.

Now, we've all trained for years to imagine when you hover over this button, what does it mean when the color changes? What does it mean when it's something fades up or fades down? But clients, they're not generally educated in that type of thinking, and so it's much harder for them to get that. I found that a lot of our meetings were spent trying to explain to them very visual, very conceptual ideas and Proty allowed us to more quickly just simply show them rather than tell them how things work.

Now, Proty is open source and free to anybody who wants it at protytype.com. That's Protytype.com. Just sign up for the mailing list and you'll get a link.

Part of Proty came out of my own study of other tools. One of the things, one of the last things I did when I left Marriott was do an evaluation of prototyping tools for the company. They were looking at trying to find some way to head off some of the problems they'd had.

They looked at Axure, and they looked at Balsamiq, and they looked at using Flash. The problem with these was that none of them actually presented the reality of what could be done on the web.

One of the things that I thought was key to making a successful prototyping tool is that, not just making it look right, but making it act right. Making sure that you can't do things in it that would be impossible or at least difficult in the real world of the web.

On the flip side, being able to do everything that you can do on the web that you couldn't do in a lot of these other products. For example, one that I point to a lot is box shadows. Box shadows, on the web now, you can have multiple box shadows. You can put multiple shadows beneath any box in your design, allowing you to create a variety of really cool effects.

Now, Photoshop or Balsamiq or Axure, any of those other programs with very limited design controls, either it would be extremely difficult to do that, to the point where a designer just wouldn't want to mess with it, or completely impossible. Yet, in Proty, those types of techniques are easily done just as easily as if you were creating it on the web.

It also uses HTML5 and CSS3, so it's up to date on those coding standards.

That's what I'd looked at, I wasn't trying to sell anything there, because as I said, it's free. But I did want to explain how I got to that need to create a tool like Proty.

Adam: Awesome. Well, there were a bunch of great questions and I think, based upon the questions we got, our audience of designers and UX professionals was pretty broad. Let's start with some foundational stuff.

There were a couple of folks that were wondering what the best way for designers to get a good basic understanding of HTML and CSS is. They were looking for your recommendations on that.

Jason: Yeah. That's funny, I get that question a lot. It's always a good question. It seems like it would be, oh, go to this source, go to that source.

The advice I always give people who want to learn design is to pick a project, a project that maybe slightly, you're a little bit uncomfortable with, not too uncomfortable, but a little bit uncomfortable with. Get a book like mine, "CSS3 Visual Quick Start Guide," or others. There's obviously lots of good books out there. Something that gives you the basics and foundations of HTML5 and CSS3. Then, take your project and start working on it.

The best way to learn how to do this is not just by reading a book or following steps. It's to actually problem solve yourself. It's to, "OK, I've got this problem. I need to figure out how to get this text to do a particular thing. How do I do that?" You've got your reference book there to help you, but you've got to figure it out yourself.

As you work through these problems, that's how you really internalize these skills and build up these skills. And I say that because that's how I learned how to do web design. When I started, there were no books on web design. There were literally no books on web design, and I was given a magazine, the "Computer Mediated Communications," magazine and was told, "Hey, we need a design for this."

I just went in there and started to experiment and play around and came up with a design. I wouldn't show it to anybody today. It was pretty ugly, but I got it done, and that's where I started learning.

Adam: Getting into the tools, Jason, if you're working with a content management system -- and the example one of our attendees asked is Drupal -- for your production versions, why wouldn't you start with that?

Jason: Well, I'll let you in on a little secret. I work in WordPress primarily for my own work, and I actually do start prototyping oftentimes in WordPress. I'll just start working away in WordPress. I do that because I have a lot of CSS and HTML and JavaScript skills, though, and I know how to do that so I can get in there and start pushing modules around and building pages and coding stuff.

Drupal is a little bit more complex. It's gotten better over the years, but it's still not as easy to start throwing modules together, especially if you're not a developer yourself. So the answer is, if you can, sure, go ahead and start working in the actual final technology that you're going to be deploying in if you can do it just as quickly.

We developed Proty because a lot of our IAs and lot of our designers really couldn't get there very quickly. They couldn't start just working in Drupal. So we needed that kind of intermediate step, something that they could work in that would as accurately as possible represent that without having to have that huge steep learning curve of learning how to do PHP, for example, in order to code the stuff.

So it really depends on your own skill level and level of comfortableness with the content management system that you're working in. I would also say, though, that I find that works fine for simple sites starting in the CMS. I will say more complex sites where you're maybe building very complicated interactions or community sites, those aren't always going to be as forgiving if you need to make large scale changes later.

So working in a simpler system where you're prototyping may save you time in the long run because you won't be rewriting a lot of this very complex code. You'll just be testing out kind of this more minimalistic, higher level version of the code where you can simulate what's going one rather than getting into the time and depth it would take to create the full realized version of the site.

Adam: So our attendees are asking you to pick sides here. There's a comment that the mobile first proponents say media queries aren't supported by all mobile browsers and further is flawed. So media queries for responsive designs or this thinking of mobile first?

Jason: I don't think they're mutually exclusive. Mobile first, really, uses media queries. The idea is that whatever the experience, a style sheet gets delivered that then renders the design as well as possible to the device being used.

There are two ways of looking at mobile first. The first way is that you start with your design in mobile. So you start designing the mobile experience first, and then you scale up to the tablet, and then you scale up to the website version. And the thinking here is that more and more people are going to be accessing web work through mobile devices, especially smartphones and tablets.

The second way of thinking about it is that you deliver as a base experience to the end user the mobile experience. So regardless of whatever device they're using if they don't support media queries they get this basic level of CSS support, and that could be called the mobile version. I usually call it the small version.

And that's actually how I prefer to think of mobile first is that you're delivering this base level experience first and then building on that as media queries allow or not allow.

Now, this can get a little tricky because then you've got IE 8-7 on back ad infinitum that may get a more limited experience as a result, but I'm also a huge proponent of the idea of progressive enhancement where every experience on every browser doesn't have to look the same. It just has to work. So that's where I come down on that. I think media queries actually play an important part in the mobile first experience.

Adam: Our audience is always looking for our experts' thoughts on different tools and resources so a question here is what are your thoughts on using Fireworks or programs like that to make wireframes interactive?

Jason: Those work, and Fireworks is one that it's kind of a shame I don't use Fireworks. Fireworks is a much better program for doing comps for the web, but unfortunately I've been stuck in Photoshop so long it's hard to escape, because it also allows for that more interactive...you can kind of program in how the different interactions work and simulate them that way.

You can also use Visio to do the same thing or actually more OmniGraffle. OmniGraffle is really good at creating interactive clickable prototypes. The problem with both of those, though, is they are not the reality of the Web, and as good as Fireworks is, it still doesn't work exactly the way CSS works. You still can't do everything that you can do in CSS.

It's a different mentality when you're working in Fireworks than when you're working in CSS. And really what I'm encouraging web designers to do is to learn CSS, not so you can code necessarily -- that would be great if you could -- but so that you can understand the thought behind CSS so that you can design better for that medium.

It's kind of like if you were designing for print and you didn't understand how ink dried to how ink worked, or how colors combined to create your finished product. You couldn't design as effectively that way because you don't understand how the final process is going to render what you're going to design. So I always encourage designers to learn as much CSS as possible and start working in it when they can.

Adam: When you're thinking about the theme for the content management system you might be working with what features should you look for to insure you can take full advantage of the techniques of responsive and adoptive designs?

Jason: Mostly the responsive designs I've been working with have been in Drupal or in WordPress. Drupal, my team and I studied it and we came up with the Omega theme as the one that met the criteria we wanted. It had the best collapsible grid structure allowing us the most versatility. It had several columns rather than jut a few, and the more columns you have in your design the more layout possibilities you have.

It had kind of a bottom up approach -- bottom up is more mobile first type of strategy -- where you start with the base theme, the base styles, and then build on that as media queries allow for larger and larger devices.

It also allowed us to change it enough so that we could put in kind of our own special sauce, including built in menus for the smart phone version. It would automatically take the menus we put into our HTML and turn them into kind of that iPhone-like menu bar at the top that you would tap and then you'd get a drop down menu from there. It'd automatically do all of that type of stuff.

The one thing I've found in working with responsive design, though, is that once you do establish your base theme, once you do find the theme you want to use, whether you're working in Drupal or WordPress, there's very little you have to do on the back end once you get going. In fact, really, you shouldn't hardly ever have to touch the back end.

Instead, all your thinking is going in the front end. How different things collapse. Do they stay? Do you use the exact same functionality between the smart phone version, the small version, and the larger desktop version? Do you present the same search field? Things like that are going to be more critical and more a part of your responsive design thinking than the base theme you end up with.

Adam: How are you simulating gestures in your prototypes? What tools are you using to do that?

Jason: That one is something that also is built into the base theme. I leave that a lot for my UI developers. It's something that you use JavaScript and HTML5 to do.

I just created a site using the impress.js framework, which I adapted to use in WordPress. I'm not sure if you're familiar with it. It's a really cool framework that was originally created as a HTML5 alternative to Prezi, if you're familiar with Prezi. They wanted to do the same thing Prezi does, but Prezi uses Flash and they wanted to do it all in HTML5.

Well, I've done several presentations that way, and I was like, this would be really cool to do a website in.
One of my friends, he actually used it to do a magazine, and he very graciously gave me his modifications, his modified version of it to use on yurisnight.net. If you go to yurisnight.net. Yuri's Night is an event every April 12th to celebrate the first manned space flight by Yuri Gagarin. I've been their Internet strategist for the last several years. I get to experiment with the design there. It's pro bono, so they give me a pretty wide berth when it comes to what I do with it.

I used it there and one of their concerns was, well, how is this going to work on tablet and smartphone. For the tablet, what we ended up doing, rather than using gestures was we provided two large buttons on the left and the right that you can push to go forward and backwards in the site. You can also use the main site navigation if you want.

I think anytime that you're dealing with a site where people are used to interacting with websites using scrolling, and you're going to do something different, it's important to give them clear call to actions, rather than expecting them to know to swipe.

Now, that's likely to change over the years as people get more and more comfortable with websites that allow swiping and pinching and so forth and so on. But for right now, I would stick with clearer button controls to help people navigate sites on tablet devices.

Adam: Let's talk about images for a bit. Are you using the same image or multiple images via the CSS? Regardless, how's that all affecting performance and download time?

Jason: Could we not talk about images? Because that's the bane of existence of all...I'm joking.

It's a huge thorny issue. I actually spent an entire day once trying to come up with a pure CSS solution to the problem. And I did, I came up with some solutions, but none of them were good solutions.

One solution involved putting all the images as background images so that the CSS could then present whichever one was needed. But then, all the images are background images, and it interferes with findability of the site and people can't copy the images anymore, which admittedly, might be a benefit for some organizations. But it didn't really work well.

The other alternatives involve, the basic issue comes down to, let me back up and present the basic issue, if you're not familiar with it. If I am on a desktop machine, I have a larger screen, so I'm going to see larger images. If I'm on a tablet, I'm on a smaller screen, so I need smaller images. If I'm on a smart phone, I'm on a still smaller screen, so I want to see still smaller images.

Now, you can resize the same image between those to fit the screen. The problem is, if you're resizing the same image, you've got to make sure that it looks as good as possible on the large screen, and thus, you're presenting a large image size, file size, and then downloading that same file size to the smart phone, to the small device, even though it doesn't need that big a size.

The issue really comes down to speed, because we're used to smart phones. If I'm out wandering around on my smart phone and I'm on my 3G network, it's not going to be as fast as my cable modem setup at home. We don't want to force smart phone users to wait for the same image that I would be waiting for at home.

How do you deliver different image sizes depending on the device? There are a lot of different solutions, but there isn't a magic bullet yet. There is not a perfect solution yet. Some involve back end coding, which I won't go into here. It is part of responsive design, but it's far more than the design. It's really down to doing server side coding.

Some people use JavaScript solutions, but I've yet to see one that works perfectly yet. I think people are still kind of searching for that.

My theory right now is to use the same-size image and shrink it for the device. That's the simplest method, and to be honest, it does remind me of the problems we used to have in the early days of the Web, when people were worried about things like color.

We had 256 colors that we could choose from. You remember those days, Adam?

Adam: I don't.

Jason: Oh. OK. Well, back in the day. [laughs] Back in my day, we only had 200...

Adam: [laughs]

Jason: No, seriously. That is true. In the 90s, most monitors could only display up to 256 colors. And so designers were told not to use anything but those core 256 colors. Many writers got their start writing books about how to get the most out of those 256 colors. We went mad doing entire designs using nothing but 256 colors.

That included for gradients, too. So, lest you think that I'm being hyperbolic, it really was a huge limitation. And then gradually, people's monitors went to thousands and then millions of colors, and that problem completely disappeared.

It's not even something you have to even vaguely think about anymore. And I see the same kind of happening with these devices. Every time I turn around, a new standard has been announced making WiFi faster and faster and faster, and making the mobile devices faster and faster and faster. So, we're struggling with this issue. Why are we worried about image size again? So, it's kind of a wait and see. And that's why I always go with the easiest solution in those cases.

Adam: So, we get to talking about all kinds of solutions that CSS files can provide us. There was a question that asks, what's better -- multiple CSS files or just one?

Jason: One, to be honest. If you can get everything in one file, that is your best bet. And there are ways to do that. There are ways to code it so that you can do that. Practically speaking, though, that's not going to be the optimal way to do it for responsive design.

Again, let me back up and explain what the issue is here. The more CSS files that you are linking to or importing, the slower your site is to load. Because every one of those files gets a separate server call. The parts are greater than the whole. Every time you make a server call, it delays your page load even just a fraction of a second. But those add up. So, the more you call, the slower it goes. If you put all that same code in one file, that's one call, so it's relatively fast.

My rule of thumb is to try to keep it below four. Five is the max. If you can get away with three, then go for it. Then you're great.

Another option, as again, it's a server side option. What I see some companies doing is they kind of develop using as many style sheets as they need, but then their server will bundle all of those into a single style sheet for delivery to the end user.

Adam: You said in the virtual seminar, you used the phrase context is queen. And the question came in, how do you understand the context of use for specific devices, a phone or tablet device, to make sure that the design best supports those contexts and not just the constraints of the given device?

Jason: That's a great question. That content is king, always bugged me a little bit. Because I was like, there's more to it than content. And so, I was thinking one day, I was actually giving a talk. And context is queen, just kind of came out of my mouth. I was like, I need to write this down.

Adam: [laughs]

Jason: So, yeah. So how do you know the context, and you're not just designing to the device, because to a certain extent we're going to be designing to the device. But what you as a designer have to do is think about more than just the device. Think about the person who is holding that device, and what they are, and what you can assume about what they are and are not doing while they're holding that device.

So, let me give you an example. We know that if someone is using a smart phone, they have a small screen size. And you're going to scale your design to that. But as designers, we need to go beyond just thinking about OK, so they're looking at it on a small screen. If they're looking at it on a small screen, then what does that mean? Well, they could be sitting at their computer looking at it while they also have their desktop. But they also could be walking around. They could be sitting on a sofa. They could be in their doctor's office waiting for an appointment.

There's a broader context, to which they could be looking at your site. If they're on a desktop machine, or even a laptop, they are almost guaranteed to be sitting down. There is a different context there.

So, you want to think about how to deliver an experience based on your professional knowledge of where you think your audience is likely to be using your website. So that gets down to fundamental questions. What is your website for? If it's a banking website, and they are using it on a smart phone, probably they are running around. It may be that they need to check their balance very quickly to make sure that they can do this transaction.

When I was working on the Marriott app, unfortunately this didn't make it into the final version. I put myself into the context of somebody using the app. I thought OK, I just got off my plane, I need to know where my hotel is. I pull up the Marriott iPhone app, the first thing I want to see is where is my hotel. What's its address, I want a button to be able to call it. I want a button to be able to see a map on how to get there.

So, think about that context when presenting the content and functionality for the site.

Now, if I'm sitting at my desktop and I come to the Marriott website, the first thing I probably want to do is book a hotel room or learn about vacation packages. It's a very different context than if I'm on the phone device, where I'm probably on the go.

Adam: Jason, the next question probably is a virtual seminar in and to itself. But how does responsive design fit into Lean UX design?

Jason: Oh, yeah, that's a great one. I think they're really natural fits in a lot of ways.

Lean UX is the idea that you need to try and cut out as much of the paperwork as possible. That gets back to another reason I had my team and I worked on Proty. We were trying to reduce the amount of paperwork we were doing. We were trying to reduce the number of cycles that we were going through trying to get to this paper-based prototype.

I sometimes refer to the fidelity cliff. What the fidelity cliff is, it's that point in every project where you start spending more time refining your documentation to try and get it to a higher level of fidelity that is closer to reality, closer to the product you're trying to create, and you see diminishing returns. You spend more time with less fidelity added to the product. That is the antithesis of lean UX.

With a prototyping tool, you can keep increasing that fidelity even though you're spending more time on it. That, to me, is the heart of lean UX is trying to increase fidelity of whatever you're doing, whether it's a prototype or the final product, with as minimal amount of work documenting that and trying to explain it as possible.

I think, early on in the web, we were looking to architects as kind of a model for how we build websites. We call them information architects, after all. We developed wireframes as kind of a replacement for an architect's blueprints.

In fact, I remember, in my early wireframes back in the late '90s, I actually really tried to make them look as much like blueprints as possible. I used light blue lines, I did the little thing at the bottom, the little pill at the bottom with all the information and stuff like that. Over the years, I've realized that that's not a good metaphor for web design anymore.

Back then, putting together a website was a lengthy and laborious and expensive process, because we were starting from scratch every time back then. Every time you started a new website, you were starting from scratch. We didn't have CMSs, we didn't have frameworks to start from. We were starting from scratch.

Now that we have all these frameworks and CMSs in place, I wouldn't say it's a waste of time, but it's not as necessary to create these thorough documentations of the product like we used to. Because the difference between a website and a building is that if the website has problems, it doesn't fall down and people generally don't die.

With a building, you really have to make sure everything is perfect before you start building. With a website, you don't have to make sure everything is perfect, and you don't have to know where everything is going before you start building.

Adam: There was a question about testing. Obviously, something we do a lot of here at UIE. The question speaks to how you often test designs before working out a lot of the details of coding and creating the visual design treatment. But how does it fit into the process when you're thinking about responsive design? How's that time table of testing the design fit in there?

Jason: That's a great question, because I think testing is vital to getting the best possible solution. But when you test, it's difficult sometimes, again, just like clients have a hard time imagining how something is going to work. The people you're testing will often times have a hard time imagining when you say, "Oh, this is just a wireframe." Most people don't know what a wireframe is.

If you're testing with a wireframe, it is going to affect how people interact. It is going to affect where people look and what they see and how they interact with it -- which is why I try to get as close to something that looks like what they're going to be interacting with as possible.

I think that might put me at odds with some who want to kind of keep that base level when you're testing. You want to just kind of test the ideas and not the whole fully realized design. But the more I get into it, the more I find that if I can give something to somebody that looks very much like what they're going to be working in, I get a more honest reaction from them.

What I've been striving to do recently is to develop those tools that allow people to do the same tasks, do that same testing, do that same AB testing, but with something that's going to be easily changed. If you don't like the design, change it. But it allows them to test in a more realistic atmosphere.

Adam: Jason, some of our audience members were looking for just your experience. They want to know what responsive frameworks you've used and what you recommend.

Jason: Other than rolling my own, which I've done from time to time, I've used the Omega theme for Drupal, which works really well. That was the primary one I used in my agency work, and we deployed that on numerous different sites, including the Aspen Ideas Festival. That was the first place we did that.

Another one I worked with for Drupal was the Mojo theme. The Mojo theme is a really interesting one. It was actually developed by one of the front end developers who I worked with at Forum One. He actually came to us and started working for us and he had this theme that he was developing.

We used that on several different sites, I mean, pretty successfully. It had a slightly different take on responsive design. It was a little less mobile first, and so we did have some issues trying to get it to work on older browsers. But I think he's licked those issues.

Those are two that I recommend. There are a lot of other ones out there, so if I haven't mentioned them, it's just because I haven't worked directly with them.

You tend to want to kind of pick one and stick with it. Because if you keep hopping around between different base themes, then you're relearning it every time, you're relearning its limitations and its benefits, and you end up increasing your project time, as a result.

For WordPress, I've not worked with a lot of different WordPress responsive themes. I did, though, take the impress.js theme I mentioned earlier and it's got an interesting responsive nature to it.

I'm still tweaking, for Yuri's Night, I'm still tweaking the small and medium versions. If you look at them now, they're not quite as perfect as I plan them to be in the next few weeks. That was a lot of fun, because I took kind of this framework and put it into WordPress and then played around with that.

As I said, it gets back to how I said it's best to learn this stuff. That's how I still learn. I kind of took something a little bit outside of my comfort zone. I'm not as much of a back end coder or PHP coder as I used to be. I took something a little bit outside of my comfort zone and made myself learn enough to be able to do it and work with it. I learned a lot on the project by pushing myself to do that type of stuff.

Adam: Awesome. Wow. Lots of stuff we covered today. Good stuff, Jason. Thanks very much.

Jason: Thanks a lot, Adam.

Adam: For folks listening in, thanks for your support of the UIE Virtual Seminar Program and goodbye for now.