Development

Working with All Star Code in NYC to empower minorities to get into development

Sometimes it is great to work for a large company that gives you opportunities to do some good. I am currently in New York to run a workshop with All Star Code in our offices. Originally Aaron Gustafson was supposed to also be part of this but he got sick. Instead I am happy to work with Rachel White, Claudius Mbemba and Adina Shanholtz to help All Star Code.

Originally All Star Code approached me to get a bulk order for Surfaces for their students to work with. When I heard that their curriculum was involving Git, Node, Web Development and Debugging in Browsers and the stack was Sublime Text and Chrome Devtools I offered a small change. So now we’ll be teaching the teachers of All Star Code’s next course how to use Visual Studio Code and do all the development and debugging inside that one. My main driver there was that Code is open source and thus the students don’t need to get another license.

If you wonder what All Star Code does you can head over to the Decoded Chats blog, where I interviewed Mahdi Shadkamfarrokhi, their head of curriculum.

If you prefer to have an audio version, you can download it here (MP3, 18MB)

Here are the questions I asked:

  1. You work for All Star Code. Can you give us a quick introduction what that is and what you do? (00:13)
  2. How low are the numbers of developers that came from a minority background? What are the main reasons? (01:40)
  3. Do you think that by teaching communication skills together with technological skills you become more interesting for someone with a less privileged background? Is selling technology skills as a part of a whole package more successful? (02:49)
  4. The program has been running for quite a while. Is there a success story you are really proud of? (04:20)
  5. You learn a lot by teaching as you can’t fake it – you have to know. Do you find that it is easier to keep your skills up-to-date by running this program? (04:46)
  6. What are the biggest barriers for your students to get into development? Is it hardware access? Connectivity? The style and language of documentation out there? (06:14)
  7. I learned a lot because when I started computers didn’t do much and you had to program. Do you think that nowadays kids are less inclined to learn as computers are more seen as a consumption device? (07:47)
  8. There is a vast amount of online courses to choose from when it comes to learning how to program. Many of them decayed a bit after the first round of funding dried out. How do you find great and trustworthy resources? (10:10)
  9. A lot of creativity happens on the web but these makers don’t know or don’t get into professional development. Where do you go to find people for your course? (12:04)
  10. Do you see Open Source and services like GitHub to host, document and discuss your projects as an opportunity for newcomers? (14:49)
  11. How can people help you? Are there ways to volunteer? (18:07)

I’m very excited to be working on this.

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)

HTML 5 game development video series

Do you want to develop a game? Here’s an introductory video series to get you started on HTML 5 game development!

Why HTML 5

The first video offers some reasons to consider making a game for the web: the power of having no friction in distribution, the freedom from siloed marketplaces, the choice of tools and APIs that are available to you, etc.

Engines and libraries

The second video provides an overview of the current engines and libraries you can use to create your game. We cover pure JavaScript libraries (such as Phaser) as well as multi-platform engines that can export to HTML 5 (such as Unity).

Firefox developer tools

Next in series, we have a hands-on video that shows how to use the developer tools in Firefox Developer Edition to debug and profile your game. Modifying code on the fly, adapting our game to different screen sizes, debugging… it’s all here!

Tips for game jams

Last, there is a video for all of you joining a game jam –these competitions where you develop a game over a weekend. I have participated in many, and I know first-hand how hard and challenging game jams are! I hope these tips might be of help.

And don’t forget, if you create an HTML 5 game, tell us about it here. I’d love to play it!

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)

Web Professional trends – 2016 – web development

In many ways, 2016 is shaping up to be an incredible year for changes in web development. Of course, that statement also applied to 2015, 2014; the more things change, the more they remain the same. That being said, here are some trends we see that we believe Web Professionals (particularly web developers and project managers) need to know about this year. These seem to be gaining momentum (and are the most obvious as we write this).

 

NoSSQL databases will be used more and more. Massive amounts of data (and associated analytics) are being used in applications and these applications (and analytics) are more real time than ever before. This is why we see trends like the InnoDB engine being added to MySQL. Availability and speed seem to be the focus today. For example, applications like Moodle rely more and more on InnoDB.

 

Animations are making a comeback to draw attention to parts of a page. This can be as simple as parallax scrolling or animations as one hovers over a part of a web page. Yes, CSS can be employed for some of these effects, but many will continue to rely on JS frameworks.

 

Page load speed is also becoming increasingly important. Most site visitors do not want to wait more than a few moments for a page to load. Keep in mind that we just stated animations are making a comeback (so your animations must load quickly – use CSS-3 where appropriate instead of JavaScript). Take advantage of approaches to reduce page load times (whether using a CDN [Content Delivery Network] or using GZIP to compress images and text).

 

There remain a number of language choices. For example, JavaScript and Java remain the most popular on GitHub. Make certain you are well versed in more than one (for example, JavaScript, PHP, and Python). Make certain you have examples to show to potential clients. Make certain you understand how to employ secure coding techniques in the languages you use. Details can be found at GitHub.

 

The use of containers (relying on Docker) will continue to grow. The big advantage to this approach is that one container has the dependencies to run the application. We don’t need to focus so much on the environment where the application will be deployed. This quote (from the Docker website) sums up this approach:

 

“Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.”

 

Ok, what does this mean for web professionals? We already know that page load times matter. So does responsive design. We need to continue to reinforce that message to clients (and potential clients). Have a set of specific reasons why these items matter. Prepare and present your arguments using the lens of business. For example, if a page takes too long to load, it is likely our customer will go to a competitor’s website. Here is how we can reduce the load times…

 

Are you comfortable talking about NoSQL? Do you have an example of a project where you used NoSQL?  What about containers/ Docker? Can you explain these in terms a business client will understand? If not, spend some time developing basic information to share with clients. Help them understand why these trends are important. Most importantly, time is money. This is why containers are gaining in popularity so quickly. The old approach of creating virtual environments takes a lot of time (and most businesses don’t have that time to spend these days). Similarly, NoSQL is rising because of the amount of data and need to access it quickly. No, these databases may not meet all the ACID requirements. But you still need to know about them as your partners and clients will also be observing these trends (and wanting to use them in new projects this year).

 

Now is a good time to retool if you are not that familiar with these trends.

 

As an association for web professionals and those that teach, our goal is to keep you current with these trends. Also, we’re working on developing course structure on our training portal at our schoolofweb.org.

 

We hope that your new year is off to a great start.

Best always,
Mark DuBois, Community Evangelist and Director of Education

The post Web Professional trends – 2016 – web development appeared first on Web Professionals.

View full post on Web Professional Minute

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

Black Box Driven Development in JavaScript

Sooner or later every developer finds the beauty of the design patterns. Also, sooner or later the developer finds that most of the patterns are not applicable in their pure format. Very often we use variations. We change the well-known definitions to fit in our use cases. I know that we (the programmers) like buzzwords. Here is a new one – Black Box Driven Development or simply BBDD. I started applying the concept before a couple of months, and I could say that the results are promising. After finishing several projects, I started seeing the good practices and formed three principles.

What is a black box?

Before to go with the principles of the BBDD let’s see what is meant by a black box. According to Wikipedia:

In science and engineering, a black box is a device, system or object which can be viewed in terms of its input, output and transfer characteristics without any knowledge of its internal workings.

In programming, every piece of code that accepts input, performs actions and returns an output could be considered as a black box. In JavaScript, we could apply the concept easily by using a function. For example:

var Box = function(a, b) {
    var result = a + b;
    return result;
}

This is the simplest version of a BBDD unit. It is a box that performs an operation and returns output immediately. However, very often we need something else. We need continuous interaction with the box. This is another kind of box that I use to call living black box.

var Box = function(a, b) {
    var api = {
        calculate: function() {
            return a + b;
        }
    };
    return api;
}

We have an API containing all the public functions of the box. It is identical to the revealing module pattern. The most important characteristic of this pattern is that it brings encapsulation. We have a clear separation of the public and private objects.

Now that we know what a black box is, let’s check out the three principles of BBDD.

Principle 1: Modulize everything

Every piece of logic should exist as an independent module. In other words – a black box. In the beginning of the development cycle it is a little bit difficult to recognize these pieces. Spending too much time in architecting the application without having even a line of code may not produce good results. The approach that works involves coding. We should sketch the application and even make part of it. Once we have something we could start thinking about black boxing it. It is also much easier to jump into the code and make something without thinking if it is wrong or right. The key is to refactor the implementation till you feel that it is good enough.

Let’s take the following example:

$(document).ready(function() {
    if(window.localStorage) {
        var products = window.localStorage.getItem('products') || [], content = '';
        for(var i=0; i<products.length; i++) {
            content += products[i].name + '<br />';
        }
        $('.content').html(content);
    } else {
        $('.error').css('display', 'block');
        $('.error').html('Error! Local storage is not supported.')
    }
});

We are getting an array called products from the local storage of the browser. If the browser does not support local storage, then we show a simple error message.

The code as it is, is fine, and it works. However, there are several responsibilities that are merged into a single function. The first optimization that we have to do is to form a good entry point of our code. Sending just a newly defined closure to the $(document).ready is not flexible. What if we want to delay the execution of our initial code or run it in a different way. The snippet above could be transformed to the following:

var App = function() {
    var api = {};
    api.init = function() {
        if(window.localStorage) {
            var products = window.localStorage.getItem('products') || [], content = '';
            for(var i=0; i<products.length; i++) {
                content += products[i].name + '<br />';
            }
            $('.content').html(content);
        } else {
            $('.error').css('display', 'block');
            $('.error').html('Error! Local storage is not supported.');
        }
        return api;
    }
    return api;
}
 
var application = App();
$(document).ready(application.init);

Now, we have better control over the bootstrapping.

The source of our data at the moment is the local storage of the browser. However, we may need to fetch the products from a database or simply use a mock-up. It makes sense to extract this part of the code:

var Storage = function() {
    var api = {};
    api.exists = function() {
        return !!window && !!window.localStorage;
    };
    api.get = function() {
        return window.localStorage.getItem('products') || [];
    }
    return api;
}

We have two other operations that could form another box – setting HTML content and show an element. Let’s create a module that will handle the DOM interaction.

var DOM = function(selector) {
    var api = {}, el;
    var element = function() {
        if(!el) {
            el = $(selector);
            if(el.length == 0) {
                throw new Error('There is no element matching "' + selector + '".');
            }
        }
        return el;
    }
    api.content = function(html) {
        element().html(html);
        return api;
    }
    api.show = function() {
        element().css('display', 'block');
        return api;
    }
    return api;
}

The code is doing the same thing as in the first version. However, we have a test function element that checks if the passed selector matches anything in the DOM tree. We are also black boxing the jQuery element that makes our code much more flexible. Imagine that we decide to remove jQuery. The DOM operations are hidden in this module. It is worth nothing to edit it and start using vanilla JavaScript for example or some other library. If we stay with the old variant, we will probably go through the whole code base replacing code snippets.

Here is the transformed script. A new version that uses the modules that we’ve created above:

var App = function() {
    var api = {},
        storage = Storage(),
        c = DOM('.content'),
        e = DOM('.error');
    api.init = function() {
        if(storage.exists()) {
            var products = storage.get(), content = '';
            for(var i=0; i<products.length; i++) {
                content += products[i].name + '<br />';
            }
            c.content(content);
        } else {
            e.content('Error! Local storage is not supported.').show();
        }
        return api;
    }
    return api;
}

Notice that we have separation of responsibilities. We have objects that play roles. It is easier and much more interesting to work with such codebase.

Principle 2: Expose only public methods

What makes the black box valuable is the fact that it hides the complexity. The programmer should expose only methods (or properties) that are needed. All the other functions that are used for internal processes should be private.

Let’s get the DOM module above:

var DOM = function(selector) {
    var api = {}, el;
    var element = function() {}
    api.content = function(html) {}
    api.show = function() {}
    return api;
}

When a developer uses our class, he is interested in two things – changing the content and showing a DOM element. He should not think about validations or change CSS properties. In our example, there are private variable el and private function element. They are hidden from the outside world.

Principle 3: Use composition over inheritance

One of the popular ways to inherit classes in JavaScript uses the prototype chain. In the following snippet, we have class A that is inherited by class C:

function A(){};
A.prototype.someMethod = function(){};
 
function C(){};
C.prototype = new A();
C.prototype.constructor = C;

However, if we use the revealing module pattern, it makes sense to use composition. It is because we are dealing with objects and not functions (* in fact the functions in JavaScript are also objects). Let’s say that we have a box that implements the observer pattern, and we want to extend it.

var Observer = function() {
    var api = {}, listeners = {};
    api.on = function(event, handler) {};
    api.off = function(event, handler) {};
    api.dispatch = function(event) {};
    return api;
}
 
var Logic = function() {
    var api = Observer();
    api.customMethod = function() {};
    return api;
}

We get the required functionality by assigning an initial value to the api variable. We should notice that every class that uses this technique receives a brand new observer object so there is no way to produce collisions.

Summary

Black box driven development is a nice way to architect your applications. It provides encapsulation and flexibility. BBDD comes with a simple module definition that helps organizing big projects (and teams). I saw how several developers worked on the same project, and they all built their black boxes independently.

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)

Web Professional Trends for 2014 – Web Development with Raymond Camden

In this 10 minute interview with Raymond Camden, Developer Evangelist at Adobe Systems we talk about Web Professional Trends for 2014 including Web Development Trends and:

* How automation and scaffolding improvements will make projects set up easier and faster for Web developers
* Some industry and product consolidation and simplification will take place
* Lots of opportunities for designers and developers and those that straddle both
* Mobile Application Development provides great opportunity
* Recommended skills include Java and Objective C for both Android and IOS
* Hybrid tools like PhoneGap support non-programmers to participate in the mobile app development space

The post Web Professional Trends for 2014 – Web Development with Raymond Camden appeared first on Web Professionals.

View full post on Web Professional Minute

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

Web Professional Trends 2014 – Web Development with Charles Wyke-Smith

In this 5 minute interview with Charles Wyke-Smith, CEO @BublishMe we talk about Web Professional Trends in Web Development and Design for 2014 and:

• A shift to applications that have two binding associated with them
• Trends that will save you time and money
• Front end frameworks like NodeJS. Angular, Ember and Backbone
• JSON Databases
• Moving from Sql to JSON formats
• JavaScript Middleware
• Benefits of Angular to both Web developers and designers
• Roles, responsibilities and skills for Web developers and Web designers alike
• Underscore and handlebars and resources for Web designers

Node.js
Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. For additional information visit http://nodejs.org/

Why AngularJS?
According to AngularJS.org, HTML is great for declaring static documents, but it falters when we try to use it for declaring dynamic views in web-applications. AngularJS lets you extend HTML vocabulary for your application. The resulting environment is extraordinarily expressive, readable, and quick to develop. Other frameworks deal with HTML’s shortcomings by either abstracting away HTML, CSS, and/or JavaScript or by providing an imperative way for manipulating the DOM. Neither of these address the root problem that HTML was not designed for dynamic views. Extensibility. AngularJS is a toolset for building the framework most suited to your application development. It is fully extensible and works well with other libraries. Every feature can be modified or replaced to suit your unique development workflow and feature needs. For additional information visit http://angularjs.org/

What is Ember?
Ember.js is free, open source resource for Web professionals. According to EmberJS, Ember is a framework for creating ambitious web applications. Write dramatically less code with Ember’s Handlebars integrated templates that update automatically when the underlying data changes. Don’t waste time making trivial choices. Ember.js incorporates common idioms so you can focus on what makes your app special, not reinventing the wheel. Ember.js is built for productivity. Designed with developer ergonomics in mind, its friendly APIs help you get your job done—fast. For additional information visit http://emberjs.com/

JSON
JSON (JavaScript Object Notation) is a lightweight data-interchange format. According to JSON.org It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition – December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language. For additional information visit http://www.json.org/

Backbone.js
Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface. For additional information visit Backbone.js

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It’s the tie to go along with jQuery’s tux, and Backbone.js’s suspenders. Underscore provides 80-odd functions that support both the usual functional suspects: map, select, invoke — as well as more specialized helpers: function binding, javascript templating, deep equality testing, and so on. It delegates to built-in functions, if present, so modern browsers will use the native implementations of forEach, map, reduce, filter, every, some and index. For additional information visit http://underscorejs.org

HandleBarJS
Handlebars provides the power necessary to let you build semantic templates effectively with no frustration.
Mustache templates are compatible with Handlebars, so you can take a Mustache template, import it into Handlebars, and start taking advantage of the extra Handlebars features. For additional information visit http://handlebarsjs.com/

About Charles Wyke –Smith
A creative media professional focused on developing enterprise online SaaS applications and web sites that provide excellent user experience and quantifiable ROI. Charles has consulted and developed online applications, web sites and multimedia for Palm, Wells Fargo, ESPN Videogames UCSF, and Benefitfocus, and have held VP and other senior positions for online companies. The third edition of “Stylin’ with CSS” was published in November 2012. The first two editions have sold over 30,000 copies. “Scriptin’ with JavaScript and Ajax” was published 2009. and “Codin’ for the Web” in 2006, all on the New Riders imprint of Peachpit Books. The second edition of Stylin’ was published in December of 2007. He also published an eBook, “Visual Stylin’ with CCS3″, that was published in August 2012 that covers the advanced design and animation capabilities of CSS3.
For additional information visit ttp://www.stylinwithcss.com/

About Bublish’
Create book bubbles in seconds like the one to the right. Share them on multiple social networks as well as here on bublish.com.
Sharing your writing and insights is a fun and powerful way to be discovered by new readers.’ For additional information visit http://bublish.com/

The post Web Professional Trends 2014 – Web Development with Charles Wyke-Smith appeared first on Web Professionals.

View full post on Web Professional Minute

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

Mobile Application Development Technologies and Opportunities

Mobile Application Development Technologies and Opportunities – Interview with Jonathan Rende

In this 13 minute interview with Jonathan Rende, Vice President Products @Appcelerator we talk about:

* Native vs Mobile Application Development with HTML5
* Skills required for both
* The pros and cons of both
* Tools that can leverage existing HTML, CSS and JavaScript skills to develop robust Native apps
* Job opportunities Mobile Application Development.

The post Mobile Application Development Technologies and Opportunities appeared first on Web Professionals.

View full post on Web Professional Minute

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 OS Development: Web Components and Mozilla Brick

In this edition of “Firefox OS: The platform HTML5 deserves” (the previous six videos are published here), Mozilla’s Principal Evangelist Chris Heilmann (@codepo8) grilled Mozilla’s “Senior HTML5 Engineer Angle Bracket Coordinator” Matthew Claypotch (@potch) about the exciting new possibilities of Web Components for Web App developers and how Mozilla’s Brick library, a collection of custom elements to build applications with, can help with the transition. You can watch the interview on YouTube.

The Why of Web components

There is a problem with the Web as a platform for applications: HTML, the language that makes it easy to mark up documents and give them meaning doesn’t have enough elements to build applications. There are quite a few new elements in the HTML5 spec, but their support is sketchy across browsers and there are still a lot of widgets missing that other platforms like Flex or iOS give developers out-of-the-box. As a result, developers build their own “widgets” like menu bars, slider controls and calendars using non-semantic HTML (mostly DIV elements) and make them interactive using JavaScript and theme-able using CSS.

This is a great workaround but the issue is that we add on top of the functionality of browsers instead of extending the way they already function. In other words, a browser needs to display HTML and does a great job doing that at least 60 frames per second. We then add our own widget functionality on top of that and animate and change the display without notifying the browser. We constantly juggle the performance of the browser and our own code on top of it. This leads to laggy interfaces, battery drain and flickering.

To work around that problem a few companies and standards body members are working on the Web Components specification which allows developers to extend the browser’s understanding of markup with own elements. Instead of writing a slider control and make it work after the browser already displayed the document, you define a slider element and become part of the normal display flow. This means our widgets get more responsive, don’t work against the browser’s rendering flow and all in all perform better. Especially on low spec mobile devices this is a massive win. The whole thing already happens: if you for example add a video element to the document you see a video controller with a timed slider bar, a play button and volume controls. All of these are HTML, CSS and JavaScript and you can even see them in the debugging tools:

Anatomy of a video element

Firefox OS, being targeted at low end devices can benefit a lot from widgets that are part of the rendering flow, which is why Mozilla created Mozilla Brick, a collection of custom elements to build applications with. Earlier we introduced the concept using a library called XTags, which powers Brick. Using Brick, it is very simple to create for example a deck based application layout using the following markup:

<x-deck selected-index="0">
  <x-card>
    0<span>I'm the first card!</span>
  </x-card>
  <x-card>
    1
    <span>
      These cards can contain any markup!<br>
      <img src="../../site/img/grounds_keeping_it_real_s3.gif">
      <img src="../../site/img/grounds_keeping_it_real_s1.gif">
      <img src="../../site/img/grounds_keeping_it_real_s2.gif">
    </span>
  </x-card>
  <x-card>
    2 <img src="../../site/img/thumbs_up.gif">
  </x-card>
</x-deck>

The resulting app consists of three decks that can be animated into another without having to do anything but call a deck.shuffleNext(); function.

Web Components are a huge topic right now and many libraries and frameworks appear each week. We hope that by using Brick we can enable developers to build very responsive apps for Firefox OS quickly and cleanly and leave the pain of making your app perform really well up to the OS.

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 HTML5 Game Development

There are plenty of valid ways to create an HTML5 game, and quite a bit of material on the technical aspect of each, so for this article I’ll be giving more of a broad overview of HTML5 game development. How “HTML5″ can be better than native, where to start with the development process, where to go when you’re stuck, and how to monetize and distribute games.

Benefits of HTML5

Most of the audience here already sees the value in HTML5, but I want to re-iterate why you should be building an HTML5 game. If you are just targeting iOS for your game, write the game in Objective-C, the cons outweigh the benefits in that scenario… but if you want to build a game that works on a multitude of platforms, HTML5 is the way to go.

Cross-Platform

One of the more obvious advantages of HTML5 for games is that the games will work on any modern device. Yes, you will have to put extra thought into how your game will respond to various screen sizes and input types, and yes, you might have to do a bit of ‘personalization’ in the code per platform (the main inhibitor being audio); but it’s far better than the alternative of completely porting the game each time.

I see too many games that don’t work on mobile and tablets, and in most instances that really is a huge mistake to make when developing your game – keep mobile in mind when developing your HTML5 game!

Unique Distribution

Most HTML5 games that have been developed to this point are built in the same manner as Flash and native mobile games. To some extent this makes sense, but what’s overlooked is the actual benefits The Web as a platform adds. It’s like if an iOS developer were to build a game that doesn’t take advantage of how touch is different from a mouse – or if Doodle Jump was built with arrow keys at the bottom of the screen instead of using the device’s accelerator.

It’s so easy to fall into the mindset of doing what has worked in the past, but that stifles innovation. It’s a trap I’ve fallen into – trying to 100% emulate what has been successful on iOS, Android, and Flash – and it wasn’t until chatting with former Mozillian Rob Hawkes before I fully realized it. While emulating what worked in the past is necessary to an extent, The Open Web is a different vehicle for games, and innovation can only happen when taking a risk and trying something new.

Distribution for HTML5 games is often thought of as a weakness, but that’s just because we’ve been looking at it in the same sense as native mobile games, where a marketplace is the only way to find games. With HTML5 games you have the incredible powerful hyperlink. Links can so easily be distributed across the web and mobile devices (think of how many links you click in the Facebook and Twitter apps), and it certainly should not just be limited to the main page for the game. The technology is there to be able to link to your game and do more interesting things like jump to a specific point in a game, try to beat a friend’s score, or play real-time against that friend – use it to your advantage!

Take a good look at was has worked for the virality of websites and apply those same principles to your games.

Quicker Development Process

No waiting for compilation, updates and debugging in real-time, and once the game is done, you can push out the update immediately.

Choosing a Game Engine

Game engines are just one more level of abstraction that take care of a few of the more tedious tasks of game development. Most take care of asset loading, input, physics, audio, sprite maps and animation, but they vary quite a bit. Some engines are pretty barebones, while some (ImpactJS for example) go as far as including a 2D level editor and debug tools.

Decide Whether or Not You Need a Game Engine

This is largely a personal decision. Game Engines will almost always reduce the time it takes for you to create a fully-functional game, but I know some folks just like the process of building everything from the ground up so they can better understand every component of the game.

For simple games, it really isn’t difficult to build from scratch (assuming you have a JavaScript background and understand how games work). Slime Volley (source) for example was built without having a game engine, and none of the components were rocket science. Of course, Slime Volley is a very basic game, building an RPG from the ground up would likely lead to more hair pulling.

Choosing Between a “Game Engine” and a “Game Maker”

Most of the typical audience of Mozilla Hacks are probably going to lean toward using a game engine or building from scratch, but there is also the alternative of using a “Game Maker” like Construct 2. Using a Game Maker means you won’t actually write in JavaScript; instead, you create code-like events in the editor. It’s a trade of ease-of-use and quickness to prototype/develop vs customization and control over the end result. I’ve seen some very impressive games built with either, but as a developer-type, I tend to favor writing from scratch / using an engine.

Finding the Right Game Engine / Game Maker for you

There are so many HTML5 game engines out there, which in part is a good thing, but can also be a bad thing since a large percentage have either already stopped being maintained, or will soon stop being maintained. You definitely want to pick an engine that will continually be updated and improved over the years to come.

HTML5GameEngine.com is a great place to start your search because the hundreds of game engines are narrowed down to about 20 that are established, actively maintained, and have actual games being developed with them.

For a more complete list of engines (meaning there can be some junk to sift through), this list on GitHub is your best bet.

Learning Tools

If you’re going with a game engine, typically their site is the best resource with tutorials and documentation.

Technical Tutorials

Game Design Tutorials

With game development, the technical aspect isn’t everything – what’s more important is that the game actually be fun. Below are a few places to start when learning about game mechanics.

Helpful Game Tools

User Retention, Monetization and more

Full disclosure here: I am a co-founder at Clay.io.

Making a game function is just part of the equation. You also want players to play longer, come back, tell their friends about it, and maybe even buy something. Common elements in games that focus on these areas are features like user accounts, high scores, achievements, social integration, and in-game payments. On the surface most are typically easy enough to implement, but there are often many cross-platform issues and intricacies that are overlooked. There is also value in having a central service running these across many games – for example, players genuinely care about achievements on Xbox Live because Gamerscore matters to them.

  • Clay.io – user accounts, high scores, achievements, in-game payments, analytics, distribution, and more.
  • Scoreoid – similar to above.

Development Tools

  • stats.js – A JavaScript performance monitor. Displays framerate, and performance over time.
  • Socket.IO – realtime client-server communication (if you’re going to have a backend for your game).
  • pixi.js – A canvas and WebGL rendering engine.
  • CocoonJS – Improves HTML5 game performance on iOS and Android with an accelerated canvas bound to OpenGL ES.

Motivation

Regardless of what you’re building, extra motivation is always helpful. For games, that motivation often comes from surrounding yourself with others who are in the same boat as you – working on games.

js13kGames

js13kGames is a competition that is currently taking place at the time of this writing. You have until September 13th, 2013 to develop an HTML5 game that, when compressed, is less than 13kb.

Mozilla Game On

Mozilla runs a game competition every year from December through February with some fantastic prizes – last year’s was an all-expense paid, red carpet trip to San Francisco for GDC 2013.

Clay.io’s “Got Game?”

Clay.io (full disclosure, I am a founder) runs an annual HTML5 game development competition for students. Last year was the first year and we had over 70 games submitted. The next competition is planned for February / March 2014.

Ludum Dare

Ludum Dare isn’t for tangible prizes, nor is is specific to HTML5 games, but there are plenty of HTML5 developers that participate.

One Game a Month

One Game a Month isn’t so much a competition as it is an accountability tool. This isn’t restricted to HTML5 games, but many of the participants work with HTML5. The goal is to crank out one game every month. I wouldn’t recommend this long-term since one month is too short of a time to create a great game, but it’s good when learning to force yourself to develop and finish simple games.

Help From the Community

HTML5GameDevs.com

HTML5GameDevs has quickly become the most active community of HTML5 game developers. Most folks are very friendly and willing to help with any issues you run into.

#BBG

#BBG is the go-to IRC channel for HTML5 games – you’ll even find quite a few Mozillians hanging around.

How to Make Money

In-Game Purchases

In-game payments, in my opinion, are the way to go for HTML5 game in the long-term. For now, most HTML5 games don’t have enough quality content, nor the game mechanics in place to get player purchasing items.

This is the revenue model with the highest potential, but it’s also the most difficult to achieve by far – not technically, but having the right game. I’d say the best way to learn how to properly monetize your game in this aspect is to take a look at games that do it really well on Flash and Mobile – games from King.com and Zynga typically have this nailed down pretty well. There’s also some good reading material, like The Top F2P Monetization Tricks on Gamasutra.

Licensing

Where we’re at right now with HTML5 games, licensing games is the strongest, most consistent way to make money – if and only if your game works well on mobile devices.

There are countless “Flash Game Portals” that receive organic mobile traffic, but can’t monetize it with the Flash games they have. Their solution is to go out and find HTML5 games to buy non-exclusive licenses (the right to put the game on their site, often making small adjustments) to offer their mobile visitors.

Typically non-exclusive HTML5 game licenses (meaning you can sell to more than one site) go for $500-$1,000 depending on the game and publisher. Some publishers will do a revenue share model instead where you’ll get a 40-50% share on any advertising revenue, but no up-front money.

Licensing is the safest way to make money right now, but the cap is limited – the most you’re going to make with a single game is in the $5,000-$6,000 range, but it is easier to hit that mark than it is with in-game payments or advertising.

Advertising

Advertising is the middle-ground between in-game payments and licensing. It’s easier than in-game payments to make money and with a higher potential cap than licensing (but probably less than in-game payments). It’s easy enough to implement ads: just pick your ad network of choice (be wary of Adsense’s strict terms) and implement them either surrounding the game, or at various stopping points.

The commonly used ad networks are LeadBolt for mobile and CPMStar for desktop. You can also use Clay.io which makes it a bit easier to implement advertising, and tries to maximize the revenue by using different ad networks depending on the device used and other factors.

Distribution

The final stage in a game’s development is distribution. The game is done, now you want people playing the game! Fortunately, with HTML5 there are plenty of places to have your game (many of which often go unused).

More and more marketplaces these days are accepting HTML5 games as-is. Each has their own requirements (Facebook requires SSL, most require a differently formatted manifest file, etc…), but the time it takes to get into each is typically less than 30 minutes. If you want to reduce that even more, Clay.io helps auto-generate the manifest files and promotional image assets you’ll need (as well as takes care of the SSL requirement) – documentation on that here.

Some marketplaces you’ll need to have a native wrapper for your game – primarily the iOS App Store and Google Play. A wrapper like PhoneGap is one option, but the native webviews have pretty terrible JavaScript engines, so for now you’re better off with tools like CocoonJS and Ejecta.

Now it’s up to you to go forth and make a great, innovative web game – I’m looking forward to see what’s on the horizon in the coming months and years!

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)

Introducing Brick: Minimal-markup Web Components for Faster App Development

Those of you on the cutting HTML5 edge may have already heard of the exciting Web Components specification. If you haven’t, you’ll probably want to read up on what makes this so exciting, but long story short, Web Components promise to open up a new realm of development by letting web developers write custom, reusable HTML tags. Think of them as JavaScript plugins without the need for additional code initialization or boilerplate markup/styling.

Unfortunately, it will be a while before we see native browser support for the spec, but that doesn’t mean developers can’t start taking advantage of the component concept now, thanks to Google’s Polymer framework and Mozilla’s x-tags polyfill library (both X-Tag and Polymer share the same low-level, Web Component polyfills).

We’re proud to announce the beta release of Brick, a cross-browser library that provides new custom HTML tags to abstract away common user interface patterns into easy-to-use, flexible, and semantic Web Components. Built on Mozilla’s x-tags library, Brick allows you to plug simple HTML tags into your markup to implement widgets like sliders or datepickers, speeding up development by saving you from having to initially think about the under-the-hood HTML/CSS/JavaScript.

Putting Brick into Action

Say that you wanted to implement a cross-browser, mobile-friendly calendar widget in your application. With current JavaScript plug-ins, such as jQuery UI, this would require putting boilerplate, non-semantic markup into your HTML, as well as explicitly initializing and managing it through JavaScript. However, with Brick, you can implement such a component simply by adding a custom HTML tag that you can treat as a normal native tag.

For our calendar example, this means just including the library’s CSS and Javascript file in your application, then adding the following tag to your markup:

<x-calendar></x-calendar>

which creates a DOM element that looks like this:

Want to edit how the component behaves, such as by adding navigational controls or pre-selecting a date? Like any other native tag, you can change how a component behaves just by changing the attributes of the tag!

<x-calendar controls chosen='2012-05-17'></x-calendar>

Available Bricks

At the time of writing, Brick consists of thirteen different tags, most of which are completely independent of one another, and can even be downloaded separately instead of a single bundle.

Some tags abstract away complex widgets into simple HTML tags, such as:

Others are cross-browser polyfill implementations of existing native not-yet-globally-supported elements, such as:

which polyfill <input type="range"> and <input type="date">, respectively. Still others are structural components simplifying the styling and markup of certain components, such as <x-layout>, which ensures that content, headers, and footers can fill a container element without explicit styling markup.

Each tag comes with a flexible attribute/JavaScript API and can be fully styled to match your application.

Start Building with Bricks

Want to start using components in your own applications? Head to mozilla.github.io/brick to download a release bundles, view demos, and read the documentation for the available tags. Alternatively, visit the Brick Github page to view the source code and contribute to the effort!

The library is still in a beta release, so we appreciate all user feedback! Brick is already starting to crop up in the wild, so we’d love to hear about how you’re using it!

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)