Developers

Panel discussion at “We are Developers”: The Potentials and Pitfalls of Machine Learning

Back in March I was at We are Developers in Vienna, Austria, gave a two hour workshop on using AI on the web, a talk about code not being the answer to everything and MCed on the main stage on the third day. Another fun thing to do was this panel discussion on the Pitfalls of Machine Learning talking about the ethics and the false definitions of AI we have to battle.

I want to thank all people involved:

Moderator:
Jan Mendling ( @janmendling ), Full Professor at Vienna University of Economics and Business

Panelists:
Charlotte Han ( @sunsiren ) , Deep Learning Marketing Manager at NVIDIA
Tuomas Syrjänen ( @TuomasSyrjanen ), CEO of Futurice
Christian Heilmann, Sr. Program Manager at Microsoft
Rainer Steffl, CIO at Mondi Group

If you want to hear more about this topic and learn how to deal with it, I have a Skillshare course out there :

Chris Heilmann giving his course

“Introduction to Machine Learning: Using Artificial Intelligence” is about an hour of materials to get you familiar with the topic of AI.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

So I went to “We are developers” in Vienna…

A few days ago, I went to the We are developers congress in Vienna, Austria. The “Woodstock for developers” actually turned out to be a very well organized, but less wild event full of pretty amazing presenters and content. It was a developer conference, not as focused about all kind of web matters, but more holistically about development. Hence a lot of the topic revolved around DevOps, high level languages, Artificial Intelligence and Cloud matters.

Starting my presentation

My personal contributions were:

A two hour “workshop” on building intelligent, human interfaces using machine learning systems. You can look up the notes and links of this workshop. For bonus points, I got confused about the date of this workshop. As I just returned from Seattle there was a time-difference confusion and I arrived an hour before the workshop. I hadn’t slept for 30 hours and arrived 20 minutes late for it. However, people seemed to have enjoyed it and I got good feedback.

On the second day I gave one of the opening talks (“Killing the golden calf of coding”) and it was incredibly scary to be on a huge stage like that, were earlier Steve Wozniak worked his magic. The slides of the talk are on SlideShare:

Feedback was phenomenal:

I also took part in an Artificial Intelligence panel talking about the ethics and boundaries of AI.

On the third day I was the MC on the main stage, introducing and running the Q&A for Bitcoin expert Andreas Antonopulous, Ripple CTO Stefan Thomas, Google Angular expert Stephen Fluin, Futurist Martin Wezowski, Google iOS security expert Felix Krause, styled components inventor Max Stoiber and Stackoverflow/Fog Creek founder Joel Spolsky.

All in all, it was a very well organized event and it was great to meet some of my heroes (John and Brenda Romero of Wolfenstein/Doom fame) and many new ones.

I want to thank the organisers for having me and trusting me with so many things. I’m only sorry that I was pretty much shattered all the way as I had just come back from a few daunting days in Seattle the day before. I will come back to the event, as it is exciting and different at the same time.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox Hardware Report for Web Developers

Suppose you’re developing a sophisticated web game or application, and you’re wondering — will it actually be able to run? What hardware should I be targeting to get the widest possible audience? Existing hardware reports (such as those from Valve and Unity) are excellent, but represent a different group of hardware users than the majority of people who use the web.

We’ve been working on the next-generation web game platform for years now, and often receive questions from web developers about the hardware market. Today we’re releasing the Firefox Hardware Report to help answer those questions and inform your development decisions.

On this site you’ll find a variety of data points showing what hardware and OSes Firefox web users are using on the web, and trends over time. This includes CPU vendors, cores, and speeds; system memory; GPU vendors, models, and display resolution; Operating System architecture and market share; browser architecture share, and finally, Flash plugin availability. Some charts (such as the GPU models) have an expanded view showing all of the models captured. You’ll also discover all sorts of interesting stats — like 30% of Firefox users have 4 GB of RAM; that Intel makes 86% of users’ CPUs and 63% of their GPUs; or that the most popular screen resolution (with 33% of users) is 1366×768.

Firefox Hardware Survey

The Firefox Hardware Report is a public report of the hardware used by a representative sample of the population from Firefox’s desktop release channel. The source data for the Hardware Report was collected through the Firefox Telemetry system, which automatically collects browser and platform information from machines using Firefox. We use this data to prioritize development efforts and to power this report.

Once data is collected, we aggregate and anonymize it. During the aggregation step, less common screen resolutions and OS versions are handled as special cases — resolutions are rounded to the nearest hundred and version numbers are collapsed together in a generic group. Any reported configurations that account for less than 1% of the data are grouped together in an “Other” bucket. At the end of the process, the aggregated, anonymized data is exported to a JSON file and published on the report website.

To learn more about how we created this report, take a look at our blog post on the Mozilla Tech Medium. The code used to generate the reported data and website is available on GitHub.

This is just our first step, and we hope to expand this data set over time. In the meanwhile, please let us know what you think — is this data useful? What other data points might be helpful in the future? Do you have visualization suggestions? We look forward to your email feedback, with thanks!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Helping web developers with JavaScript errors

Errors are one of the more frustrating things you encounter while  programming. Those little messages in the console can ruin your entire afternoon, day, or week. When “undefined is not a function” appears yet again, it’s often time to get another coffee.

Even if you use the one true JavaScript exception handler, and have a lightning fast “copy and paste into $search_engine” reflex, the process of tracking down helpful information about an error can be annoying.

It doesn’t necessarily need to be that way! Some programming languages (hi Rust) take their error reporting to the next level by providing more information than just the fact that something went wrong.

We are not introducing JavaScript Clippy today. However, with the help of the MDN community, we are going to add links to documentation from error  messages that appear within the Firefox Developer Tools console.

This is to help you debug faster and learn more about JavaScript’s edge cases and lesser known functionality. Especially if you are new to JavaScript, we hope that you’ll appreciate this additional debugging help, or for those times when you’ve had too much coffee and you still can’t find the solution.

Documenting all the JavaScript, DOM, and other varieties of error messages that are thrown at you is a lot of work. We are focusing on the most commonly thrown errors for now. If you feel like helping here, get in touch with the MDN community and we promise you’ll learn a lot about JavaScript’s interesting quirks!

Try a recent Nightly build of Firefox to test this feature, or have a look at the MDN JavaScript error documentation directly.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Resources for HTML5 game developers

Today we released Firefox 31 and it offers a couple of new features that help HTML5 game developers to code and debug sophisticated games. In addition Mozilla blogged about the first commercial games leveraging asm.js, Dungeon Defenders Eternity and Cloud Raiders both of which were cross-compiled in to JavaScript using the Emscripten compiler. Games like these show that HTML5 is ready as a game platform.

If you are interested in working with Emscripten you can get more information at the main Emscripten wiki or grab the code on the github page. Another good resource is the getting started with Emscripten tutorial on MDN. If you are wondering about the performance of asm.js, read asm.js performance improvements in the latest version of Firefox make games fly! for details.

In this post we’ll introduce you to some of the resources built by Mozillians that allow you to code and debug HTML5 based games. This list is not exhaustive and we appreciate feedback on any valuable resources that would help in this arena. Don’t be shy and tell us about them in the comments.

Where To Start

When developing an HTML5 based game, you have a lot of choices to make. These range from what editor to use, if the game will use Canvas 2d, WebGL, SVG, or CSS up to which specific rendering frameworks and game engines to use. Most of these decisions will be based on the developer experience and the platforms the game will be published on. No article will answer all these questions but we wanted to put together a post that would help get you started down the path.

One of the key resources available for game developers on MDN is the Games Zone. This section of MDN contains general game development articles, demos, external resources and examples. It also includes detailed descriptions of some of the APIs that a developer will need to be aware of when implementing an HMTL5 game, including sound management, networking, storage and graphics rendering. We are currently in the process of adding content and upgrading the zone. In the future we hope to have content and examples for most common scenarios, frameworks and tool chains.

In the meantime here are a few posts and MDN articles that help game developers getting started.

Tools

As an HTML5 developer you will have no shortage of tools at your disposal. In the Mozilla community we have been hard at work expanding the features that Firefox Developer Tools provide. These include a full-featured JavaScript Debugger, Style Editor, Page Inspector, Scratchpad, Profiler, Network Monitor and Web Console.

In addition to these, some notable tools have been updated or introduced recently and offer some great functionality for the game developer.

Canvas Debugger

With the current release of Firefox, we added a Canvas Debugger to the browser.
s_canvasdebugger
The Canvas Debugger allows you to trace through all canvas context calls that are used to generate a frame. Calls are color coded for specific calls for things like drawing elements or using a specific shader program. The Canvas Debugger is not only useful when developing a WebGL based game but can also be used when debugging a Canvas 2D based game. In the game below you can see in the animation strip as each image is drawn to the canvas. You can click any of these lines to get directly to the part of your JavaScript responsible for this action.
s_captainrogers
Two very common issues that have been reported when using the Canvas Debugger are with animations generated using setInterval instead of requestAnimationFrame and inspecting canvas elements in an iFrame.

To get more information about the Canvas Debugger be sure to read over Introducing the Canvas Debugger in Firefox Developer Tools.

Shader Editor

When developing WebGL based games it is very useful to be able to test and alter shader programs while the application is running. Using the Shader Editor within the developer tools makes this possible. Vertex and Fragment Shader programs can be modified without the need to reload the page, or black boxed to see what effect this has on the resulting output.
s_ShaderEditor

For more information on the Shader Editor, be sure to see Live editing WebGL shaders with Firefox Developer Tools post and take a look at this MDN article which contains a couple of videos showing live editing.

Web Audio Editor

The current version of Firefox Aurora (32) – has a Web Audio Editor. The Editor displays a graphical representation of all the Audio Nodes and their connections in the current AudioContext. You can drill down to specific attributes of each node to inspect them.
s_webaudioeditor

The Web Audio API provides more robust and complex sound creation, manipulation and processing than what is available in the HTML5 Audio tag. When using the Web Audio API make sure to read over Writing Web Audio API code that works in every browser as it contains pertinent information about support for the various audio nodes.

For more information on the Web Audio Editor be sure to read this Hacks article introducing the Web Editor and this MDN article.

Network Monitor

When developing an HTML5 based game network impact can be not only cumbersome but also costly if the user is on mobile device. Using the Network Monitor you can visually inspect all network request for location, time spent on the operation, and the type and size of the artifact.
s_networkmon
In addition you can use the Network Monitor to get a visual performance analysis of your app when cached versus non-cached.
s_networkcache

To get more information on the Network Monitor see the MDN page.

Web IDE

When starting your game one of your first choices will be which editor to use. And there are a lot of them (Sublime, Eclipse, Dreamweaver, vi, etc). In most cases a you already have a favorite. If you are interested in doing your development within the Browser you may want to have a look at the Web IDE that was recently released in Firefox Nightly.
s_webide

The Web IDE project provides not only a fully functional editor but also acts as a publishing agent to various local and remote platforms, debugger, template framework and application manager. In addition the framework supporting this project provides APIs that will allow other editors to use functionality provided in the tool. To get more details on the work that is being done in this area have a look at this post.

In order to keep up-to-date with news on the Firefox Developer Tools, follow their article series on the Hacks blog. For more detailed information on new, stable developer tools features, check out their documentation on MDN.

APIs

The MDN Games Zone lists various APIs and articles that are useful for beginning game development.
s_apis
In addition to these resources you may be interested in looking over some additional posts that can be valuable for development.

If your game is going to support multiplayer interaction using either WebRTC or WebSockets you may also be interested in looking at Together.js which provides collaborative features for web apps. To get an idea what is possible take a look at Introducing TogetherJS.

Many games will require storage and IndexedDB can be used to handle these needs. For information on extending the capabilities of IndexedDB read over Breaking the Borders of IndexedDB. You may also be interested in localForage which provides browser agnostic support for simple storage. To get more details about this library read over this Hacks post.

Game Optimization

HTML5 games today offer a great deal of power to the game developer. That said many of these games are going to be played on a mobile device, which in comparison to your desktop will pale in performance. So if you plan on your game being a success across platforms it is important that you optimize your code. The Optimizing your JavaScript Game for Firefox OS post has a lot of great techniques to help you build a game that performs well on low-end mobile devices.

Localization

In order to reach the most users of your game you may want to consider offering it in different languages. As part of this developers should start with localization built into the game. We are doing a great deal of work around recruiting translators to help you translate your game. To get more information about this initiative see this post.

Your Voice

As Mozilla is about the community of developers and users, we want your help and your feedback. If you have recommendations for specific features that you would like to see in the products make sure to either get involved in discussion on irc.mozilla.org or through our mailing lists. You can also log bugs at bugzilla.mozilla.org. In addition we are also provide additional feedback channels for our DevTools and Open Web Apps.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Quick Note: Mozilla looking to survey Mobile App Developers in the Bay Area – tell us what you need

The Mozilla User Experience Research team is looking for developer who have experience writing mobile Web apps in the Bay Area to participate in a paid research study that will have a significant impact on making our developer-focused efforts even better.

To qualify for the study, please take this 10-minute survey.
If you’re eligible, a member of our team will contact you to tell you a little more about the research and schedule time with you. Developers who qualify for and fully participate will receive an honorarium of $250.

We’re looking for developers who are:

  • willing to participate in a 2-hour in-person interview at their workplace or home
  • available for the interview the week of March 10 to 14 (the weekend before / after may also be possible)

The interview will be recorded, but all materials will be used for internal research purposes only.

You DON’T have to use Mozilla products or be part of our community to participate (in fact, we’d like to hear your voice even more!).

Your feedback has the potential to improve the experience of other Web app developers and influence the direction of our products and services, so we would love to get a chance to talk with you! Please feel free to share this opportunity widely with your own network as well.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Five Potential Privacy Pitfalls for App Developers

Fighting for data privacy — making sure people know who has access to their data, where it goes or could go, and that they have a choice in all of it — is part of Mozilla’s DNA. Privacy is an integral part of building an Internet where people come first.

“Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional.” ~ Mozilla Manifesto (principle #4)”

On January 28th, the world will celebrate Data Privacy Day — an international holiday intended to raise awareness and promote data privacy education. It is officially recognized in the United States, Canada, and 27 European countries.

As part of our own Data Privacy Day celebrations this year, we have created a developer-specific list of Privacy Pitfalls to watch out for:

1. More isn’t always better

Collecting lots of data is seductive but in a privacy context can create risk (the more you have, the more you need to protect) and a lot of additional work. A privacy policy, for example, may require you to publicly share:

  • What personal information your app collects
  • Why you are collecting it
  • Where it will be stored (on the device or elsewhere)
  • Who it will be shared with and why
  • How long you will keep it
  • How a user can have their data removed

What’s more, you are on the hook to make sure all of the things you’ve communicated are really happening.

The key is to collect only what you need. When you are in the planning stages for your app, document the data collection, usage and flows. You should be able to justify each piece of personal information and describe how it will be used. If you plan to collect personal information for future or extra features beyond core functions, always give users the ability to opt-out.

Finally, know which types of data collection require informed consent such as information about a user’s movements and activities through the use of location and movement sensors, sound, or activation of the device camera.

2. Avoid treating your user’s contacts as your own

“Share” buttons and social media sign-in widgets are ubiquitous in today’s apps and Web sites. And while these buttons may make it easier for users to share information, they are not an all-access pass into your user’s address book.

Respect for the people who use your software; allowing them to control what’s being shared and with whom, builds trust and loyalty. These two things have the potential to be exponentially more valuable than a random connection with a stranger.

3. Provide a fair trade for the data you collect

User data is undeniably valuable and collecting it isn’t inherently wrong, especially with consent. Oftentimes though, users are asked to trade their valuable personal data without much in return (sometimes, as in the address book example above, they may not even know they’re giving you anything).

Collecting data with a fair trade mindset — making sure the people who give you their information are getting something in return (features, a personalized experience, etc.) helps the user feel respected and in control — resulting in an invaluable sense of trust and loyalty.

4. Understand all the privacy conditions you yourself are agreeing to

If you use third party services, like analytics or ad networks, make sure you are aware of their data collection practices as well as your own — they could impact your users. Third party code or software development kits can contain code you aren’t aware of. Providing accurate information to your users on the data collected by these organizations should be part of your privacy policy, and disclosed as if you were collecting it yourself.

Best to identify third parties by name and to link to information about how to modify or delete the data they collect. You should also consider providing a means for your users to opt out of such tracking.

5. There is no “one policy fits all” when it comes to privacy

Despite your best intentions to respect user privacy, legal requirements and user expectations can vary widely – a challenge made especially acute now that apps are available to a global audience. While we can’t give you legal advice, we can share some of the nuggets we’ve found through our user research in different countries:

  • In the US, non-technical consumers care more about their social circle tracking their online behavior than companies or the government.
  • In Thailand, relatives share and swap devices freely with each other, with little desire to create individual accounts or erase their personal data.
  • In Germany and most of Europe, consumers are quite sensitive about sharing their personal information with companies and governments, and those countries have strict laws to reflect that stance.
  • In Brazil, the middle class is more concerned about thieves physically stealing their devices (particularly mobile phones) than about online piracy.

Ultimately, talking to real users first can go a long way in making an app that truly reflects their privacy concerns. Engaging with real users not only reveals unique behaviors, but also digs into the motivations and emotions that drive these preferences.

In our experience, it can be hard for users to articulate how they feel about privacy. With the exception of privacy-sensitive countries/individuals, “privacy” may not always be top of mind. Rather than using the term “privacy” when talking to users, we’ve had success asking specific questions, such as who the user feels comfortable sharing personal information with and why, rather than to trying to get the participant to talk about privacy in an abstract way.

Do you have experiences related to these pitfalls? What others have you encountered in your work? Let us know in the comments!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

WebAPIs – Firefox OS for developers: the platform HTML5 deserves

In the fifth video of our “Firefox OS – the platform HTML5 deserves” series (part one, part two, part three and part four have already been published) we talk about how Firefox OS extends the capabilities of the Web by adding new APIs, called WebAPIs to the existing stack of technologies.

Firefox OS - be the future

Check out the video featuring Chris Heilmann (@codepo8) from Mozilla and Daniel Appelquist (@torgo) from Telefónica Digital/ W3C talking about the need for device APIs on the Web, how some of the existing APIs can be used and how the work on Firefox OS benefits the Web as a whole. You can watch the video here.

The WebAPI work is important as it allows apps built with Web technologies to access the hardware. For the work on Firefox OS (which is fully built in HTML5 itself), we very much needed to know the status of the phone, how much battery is left, what the connectivity is like, the screen orientation and many more features. Thus we defined access to the various parts of the hardware as JavaScript APIs and sent these as proposals to the standard bodies.

If you want to learn more about these new APIs the canonical place to go to is the WebAPI Wiki Page where you can find an up-to-date list of all the APIs, their implementation status in the different Firefox platforms, the standards bodies involved and where to file bugs for them. You can also click through to bugzilla to see demos of the APIs in action. We’ve blogged here about WebAPIs in detail before: Using WebAPIs to make the web layer more capable and you can see a lot of information and demos in that post.

In general, all the APIs follow a simple model: you ask for access and you define a success and failure handler. You also get methods to ask for various properties in detail and some have Boolean values available to you. This makes it very easy to test for the support of a certain API before trying to access it.

Not all APIs can be available on the open Web as we can not trust every server out there. That is why the APIs come in three flavours: regular, privileged and certified. Regular APIs can be used in any app, regardless of its location (you can self-host these apps). Examples for that are the geolocation or the battery API. Privileged and Certified APIs both need your app to have a content security policy and be hosted on Mozilla servers. That way we can give you access to the hardware but minimise the potential of abuse and malware at the same time.

Take a look at the exhaustive list of blog posts here dealing with WebAPIs for more reading and we’ll be back with the next video covering WebActivities soon.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Firefox Marketplace and alternatives – Firefox OS for developers: the platform HTML5 deserves

In the fourth video of our “Firefox OS – the platform HTML5 deserves” series (part one, part two and part three have already been published) we talk about how to submit apps to the Firefox Marketplace, and explain alternative ways to distribute your apps.

Firefox OS - be the future

Here are Mozilla’s principal developer evangelist Chris Heilmann (@codepo8) and Desigan Chinniah (@cyberdees) of the Firefox OS business development team showcasing how easy it is to get your app published on Firefox OS. You can watch the video on YouTube.

Firefox OS – like any other mobile platform – has a marketplace that allows you to find apps by name or category.

marketplace

As a developer, to submit your app to the marketplace all you have to do to is to create a manifest file and host it on your server (make sure to give it the correct MIME type “application/x-web-app-manifest+json”). In the manifest you define name of your app, provide icons and ask for permission to access web activities and other functionality. You can validate your manifest online before going further to avoid erroneous submissions.

Once you have your manifest in place, you can submit your app to the marketplace. There you provide screenshots or videos and a longer description of your app.

If the app is hosted on your server, you get all the HTML5 functionality you expect to get. You don’t get access to the camera or the contact book though. To get this, you need to package your app and host it on the marketplace. You can get more information on the different levels of app privileges on the Wiki.

As your apps are HTML5 apps you can also install them directly from the web without having to go through the marketplace. This also means that we don’t break the link-ability of the Web – you can send someone a link that will trigger the app install on a device that allows for the Open WebApps standards proposal (Firefox OS or Android with Firefox installed). This proposal is part of the WebAPI proposals and allows you to create a “install this app” button with a few lines of code:

if (navigator.mozApps) {
  function install() {
    var installapp = navigator.mozApps.install(manifestURL);
    installapp.onsuccess = function(data) {
      // App is installed
    };
    installapp.onerror = function() {          
      // Something went wrong,
      // information is in: installapp.error.name         
    };         	
  }
  var button = document.createElement('button');
  button.innerHTML = 'Install this app';
  button.addEventListener('click', install, false);
  document.body.appendChild('button');
}

This allows you to re-use all the effort you put into promoting your existing web presence to become the advertisement for your app.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Getting started with apps – Firefox OS for developers: the platform HTML5 deserves

In the third instance of our “Firefox OS – the platform HTML5 deserves” video series (part one and part two have already been published here) we talk about tools available for building apps for Firefox OS.

Firefox OS - be the future

Check the short video featuring Chris Heilmann (@codepo8) from Mozilla and Daniel Appelquist (@torgo) from Telefónica Digital/ W3C talking about starting your first HTML5 app. You can watch the video here.

First things first: you don’t build apps for Firefox OS – you build HTML5 apps for the Web. Firefox OS enables you as a developer to access the hardware of the phone by means of Web APIs – JavaScript APIs that are proposals to the standards bodies to give secure and simple access.

This means first and foremost that for web developers, nothing changes. There is no SDK for the web you need to download and install. You can use the editor and tool chain you are familiar with. This could be as simple as VI on the command line, or Eclipse as you are working with other languages than the web ones. Firefox OS doesn’t demand any fixed environment, much like the Web doesn’t. That said, there are efforts to create HTML5 tools out there and Mozilla is keeping a close eye on these efforts to see where and if partnering makes sense.

To get you started with building a Firefox OS app, you simply start with an HTML5 application in your browser. Whilst the first wave of Firefox OS devices have a resolution of 320 x 480 pixels, you should not fix your app to that size. Embracing the ubiquitous nature of the web, it seems prudent to use a responsive design approach. We’ve collected a lot of information on how to design a good HTML5 app on the Firefox OS developer hub.

One great feature of the Firefox Developer Tools is the responsive view mode. You can turn this one on by opening the developer tools and clicking the responsive mode icon. This will result in the current page becoming re-sizable in the browser without losing the developer tools or having to resize the window: the responsive mode in the Firefox developer tools allows you to resize your app without resizing the browser

Firefox is not the only browser with great developer tools built in. Chrome, for example allows you to simulate touch events when you are not on a touch device. To enable this, go to the developer tools settings, click “Overrides” and check the “Enable touch events” checkbox. For some great tips on when to use touch and when to use click, check out this video by Peter-Paul Koch (@ppk).

If you want to test Firefox OS itself or how your app performs in it – including the install process – you can download the Firefox OS simulator, a no-restart-required add-on for Firefox.

Once installed, you get a dashboard that allows you to manage your applications on your computer and start or stop the emulator:firefox emulator dashboard

When you start the simulator, you get a clean instance of Firefox OS running on your computer in a window of the right dimensions. You
can try out the OS, install your apps and see what the experience is like. simulator

More detailed testing of the performance of your apps requires a Firefox OS device. If you have one of them, you can connect the phone via USB and send your app directly from the simulator to the phone.

device connected

The tooling space of HTML5 applications is one of the most discussed markets on the Web right now. We are confident that in the nearer future a lot of new, amazing tools will become available to make HTML5 app development easy and give developers the insights they need when they develop. For now, using the browsers’ developer tools and the Firefox OS sSimulator will get you 90% on the way.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)