Articles Tagged ‘JavaScript’

Tips and Problems when Enhancing SharePoint with JavaScript

If you’ve developed for Microsoft’s SharePoint before (I’m talking about 2007 here, but this applies to WSS2 and 2010 as well) , then you’ll know that you can reach the limits of it’s functionality very quickly. This is a big problem if you’re making a zero-code solution, i.e. you have no access to Visual Studio and can’t create web parts. This is more common than you’d think, especially in large organisations that use SharePoint extensively. For this, the only choice is to use SharePoint Designer 2007 (SPD), but it’s not pleasant because, frankly, SPD sucks. I’ve not found a program that crashes as much as SPD, or that performs so poorly when presented with the most basic tasks. If you make a page that is too complex, has too many web parts, large data sources or lots of conditionals, connections and filters, it can take anywhere up to 20 minutes to perform a single action.

SharePoint crash

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.

Javascript Fun at London Web Standards #lwsfun

Last night was London Web Standards‘ April 2011 event, Fun with JavaScript. Speakers Rob Hawkes of Mozilla and Seb Lee-Delisle of Plug-in Media came to talk about all the fun stuff you can do with JavaScript, canvas, and HTML5. Sketchnotes for both talks are below.

We were also joined by a man showing us a quick look at Dreamweaver CS5.5 with it’s new HTML5 features. Unfortunately, the software had a few bugs which showed up in the talk, and after being burned by the very expensive adobe software for years, the crowd didn’t take to the UI very well, which wasn’t helped by a low-res projector. Still, it looks like a big improvement over the old version, but I’ll still use Coda when on my Mac.

Rob Hawkes: multiplayer gaming in HTML5

Sketchnotes of Rob Hawkes' talk Multiplayer Gaming with HTML5

Sketchnotes of Rob Hawkes' talk Multiplayer Gaming with HTML5

Rob is a canvas and animation guru. He’s not far out of uni and has a book out this month! He gave a new talk on multiplayer gaming, and how it was possible in HTML5.

Basically: Canvas + Websockets + a server (rob recommended Node.js) = multiplayer gaming on the web.

Rob didn’t go into much detail as to how to do all this, just talked us through the principles of what you should be doing, what you should avoid, how to prevent cheating and simple tricks to improve performance.

At the end, Rob proposed a HTML5 gaming knowledge repository, a community wiki and tutorial site, so that it’s easier for people to learn. Someone at the event will take him up on the offer, so look forward to more things soon!

Rob has a book on Foundation HTML5 Canvas: Gaming and Entertainment for pre-order on Amazon.co.uk

Seb Lee-Delisle: Fun with JavaScript

Sketchnotes for Creative JS visual effects – Seb Lee-Delisle

Sketchnotes for Creative JS visual effects – Seb Lee-Delisle

Seb is a flash guy, but also a JavaScript guy and a graphics guy. He’s so multi-talented that he doesn’t know what exactly he does any more.

Seb has won two BAFTAs (thanks for correcting me Seb!) for some of his BBC kids web sites. He personally runs a javascript graphics workshop and took us through a few things that we’d do if we went on it.

He started with particles, showing us how to do basic (pseudo) physics in canvas and JavaScript. He then broke out his large array of particle demos, showing how complex effects can be produced with very simple code.

Seb then talked about performance, and how bad canvas is at the moment. DOM elements with hardware acceleration is easily twice as fast as canvas, especially on the iPad. The iPad’s saving grace is its touch screen, which can take 11 touch points (just in case we grow an extra finger). Seb created a simple asteroids game using touch events for input.

Seb finally talked about 3D and how using libraries was a great way to go from 2d to 3D very simply. He recommended Unity as a game engine and framework of choice, and they’re building HTML5 renderers on top of their regular OpenGL and DirectX methods. Exciting stuff indeed.

Unique IDs in AJAX Web Applications

This week, Roger Johansson of 456 Berea Street posted about unique IDs in web applications. I read this and thought, “you’re right, they should be unique, but what if you’ve got an AJAX repeater?” By this I mean when I’m loading functional parts of my application that I’ll be referencing with JavaScript again, do I have to maintain a unique ID? Surely it knows what I added last or how to make them into an array?

Read more…

Patching iUI

Recently, I’ve been working on an iPhone web app for my employer (internal, so I can’t share). I based the design and architecture around the iUI library by Joel Hewitt, which became an overnight de-facto standard for web apps. However, after a lot of playing with it and turning it inside out, I’ve found there are a number of problems which have not yet been fixed.

For example; I want to run an AJAX search on a page one menu down my site tree. I found that this wasn’t possible as subsequent javascript code was not evaluated by Safari. There’s other things too, like any iPhone/iPod application link not working, having to press any link that goes to “_self” twice and having a slide animation that stutters more than a broken record.

I am happy to say that fixes exist for all but the last item, and I have put them all into a javascript file, which can be found at the end of this post.

However, I do not believe that this is the solution to iUI’s problems. I feel that a complete re-write in a standardised library like jQuery is the solution. Who knows, I may even find time to write it 😉

So, here’s the file: iui.patched.js

Steve