The principles of Schedules, Work Based Structures, Resources, Effort, Duration… I understand.

But Microsoft Project… Baffles me every time. It seems to work against my logic. I’m stuck with it at work because I’m on Windows, the ‘real’ project managers in our team have fancy Macbooks with OmniPlan, which I can only imagine is more intuitive. I had given up on using it for anything other than a very bloated hierarchical list editor. Gantt charts, levelling, resource allocation, estimates and due dates were all not working the way I wanted. Until I read this in a series of articles at Tech Republic on MS Project:

Duration = Work/assignment Units

And the penny dropped. A lot of the behaviour of MS Project makes sense when you understand that the above formula remains true and unalterable.
The program still annoys me in the way it tries to think for me and automates some of its calculations while you are entering info. (hint: Enter your tasks and durations first, then do your resource allocation) And I am not about to call myself a Project Manager. But I am one step closer to understanding this tool and actually getting a few things done with it instead of spending the day cursing.

I’ve seen Abraham Lincoln’s quote, “If I had six hours to chop down a tree, I’d spend the first four hours sharpening the axe” used in the context of software programmers’ obsession with refining their tools instead of getting on with the job, but thinking about it, the tree metaphor doesn’t really apply, we’re not cutting down trees, we are building unique structures. The point is, choosing tools can be a distraction, and that remains true.

There is large overlap in features and capabilities across the available JavaScript libraries, and the good ones all perform as well as each other. In other words they can all do the job, so just choose one and get on with it. But despite their similar capabilities, they all work in different ways, so to jump from one to another has the friction of a change in direction or a new learning curve, which can only detract and add strain to the development process.

The only way you are going to get the most out of an open source code library is to use it, and learn about it. Use it some more and get to know it better. Use it a lot and know it backwards. A JavaScript library is not a drag and drop or copy and paste replacement for coding. It will not make up for your lack of ability or willingness to understand JavaScript programming paradigms.

If there’s any advice it’s make a choice and stick to it. You definitely need some help ironing out the differences between browsers and at least standardising your access to the DOM and Events. The light weight of most libraries’ core files make this worthwhile. The rest is subjective. Here are some of the issues I have encountered.

Administrative or Expressive?

If there is one major differentiator between the available JavaScript libraries, it’s whether they ship with a standard set of UI widgets, or at least a standard capability of making widgets and skinning them so they look like they come from the same family. This split seems to reflect the different purposes of libraries, and their possible developer (functional) or designer (visual) bias. So depending on the needs of your project, and the people who will be coding with the library…

For building the interface to a CMS or other application-type interface, that should follow well established interface design patterns, a good component or widget library is essential. You need your datagrid and tabs and layout and menus to look like they belong together. If this is part of your requirement, limit your selection to YUI, Dojo or ExtJS. Application developers and programmers from a more structured server-side background may feel more at home with these.

If your use is less administrative, and you are looking for a library to support a tactile and dynamic user experience, within the context of a branded or expressively designed site that doesn’t use standard UI widgets, consider MooTools or JQuery. The learning curve on these is not as steep, and implementation is often simpler. These libraries have more traction in visual design communities, and in my experience, visual designers who are willing to code, and client side web developers will be comfortable and familiar with these.

Open source?

Licensing can be an issue. As far as I know, all bar one of the libraries I mentioned above have a liberal open source license, which mean you can use it freely wherever you like. ExtJS is more restrictive. You can use it for free under GPL, which means the project you use it for must also be GPL. If licensing their bespoke CMS as open source winds your client up the wrong way, and you still want to use ExtJS, there is a paid option.

Personality

A little personality goes a long way, and this may be the deciding factor for you. Do you feel in your heart you can get along with this library or that one. Have you fallen in love yet? A library’s community, its inventors or corporate connections have a huge sway in the emotional connection you as a developer/person will make. And lets face it, you’re going to be spending a lot of hours together. Each library has its community of developers that hang around the forums to help others and sing the praises of their choice in JavaScript library. Sometimes the praise is evangelical, sometimes it is dismissive and arrogant. But the technical help among these communities is almost always useful. Some libraries are organisationally structured to allow more direct community contribution to the project codebase, and embrace the Bazaar more than the Cathedral. The others, while releasing code as open source and accepting community input, are structured more centrally around a single person/genius inventor or an internal team.

And the winner is…

The developer. You can only win with the choices you have out there. In case you are wondering why I have not mentioned Prototype, or any other popular libraries here. That’s because I’ve never used them, or if I did, I didn’t get on with them well enough to comment.