If you couldn’t make it, sad times, but we streamed the whole thing live on the website. Vimeo videos will be on the website soon, direct yourself to browser.londonwebstandards.org for the goodies.

Before that, I was taking photos, so take a look at this album to see what was going on:

https://plus.google.com/photos/102931355438327676259/albums/5736524470114876337

Steve

If you liked this, you may also like:

1. Browser Wars: The SlickSpeed Test
2. It’s time to upgrade your browser, no, really
3. Why I Use Opera – A case for the browser underdog

I took sketchnotes throughout the day and inked them up earlier. They were started in pen, hence being a bit rough around the edges (my FOWD set is still the high water mark personally), but have a look.

My thanks again to James Parton, Tom Hume, Keiran Gutteridge, Thayer Prime, Karen Barber, Rick Chapman, PPK, Phil Archer and Laura Kalbag for such great talks, and to Chris and Mike for putting on the event.

If you liked this, you may also like:

1. Future of Web Design Sketchnotes – Day 1
2. Future of Web Design Sketchnotes – Day 2
3. Dangers of an open mobile OS

This all works really well… on Linux and OS X. On Windows, Node.js can’t run pre-built native Node.js libraries, so it has to be build by the NPM build service. This is all documented on the JSDom github issue, but for brevity, this is what you have to do to make it work

1. Node.js 0.6.12 is required, apparently 0.6.13 will make this easier
2. NPM 1.1.8 is required – Node.js is bundled with 1.1.4 so you’ll need to run npm install npm
3. Python 2.7 is required – And the python runtime needs to be on the PATH
4. Microsoft Visual C++ 2010 is also required – I’ve got the whole Visual Studio installed on my machine, but I think you’ll be able to get away with the distributable package
5. I believe you’ll also need the node-gyp module installed globally Node-gyp is included in NPM

That’s a lot of dependencies, but it should all work. Once Python and C++ are installed,  the commands you’ll need to run are:

npm install -g npm

npm install -g node-gyp

npm install jsdom

And that’s it. If there are build errors, let me or the JSDom team know.

If you liked this, you may also like:

1. Safari update makes itself obsolete on Windows
2. Node & Tell at London Web Standards #lwsnode
3. Improving Javascript XML Node Finding Performance by 2000%

LWSNode - George Ornbo

Introduction to Node.js – George Ornbo

George is a front-end javascript developer who wanted a simpler way to create web apps quickly, and in a language that he knows. Enter Node.js, with its “Event driven I/O”, or better put as “Network programming with javascript”.

George fired up his browser, and gave the attendees the IP address of his laptop, which was running a simple Node.js chat server, which coped incredibly well with 100 people trying to join from their phones and laptops, showing how resilient it can be on a small laptop. We were then treated to a demo of a “Love/Hate” measure, taking a data feed from Twitter in real-time, it counted and displayed a graph of the percentage of love and hate on Twitter within the last 10 minutes. Seeing the data streaming in, and then the 30 lines of code used to create that was amazing. Node is a framework that does all the hard stuff for you, and enables you to write applications quickly and efficiently.

George then explained why it was so fast – Node works on an event loop, rather than threads. The idea is that no operation should be blocking so that Node can always keep getting http requests and fire of requests to the database or any other data sources asyncronously. It’s a big of a head scratcher to anyone who hasn’t done much high-performance javascript before, but it’s a very efficient way to program. George showed two graphs (roughly transcribed to the notes) on node performance vs apache for high concurrency and memory usage: node wipes the floor with it. Note: since this talk took place, Apache 2.4 has come out. These graphs are a bit different now but Ngix is still well ahead on speed

In summary, Node is great for high concurrency situations and for making server back-ends quickly. It’s a break from your normal programming style but is is just JavaScript when you’re over that hurdle. Give it a go!

Node and Tell Sessions

Node & Tell

All of these 4 people gave it a go and were kind enough to show us what they’d been doing.

First was Maired Buchan from Head who had made a voting system based on an Arduino and Node to collect the data. Other than that the voting machine use marble runs to capture votes, she explained that they’d tried a number of places to put the Node server to get maximum performance, eventually settling on a separate server, allowing the Arduino to just count and send a message to Node. The source code is now on GitHub.

The second talk was from Andrew Nesbitt talking about the London Node User Group (which me mentioned on and off), and showing off how he’d made the LNUG website with Node and GitHub.

The third talk was Simon Thompson talking about how he’s used Node as a prototyping language, making a drag & drop filing cabinet backed by a MongoDB. He was really impressed with how simple everything was and how little setup you needed to do before everything was working.

The final talk from Daniel Knell and Jason Grant showed a responsive web app that found interesting things to do in your local area. Using Node to help them make some of the more complex geolocation calculations, the web app is a very simple idea that is well executed. It is so good that it won first place at a recent hack day, and they finished in half the time they were given.

Node Training

If you want to learn more, go to LNUG.org or look into Remy Sharp’s training course, which is an excellent introduction to Node

London Web Standard crowd at Forward

If you liked this, you may also like:

1. Javascript Fun at London Web Standards #lwsfun
2. Improving Javascript XML Node Finding Performance by 2000%
3. Installing JSDom on Windows

So why is it happening?

The February 2012 face-to-face meeting of the CSSWG [complete transcript] had vendor prefixes on the agenda because:

glazou: Title is: Why and How to Implement Other Vendors' Prefixes
   tantek: This is a specific subtopic of vendor prefixes
   tantek: The problem statement right now, and this is a problem for
           Mozilla and any other non-WebKit browser
   tantek: Sites have webkit-specific content, and serve backup content to
           everyone else. Specifically for mobile content.
   tantek: Non-WebKit browsers face prisoners dilemma
   tantek: similar to quirks in 2003 or so

FYI: glazou is Daniel Glazman, chair of the CSSWG, tantek is from Mozilla. Other parties who appear in quotes are Peter Linss (HP), Florian Rivoual (Opera), Sylvain Galineau (Microsoft) and Simon Fraser (smfr from Apple).

So far, sounds reasonable, then tantek continues:

tantek: At this point we're trying to figure out which and how many webkit
           prefix properties to actually implement support for in Mozilla
   plinss: Zero.
   tantek: Currently we have zero. Zero is no longer an option for us.

Suddenly, everything is turned upside down. Opera and Microsoft start saying the same thing – the argument is that of the top 1000 websites, a significant percentage uses webkit-only prefixes without the other browser prefixes.

glazou: A long time ago, Mozilla had an Evangelism team that would call up
           the website owners and ask them to change.

This refers to developer evangelism, people like Bruce Lawson, Martin Beeby and Rob Hawkes to name just three (Google has a huge team - [Thanks to Michael for the correct link]). All of these people are pioneers in web technology and use vendor prefixes every day, and all of them tell developers to use the other browser’s vendor prefixes too. This is not the opinion of the CSSWG:

 Florian, Sylvain: Evangelism has failed.
   glazou: Have you tried pinging the WASP about that? Other activists of web
           standards?
   sylvaing: If MS can't scale to handle this, you think WASP can?
   tantek: Opposite is happening right now. Web standards activists are teaching
           people to use -webkit-
   tantek: People like Lea Verou.
   tantek: Their demos are filled with -webkit-. You will see presentations
           from all the web standards advocates advocating people to use
           -webkit- prefixes.

These words make me sad indeed. The CSSWG has lost faith in evangelists and the community upon which it relies so much that they are prepared to implement other vendor’s non-standard code and prefixes to help them gain market share back.

Quirks mode all over again

Yes, this is where we’re at. The current dominance of webkit, especially on mobile, is causing developers to adopt non-standard technology and only those bits of technology for webkit. This cannot happen. Daniel Glazman understands:

tantek: What are the thresholds, even approximate, for implementing
           -webkit- properites (or none)?
   glazou: Unbelieveable we are having this discussion.
   Florian: Our job is to solve interoperability. We want to discuss it here,
            because that's our job.
   tantek: Help us minimize the damage.

There are two problems that have been raised: that webkit has an “IE6 style” dominance over mobile, and that developers are making matters worse.

Time for action

The first problem is not a problem at all. It is a symptom of developer knowledge being controlled by the “latest sexy and experimental technology”. Developers are fixated on making all of those great effects that we used to have with Flash work on iPads and iPhones, and because that’s webkit only, they pay no attention to the other browsers that can use their sites. Web standards is going backwards, and it’s our fault. It’s not Apple’s, it’s not Google’s, they simply make technology available, we produce code that only targets them.

The first step is to admit that there is a problem. Look at your code. If there is a vendor prefix for any property ask yourself why you chose to use it. If there’s a good reason (like 2d transforms are cool) then look closer – have you put all of the other vendor prefixes there as well? Have you checked the syntax to make sure it’s the same (because that’s what vendor prefixes are for). One final thing is to make sure you never do it again. There’s tools to help like prefix-free and SASS and LESS CSS pre-processors all do this for you.

Do it.

Change for browsers is harder

I’ll quote directly from Remy Sharp on this one:

Browsers need to:

1. Fucking drop experimental prefixes. It’s unacceptable and a disservice to the developers working with your browser. You need to give timelines to dropping these things.
2. Non-production ready browsers should support experimental prefixes, production ready releases should not. If it’s Chrome 16 – the stable version – experimental support should not be baked in. The properties should be full available without the prefix.
3. Work with the working groups (…Apple).

I especially like item 2 here. Too many developers use dev channels as their main browser (I know I do). This is fine, but by removing prefixes from stable browser versions has the great advantage of breaking for your clients who will be on the stable channel. This will raise bugs and force developers to change their code. It works for me has never been a good excuse, and with this change it never will be.

Make some noise, Internet

None of these changes will be made if we don’t get the evangelism community back on its feet. For too long have we assumed that everything is hunky-dory now that HTML5 has ridden in and saved us from non-standard implementations. I implore you, blog about this, shout about this, tell your friends and make them review their code. Vendor prefixes are here to stay, and so are the five major browsers. You must code for all of them, all the time. Shout it from the rooftops, the only good vendor prefix, is every vendor prefix.

If you liked this, you may also like:

1. CSS3 Bookshelf
2. Why iPhone Web Apps are Still Worthwhile
3. Why CSS Multi-Columns aren’t ready for prime time

Sprintly was born out of frustration in how products are made. Joe is a business major, not CompSci like many Silicon Valley successes. The guiding principle behind Sprintly is that product is greater than the process.

No time like the present
The first major difference to most agile tracking tools is that there’s no concept of time in Sprintly. In SCRUM, we use points, but that’s still tied back to a notion of time (where it should be effort+complexity+doubt), so it’s still a developer lying to themselves. Sprintly works with the notion of features, and those features will ship when they’re done.

Sprintly has Stories, Tasks, Tests and Bugs. Stories are your general user stories, Tasks are any other tasks, Tests are for developers to write tests for their code and Bugs are bugs! Any of these can be tagged with anything. A lot of teams tag with “a release” (1.0, Cupcake, whatever) which is fine, but the release will happen when stories are done or when the team decides to release something. Sprintly isn’t there to enforce the process, just help you along the way.

The holy grail for “older” clients: e-mail integration
Everyone is allowed to be part of the process in adding stories to the backlog, favouriting a story or just looking around. There’s e-mail integration whereby emailing a specific Sprint.ly address and cc’ing a developer will create a task assigned to that developer with the content and attachments of that email. The developer can then respond via email and that will be added to the conversation. It’s awesome. I can see my clients getting involved with the agile process through this even though they may not be aware of it, helping manage the admin overhead of ticketing through e-mails. Long-term there will be ZenDesk support and potentially others depending upon “how much their API make me want to kill myself”.

Tasks can be sorted easily with the quick-sort bar which shows in-progress and backlog items. These are integrated with GitHub, but it can work with any SCM that has a post-commit hook (SVN,Perforce etc), and even those SCMs behind a firewall. Any open bugs can be modified with your commit messages, even closing or marking multiple tickets as fixed.

Dashboards for those up top
There’s a dashboard with standard drag & drop Kanban board on it. It’s a bit bare at the moment but this will be much improved in the future, including tools that allow managers to estimate better and identify overloaded developers. There’ll be a read/write API coming in January so developers will be able to do our own dashboards for stakeholders etc if we don’t want them to have access. Eventually Sprintly will give you daily digest emails and better integration with email when tasks are closed/broken.

In comparison to others, it’s got its own niche: “Jira is like bringing a thermonuclear warhead to a knife fight”, you only use 1% of it at most. Trello is similar but isn’t just for software developers, it could be used for anything so won’t be as useful in the long term.

Sprintly is currently getting loads of great feedback from users with around 35% retention rate for daily task usage creation, which is excellent for such a new product. You just have to search Twitter for Sprintly love to see how well they’re doing.

Making money right now, and opening beta in 2012
Joe talked about how important he thought it was to be making money straight away, rather than having profit as “an afterthought”. So, from January 1st 2012, Sprintly will be $9/month/seat (which is cheap compared to competitors) and it will enter open beta shortly after that.

I’m really looking forward to using Sprintly in anger at the start of next year. If you want to be part of it, get yourself on the waiting list. Thanks again to Joe for talking to us and I can’t wait to start playing.

If you liked this, you may also like:

1. Facebook Logins with Facebook Connect

In my work, I’m parsing web services all of the time. Most of the time, they’re XML, which does not make the best use of bandwidth/CPU time (compared to JSON), however, if it’s all that you’re given then you can certainly get by. I’ve been looking into ways to speed up the XML document traversal in with jQuery after the current best practice method was removed.

The basic way to find certain nodes in an XML web service is to use the .find() method. This is used heavily by the SPServices jQuery helper (which is, in general, a great library).

$(xData.responseXML).find("[nodeName='z:row']").each(function() {
// Do stuff
});

That’s absolutely fine – it’s going to find the attribute nodeName with a value of z:row. However, since jQuery 1.7, this method does not work. I raised this regression in the jQuery bug tracker and was encouraged to find a solution; another selector that worked in all browsers. Unfortunately, at the time I couldn’t come up with anything better than this:

$(xData.responseXML).find("z\\:row, row").each(function() {
// Do stuff
});

The “z\\:row” selector works in IE and Firefox, and the “row” selector works in Chrome and Safari (I’m unable to test in Opera here, sorry). This was flagged as the solution to the problem and they wouldn’t be making any fixes to the jQuery core.

After a few weeks of using this method, I noticed that the site had been slowing down, especially in IE, and I thought this new selector was the cause. So, I looked into the performance numbers using jsPerf and I raised a bug too. My first test was to see what the current solution was doing, and whether jQuery 1.7 had made things worse.
Test case: http://jsperf.com/node-vs-double-select/4

http://jsperf.com/node-vs-double-select/4

So, performance in Chrome is identical for each of the selectors (and it’s the same in Firefox and Safari) but IE drops nearly half of its operations because it has to perform that second selector.

It’s still not very high performance though, and so I looked for other solutions.

Dmethvin suggested:

Did you try the custom plugin in the ticket? If you’re having performance issues that should be much faster.

The plugin he’s referring to is this:

jQuery.fn.filterNode = function(name){
   return this.filter(function(){
      return this.nodeName === name;
   });
});

This filters content by their nodeName and compares it against the name that you gave it. The issue with this is that .filter() does not traverse down the tree, staying at the level of the set of objects that it was given. Therefore, a quick solution was this:

$(xData.responseXML).children().children().children().children().children().children().children().filterNode('z:row').each(function() {
// Do stuff
});

jsPerf Test: http://jsperf.com/node-vs-double-select/1

Wow, that’s about 50 times faster. Even IE beats Chrome when doing this operation. The simple reason is that it’s got a smaller set of objects to go through and it’s comparing a single attribute rather than parsing the text of the XML to try and find the namespaced element.

Still, I wasn’t satisfied as in order to achieve that performance, I had to know how deep I was going to be going in order to retrieve the set. So, back to the bug and another suggestion by dmethvin:

If you’re going that deep, use a filter function passed to .find(). How does that fare?

After a few attempts, a colleague of mine came up with this beauty:

$.fn.filterNode = function(name) {
      return this.find('*').filter(function() {
        return this.nodeName === name;
      });
    };

jsPerf test: http://jsperf.com/node-vs-double-select/3

Using .find(‘*’).filter() increased performance to 200x faster than the original .find(‘z:row’) selector

I mean, wow, that’s incredible. On the graph, those tiny little bits of colour are the original selectors, and those only 20% of the way up are the previous massive performance increase by using filter. It should also be noted that IE8 performance using this selector increased in jQuery 1.7 in comparison to when using jQuery 1.6.

Side-note: IE10′s javascript performance is almost equal to that of Google Chrome. In comparison, IE9 (not shown) is about half of that.

The reason for this massive increase is that it’s backed by native selectors. A .find(‘*’) will translate into element.querySelectorAll(‘*’) which is very fast when compared to doing 8 .children() calls.

Summary
Dealing with large amounts of data from web services needs to be fast. Using a simple .find() on the node name no-longer works and alternatives have been investigated. The fastest method, using a short one-line plug-in, improves performance by up to 2000% compared to the old methodology.

I’ll be notifying the SPServices group of this post, and hopefully they can improve the performance of their library.

If you liked this, you may also like:

1. Javascript Fun at London Web Standards #lwsfun
2. Node & Tell at London Web Standards #lwsnode
3. Tips and Problems when Enhancing SharePoint with JavaScript

The problem

Font rendering comparison: clockwise Chrome 16, IE10pp2, IE8, Firefox Aurora 9

This image shows the beautiful Univers font in four different browsers. Each of them are rendering the following CSS:

#univers55, #univers55bold, #univers45, #univers45bold { font-size:3em;}
#univers55 { font-family:"Univers 55", serif; }
#univers55bold { font-family: "Univers 55", serif; font-weight:bold; }
#univers45 { font-family: "Univers 45 Light", serif; }
#univers45bold { font-family: "Univers 45 Light", serif; font-weight:bold; }

Now, Univers 45 is a light-weight font, an should be a good 10 points lighter than Univers 55, you can see this in Chrome and IE8 (top-left and bottom right). In Firefox and IE10, Univers 45 looks heavier than Univers 55, and the bold version actually appears to be the same size. That just isn’t right. So I called for reinforcements: step up Paul Rouget (Mozilla) and Martin Beeby (Microsoft).

Further investigation

I raised a bug against Firefox core with a test case on jsfiddle and got some good responses. Martin and Paul both asked:

@steveworkman @paulrouget could you include the font-face code in the fiddle for Univers 55 and Univers 45 Light

So, they thought it was something to do with the way I was including the font in the CSS. So, let’s put it in and see what happens:

Font rendering comparison with the font-face rule added

The rendering appears to have corrected itself. Univers 45 and 55 are now properly weighted in Chrome, IE10 and Firefox. So, what happened? Well, Jonathan Kew sheds a little light on the problem:

Note that the @font-face rules shown in your second image are incorrect (e.g. ‘src: “Univers 55″‘ is invalid; did you mean “src: local(‘Univers 55′)”?), and as a result you’re not getting Univers at all in some of those examples, you’re getting fallback to the default sans-serif font, probably Arial. Look at the shape of the “5″, for example.

Also note that under the DirectWrite model, font families are organized differently from the old GDI model. Family names like “Univers 45 Light” are not generally used; instead, all the faces belong to a single family, with distinct font-weight values. (But I haven’t examined the Univers family to see exactly how they’re organized.)

So, yes, a little stumble over the “local(‘font-name’);” issue, but otherwise it appears to be fine. The second part where he mentions that in Windows 7, font families are organised differently, and so may be under a different name intrigued me. So, I took a look:

Univers Font Families

Univers 45 Fonts

Univers 55 Fonts

So, this is where it goes a bit fuzzy. I can address the “Univers 45 Light” font directly through font-face, but I can’t access the “Univers 55 Normal” font, though I can access the whole font family by looking for “Univers 55″. That doesn’t feel right to me, and needs more investigation. Still, I can at least get it to render the font when using font-face. So, is that it? Bug closed?

Why can’t I just use font-family?

This is the question that I want answering, and Martin has kindly volunteered to look into. Loading a local font through font-family should work in exactly the same way as @font-face and src: local(); – but in Firefox and IE 9/10 it’s not.

So, web community, do you know why this doesn’t work? Can you make it work with the test case? Please help! Leave a comment, send me a tweet or update the test case and make it work!

UPDATE 1^st November 2011:

 Jonathan Kew has responded again with some more words of wisdom for me:

The @font-face and non-@font-face cases there aren’t comparable. When you say

font-family: "Univers 55";

without the use of @font-face, you’re requesting that _font family_, which may have multiple faces with different weights. What you’ll get when you use font-weight:bold along with this depends which faces have been grouped under that family name – which may well differ between GDI and DirectWrite environments. And if there’s no “bold” face in the family, then the browser will artificially “embolden” the text. (You can tell exactly which font is really being displayed using the “font-info” add-on, btw.) I suspect you might get a true bolder face in one case and synthetic bold in the other, but that depends very much on the structure of the font families you’re using.

In the @font-face case, you’re defining your own font families (independently of how the OS or the font designer organized things), and your CSS only assigns them a single (normal-weight) face each, which means that when your styles ask for font-weight:bold, you should be getting synthetic emboldening rather than a real face with a heavier weight.

To see what faces are supposed to be available within each family, look in the Windows Fonts folder – IIRC, this should reflect the DirectWrite organization of the fonts. Do you see separate “Univers 45″ and “Univers 55″ families? What faces exist in each?

So, I looked back at the spec and re-engineered the @font-face CSS, and the non-font-face CSS. The non-font-face CSS was definitely wrong, so I updated that, but the @font-face CSS still wasn’t working. I looked at the font libraries as they are in Windows, and identified the following named structure:

• Univers 45

• Univers 45 Light
• Univers 45 Light Oblique

• Univers 55 Black
• Univers 55 Normal
• Univers 55 Oblique

Given the advice Jonathan gave me, the correct font-family should be “Univers 45″ and “Univers 55″, and the correct fonts for @font-face should be “Univers 45 Light” and “Univers 55 Normal”. That gave the following results in Firefox and IE10

Firefox Aurora 9 (left) fails to find the font, IE10 pp2 (right) finds the font

IE is finding the correct font, but Firefox isn’t and is falling back to the serif font. I used the font finder plugin to look at which fonts were being used on the page, and the answer surprised me. When loading the Univers 55 font-family, the normal weight font is titled “Univers 55 Roman”, instead of “Univers 55 Normal”, and the bold version is “Univers 75 Black”, instead of “Univers 55 Black”.

So, I took a look at the system file properties for the font, and lo-and-behold, the detailed properties were different to the name of the font:

The file name says "Normal", but the properties say "Roman"

I quickly looked to see if Firefox was looking for the title property instead of the file name, and I was right. If you’ve got the Univers font you can see the jsFiddle test case for this, otherwise, the final result is below:

With the extra @font-face rule, Aurora renders correctly like IE10

The @font-face code goes like this:

@font-face {
	font-family: MyUnivers55;
	src: local('Univers 55 Roman'), local('Univers 55 Normal');
	font-weight:normal;
}
@font-face {
	font-family: MyUnivers55;
	src: local('Univers 75 Black'), local('Univers 55 Black');
	font-weight:bold;
}
@font-face {
	font-family: MyUnivers45;
	src: local('Univers 45 Light');
	font-weight:normal;
}

It looks to me like IE and Firefox use different properties to identify fonts under Windows 7: IE looks at the name in the file system and Firefox looks at the Title attribute of the file.

Amazingly, it looks like the spec doesn’t care which one is right, and advises you to include both as different platforms use different naming conventions. What surprises me is that two browsers look for a different name on the same platform, as this could cause naming clashes; the Univers 55 Black is titled Univers 75 Black – so if there was also a Univers 75 Black titled Univers 85 Black, browsers are going to retrieve the wrong font.

So, Microsoft, Mozilla, please sort it out Who is right?

If you liked this, you may also like:

1. Why I Use Opera – A case for the browser underdog
2. Tips and Problems when Enhancing SharePoint with JavaScript
3. Best Practice Error Messages

Josh, and his mobile vs native talk, positioned this decision as an “audience/content/budget” question, which matched the conversations I’d been having with my client. At the end of his talk I said to Josh, “this would make a great flow-chart, like that one that Jessica Hische did!”, “Yeah, that’d be awesome!”, said Josh.

I’m very pleased to say, that after some delay, it’s ready for public consumption.

With a lot of help from my company and colleagues Ed Hartwell-Goose,  Fin Edridge and Simon Dring we made an interactive flow-chart to guide our clients, other industry professionals and their clients through the minefield that is choosing the platform for your app. We called it, “So, you want an app?”.

It’s still a simplification of the whole process but, in researching it, three things became abundantly clear:

1. You must know your audience – there are no exceptions to this. People use different phones for very different things. Blackberries are used by teenagers for BBM and by corporations because of it’s security and low data usage; iPhones are very high-end consumer devices; and Android phones are thought of as being for very technically minded people, but they’re also entry-level smart phones. Picking a platform without knowing what your content and its audience is a recipe for disaster.
2. Your content needs to be simple to access – all end-points on the flow-chart will need some form of content platform behind them to drive engagement, re-use and to keep the app up-to-date. If you’ve got an old CMS, you may have to build a light-weight web service to let your app access the content easily, quickly and efficiently. People use apps to get at content, and whether they’re a game or social media, your content is king.
3. You cannot do this half-heartedly – and by that I mean you’ve got to have a decent budget. Also at FOWD, Matt Gifford was joking that the £50 website was now a £75 website; apps are suffering this problem. Apps are viewed as small, simple bits of functionality that you can knock-up in a weekend; this is simply not true. Apps are often full-sized websites with the added complexity of fitting the core content onto a tiny screen, but since they look small clients think they’re easy to make and do, and are therefore cheap. Stories in the news of 14-year-olds making games in the app store top 10 aren’t helping either. Start with a 5-figure sum, and keep going upwards if you want your app to really succeed.

I also mention PhoneGap a lot in the flow-chart, and that’d because I genuinely believe it’s a great solution to the “discoverability” problem. This is where you have a mobile web site that isn’t getting enough exposure as people think of “apps” as items in the “app store”. PhoneGap fills this hole nicely, and gives you access to device hardware as a brilliant bonus. The tools are easy to use and PhoneGap Build now takes all of the hard bits of building for Blackberry and Windows Phone away.

Still, there are gray areas in the platform selection process, especially when it comes to tight budgets and enterprise apps. If there’s only one thing you take away from this tool it should be this: Content is King, know your audience and how they will use your app. The rest flows from there.

You can find the tool here: www.paconsulting.com/so-you-want-an-app – I’ll post the full poster version here when it’s completed.

Please, let me know what you think, and let me know if you use it for a client as well, share your stories and share the tool with your friends.

If you liked this, you may also like:

1. Handling iPhone App Ideas
2. Project WOW on the Google App Engine Blog
3. Sketchnotes from #LWS3D – A 50-line WebGL app

Adobe should be thrilled.

It’s now got two sets of highly skilled developers with great ideas and good products to work with. TypeKit is an obvious acquisition as it’ll be part of Adobe’s Creative Cloud offering that gives them the ability to use (and sample) a huge range of fonts across their apps.

Adobe have also promised that PhoneGap will remain open source, being donated to the Apache Software Foundation. This feels strange, as then Adobe just gets the developers at Nitobi themselves (who are obviously very good). This begs the question: why did Adobe bother with it?

Well, Adobe is a tools company – they make programs that we make other cool things with. Nitobi was also a tools company, making PhoneGap, that lots of people made cool things with. Alongside the PhoneGap framework, there were two smaller projects, PhoneGap Build and Cordova.

PhoneGap Build takes the pain out of making PhoneGap apps for multiple platforms. If you’ve ever tried to do a build for iOS, Android and Blackberry, you know it’s a world of pain and about 10GB of tools and frameworks. PhoneGap Build takes this all away from you, and is a service that Adobe can integrate into their Cloud offering.

Cordova is the stand-alone desktop equivalent of PhoneGap Build. It’s creator, Brian LeRoux, recently said:

All the cli tooling prototyped in Cordova now first class in phonegap/[ios|android]. Time to update Cordova.

I take this to mean that Cordova is back in focus, and Adobe will be actively looking to integrate it into DreamWeaver, in the same way it integrated jQuery Mobile.

We should be wary

Adobe’s track record for mergers is not great. The Macromedia merger led to a focus on Flash and Photoshop, whereas other products like DreamWeaver and Fireworks were not given the time that they deserved. Lots of people lost their jobs in that merger too and I’d hate to see that happen to the guys at Nitobi or TypeKit.

We have to watch out for rising prices and being forced to buy products that we don’t need. I can see it already: with PhoneGap integrating with DreamWeaver, the easiest way to build a PhoneGap app will be with that product or Build. Yesterday, those in the PhoneGap Build program were sent a pricing structure:

PhoneGap Pricing Announcement

I can see these prices going up, and up (and they’re not that cheap to begin with). One build a day with the free package probably isn’t enough. I hope the same doesn’t occur with TypeKit, or people will just move to one of the other services that exist (Fonts.com for example).

The other danger is that somewhere down the line, these products that many have come to rely upon will simply cease to exist. Merged so deep into Adobe’s pipeline, the one thing that made them great, their independence, is stripped from them and the revolutions that they make simply slow down and stop. With the core of PhoneGap, we’ve been promised that they’ll actually have more time for it and I hope this continues for as long as possible. What I’d hate to see is the core being neglected in favor of tools for products that I don’t want to buy.

Fingers crossed that Adobe will really make something good this time, and that their commitment to the web and web standards continues, but I won’t be holding my breath.

If you liked this, you may also like:

1. 5 Rules for a great workspace
2. Easy iPhone Applications
3. So, you want an app?