theThought's thoughts

@Media WebDirections Conference : Day 1 - Sessions 3 and 4

The morning of Day 1 finished with a second presentation on JavaScript, however this one focused on the use of JavaScript on the server.  Having not learnt from my experience in the morning I thought I would attend to learn more about this concept that I had heard of but never practiced.

Tom Hughes-Croucher

This presentation had a promising start.  He was bright, breezy, humorous and excitable always a good combination in my opinion. Alas the presentation, for me, went steadily downhill.  It became more and more complex,  Tom lost his witt as he became more embroiled in the technicalities and I became steadily more and more detached from the proceedings.  I am not saying it was a bad presentation because it was not it was just not a presentation for me (I had had a shower that morning and I had not yet achieved a level of geekiness that allowed my subconscious receptors to translate what was being said).

Here is the gist of the presentation:

The big advantage Server Side JavaScript (SSJS) has over Perl, Ruby etc is that people are already familiar with the syntax and are used to writing in it.  A quick straw poll of the attendees demonstrated this when everyone said they had written JavaScript routines but only a few had experience of PHP, Perl or Ruby (no one asked about .net).  Effectively JavaScript IS the language of the web.

In addition libraries are increasingly being made available that simplify complex tasks such as jQuery, Mootools and YUI.

But SSJS has been around for quite some time so why is now the right time to push it as a viable solution.

Professionalism.  JavaScript coders are no longer seen as 2^nd class citizens they are a respected part of the development community

Runtimes.  There are a number of these available, they have been placed inside browsers for a start.  They include V8, SpiderMonkey and Rhino.

Speed Placing these runtimes in browsers has resulted in a drive for fast execution. V8 (part of Chrome) is very fast.  This is because leading browser manufacturers, like Google, are trying to make speed of execution a unique selling point.

Runtimes are not Browsers, there is no Document Object Model (DOM), there is no accessibility to specialised APIs.  It is only the pure JavaScript implementation.

• Rhino is equivalent to JavaScript v1.7
• SpiderMonkey is equivalent to JavaScript 1.8
• V8 is equivalent to ECMAScript 3

Brendan Eich talked about Harmony which is currently in development this will be equivalent to ECMAScript 5.

This latter statement put into context much of the presentation given by Brendan in the fact that those new facilities being placed inside Harmony but not yet available in browsers (via their JavaScript runtimes) would be available on the server as part of a SSJS implementation based on Harmony.

Here is where Tom became quite animated.  The speed and capability improvements discussed by Brendan and shown in the new runtimes means that Server Side JavaScript has real potential to deliver power and performance without the issues encountered by client side JavaScript.  When combined with libraries such as Note.js it becomes a great way to deliver browser agnostic web pages with powerful capabilities.

Unfortunately Tom’s increased animation was demonstrated by an increasing willingness to go into code level detail most of which went over my head.  It was clear that you need a linux server (no Microsoft Servers here today) and that you need a deeply technical mind to handle all the potential.  I have neither of those at my disposal so it was an interesting presentation that will result in little to no difference in the way I work.

Jonathan Stark

Jonathan’s presentation was the complete opposite.  I saw elements in this presentation that made me bubble with excitement and tremble with unequivable potential.  Jonathan is a specialist in Mobile Application development he has previously focused on iPhone development but it increasingly moving cross platform.  He is currently writing a book on Android and is hoping to look at other platforms like BlackBerry in the near future.  He started his presentation with three clear statistics

• 4.6 Billion cellphones are identified as currently active today
• 15% of these are smartphones
• 56% of public wi-fi connections were made by smartphones

This, Jonathan says, means that the smartphone is here and it is a dominant methodology for viewing the Internet.  These smartphones are able to be extended through custom applications that fall into the following categories:

• Native – Written for the specific device using languages like Java and Objective C
• Web – Browser based applications
• Command Line – often SMS based connectivity

Each of these types has its own challenges.  Native development is very fragmented with no one technology/language capable of developing a solution for all devices.  Web apps may be more consistent across devices but they are run in sandboxes and can not use many of the rich capabilities of the device such as camera, accelerator, compass.  Lastly command line apps suffer from discoverability issues.  How do you let people know about your service.

Although the above is the standard statement made for mobile development it does not give the entire picture.

Web development is done through standard web technologies such as HTML, CSS, JavaScript.  Apps using this technology are the cheapest to build, the technologies used are the most standardized and the solutions are the easiest and most cost effective to distribute.  If Web Apps could use the advanced technologies on the device, if they could provide a smoother user experience more in line with Native Applications they would probably be the best way to write an application.

jQuery

An extension of the jQuery initiative has been constructed by David Laneda.  It is called jQuery Touch.  Its purpose is to provide a more app orientated experience for a web based application.  It can be added to any webpage and then used to introduce smartphone like interfaces that would usually take a long time to build and test.  This includes the types of menu systems, buttons and transitions you would expect to see on a smartphone like the iPhone.  Add to this the HTML 5 capability to cache web assets on the device so that they can be used offline and you have a web application that looks like a native one it just lacks a few features

PhoneGap

The developers at PhoneGap do not really want this technology to exist.  They have built it because of the fragmentation of native app development.  Their aim is to give developers a path to cross device development.  PhoneGap gives a developer the ability to convert a web app into a native app.  It works for:

• iPhone
• Android
• Symbian
• BlackBerry

During this conversion the developer is given access to device capabilities such as the phone and vibration through relatively easy mechanisms to implement.  PhoneGap is only available on a Mac platform as the submission procedure for Apple is unchanged.  It is written so that the developer ends up creating an Objective C solution that can then be submitted.  It contains templates for each device delivery mechanism so that conversion/compiling process has to be done separately for each device type but this is still greatly reduced compared to the alternative process.

At the end of the presentation the inevitable question was asked regarding section 3.3.1 of the Apple terms and conditions.  Jonathan stated that Apple have indicated that, at present, PhoneGap is not affected by this changes made to this section.  There is no guarantee, however, that it will remain that way.

The presentation was good, there were clear examples of how to do the work, Jonathan built them on the fly showing the simplicity of the basic process.  The results looked good and apart from the seemingly difficult installation process for PhoneGap, nothing seemed particularly arduous – especially compared to learning Objective C and Java.

The Missing Session

There was a fifth session to the day called Hot Topics.  I believe it was supposed to be an open forum.  As much as I would have liked to have attended this I was unable to.

@Media WebDirections Conference : Keynote - Day 1

Yesterday I attended day one of the @Media/WebDirections Conference at Queen Elizabeth Hall, South Bank, London.  This is my second conference in a number of weeks following the Future of Web Design (FOWD) conference in May.  I was intruiged to see how different this conference was especially as at least two speakers at FOWD were also speaking here (Remy Sharp and Aral Balkan).

The differences were quite significant.

Firstly this event was much smaller, although located in a large facility (the Queen Elizabeth probably sits about 2000 people) I think there was less that a quarter of that number.  It was the same type of gender mix, predominantly male with a smattering of females (although that smattering was even lighter here) and a similar role mix although by the looks of them there were more developers and less designers.

Secondly, as you will see from this post and the next one, the content was more technical.  I should have realised this after the workshops but just how much more technical was a big surprise.

Lastly, and unfortunately, it was a little less organised, especially around those luxuries that you come to expect at these conferences such as wi-fi connection and power sockets.  As a result I was unable to get any quality Internet access which meant that I was unable to tweet (My blackberry was on low power too and its too slow for typing tweets in a conference).

Despite this last point I enjoyed the day and learnt a lot - which in the end is what it is all about

The event started with a short introduction that explained the merging of @media conference and the webdirections conference and was followed by a keynote by Brendan Eich.

So I have to admit that I am not familiar with the big names in the scripting industry especially those that orbit the W3C.  At FOWD I saw the workshop and presentation of Molly and she gave off an air of almost angelic reverence to these people (including herself by inference).  The same reverence seemed to be in the air for Brendan.  For those other people who read my blog who are equally unfamiliar Brendan is one of the co-founders of JavaScript.  He worked for Netscape and now works for Mozilla.  He is deeply technical, I think a portion of his oxygen intake (lets say 40%) has been replaced by code.  He promised something fast and furious and that is what we got.

His talk was effectively about the future development of JavaScript.  I think that people like me think JavaScript just is and don’t think too much about its evolution.  But evolving it is.  There are a raft of new developments on the table for the next round of standardisation approvals some of which are being adopted by browsers right now and are likely to be ratified by 2013 through a project called Harmony.  This includes:

• Const
  The ability to define constants in addition to variables that can be scoped within functions or globally
• Destructuring
  The ability to see arrays in any order to swap the elements and rotate them to see [a,b] = [b,a]
• Functions in Blocks
  The ability to create inline functions with the same name within a block of code without conflict
• Let
  A better type of var that handles scope better and is less likely to leak to higher level functions
• Default Values
  Where parameters in functions can have defaults that are adopted if no value is applied to that parameter when the function is called.
• Arguments as Parameters
  Where a parameter of a function does not have to be a single value but could be an array of values

As you can see from the above items and descriptions.  This is a technical subject and Brendan was quite obviously in his element.  He talked rapidly (as he promised) and slides flashed before our very eyes.  His content was assured and direct.  At this point in the proceedings I felt that I was keeping up especially as many of the above conventions can be seen in more mature languages such as C.

However this is the point at which things started to change.  Having discussed those elements where most if not all members of the working group are in agreement he started to move to those more bleeding edge ideas where not everyone has agreed the way forward.

I am not going to attempt to list or describe all the topics he covered.  For two reasons:

• There were a lot of them
• I am not sure I understood them enough to write with confidence and not mislead

There were some elements worth noting:

Proxies
These seemed to be constructs that would allow developers to extend current functionality.  For example the Math object a fundamental construct within JavaScript can be enhanced by Proxies with developers either extending or overwriting the native functionality.  This may be useful where different providers have diversified with their implementation and developers want to be consistent (across browsers for example)

ByteArrays
A better way to manipulate complex objects, at least better than string arrays which is effectively the only option currently available

Improved Random Number Generator
Brendan did not say much about this except a clear message that the current implementation is not very good and probably should be avoided especially if it is going to be used in the construction of unique identifiers like those used in e-Mail request URLs.

Brendan finished his presentations with some predictions.

WebKit the major standard, currently, in browser construction, will fracture with Google and Apple taking the implementation in two different directions.

Harmony will be implemented in FireFox and IE first with Apple and Google to follow at a later date.  This is mostly because Apple and Google’s browser development teams are quite small compared to those of Mozilla (Firefox) and Microsoft’s (which has recently been reformed to make IE9).

Native App stores (Apple and Android) will cause a resurgence of native code initiatives (like Objective C, Flash etc) but in the long run open source initiatives like JavaScript and ECMAScript will win out.

"one for all" is definitely possible - the Test Centre

In my previous post (read it here) I classified browsers into three types:

• Basic
• Simple
• Rich

This was done so that I could organise the way that I build templates for IBM SPSS Data Collection.  This is part of my project to build a single template that works for all browsers both desktop and mobile.

I defined these three classifications by building some simple web pages and testing a number of different browsers on them.  The web pages has a range of capabilities from basic HTML with CSS styling to complex HTML 5/CSS 3 and JavaScript.

The Environment
A first I tried building a test, test environment on my new Dell 1645, a 64bit laptop running Windows 7 64bit.   Installation of the main desktop browsers was not an issue, however almost all the emulators failed to work properly.  Consequently I stopped and reverted to a Windows XP operating system running in a vmWare image.  I built this using vmWare Workstation and started by taking a blank Windows XP SP 2 install and then performing a series of upgrades to ensure that I had all the latest patches applied and .net 3.5.

The Emulators
Once that was done I started installing desktop browsers:

Then I moved on to emulators for mobile phones.  There were a number of emulators that I wanted to try including the OpenWave emulator that I simply could not download.  It seems that the OpenWave browser and many of the older emulators are no longer available.

I installed a Sony Ericsson emulator which was written in Flash.  This was, consequently a simple installation from Sony Ericsson’s Developer Site (PhoneGap Simulator).  This was by far the easiest of the installers to get working.

The other two emulators that I wanted to install were the Blackberry, because I believe that this is a fairly limited browser that being built by RIM cannot be described as standard and the Android emulator.  I would have liked an iPhone emulator but alas my machine is a PC not a mac so I have to make do with testing on my iPod Touch.

Both of these emulators require the Java Runtime emulator (JRE) so that was the first element to install (JRE is available here).  Additionally the RIM emulator requires the Java Development Kit (download JDK here).

Next it was off to the Blackberry site to download an emulator.  I chose one for the Blackberry Storm (9500), however it is my understanding that you can download a number of them (get a blackberry emulator here).  Downloading the emulator, however is not enough if you want to browse the Internet.  It is also necessary to install MDS which is a Mobile Delivery Service created by BlackBerry.  Not only does this need to be installed but it also needs to be run at the same time as the emulator.  Testing with the RIM was concerning.  There are two modes the first is Page View this is a smartphone mode that I had expected to be as good as Sony Ericsson, Android and iPhone.  What I found was that although it supported HTML 5 and a fair amount of CSS it did not really support JavaScript (even though JavaScript support is switched on).  The other mode is called Column view and is a more basic view that is similar to that provided by very basic mobile browsers.  As can be seen by the following example neither gives a very good experience.  It is really troubling that these phones are the phones of choice for Businesses.

The last emulator was the Android emulator (get the android emulator here).  Like RIM there is an opportunity to download a number of different emulators, unlike RIM downloading them all is much easier and therefore I did just that.  Also like RIM the Android needs more than just JRE and the emulator.  There is also a need for eclipse (get eclipse here).  Careful with this download.  It is a zip which needs to be extracted in the location where you want to run it.  The setup is not an installation routine just a way of quickly setting up the environment and getting to the emulators once they have been installed.  Once these items are installed you are presented with an array of different device types.  Each takes quite a while to load but there is no doubt that the wait is worth it.

So that just left aDesigner.  This too needs Eclipse but as that was already installed this final installation was easy.  I may extend my list of browsers and emulators over time (a proper Nokia S60 is very likely).  I would really like a proper iPhone emulator rather than just Safari as Safari does not give an indication of how screen real-estate is working nor does it allow me to tilt the device.

If you have any emulators that you think I have missed feel free to drop me a line.

"one for all" is definitely possible - the Browsers

A couple of weeks ago I wrote an article questioning whether it would be possible to create a single template that handles the vast majority of browsers and allows Data Collection to deliver the best experience each browser can deliver (read Is “one for all” even possible).

I am pleased to announce, after a number of weeks of hard work that the answer is “YES”.

So what has happened over the last few weeks that allowed me to come to this answer?

The steps so far
I have not yet reached the end of my journey, however, I thought it might be a good idea to allow you to catch up.  I have started/completed a number of tasks including:

• A review of different browsers on the market (or previously on the market) identifying the capabilities they provide
• Locate and install a number of browsers and emulators into a Test environment
• Build a small Data collection survey to allow testing
• Start building a solution

Browsers

I started with the currently installable browsers (Internet Explorer, Firefox, Opera, Safari, Chrome)  Then I tried older versions of IE.  Lastly I obtained some emulators (Blackberry, Sony Ericsson, Nokia), finally I installed a copy of aDesigner for testing JAWS screen reader compatibility.

aDesigner an aSide
If you have not encountered aDesigner before and you are seriously interested in web accessibility you need to look at it now (aDesigner is available here).  aDesigner was built by IBM but it has been donated to the Accessibility Tools Framework (ACTF).  Not only does aDesigner provide clear information about the general level of accessibility of a website (based on its markup) it will also render the website from the perspective of “low vision“ showing how those with poor eyesight will see the site.  Furthermore, if that was not enough, in addition to testing websites it can also test ODF (Open Document Format) files, Flash content and general GUI accessibility of any application.

3 Classifications of Browsers
Having reviewed a multitude of browser capabilities I ended up with three simple classficiations.  These are based on the capabilities of the browser and will affect the way in which the template will be designed.  The basis of the categorisation is the fact that there are, currently, primarily, two platforms that have to be handled:

• Desktop Browsers (PC, Mac and others)
• Mobile Browsers (smartphone, basic phone, portable devices)

Against these two basic platforms there are a number of capabilities that may or may not be used:

• HTML
• CSS
• HTML 5
• CSS 3
• JavaScript

All of the browsers support HTML although some only have limited support of CSS.  Only a few have support for HTML 5 and CSS 3 (as I wrote this Microsoft announced that this list will expand to include IE 9 – review by the Register.com).  Lastly there is JavaScript.  This is more complex as browsers that naturally support JavaScript can be “crippled” by corporations that disable its use.  The following graphic shows how these different elements interplay with each other.

From this I defined three classifications of Browser as follows:

Basic Browsers           OpenWare browser, Basic (old) Mobile browsers, very early versions of IE and Netscape (Full HTML coverage, limited CSS coverage, little or no JavaScript coverage)

Simple Browsers         IE, Netscape, RIM, Nokia browser (Full HTML/CSS coverage, no HTML 5/CSS 3 coverage, some JavaScript Coverage)

Rich Browsers            Chrome, Firefox, Safari, Sony Ericsson (Full HTML/CSS and HTML 5/CSS 3 coverage, Full JavaScript Coverage)