Note: I know it’s not Wednesday, but I was sick for a couple of days, so this is the soonest I was up to handling this. Sorry!
Here are today’s Wiki Wednesday articles! If you know about these topics, please try to find a few minutes to look over these articles that are marked as needing technical intervention and see if you can fix them up. You can do so either by logging into the wiki and editing the articles directly, or by emailing your notes, sample code, or feedback to mdnwiki@mozilla.org.
Contributors to Wiki Wednesday will get recognition in the next Wiki Wednesday announcement. Thanks in advance for your help!
This is the third installment of Mission:Mozilla, a series of interviews that link Mozillians, the technology they produce and the Mozilla mission. This time, We’re interviewing Atul Varma and Jessica Klein about their project, Hackasaurus.
Tristan- Jess, Atul, could you introduce yourself in a few words?
Jess - I am Jessica Klein, the Design and Learning Lead of Hackasaurus. I design the various curricular aspects of Hackasaurus, and help learners of all ages delve into the building blocks of HTML and CSS with our tools.
Atul – I am Atul Varma, the technical lead for Hackasaurus and implement the tools such as the web X-Ray Goggles and the website. Jess and I iterate on the design of the tools based on user observation and feedback from the hack jams that we hold.
Tristan- What is Hackasaurus?
Jess – Hackasaurus is a suite of tools and curriculum that make it easy for anyone to learn webmaking through HTML and CSS. Our primary tool is the X-Ray Goggles, which makes it easy to see through Web pages and tinker with their individual parts. Our primary learning resource is the Hacktivity Kit – — which tells you everything you need to know to host your own “hack jam”, where participants can remix the web together and learn basic HTML and CSS.
Tristan – What issue are you trying to solve with Hackasaurus?
Atul – Hackasaurus is really about bringing HTML back to the non-technical audience. When I first learned HTML in high school in the mid-1990s, lots of other folks knew it, because it was what people those days did — they made web pages on Geocities. As the masses of the day turned to making blogs and then simply having Facebook pages, we’ve lost a lot of that knowledge, culturally — which is particularly unfortunate since HTML has gotten so much more amazing over the past decade.
Hackasaurus’ aim is to give everyone what film critic Roger Ebert calls “restaurant HTML” — enough knowledge to know how the bones of the Web work, and how to use it to empower themselves in their online lives. In doing so, they will also understand, at a very visceral level, what makes the Web such an amazing public resource.
Tristan – How did you end up working on Hackasaurus?
Atul – For me personally, it was something I was excited about and blogged about in 2009. Mark Surman (Mozilla Foundation Executive Director) really liked the post and later invited me to a brainstorming session with the MacArthur Foundation in Chicago — they were working on turning libraries into maker spaces for kids, but weren’t yet doing anything with the Web other than using it as a passive medium to e.g. upload videos to YouTube. So Mark thought there might be some way to connect the idea of teaching kids about the Web with MacArthur’s efforts.
That ultimately led to the Drumbeat Festival in Barcelona at the end of 2010, where I met Jess and led a design session with a cross-disciplinary team of hackers, librarians, and educators to come up with a curriculum and motivate the use cases for a tool that eventually became the X-Ray Goggles.
Jess – I came to the project through my work with the Hive Learning Network, an initiative started by the MacArthur Foundation as part of their Digital Media and Learning portfolio. They connect museums, libraries and community based youth organizations who are really trying to take risks with technology in their programming. At the time, the Hive and Mozilla were “dating” so to speak and this project was the first time we really started to work together. I came to the Learning, Freedom and the Web festival and met Atul and we really just started to tinker and figure out what kinds of curriculum would complement the technology. We did a lot of user testing and iterating incorporating the lessons learned by directly working with the end user (teenagers!) to create the software and eventually that defined a really nice and organic community-driven design process.
Tristan – How do you plan to evolve Hackasaurus?
Jess – Right now, Hackasaurus just released its beta — so we are really at the phase of exploring how our tools and curriculum hold up on a global level to the design question of — how do you teach code to users in an accessible, fun and interest driven manner? We are constantly experimenting and iterating our tools, but our next steps are really to expand the learning tools so that our users transition from simply hacking websites to really becoming full on webmakers.
Tristan – Can other people reuse this material? Under which license?
Jess – yes, everything is available currently under a creative commons license. We actually really want to encourage users to essentially fork our content- which makes our project both an open source project and an open educational resource (OER).
Tristan – Do you need help with Hackasaurus?
Atul – Yes! Currently localizers can use Mozilla Verbatim to help translate, and they can easily see the results of their translating on our staging server. Testers are all welcome too — for more information, check out http://hackasaurus.org/contribute/.
Also, a good way to stay connected to our community of webmakers is to participate in the webmaker community calls on Tuesdays.
Tristan – How do you plan to reach to a broader audience? Or is it too early to discuss this?
Atul – Not at all! We’re currently working with the MacArthur Foundation, and the Hive Learning Networks to bring Hackasaurus’ curriculum and tools to libraries, museums and community based organizations across the US, and we’re recruiting “Mozilla Youth Ambassadors” to hold their own hack jams and spread the word. The Hacktivity Kit, which we just released last month, is another way we’re trying to scale participation, as it gives anyone all the tools they need to hold their own event.
At a technical level, another thing we’re trying to do to reach a broad audience is to make our tools available on as many platforms as possible. The goggles, for instance, currently work on Firefox, Opera, Chrome, Safari, and IE9–we’re working on IE8, because many libraries and schools don’t have the ability to run a newer browser. Initial work has been done to have the goggles work on tablets, too, as a number of places only have access to those.
Jess – We are also working with community members to run local hack jams. Currently, people have run jams in locations including: Nairobi, Barcelona, and Brussels. Some of these members have come to us through the Mozilla Reps program , while others have come to us through like minded organizations like the National Writing Project. But this kind of community involvement is really integral for the success of the project, because as we know, creating meaningful learning experiences isn’t going to just be about translating our open source offerings, but truly localizing.
Tristan – Who, other than Mozilla, could have done something like this?
Atul – Probably the MacArthur Foundation and its network of informal learning organizations — the Hive — which is why it’s so great that we’re working together with them on the project. I don’t think Hackasaurus would exist today if it weren’t for Mozilla’s technical know-how and non-profit mission of turning web users into Web makers working in conjunction with the MacArthur Foundation’s plethora of research on informal learning and their network’s practical knowledge on holding events for youth. It’s been really inspiring to see the two organizations work in concert to do something that neither one could have accomplished on their own!
Jess – Mozilla is truly committed to empowering a generation of web-makers — people who want to make things on the web — and I think that really requires us to design our tools and learning resources with different communities of makers, including filmmakers, journalists and young people. So, in a sense, this project is enhanced by Mozilla but designed by the community.
Tristan – Anything else you’d like to tell our readers?
Jess – I guess I would just say, that when people learn the basic building blocks of the web as they are learning through Mozilla projects like Hackasaurus, they are not only empowered to make things they are passionate about, but they also come to expect the web to work in a certain way — to be open, editable, remixable and accessible. The most skilled among them will make things that are useful to others that embody those values of the open web- and thus, help to build the web for everyone. With our tools, and programs we are helping to educate the next generation of webmakers — what is possible and hopefully empower them to design the rest.
Tristan – Amen to that, Jess! I see that you have a partly localized version in French. I’ll walk through it with my son, I’m sure he’ll fall in love with it… Thank you Jess and Atul, and long live Hackasaurus and the Open Web!
In a dramatic turn at the end of that blog post, I foreshadowed that we had “more to come”. And, indeed here I am to tell you about the new developer tools features now in Firefox Aurora. What you see here is slated for final release in March, 2012.
Free-form Style Sheet Editing
In the last Firefox release, we introduced the Style Inspector. You can use the Style Inspector’s rules view to make changes to the CSS properties for an element. With this release, we’re adding a free-form Style Editor to the mix.
Select the Style Editor from the Web Developer menu, and you’re presented with a view that lists the style sheets for the page in one pane, and gives you an editor to make changes in another:
The Style Editor provides a friendly environment for working on your style sheets. Any changes you make are reflected instantly on the page. Once you’ve made your changes, you can save the file on your computer.
There are also a number of handy additional features. Click on the “eye” icon next to the style sheet and you can toggle the entire sheet on and off. If you’re working on a new page, you can create new style sheets on the fly or load a style sheet from disk.
If you want to take a look at how other sites on the web are styled, you can use the Style Editor to view the style sheets on any site. On public sites, the style sheets are often minified to reduce download time. The Style Editor will automatically prettify style sheets that it detects have been minified, but it will leave your source style sheets alone.
“Tilt” 3D View of Web Page Structure
Open up the Page Inspector (Web Developer->Inspect from the menu, or Inspect Element in the context menu on the page), and you’ll see a new 3D button on the toolbar if your computer is compatible with WebGL. Click that, and you’re presented with a whole new perspective on web page structure.
This 3D view (which was previously available in an add-on called Tilt), stacks elements as they are nested in the DOM and lets you see elements that are hidden or off the page. You can zoom in and out, rotate and pan the view to see the page from any angle that is helpful to you.
The 3D view is fully integrated with the rest of the Page Inspector functionality. You can open the HTML view or the Style Inspector for more information about the element you’ve clicked on in the 3D view. You can also change selected elements using the breadcrumbs on the toolbar.
The controls for the 3D view are easy:
Function
Mouse
Keyboard
Zoom
Scroll up/down
+ and -
Rotate
Click and drag
a/d and w/s
Pan
right-click and drag
Arrow keys
Dozens of Other Improvements
Since the last release, we’ve landed dozens of refinements to our other developer features. A growing number of contributors are making the tools they use better by getting involved.
The Web Console, Scratchpad and Style Inspector have all had improvements since the last Firefox. Take a look, and let us know what you think!
Get it Now!
You don’t need to wait until March to get these great new features. Download Firefox Aurora today and see these and other improvements that are coming to final release soon.
Updates+Screencast
Since I wrote this article, we’ve landed some fixes and improvements to these tools. I added the way to pan the Page Inspector 3D view (right-click and drag). Also, there is now a screencast for these features. Be sure to opt-in to YouTube’s HTML5 video option.
Kevin Lim led a local doc sprint that focused on games, mobile, offline, and other stuff. Eric Bidelman, Ernest Delgado, Kathy Walrath, Andy Watson, Paul Irish, Jan Kleinert, Lilli Thompson, Ido Green, and Jed Hartman worked on:
Jeremie Patonnier is organizing a weekly meetup to improve the French and English areas of MDN. It is held 7 to 9 pm, Paris time, on Wednesdays. You can join in face-to-face at the Mozilla Paris office, or participate remotely, in the #mozfr IRC channel. The meetings are conducted in French. The goals are:
Increase the volume and quality of the documentation on MDN.
Encourage newcomers to get involved by showing how easy it is to contribute to MDN.
Have fun with other Mozillians
Be sure to contact Jeremie (@JeremiePat on twitter) if you plan to show up in person, as space in the Mozilla office is limited. The next meeting will be January 4th.
Last Mozilla Hacks Weekly for this year and then we take a break for the holidays. We’ll be back in January again! If you have any feedback on our weekly link posts, format etc, please let us know!
As web developers we want to ensure what we build is accessible by as many people as possible, with as many web browsers, operating systems and devices as we can support. It is also hard to know what the future holds, and for that we have put together Writing forward-compatible websites
As explained in this blog post by Jared Wein of the Firefox team there are quite a few new features in Firefox when it comes to playing HTML5 video. As an Aurora user, I am most excited about the option to go full-screen, the ability to overlay video statistics and to save a snapshot of the current frame as a JPG. You can see me talking about and showing them in this short video:
Firefox has a few features up its sleeve when it comes to HTML5 video playback you might not be aware of:
Firefox‘s seeking is now accurate to millisecondsmicroseconds, there is visual feedback when the video has stalled and clicking the whole video pauses and plays it
Firefox Beta has specialised controls when you watch video on small devices and watching HTML5 video shows a pleasing background rather than a brutal grey
Firefox Aurora has fullscreen, statistics overlay, saving of snapshots and controls appearing when the video ended
Firefox Nightly has a full-screen button, fading video controls after 2 seconds of non-interaction, no loading throbber on audio, error reporting when a video could not be loaded on the video, loop attribute support, and resizing of videos larger than the browser window when you watch them directly
Planned features for Firefox are an overlay play button like YouTube when the video is not set to autoplay and turning off screensavers during fullscreen playback.
In this post I give a quick overview of the Mozilla Labs Apps project and how it and the other technologies at Mozilla relate to gaming. We really are at a point where amazing games can be created on the Web with nothing but open technologies.
A few days ago we launched the developer preview of the Mozilla Labs Apps project, our vision of a distributed Web application platform. This apps project is directly related to our overall mission to better the Web, as recently described by Ragavan Srinivasan:
As part of Mozilla’s mission to make the Web better we believe that apps should be available on any modern Web-connected device, operating system or browser, allowing billions of people worldwide to use and interact with apps.
Today, apps are tied to closed ecosystems. Apps also can’t be used across all devices; data within apps is silo-ed and inaccessible to other apps or Web services; and user choice is limited and undervalued.
In an open ecosystem, developers should have the ability to build apps using open Web technologies and resources. They should then be able to distribute and sell those apps with the reach, flexibility and choice that the Web provides.
It’s important to remember that although we often talk about apps as pieces of software that each serve a particular task, they can also be games. After all, if you pull away the story and graphics, a game is really no different to what you would normally consider as an application — it uses the same platform and programming languages, HTML and JavaScript in this case.
So how does the Mozilla Labs Apps project and the other technologies that we’re working on relate to open Web games? I hope to shed some light on this question in the brief overviews that follow.
Rest assured, Mozilla is very much focused on making the Web a better platform for open Web gaming.
Identifying players with BrowserID
Just like how iOS has services like OpenFeint and the Apple Game Center, games on the Web need open and reliable methods of identifying players. BrowserID is one of our solutions to this problem. It allows players to log into your game using their existing email address, providing a password only once per browser session.
Implementing BrowserID within your game is a simple 3-step process. I advise you to check out the documentation about installation, where you’ll also find some fancy BrowserID buttons to show your players that you support distributed authentication. Right now BrowserID is provided via a JavaScript library. However in the near-future it will be built into Firefox for a seamless experience.
Identifying players in this way is just the first step in providing all sorts of functionality with your game, like friends lists, leader boards, chat, and multiplayer.
Creating immersive gameplay with the Full Screen API
Something that prevents current games on the Web from feeling immersive is that they look like they’re just tiny boxes embedded into another website. Why do they feel like that? Well, because they are just tiny boxes embedded into other websites. The odd 5-minute puzzle game during your lunch hour might feel OK in a tiny box surrounded by browser UI and other distractions, but a first-person shooter or driving game certainly wouldn’t.
Fortunately, the Full Screen API has arrived to solve this problem. It allows you to make any DOM element fill the player’s entire screen, something normally only considered for videos. Using this in a game can make the difference between 5 minutes of relative fun and hours of immersive delight.
Like most of the JavaScript APIs, it’s pretty easy to implement full-screen functionality in your game. All you need to do is call the requestFullScreen method on the desired DOM element:
var elem = document.getElementById("myGame");
if (elem.requestFullScreen) {
elem.requestFullScreen();
} else if (elem.mozRequestFullScreen) {
elem.mozRequestFullScreen();
} else if (elem.webkitRequestFullScreen) {
elem.webkitRequestFullScreen();
}
Taming mouse input with the Mouse Lock API
An issue related to input in games is that of misbehaving cursors, where the mouse is used to rotate a player around a fixed point, like moving the viewpoint in a 3D first-person shooter, or rotating the player in a top-down 2D game.
In both of these situations, the mouse cursor is visible at all times, which is generally annoying and ruins the experience. However, the most debilitating problem is that when the mouse cursor leaves the browser window all movement stops. This same behaviour occurs in full-screen mode when the mouse cursor hits the edge of the screen. It’s a horribly simple problem for players that completely ruins the experience.
The good news is that the Mouse Lock API has been created to solve this problem, and it just landed in experimental builds of Firefox Nightly. Its sole purpose is to tame the mouse by hiding the cursor and locking it in place so it doesn’t hit the edges of the screen. This means that instead of relying on x and y coordinate values for mouse position in related to the top-left corner of the browser, you instead rely on x and y distance values from the position that the mouse was locked to.
Using the Mouse Lock API is really just a case of calling the navigator.pointer.lock method. However this must be done in full screen mode to work properly (and remember to use the experimental build of Firefox linked previously).
The following example expands a <div> element to full screen and locks the mouse in place at the same time:
<script>
function fullAndLock() {
var div = document.getElementById("div");
document.addEventListener("mozfullscreenchange", function() {
var pointer = navigator.pointer;
if (document.mozFullScreen &&
document.mozFullScreenElement === div &&
!pointer.islocked()) {
function onMouseLockSuccess() {
console.log("Mouse successfully locked");
}
function onMouseLockError() {
console.log("Error locking mouse");
}
pointer.lock(div, onMouseLockSuccess, onMouseLockError);
}
}, false);
div.mozRequestFullScreen();
}
</script>
<button onclick="fullAndLock();">Mouse Lock</button>
<div id="div">Element to receive mouse lock</div>
Here is a quick video of the Mouse Lock API in action, with comparison to non-mouse lock game-play to see the improvement:
Providing a console-like experience with the Gamepad API
Another input-related improvement that is coming to the Web is that of the Gamepad API. No longer are the keyboard and mouse the only options available for your players to engage with your game. The Gamepad API now allows for all sorts of gamepads to be accessed via JavaScript. This even includes some of the console controllers like those on the xBox 360 and Playstation 3 (with third-party drivers)!
Like the Mouse Lock API, the Gamepad API has just landed in experimental builds of Firefox Nightly and it’s nice and simple to use. Coupled with the Full Screen API, gamepad support can really change the experience of your game from that of a game within a website to that of a desktop game or console.
To find out when a gamepad has been connected, you need only listen to the MozGamepadConnected event on the window object (remember to use the experimental build linked previously):
Receiving updates about all the buttons and joysticks on a gamepad is also a case of listening for events, or you can manually poll the status of buttons and joysticks whenever you want. Check out the Gamepad API documentation and the input.js library for more information.
The video below shows the Gamepad API in action, controlling a player in the game Rawkets:
Adding real-time multiplayer game-play with WebSockets
If you’re thinking of creating a multiplayer game then before now you would either have put up with the latency involved in constant AJAX requests, or you would have moved to Flash. Neither option is ideal. What’s cool is that since last year this is no longer the case, WebSockets have now arrived to allow for real-time bi-directional communication between the browser and a server.
But why is bi-directional real-time communication important for games? Well, this means that you can now literally stream data to and from a player’s browser in real time. One obvious benefit to this is that it saves bandwidth by no longer requiring constant AJAX requests to check for new data. Instead the WebSocket connection is left open and data is instantly pushed to the player or server as soon as it is needed. This is perfect for fast-paced games that require updates every few milliseconds. On top of this, the bi-directional nature of WebSockets means that data can be instantly sent both from the server to the player and from the player to the server at the same time.
Using WebSockets is a case of connecting to the socket server by initialising the WebSocket object:
var mySocket = new WebSocket("http://www.example.com/socketserver",);
From there you can send data using the send method of the WebSocket object:
mySocket.send("Here's some text that the server is urgently awaiting!");
And you can receive data by listening for the onmessage event on the WebSocket object:
A full code example for game communication would be too much for this post but you should definitely check out the tutorial that that I made a couple months ago. In it I detail exactly how to create a real-time multiplayer game using Node.js and WebSockets.
Using games offline with local storage and the application cache
Creating games on the Web is all well and good, but what about if you want to play that game offline? Or, what if the player’s Internet connection drops out half way through an epic gaming session? Most open Web games today would at worst simply stop working as soon as an Internet connection fails, and at best they would stop sending data to your server and saving player data. When your player refreshes the page that the game is on, they’ll just see a blank page and all their hard work achieved while offline will have been lost. That probably won’t make your players very happy, and unhappy players are not ideal.
There are a few solutions available today that can help solve these issues. The first is the application cache, which allows you to use a cache manifest to declare particular assets (like HTML, CSS, images, and JavaScript) that you would like the browser to cache for offline use. Not only that, the browser uses the cached versions of the files when when online to speed up the loading process.
You can include a cache manifest within your game by using the manifest attribute of the <html> element:
Writing a cache manifest is straightforward and requires you to follow a simple format to declare the files that you want cached. For example, the manifest below looks for /example/bar online and falls back to the locally-cached example.html file if your player is offline or experiencing network issues:
There is much more to cache manifest than this, so I advise you to read the documentation to discover it in detail.
Another technique you can use is to store a player’s game data locally and periodically sync it with the game server. Normally you wouldn’t be able to store enough data in the browser to achieve this (like with cookies) but with Local Storage and IndexedDB, you can now store many megabytes of data in a structured way.
You can also add functionality to your game so it is alerted when a player’s Internet connection goes offline. The navigator.onLine property allows you to use JavaScript to see if your player is currently online or not. You can also use the offline and online events to trigger automatic behaviour in your game when a change in connection occurs, like stopping all WebSockets communication and caching player data locally until the connection is back.
Creating native OS applications with WebRT
One of the more profound aspects of the Mozilla Labs Apps project is the integration of a Web run-time (WebRT). This allows players to install your game "natively" on their chosen operating system (Windows, Mac, and Android right now), with a launch icon just like standard OS applications.
WebRT also runs your game using an app-centric user agent (in contrast to browser-centric user agents like Firefox) and runs your game using a separate user profile and OS process to your player’s normal Firefox that they use for browsing.
The ability of WebRT to break away into another process and remove all the browser UI makes the experience for gaming that much sweeter. There’s something about having an icon in the dock on a Mac that launches your game in it’s own "native" window with no mention or feel that this is a browser.
As a developer this is slightly magical. It allows you to break free from a game being a glorified website, instead turning it into an application, an experience in its own right. Mark my words, this will be a turning point in the transition from 5-minute puzzle games on the Web to professional-grade games that have a console-like experience.
As you can see it’s a simple JSON structure. You would then need to pass that manifest file in the call to the navigator.mozApps.install method:
function installCallback(result) {
// great - display a message, or redirect to a launch page
}
function errorCallback(result) {
// whoops - result.code and result.message have details
}
navigator.mozApps.install(
"http://rawkets.dev:8000/manifest.webapp",
installCallback,
errorCallback
)
This is the most basic implementation possible and would result in a panel popping up in the player’s browser asking if they’d like to install your game and whether they’d like that installation to be a native app or not (like the screenshot above).
Making money from your passion with the Mozilla Labs Apps project
Finally, the last thing about the apps project that I want to cover is that of making money from your game. Let’s be honest, if you can’t make a living from something then you’re going to have a hard time keeping it up for a long period of time.
For the Mozilla app marketplace we are using PayPal as the payment provider. All you need do is set a price on the store and the rest will happen automatically as people start paying for your game — you’ll start receiving money in your PayPal account.
In the future you’ll be able to provide your game on your own website or another store and charge for it there also. This means you’ll be able to use your own payment provider.
Scratching the surface
These technologies are really just scratching the surface when it comes to creating games on the Web using open technologies. At Mozilla we’re working hard to bring you these APIs and services to help make the Web a better place for games. The year 2012 will be a game-changer, for sure (pun intended).
Keep an eye on this blog as we’ll be sure to post more updates and guides as our gaming technologies and the apps project mature.
In the meantime, here are a few of places to go for extra information on the Mozilla Labs Apps project and gaming at Mozilla:
