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.

Future of Web Design (Day 2) - Aarron Walters And Sarah Parameter

Welcome to the afternoon, lunch has been consumed (at Starbucks) and we are raring to go for the third of four sessions for the day.  In this session two very different presentations around the key concept of design (not development).

Aarron Walters – Learning to Love Humans

This presentation is by one of the founders of mailchimp (http://www.mailchimp.com) not a service I have thought of subscribing to but one that is recognised in the industry for its innovative design.  The presentation was called amusingly “Learn to Love Humans”.  It aimed to show that emotion should be a strong factor in the development of a website design.  It started with the premise that the changing nature of the internet (specifically the increasing use of social media) means that people are starting to expose themselves as human beings rather that remote non-entities and that web design should reflect that.

This was followed by an glimpse of Maslow’s Pyramid of needs which Aarron indicated could be translated into an equivalent pyramid of interface design needs.  Aarron stated that interface design needs to be functional, reliable, usable, pleasurable.  Today’s designs tend to be able to fulfil the first three of these to varying degrees but few (if any) could be described as pleasurable.  For example 37Signals designs implementations for BaseCamp are often heralded for their ease of use and functional approach to project management but they cannot be described as pleasurable.  On the other hand WuFoo (a forms creation tool) brings a colour delight to forms creation so increasing the pleasure of what is basically a database interface.

In effect Interface Design needs to incorporate the concept of personality, personality is an important part of every individual.  More importantly it is a platform for emotion and emoting is one of the first things we do when we are born.  We quickly learn that broadcasting emotion can result in the satisfaction of needs.  Interface Designs need to bathe users in emotion.

Tapbots is a company that have succeeded in this concept.  Their iphone applications are a brilliant example of bringing pleasure to non-pleasureable activities. 

Weightbot, for example, brings just the right blend of function and pleasure to the tracking of weight (an activity that usually indicates a not too positive frame of mind).  Designed on the concept of Wall-E, they combine clean, functional design with the basic features of a face to make their application more attractive, more pleasurable to Humans.

Aarron indicated that there were a number of approaches to the adding of pleasure including:

Treats – Providing mild amounts of humour within the site

Discovery – Using easter eggs to deliver additional pleasure when something good or bad happens

The main aim of this type of design can be used to overcome humans natural inclination to doubt, it can also have the additional benefit of bringing forgiveness when something goes wrong.

Overall this presentation was just what this conference needed.  An emotion response to design issues, not steeped in the technicalities of how to deliver such experiences but a real view into how designers should be thinking when building the websites of the future.

Sarah Parmenter – 10 Tips for iPhone Interface Design

Sarah is a designer focused on the field of iPod/iPhone/iPad design.  She provided 10 key thoughts crucial to successful design of an Apple App (how to get it past Apple’s approval process and into the hands of users).  Sarah brought her not inconsiderable knowledge of app design and the oddities of Apple to an audience who are probably unfamiliar with many of these issues.  Her ten thoughts focus on:

• Making a clear Development choice between App and Web App
• Clearly defining the purpose of the application from fun tool to serious entertainment
• Provide Inspiring design documents – do not just send designs by e-Mail
• Be Prepared for UX interjection – expect clients to have their own ideas
• Understand the orientation, dimension an hierarchy elements of iphone design
• Unravel Hi-Fidelity UI – know when to bring this into the discussion
• Take time to design a beautiful icon – it is the flagship of the product
• Understand the App approval process

This presentation was clearly targeting freelance designers (as opposed to developers or those of us who work for corporate). It talked about the right ways to approach pricing and hints on how to engage customers effective.  It was concise clear and great content for this type of event.

These two presentations were by far the best of the day the presenters knew their audience, pitched their content at the right level, had a clear message and brought it forth in a commanding way.  Its great to be able to attend events with this level of quality.  Long may it continue.

"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.