While working on a number of early Windows 8 projects I noticed companies often had a base set of features that they were trying to implement. It seemed to me that you could build a tool that could generate a decent base app that would comply with the store rules and give developers a head start to making their apps a reality… so I kicked off development at the end of last year and have released ZipApp, a web based platform that lets you do just that.

Getting Started: from Zero to Hero in 10 minutes

ZipApp gives you the ability to enter some data, hook up some of your existing online content and create a Minimum Viable Product which you can then extend and add functionality too if you wish.

So here is a simple guide to building your first app in 10 minutes:

Firstly, Go to ZipApp.co.uk and sign in with a Twitter, Google, Facebook or Microsoft Account. Once you are signed in you will be able to create a new app. It will ask for some basic information such as the App Name, and a description.

You can then choose a template, these templates are simply colour variations, in my opinion the “ZipApp” Template looks the best. Next choose an icon. The icon will be used to create all of the Windows 8 tiles and store icons.

First add some groups to the application. We are going to add a YouTube playlist, a Twitter stream and an introduction page to our app. In ZipApp a group is a collection of Articles, Videos or Tweets. You can get your Videos from a YouTube playlist, your Tweets from a Twitter Hashtag and/or a Twitter Screen Name and your articles from either an RSS feed or you can manually add them via a simple Content Management system on ZipApp.

To add a group edit your newly created application, navigate to the “Create New Group” button in the sidebar navigation. You will need to enter a group name and a description. For my YouTube group I added the title “How-to build Videos” and the description “A selection of videos that show you, step-by-step how to build Windows 8 applications from scratch” Finally I need to fill the group with my videos from YouTube.

To do this go down to the Plugin Configuration section and choose the YouTube Plugin. In the username box enter a YouTube username. It will then show you all of the playlists from that user. I am getting my videos from the user “windowsvideos” find the playlist you wish to add and press the “Create” button.

To add a twitter Group navigate to the “Create New Group” button in the side bar navigation. Enter a title for the Group such as “Tweets from the Team” add a description like “All the latest tweets from our friendly Team” go down to the plugin configuration section and choose the Twitter plugin. Enter a Twitter Username or hash tag such as “BuildWindows8″ then press the “Create” button.

To add our introduction page navigate to the “Create New Group” button in the sidebar navigation. Enter a Title for the Group such as “About” and a description such “This group contains articles about the application”. In the Plugin Configuration make sure that “Static Content” is selected. Press the “Create Button”.

Now we have a group called “About” we can add an article to this group. On the sidebar navigation expand the article section, find the group called “About” and click on it. This will load all of the Articles for that group.

Since we haven’t added any yet you will see a message telling you to add an article and a button saying create new, press this button. Enter a name for the article such as “An introduction to this app”, enter the Subtitle, this is used on the hub page just underneath the image. I often use it to describe the image or the article. It should be just one line, around 20-30 characters.

Enter a description of the article, this text appears next to the image on the hub page. You should use this text to get users intrigued about the content. It’s only a couple of lines but it should encourage the user to click on the article. If you have an image add it by clicking the small picture icon, this will give you an image dialog box. You can choose from your existing pictures or upload new ones to the system. Finally you will need to add some content. You can type the content directly into the text box and use the various formatting tools to get the text looking how you want it. Finally press the Create button.

You now have an app and it’s ready to download. At the top of the page press the download button. A Zip file containing all of the source code for the application will be downloaded to your system.

Now you have a working app, you can submit to the store, or use Visual Studio to refine it, add new features and functionality. It generally takes a couple of days to get past certification. If you need any help I’ve detailed the submission process here.

Once your app has launched, your job isn’t over. As you gather more users, improvements will suggest themselves. You can start adding features and improve your content based upon feedback.

>> Register for ZipApp

Now that the Windows 8 release preview is out, a lot of developers are beginning to experiment with what they can do with Windows 8.

Unsurprisingly the focus for many is on Metro-style apps that can run across everything from desktop to slate. There are a number of ways to develop these apps but HTML5 is a good place to start if your background is Web Development.  While Metro offers fantastic flexibility, it does require that we get our heads around some new concepts. So for this post I thought I’d cover some of the areas I talk about at events and point you towards some useful resources to get you started.

I’ve selected 5 things that I think you should start exploring:

Views

When you’re producing an operating system without a specific device in mind, you need to make sure it’s flexible. After all you don’t know whether the user will be viewing the app on a PC with a large 27inch screen or a tablet with a 11.6 inch screen and a high pixel density. This can be a challenge for developers as they need to consider how there application will look across multiple devices in various orientations and in specific states (like when your app is snapped alongside another application).

The basic approach to solving this is by using adaptive controls, CSS3 Media Quires and CSS Grids. The following articles will help you understand how to make sure your app looks great whatever device it’s used on:

• Designing flexible layouts
• Defining layouts and views

Search Contract

There’s lots of common functionality built into Windows 8 that you can take advantage of as a developer. You take advantage of this functionality by using Contracts. If you use the Search contract then a user will be able to search your app by swiping their finger over the right hand side of the screen and bringing up the search charm (the charms are a set of buttons that are always available to the user regardless of what app they have open that provide common functionality) As you’d expect, this allows users to search within your app. However, it doesn’t end there. Because of the way contracts glue everything together, it will also allow people to search within other apps too – or across the web for that matter.

Users can search from one single place, regardless of the app they are using or where they are in the system.

• Adding search to a Metro style app

Share Contract

Traditionally, when you’re looking to add sharing functionality to an app, you need to choose up front which other services you want to use. So you might decide that you really need to let users share with Facebook and Twitter and then code that in. Of course things change over time – who knows what kinds of sharing will be popular in future? (An obvious example right now is Pinterest.)

The share contract is a pretty cool way round this issue. If your app in a Share Source then it will be able to share specific content types with any app on the system that supports accepting those content Types. Apps that accept specific content are called Share Targets.

So you could share an image from your app with any app that is capable of accepting image files. As a developer you don’t need to know what app you are sharing with, you just code to a contract and Windows 8 becomes the middle man that manages the sharing.

You can share specific content types, however it is also extensible so you can define your own content types to.

• Adding share

Default controls

A lot of research has gone into Windows 8. Specifically, how people like to interact with an operating system on various devices. So the team has looked at desktops, laptops and tablets, and how people work with a mouse or pen or touch. In fact every which way someone might use any individual element.

All this learning has then been bundled up into the default set of controls that are included in the SDK. It means that developers don’t have to face the complexity of re-learning everything to make their apps more user-friendly. They simply get best practice elements right from the start.

• Adding controls and content shows a whole bunch of resources around controls.
• Some of the research and guidance around Windows 8 and Touch

WinJS

I’ve talked before about where HTML5 excels and where it can struggle. As good as it is, there are still some things HTML5 can’t do yet. But when it comes to Windows 8, the answer is the Windows JavaScript Library.

WinJS provides a bridge between HTML and Windows APIs. It means you don’t have to limit what your apps can do to just what HTML5 can do.

• Writing code using the WinJS library

So that’s it. My starters for beginning to develop for Windows 8. I hope you find the resources useful and I’d love to hear from you if you are currently planning or developing a Windows 8 Metro app.

Last week when I launched the HTML5 Sports Challenge we gave you a CSV file full of data. I thought I would take some time out and show you how to convert that CSV data into JSON (without using any server side code) and then use that JSON in an application. Here is the video:

In the Above video I showed you how to convert a CSV file to JSON, in the video below I look at how you can process that JSON and print some data from it on screen.

So among the other, more serious stuff we do at Microsoft, we also get to play on some really cool projects too. Half the time I can’t talk about them (if I told you I’d have to kill you and all that) but now and then one surfaces that we have more free reign on. And this is one of those times.

The Hunger Games is a new film directed by Gary Ross set in a not-too-distant future where teens fight to the death on live TV (as you would). The production company, Lionsgate, wanted to bring the world of the film to life on the web and turned to development house Ignition Creative, HTML5 specialists at The Nerdery and the Microsoft Internet Explorer team to make it happen.

You can check out the site here.

Trust me, there is some very cool stuff going on under the hood. We have actually produced a full developer tear-down which goes into details about how it was all done. The first instalments can bee seen here which looks into how they dynamically displayed skewed 2D images on a 3D surface.

Over the coming weeks the site will discuss a number of other topics too so make sure you head back and dig into the details.

• Part 2 – Leveraging Developer Tools
• Part 3 – Event Model
• Part 4 – Sprite Animations
• Part 5 – Text Curvature

Plus there’s a bunch of other stuff too. If you want to geek out, you can find the details (plus some code examples) on the tear-down itself. And please do check out the site. I’d love to know what you think.

I recently stumbled across an article on ITworld: Facebook pushes for HTML5 standardization, mobile payments. It did a good job of hanging some thoughts off the back of an attention-grabbing headline but, IMHO, missed the point.

Let’s get this straight: standardisation is a wholly good thing. It gives us all confidence that the sites and apps we build will be accessible by the widest number of users. Likewise, the extension of this standardisation into the area of mobile payments will mean that people will be able to shop on their mobiles and be sure that it’s safe, secure and effective to do so. All good stuff.

What the article neglects to mention is that the W3C Mobile Web Platform Community Group currently has 83 participants including people from Nokia, Zynga, Opera, Intel and Facebook (among many others). And it has a much wider remit than simply mobile payments – check out the group’s charter here.

It’s in the charter you’ll find the really important part of the group’s work – it will deliver specifications, guidance and, crucially, test suites.

It’s these test suites (such as Facebook’s own Ringmark) that will make or break any resulting standardisation. The more people who can supply robust, effective testing the better. (And just to blow our own trumpet for a moment, when it comes to HTML5 and related specifications Microsoft has added over 7548 tests.)

In the final analysis, the development of the mobile web will be less about specifications and more about implementation. The work done by the W3C and its community groups is a vital step forward. But it’s within the test suites that these initiatives will be won or lost.

How many screens do you create your sites for?

For many designers and developers the answer is one, perhaps two – a traditional desktop/laptop and, maybe, a smartphone. Chances are these will be two separate sites – the www.main-site-that-most-effort-goes-into.co.uk and m.mobile-version-with-bigger-buttons-and-some-stuff-taken-out.co.uk. But, just between you and me, the real world isn’t nearly so simple.

Today, there is a huge range of devices to think about. Some users will be basking in a state of the art 30” LED screen, others on a 15” laptop, some will be on netbooks, a bunch will be on tablets (in various sizes) and a load more will be on differently spec’d smartphones. So whatever your site was originally designed for (eg the ubiquitous 960px grid), every other format will be, to a greater or lesser extent, a compromise.

The thing is, it really doesn’t have to be this way.

The answer is responsive web design. It’s not new – and wasn’t when Ethan Marcotte came up with the name in 2010 (as he’d be the first to admit). But there has never been a better time for designers and developers to get their heads round it.

Last week I hosted the Responsive Summit in London. It was set up by Josh Brewer at Twitter, Alex Morris of Mark Boulton Design and Chris Armstrong of Front and got a number of leading designers round a table to discuss the state of responsive web design and what they want to see in future. It was fantastic to see so much passion so well articulated. I came away truly inspired. I have tons of content that I will publish later on in the week, you can check out the coverage over on Lanyrd

In this post, however, I simply want to give a short primer on responsive web design for the uninitiated together with some links for those who want to know more.

What is responsive web design?

There are a range of definitions available, but for the purposes of this primer I’m going to define responsive web design as:

The creation of a site that is able to adapt to the context
in which it is being viewed.

To flesh this out a little, it means creating a site that will dynamically adapt to different screen sizes by resizing and reformatting its constituent elements. So it might be a 3-column site with large images and detailed navigation on a big screen and a 1-column scrolling site with simple navigation and smaller, lighter images on a smartphone.

Importantly, it can be all these things employing a single set of code and will use CSS3 to achieve the right effects.

The three core elements to responsive web design

In Ethan Marcotte’s book, Responsive Web Design (which you simply must go and buy right now) he sets out the three elements you need to play with to create a responsive design:

1. A flexible, grid-based layout,
2. Flexible images and media
3. Media queries

Fundamental to the first two is to stop thinking in terms of fixed pixel widths. At best fixed widths will simply cause a small device to scale everything, making it unreadable and un-navigable. At worst, your site will simply look broken.

Instead, in responsive web design, all elements become proportional to the whole. So rather than a column being 331px within a 960px site, it becomes a percentage of the overall width of an individual display (no matter what that is). The same applies to padding and images. Ultimately, this allows the design to adapt to different screen sizes.

Now, as Ethan points out, at a certain point, when you scale down really small, everything breaks. That’s where media queries come in.

Media queries allow you to determine the type of media the viewer has access to and the physical characteristics of their device and browser. It means you can set parameters for what gets shown, how and under what circumstances. So you can serve up the 3-column extravaganza on a big screen and the 1-column mobile version on a smartphone.

I am, of course, massively over-simplifying the topic here. Do check out Ethan’s book, it’s a great read. And take a look at the sample site he set up at http:// responsivewebdesign.com/robot/ – resize to your heart’s content to see what he means. Finally, further reading can be found at the links below.

Further reading

• Responsive web design (the original A List Apart article by Ethan Marcotte himself)
• Fluid grids, orientation and resolution independence
• Beginner’s guide to responsive web design
• Responsive web design techniques, tools and design strategies
• Responsive web design: 50 examples and best practices
• 21 top tools for responsive web design

How did you learn to code?

I ask because a couple of recent chance encounters have got me thinking that there are some pretty big gaps in people’s knowledge of HTML5 and CSS3.

For example, I was chatting to a student who approached me at an event last Saturday. He asked me where he could go to learn HTML5. I suggested a few books and started explaining how HTML5 differs from HTML4. He interrupted and said, “Sorry you don’t understand… I have no idea about HTML 4 either.”

Is it me or is there a real problem here? After all, the guy was enthusiastic, he wanted to learn but was struggling to find the right resources for him. The problem seems to be that too many of the current books and sites assume that you’re simply moving up from an earlier version. So they spend a lot of time putting HTML5 into context by making exactly the same mistake as I did – explaining how it was different from HTML4 (or 3 for that matter).

When I started web development back in the late 90′s (when dinosaurs ruled the world) I remember starting with WebMonkey.com. Then I moved on to learn DHTML from DHTMLcentral.com. And then on to 4guysfromrolla.comto learn server-side programming.

Is there a modern day equivalent? A resource that guides people from complete beginner to web developer. Or do we simply expect all new developers to find their own way?

What site, book, course etc would you recommend to people that are just beginning in web design and development?

The .net awards are over for another year, but fear not, we have posted the video and photosfrom the night so you can relive the memories of guy-liner, tight leather and screaming guitar solos.

I caught up with a few of the winners including Paul Irishwho collected two Awards for  Open Source App of the year and Developer of the year . I asked him how he found the time to work on so many projects, “For me, it’s just like a matter of passion… I’m just excited about pushing the web forward”.

I also managed to chat to Sarah Parmenterwho was ecstatic to win Designer of the year, she went on to say that the awards ceremony was a great chance to meet up with friends from twitter and the industry in general.

The Master of Ceremonies Paul Boag said the event was “brilliant” and it was really great to see all of the superb winners, his highlight was Jack Hendersona 6 year old boy from Scotland winning the Social Campaign of the Year.

I personally had a great night chatting to tons of fascinating people, my highlight however, was being stopped in my Freddie Mercury outfit by two American tourists who asked if they could have a picture taken with Queen. The list of winners can be seen below, for more in-depth interviews, with all the winners, head on over to the .net magazine awards site.

• Online Game of the Year: Angry Birds Chrome
• Web App of the Year: GitHub
• Best API Use: Instagram
• Podcast of the Year: The Big Web Show
• Social Campaign of the Year: Jack Draws Anything
• Innovation of the Year: jQuery Mobile
• Open Source App of the Year: Modernizr 2.0
• Mobile App of the Year: Reeder
• Mobile Site of the Year: Facebook
• Site of the Year: BeerCamp SXSW 2011
• Redesign of the Year: Mailchimp
• Brilliant newcomer of the Year: Rob Hawkes
• Young designer of the Year: Janna Hagan
• Young developer of the Year: Paul Davis
• Designer of the Year: Sarah Parmenter
• Developer of the Year: Paul Irish
• Agency of the Year: Clearleft

My Summary: Nicholas showed a technique to build large scale applications, one which he used during his time as an engineer at Yahoo. The technique had specific relevance to single page applications all though could be employed on Multiple page applications as well. The architecture he described split an application into multiple tiers with each tier having specific roles and responsibilities and loosely coupled so that elements could be removed, replaced or updated. Slides from the talk are over on slide share.

Nicholas Zakas is a regular speaker on the JavaScript circuit but for some reason I’d always missed his talks at other conferences. So when I saw his name on the Full Frontal 2011 speaker list I knew I was in for a treat. His talk absolutely delivered the promise of the abstract, a solid talk that gave practical advice on how to build large JavaScript applications.

The Abstract: Building large web applications with dozens of developers is a difficult task. Organising the engineers around a common goal is one thing, but organising your code so that people can work efficiently is another. Many large applications suffer from growing pains after just a few months in production due to poorly designed JavaScript with unclear upgrade and extension paths. Learn the tips, tricks, and techniques that allowed large sites such as My Yahoo! and the Yahoo! homepage to continue to grow, scale, and change over time without throwing away previous work. This talk isn’t specific to any JavaScript library, rather, it gives you new ways to apply the libraries you’re already using. The principles of good, loosely-coupled design apply to any system, and you’ll learn how this can help your application today.

Nicholas took the stage and asked “How many people are building single page JavaScript applications?” over half the audience raised their hands. Well, he continued, lots of people are working on single page apps but what I’m going to talk about works for multi page apps as well.

Many people are using Application frameworks like backbone.js, but many don’t realise it’s actually pretty easy to build your own. According to Nicholas, frameworks are like a playground, there are a bunch of things happening and the framework ties them all together. He was quick to add that a framework was not a replacement for jQuery or YUI but rather it sits on top of those base libraries.

Everything on a webpage is a Module, explained Nicholas, he then drew an analogy between web development and building the international space station by saying different people from different locations can build small parts and they go to create a much larger thing. He defined a module as:

web application module (n)
1 : an independent unit of functionality that is part of the total structure of a web application

All modules should be able to live on their own and this is achieved using loose coupling. Each module has it’s own sandbox. A sandbox sits on top of the application core. It acts like a gate keeper. Modules know about the sandbox but are unaware of other modules.

In total the Application Architecture consists of:

• Modules
• Sandbox
• Application Core
• Base Library

Each part of the architecture is like a puzzle piece, no single piece needs to know what the completed puzzle looks like, all that matters is that the piece does its own job correctly. Nicholas then went on to explain each of the sections in turn.

Modules

It’s the modules job to create a meaningful user experience. These modules are made up of JS, HTML and CSS. The web application is what is created when all the modules work together.

Core.register("module-name", function(sandbox){
	return {
		init: function(){
		//constructor
		},
		destroy: function(){
		//destructor
		}
	};
});

Modules are like little kids. They need rules:

• Hands to yourself
  • Only call your own methods or those on the sandbox
  • Don’t access DOM elements outside of your box
  • Don’t access non-native global objects
• Ask, don’t take
  • Anything else you need, ask the sandbox
• Don’t leave your toys around
  • Don’t create global objects
• Don’t talk to strangers
  • Don’t directly reference other modules

Modules must stay within their sandboxes, this can be uncomfortable as developer just want to use YUI or jQuery directly, but by using modules you can build things quicker.

Sandbox

The sandbox ensures a consistent interface, each module only understand the sandbox. The sandbox acts like a security guard, you may not, for example, want the module to set cookies without going through a sandbox.

Core.register("module-name", function(sandbox){
	return {
		init: function(){
		//not sure if I'm allowed...
			if (sandbox.iCanHazCheezburger()){
				alert("thx u");
			}
		},
		destroy: function(){
		//destructor
		}
	};
});

Sandbox Jobs

1. It provides consistency
2. It provides security – Determine which parts of the framework a module can access
3. It provides communication – Translate module requests into core actions

Nicholas made the point that you should take time to design the sandbox as it’s very difficult to change it later.

Application Core

The application core is the gut of the application,  it controls the application. It will start modules and also will destroy modules. So a module might look something like this:

Core = function () {
    var moduleData = {};
    return {
        register: function (moduleId, creator) {
            moduleData[moduleId] = {
                creator: creator,
                instance: null
            };
        },
        start: function (moduleId) {
            moduleData[moduleId].instance =
			moduleData[moduleId].creator(new Sandbox(this));
            moduleData[moduleId].instance.init();
        },
        stop: function (moduleId) {
            var data = moduleData[moduleId];
            if (data.instance) {
                data.instance.destroy();
                data.instance = null;
            }
        }
    }
} ();

And the sandbox might look something like this:

Core = function(){
    return {
        //more code here...
        startAll: function(){
            for (var moduleId in moduleData){
                if (moduleData.hasOwnProperty(moduleId)){
                    this.start(moduleId);
                };
        }
        },
        stopAll: function(){
            for (var moduleId in moduleData){
                if (moduleData.hasOwnProperty(moduleId)){
                this.stop(moduleId);
                }
            }
        },
    //more code here...
    };
}();

You’d then register the modules like this:

//register modules
Core.register("module1", function(sandbox){ /*...*/ });
Core.register("module2", function(sandbox){ /*...*/ });
Core.register("module3", function(sandbox){ /*...*/ });
Core.register("module4", function(sandbox){ /*...*/ });
//start the application by starting all modules
Core.startAll();

The application core controls the communication between modules. Nicholas used the example of twitter (circa 2009) as a good example of a modularised application, where the different modules need to communicate. When you update your status, the status module needs to let the timeline module know a change has happened.

Nicolas went on to show an example of tight coupling where one module called another module. Explaining that tightly coupled modules were difficult to maintain.

TimelineFilter = {
    changeFilter: function (filter) {
        Timeline.applyFilter(filter);
    }
};
StatusPoster = {
    postStatus: function (status) {
        Timeline.post(status);
    }
};

Creating modules that notified the sandbox that something had changed was a better approach, since the sandbox could then choose if it should do something. Loose coupling ensures your code has longevity, Nicholas stated that the code you write should last 5 years – taking a long term outlook on the code you write ensures you take care of it and that it is extensible.

Nicholas recommended that the application core should handle errors and pointed the audience to another of his presentations Enterprise JavaScript Error handling for further information.

In summary the Applications Core’s Jobs are:

• Manage module lifecycle
  • Tell modules when to start and stop doing their job
• Enable inter-module communication
  • Allow loose coupling between modules that are related to one another
• General error handling
  • Detect, trap, and report errors in the system
• Be extensible
  • The first three jobs are not enough

According to Nicholas planning for extension is extremely important, since anything built for extension can never be obsolete. You should plan for common extension scenarios such as Error Handling, Ajax Communication, New module capabilities and General Utilities. If you use a sandbox and make all your AJAX communications through it, to a single point in your application core, you can switch the AJAX communication out for another type in just one place. It will then be changed for your entire application.

Base Libraries

According to to Nicholas most applications are too tightly coupled to their base library, he pointed to a presentation by Joseph Smarr called High Performance JavaScript  which suggests you should use libraries like jQuery as a scaffolding; only the application core should know what base library is being used. This approach ensures that you can swap out your base library at anytime.

In general a base library should do the following jobs:

• Browser normalization
  • Abstract away differences in browsers with common interface
• General-purpose utilities
  • Parsers/serialises for XML, JSON, etc.
  • Object manipulation
  • DOM manipulation
  • Ajax communication
• Provide low-level extensibility

If you follow Nicholas’s advice then you will end up with an architecture where:

• Only the base library knows which browser is being used
• Only the application core knows which base library is being used
• Only the sandbox knows which application core is being used.
• Each module knows nothing except that the sandbox exists.
• And finally no single part of the web application knows about the web application.

By structuring your application this way Nicolas suggested that you could reuse your framework across multiple applications. Also because each piece had it’s own unique job it could be tested individually.

The real benefit, according to Nicolas, was the ability to build highly scalable web applications where pieces could be removed at will.

The talk provided a great introduction to design patterns, Nicolas’s delivery was clear and well paced, and made for a great talk that left me thinking that I should probably apply the same architectural rigor that I apply on the servers side to my frontend development.

My Summary: Web developers are being seduced by modern web techniques to the extent that they sometimes forget the fundamental lessons that have been learnt over the past 20 years. It’s every web developers responsibility, as a professional, to use cutting edge techniques responsibly and take that little extra time to make sure our applications respect the web.

In the packed auditorium at the Full Frontal JavaScript conference in Brighton Phil Hawksworth took the stage to question if Modern Web Developers are taking care of our beloved web. The abstract, listed below, peeked my interest as it sounded like some controversy was in store… I wasn’t disappointed.

The Abstract: “We all love to see exciting and innovative “interface shizzle” driven by JavaScript and the ever increasing rendering capabilities of modern browsers, but are we getting these at the expense of the Web? This talk will explore the good, the bad, and the fugly of rich interfaces, while examining how and why we should take care not to damage the Web.”

We now have the whole pantomime cow. JavaScript on the frontend and JavaScript on the backend, said Hawksworth, Whilst this was exciting it also reminded him of some thing Jeff Goldblum once said. 

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

Phil noted that developers were so seduced by the shizzle and the possibilities that they often forgot about the foundations on which the web were built.

Many of the things that JavaScript developers sneer or look down on Flash developers for – Lack of Copy-Paste, No bookmarks, making content inaccessible or unsearchable. Are being repeated by developers today who are using standards based technologies.

In the past, whenever Phil would speak to flash developers, about those sorts of shortcomings, they’d always come back with the same response. Flash *can* do it, and with a little extra care and attention to detail those sorts of problems can be overcome.

The problem is when developers care more about the pixels rather than the web or to put it another way pixels > the web. People care more about the look rather than the web.

In many respects the choice between Pixels or the Web comes down to what is valued by the developer. In the flash world, developers often go through a journey of Photoshop > Adobe suite > Flash and therefore care more about the sex appeal than the web or the seductive power of what is possible.

If we look at how websites were, we now have increased sophistication in the features and users expectations.Take for example the McDonalds website 15 years ago:

With the site on screen Phil pointed out some of the sites deficiencies, such as the way they used a loading screen, how much instruction was required and how it catered for a less sophisticated audience.

He then loaded beetle.de and went on to explain that although it has a richer experience, it takes 13 seconds to load, the user journey is different to the point that it also requires instructions and it seems like we haven’t come along way from the McDonalds website built 15 years ago. The beetle site has over 11mg images, with 251 http requests and is missing cache expiration on many of the elements.

Rather than using image sprites, all of the elements are separate images. Phil remarked “We know better than this” and went on to say it reminds him of a quote:

Jeff Goldblum – “Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

Or if you really pushed Jeff he’d probably say:

Jeff Goldblum – “That’s really a lot of http requests for a site about a car”

The mobile experience was also used by by Phil to make another point “If you need a separate version of your site for mobile, it’s time to think, maybe the way we approached this website was wrong. “

Also the site doesn’t use the URL bar so elements of the website are not discoverable.

With all things considered, Hawksworth remarked, maybe it would have been better if it was built in flash. Phil then went on to demonstrate his rule of thumb to determine if a website respects the web: switch off JavaScript. If a site has no fall back content or just vomits a warning with a noscript tag then things aren’t great.

Phil used the example of twitter.com as a site that doesn’t work at all if you switch off JavaScript.

Phil was keen to point out that it’s not that he’s against new client side technologies but just that as professional developers we should take more care to be respectful of the web.

Things like URIs are what make the web the web.

Phil went on to talk about the usage of Hash Bangs # in URLs pointing out that these complicated hacks are making crawling the web really hard raising the question “When did it get so hard to crawl the web?”

All this client side shizzle doesn’t have to break the URL. Phil was keen to point out the great work GitHub have done to utilise the History API and pointed to the work that Google Advocate Paul Kinlan (and Michael Mahemoff incidentally) did on Levi Routes a routes framework for JS that hooks in to HTML5 history API.

Phil also showed Adobe expressive web (which rather oddly was removed from the internet last night. UPDATE: it was a temp DNS issue which Adobe fixed and the site is now online.) and showed that without JavaScript it was a whole lot less expressive.  The problem that Phil was articulating was he said well summed up by Bruce Lawson “The real worry is when the demo mentality sneaks into the production site”.

Phil admits that on occasion he’d have spent a little more time refining his own work so that it better respects the fundamentals of the web.

Phil spoke about his worry around tools like Adobe edge saying that by Automating things for us, they can sometime make it too easy for us to forget about the web. He showed an image of Microsoft Clippy suggesting that having a tool that’s always willing to help isn’t a great thing.

Fundamentally Phil’s talk could be reduced to this: As professional Developers and designers we should all look after the web a little more. It was a fantastic, well researched and insightful talk and if you get the chance to see Phil speak in future you should absolutely go.