And exactly that is why every attempt at taming the wild wilderness hiding in the blank canvas is met with ample shoulder-carrying by ululating tribes of eager developers.

This type of programming environment, where doing fairly basic stuff requires you to write a fair amount of repetitive code and where every line of code requires you to desperately draw pictures and scribble calculations in an attempt to try and visualize what exactly is going to be drawn on the canvas – this is the ideal breeding ground for frameworks and utility libraries.

And that’s where Paper.js steps in. Quite successfully, I might add.

Paper.js is not just a utility library. It is actually an entire document object model for vector graphics.

What does this mean?

Similar to the way html has defined document objects, which define common behaviours for text, Paper.js has defined sets of objects that simplify working with vector graphics, especially if you’re used to working in a typical vector graphics editor like Adobe Illustrator.

Animation is built on top of this in a very simple way by providing a hook into the frame renderer in the form of a user-definable function that executes every time a frame is rendered.

In normal language this means that every time Paper.js draws a frame in the canvas, it gives the programmer the ability to tell it what to draw.
The actual drawing of the frame is not triggered or controlled by the programmer; Paper.js just keeps drawing frames as fast as possible, executing the right functions at the right time.

User interaction is done in the same way. The programmer has the ability to define pieces of code that get executed when the mouse is clicked, the mouse is moved, a key is pressed on the keyboard, etc.

At this point, I could go into more detail about using Paper.js and it will all become very technical. But that’s not really necessary, because the Paper.js tutorials are simply brilliant and very concise.

If you’re at all so inclined, dive in and start playing – that’s where I’m going to be for the next week!

It certainly looks like Apple has cooked the goose that lays the golden eggs for dinner.

So, what is this alternative platform, exactly?

I mean, you don’t want users to have to jailbreak their iDevices to be able to install the next big serendipity app, right?

Let’s take one step back.

In the blue corner, we have native frameworks and languages. These are vastly different from platform to platform – in other words, once you’ve finished coding an iPhone application, you still have to code a version for Android from scratch, as well as a version for Blackberry, a version for Windows Mobile, and every single update you release, has to be ported to all these platforms.

In the red corner, we have good old HTML5, CSS3 and Javascript. It works the same in all browsers on all devices, with minimal styling adjustments between different platforms. In other words, a mobile web app is easier to build than a traditional desktop website.

This is mainly due to the fact that, on mobile, there is no equivalent to Internet Explorer version 6, 7 and 8. Hallelujah!.

The main trade-off here is native app styling, which is quite design-heavy, and has had a lot of thought and development put into it.

And here jQuery Mobile provides us with a true Silver Bullet.

The jQuery legacy

jQuery, self-branded as the write less, do more javascript library, has all but re-invented Javascript in the past six years. Based on, and improving on a discontinued library called Behaviour, jQuery treats Javascript development as a bag of functions tied to HTML elements. This results in a much more organic development paradigm for the web.

This all sounds pretty technical, but all you need to know is, once you’re used to jQuery, it makes previously complicated things very simple. In a very big way.

jQuery goes mobile

In August 2010, jQuery announced an alpha version of their new library, jQuery Mobile.

Everything jQuery does for the desktop also applies to mobile, so what does jQuery mobile add to the mix?

Styling and behaviour. With some Javascript and CSS magic, jQuery Mobile turns this:

into this:

without any work on the developer’s part.

Pretty nifty eh?

In the Interim …

While the app store is still alive and well, HTML5, CSS3 and jQuery Mobile can be used in conjunction with platforms like Phonegap or Appcelerator Titanium to actually compile HTML5/jQuery apps down to native apps on most of the main mobile platforms.

Hopefully, before too long, one of these will happen:

• Someone will start an alternative, hugely adopted HTML5 app store (quite likely)
• Apple will come to their senses and try and save the app store by including HTML5 apps (less likely)
• The entire app store paradigm will die, and people will install apps from a variety of third party providers (not very likely at all)

So … while we keep on building HTML5 apps and mincing them into apps through Phonegap, won’t someone please go ahead and start up an HTML5 app store, please? (and make it hugely popular, of course … )

The server side of AJAX is still in most cases handled by PHP, causing most web developers to, apart from markup languages HTML and CSS, having to code in both Javascript and PHP. (PHP could be replaced here by Python, Perl, or any other server-side language).

Well, those days might be over, thanks to a nifty little (and I mean litte, as in extremely lightweight) engine called node.js, which not only runs javascript on the server, but actually uses javascript as the server.

A Javascript webserver? What are they smoking?

My initial rection to this is a bit similar to seeing someone building a palace out of ice, or a steam locomotive out of sand. Amazement at the amount of effort and creativity that’s being put into the idea, but very little for its actual usefulness.

Wake up and smell the future.

If this google trends graph is anything to go by, I’ll have to rethink my attitude a bit:

Let’s have a look at the Javascript engine under node’s hood: an engine written by Google, called V8.

Why did Google write their own Javascript engine?

When Javascript was first integrated into the Netscape Navigator browser in the mid 1990′s, it’s main goal was to provide access to an HTML document’s elements (called the DOM tree), after the document has been rendered by the browser. Its use was mainly to make small alterations in content based on user interaction, like changing the colour of a button when the mouse hovered over it, or popping up small browser windows (annoyingly so).

Performance was not a big issue.

Later, people started using Javascript to, after the document has been rendered in the browser, pull more content from the server to update into the browser, thus making web pages active. A good example of this is GMail, which, without having to reload the page in your browser, adds new mail messages in your inbox. This technique is called AJAX.

Javascript is an integral part of the AJAX revolution, which was largely driven by Google. They quickly realized the severe shortcomings of most Javascript engines, and wrote their own: the V8 engine, highly optimized for speed and memory consumption.

Given the way the V8 engine was written, and the asynchronous nature of Javascript (which basically means Javascript multitasks by default), It suddenly becomes clear that Javascript, given the right implementation, could be better suited to the server side of AJAX than PHP, Python or Perl. That means, in the GMail example, that both the part that reads the new mail on the server, and the part that shows you your new mail in your inbox, could written in Javascript.

Seeing the light

Node.js extends the V8 engine with a set of libraries that makes building a simple web server as simple as this:


var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello Worldn');
}).listen(8124, "127.0.0.1");


You don’t have to understand Javascript to see that that is really simple. Given that Node is installed on your server, you simply have to run a .js file with the above content with Node, to have a working (though basic) webserver.

On top of that, as highlighted in this article on Mashable, node’s footprint on the web server is extremely small, up to 1000 times smaller per connection, compared to Apache (the most commonly used web server on the Internet). This means, as your site accumulates concurrent users, your server could take 1000 times longer to run out of memory.

Apart from this, users are more likely to experience a smooth, fast user journey, because of the fact that so much less server oomph is needed to process and deliver the same data.

Node is not the be-all and end-all of server solutions – it has a very specific use, which happens to fit a common trend today: providing a lightweight server infrastructure to serve up large amounts of small chunks of data to large numbers of users.

This makes node a perfect match for the realtime web, for gaming apps, for collaboration: basically all applications where speed and concurrency of data transfer matters.

Where does this leave PHP, Python, and their counterparts?

PHP will remain to be the best Hypertext Preprocessor there is, until further notice (which is what it was built for – generating and manipulating HTML). Python will remain the language of choice for building very complex server applications quickly. Perl will remain … well, Perl.

I do think, however, that PHP, Python or Perl’s role as server-side language in AJAX communications could diminish into obscurity. Let’s wait and see.

Meanwhile, if you like to dive into Node, check these out:

• Node Installation Instructions
• How to get Node running on an Amazon EC2 instance
• Find a Node.js job

This is what happened in their shop window. As it turns out, a lot more was happening in the engine room.

Foursquare BC

Before launching their new venues API (beta), finding something useful to do with Foursquare’s data was notoriously difficult.

Let’s take, for example, the problem of finding only venues with lots of checkins, in real time. This proved to be a major problem for us while building WOOS.at (mobile only)

These are the limitations:

• Foursquare’s normal API calls are rate limited to 500 calls an hour.
• Because of the low barrier to creating venues, the checkin-to-venue ratio is ridiculously low.
• A maximum of 50 venues can be queried from Foursquare per venue search on the API.
• There is no control over which venues are returned. If a venue is not in the 50 returned by a venue search, there’s no definite way of getting it.
• The search radius for venue searches on the API is 40km.

Given these limitations, it is possible to process 50 venues, 500 times an hour. This sounds like a lot, but 25000 venues an hour is not that much when you’re trying to discover trending venues in real time. Especially if you’re firing shots in the dark, and hoping for the best (hitting the same empty venues over and over).

In steps the new venues API.

Foursquare AD

At face level, it doesn’t look like much, until you give it a second look, and read the fine print:

• The new API is meant for userless access. This means it is built for bot usage, as opposed to front end usage. Ideal for determining venue trends in real time.
• The new API is rate limited at … 5000 calls an hour!
• There is a new API call, venues/trending, which automatically returns only the trending venues within a configurable radius (up to 2km)

Suddenly, even 500 calls an hour would’ve been enough.

Foursquare Beyond

Foursquare has a very vast location database. They have achieved this by making it extremely easy to create venues, and by being the first to do so. That is a very valuable resource, if dealt with correctly.

Up to now, Foursquare’s venues database was kind of proprietary, in the sense that its usability did not allow it to easily get a life of its own outside of Foursquare itself. It was mainly used for checkins.

By making their venue database accessible and usable, Foursquare have increased the value of the database by an immense amount. Add to this their actual reason for launching the new venues API: Mapping Foursquares venue data to other venue databases, like Facebook, Twitter and Google places.

Suddenly the future looks a lot brighter for Foursquare (and its API consumers)!

Many users, especially power users, would rather have been seen at work browsing weird furniture porn than with a royal flush of colourful flashing pop-ups all over their desktop. Thus, they preferred to disable javascript in their browsers.

Well, no more, brother. Today is a new day.

Javascript is right now poised to become the status quo programming language of the future.

What!? How did this happen?

Consider the following stats, plotting by date how many users had Javascript switched off in their browsers. This comes from W3schools, a web development howto and reference site boasting mostly web developers as users (ie power users):

Genesis

And the web was created out of pure, static, marked up text, in the likeness of printed media. And it was called HTML.

Way back when the web started, all web content was static. In other words:

1. The browser asks the server for a page.
2. The server generates the page.
3. The server sends the page to the browser.
4. The browser displays the page.

This process is repeated every time the user clicks on a link or browses to a new page, even if some of the page content stays the same. The browser compensates for that by storing certain resources locally, like pictures, scripts and even pages.

It was this scenario that gave Javascript its bad name. The only place for Javascript in this setup was to attempt to create eye candy, or to show the user stuff they did not want to see, like pop-up ads.

Then, between 2002 and 2005, this scenario changed dramatically …

Exodus

And the web longed to be freed from the bounds of the browser. It longed to reach out to the Source, the Server. It was the dawn of the age of Ajax.

By using Javascript as a network client running in the browser and using PHP as a network server, the web became dynamic. The typical browser/server interaction changed as follows:

1. The browser asks the server for a page.
2. The server generates the page, plus some Javascript client code.
3. The server sends the page to the browser.
4. The browser displays the page and runs the Javascript client code.
5. The Javascript client code connects to PHP server code, on user interaction, or periodically, to fetch new bits of content from the server as it becomes available
6. The new bits of content is inserted where appropriate, and the display is updated, without having to reload the parts of the page that didn’t change

This move changed the web paradigm quite a bit. The web page became more of an application. Links became buttons, firing off locally stored pieces of Javascript instead of requests for entire pages to the server. The browser became a more of a platform, for applications to run on.

This tendency is about to be taken to an entirely new level, though …

Revelations

And behold, the apocalypse of the web was upon us, and it was called HTML5. Content became function, reader became platform, and the New Web rose from the dark depths, driven by Javascript, with a crown on its head, called CSS3.

In a previous post I explained how HTML5 is changing the browser into a fully capable application platform, replacing the Operating System, capable of running any application thinkable. This is a change that Google fully acknowledges by investing a huge amount of development and marketing effort in ChromeOS.

So, if HTML5 turns the browser into the OS, what language does it speak?

Javascript.

Javascript is to the HTML5 capable browser what Machine Code is to computer hardware, with the added benefit that it is human readable. HTML5 provides the containers to do amazing stuff in, but Javascript will do that amazing stuff.

All of a sudden, Javascript is becoming the language of the future. Any contenders?

So – what’s all this then?

Unfortunately I cannot, and do not want to, make anything of the fact that Blogline is shutting down. A supermarket in my hometown once shut down when I was small, but somehow groceries just didn’t seem to go out of fashion. This debacle, along with the fact that RSS is built upon XML, did make me think about an entirely different issue though: the death of XML.

To be fair, I should rephrase it as The probable death of XML as communications protocol, possibly leading to the timely demise of XML altogether, sometime in the next 50 years. But that would’ve been just too long and awkward for a title.

I’ve been in love with XML ever since I started using it. Mostly because I’m an engineer, and XML is a complicated solution to a simple problem. XML is beautiful. XML is well formed, it’s extendable. You can use it to fill an entire page with a single tag, and thousands of nuances of attributes which might or might not be used in future. Many a late night we spent around the whiteboard, arguing over the exact schema to design for a specific problem – all of them being right, fo course, but each person believing in the superior beauty of their own schema.

I have wasted months, if not years, of my life on XML. It was months well spent.

Then came JSON.

JSON still makes me think of an array written a bit differently. There’s no design to it, and most arrays and objects can be converted to JSON by a three year old doodling on a piece of paper. The conversion algorithm is so simple, it can be implemented on dried leave.

This is why, shortly after AJAX became big in web development, even though the X in AJAX stands for XML, programmers started using JSON to replace XML as the communications protocol in AJAX.

The Twitter API supports both XML and JSON formats, with the JSON format being listed on top on all pages of their API documentation, a decision based on format popularity. The Facebook Graph API returns JSON only. The bit.ly API has the following sentence in their API documentation:

” … note that json is the default response format. but xml is also available … “

All of this makes me believe, as a communication protocol, XML is in the process of making way for a more agile successor. It will be missed.

And that’s the whole point.

In the retail and service sector, there’s a well-known, yet unexpected way in which new customers are turned into loyal customers. It works as follows:

• A customer has a complaint. They see someone at customer support.
• The person at customer support solves their problem as well as possible, but above all, treat them with the highest of respect and dignity. The customer support officer needs to be a senior employee with advanced people’s skills.
• The customer leaves, not only with their problem solved, but with an unbreakable mental association between your business and the person who treated them so well. This instantly turns them into a loyal customer. They feel that they have seen the guts of your business, and not just the carefully manicured face. And they liked it.

How does this apply to websites?

Error message copy

When something goes wrong, like your website’s database server crashing, your pages getting corrupted, or even just when the user forgets to fill out a required field in a form, they are put in a situation where they see something different than the carefully designed front end of your website.

They see some kind of error message. How do these error messages treat them?

• Error message should not contain detailed technical information (or some cryptic phrase) that the developer used to debug the site, none of which makes any sense to the user. This is intuitively wrong, but so often the case. This is what happens if no copy is written for error messages, and it’s left up to the developer.
• Error messages could be funny (do resist the temptation to crack an in-joke, though).
• If at all possible error messages should go as far as providing an alternative way of leading the user to that which they have looked for in the first place. This is ideal, and this is what every error message should strive to achieve.

Error Message Design

Error messages should stand out (maybe even jump out), especially in the case where the user is required to fix some input errors (like on html forms). It’s not necessary to make it too ugly or out of step with the rest of the design, but do make it the most obvious item on the page.