I just got asked to provide a few answers for a survey amongst “mobile web experts” and thought it’d be good to re-use those here. So here goes:

What is the difference between a web site and a web application?

There are a few differences. On a very basic level applications are catered for doing things whereas web sites are more catered for offering content for consumption. Web sites started as structured, interlinked academical documents. Later on we added multimedia content to make them much more engaging but all in all they are fixed in their state.
Applications are more dynamic. They allow for customisation of the interface and store the state of what happens so that when you get back to it you can go on from where you left off.

The use case of an app should always be to do something with it. This could be as simple as voting on a how much you like a kitten photo and go as far as editing video content live in your browser or on your device. Basic examples would be a webmail client as an application and a pure image gallery to click through as a web site.

Web sites are static whereas web applications have atomic updates and in of themselves have a very small footprint as most of the content gets loaded subsequently and changes every time you use it.

All in all it is a sliding scale though as for example an image gallery can easily become an application if it allows you to upload your own images or edit and remix the existing ones in your browser. That is one of the main benefits of web technology – it is very flexible and allows for quick and simple changes to the final product without being hindered by a complex compilation, packaging and deployment process.

What kind of features should a web site have to be qualified as a web application?

Again, there are many things to consider. One main thing is that an app does one thing and one thing well. It is there to help you do something.

Technically it should behave like the fat client apps of old: it should retain my state and settings, allow me to customise the interface to my needs and it needs to work offline. The latter is not a technical necessity in terms of definition but to me crucial usability. Seeing how flaky our connections are – I am writing this on a plane – our apps should make people as effective as possible and this means we shouldn’t be dependent on a connection. The interface should be usable whilst we are off the grid and sync as soon as we go online.

Customisation and personalisation of the interface and interactivity to me make an application. This could just mean a game where I can change my character and get extras the more I play. A proper “web” application to me also should use the web whenever it can. For example I am very frustrated with playing a game on my phone and when I go to my tablet playing the same game my score and achievements aren’t synced although the device knows who I am. Why be online then?

A lot of badly designed web apps are just wrappers for content like a news feed. For example turning a blog into an app is a pointless exercise. It just adds the overhead of having to install the wrapper, update and uninstall it when I am fed up with the blog but doesn’t give me the “do something” part that defines an app.

If I don’t interact with it other than reading there is no point in making it an app. You lose a lot of the flexibility of the web when packaging HTML as native apps with the most important thing being opaque updates. An app that is hosted on the web can be patched and upgraded without the end user having to download megabytes of data. That is incredibly useful on slow or flaky connections. Instead of the whole app you only download the changes.

What is the difference between a mobile-friendly site and a mobile web app?

A mobile-friendly site is a web site that detects the capabilities of the device it is displayed on and doesn’t make assumptions about how big my screen is and that I have a mouse and keyboard or not. It runs in the browser of the device and is thus hindered by its limitations – which in the case of older Android devices are quite limited indeed. It caters to the mobile space in terms of display changes – single column display, larger fonts, larger buttons.

A mobile web app is an application built with web technologies running in an own, full-screen wrapper and not inside a browser. It takes advantage of all the things the current environment allows for. For example it stores content and itself locally instead of having to be online and requesting everything new every time you open it. It can access the special features of certain environments like swipe gestures, accelerometer for interaction or accessing the camera to get content in. Its purpose is for me to do things with it and not just visit it like I visit a web site.

What would you consider is the key feature that made HTML5 (as opposed to Flash and Java) the number 1 choice for developing mobile web apps?

Flexibility is the super power of HTML5. It is easy to make an HTML5 app adapt to a new environment and to make an interface that shows and hides content and functionality dependent on the capability of the device or environment. Both Java and Flash are not “web native”, meaning you need to initiate and execute an own code environment inside a browser before you see the results. This hinders interactivity of the containing document and the content of the Flash movie or Java Applet. Whilst both Java and Flash have incredibly good development tools and capabilities once they are available they are very demanding to the hardware they run on. That’s why iOS devices don’t have Flash. There is already a fully capable environment available – the browser – and executing another one inside it means using a lot of resources. On mobile devices this means shorter battery life and the device heating up quickly.

With HTML5 we have the opportunity to improve what mobile, web enabled devices already have to have – a browsing environment. These are available open source and for free (Firefox, Chromium and others) and developers can build apps without needing to sign up for one company and get their SDK to get started.

All environments have their uses and there are things that are better done in Flash than in HTML5. Betting on open technologies and browsers means though that you are very likely to be flexible enough to cater to the next environment around the corner. The web has always evolved and mutated around the needs of the market. That’s why multimedia in HTML5 is just another element of the document and not a black hole that can not interact with the rest of the browser or the document.

Where would you say the mobile web is heading? Do you see a future for the mobile web?

There is no mobile web. There is the web. Right now we start consuming it more and more on mobile devices. That is cool. And the web is totally ready for that as it is flexible enough to adapt.

If you use web standard technologies to build applications that expect a certain device, a fixed size of a screen, a special way of user interaction or expect a fast connection you are building a very limited and very quickly outdated piece of software.

Over the last years we should have learned that hardware is a commodity and susceptible to very sudden change. An amazing piece of hardware that is the hot new thing now can tomorrow be embarrassingly outdated.

When you build your web apps to only cater for that you try to be native code and that is a race you can not win. A lot of native apps are built to promote a new piece of hardware and to get people to upgrade. That is a very old technique of selling more products called in-built obsolescence.

Web apps should be beyond this. Our job is to give end users the best possible experience on the current devices but not make them a necessity. We did this mistake in the past which is why you see web applications that tell you that you need a “modern browser like Internet Explorer 6” and “at least 800×600 resolution”.

Native apps on high-end devices are doing really well right now, but I can foresee that people will get bored of having to buy a new phone every year just to get new functionality that is not that important when you consider the cost. The web will stay and always be the open alternative for those who want to consume and create on their own terms instead of being dependent on the success or goals of a certain company.

A few days ago a vertical video went viral of the student Jeff Bliss telling his teacher off for being a bad teacher who just hands out materials without explaining anything.

And we all applauded him for his gall and his eagerness to learn and to point out the obvious flaws in the education system. Teachers are not paid enough, are under more stress to be seen as someone who has students with good grades rather than understanding and have to deliver course materials they don’t believe in but are forced to go through as those are the ones that are easy to mark.

Terrible, isn’t it? So why do people in our little world of web development constantly and voluntarily become this bad, bored and ineffective teacher?

What am I talking about? The thing I mentioned in large detail in my talk at BaconConf this year but here it is for the generation who wants things in 140 chars or as a cute image with large letters on it:

Whenever you answer a question of another developer with “just use $x” you breed an expert idiot. You did not teach them anything, you showed a way out of learning.

In my ongoing task to de-clutter my life I just un-subscribed from several communities on Google+, namely the HTML5 community and the JavaScript one. Not because I am not interested in these matters any more, quite the opposite: because I care much about these communities and all I found there is frustration and annoyance. Nearly every single question new developers have is answered in three ways:

• Use jQuery – here is a plugin
• Just Google for it
• You’ll need to use framework $x / JavaScript and/or HTML5 is not good enough for that

None of these answers are satisfactory if you really want to help someone who needs to solve a problem and learn how to repeat the solution in the future. The latter in most cases is a plain lie and shows that you are blaming a technology for your lack of interest in it.

What gets answered far too quickly is the “how” – how to achieve a massively complex result (which yet has to be proven to be really necessary) without thinking about it or understanding the solution that you apply. We assume that is enough and that we are doing something good – we let a new developer have a positive experience of having something achieved very quickly and that will obviously entice him or her to learn more and go explore in more detail later on.

That is not necessarily the case. We showed people a shortcut and how to focus on the outcome and hope the step where they understand what they are doing comes later. Sadly in a lot of cases this never comes but it fills people with fake confidence that gets shattered once they have their first job interview in a real company who cares about what they build.

If you want to teach people, make them understand the “why” and let them find their own “how”. That is much harder work, but also much more rewarding when you see them grow and explore.

We do not teach people how to write by copying and pasting the style of other authors. We tell them about similes, metaphors, rhetoric devices, orthography and grammar rules. Why bother with that? We could just show them TXTSPK and explain that anyone who knows English will understand what they try to convey. The reason why we do it is that we teach the fun of playing with language and finding your own style.

“But I don’t have time for that – I just want to help someone solving their problem”

Is a very common, admirable, but misguided idea. What you do is advertise the solution that made most sense to you as you already solved the problem. You steal the learning experience away from the other person and the way we learn is our most personal asset and differs vastly from person to person.

If you don’t want to really teach and see people grow and learn on their own terms, please stop spouting truisms and “best quick solutions” in places where people come to learn. If all they want is for you to solve their issue, they should hire you to do so for them.

Don’t be the grumpy teacher you learned to first despise and later on pity. We can do better on the web.

As developers we are incredibly lucky. We work in a very growing and immensely well paid market, our companies shower us with benefits, companies offer us jobs rather than having to send out hundreds of CVs on the off-chance and even the mass media and politicians start talking about “coding” being a skill everybody needs.

Quite some part of this success is based on the stubbornness we showed in the past. When we got a task to build something we didn’t give up on it and said it is impossible. Instead we went back in our corner and tried and failed and tried again with sparks flying and code explosions happening until we achieved what we wanted. Think Dr. Bunsen Honedew’s laboratory instead of Statler and Waldorf.

This gave especially the web a strange “hack it together” reputation that many people keep bringing up when it comes to replacing JavaScript for example with “more organised and professional” languages. But you know what? I really think when it comes to the web, this is its main strength.

The fun of coding

As explained earlier in my Flash is not the enemy post, whimsy and spontaneous ideas is what made the web a larger media outlet than it was. It wasn’t the large sites that got non-technical people excited. It was the funny animation and short-lived game that you could mail to your friends.

Therefore I think it is important to celebrate this for yourself from time to time. Personally I find myself extremely lucky to have been at the right time (and moving around to the right places) when the web exploded into an offering of amazingly cool things and while I am sure as hell not proud of the code I had to write to get things done in the past, I am happy that I did and that I didn’t give up or wait until someone else solves my problems for me.

Having just taught a workshop on HTML5 at Industryconf I found that we are losing a bit on that. Attendees were worried that they need to learn a lot of libraries and find the right plugins to get started and once shown that they have the power to do most of what they want using the things browsers come with out of the box got quickly into enjoying themselves reaching new levels.

One thing I did with the attendees is a To-Do List App in plain HTML/JS/CSS (No sound).

This is what the Mozilla Webmaker Project is about – to get non-programmers excited about building things for the web. And it is incredibly exciting to see some of these events as a “professional”.

I think it is very important to never forget about the wonder we experienced the first time we made something show up on screen or wrote our first condition that printed out “is amazing” when you entered your name or “is boring” when it was another one.

Be fearless

A lot of times being creative means being fearless. Watching Bret Victor’s talks and seeing his Learnable programming course and Seb Lee-Delisle’s training courses they consist of one main thing – play with things and worry about them breaking later. Amazing results happen when the outcome and the input get as close together as possible – not when things happen using dozens of abstractions.

This does not have to be visual from the get-go though. The MPEG-1 decoder in pure JavaScript for example is pure byte-shifting but blew me away in its fearlessness of what could go wrong.

Go, code!

Why not have a go? Take 10 minutes, half and hour, an hour out of your life right now and use it to #justcode something, anything. Just play with an idea, put it on JSFiddle, Codepen, JSBin, Dabblet, or whatever other amazing tool we have right now and share it.

Don’t build a perfect plugin, don’t build a solution dependent on preprocessors and libraries. Go vanilla and just play with what we have in browsers today. CSS Animations and Transitions, Canvas, Audio and Video, HTML5 and Friends – we have so many cool toys to play with. Don’t explore the main use case either. Yes, Canvas is for putting things on the screen, but it is also about reading image data.

We got where we are by playing with things. Never forget this and never stop playing.

Back in November my colleague Robert Nyman wrote about a word that annoys him. I like that. I think our day to day online conversations are full of little misunderstandings and knowing what ticks someone off or brings up weird connotations is a good thing. So I thought I should quickly write this bit here.

There is a pretty bullet-proof way to make me feel uncomfortable and not react to requests that you have and that is by calling me “Bro”. There are two people on this planet that can call me “Bro” and that is my sister and my brother and both call me “Christian”.

I don’t like “Bro”. I understand that for some this is a very normal way to talk to each other but I don’t get it.

First of all, it assumes a relationship that we just don’t have. I have quite a lot of friends and I have some very good friends (you know the ones that helped you when you were sick or show up without any questions when there are things to be done like moving flat). Friendship is something that grows, that gets earned. A bond that would warrant calling someone else a brother (or sister for that matter) that is not related to some religious lingo is something that so does not happen by using the same social media channel or commenting on the same pull request thread. Someone calling me “Bro” out of the blue makes me twitch and reminds me of the fake friendliness the bazaar salesperson shows when asking you to “want to look at my carpets, friend?”.

Secondly when I hear “Bro”, I have in my head the caricature of a beercan-on-forehead-crushing frat boy jock who is boisterously shouting about how awesome all his bros are and that they come “before hos”. I never went through university and the mere concept of fraternities and sororities is beyond me. It seems so fake and artificial and with its initiation and hazing rituals flat out creepy. Where I grew up we used to have (and still have) student organisations that have sword-fighting as the initiation rites and you might have seen old German men of power with scars in their faces. That is where that came from. All of these smack of nationalism and old-school class systems, all of which things I don’t get and that make me feel uncomfortable.

So in short, every time someone calls me “Bro”, I lose a bit of respect – subconsciously. Maybe that is something I should work on. But seriously, I think the whole “Bro” culture is outdated and seeing the effects of it in mainstream media scandals and “Brogrammer culture” is something we shouldn’t support but actually move away from. So, sorry, but #nobro from me.

I am spending this week explaining lots of press folk what the Geeksphone is about. I just got excited like a puppy on sugar rush about unpacking mine, after waiting for a long time to get it internally at Mozilla. See the unpacking photo set on Flickr

Posting this on Twitter and Facebook caused quite a stir and many people who bought a Geeksphone wondered about their delivery times. Here’s what I know about this: nothing. I also don’t have access to phones to give out or expedite delivery for you – nobody outside of Geeksphone or inside Mozilla can, so please don’t ask for any of this as it is impossible for us to help you.

I think it is very important to repeat what the Geeksphone Firefox OS preview device project means and stands for. So here it is, in a very clear fashion: the Geeksphone Firefox OS developer preview devices are developer tools for Firefox OS. They are not:

• Firefox OS phones for day to day use
• Swag to give out for free as prizes on conferences (so don’t ask)
• A collector’s item to buy and put on a shelf

Firefox OS is meant to fill a gap in the mobile space and bring HTML5 capable devices in a very affordable fashion to markets that can not get handsets with great web capabilities. In other words, it replaces feature phones, not your high end Android or iPhone.

That’s why we found ourselves in a pickle: how do developers test on a platform that is not sold in their locale as it would be pointless to add to a saturated market with a lower-spec phone? The answer is developer tools like the Firefox OS simulator and affordable testing devices where you can really see how responsive the hardware with the OS is. And these are the Geeksphone Firefox OS preview devices.

Having a Geeksphone Firefox OS preview device means you should be working on an app, that is what we need developers to do. We need the marketplace to have a lot of good apps on launch of the phones to the end users. All you need to do is to build an HTML5 app (that also can be converted to native code with PhoneGap) – you can develop that one to 80% in the browser. To get all the Firefox specific goodies, you’d need a phone like the current one Geeksphone provides.

So while it is very exciting to see people go nuts over the phones, I think it is very important to remember that these are tools to build and test apps and not phones to have instead of the phone that our partners will release in the target markets. These will be very different but share the same hardware specs.
Consider the Geeksphone Firefox OS preview device a Nightly build of a browser. You are helping the browser to test out future features for normal end users but you shouldn’t be surprised about quirks and errors. On the contrary – we want you to find them and tell us what is broken, that’s why there are preview and beta versions of browsers.

I am terribly excited about being able to give real hardware to people who work on exciting apps that will make a massive difference for people who now only can play snake and send SMS on their phones. You could be part of the new wave of mobile internet entertainmment and access in countries that hunger for a better experience. That’s what you’d need a Geeksphone Firefox OS preview device for. If all you want to do is to play with a phone, drop by in any Mozilla location or any of our events.

Right now Firefox OS needs you to build stuff for the web, and if you do that already, the device can give you the final testing platform you need. You won’t need one for most smaller apps though, so don’t feel left out as there are not that many available and it may take some time for yours to arrive.

That doesn’t mean that in the future there might not be devices sold by Geeksphone that are targetted at end-users. It simply means that the Geeksphone Firefox OS preview device is what it is – a preview device for developers.