Well, It turns out that Steve Jobs wasn’t just being spiteful to Adobe by preventing Flash from running on the iDevices. It really was a poor experience for users and a limited and inflexible environment for content creators too.

Adobe have been edging towards HTML5 with the launches of tools like Wallaby and Edge. It now looks like they intend, like Microsoft, to fully embrace HTML5 and ultimately ditch their proprietary plugin technology entirely. Killing their mobile plugin looks like the first step to that conversion. It seems inevitable that eventually their desktop plugin will go the same way, as will Microsoft’s Silverlight, over the next couple of years.

More and more developers are choosing HTML5 as their RIA technology of choice, particularly as the web is increasingly extending from desktop to the mobile and HTML5 is the only ubiquitous choice. At Caplin, we have always been pushing the boundaries of what can be achieved in a browser with our Caplin Trader Toolkit, so it’s nice to see the world (and Adobe) finally starting to catch up!

The vocal portions of the Web that care about such things seem to have already made up their minds about Dart, the new web programming language from Google. My opinion of it has been flipping between intrigue and tedium.

Maybe you don’t even know what I’m talking about so here’s the gist of it: last week at the GOTO conference Google unveiled, to moderate hype, their new programming language called Dart. The official aim of Dart is to help developers with writing “structured web applications” – which sounds like a euphemism for “[eventually] replace JavaScript” — to some at least. I’m going to explore that loaded sentence (or go to tl;dr).

Origins of Dart at Google

Google and the Web are inseparable. To many, the Web would pretty much cease to be useful without Google Search and Gmail. Google pioneered, or at least popularised, the foundations of modern web application development, namely AJAX. When Google Maps was released it was a breath of fresh air in its product niche and an astounding achievement in programming and UX. The thing to note here is the J in AJAX, which stands for JavaScript. Having wedded itself to the Web, Google has had to wrestle with this piece of technology since the beginning of its forays into anything more complicated that a search box and a list of results.

I doubt a Google spokesperson has ever come out to say it, but it’s clear that Google staff are no fans of JavaScript. Six years ago, they got sick of figuring out the look and feel of things and started work on GWT. A few years later they got fed up of the performance of JavaScript runtimes and wrote the source-to-source Closure Compiler/Optimiser for JavaScript and started work on their own V8 JavaScript Engine which powers Google Chrome (and notably also NodeJS). All in all, a business expense of at least tens of millions of dollars, not to mention the headaches and opportunity cost. Of course, Google has to go all this effort because of the scale of their JavaScript codebase, which makes any criticism from small- to medium-sized development teams utterly moot when they say “we’ve never had a problem with normal JavaScript” — yes, of course you haven’t, because you’re not juggling a web application product line which includes Gmail and Google Docs.

This leaked email from Googler and ECMAScript committee member Mark Miller emerged last year. It provides an insight into Google’s view of JavaScript as a bottleneck in their efforts to build products that compete with native applications. It’s a long read but the gist of is that Google can either wait for JavaScript to evolve slowly, and/or take action and write its own better JavaScript, codenamed “Dash” in the email. The main goals of the new language are listed as performance, developer usability (including familiarity) and improved tooling (a.k.a. clearer code structuring and packaging), which no-one will deny are lacking in JavaScript.

So they did just that. Sort of.

Dear Google, Public Relations != Developer Relations

<rant>

Google suffers from NIH Syndrome: it does not take from the outside world, preferring to build its tools from scratch, and anything it produces it does so mainly for consumption by the thousands of people it employs (this manifests itself in things like their approach to Platform development, too). Don’t let the odd open-sourced project fool you.

In the case of Dart (not the first Google-made langauge) they may have hyped up its announcement, but they clearly have no intention of letting programmers — the only people who care — actually experiment with the new language yet. When you go to Dart’s code repository, there is little effort made to make it simple for you build and use anything. Maybe Dart is just not ready for too much public airing, but that means they should have left its unveiling until it was. Google is not providing a pre-built compiler or VM binary for Dart, and their build instructions are just about tedious enough that I’d rather not waste my time. If git clone and make install are good enough for many a large project, why am I being instructed to install and use a Google-specific tool to merely fetch code?! No thanks.

</rant>

What’s Dart Like?

Apart from syntax and code samples that run in the browser, there isn’t much to go on. I quite like this article that says Dart is to JavaScript what C# is to C++: basically cleaning up some of the mess. Here’s a summary of what I think are the main features to give you a feel.

Key Language Features

Purely class-based

The class and interface concepts from Java are brought into Dart, almost exactly, with multiple inheritance being achieved through implementing several interfaces. The “purity” here refers to the idea of everything-has-a-class (or everything-is-an-object), which is lacking in both Java and JavaScript, and can only be a good thing. This applies to functions, of course, which makes closures possible in the same way as JavaScript. Compared to JavaScript’s prototype-based model of OOP this class-based approach makes writing Dart code less crufty, more familiar to the average programmer, and will make tooling and dealing with hierarchy of the code simpler or at least easier to adapt from existing tools.

I suspect this model improves the run-time performance of Dart code compared to JavaScript, too, since JavaScript’s prototypal inheritance and functions-as-objects idiom are expensive (objects are cloned or recreated instead of referenced or re-used), at least without a good JIT compiler (but don’t hold me to that).

Optional typing

This is one of the more baffling features for me. You could write Dart code without any consideration for variable types, but you could also annotate your variables with types, like String or any class you’ve defined. The baffling nature of this is that the annotation is just that, an annotation: it makes no difference to how your code works, other than the compiler giving you a warning if you’ve misused the variable (e.g. tried to assign a number to a String variable). The code will still compile and run.

The justification for this feature is that it provides “documentation” and aids debugging and static build tools during development. I’m not convinced by this half-feature. Perhaps the makers didn’t want to put off web developers with scary strong typing or the goal of making Dart compilable to JavaScript was an obstacle. The official advice is “use types where they make sense”. To me, that advice doesn’t make sense.

Structure and isolation

One of the big practical difference between JavaScript and Dart is that when embedded in HTML, each script tag containing Dart code is isolated and can not access other scripts directly, i.e. there is no per-page global namespace. Also, Dart code isn’t simply run when it is encountered but a main() function needs to be included as the entry point into each piece of code. In theory, the designers intend each portion of code, or isolate, to be able to run in its own thread, but such multi-threading support is non-existent in browsers.

This is where the “structured” nature of Dart is most obvious and I personally like it compared to JavaScript, but those used to the way JavaScript behaves will resist it.

In the language specification, there is some detail about the concurrency model of Dart, which involves these isolates behaving like actors which perform local computation and then communicate via message-passing. I didn’t spend much time trying to understand these, but this (rather negative) write-up has an explanation.

Why you won’t use Dart

Firstly, there is obviously no practical implementation for developing or deploying Dart code, so don’t waste your time on it yet. Even the Google Chrome team aren’t 100% on whether and when they will implement a Dart runtime, let alone other browser vendors.

Secondly, although all concepts used in Dart should be familiar, it is still a paradigm shift for web developers and you can get by just fine with JavaScript. This extends to the way Dart handles DOM events which is something many developers take some time to completely absorb even in JavaScript with all the online documentation available, let alone with Dart’s event model.

Thirdly, if you really don’t want to write in JavaScript, and you don’t have Google’s NIH Syndrome, you already have access to many well-established alternatives. I have written a non-trivial amount of code in CoffeeScript, which is a pleasure to use, and look forward to playing more with ClojureScript, which is elegant but still immature. Of course, JavaScript isn’t just “assembly language for the Web” which can be ignored and you still need to fully understand its intricacies before trying to work around it.

tl;dr

This chap on StackOverflow got it right, in my opinion: Learn JavaScript, use CoffeeScript, check out Dart.

A colleague sent out a link to this article over the weekend – well worth a read. Apparently when Apple decided that publishers had to hand over 30% of the revenue of apps sold via the iTunes store, the FT decided to take a different route and pull their app from the iTunes store – focusing instead on creating an HTML5-driven, Web-based application.

I won’t re-write the story – instead, read it here.

Anyone know of any other good examples of other such web-based apps that are experiencing a similar degree of success?

When it comes to how we act as professionals it seems as though there is a certain taboo around the subject. Speak to any software engineer and he will be more than happy to tell you about all the mistakes he has made in his code; No one wants to discuss their professional conduct.

A Code of Conduct for Professional Programmers

“The Clean Coder” cuts through all that with a frank and open discussion. Bob Martin admits the mistakes (and successes) that he has made through his career while explaining how to avoid making them yourself. As with his previous book, Clean Code, his conversation writing style and straightforward manner makes this book a great read.

All readers, from experienced managers to fresh graduates, will find questions they need to answer about the way they work. And as any book on this topic should, it raises some pretty inflammatory opinions.

Robert Martin doesn’t shy away from making bold statements, for example saying that if you are giving 8 hours a day to your employee you should be giving an additional 4 hours a day to self study to truly consider yourself  a professional. A big ask for many of us. And his outright condemnation of “entering the zone” will definitely get some of the master hackers I know more than a little riled up.

Conversely some of his advice seems too obvious in retrospect. His explicit declaration that “to try is to fail” reinforces something I should have known all along; no amount of hoping and finger crossing can make you develop any faster. If code is going to take 5 days, no amount of “trying” will make it ready in 3. And while most of his advice is “non-technical” there is still plenty of advice on development itself.

I encourage every developer to have a look at this book and reflect upon what it truly takes to be a professional.

Google finance has clearly decided it is all over. For the financial sector at least.

As of 10 minutes ago, this was what the search engine was showing. It might not be a great time to sell!

This year we’re presenting three separate sessions at the Software Practice Advancement Conference (SPA)! Read on for a run down of the sessions we’ll be leading.

Professional JavaScript – Tues, June 14 – 09:00-11:45

Run by Richard Chamberlain & James Turner

This session takes developers from a simple .js file in an HTML page to being able to develop enterprise level JavaScript-based application identifying best-of-breed tools for development and deployment. Reflecting on in the field experiences with these tools.

Attendees will produce a package and set up a development environment that will allow them to:

For more information, click here.

Sketching – A Creative Problem Solving Tool – Tues, June 14 – 09:00-11:45

Run by Duncan Brown

Sketching is not just for artists! Come along have some fun and take away ideas for visual thinking with sketches.

The focus will be on communicating software design and interaction problems and solutions not flowers or life drawing… unless anyone wants to model.

If you don’t already sketch, you’ll be able to add sketching to your expanding Agile toolbox of quick and simple tools for getting things done.

No previous specific skills/knowledge needed. You may think you cannot draw or sketch but I will help you how to build your skills and confidence. This workshop should be relevant to anyone who wants/needs to communicate ideas quickly and effectively.

In this session you’ll participate in group sketching sessions that build in complexity. We will also do some ‘trick’ exercises that make your brain flick into ‘Right brain’ mode.

For more information, click here.

WebApps That Shine – Wed, June 15 – 09:00-11:45

Run by Adam Iley & Ian Alderson

The aim of this session is to demonstrate what is possible with HTML5. At the moment it is a term that has been grabbed by the marketing departments…the time has come for developers to claim it back.

Offline & Performance Workshop

Device Feature Workshop

Portability Workshop

Other Concerns

For more information, click here.

Just last week the UX team at Caplin had the fortune of attending UX London 2011, the largest UX conference in the UK, for three days of talks and workshops. Some of the biggest names in the industry from all over the world came and shared their insights. It was a great opportunity to meet with fellow UXers and learn about their trials and triumphs. Here are our top 3 highlights:

1. We Need A Common Language To Communicate

In many companies, there seems to be an issue of miscommunication, particularly amongst designers, developers and business folk. There is the confusion of “what we said, what he expected” and the end result which is normally nonsense. Dependent on your career you may use different jargon, buzzwords, delivery styles and have different ideas of what are the important aims and goals.

Business jargon defined

In order to overcome this gap of understanding, we need to “align the dialects”, as Kate Rutter says. By this she means that we need to demystify our different vocabularies and clarify their meanings to each other in simple terms. As designers we need to express our strategy and its impact on business through using certain “strategy tools “ such as the Ishikawa diagram, prioritisation charts, storyboards, conversion models and product evolution maps. These tools allow the business people to understand our approach and help reinforce decisions. Having an insider who can appreciate the perspectives of your business colleagues will help bridge the gap between the languages and establish expectations. Finally addressing key points with short, concise answers removes the extra jargon while getting across the underlying ‘What’ and ‘Why’ behind a design.

(For Kate’s full presentation check out on ‘Strategy Patois’)

2. Redesign Must Die

Louis Rosenfeld gave a great talk about how we should never “redesign” a website,  software application or digital interface as it is a hollow, meaningless and vain pursuit.

By this he means that simply giving an interface a new look will never weed out the original problems it had, as this can only be achieved through understanding interface users’ needs and designing to address these. He said that ill-defined problems cause “insanity and vanity” as they cause the user (and the designer!) to have a painful experience and only focus on the surface. In order to avoid doing redesign we should:

1. Prioritise – regularly identify the most important problems to our users
2. Tune – incrementally address those problems
3. Be opportunistic – Look for simple ways you can make a difference now, such as supporting contextual navigational needs of users or improving search results to be ‘smarter’ according to users’ needs

(For Louis’ full presentation check out ‘Redesign Must Die’)

3. Changing A Company’s Culture Is Difficult

This point came from Kim Goodwin’s Leading UX presentation which covered the core skills a good UX team leader should have as well as how to make changes internally in your company. The overall message was that the two things that companies that deliver great experience have in common is: 1. Great Leadership and 2. A Culture That Supports Change. A ‘good leader’ will be able to deliver feedback, handle criticism, negotiate, and mediate conflicts.

A culture that supports change will be full of people that share the same vision and values. It will also be adaptive, accepting of risk & failure, committed to quality and willing to prioritise. If a company is lucky enough to have both of these, it will take a minimum of 3-5 years for the change to emerge in a noticeable way. The reason for this is that old cultures have deep roots and without full commitment from the entire organisation, change is improbable. However if you are determined to bring about positive changes in your organisation the steps to take are:

Establish Urgency —> Develop A Guiding Coalition —> Develop A Vision —> Communicate The Vision —> Enable Action —> Get Short-Term Wins —> Don’t Let Up —> Make Change Stick

(For Kim’s full presentation check out ‘Leading UX’)

For other exciting UX events around the world check out FindUXEvents.com and Johnny Holland’s UX Calendar for listings!

——————————————————-

So it seems that HTML5 marches on, driven by faster browser cycles…

This, and the news that Mozilla plan 4 releases of Firefox in the next 12 months (including FF5 by the end of June), show that Google have got it spot on in breaking the traditional 2-3 year browser cycle with their Chrome release schedule.

This can only be good news for the future of HTML5 and more evidence that HTML5 apps are converging fast with native apps, not just on the mobile platforms but on the traditional desktop too.