Episode 105 of The SitePoint Podcast is now available! This week Louis Simoneau (@rssaddict) chats with Max Wheeler (@makenosound) and Myles Eftos (@madpilot) about the state of the mobile web. We talk about responsive web design, native apps vs. mobile web apps, PhoneGap, and the changing mobile landscape.
Listen in Your Browser
Play this episode directly in your browser — just click the orange “play” button below:
Download this Episode
You can download this episode as a standalone MP3 file. Here’s the link:
- SitePoint Podcast #105: There’s Something About Mobile with Max Wheeler and Myles Eftos (MP3, 38:21, 48.6MB)
Subscribe to the Podcast
The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.
Links Mentioned in this Episode
- TumblrThemr
- PhoneGap
- Jeremy Keith: Sea Change
- Responsive Web Design
- Media Queries
- Yiibu.com
- Rethinking the Mobile Web
- cssgrid.net
- Less Framework
- Build and Analyze podcast
Interview Transcript
Louis: Okay, welcome to the SitePoint Podcast. This week on the show we have two web designers and developers from here in Australia, so first up we’ve got Max Wheeler, and we’ve also got Myles Eftos. Now, I saw both of you give talks at Web Directions South in Sydney at the end of last year, and given your talks were in some way related I wanted to have you both on and talk about a couple of things related to that. But before we dive into any of that can you just maybe introduce yourselves quickly, tell me what you do, and what you’re working on at the moment, do want to start with Max?
Max: Yeah, sure, so I’m Max, I’m the generally mumbly one, so I apologize in advance if there’s anything you can’t understand. And I’m mostly a kind of front end designer, I work for a company called Icelab based out of Canberra, at the moment I’m working on working on something we just released actually which is a little tool called TumblrThemr which is basically to make the process of developing themes for Tumblr a whole lot easier while letting you do it locally, so we just released that yesterday.
Louis: Very interesting. Myles?
Myles: Yeah, I’m based out of Perth, I’m more of the backend developer, but I dabble in front end stuff as well, generally doing Rails, but I’m at the moment actually working on a number of iPhone and iPad apps using web tech and I’m in a couple other projects as well mainly in Ruby on Rails.
Louis: Right. So, like I said earlier, you guys both gave talks at Web Directions South last year, Max your talk was on the geolocation API’s in I guess JavaScript and HTML 5.
Max: Yes.
Louis: And, Myles, you gave a talk on PhoneGap. So before we dive into talking about that, do you want to just maybe give a quick talk about the talks you gave. So, Max, you were talking about geolocation, and I guess one of the things that struck me when I saw your talk is that I guess it’s one of those things that you think is going to be harder than it is.
Max: Yeah, I think you’re right. The geolocation API, or the JavaScript geolocation API is actually really, really simple to use, and there are some kind of gotchas that you need to think about, but to get the very basics of it are incredibly easy to use, just kind of one JavaScript call and if the device supports it you can get a fairly accurate, get some fairly accurate information about where your users are at any particular moment.
Louis: Right, and that’s pretty well supported across a lot of browsers right now.
Max: It is, yeah, yeah. I think it’s supported in Firefox, Safari and Chrome on the desktop.
Myles: IE 9’s got it now, too, yeah.
Max: Yeah, yeah, that’s right, I think it wasn’t in the early betas but it is in the final release, and it’s obviously much better supported in the mobile space as well, so Mobile Safari and the Android browsers support it.
Louis: Right. And, Myles, you were talking about PhoneGap which I guess is a technology that a lot of people might not be familiar with, so you want to give just a little introduction as to what that is?
Myles: Yeah, sure, it’s basically up until PhoneGap sort of came out if you were developing iPhone or iPad or Android applications you’d have to go out and learn Objective-C or Java or C++, which as a web developer who’s used to scripting languages was a bit of a pain, some bright spot worked out that you can embed a WebKit view in most of those phone apps and came out with this library called PhoneGap which basically allows you to write HTML, CSS, and JavaScript, embed it in a skeleton app and then it will run, well, it runs natively so it means you can put it in app stores and you can install it like a native app, and all while using the technologies that we’re used to and doing it sort of cross platform because you can obviously use the same HTML and JavaScript and just flip out some CSS files really easily.
Louis: And one of the cool things about PhoneGap is that on top of just giving you access to a web view that will run natively, it also sort of ties into some of the more device-centered API’s that the native development framework makes accessible.
Myles: Yeah, that’s right. So I mean obviously HTML 5 exposes a few of them, like the geo API, but the things like accessing the camera, accessing accelerometers, and also accessing local file storage and local databases, it gives you an API into that so you’re not reliant on the browser for that stuff when in fact the browser can’t even do some of these things.
Louis: Right. So, if someone was looking to start developing for native platforms would you recommend looking at PhoneGap before looking at some of the native; is it ready for prime time? What are the major gotchas?
Myles: Yeah, it’s definitely ready for prime time, but you’ve got to understand that they’re different, so you’re not going to get — you don’t get access to native widgets like buttons and calendar views and that sort of thing, so everything you put into the UI you have to design yourself using HTML and CSS, which is definitely possible; a lot of the CSS3 stuff that’s in many of the mobile browsers, but it’s still a lot of work to get it looking really native, and it can be — you’ve also got to manage all of the transitions and all of that sort of stuff yourself, so there’s a bit more work upfront a lot of the time. That said you’ve got a lot more control over the UI as well, so if you’re doing anything a little bit crazy and you can do it in HTML then it’s all good. The best thing about though is that the development speed is a lot faster, especially when you take into consideration you probably have to go learn another language to do it natively, but there are other avenues as well if you don’t want to be learning Objective-C or Java.
Louis: Right. So I guess that wraps that up. What I really wanted to get you guys on to talk about is I guess a question of designing for mobile devices because I guess we’re definitely at the point now where that’s becoming pretty mainstream, there are a lot of devices out there, and cheaper devices, that have good browsers so you can really develop full-featured websites with them. And I guess it was kind of brought on by a blog post that Jeremy Keith published about a month ago and that just got a few more comments on Twitter fairly recently and it got me thinking about it. So his argument is that what people should be doing is doing responsive design of their regular websites but using CSS media queries to make those adaptable to different screen sizes. So, I guess that’s interesting because his argument is that there are so many different devices and so many different sizes that if you want to develop a specifically mobile website that you serve to mobile devices and then a completely different site that you serve desktop devices, what do you do for tablets or for Netbook or Kindle or whatever. But I guess you guys might have different perspectives on that, I guess there are kind of four levels of ways you can go, you can either go sort of responsive design on your desktop site, you can develop a custom mobile site that you serve up only to mobile customers, you can develop a native app using something like PhoneGap which is cross platform or you can go full native. And I wanted to know what you guys, because you’re both sort of involved in this space, what were your opinions on those questions, because I think it’s a lot of — it’s something that a lot of developers are going to be starting to look at now.
Max: Yeah, sure, I mean I think it really depends on the kind of target, what you’re trying to achieve and your target market. I think responsive design is great.
Louis: So maybe it’s possible some people listening might not be familiar, I know I introduced it pretty quickly there, but can you just give a bit of a quick rundown on what sort of media query based responsive design means.
Max: Yeah, sure, so responsive design is the term that refers to a technique kind of put forward by Ethan Marcotte in a seminal article on A List Apart, and the idea is that you use media queries in CSS which you probably normally see using, like by specifying @media print or @media screen, but in this case you can actually query the pixel dimensions or a bunch of other things like the DPI and the orientation of the user screen and then serve them different CSS depending on the capabilities of the device or the screen size, and that means that you can restyle your pages and lay them out so that they’re kind of perfectly laid out for any particular given size from say iPhone size at 320 pixels wide to gigantic desktop screens, the new iMacs which are 2700 pixels wide, you can kind of adapt your layout and have it respond to the particular resolution of the user’s browser or their device.
Louis: Right. And so if someone wanted to have a look I know there’s one site which is kind of a showcase of these kinds of designs, it’s at Media Queries, so the last two letters are the domain, so it’s mediaqueri.es, has a bunch of really nice designs, and if you just resize your browser window while you’re looking at it you’ll see how it reflows and adapts to a very narrow browser window like what you’d get on mobile. But I guess some people take issue with that, so some people would say it’s better to develop a full blown mobile site specific for mobile, and what do you think would be the reasons you might want to do that instead of opting for a media query based responsive design?
Max: Sure, I mean I think media queries are fine if you want to present basically the same information just kind of relayed out to your mobile users, so in some cases that’s totally appropriate; our company website, for example, we don’t really need to give anyone any more information or any less information than on a mobile device than on a desktop, so using media queries makes a lot of sense. But for kind of more powerful applications or web applications where people are trying to achieve certain things then you may want to restrict or limit the kind of functionality of the site and limit the scope of things that people can do to make it more appropriate for mobile. So Twitter’s a good example of that, the main Twitter site is fairly complex and fully featured, but the mobile Twitter site just lets you kind of get to the core of what Twitter is, which is viewing the timeline and updating with your latest Tweets and viewing your friends’ stuff; there’s not that extra cruft that you get on the main Twitter site.
Myles: And then Twitter, you can take the Twitter example one step further because of their native application is where the majority of their traffic actually comes from, so that’s a perfect example of that fitness of purpose, it makes sense for the Twitter app to be a native app, something that’s there that you can hit on your home screen and it pops up and does all of that stuff for you rather than you having to wait for screen reloads or HTML running in a mobile browser. So, yeah, you’re bang on Max, it’s all about fitness of purpose really.
Max: Yeah, I think that’s right.
Louis: So, in this case it seemed like Jeremy Keith was taking a pretty hard line, he’s saying this is really never going to be appropriate; if you’re designing for the Web you have to be designing for every conceivable device, and that means doing responsive design. What do you think about that, is that an appropriate statement or is it taking things too far?
Myles: I think it’s taking things a little bit too far to be honest. I mean you look at — I can see what his point is, and with being for the last God knows how long harping on about different screen resolutions and different screen sizes, and now we’ve got different devices, but the thing is you take a look at something like a tablet form where you might have a seven or nine or ten inch screen, the resolutions on those things are comparable with smaller desktop screens anyway, and so quite often you don’t need to serve up anything different to those devices; obviously with a phone you’ve got a much smaller screen, your real estate’s much smaller, you need to use it a lot better, so there’s an argument there, but with anything over sort of 1024 x 768 screen it’s a desktop anyway, unless you’ve got some crazy sort of UI interaction stuff going on because obviously with pinch gestures and other gestures that makes other things not work the same way, but that’s a completely different argument, that’s not a CSS media query issue, that’s generally a JavaScript issue which I think is actually a more important sort of thing to be looking at.
Max: Yeah, I half agree with Jeremy, and I think being able to build all your designs using responsive kind of design principles would be great but it isn’t necessarily a reality all the time. I think responsive design can get complex quickly and that’s something you need to consider, and oftentimes you need to, if you’re making a responsive design, I’ve only made sort of three or four, but you need to make accommodations in your — like the structure of your HTML which means that your desktop users might get a slightly worse experience than you would otherwise have because you’re trying to accommodate for everybody, and I think you need to look at; actually take a look at your traffic and see if you’re getting people visiting on mobile, if you’re not then it’s something that you might not want to consider, but if you are then you should definitely think about it.
Louis: Right. I guess one of the other things that plays into that is sort of the — there’s two things, one of them is the context that people are browsing in, so I mean I was having a quick browse this morning before our interview about the Media Queries gallery that I talked about earlier, and it looks like a vast majority of sites on there are either blog sites or sort of agency portfolio sites that are done as a demo of this kind of thing, you know, the content that you want to deliver to the user is exactly the same no matter where they’re coming from.
Myles: Yeah, that’s right.
Louis: But I guess there are a lot of sites, for example, my bank’s website, when I go to it on my mobile it’s not a media query adapted version of their full blown website with all that content just crammed into one column, it’s a completely different experience where I’ve just got three options: log in to online banking, find an outlet, or call us.
Myles: Yeah, they’re not trying to sell you a home loan when you’re on your mobile phone.
Louis: (Laughs) exactly right. I’m just at the bus stop like oh wait, you know, I could really go for a mortgage right now (laughter).
Myles: Yeah, I think that’s at the core of it is media queries essentially reshaping the same content and a separate mobile site is really targeting users in a specific context.
Louis: Right. And I guess the other thing that plays into it is the bandwidth requirement. Sometimes that media query design, depending on how you do it, but it can if you’re doing images that are suited for a 960 pixel resolution but they’re scaled down in CSS then I mean that can be a pretty big image to a server of a mobile broadband.
Max: Yeah, I mean you look at something like a really heavy website like a news website where it’s not uncommon for them to be half a meg worth of assets that you’re downloading every time you get the front page. It makes sense for them to serve up a different version of their website to mobile because you don’t want people having to wait for half a meg of stuff to come down the wire while you’re at the bus stop. And that is a problem, that’s always been, I mean this isn’t a new argument either, we’ve been having this stuff about mobiles for years, it’s just we’ve now got the actual browsers that can support this stuff, and it was even more of a problem before where we had even less bandwidth on mobiles. But, if you’re going to be serving up the same amount of stuff to people on mobiles then, yeah, you’ve kind of done it wrong.
Louis: Right, good. And I suppose to take that next step, so say okay someone might have made the decision where on my website I’ve got a separate mobile version that I’m doing some service side shenanigans to decide when to serve up, that next step going from a website to a native app, what do you think of the deciding factors that might lead, or that make that a good judgment call, that make that a good idea?
Myles: Basically what you’re going to get out of a native, I mean this takes it one step further, when you’re building for a native app you’re building for — you’ve got a whole bunch of other contingencies you need to consider now. The first one being that it needs to work without any network connection at all or at least fail gracefully, which you don’t have to worry about if it’s a regular website because they just won’t be able to get there. But I mean the first thing you’d probably notice is you’re not going to convert your blog site to a native app, that’s probably not quite, so the first thing you’re going to have to look at is whether it’s an app that is going to have interest and is going to make sense being a native app in the first place. But then you’ve got to take into account using local storage wherever possible to cache things if required, doing a bit more handling of network failures, but also the way that the user interacts with the application; when they’re in the Web browser they kind of expect things to have to reload and there being a little bit of a delay when you click on links and that sort of thing. When you’re running natively they want something a little bit snappier, a bit more responsive, so the amount of times you would be able to just take what you’ve done online and drop it into a native app frame it’s probably not going to happen that easily, you do have to do a bit of work to re-factor some of the stuff that you’re working with.
Max: Yeah, I think you need to decide whether you think people will use it is the main thing. Like you say, if it your blog site then people probably are going to download that and install it on there home screen and use it everyday. I mean to jump to a native app is only worth it if you think your users are going to get good use out of it and that it’s going to be worth your time.
Louis: Yeah, right. And I guess in some cases where there’s functionality that you need that’s just not available through the browser. So you were talking earlier about Twitter and I guess the Twitter native app allows you to upload a photo with your Tweet which you couldn’t do on a website, well, not on most mobile browsers anyway. Or just to take one directly from the camera I guess is not possible in mobile.
Max: I was going to say with the discussion about media queries there’s a good resource that I’ve been looking at called Yiibu.com, and they’ve done a bunch of thinking kind of about — they wrote an article called Rethinking the Mobile Web, and I think a lot of the stuff they talk about in that as applies to media queries is really useful to look at, it’s basically the idea of designing for mobile first and then building up a set of — layering on more information and heavier design for your desktop users to somewhat negate what we were talking about earlier which is that problem of network access and extra assets for mobile users by trying to specifically having the default be for mobile users and then targeting desktop users rather than the other way around, which is kind of the initial way that responsive design was thought of, then you don’t force mobile users to download lots of stuff they’re not going to use, but desktop users do and it’s less of a problem for them.
Louis: Right. That does bring up one thing interesting, I don’t remember where I was reading this recently, but I do remember reading that some websites have had reports of users saying you know what, even when I’m at the desktop I still prefer the mobile version of your site just because there’s not all this junk that I need to swim through to find.
Max: Because you’re hiding all the ads (laughter).
Louis: Is it just ads though or do you think there’s something to be said for sort of the simplified user interface?
Max: Yeah, I think there’s definitely something to be said for simplicity.
Myles: But then it works the other way around as well, like I know there’s a number of mobile websites they have done that whole we’re going to do a different site for you, and the stuff that I’m actually looking for isn’t on that and the first thing I do is go to the main site, the full view site because I need some other piece of information. So, it kind of works both ways I reckon.
Max: Yeah, that’s absolutely true.
Louis: That’s an important point is if anyone’s building a separate mobile site it’s important to have a link back to the full site, because if you’re just force redirecting everyone and there’s no way to get to the information you want.
Max: Yeah, I think you want to make sure you’re giving your users the choice rather than kind of enforcing your opinion on them about what they should see.
Louis: Yeah. I just pulled up the Yiibu site that you were talking about, and I had seen this before, they’ve got this sort of flow chart on the front page of I guess it sums up their entire philosophy about designing for mobile in this very fairly sophisticated flow chart. And I seem to remember the flow chart itself also is responsive and they’ve got two versions of it, and one of them loads if you reload the page when you’re in a narrow window. Yeah, it actually does.
Max: It’s quite smart.
Myles: Although it doesn’t look very good when you resize it.
Louis: No, it doesn’t. But I guess that’s the other thing, you consider as a designer the thing that you’re doing is constantly resizing your browser window and you want things to look smooth as they scale, but in reality when you’re doing responsive design it’s not about people resizing their windows, it’s about people loading it on a device that is that narrow I guess.
Max: Yeah, that’s right. And I think there’s a bunch of kind of responsive libraries I guess that have come out, like CSS libraries, one that’s cssgrid.net and there’s one called the Less Framework, and they kind of build upon that idea which is a grid that is responsive and it means that things don’t sort of resize perfectly for every screen when you’re using responsive design, but at any particular resolution then you get like a grid that makes sense and you get a structure that makes sense and that fits, so it still sort of makes this kind of a hybrid between a six width design and kind of completely fluid responsive design.
Louis: Yeah. It definitely looks impressive. I mean as a web geek when you’re sort of resizing your browser window and you see something that seems like the whole way down it looks like it was crafted for exactly that pixel width, it is really impressive.
Myles: It does feel very nice.
Louis: (Laughs) I don’t know how much of the appeal that is, it’s just how cool it feels to web designers to play with it.
Max: (Laughs) yeah, that’s right. I think that’s important, you know, you’ve got to feel good about the things you’re doing, and you want to impress your friends, right?
Louis: (Laughs) yeah. Do you want to maybe have a quick chat about what you were talking about, I know we touched on it briefly at the beginning about what you were talking about in your talk at Web Directions, Max, about geolocation, it’s interesting that this is now pretty much available in every browser, so even for when we’re doing something like a responsive design or a mobile design that’s not necessarily native you still have access to what we think of as device information.
Max: Yeah, that’s right. I mean I think the gap is sort of slowly closing between kind of what’s available in a native application and what’s available in a web browser generally. There’s a lot of work going on in the W3C working on specifications for I think like reading files and getting access to other device APIs like the camera and things, and kind of trying to establish like a standard API for giving access to that functionality like through the Web browser, so it’s kind of an exciting time because you can really build some web applications that do feel like native apps, that have the functionality of native apps.
Louis: Yeah. What do you feel about I guess what do you think is going to be the future of the mobile web; are we moving to a time when everything is going to be via the Web? I know, for example, John Allsop who is also an Australian web designer who runs the Web Directions Conference, he’s pretty vocal about his belief that we should aim for applications mediated via the Web as much as possible. I don’t think he’s a fan of native if I’m reading his Tweets correctly.
Myles: He’s pretty adamant about that.
Max: Yeah, I think it is going that direction, and to me it’s mostly a question of speed for the most part, when you’re building a mobile app it’s interpreted by — it’s interpreted on the fly by browser engine and the JavaScript engine, and native applications don’t have to go through those steps so they’re much faster, but that gap is rapidly closing. The iPhone 4 compared to the original iPhone, the performance of web applications is mind-blowingly faster, and it makes building web applications much more viable I think.
Myles: It’d be even faster if Apple would let us use their new JavaScript engine in native apps.
Max: Yeah, that’s true. That’s pretty mean.
Louis: And, sorry; maybe if people listening aren’t aware of that particular issue do you want to just provide some background on that.
Myles: So, basically the latest iOS upgrade, which is 4.3 or whatever it was, introduced a new JavaScripting engine, I think it’s called Nitro.
Max: Yeah, Nitro.
Myles: Yeah, which is awesome, it means that the mobile Safari on iPhone runs a hell of a lot quicker, but they haven’t actually allowed native PhoneGap type developers to use it, so when we’re trying to fake native apps in a native wrapper we don’t get the speed up that web developers doing stuff in Mobile Safari get which is whether or not it’s a bug or a –
Louis: So they haven’t come out and said we’ve decided for x reason not to allow this, or it hasn’t been commented on at all?
Max: They haven’t commented.
Myles: Yeah, they’ve kind of just left it and gone, eh, whatever.
Max: I think they haven’t gotten to it yet. There’s some discussion about the security implications of the new JavaScript engine and that’s why it hasn’t been included as yet.
Myles: But I mean that does kind of affect — because I’m quite a fan of running native apps, I think there again it’s fitness of purpose, right, so there’s a lot of websites out there that want a native app but for some things I think they make sense, but I don’t want to go learn new languages so something like PhoneGap is very exciting, but when they start pulling that sort of stuff it gets a bit annoying. But on your question about whether that’s the direction we’re going to go, from a tech point of view I think that’s definitely a direction people will want to go because it is a lot easier, you’ve got one platform to work on, you’re building in a web server, you don’t have to worry about packaging up native apps which can be quite painful and all of that sort of stuff. Where I think it might go the other way is from a marketing point of view, I know a lot of guys who aren’t nerds, they’re marketing people, they kind of get a little bit excited about the monetization ability of app stores and native apps, but a lot of them are sort of talking about we did the whole web 2.0, I’m sorry for saying that word (laughter) thing, and it was all awesome but no one — it was really hard to make money on that sort of stuff; with an app you can sell the app and people will pay a couple bucks for it. So I think that’s where kind of the dichotomy is going to occur, and that’s going to be another — a while off until the sort of marketeers get their heads around the whole space, and then by that stage the tech guys will probably be bored with it anyway and will be moving on to the next thing. But I think that there will be a bit of a decoupling between — web delivery will still occur, like you’ll still be pulling information over from websites, but the display mechanism might go more towards native, and that’s purely a marketing thing I reckon.
Max: Yeah, I guess I haven’t played with it much but the Chrome Store is going to be a good example of that, it’s a way of monetizing web technology because all the Chrome extensions are built in HTML and CSS and JavaScript, is that right?
Myles: Yeah.
Max: Yeah, I kind of imagine it ending up in a similar sort of space where the technology for several native applications and web applications end up being pretty close to the same thing, but there are sort of different marketplaces for those apps.
Myles: You’re still kind of talking an app that is downloaded somewhere, but decoupling that from like an actual website that you just type in a URL for, you know, Chrome App Store doesn’t really unless there’s some way of stopping people getting to your website if they didn’t come through a Chrome Store then you’re still kind of — it doesn’t work in that effect, but I mean from an app point of view yeah, and that’s why the sales guys are getting excited about that stuff.
Louis: Yeah, there are a couple of things there, one of the things that’s kind of interesting about the app store mentality from a sales perspective, doesn’t it seem like if my business model is I’ve got this sort of web based service but rather than charging a monthly fee for access to it via the Web I’m going to just sell a downloadable app for people to use it on their devices, right. Does that pose a problem, like once I’ve got my plateau of users that have already paid me I still have to keep serving them with my servers in a way that’s not bringing in any additional revenue?
Max: Yeah, I think that’s something you need to consider.
Myles: Well that’s a big problem, I mean with the new subscription model stuff that Apple’s bringing, I’m sorry to talk about Apple specific stuff here but they’re the best example, with the subscription model that they’re doing we’re seeing a whole bunch of newspapers and magazines and stuff that they do the subscription model for you. So that’s definitely a problem, and we’ve seen that with one of the apps that we’ve built, it’s a one-off fee but there’s this like ongoing server costs and stuff you’ve got to consider, but some money’s better than none, right (laughter).
Max: Well, that’s true. Marco Arment talks about this a little bit on the Build and Analyze podcast with regards to Instapaper because that’s Instapaper’s general model is to give away the service for free and have people pay for a very nice native client for reading, but obviously that means he only gets money from people once most of the time.
Louis: Right. Was there anything else you guys wanted to talk about? Do you have something cool you guys have seen lately that would be worth pointing out to people?
Max: What I would say is that one of the projects that I’m working on at the moment which won’t make it to the Web for a little while but should eventually is like a couple of touch screens for the National Museum of Australia, and so traditionally we would build these in Flash because they need to be sort of fairly animation rich and feel kind of like an application rather than a website.
Louis: So this is like an installed touchscreen that’s just set up.
Max: Yeah, so they have a gallery and there will be a physical touchscreen in the space next to a bunch of objects usually around a particular theme. And so this time we decided to build them in HTML and CSS and JavaScript rather than building them in Flash, and it’s been really successful and they’ll be deploying them in Chrome like running in a full screen kiosk, and the great thing about it is that it out of the box runs on an iPad, so it runs on my iPhone.
Louis: It’s really impressive what you can do with a lot of the new animation stuff in CSS. You guys were both at Web Directions; you saw Cameron Adams’ intro video which was pretty impressive.
Max: Yeah, yeah, absolutely.
Myles: Also there’s rumors that some of the WebGL stuff is going to end up on some of the mobile devices pretty soon as well which means that one of the main reasons you’d want to go native, especially if you’re running a game, which we just didn’t have the speed to throw graphics around too much, there’s a couple of things that were hardware accelerated that not really, and if we can get WebGL sorted out in the mobile space then that means we can do some pretty impressive graphic stuff in JavaScript and HTML as well.
Max: Yeah, it’s definitely an exciting time.
Louis: Absolutely. Well, so thanks both of you for coming on the show this week, it’s great to have a chat outside of our normal work thing. So do you want to just tell the listeners where they can find you online or on Twitter, what’s your main point of contact? Max?
Max: Sure, I’m @makenosound on Twitter and my website is makenosound.com, and you can find most of my work stuff at icelab.com.au.
Myles: My Twitter is @madpilot and you can find me at madpilot.com.au, that’s my work website which has the various links to other bits and pieces that I’ve done as well.
Louis: Alright, well thanks very much guys! It was pleasure.
Myles: Cheers.
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Comments