Tip:
Highlight text to annotate it
X
Jenny Donnelly: Welcome back everyone. Next up we have Bill Walker from Mozilla who's
going to talk through some of the things they're doing to shake things up over there. Thank
you, welcome.
Bill Walker: Thank you.
[applause]
Hi everybody, thanks a lot for being here. My name is Bill Walker, I manage partner engineering
and cross platform groups at Mozilla. Hopefully by the end of the talk you'll know what I
mean by that.
This was the talk title that I submitted before I came to the show, and having been sitting
here for a day and a half I pretty much threw away all my notes and started over again,
because there's a bunch of developer specific things I really want to show you guys, so
rather than play it safe and have a bunch of canned videos I'm going to fly without
a wire and try doing some live demos of things.
Why would Mozilla be here at this show? I think probably you know about our desktop
browser. Firefox users in the house give it up. All right, cool. Lightbeam, by the way,
if you want to make it hard to go to bed at night you should download this Lightbeam thing
and try it out. It shows you who's tracking cookies and who they're sharing them with.
Very revealing, very interesting.
That's the thing that started the ball rolling for Mozilla, but we're also doing this cell
phone project. We are really, over the past two or three years, focusing everything we
do on mobile first. Recently we had our biggest launch so far this year of Firefox OS, which
is a cell phone operating system that is built entirely in HTML. There's your homepage over
there in the slide. The app dials the phone, sends text messages, email, all of that stuff
is built entirely in HTML, there's nothing else. I used to tell people HTML apps are
the native apps on this phone. There's none of this is it just like a regular app on this
phone, that's the only kind of apps there are.
So that is a really exciting technology stance as a bunch of HTML, JavaScript nerds. But
it's also totally open source, and we think it's really a game changer in a lot of ways.
Telefonica think so too, and that's why they're willing to pony up a lot of money and a lot
of marketing to make this phone successful.
You can't just have a phone with software on it, right? A smart phone has to have apps,
it has to have services attached to it, and that means having cloud services available,
having data centers, and it means having an ecosystem of developers like you guys. That's
the unfair advantage we have that's going to make this different from other cell phone
ecosystems I could mention. We have millions of developers making stuff for the web and
we can harness all of them and bring those experiences to a smart phone that is priced
like a feature phone. That's why we talk about bringing the next billion people on to the
internet, it's going to be on inexpensive smart phones. That's the big exciting project
that we've been spending our time on this year, and my friend Harvey back there has
been traveling all over the world helping developers in different countries, especially
in Spanish, learn how to build apps.
Okay, so I want to show you what that might be like. I thought well if I'm going to do
this here I have to do it with some YUI code, so this is the first YUI app that I built
or stole. I don't know, I haven't had a chance to meet everyone. Allen Rabinovich, is he
here today? Okay. The guy has an awesome site, it's very helpful.
So this is a very simple thing that gives you groups of items and has a click handler
to move them back and forth between groups. Shows nicely how you can add behavior to the
DOM. What would happen if we took this and turned it into an app? What do I mean by that?
We're going to explore both those questions as we go along.
First of all, what I think you're probably already doing is developing stuff in the browser.
What that probably looks like is you've got your code running here and maybe you've got
some developer tools that are running alongside it. Apologies for the small font, but you'll
get the gist of what's going on. This is the code that we just looked at and as you click
on these things they migrate back and forth between columns. I know you all have your
favorite browsers and your favorite tools. I know that Chrome was probably winning that
race for much of the last 18 months β I'm not sure that's true anymore. If you haven't
looked at Firefox developer tools lately I'd encourage you to take another look.
One of the things I really like here in the tools menu is this thing called Responsive
Design View. This is a way to cope with multiple screen sizes and try them out in a nice easy
way. You shrink the rendering area down to a certain number of pixels, you have a menu
here where you can add and remove preset sizes, and you have a rotate button so you can simulate
rotating the phone, the device, in portrait or landscape mode. This is a really easy way
to test out whether your CSS is responsive. Hint: in this case it's not. We're just going
to go in landscape mode here.
Two other things I'll note. One is there's a screenshot button so you can grab a screenshot
of what's going on there, and this button here which simulates touch events. If you
want to make sure that you're not just handling click but also touch correctly you can do
that.
So that's pretty cool. What else is there? I also want to mention the style editor, which
is a pretty cool way to get a handle on all the styles that you've got currently active
and to edit them on the fly. If this border around these two groups, if I wish this was
a thicker line, I can just edit that and see it change live in the running code. I can
maybe set a background color to pink, because everybody loves pink, and get that. This is
a really great way to edit CSS live and see its effects immediately without even having
to hit refresh. That's kind of a cool thing to do.
Other new stuff that we have β or new to me anyway βin here include network tab,
so that when you refresh pages you can see how long it takes to load at different parts
of your payload, how big they are. There's also profiling tools in here for the first
time I think, this year maybe. Now you can watch what your CPU is doing while the page
is rendering, you can load those up and compare them across different versions of your page,
that kind of stuff.
So there's a lot of cool stuff in there that's worth checking out. But this general workflow,
this you already know.
So what comes next? Next we want to make this into an app. What do I mean by that? What
it really means is adding a little bit of metadata. That's the required thing, is to
add some metadata so that an app store and the user can know a little bit more about
what they're going to get. Chrome apps have this kind of thing in XML. Ours is a JSON
file. All I've done is added this JSON file, served it up with the right MIME type from
my server, and I've given my name, the name of the app, a version, a description, and
there's some localization stuff you can do here.
There's also a set of permissions I can ask for, and this is where we start to more and
more differentiate from just an ordinary website. As you can imagine, the HTML, if I tell you
that the thing that dials the phone on this cell phone here is made in HTML, it's got
to have access to some special APIs in order to do that. So there's the Telephony API that
that app has to list in its permissions field here.
Okay, so you publish this and that means you're basically ready to go as an app. But the other
thing I can't resist mentioning here, the other thing that's really important about
phones is that people use them in the subway or in a tunnel or in an airplane, and they
expect that something is going to happen when they launch your app. Maybe you guys are already
all over this, but this a mental shift I think for a lot of web developers, is what's my
offline story? What am I going to do when I don't have a net connection?
There are two basic answers. One of them is a legacy standard called AppCache which lets
you list the resources you're going to want to cache on the device no matter what. AppCache
is prickly and hard to use. But the thing you can do to make AppCache work the best
is by going to a single page app model. I think everyone here is probably already thinking
that way, or else they wouldn't be using... You know, it comes with the territory. Single
page apps, it's pretty clear what your resources are that you want to cache. Life is good.
Traditional server side apps where each click is a new page load, AppCache is not going
to help you.
Then the other technique is to package up the resources. Chrome apps and our apps here
offer the ability to take all your assets, put them in a zip archive, and upload them
to an app store and just move them around as a zip archive, which is one simple way
to get your offline problem addressed, but it means you need to really, really know upfront
where all your assets are, and you don't get to sort of change your mind later. So there
are tradeoffs there.
Okay, so suppose you've done all those things and now you want to find out what it's going
to feel like on various devices. Up until recently it was pretty difficult, I have to
admit, to get ahold of one of these phones. For a variety of reasons we felt it was going
to be a good idea to... Sorry, let me hide this. We felt it was going to be a good idea
to provide a simulator. This little window here is a copy of the whole cell phone operating
system running in its own process. You've got your home screen, it's got your app for
dialing the phone, all that good stuff.
And this little tab here, which is called Firefox OS Simulator, is running the same
developer tools we looked at before. As I'm clicking on things I'm seeing the console,
and if I come in here to the style editor I can do some of the same tricks that I did
before. But these tools are now remotely targeting the other process that's the simulator, which
may be just an inside baseball kind of thing, but the tools in this browser are talking
to the simulator over there, which technologically is a pretty impressive thing to pull off.
Now you can really see what your app is going to feel like on the phone and still get all
the debugging tools you want without leaving your laptop, so that's pretty nice.
Okay, any questions so far? I'm kind of rocketing along.
This simulator is at the addons.mozilla.org site along with all the other Firefox addons,
and I encourage you to go check that out. Okay.
Now, what about actually testing on the device? This is both really important and can be a
real productivity hit, because it's HTML so it ought to run the same everywhere, but as
we all know if you haven't really tested it on that device it doesn't work and there's
always going to be some little paper cut that's going to hurt you.
Now that it is possible to, as one gentleman did here in the audience, go to eBay and purchase
a phone from Geeksphone or from ZTE, you can actually get your hands on one of these. This
is made by a Spanish company called Geeksphone, and I've got it connected over USB here.
This is probably the big aha moment that might be new to some of you, which is something
called the App Manager. This is part of our developer tool suite that just showed up in
the past few weeks in the Firefox Nightly, and maybe in Firefox Aurora. What I find super
exciting is that this notion of apps that I've been talking about is now baked into
the heart of our developer tool suite. All of our tools are now getting focused around
this notion of apps. And of course philosophically what I love is that we ship these tools with
every single copy of the browser, so we're sending the message anybody out there can
get this browser and become a developer, which just lines up with our mission really well.
Okay, so what are we looking at here? This window shows some information about this device
β gives which build it is, tells it which apps are installed on it. It also gives a
list of all the permissions. I was talking about that earlier. These are various APIs
available to HTML code and which kinds of apps are allowed to access them, so that's
a handy quick reference card. Here in this tab I can see information on all the apps
that I'm working with. I can refresh them if I've made edits, and if there's something
wrong about their manifest I'll get some error messages in here. Okay.
So I am connected to this device, and I'm going to... I wanted to show both the laptop
screen and the phone at the same time, so I rigged up this cardboard contraption this
morning which I'm extremely smug about, and pointed it at the camera in the lid. Okay,
tangent. I'm showing you the content of the webcam in this little window, which appears
to be a browser window. What is that?
This is another cool thing I'm excited about. See here where it says navigator.getUserMedia?
This is a new API which is part of WebRTC. Using these 20 lines, you can do the hello
world for WebRTC which is make a window that shows the current video. You can use JavaScript
to get access to those images, get access to that stream, do whatever you want. So WebRTC,
I expect a lot of cool crazy things to happen this year with that.
Okay, back to the main topic. Here is the app running on the phone. It's as easy as
coming to this tab, telling app manager where your app is and then pressing update, and
boom, it gets side loaded onto the phone using USB. No hands, it's completely easy, it's
up and running. Now I press the debug button over here and I get this set of... Whoops,
excuse me, that's the wrong window. There it is. So here is now my set of developer
tools again, but this time they're connected over USB to the gecko running on the phone.
Now comes my exciting left right excitement. But if I click on these links here on the
phone, I'm seeing the console running on my laptop, showing me the console logs from the
phone. This is a huge... Trust me, debugging apps on the phone before this was really no
fun. So this is a great step forward. But wait, there's more. I can come here to the
style editor and I can once again do those tricks I was doing before. I can make that
border get really big and it's doing live edits to the CSS on the phone. If you need
to tweak the CSS because of some idiosyncrasy of the particular device you're messing with,
you can do it for real and see how it works. The debugger also works.
Let's see, what else should I show you? In the console I can come in here and type alert
hello world and make that alert box appear on the phone. So they're really, really connected.
Also the profiler works, so you can profile your code running on the device and find out
where it's slow. Maybe it's going to be slow for different reasons compared to what was
happening on the desktop browser.
What I'm trying to get across is all of this stuff makes it easier for you to take the
skills you already have building cool stuff with YUI and bring it on to these kinds of
devices in a perfectly natural way.
Oh shoot, sorry. There's one more thing you've got to see. Rats, okay, hold on. I closed
my mirror.
Okay. The other thing that I think is really cool is... So here's the inspector that lets
me inspect the different parts of the DOM. I can click this button which says select
something by pressing on it and then I can come in here and actually select items in
the DOM to inspect by pressing them on the device screen. If you're looking at your app
running on the phone and you can't figure out which part of my DOM is that, you can
just press an item on the screen and the inspector on the laptop will switch to it.
Okay, so now let's say we've got all that figured out, we've got the code running the
way we want it to on all the devices and screen sizes we care about, written our little manifest.
What's the payoff? What do we get for this? The idea is, of course, that we get more discovery.
We bring the web content that you guys are already making to more audiences in more places.
One publishing channel is something that we're doing called Firefox Marketplace, which is
pre-installed on all of the phones that we're selling. It is Mozilla's notion of an app
store, and it's totally free to purchase, you can go to sign up right now. It has a
really simple submission flow where you take that manifest file I told you about, you upload
it, we make sure it's valid JSON and we do a couple of other checks. You tell us some
stuff about your app and then it gets reviewed and gets published. That is super, super easy.
In that case it feels like an app and it feels like it has a developer community behind it.
It's also a set of web services, so you can make a query to our marketplace and find out
the entire catalog. You can get access to all the reviews, all the information about
all of the apps. If you want to mash that up somehow, make your own app store that uses
that same database, you can do that.
It's also a community. The developers, but also users and app reviewers, are not just
people paid by some corporation who are not accountable to anyone, off in a secret place
somewhere like some companies I could think of. These people are volunteers in many cases.
Our review criteria are completely public, and if we reject your app we're going to tell
you exactly why and we're going to give you a chance to fix it.
So this is a piece of technology and it's also a community, and it's also a set of web
services. That is a much more open notion, I think, than a lot of other app stores. Again,
it's why we have an unfair advantage.
Okay, so two more things. First of all, we don't insist that there be only one app store
in this universe. In fact, I like to tell people the only criteria you really have to
meet in order to be considered an app store is that you let people install apps, and that
is one function call. Here we have... it's probably hard to read, but navigator.mozzApps.install.
You call that function and the device will go through its app installation flow. You
pass it the manifest that we just talked about and the device will install the app and make
it feel like a real app. This is all you need to do to make an app store.
So in fact, if we go back to here... Close the developer tools, right, okay. Get rid
of this. Here's the app. I kind of glossed over this button down here, but this is an
install button that invokes that code that we just looked at. If I press install here
I get this little door hanger here which is our app installation flow for the desktop
browser. I hit install. Now I go to my applications folder. There it is. Now it's running like
a native app on Mac OS X. You can switch between it using the tab switcher. It has a real menu
with a real quit option. You didn't do anything and you get that. By the way, we can make
that work for you on Android, we can make it work on Windows, and we can make it work
on Linux.
I would love to talk all day about that but I won't. I have recently done a blog post
about this cross platform story, there's a video I put together that shows these apps
installing and launching on all those platforms. I hope you will come and check this out. I
think all of this stuff will feel both familiar and also kind of new and exciting. Would really
love to see a bunch of YUI content show up all over the place in Firefox OS in the next
12 months.
If there's anything I can do to help, let me know. Thanks a lot.
[applause]
Jenny: Thanks Bill. We have time for a couple of questions. All right, let's get them going.
Audience member: If you use third party libraries like YUI to do your development will you be
able to load those libraries the usual way with the desktop, or will we have to bundle
them with our application?
Bill: Right, so the question is yeah, what do you do with third party libraries? There
are kind of two choices. You can load them each time you launch, in which case your app
is small but you need network connectivity. I think it's advisable to at least list them
in your app cache manifest so they get cached the first time. But if your app is going to
seek to use certain privileges then you'll probably want to package them up in the package.
It's always a tradeoff between how many privileged APIs do you want access to and how webby to
your want your development process to feel like. But we can accommodate both.
Audience member: I know that Firefox OS provides APIs to the system. I'm curious if there's
anything special being done with SMS, like location bundling with SMS or is there anything...
since SMS is so critical for third world countries if you're doing anything on that.
Bill: Yeah, we think about SMS a lot. Right now, the API we have internally for our SMS
app is very early. Especially since SMSes can cost people money, we're erring on the
side of being conservative about who gets access to directly manipulate that API.
What we are telling though is we have a system like Android intents. We call them activities,
web activities. Any app running on the phone can say hey I want someone to fulfill an activity
to send a message, and then at that point you switch over to the SMS app and you can
pre-populate everything and send the text that way. We definitely want to come up with
creative ways to let app developers get access to sending and receiving SMS without putting
users at risk. That's the balance we're tackling
Audience member: Looking at the web apps, have you guys looked at anything that Samsung
is doing that Tizen? Are you thinking at all how easy it would be to port one app from
the other over and stuff like that?
Bill: Yeah, there's a bunch of things going on, everything from WebOS to Tizen to what
Windows is doing, to Chrome apps, and maybe the prospect of Chrome apps on Android. We
are talking to all those guys as much as we can, and we really are trying to herd everyone
in to W3C, because a lot of the differences are pretty small. Especially you look at what
Chrome does with app manifests and what we do, it's very similar. I think some of those
simple things we can bridge. We want to converge on certain standards. If Tizen apps are based
on HTML5 and CSS and JS then I think we can easily converge on that.
Audience member: So maybe I'm not understanding something but if you're using something like
PHP with your HTML, what would happen? Instead of PHP do you use something else?
Bill: Well, I think what we're talking about here is... Let's see. Apps come in different
flavors. We recently announced Cut the Rope. It took a lot of work, that's in our app store.
That's entirely in JavaScript and entirely on the client. It's just running locally on
the device and there's no backend at all. Whereas let's talk about New York Times. Obviously
their frontend is all written in HTML and JavaScript. Their backend could be anything,
right? It could be PHP, it could be servlets, whatever. We don't have to care because just
like any other browsing device, the backend stuff happens and it's their responsibility.
We just talk HTML to the device. Does that answer your question? I'm not sure I understood.
Okay, let's talk afterward.
Jenny: Thanks Bill, that was really great. Thank you.
Bill: Thank you.
[applause]