JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

059

059 JSJ jQuery Mobile with Todd Parker


Panel

Discussion

00:53 – Todd Parker Introduction

01:21 – DevChat.tv Indiegogo Campaign

01:55 – jQuery Mobile

04:13 – Responsive web design

06:17 – Mobile & Proxy Browsers

14:06 – Enhancements

17:11 – Plugging jQuery Mobile into Desktop Applications

19:11 – Using client-side MVC frameworks

21:52 – Filament Group and jQuery projects

28:26 – Theming

37:25 – Accessibility

44:18 – Progressive Enhancement

Picks

Next Week

Development Environments

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  CHUCKHey everybody, and welcome to Episode 59 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE:  Hey everybody. CHUCK:  Jamison Dance. JAMISON:  Hello. CHUCK:  Merrick Christensen. MERRICK:  Hey guys. CHUCK:  I’m Charles Max Wood from DevChat.tv. And we have a special guest, Todd Parker from the jQuery UI team. TODD:  Hey everyone. CHUCK:  You want to introduce yourself really quickly? TODD:  Sure. My name is Todd Parker. I am a partner here at Filament Group in Boston. We’re a small web design shop. And I’m also the project lead for the jQuery Mobile team. And previous to that, I was on the jQuery UI team as well. So, I’m both covered. CHUCK:  Did I say jQuery UI? I meant jQuery Mobile. TODD:  You did. I was covering for you though, it’s okay. CHUCK:  [Laughs] Awesome. Before we get too far into this, I want to make one announcement and that is that I’ve set up an Indiegogo campaign for the network of podcasts that this is a part of. So, we’re trying to build a website that has all the features that people have been asking for. Mostly it has to do with search and some RSS feed management stuff. So, if you would like to support the show, then by all means do so. You can do it by going to Indiegogo.com/projects/DevChat-tv. And I’ll put a link to the show notes so that you can find it. Alright. Well, let’s talk about jQuery Mobile here. I’m a little curious. I’ve played with it a little bit, but I haven’t really had to build too many Mobile sites. So, can you explain a little bit about what the focus is and how it’s different from the jQuery that we all know and love? TODD:  Sure. So, jQuery Mobile started its life, it’s very similar in concept to jQuery UI, so it’s a user interface framework that’s built on top of jQuery core. The difference between UI and Mobile is obviously UI is much more desktop focused, and Mobile is mobile focused. That said, jQuery Mobile, from the beginning, we’ve always sort of approached it as being web first. So we never, as a framework, have tried to ape a specific OS like some other mobile frameworks out there. We’ve always said it’s native to the web. You can certainly wrap Mobile in things like PhoneGap and create a hybrid app. But we sort of have a more neutral webby look and feel to it. And we’ve also always sort of embraced the principles of responsive design, which is the idea that there is a blurring of the lines between phones and tablets and desktop. And that’s going to continue to happen. So really, the Holy Grail here that we’re pursuing is a single, unified codebase that will gracefully work across all of those different devices. So, the layout and UI elements will adapt based on the screen size. And also, things like user input. So, we make sure that Mobile works with both touch events and mouse events and keyboard events and all those kinds of things, so embracing everything that is the diversity of the web, from the very beginning. And we’ve been very focused on the UI side of things. We do all the hard work on making sure that we figure out how to make the CSS behave, which is really tricky across all these platforms. So, we’ve been very focused on that as a project, making sure that the UI works really well across really, every device out there. If you’ve seen our device list that we support, it’s sort of insane. CHUCK:  You totally stole my thunder. I was going to sound all intelligent and ask you about responsive design. TODD:  Aha! JAMISON:  You stole my thunder too. TODD:  Oh, I’m sorry guys. CHUCK:  We are thunderless now. TODD:  Sorry. You are powerless. Yeah, so responsive design is a really big deal here at Filament Group. We’re huge fans of responsive design. We’ve been doing a lot of work with our friend, Ethan Marcotte, who’s sort of the guy that coined the term. He hangs out in the office sometimes here and we work together on the Boston Globe project, which is one of the better known responsive design projects. We sort of came into this project with that philosophy in mind. So I think when we launched, a lot of people — there are two expectations that were outside of what we were trying to do. One of them was, “Hey, why isn’t this just a DOM library that’s mobile-centric?” So basically, a replacement for core. And from the beginning when John Resig started this, he always wanted it to be built on jQuery core and not be sort of a competitor to that. There’s a lot of stuff the core team is doing to make things mobile-friendly with the move towards 2.0. So, there’s that happening. The other thing, the other misconception when the project came out was, “Hey, why doesn’t this look just like iOS. All I’m trying to do is build an iOS app.” And our response to that was, “That’s great.” There are ways of making that happen. But what we’ve all learned over time is that trying to mimic, to the pixel, any specific native platform is a fool’s errand, right? We’ve always said we’re going to be true to the web. And if people want to build themes on top of that, that look a little more native, that’s cool. And we have, well, quite a bit of a plugin ecosystem out there, around that, around plugins and themes. But what we’ve always wanted to do is something a little more all-encompassing that sort of feels right on a lot more platforms than just a single iOS app or an Android app. CHUCK:  Cool. So, what are some of the gotchas that you run into between the different mobile browsers? So for example, you got Safari on the iPhone, you’ve got, I don’t even know what it is, on the Android. [Chuckles] CHUCK:  I don’t remember what it’s called. It always just said ‘Internet’ for me. TODD:  Yep. CHUCK:  But you can also get Chrome or Opera for your mobile device. TODD:  Or Dolphin, or UC Browser or Firefox. CHUCK:  [Laughs] TODD:  I mean, it’s sort of madness out there. There’s a tremendous diversity in what’s out there. And the gotchas are pretty huge. JAMISON:  I was going to ask, how different are they? Aren’t they all basically, at least on iOS, they’re all basically just WebKit, right? TODD:  Yeah. So, iOS definitely makes our life easier. iOS doesn’t allow other rendering engines on its platform. So, when you download Chrome, you’re actually getting basically a WebView with Chrome look and feel. Although even in that case, Chrome has somehow managed to mess up quite a bit of things. [Laughter] TODD:  Yeah. We had all sorts of crazy things with popstate. We use an Ajax based navigation model and there are some really weird things that happened in Chrome, which is unexpected. I always just called it basically a toolbar. It’s a fancy toolbar. But they did a lot of improvements to the WebView somehow that broke a lot of pretty important things, so that’s interesting. Yeah, so across the platforms, there’s a lot of differences. If you even pick up your typical Android device, you have all of the typical renderers out there. You’ve got Firefox. You have both Opera Mini and Mobile. And Opera’s sort of interesting because if you’re looking at the desktop perspective, Opera’s always been sort of a very fringy browser. But in the mobile space, Opera’s really huge. I mean, you’re talking in the scale of hundreds of millions of users. JAMISON:  And the reason? TODD:  Yeah, and the reason for that is Opera Mini especially, is basically optimized for low-powered devices. So, if you have a feature phone, or a low-powered Smartphone, you’re going to probably either have Mini installed by default or you’re going to go out and have that be one of the first things you do. And Mini is basically a proxy-based browser. So, it essentially sends you an encoded picture of the page pre-rendered on the server. And so, if you have a low-powered device, that speeds things up quite a bit. But as you can imagine, getting a picture is interesting from an interaction perspective or when you’re trying to do more advanced things like use a slider or have animated page transitions and things like that. So, we’ve had to do tons of testing across all these devices. And they’re just very different and they’re very buggy. Android is really problematic. Android is the IE6 of mobile. [Laughter] JAMISON:  That’s funny, because the problems with IE6 were that we were stuck on this one rendering engine that was awful. And now, it seems like it’s lots of problems, but it’s from so many different crazy rendering problems from different engines. Can you talk a little bit about the challenges and approaches you use to dealing with proxy browsers? I know Amazon has, isn’t it Silk or something, the thing on Fire? TODD:  The Silk browser. JAMISON:  Yeah. So, what do you do to respond to events on a thing that’s rendered on the server and then sent down to you? TODD:  It’s sort of interesting. So, there are certain things that we had to do, for Opera Mini especially. So, jQuery Mobile has a bunch of UI widgets and one of the things that people also wanted that we built from the get go was people really want animated page transitions. They want to click on a link and have something, a page slide to the side. And so, the way that’s done is you need both pages in the DOM so that you can actually do the transition. So, when you click a link in jQuery Mobile, we’re using progressive enhancement principles, so we start with a link that goes from page A to page B. And then we have an Ajax navigation system that basically hijacks that link, formulates an Ajax request, pulls in the guts of that page into the DOM, enhances it and then does a CSS-based animated page transition from A to B. So there’s a lot of complicated stuff going on there. And so, what we found is that Opera Mini would do all sorts of weird stuff and a lot of it was timing-based. You’d click a link and you’d get a blank page, because the server, I guess, was in the process of figuring out what was happening and it was like, “Oh, times up. Time to send whatever I have.” And it’ll send you a blank page. JAMISON:  So, their server still has time to render and interpret, it’s still trying to run the JavaScript, right? TODD:  It tries very hard, yeah. It is rendering and running JavaScript. And it’s doing all sorts of fancy things, trying to keep up. Because the promise of a browser like Opera Mini is that you can go to a full desktop site and operate it. But it’s very slow. And the things that are especially slow are things that will require a repaint. So even a simple thing, if you have a collapsible widget on a page and you click on it, when that opens up, it has to go back to the server and fetch either the whole page or that piece of the page, that image of the opened version of it. So any time you do a user interaction, it gets really heavy. So, there’s a lot of things that we did over time for Mini. Things like, first of all, we kicked them out of the Ajax navigation system because there’s all sorts of problems with it losing track of where you were. Other things like we originally, with select menus, we have a nice pretty custom select menu that would open up, and that was very slow for it to parse and very slow for you to move through it. So, as a default, we now, when you tap on our pretty looking select menu, it actually triggers the native menu to open. And things that are native, like the native select menu, actually render immediately in Mini. So, it’s a lot faster. A lot of these things are little tricks to take advantage of whatever native capabilities are there and avoid things that are heavy. JAMISON:  But basically the answer sounds like a lot of custom work. TODD:  [Chuckles] There’s a lot… JAMISON:  For like, every individual feature. TODD:  The thing is, there’s no shortcuts. And what we’ve had to do is just test. So we have, here in Boston, I think, 70 different phones, tablets, eReaders that we test everything on. So, when we’re working on a feature, we’ll have a theory about how we want it to work. But we just do a ton of iterations. So, you test it out and see, “Does it work? Is it buggy?” And these are things that, like, you can’t go into it. Like you wouldn’t, server side and say, “Okay, I’m going to write a test for this. I’m going to write the code against it and everything is cool.” Like there’s a whole lot of black magic. JAMISON:  You still have to pick up the feature phone and run stuff on it. TODD:  Yeah. JAMISON:  So basically, it sounds like there’s a phenomenal amount of man hours put into this. TODD:  There is a huge amount of man hours put into this. And I think that’s really the value of the libraries. We spend a huge amount of time, blood, sweat and tears, to figure out what’s that perfect line that you can walk that gives you something that works everywhere and works really slickly in a better browser. We don’t do a lot of hack-y stuff. And that only happens by experience and a lot of testing. And so, if people are — if you’re a developer and you want to build a web app or a hybrid app, you can just pick up Mobile. It’s very easy to use, and you don’t have to worry. As long as you stay on the rails, you don’t really have to do a lot of testing, because you can assume that we’ve done a lot of testing for you. And I think that’s why it’s become very popular because a lot of people just don’t have the thousands of hours to sit there and figure out why select menus have stopped working in Android 2.3. [Laughter] TODD:  It is a lot of madness. CHUCK:  So, jQuery Mobile is kind of a mix between touch, functionality and making things work on a mobile device, and then you’ve also got all these UI widgets. So, it’s like enhancing jQuery so that it works well on mobile and giving you a lot of the features that you would expect out of something like jQuery UI. How much of it is enhancements that would go on top of jQuery versus some of the more visual elements? TODD:  I would say it’s mostly UI-focused. We’ve added a few things, like there are tools in the library that give you orientation change events and touch events and things like that. We tried normalizing those. So, there are utilities like that in the library. But pretty much the majority of what you’re getting with the library is a set of UI elements. So, you have a full set of form elements, sliders and inputs and all that kind of good stuff, and things like accordions and collapsibles and panels and pop-ups and overlays and dialogs and all that kind of stuff. Those are the things that you’re going to get in the library. It’s a lot of UI widgets that have been tuned for mobile and touch but also work just as well on desktop devices as well. And you know, trying to tackle some of the harder problems out there. So for example, if you’ve ever worked on a responsive design project, one of the really hard things to get to work is tables, right? So, imagine you have a financial report. It’s got 12 columns of data, and you have to see them all. How does that work at 320 pixels wide? It’s a really tricky problem to solve. And at Filament Group, we did a lot of experimentation and some other people did. And as a library, we said there’s two patterns here that we think are interesting. And so, we built those as widgets in the last release. And so for example, if you have a table of data, you can either use a reflow mode so basically each column of data now at a small width basically stacks. So, you end up with the column header becoming a label and the cell contents becoming data so it’s like label-data pairs. So that works really well if you’re presenting, say, a list of movies or stuff like that, that doesn’t need a lot of comparison across columns. And then we have a column chooser mode that basically, you just start with a plain old table, you add one data attribute and it will let you, as the screen gets smaller, you can choose which columns are most important, and the lesser important columns will drop away and be hidden. But we inject a button and a little menu so you can hit the button and you can, as a user, choose which columns you want to see. So, those are both things that would be really hard to build, but we do a lot of the heavy lifting for that. So you can just add one data attribute and tell us which columns are most important and now you have a fully responsive table. So that’s what we’re trying to do, is really solve the harder problems that people would probably punt on if they had to sit there and invent it from scratch. CHUCK:  That’s really cool. One other thing I want to ask about is, let’s say that I’ve built desktop full width application and I start doing some of the responsive design and things to it. What kinds of things am I going to run into as I start plugging jQuery Mobile into it, if it didn’t have it before? TODD:  That’s an interesting question. I think what we’ve learned with responsive design is it’s always very hard to retrofit something that’s desktop-centric into responsive. It’s much easier if you take a mobile-first approach, which basically, you start from the mobile side and you scale up from there. Your life is always going to be quite a bit easier. But if you were trying to retrofit, and there are a lot of people out there that have taken desktop sites. I think there was a guy I met that, I think he worked at American Century Bank, and they already had a full desktop website. It was a really complicated site. And they were just conditionally figuring out, using a server-side detect, whether you’re on a mobile device or not. And if you were, they were simply injecting jQuery Mobile and their custom styles, style sheet. And so, it was taking the exact same content that was on their website and reformatting it, which is sort of an interesting approach. So, that’s definitely something you can do. I think the things that people find a little challenging when they’re using mobile for the first time is, because if you use all the features and you do use the Ajax navigation, there’s a little bit of a different approach on how you handle things like scripting, because you’re not hooking into DOM-ready anymore. The page is already there and a new page is being pulled into the DOM. So, we have our own set of page-level events that you have to hook into. So, that’s usually one of the learning curve things that people have to get their head around a little bit. But for the most part, things should just work. So as long as your site is built with pretty straightforward semantic HTML, just adding jQuery Mobile and our style sheet will just moblify the whole thing. JAMISON:  So, what if you’re not building a server-side rendered app, but you’re using one of these client-side MVC frameworks? Is that going to clash with jQuery Mobile or have you seen people use them together with Angular or Ember, one of those things? TODD:  Absolutely. So as a library, that’s something that we definitely spend a lot of time thinking about. Just like how jQuery doesn’t get very prescriptive about which framework you should be using, we’re trying to be neutral and let lots of people fill in that part of the ecosystem. But yeah, there are a lot of MVC-style adapters for jQuery Mobile already. Angular is one of them out there already. And if you go to jQueryMobile.com/resources, there is a really nice page where we try to collect a lot of these things together. So it’s a very long page. But at this point, there’s almost 15 books that have been written about Mobile. And there’s a huge list of different toolsets and frameworks that you can use with it. But yeah, there’s a number of different MVC-style frameworks that people have used with it. And one of the little gotchas is, again, with the Ajax navigation, there are some settings that you need to make in Mobile in how we handle certain things, but they’re all just a matter of flipping the right switches so that we play nicely with an MVC-style framework. And a lot of people do that. Because when you’re building an app, that’s really where you want to be, right? You don’t want to be rendering markup on the server, you’re probably going to be doing a lot of client-side building. CHUCK:  So I’ve been working on an application, we’re using Backbone.js and I’m not sure if we’re using jQuery Mobile or not, to be perfectly honest. I’ve looked through a lot of this. Anyway, I guess my question is, it has its own little syntax for the events and the events don’t seem to be working when we try and do a, is it start touch event, in Chrome or in Safari in the emulator I’m running for iOS. So, I think it does some funny stuff with jQuery’s on function that creates an event on an object. But I’m just wondering, are there shims or things that you can plug into Backbone to make them work properly with jQuery Mobile? TODD:  There is a number of articles that have been written about using Backbone specifically with Mobile. I would say the resources page, I’m just getting it through right now, and there’s quite a bit of tutorials on those topics. So, it might be good to take a look at that first. If have trouble, definitely let us know in the [chuckles] issue tracker. We’re very active on GitHub so feel free to log an issue. CHUCK:  Alright. Sounds good. JAMISON:  So, you work for Filament. You’ve mentioned that a couple of times. Are they supporting your development of jQuery Mobile? Or is it just kind of you’re using it and you help out on [inaudible]? How’s that? TODD:   So yeah, Filament Group has been volunteering quite a bit of time for jQuery projects in general for the last, say, five years or so. We originally were involved — we were using jQuery UI quite a bit on client projects and so we were like, “Man, there’s a lot of features we’d like here and we’d like to fix some bugs and we really want to rethink the way theming works.” So, we got involved in UI and did basically a whole frontend redesign of all the widgets and the CSS and HTML. And along the way, we came up with a new theme framework and web-based tool called ThemeRoller that lets you create your own themes. And so, we did that over the course of about two years. And from there, John Resig asked us to help lead the mobile project. So, that was three years ago when we started that. As a company, I think we’ve probably worked 7000 hours on the project, or some crazy amount like that. A part of those hours has been sponsored. So, part of the project, we get sponsors from large corporations and things that want to support the project and that in turn sort of supports some development time at a discounted rate. That’s how some of the folks on UI/Mobile work. An [inaudible] will work on it during hours. So it’s a little bit of a mix. It’s like majority of it is donated time and it’s sort of different people here at Filament Group that plugin. It’s been a really interesting process to run a large-scale open source project like this. JAMISON:  Do you want to talk about some of the, I mean, you’re such a huge project both in terms of number of people using it but also the scope of what you cover. How do you organize it and make sure people are working on things that are useful and keep track of contributions and stuff? TODD:  Yeah. It’s just one of those things. I guess we spend a lot of time in the GitHub issue tracker and looking up pull requests and things. The thing that you’d probably be surprised about is that the jQuery projects in general is fairly small and the number of people that are working on core and even UI and Mobile are all fairly small teams. Mobile right now has probably eight people, sometimes ten people that are day to day contributors and then we have lots of help from the community people doing pull requests or helping us with issue triage or just reporting issues. JAMISON:  Wow! I thought it was a lot more than that. TODD:  Yeah, it’s a small group. And even that is fairly big even by jQuery project standards. Something like UI probably has a smaller team than even Mobile does. So yeah, the people that are keeping all of these projects going, it’s a pretty small number of folks out there that are at least providing the day to day eyes on everything. That’s why we are always out there seeing if there are people that are fired up and active. Usually, we find people on the issue tracker that are working on a project and they’re logging a lot of issues and/or doing pull requests for things that affects them. And we try to, as a project, be very open and say, “Hey, it seems like you’re really active. Why don’t you come aboard?” And we’ve had really good luck getting people that just were fired up and that wanted to help out the project. So, I do encourage anyone that wants to help reach out to us through GitHub and we’d love to have more contributions from folks. And this is also a mixture of other things. Some of those people that I mentioned on the team, some of those people are sponsored. So we’ve had a person who works at RIM who works on jQuery Mobile part-time. We have a really great developer John Benner who works at Adobe. He’s been working on Mobile full-time. We have a person who works part-time, he’s from Jive Software. We have one person who works at Intel. So we have different people that work for companies that are using jQuery Mobile for parts of either their tooling if you’re Adobe or they’re working on using jQuery Mobile for products, as in the case of Intel. It’s in their best interest to have somebody on the project who can make sure that it has good momentum. My job on the project is just to sort of help guide us and make sure that we’re on track in terms of listening to what the community wants and that we have a very regular release schedule and things like that. But it’s always a lot of negotiation. JOE:  Since Microsoft kind of officially blessed jQuery a while ago, have you seen much of a contribution from Microsoft corner, especially now that Windows Phone is around? Has there been a lot of contribution to make jQuery Mobile work well on Windows Phone? TODD:  That’s a good question. We actually have had on and off contributors from Microsoft on the project, which has been really cool. And one of the things that Microsoft did is they created their own Metro theme for Windows Phone. So, if you built a UI using jQuery Mobile, you can basically just toss in a CSS file and it completely changes the look and feel to look like a native Metro theme. And I think we’ve actually seen a number of companies do that. RIM, for example, just recently came out with a really polished Blackberry 10 theme for jQuery Mobile as well. That was an interesting thing that we were hoping would happen. Like I said at the beginning, Mobile was always very web-centric, fairly neutral in our look and feel. We didn’t want this to look like any particular platform because there’s nothing weirder than going to a website on your Android phone and it looks like iOS, right? CHUCK:  [Laughs] JOE:  So do you think Apple’s going to contribute an iOS theme? TODD:  [Chuckles] No. [Laughter] CHUCK:  Yeah, I was going to say I wouldn’t hold my breath. TODD:  I am not holding my breath. That said though, there’s a really great designer who actually has created an iOS theme. So, if you are using Mobile, there is now a really nice theme that looks like the Halo theme, which is the newer Android look and feel. There is one for BB10, Windows Phone 7, there’s an iOS theme, and that’s sort of perfect. As a project, we want to keep focused on something neutral but encouraging other people to, in that ecosystem, keep building custom themes that are more appropriate if you’re building a native app. For Microsoft, I think that was a really important thing for them, is to make sure that’s [inaudible]. MERRICK:  So, you’re talking about theming, and theming seems to be something that’s really difficult. What do you do to ship a project that is themeable? Do you only ship structured styles and then themes that sit on top of it? What are your design goals to be able to make something themeable? TODD:  Yeah, that’s a really great question and it’s tricky. So, we’ve sort of gone through this a number of times on client projects where people need a white-labeled software. And then like I mentioned it, with jQuery UI, we only came up with the new look and feel, we said, “Hey, we don’t know what the perfect color here is. Let’s just make this themeable.” And so we build a tool around that. In UI, we learned quite a bit of stuff about how to abstract away look and feel from structure, and that’s exactly what we call it, is structure. In the library, the way we currently are doing theming is each widget, if you have the slider for example, there is a slider.css and that consists of all the structural things that make it work, the padding, the sizes, the borders, all that stuff. And then we have a theme style sheet. And the theme style sheet is very generic. It’s not widget-specific in any way. A theme basically consists of colors and fonts and things like that. Within the theme, there are things called swatches, you can do A thru Z. And each swatch basically consists of a bar of normal page background and then typical button states. That’s the normal state, the hover state, the pressed state. And so, for each one of those collections of things, you can apply them to widgets. So, you’ll have a button on the page, I can just say we’re using a lot of data attributes for configuration, so we’ll say Data Theme A, and that’ll make it black. Change it to Data Theme B, it’ll make it blue. And so, we’re basically letting these colors flow over the structural styles. From a technical perspective, they’re actually flipped, but that’s sort of a minor detail. So, there’s a really clear separation between just setting things like gradients and colors and fonts and things and what defines the widget itself. MERRICK:  Got it. So, it’s really just structure versus style. TODD:  Yup. MERRICK:  Cool. CHUCK:  Is the style mostly CSS or are there actual JavaScript components to it? TODD:  There’s quite a bit of JavaScript involved and one of the things that we’re doing right now in the latest release is, because we’re using progressive enhancement, we want to start with a really simple markup. So, you can have a list view. The basic markup for that is just an unordered list and you have some linked list atoms, right, some really basic stuff. Once you add one data attribute to say, “Hey, this data will give a list view,” we go through and we we’re adding quite a bit of classes for you. So your markup can be really simple and we’re using JavaScript to add a bunch of classes for these button states and all these good things. And so, there is JavaScript for basically decorating markup. The only thing is that we’re doing in this latest release is, we’re actually refactoring that side of it quite a bit to reduce the amount or even the need at all for using JavaScript to enhance things. JOE:  Are you saying the themes also include HTML as well? HTML customizations? TODD:  No, it’s more like the way we actually will do it is if you have, say a list view, the JavaScript right now is looping through and on each list item, it’s adding a class of UIButton A, if you said that you wanted swatch A for that. So, it’s adding a class that applies the button-y look to that list item. And then we might add another class that adds an icon. So, we’re using lots of stackable classes to sort of build up the theme. So, if you have just a div on the page, you can add a class of ui-corner-all and it will add our standard theme border radius to all of the corners. And you can add another class that’s shadow, and another class that’s bar. So, each one of those things eventually build up a rounded corner drop shadow bar-looking thing. JAMISON:  So, that sounds a lot like object-oriented CSS where you have specific classes or whatever for portions of functionality. I don’t know. Someone give a good definition of object-oriented CSS, I’m kind of butchering it. But it sounds a lot like you described. TODD:  That’s exactly what it is. Props to Nicole Sullivan for that idea. So, that’s exactly what we’re doing right now, is lots of stackable classes that are very narrowly defined so that we can reuse those over and over again. That way, we add the same corner class, whether it’s a button or a list view or whatever. And that way, it’s a very consistent corner radius and we’re keeping our code very clean. One of the things that we’re thinking about is whether something like a CSS preprocessor would change the equation a bit. So, that’s something that we’re probably not going to do for this release. But maybe in the next release, we’re going to give that some thought because you can achieve similar effects by using a preprocessor. And the advantage of that is that you can essentially compile everything out to a point where it’s much easier to see what’s happening style-wise. Because we do a lot of like, we’ll add a generic class and then we’ll do some overrides at the widget level to make it the way we want it to be. And it makes a lot of sense if you know the whole system. But I think there can be a learning curve in how to customize things. So, that’s something that we’re always looking at what we’re doing and saying, “Is there a way to make this easier or make it more flexible?” But currently, we are using an object-oriented CSS model that doesn’t require a preprocessor. Back three years ago, that was not really something that we wanted to do as a project and just add it in another dependency. MERRICK:  In terms of the themeability, do you guys have any effort in terms of the jQuery UI project to make the themes similar in terms of the learning curve? Are they architected similarly? TODD:  Yeah, they actually are architected very similarly. There are still all the same abstractions in UI. The only difference is UI essentially has one theme swatch. So, when you’re doing ThemeRoller in jQuery UI, you can only choose one button. [Chuckles] So your button, if you want a blue button, that’s cool. But if you wanted a blue button and a green button, you really can’t do that very easily. You have to actually add a second theme and you can scope it. It’s sort of not built for that. So at Mobile, that’s the main thing that we did, is we added this notion of multiple swatches so you can build up to 26 color swatches. So you can have a silver button and a black button and a red button and a blue button and a green button. And then you can just, on a button on the page, you can say, “This is really important so I want it to be a green button.” And you can just easily add that, the theme attribute on there and apply that. So, that’s the only major difference. Otherwise, what we already talked about, the abstraction between structure and theme and the stackable classes still applies. CHUCK:  Do you find that some of the features, for example, with the themes that you build into jQuery Mobile translate well to jQuery UI and affect the design over there? TODD:  Yeah, there’s actually quite a bit of big thinking right now on the jQuery project just in general about what’s the relationship between jQuery UI and jQuery Mobile because they do the same thing. They’re both UI frameworks. And if you believe like we do that the distinction between mobile and desktop is very fuzzy already and it’s just going to have to go away if you’re going to be taking a more pragmatic approach, that you really should be using responsive design, we probably really need to knit these two libraries much more closely together, right? And so, we’re doing quite a bit of work on that side of it. In this current release, we’re actually pulling in the jQuery UI tab component and using it in Mobile. So, we’re trying to figure out a couple of things. One, we’re harmonizing our cores. There’s like a jQuery UI and jQuery Mobile core. And we’re basically using the same core at this point. We both are based on the Widget Factories. So, there’s a lot of similarities there in terms of that, how we’re structuring our code. And then, one of the things that we’re working on here is trying to figure out how to have a shared infrastructure for theming. Ideally, there would be one ThemeRoller tool and that would work across UI and Mobile in the short term, and then maybe in the long term, there is just one thing. I think it will be good for UI to actually move it more towards the mobile theme framework just because it’s newer. So, we’re using some more modern techniques in some of our theming that just wasn’t available four or five years ago. We’re working on the UI version of it. So, that is all stuff that is under way. CHUCK:  One thing that I think is interesting that you pointed out, you’ve done it a couple of times, is that the line between mobile and desktop is blurring. We even see these days, systems like Windows 8 where they’re building touch screens into the machines that run it. And yeah, it really wouldn’t be shocking to see it move that way as things move along. One thing that I’m curious about, I’m going to change the topic a little bit, last week we talked to Brian Hogan about accessibility. And I’m really curious, it says that you do the ARIA stuff from W3C’s specification and things like that. I’m wondering how those features fit in with everything else. And I’m also curious as to whether or not that’s going to be moved up to jQuery or jQuery UI. TODD:  Sure. Yeah, accessibility is a very important thing for both UI and Mobile. And in its current state, both UI and Mobile are accessible and we both do use ARIA pretty extensively throughout our widgets and give quite a bit of thought not just to ARIA but things like tab focus and keyboard input, because it’s all well and good that you know that something is widget X, but it’s much more important that you can still actually use it. Both projects have spent a lot of time thinking about accessibility, working with folks that are in the accessibility community and trying to do the best we can to just make it work because accessibility is a really hard thing to get right. And we actually wrote a book at Filament Group about progressive enhancement and how to build rich UIs that were accessible to everyone. So, building in ARIA and things like that were really important back then. But yeah, there’s a lot of questions. When we were writing the book, it was like, “Is this really the right thing? Do we have to use this role or that role? Or this is unprecedented and how does this really work?” And so, what we’re trying to do is libraries and have it just work so that as long as you’re using UI or Mobile, it’s accessible. And you don’t have to do any work. You don’t even have to know it’s happening, but it’s there. There’s some interesting things with accessibility, though. We got a lot of feedback recently and one of the pieces of feedback we heard was that it’s really cool that when I open up a jQuery Mobile page, it uses ARIA roles and things like that. But when somebody uses jQuery Mobile within a packaged native app, like as a hybrid app, they actually don’t want to hear any of the ARIA roles in that context. It’s confusing, which sort of surprised me. But the feedback we heard from people who are actually using screen readers is that it just doesn’t make sense. That there’s other ways of navigating with an app and they don’t want to hear all the ARIA roles. So, we actually have a few open tickets right now which tap a configuration switch that will, you turn that on and off so you could say it’s a native app, for whatever reason, I want to turn off all this ARIA stuff and quiet down the interface. So, it’s always evolving. What works and what makes sense for people is something that we’re still learning. It’s an interesting area. But it’s very important to us, that’s for sure. And part of that too is, we always talk about this with progressive enhancement, when you start with HTML, it’s accessible. If you build a nice semantic HTML page, it’s 100% accessible and it’s only when we start adding CSS and JavaScript do we start breaking that accessibility. And then, we have to put great care back into adding keyboard shortcuts and adding ARIA roles and states and regions and things like that to start describing these more complicated interfaces. So, the fact that we use progressive enhancement is also nice too because if you want, you can flip off JavaScript and you should still have a very usable experience. We’re still using links and form elements and the whole library is geared towards making you write good semantic HTML. It sort of freaks out if you don’t, which is by design. So, that’s another accessibility angle too. You can make sure that it works even if JavaScript is off or you choose to be using a text-based browser. CHUCK:  Yeah, one thing that came up after doing the accessibility episode, and this is something that I think the rest of the panel will be interested in as well, is that our transcriptionist actually sent an Email to my assistant who’s the one that provides her with the audio files. And she actually mentioned that her son has a hearing disability. So, it was very interesting to me to know that it’s everywhere, the accessibility issues and just being able to take care of that. I love that it’s a no-brainer thing with jQuery, or at least it’s getting there with jQuery Mobile. So that you don’t have to think about it, you just have it. TODD:  I think that what we found is it’s much better to use the framework in some ways to get people to do the right thing. You know what I mean? So, I think being slightly opinionated as a framework is good, because we don’t advocate that you serve up an empty page and populate it later. [Chuckles] We recommend that you start with a page that’s fully functional and then you layer on all this good stuff on top of it. And I think that’s just important. And I think that’s also very much in line with the philosophy of jQuery. When jQuery came out, it was all about making everything work cross-browser and making it work in a really simple way. And I think that’s the spirit that we’re trying to [inaudible] which is lowering the barriers to do the right thing. And that takes on a lot of facets. We’ve already talked about the fact that this works with screen readers, that it works on pretty much on any device you might want to use it on out there. The other part of accessibility is lowering the developer barrier. So as a project, we were one of the first projects to use a lot more data attribute based configurations so you can actually use the library and configure these widgets, but you don’t have to write a lot of JavaScript at all. And people that write JavaScript will say, “Ah, that’s garbage. It slows things down. Blah…blah…blah…” And you don’t have to use that. These are regular old jQuery plugins. But it’s really amazing to see people that were designers or that were just educators or in government using jQuery Mobile to build stuff that can reach everyone and is accessible. And it’s very easy for them to actually build these things. They don’t have to spend $200,000 and hire some fancy firm. They can build a pretty solid-looking web app just learning plain old HTML. And I think lowering the access barrier on the developer side is equally important, I think, for a library or framework. That’s something that we’re really proud of as well. CHUCK:  One other thing I want to ask you about, you keep bringing up progressing enhancement. And you just talked about how you take a basic HTML page and then just layer stuff onto it. Is that what you mean? TODD:  Exactly. The philosophy with progressive enhancement is pretty simple. It’s just, imagine a world where CSS and JavaScript didn’t exist and you just have the semantics to express yourself of HTML. So, you sit there and you say, “Okay, I’ve got this form or I have this content. Based on what the limited vocabulary I have in HTML semantics, how do I express that as richly as possible?” And once you’ve done that and only when you’ve done that and things work and make sense, do you then start thinking about what happens with CSS and JavaScript. And it’s a very future-proof kind of approach anyway because HTML is always going to be around. It’s been here forever and it’s sort of like the cockroach of technologies, right? It’s always going to be here. And so having a nice, clean, semantic, well-structured document is just a really great thing. You can pull out of jQuery Mobile and put in some other stuff or your own custom styles and scripts and just get that new life. So, I think that’s a really good thing. And the other side of the coin from progressive enhancement is this idea of graceful degradation. So, we build something and when it breaks, we give them some alternate content, which is okay in theory and sometimes we do use that technique. But in general, it really lies on the developer to create two different experiences. And a lot of times, when time is short, they just punt on it. So, it’s much easier to say build the simple HTML form and then we’ll give you the whizzy sliders on top of that, but in the end, if you shut off JavaScript, it still works. And I think that’s been another reason why Mobile’s been very popular is it does use JavaScript, it’s a JavaScript library. But it’s also based on plain old good HTML semantics. And I think you’ll see there are projects like Bootstrap, which is now insanely popular, and that also takes that similar approach. It’s pretty, clean, semantic markup with some classes. And if you wanted some extra interactivity, there are some plugins you can add on top of that. So, that’s sort of even taking that a little bit further. And I think that’s definitely a really nice solid foundation to build anything on top of. CHUCK:  I like the approach. I really like it. If I’m building my own library, how do I take that kind of approach there? Is it the same kind of thing? Just okay, how do I make this a little bit better, how do I make it a little bit better and does it still work when the JavaScript’s not there or has an issue? TODD:  Yeah, exactly. The approach that we talk about quite a bit in our book is sort of this x-ray approach. If you look at something that’s really slick, you have to look through that and figure out what you’re trying to communicate with it. The slider is the simple example. So you have a cool slider, but really, what you’re trying to do on the slider is usually set a numeric value, right? So, you could just start with an input type of number, you can set your min and max attributes, you can set your value attribute. And then what you can do is you can then write the JavaScript to first of all, be cautious and say, “Are you a capable device?” And there’s different criteria, feature test based criteria you can use to decide that, using tools like modernizer. But once the script has determined that, “Okay, this browser can handle a more enhanced experience,” what we usually advocate doing is using JavaScript to sort of parse those HTML attributes, parse the richness that’s already in the HTML and then use that to configure your widget. So, you’re parsing the min/max value attributes, the step attributes, those kinds of things, and plugging those into the JavaScript widget and then creating the enhanced experience on top of that. The cool thing is it’s easy to configure because you’re just doing HTML. And if there isn’t a native attribute for something, you can use the HTML5 data-attribute kind of thing to make up your own, which we do quite a bit on Mobile. But you don’t have all this text strings and stuff embedded in some sort of JavaScript config. Instead, you’re just writing the markup into the page and letting the script figure out how to configure itself based on that. So, that’s just a simple example of how you would use progressive enhancement. You can take it pretty far. We actually, Filament Group, wrote a really cool plugin called Visualize. And the way Visualize works is, let’s say you wanted to do a pie chart or a line chart or bar chart on the web, normally that’s going to be done in some tool like Visio or Excel or whatever and export it as an image which has really very little meaning. So, if you’re on a screen reader, even if you’re a good web developer and you wrote an alt description for that, what do you think that alt’s text is going to say? It’ll say, like, “Chart of 2013 sales data.” [Chuckles] You know, great. That doesn’t mean anything to me. So, Visualize takes that approach of progressive enhancement and turns everything on its head. It says, “Well, what are you trying to communicate in that chart?” You’re trying to communicate information. There’s data there. So, Visualize works by, if you say you wanted to do a bar chart, you put an HTML table in your page that has all the rows and columns and all the data and all that good stuff. And you can very simply call Visualize on that table and pass in, “Okay, I want this to be a bar chart.” And the plugin then parses the data out of that table and uses canvas to generate a chart. And then you can choose to hide the original table or leave it there or whatever. So, if you’re on a screen reader, you now get a table that gives you all the data that you need. And so, that’s a more advanced sort of idea with progressive enhancement. But pretty much anything that you can imagine can be translated into this progressive enhancement framework. There’s a very small number of things that I would say, “Eh, it’s probably not worth doing.” If you’re building a Photoshop clone in a web browser, you may not want to try to attempt to build that with PE, you may not want to use it on a screen reader. But for the most part, you can communicate really complicated things in HTML, I would argue, and provide a pretty good experience. CHUCK:  Alright. Well, we’re running close to the end of our time. Are there any other questions you guys have? I know I kind of monopolized the conversation here for a little bit. JAMISON:  I don’t think so. I think that was really clear. TODD:  I’ve answered all the questions? There’s none left in the world? Excellent! JAMISON:  Well, I have some about life, but… TODD:  [Chuckles] CHUCK:  Yeah, and somebody else probably has questions about the universe. And I have questions about everything. TODD:  I am not a deep thinker. You will not get answers from me on those things. CHUCK:  Alright. Well, in that case, let’s go ahead and get to the picks. Joe, do you want to start us off? JOE:  Yeah, you bet. I’ve got two quick picks here. The first one is the book ‘Disenchanted’. I read this a little while ago. It’s a story about a guy who dies and is a walking ghoul. He’s roaming the land trying to free himself from this curse and it’s pretty irreverent and quite funny. And I really enjoyed reading it, so I highly recommend that. It’s called ‘Disenchanted’. And my other pick is a brand new release that I haven’t had a chance to play, but I’m really excited to play. It’s made by Sid Meier. It’s an iOS game. And it’s called Sid Meier’s Ace Patrol. So what it is, is it’s a World War I based turn-based flying game where you play like a squad of World War I flying aces. And it apparently has RPG elements where your guys will level up. But it’s made by Sid Meier and as far as I’m concerned, Sid Meier doesn’t make anything bad. [Laughter] TODD:  Nice. JOE:  Please don’t mention any of the bad games that he’s made. JAMISON:  Which ones? There are none. JOE:  Right. So anyway, those are my two picks. CHUCK:  Awesome. Merrick, what are your picks? MERRICK:  My first pick is going to be a musician, actually two. It’s called Zeds Dead & Omar LinX. And it’s like this really cool mixes, like electronic wub-wub-wub-wub-wub dubstep with rap. And it’s kind of a weird name, Zeds Dead & Omar LinX. I’ll put the link in the show notes. Then my second pick is RequireJS. I think James Burke has done a fantastic job on it. I still enjoy using it after, oh man, two plus years, three years. CHUCK:  Awesome! JAMISON:  Now, because you’re younger than me that means your music is automatically cooler than the music I like. I ought to pay attention to that. [Laughter] JAMISON:  I’ll have to check it out. CHUCK:  Nice. Yeah, I’ve recently gotten on to a project that’s using RequireJS. And holy cow! It makes things so much easier. Jamison, what are your picks? JAMISON:  So, I have three. First one is Ember101.com. This is a series of introduction to Ember videos done by Ryan Florence. He’s a guy here in Utah. And they’re really good. They’re probably the best gentle introduction to Ember that I’ve seen so far. The second pick was just a little tool that was invaluable for adding my funny pictures to some conference talks I did recently. It’s called Gifsicle. It’s just a little command line util to manipulate GIFs. So, you could slow them down, speed them up, just expand them, shrink them. You can do all this stuff with ffmpeg and bash, but it’s just a nice wrapper around that. So most of the things that you would want to do with the GIF, you can just do with one little command line flag. And my last pick is, it’s a tool for bundling vim plugins, or installing the plugins, I should say. It’s called Vundle. I was using Pathogen before, and Vundle is a million times nicer because it gives you a really nice syntax for specifying the plugins you want to install right inside your vimrc file. So, you don’t have to hack together your own ghetto thing that everyone always creates with Pathogen, where you embed git submodules, you have a little script that downloads these list of files you create yourself. So basically, it does all the work for you. It’s pretty good. Those are my picks. CHUCK:  Cool. Alright, so I’ll go next. I’ve ordered a couple of things off of Amazon recently that I’m really excited about. One of them is the D-Link SharePort Go. It’s basically a wireless router except that it has, like most wireless routers, it has the CAT5 or CAT6, I forget what the plug’s called, but anyway. So, you can plug it into the Internet in your hotel room and stuff, but if you’re somewhere where you can’t plug it into the Internet because you don’t have a CAT5 or CAT6 connection, you can actually set it up so that it gets its Internet connection from the hotel wireless and then you can connect all of your devices to this device. So then, you basically get the benefit of being able to have five or six devices on one connection on the hotel system. The reason that it’s nice is that when you’re traveling, a lot of times, the hotels will only allow you to have one or two devices on their wireless. And so, this is a way to get around it. The other thing is, is it has some security features. So that if you’re on some insecure WiFi, you could just hook this thing up and off you go, and you’re working on a more secure wireless. I’m really excited to try it out. I’m actually heading out to Denver as soon as we’re done here. So, that should be cool. JAMISON:  What if it’s terrible, are you going to unpick it next week? [Laughter] JAMISON:  What if it turns your Internet upside down? CHUCK:  Then I don’t know. TODD:  So Chuck, does it just produce its own WiFi or does it actually have hardwires for you to plug in your own devices like through a wired connection? CHUCK:  It just produces its own WiFi. So you can only connect wirelessly. It also has a USB port on it, so if you want to connect a hard drive or USB thumb drive to it, then you can do that and it’ll share that as a file server to all of your devices as well. So, it’s pretty slick. The other one that I’m going to pick is just having a — I got a rather cheap gaming mouse, but it makes playing some of the games that I play a whole lot simpler. And so, I’m going to pick that as well. And then the last thing I’m going to pick, and these are all things I’ve ordered off of Amazon, is I got my wife an Apple TV for Christmas, and we were having trouble figuring out where to put it. Anyway, there’s a TotalMount on Amazon that you can get and that just hooks it to the back of the TV and then that seems to work just fine. So then, the little remote works and everything and it’s just up there and out of the way. So, those are my picks. Todd, what are your picks? TODD:  So I think my first pick is Sonos, because I am cracked out on Sonos right now. So, Sonos is this wireless audio system. I don’t know if any of you guys have it, but it’s really cool if you listen to things like Spotify. JOE:  I thought it was a drug. It sounds like one of those [inaudible]. TODD:  I know, right? So, there are basically a bunch of different little speakers. They’re powered, so they have their own amps, but the cool thing is they basically have little PCs inside them so they have clients built into them. They connect through their own WiFi mesh network. And the clients on them can run things like Spotify and Pandora and stuff like that. You can just plug each speaker into the wall and then you can start streaming whatever you want to them. And you can hook them together so they’re all playing in sync. It’s one of those things where you buy one and you end up with six, three months later. CHUCK:  Oh no! TODD:  You don’t know what happened to you. CHUCK:  I think you just spent a whole bunch of my money. TODD:  Yeah. JAMISON:  They’re multiplying. [Chuckles] TODD:  It’s pretty cool. It’s pretty addictive. I’m just jonesing for their — they have a nice wireless subwoofer. So, that’s what I’m jonesing for now. CHUCK:  Nice. TODD:  Yeah. And then my next pick, I guess would be, I’ve been playing around this week with Sketch App. I don’t know if you guys ever end up having to do any sort of graphic design stuff, but it’s a really cool app. It’s vector-based, so it’s sort of like the poor man’s Illustrator, but it’s really good. So if you’re a UI designer, it’s really cool. You can basically build UIs really quickly and it sort of encourages you to design in a way that’s much more like a developer. So when you’re plugging stuff in, you’re using the same syntax that you would with CSS. And in fact, the coolest thing is you can highlight a bunch of elements, so you highlight a button and a button and some text and some other things, and then you could copy its CSS. And it writes really nice CSS that you can then copy out and re-factor and get into your style sheet. So, there’s much less lost in translation in between designers and developers. That’s a pretty cool app. I should also say, yeah, Require is awesome. We use it all on jQuery Mobile for all of our dependency management. It’s great. And oh man, we should give a shout-out to GitHub. We should all just give GitHub a big hug right now because our lives are so much better with GitHub. CHUCK:  That is so true. I have to say, I forgot another pick that I want to do, and that is iOctocat, which is an iOS app for GitHub. I’ve been trying it out and it is freakin’ awesome. TODD:  Yeah? That’s for iOS? Really, what does it let you do? CHUCK:  It basically gives you a list of all your news and activities. It’ll show you all your repositories, all of your organizations, your gists, all that stuff. You get access to all of it through your iPhone or iPad. TODD:  Very cool. So yeah, GitHub is always, it’s not really on my list, but come on. We have to say we love GitHub. CHUCK:  [Laughs] TODD:  The other tool we’ve been using a ton here is Grunt. Thanks to Ben Alman for his awesome little tool for automating all of our frontend lives. We built a lot of tools around Grunt and if you haven’t used it, it’s pretty awesome. We use it for concatenating files. We use it for exporting svg graphics and all these fallbacks that write CSS for us. It does all sorts of stuff. So, Grunt is great. And lastly, I’ve been wasting way too much of my life playing the LEGO Batman. It’s the DC Super Hero edition for iOS. I just have one more level. I’m on the final battle right now. But it’s a blast. I’ve been playing it with my five-year-old. [Laughter] CHUCK:  More of my money, right there. JAMISON:  I don’t have a five-year-old and I’m going to play that game. TODD:  You don’t need one, man. It’s great. You can unlock every possible superhero. But it’s fun, it’s fun. CHUCK:  So, you play it on iOS? TODD:  Yup. CHUCK:  And you can play it multiplayer? TODD:  No, that’s the one bummer, you can’t do multiplayer on this. I’m currently also in parallel working through the LEGO Star Wars on Wii, all six movies. Now that one’s multiplayer which is way better. So this is good [inaudible]. CHUCK:  Yeah, we have those for the Xbox. We have Star Wars and Indiana Jones and The Hobbit. TODD:  Yeah, they’re a blast. CHUCK:  Yeah, they’re fun. They’re way fun. TODD:  So, this is one just to play by yourself when you’re on the subway. But it’s good. CHUCK:  Do they have this for Xbox and stuff, the Batman one? TODD:  I’m not sure. I think they do, though. I think these are all ports of the DS version or something, of all these. I think all these, it’s like last to iOS, but yeah, I think they’re all on Xbox. CHUCK:  Alright, cool. Well, you just spent five of my bucks. [Laughter] TODD:  There you go. CHUCK:  Five Chuck bucks gone. TODD:  Boom! Oh you have to upgrade your guys too, so sign up another five bucks for some extra points. CHUCK:  Oh, I don’t know. TODD:  You need Flash. You need the Green Lantern. Don’t deny it. [Laughter] CHUCK:  Oh, I’m a cheapskate. It’s funny, because I will buy the games, and then I refuse to buy upgrades, which is kind of weird to me now that I think about it. Anyway, alright. Well, thanks for coming on the show. It’s been awesome. It’s been really fun to talk about this. And hopefully, some folks will go out and build some awesome mobile web apps and do some cool stuff with some of the hybrid apps things that you can do as well. TODD:  Very cool. Well, thank you for having me. It’s been a lot of fun. JAMISON:  Yeah, thanks for coming. It’s been really educational. CHUCK:  Thanks. Definitely. TODD:  Excellent. CHUCK:  Alright. We’ll talk to you later. TODD:  Thanks guys. Bye. CHUCK:  Bye.

x