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. End of an era
2. v3.03 and The Business
3. v3.04 and upcoming development

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. Is WordPress putting whitespace in your XML? Here’s how to fix it
2. Javascript Fun at London Web Standards #lwsfun
3. Browser Wars: The SlickSpeed Test

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. The Future of Web Typography with Richard Rutter (LWS Future)
3. Easy Semantic Forms with CSS

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. Easy iPhone Applications
3. Why iPhone Web Apps are Still Worthwhile

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. Executive Summary: Flash vs HTML5
2. Easy iPhone Applications
3. 5 Rules for a great workspace

Carlos Ulloa of Brighton-based HelloEnjoy showed off two demos that he made using Three.js and WebGL. The first was HelloRacer, an interactive look at the 2010 Ferrari F1 car that you can even drive and do handbrake turns in. The second demo got it premiere at LWS, an interactive music video for Ellie Goulding’s “Lights”. Honestly, it was extremely cool, on a Ro.me “3 dreams of black” scale. It’ll appear at the linked URL in the next week or so. There’s a great Q&A session on the London Web Standards blog of the event for more detail on how they did it.

Ilmari Heikkenen showed the gathered crowd how to make a basic WebGL app using Three.js in about 50 lines. He showed off all of the components that you need: a renderer, scene, camera, mesh and lights (and shadows). He went into more depth about vertex shaders and fragment shaders, the GPU effects that make everything look a lot more real.

Ilmari gave examples of a few uses, including games, 3D bar charts and scatter graphs. He then started animating all of these, including a 10,000 point scattergraph that moved in real-time. Finally, he demonstrated a loader for Collada meshes (supported by Maya) and brought in a monster that with a few lines of code started walking around the screen.

Overall, it was a great introduction to the subject, one worth a lot more of your time.

Ilmari’s slides can be found on his blog.

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. So, you want an app?

You see the site in action over at wow.metoffice.gov.uk

If you liked this, you may also like:

1. Facebook Platform – a thought
2. HTML5 in your blog
3. SteveWorkman.com Launches

I’ve got this great idea for an app…… what do you think?

I run the mobile development team at my employer, a role that I really enjoy and feel privileged to be doing. I get to work with cutting edge technology, forward-thinking clients and brilliant developers and user experience experts. There’s always a flip side, and for this role it is filtering out the bad ideas from the good ones.

The process
I have a simple process for capturing and evaluating ideas: listen, write it down and do a quick estimate of effort and benefits. If the benefits do not heavily outweigh the effort, say thank you and move on.

That’s it in a nutshell, but it’s a bit more complicated than that. Lets step through the process.

Ideas
An idea will come from one of two sources:

1. The media, or
2. A personal need

Ideas based in the media
The request goes a bit like this:

Hi Steve, have you seen this article about this cool iPhone/android app? Well, I think we could do something similar (for the other platform)! It’d be great for [publicity/marketing/a demo/this client I have/making lots of money]. What do you think?

If I get a request like this alarm bells start ringing in my head. Clearly, someone else has already done this, and therefore has 3-6 months development time ahead if we were to start developing a rival app. Requests based on the media tend to be for porting android apps to iOS, and unless it’s an android-only developer, there’s likely to be a good reason why there’s no iOS version. Take the BBC 3G strength meter app. It’s only on android and I was asked if we could do an iPhone version. The answer was simply “no”. The long answer was, “do you really think the BBC wouldn’t have tried to make an iOS version? Of course they would have. It’s not possible. iOS doesn’t allow you that level of access to the phone’s hardware.”

The only time that an idea from the media would meet the benefits/effort threshold is if there was a direct client opportunity and the idea came from demand, rather than porting an app. Augmented Reality was a big buzz topic a few years ago, but finding a useful application for it for a client was a challenge, hence I didn’t make an AR app.

So, unless there’s a direct need for an app, it’ll go into my big black book of ideas for a rainy day.

Ideas from personal need
The best ideas for apps come from genuine need. You can quote me on that. When someone comes up to me and says,

I’ve got this problem, I need to …… I thought it could work as an app?

I listen and I’m always much more hopeful. If someone has a need, then you can bet that other people have that need too. It may be something like large manuals or reference information for a specific sport e.g. SCUBA diving, or an app that collects a lot of information together and displays it usefully. These are the kinds of apps that I like people to talk to me about, and that straight away get to the top of the to-do list.

Which app to do first?
This is a tricky question, but it should be one that you can answer. Follow this formula:

Potential audience * USP / effort

1. Your potential audience, on a scale of 1-10 where 1 is “just you” and 10 is “every phone owner”
2. USP (Unique Selling Point) on a scale of 1-10 where 1 is “It’s a twitter app” and 10 is “best idea ever, never been done before, it’ll revolutionise the way we live”
3. Effort is a 1-10 scale of how long it’ll take you to make the USP work (1 is short time, 10 is long time). It is not how long until you can get a first release out, it is how much effort will it take to create the hook for users.

So, for a basic twitter app, you will end up with a formula of 8*1/4 = 2. For an app for flight controllers, you’d get 3*7/7 = 3, so you’d be better-off spending your time on the flight controllers app. Either way, they’re both not very high scores, so you may want to keep looking for better ideas.

Yes, I know it’s a contrived example, and that it won’t apply in every case, but give it a go if you are given a few ideas and don’t know which one to do.

What next?
Once you’ve got your good idea, don’t ignore any other ideas that come your way. Keep writing them down, keep doing the analysis, and you’ll always have an idea in your pocket to fall back upon. You may have so many good ideas that you’ll have to hire some more developers to work on more apps, and that is a very good problem to have.

If you liked this, you may also like:

1. So, you want an app?
2. Why iPhone Web Apps are Still Worthwhile
3. Easy iPhone Applications

Very quickly, you have to start looking at alternatives to complex data views. These days, the go-to technology is JavaScript, which is very powerful and can allow developers to access almost every SharePoint function through web services. However, this functionality comes at the cost of accessibility. So, the first piece of advice: if you can avoid using JavaScript, do so because otherwise the site won’t be accessible. See these links for why accessibility is a good thing.

Unfortunately, SharePoint is so limited that often a JavaScript is the only way to add functionality in or to correct formatting. In this case, use of simple SPD functions and <noscript> tags can keep your content accessible, allowing you to progressively enhance the user’s experience on top.

The final hurdle to cross before you can create great JavaScript-based interfaces in SharePoint is IE.

Internet Explorer, especially IE6, has appalling developer tools for JavaScript debugging. There’s no console, inspector, breakpoint facility, no nothing. It’s almost impossible to debug your problems because they all manifest themselves as runtime errors on some arbitrary line on the page.

The best way that you can debug JavaScript in IE, is with Google Chrome. It doesn’t sound right, but I promise it’s the easiest way to make your code work. Both Chrome’s Web Inspector and Firefox’s Firebug work very well with SharePoint, though my personal preference is for Chrome as it works better with Windows’ NTLM authentication system (it doesn’t ask you for your login details, just takes them from Windows). They allow you to check and validate your code so that it works well and runs as expected. You should be able to achieve this in half the time that you would if you were just developing for IE, using alerts to work out what’s going wrong.

There’s another benefit for working this way around: your code will work on standards-compliant browsers, and any that come along in the future. This is always a good thing as you don’t know when the organisation will roll out IE8/9 to its users, nor can you always guarantee that a user will be using a IE. It’s important that sites are ready for these changes and best-practice development is maintained.

In summary, if you have to use JavaScript, ensure the page content will work without it. If you are doing any major development work, do it in Chrome and reap the benefits of its debugger, then make it work in IE.

If you liked this, you may also like:

1. Improving Javascript XML Node Finding Performance by 2000%
2. Problems loading local fonts with font-family
3. Chrome or Opera

It’s a sad time for me as www.sheffieldhockey.com was my first big web project. Over the four years I was at uni, I re-wrote it three times. As I learnt more and more about programming, CSS, MVC and HTML, I discovered whole new things I could do. It was one of the first sites I’d seen that used Facebook to log people in, well before Facebook had a proper mechanism for allowing you to do that, and people loved it. It was my playground and now it is no more.

However, all is not lost. I’ve set up http://sheffieldhockey.steveworkman.com to serve as a lasting memory of an awesome site. Joe, the new club captain, may still want to carry on with the site, get one of the freshers to, well, freshen it up. I’m hopeful that my gift to the club may continue to be used in some capacity, but, for now, it’s gone.

If you liked this, you may also like:

1. USEv4 is Done!
2. The Facebook Platform
3. Getting a Facebook Login working on your application