Career advice, AI ethics and inspiring the next dev generation to care about the web at Web Unleashed

I just got back from Toronto, Canada, where I attended Web Unleashed a FITC organised three day conference with fifty talks in four tracks. Despite this size, the event felt cozy and not too spread out. There was a lot to learn and a truly stellar line-up of speakers to choose from.

Setting up for my AI talk

Originally I was lined up to give a workshop together with Burke Holland on developer toolchain setup, but there were not enough sign-ups, so I “only” spoke on a panel about “Life as a lead developer”, gave a talk about AI, ethics and building human interfaces and the closing keynote.

The slides of the AI and ethics talk are available here and I made a gist with all the resources I mentioned.

The closing keynote slides are also on together with the resources mentioned in that one.

The resources mentioned in this one are here:

I will write more about the subject of the closing keynote soon here.

I want to thank everyone involved in this event and hope that people learned something from my efforts. It is impressive how many great speakers were present and I had a wonderful time with some of the most relaxed parties.

I also realised that no matter how hard I try, I will never have the same presence as the devrel expert at the Shopify booth:

Walnut the dog

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)

Talking about building the next interfaces with Machine Learning and AI at hackingui

Yesterday I was proud to be an invited speaker at the HackingUI masterclass where I presented about what Machine Learning and Artificial Intelligence means for us as developers and designers. I will be giving a similar talk tomorrow in Poland in my Code Europe talk.

Speaking at the masterclass

The Masterclass is using Crowdcast to allow for discussions between the moderators and the presenter, for the presenter to show his slides/demos and for people to chat and submit questions. You can see the whole one hour 45 minutes session by signing up to Hacking UI.

Master Class #4: The Soul in The Machine – Developing for Humans

It was exciting to give this presentation and the questions of the audience were interesting which meant that in addition to the topics covered in the talk I also managed to discuss the ethics of learning machines, how having more diverse teams can battle the issue of job loss because of automation and how AI can help combat bullying and antisocial behaviour online.

The materials I covered in the talk:

All in all there is a lot for us to be excited about and I hope I managed to make some people understand that the machine revolution is already happening and our job is it to make it benefit humankind, not work against it.

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)

Maker Party 2014 – go and show off the web to the next makers

Today is the start of this year’s Maker Party campaign. What’s that? Check out this video.


Maker Party is Mozilla’s annual campaign to teach the culture, mechanics and citizenship of the web through thousands of community-run events around the world from July 15-September 15, 2014.

This week, Maker Party events in places like Uganda, Taiwan, San Francisco and Mauritius mark the start of tens of thousands of educators, organizations and enthusiastic web users just like you getting together to teach and learn the web.

You can join Maker Party by finding an event in your area and learning more about how the web works in a fun, hands-on way with others. Events are open to everyone regardless of skill level, and almost all are free! Oh, and there will be kickoff events in all the Mozspaces this Thursday—join in!

No events in your area? Why not host one of your own? Maker Party Resources provides all the information you need to successfully throw an event of any size, from 50+ participants in a library or hackerspace to just you and your little sister sitting on the living room sofa.

Go teach the web, believe me, it is fun!

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)

Build Your Next App With a Flame

Earlier this week, we introduced Flame, the Firefox OS reference device for developers, testers and reviewers from T2Mobile, and announced the opening of the pre-order page. The Flame retails at $170 (USD), global shipping included.

Wanted: Engaging apps for Firefox OS

Flame2If you are an experienced HTML5 app developer with a published, well-rated app that you’d like to port to Firefox OS, we’d love to hear from you! It’s always exciting to discover topnotch apps (such as PhoneGap app Find the Movie, pictured to the right running on a Flame) and see them ported from native platforms to Firefox OS. We currently have a small inventory of Flame phones for qualified HTML5 app developers with published, well-rated apps.

How to qualify

Through our ongoing Phones for Apps program, there’s an opportunity now for a limited number of invited app developers to receive Flame devices in exchange for a commitment to port their qualifying HTML5 apps within a month of receiving the device. Please apply here.

There are only three ways to qualify:

  1. You’ve built a successful, well-rated HTML5 app on another platform (such as Amazon Web Apps, Blackberry WebWorks, Chrome Web Store, WebOS, Windows Phone or the PhoneGap store) and are ready to port it now to Firefox OS.
  2. You’ve built a successful, well-rated native app for iOS or Android using a cross-platform wrapper like Cordova or PhoneGap and are ready to port it to Firefox OS. Be sure to indicate the cross-platform tool you used.
  3. You’ve already published a well-rated app in Firefox Marketplace, and you have a second app in progress or already built, and are ready to port it now to Firefox OS.


  • Learn more about the Flame (Mozilla Developer Network)
  • Get started with Open Web Apps (Mozilla Developer Network)
  • Mark your calendars for Marketplace Day, June 26 – it’s all about Apps and how you can contribute – as app developers, testers, reviewers and localizers. Hope you can join us!

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)

Edgeconf 3 – just be there next time, trust me

I just got back from Edgeconf 3 in London, England, and I am blown away by how good the event was. If you are looking for a web conference that is incredible value for money, look no further.


The main difference of Edgeconf is its format. Whilst you had a stellar line-up of experts, the conference is not a series of talks or even several tracks in parallel. Instead, it is a series of panels with curated Q&A in the style of Question Time on BBC. Questions are submitted by the audience before the conference using Google Moderator and expert moderator triage and collate the questions. Members from the audience read out the questions to the panel and the moderator then picks experts to answer them. Audience members also can show their intent to ask a question or offer extra information.

In essence: the whole conference is about getting questions answered, not about presenting. This means that there is a massive amount of information available in a very short amount of time and there is no chance to grand-stand or advocate solutions without proof.

The main workload of the conference is covered by the moderators. It is up to them to not only triage the questions but also keep the discussion lively and keep it entertaining.

All the moderators met the day before the event and spent half a day going through all the submitted questions and whittle them down to seven per panel. Each person answering a question has 30 seconds to a minute to answer and there is strict time-keeping.

The whole event was streamed live on YouTube and the recordings are available on Youtube/Google+.

During the panels, the audience can interact live using the Onslyde system. You can agree or disagree with a topic and request to speak or ask a question. All this information is logged and can be played in sync with the video recording later on. Onslyde also creates analytics reports showing sentiment analysis and more. Other conferences like HTML5DevConf, Velocity and OsCon also started using this system.

Another big thing about Edgeconf is that any of the extra income from tickets and sponsorship (in this case around £10,000) get donated to a good cause. At the end of the conference the organisers showed a full disclosure of expenditure. The cause this time was Codeclub, a charity teaching kids coding.

I am very proud to have been one of the moderators this time and run the accessibility panel (a detailed post on this comes later).

I have to thank the organisers and everyone involved for a great event. I learned a lot during the day and I am happy to be involved again in September.

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)

This developer wanted to create a language selector and asked for help on Twitter. You won’t believe what happened next!

Hey, it works for Upworthy, right?

Yesterday in a weak moment Dhananjay Garg asked me on Twitter to help him with a coding issue and I had some time to do that. Here’s a quick write-up of what I created and why.

Dhananjay had posted his problem on StackOverflow and promptly got an answer that wasn’t really solving or explaining the issue, but at least linked to W3Schools to make matters worse (no, I am not bitter about the success of either resource).

The problem was solved, yes (assignment instead of comparison – = instead of === ) but the code was still far from efficient or easily maintainable which was something he asked about.

The thing Dhananjay wanted to achieve was to have a language selector for a web site that would redirect to documents in different languages and store the currently selected one in localStorage to redirect automatically on subsequent visits. The example posted has lots and lots of repetition in it:

function english()
function french()
  window.location.href = "french.html";
window.onload = function() {
if (localStorage.language === "Language")
   window.location.href = "language.html";
else if (localStorage.language === "English")
   window.location.href = "eng.html";
else if (localStorage.language === "French")
  window.location.href = "french.html";
else if (localStorage.language === "Spanish")
  window.location.href = "spanish.html";

This would be done for 12 languages, meaning you’ll have 12 functions all doing the same with different values assigned to the same property. That’s the first issue here, we have parameters on functions to avoid this. Instead of having a function for each language, you write a generic one:

function setLanguage(language, url) {
 	localStorage.language = language;
 	window.location.href = url;

Then you could call for example setLanguage(‘French’, ‘french.html’) to set the language to French and do a redirect. However, it seems dangerous to clear the whole of localStorage every time when you simply redefine one of its properties.

The onload handler reading from localStorage and redirecting accordingly is again riddled with repetition. The main issue I see here is that both the language values and the URLs to redirect to are hard-coded and a repetition of what has been defined in the functions setting the respective languages. This would make it easy to make a mistake as you repeat values.

A proposed solution

Assuming we really want to do this in JavaScript (I’d probably do a .htaccess re-write on a GET parameter and use a cookie) here’s the solution I came up with.

First of all, text links to set a language seem odd as a choice and do take up a lot of space. This is why I decided to go with a select box instead. As our functionality is dependent on JavaScript to work, I do not create any static HTML at all but just use a placeholder form in the document to add our language selector to:

<form id="languageselect"></form>

Instead of repeating the same information in the part of setting the language and reading out which one has been set onload, I store the information in one singular object:

var locales = {
    'us': {label: 'English',location:'english.html'},
    'de': {label: 'German',location: 'german.html'},
    'fr': {label: 'Français',location: 'french.html'},
    'nl': {label: 'Nederlands',location: 'dutch.html'}       

I also create locale strings instead of using the name of the language as the condition. This makes it much easier to later on change the label of the language.

This is generally always a good plan. If you find yourself doing lots of “if – else if” in your code use an object instead. That way to get to the information all you need to do is test if the property exists in your object. In this case:

if (locales['de']) { // or - the bracket allows for spaces
	console.log( // -> "German"

The rest is then all about using that data to populate the select box options and to create an accessible form. I explained in the comments what is going on:

// let's not leave globals
  // when the browser knows about local storage…
  if ('localStorage' in window) {
    // Define a single object to hold all the locale 
    // information - notice that it is a good idea 
    // to go for a language code as the key instead of
    // the text that is displayed to allow for spaces
    // and all kind of special characters
    var locales = {
        'us': {label: 'English',location:'english.html'},
        'de': {label: 'German',location: 'german.html'},
        'fr': {label: 'Français',location: 'french.html'},
        'nl': {label: 'Nederlands',location: 'dutch.html'}       
    // get the current locale. If nothing is stored in 
    // localStorage, preset it to 'en'
    var currentlocale = window.localStorage.locale || 'en';
    // Grab the form element
    var selectorContainer = document.querySelector('#languageselect');
    // Add a label for the select box - this is important 
    // for accessibility
    selectorContainer.innerHTML = '<label for="languageselectdd">'+
                                  'Select Language</label>';
    // Create a select box 
    var selector = document.createElement('select'); = 'language'; = 'languageselectdd';
    var html = '';
    // Loop over all the locales and put the right data into 
    // the options. If the locale matches the current one,
    // add a selected attribute to the option
    for (var i in locales) {
      var selected = (i === currentlocale) ? 'selected' : '';
        html += '<option value="'+i+'" '+selected+'>'+
    // Set the options of the select box and add it to the
    // form
    selector.innerHTML = html;
    // Finish the form HTML with a submit button
    selectorContainer.innerHTML += '<input type="submit" value="go">';
    // When the form gets submitted…
    selectorContainer.addEventListener('submit', function(ev) {
      // grab the currently selected option's value
      var currentlocale = this.querySelector('select').value;
      // Store it in local storage as 'locale'
      window.localStorage.locale = currentlocale;
      // …and redirect to the document defined in the locale object
      alert('Redirect to: '+locales[currentlocale].location);
      //window.location = locales[currentlocale].location;
      // don't send the form
    }, false);

Surely there are different ways to achieve the same, but the important part here is that an object is a great way to store information like this and simplify the whole process. If you want to add a language now, all you need to do is to modify the locales object. Everything is maintained in one place.

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)

Make space for the next users of the web – Webvisions Barcelona 2013

WebVisions is an interesting series of events in the US and Europe. The audience is incredibly creative and mixed and the workshops range from the traditional web tech topics to robotics to hacking for good and up to getting kids to build their first machines.

This year I got invited to give the closing talk of the Barcelona instance of WebVisions and I went all out on that one. Instead of giving a detailed technical talk I took the opportunity to remind ourselves of the importance of a web for everyone and how we fail at delivering that old dream of its inventors.

The slides (without notes) are available on the web and the video of the screencast is on YouTube:

Here is a (long but also short) summary of what I was talking about: please don't hurt the web

I started the talk with an example how things can go wrong when they should be right. Richard Strauss’ “Also sprach Zarathustra” inspired by Friedrich Nietzsche’s book with the same title is an iconic piece of music. It was brought to a totally new audience with its use in 2001 – A space odyssey, the – in its own right – iconic movie by Stanley Kubrick. Now if you listen to this version, however, it sounds more like terrible things being done to elephants than the original song.

What happened? Were the musicians just terrible? Yes, but also, no. The second version is by the Portsmouth Sinfonia, a classical ensemble put together by either people who did not know how to play, but also by people who are gifted musicians, but weren’t allowed to play the instrument they know. It was a tongue-in-cheek experiment to see if musical genius is something that is given or can get taught to anyone with the right amount of effort.

The horrid, cacophonous outcome of this shows one thing – the wrong instruments in the hands of the right experts will not yield good results. And this is the vibe I am getting a lot when people speak about “the mobile web”. When smartphones came about everybody got incredibly excited: web developers saw a whole new market opening and new, interesting challenges coming towards them and native developers out of a sudden were asked to build things with web technology (this includes in my book Flash developers, who out of a sudden were asked to “do HTML5 as this works on iPhone”). The new form factor of smartphones brought up some new challenges for developers, who, until then, were used to catering to desktop users on fast, stable connections with computers that were in a certain range of resolutions. Out of a sudden, we found ourselves with new challenges:

  • Unknown, smaller screen size
  • New ways of interaction – touch, voice
  • Flaky, slow connections
  • Limited data plans
  • Less patient end users

Or so we told ourselves and people got very excited and worried about all these “new” things. We threw out a lot of truisms like “users on the phone are always busy and want a few big buttons as the interface” and started to consider locking our solutions down to one phone on one platform the only solution to delivering “exciting experiences”. If you took your job as a web developer serious though, then none of this should be new to you. We never were able to tell what the end user has at her disposal to consume what we put on the web and that is the beauty of it!

When Tim Berners-Lee came up with the idea of the web, the concept of what hardware and in what resolution or what connectivity it is consumed in was never, ever included. It is a system to deliver content and get it consumed by other computers. Or, as stated in the W3C Accessibility guidelines:

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability.

In other words: fiercely flexible is what the web should be. And the advent of smartphones and mobile computing consuming web content rather than just email and text messages brought this original idea more than ever back into the spotlight.

And instead of embracing it and finally giving in and saying “well, we have no clue what people use, so let’s use software to do what it does best – test and then adapt” we overload users on the desktop with lots and lots of widgets and an avalanche of content and we limit the mobile interfaces to the bare minimum, in many cases not even in a working fashion. The current mobile web is a failure, so much that clever marketers manage to sell to many companies the idea that asking users to “download the app” when they come to the site using a mobile device is the best choice. It reminds me of popup windows and Flash tunnels – both of which, luckily, are hardly ever used any longer.

Which is weird and disheartening seeing just how blessed we are these days with great tools to learn our trade. There are dozens of online course companies out there – many of them free and even then very high quality. Our browsers have amazing debugging tools and there is a large amount of collaborative editing tools out there where you can try and debug together with other people.

How is it we are losing ground? How is it that webstandards based interfaces are such a disappointment? Well, there are a few reasons:

First, we are too busy fixing things that are not a problem yet. The whole web world is abuzz trying to find solutions for the “retina problem”. We have a few very shiny, very cool devices that need high resolution images to look good. We also have an infrastructure that doesn’t support that much image data to be transferred in time. So we bash our heads together trying to solve that problem. Why? Why not ask the companies who break the web with their proprietary hardware and secret roadmaps to find a way to fix it in their hardware? Why should it be upon us as developers to reverse engineer and hack around issues that are man-made?

The very frustrating part about this is that we are solving a problem of a small minority of people. Granted, the richest ones and the ones that consume the most. But the web is more, and we should be thinking about tapping into the group of those that are not on the web right now, but have demands and needs that could be fulfilled by it.

Secondly a big problem that we have is reminiscent of the Portsmouth Sinfonia: we have a lot of developers doing design and designers doing development. Either because they are asked to, or because they are deluded enough that they think they can do everything or because our project plans are not catered for allowing specialists to do what they do best but instead to roll out the product as quickly as possible.

Almost weekly there is some rant by developers that CSS is too hard, not logical enough and needs replacement. Or designers answering “just use a jQuery plugin” for any problem that comes up in web development rather than finding a much simpler, more scalable and easier to understand JavaScript solution.

Maybe instead of trying to replace something we don’t get along with we find a person who loves doing it and partner with them? If I hire a plasterer to fix my ceiling I don’t expect him also to check out the plumbing of my house or build me a nice cupboard. Instead of ranting and calling a technology inapplicable we should leave it to other experts to do that part of the job for us and deliver the product with us.

All in all, this is just laziness or unwillingness to learn something new. We keep to our small worlds and see everything as a nail as we have one hammer at our disposal – not realising that in many cases the nail turns out to be a thumb once we have a go at it. A developer giving other developers design advice on Stackoverflow telling them to “use a layout table, as CSS isn’t ready for this” or a designer telling other designers to “just use this library” without understanding what it does under the hood is stagnation and fleeing into quick solution land where everything can be healed by applying a band-aid.

One big thing is people claiming that they have no talent for programming or others for interface design. One person that told this the right way is Bob Ross:

Talent is a pursued interest. In other words, anything that you are willing to practice, you can do.

Practice makes perfect, and you can only get better by learning from people who know the thing you want to learn. That is why the most important thing we need to do as creators of the web now is to collaborate and learn from another.
We are experts and experts use expert tools and talk to other experts. They do not just go and buy the first thing that promises a fast solution. That’s what frauds do. If we don’t want to be frauds, we should stop doing a few things:

  • Looking for technical solutions on Google. This is what underpaid helpdesk people do. “Any answer will do”
  • “Use this, it will solve all your problems” is nonsense used in advertising
  • Finding out the “how” doesn’t give you anything if it doesn’t answer the “why” at the same time.

All of these lead not to solutions and products, they lead to stop-gap solutions. And as we are normally not on the same project for a long time following these principles means we fill up the web with quick hacks and stop-gap solutions.

Instead we should tap into the community when we have a problem:

  • Write a demo of your problem and post it on JSFiddle, JSBin, Dabblet, Codepen or whatever has collaborative coding.
  • Go on Twitter/Google+/Facebook and ask people
  • Let’s use #cssissue or #jsissue as hashtags? That’s what the cool kids use!
  • Get fixes and share your learnings with the community

In other words: we should talk more. The web became what it was by collaboration, sharing and open discussion of problems and solutions. If we make these work around code and tangible examples we can avoid a lot of nonsensical, dogmatic discussions and “meh, just use $x” answers.

We forgot how to share knowledge, as we are stuck in a rat-race about innovating to “keep up with native”.

The question is though, what is the future of the web? I don’t know, but I feel very deeply that it will not be about a certain hardware. I also know deep down that it will not be about one browser. I also know that there is no such thing as an SDK or an IDE for the web (something native developers keep asking for when they start building web apps). And I know for sure that it is not achievable when mainstream media and governments keep trying to tell us that the web needs to be controlled to avoid people getting content they shouldn’t get. That last ship has sailed recently with – ironically – the release of a certain powerpoint presentation.

Is it trying to give users the same experience native solutions do? I don’t think so – at all. I find apps to be a step back and a step into a direction of controlled consumption rather than distributed discovery and consumption. And it hurts me to talk to new developers asking me where they can get a certain hardware before they can build their first web app. No, you do not need the hardware to build an app – you need the knowledge and the tools and both are available in the form of standards and freely available information and editors. The latter will sooner or later simply be part of the browser.

It hurts me to see that developers start thinking they need to “pay to play”. This is a horrible step backwards to me. The web is there for anyone to become a publisher. Closed environments work very much against that idea.

It is not surprising that sooner or later people would try to reign the web in and make it easier to sell and digest. This is how selling always worked and it is actually based on a principle defined in 1955 by Victor Lebow in an article in the Journal of Retailing:

Our enormously productive economy … demands that we make consumption our way of life, that we convert the buying and use of goods into rituals. That we seek our spiritual satisfaction, our ego satisfaction, in consumption … we need things consumed, burned up, replaced and discarded at an ever-accelerating rate.

In other words, things need to break. The phone has to die, so people buy a new one. That doesn’t work with intangible things like software and with things that are distributed and copied as soon as they become available. Which is why it needs even more to make people consume more. Clifford Brooks-Stevens defined the priniciple to make that happen in 1954 already, that of planned obsolescence:

Planned style obsolescence occurs when marketers change the styling of products so customers will purchase products more frequently. The style changes are designed to make owners of the old model feel out of date.

Do end users really need Retina displays? Or is it a wish, is it a need caused by damn good advertising and giving them a feeling of “not belonging to the hip people” when they don’t have it? As early as 1960 the concept of planned obsolescence was critiqued. My favourite quote is by Vance Packard in “The Waste Makers“:

“The systematic attempt of business to make us wasteful, debt-ridden, permanently discontented individuals”.

I am afraid that this dark prediction is coming true. Yes, Moore’s Law is in full effect and things get faster, smaller and cheaper all the time but not everybody who buys an iPhone just to go online can really afford it. And whatever new and cool we buy, we are annoyed with a few weeks later and consider it outdated.

How can we break this cycle? How can we bring the original ideas of the web to the mobile space, rather than the self-destructive cycle of perishable and – by design – soon obsolete products?

I am very happy to be part of one of the anti-movements of this: Firefox OS. FirefoxOS is a completely open operating system, built on web standards and available for download. It is not there to kill iOS or Android. It is there to bring web connectivity to the people who do not have it yet and who could never afford to be part of the race for new, faster, higher-resolutioned and shinier every half year. It has a few unique features:

  • It is targeted at new, emerging markets – true, the first country FirefoxOS phones are available right now is Spain, but that was a decision by our partner Telefonica. In the long run Firefox OS is going where the other players don’t bother to go – yet. If they go later on and offer affordable hardware, we as Mozilla have reached the goal we set ourselves: opening the mobile space
  • It runs on very affordable hardware
  • There is no credit card needed – apps can be bought on the phone bill or via prepaid cards (this is a big obstacle for people)
  • It is web technologies through and through – the OS and Apps are HTML5
  • You have full hardware access via open APIs
  • We have 21 mobile partners and 6 hardware partners

Apps for the OS can come from the marketplace – much like any other mobile platform – but you can also easily make them installable from the web with a simple JS API call. A web page can become an app just by defining a manifest file.

The really disruptive idea, however, is that Firefox OS turns the “find app, install app, use app” on its head. Instead of having to find an app by name in a marketplace, the search functionality of the OS allows you to find applications by entering a search term, like a band name, a movie name or anything else. After the system found an applicable app in the marketplace or on the web it shows you its icon. Clicking the icon sends the search term to the app and you immediately get what you came for. No need to enter the data again or go through an install process. If you like the app, you can long-tap it and install it. Your HTML5 mobile-optimised web sites become the ad for your app. You can see it all in the following video:

All in all, Firefox OS promises web developers a few things:

  • A whole new audience
  • HTML5 without the lock-out
  • Your web site is your ad!
  • Minimal extra work, it works across platforms

You don’t need to build apps for Firefox OS – you build them for the web and Firefox OS gives you the most APIs to play with and full access to the hardware.

All in all, we need makers of the web to unite and to ensure that what we know goes to the next generation. If we do not fight this fight right now, the web as we know it will play a second role to closed systems. Those will fade away – as they always do – but, to me, it seems like a big waste to spend lots of money and effort when we already have something that works. You can innovate faster and better in a closed space – no doubt about that – but being flexible makes you succeed in the longer run and reach people you don’t even know yet and who are hungry to get something new.

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)

Broken promises of HTML5 and what’s next? – a presentation at HTML5DevConf

Yesterday Mozilla attended the HTML5 Developer Conference in San Francisco, California to give a keynote presentation. The very packed schedule of the conference already covered a lot of topics around the subject matter, which is why we considered it worth while to contribute with a talk that told tales from the trenches of advocating HTML5 instead of going into technical details. Under the title of “Broken Promises of HTML5 and what’s next?” we reported some of the findings we had when talking to press and people outside the web enthusiast sphere.

Keynote audience

The Slides of the talk are available online and there is a screencast of the live presentation on YouTube.

The organisers of HTML5DevConf promised to release the video recording in the next few weeks.

Here are a few of the points covered to make it more interesting for you to check the 50 minute talk, in case you need more incentive:

Following the press around HTML5 lately we get more and more the impression that we are on the downward slope of the hype cycle about the cool new tech HTML5. The honeymoon period where every shiny HTML5 demo was heralded as the coolest thing and the future of the internet is over and business analysts and developers start feeling disappointed by what HTML5 is portrayed as. A lot of the things that get us as developers excited have been done in Flash years ago and performed better – even on the hardware of the day. The main mistake we seem to make when advocating HTML5 is not think about what makes it unique and how it is different than other approaches to bring higher fidelity to the web.

This talk covers a few ideas we can follow to turn the disappointment around. We will soon deliver a more in-depth article about this and are in talks with business analysts to make that message clearer. Some of the points mentioned here are allowing for re-use of existing knowledge with tools to get Flash developers to create HTML5 content, convert C++ to HTML5 for games using Emscripten (with Bananabread as the flagship demo) and in general not to think about what we can add but instead concentrate on what we can not remove to make our products web products and apps instead of simulating native and mobile apps.

It is up to us to move HTML5 from a flash in the pan to a productive platform, and we can do that by re-using existing knowledge and merge it with the web ideals and the basic principles of HTML5. We will not succeed by trying to replace other platforms that have a lot of knowledge and perform very well indeed.

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)