Is anyone else tempted to put an ID on every freakin HTML element so that they are easy to reference? As I write routines to locate my elements within the div an event fired on I wonder to myself - “Just what would happen if someone whacked some extra DIV tags in this template?”.

Most of our code is PHP and we put some effort into making stuff that wont fall over for our clients. I am not used to writing code which I know will break when inevitable changes are made. But what are the alternatives? Put IDs everywhere? I’d have to generate the IDs because most of my pages are dynamic. Should I attempt to write more forgiving routines that keeping searching until I find that img tag I am looking for? This brings in issues of performance and why the hell am I spending so much time writing routines to find elements on a page that I put there in the first place, just to frickin switch an image or fade some div!?

Awhile back I likened working with Javascript to an addiction. I think that is still apt and I am starting to see that the act is also fairly futile. Maybe I am just weary from a long project but maybe I am seeing the truth of this thing. I think maybe we are all blinded by the pretty moving, pulsating, bevelled corner DIVs and not being realistic about the disproportionate effort required to get a dubious gain in usability.

If you have some suggested reading for me which may ease my pain then drop me a comment and join the illustrious crowd of Dustin Diaz and some guy named John who have commented on my blog.

A constant battle in my work is the balance between being attentive to detail and being proportionate when addressing issues in relation to the goals of the business. It is easy to spending alot of time ‘perfecting’ things whilst ignoring more pressing business issues. This is not a post advocating a lax approach to work - I pain over detail - but I acknowledge there is a line to draw.

It is easy to lose sight of what you as a member of a business unit is trying to achieve. I won’t spend any time in this post going into what a business unit’s goals should be - it will differ for every unit. What’s important is to know what the business motivations are and how your unit can impact the overall business the most.

I find its helpful to reconsider what my top priorities should be on a regular basis (let say weekly). This involves weighing the guidance you get from above, from stakeholders and those challenges that impact your work overall, your day-to-day performance and more longer term efficiencies.

Pressure to take the quick and nasty approach to tasks (often complete aesthetically and functionally but completely destructive in terms of maintenance for you and your co-workers) often looms from your own pragmatism as well as from those with a limited understanding of the challenges of development.

The real difficulty is in reconciling your own interpretation of this balance with that of others. The danger all workers is to believe that every issue that can be described is worthy of immediate attention. It is also to favour the small tasks over significant challenges that might require longer than a few hours of someone’s attention.

We’ve done some great things at my workplace over the years which has been testament to a dynamic approach to our work. I can’t say we’ve got it right everytime but I can say that we’ve embarked on some projects which have taken us out of the small-task cycle to instead expand our business to greater opportunities.

We’ve been working with YUI recently. There is plenty that is good about it - we were originally drawn to it because of its obvious amounts of documentation, examples, blog and the backing of a big, big company in Yahoo! (and their suite of javascript luminaries).

Its been quietish on the YUI front, recently however, there was a point upgrade, but I do think we over-estimated Yahoo!’s ability to keep the library bubbling along. I think there is a difference between the priority Yahoo! places on YUI when compared to dedicated library development efforts (prototype, jquery, dojo all come to mind).

The documentation in use comes fairly short of acceptable. I will try to elucidate on why because I don’t really want this post to be anything other than constructive. Afterall, YUI did end up achieving what we were after however I felt we probably ended spending too much time trying to learn the library and the quirks of its construction.

As part of the documentation an overview or survey of the library would have been great - many features we found too late and spent time retrofitting onto code we had already written. This process helped fix browser compatibility issues but ideally we would never have come across these if the prefered ways for changing styles and retrieving elements were highlighted. Further browser compatibilty issues could have been prevented with some more defensive programming within the library - there is definitely wrong input that you can put into the API which will yield js errors from within the library.

Other frustrations included examples which appeared to have their own custom additions to the library with little or no explanation eg. the DDPlayer objects in the Drag and Drop modules.

I also found the DD module had a few too many assumptions when it came to its events.

Drag events can work in a simple point mode (ie. the target is wherever the mouse pointer is) and intersect mode (events such as DragEnter, DragOver and DragOut get an array of targets which you can use to determine which you want to interact with). Intersect mode is, I believe, a preferred method because the drag item becomes the mouse cursor. This means users will expect interactions to occur with the item rather than the mouse cursor.

The problem I found was that the library did not pass me the true list of items I was over. It appears that it was caching items already found by earlier events. This was frustrating because now I need to mirror this caching in my objects and am therefore needing to peer behind the curtain to see how the library works.

Early on we found a bizarre class notation which was used in some of the YUI modules. It puzzled as to why use this over the more standard javascript approaches to defining objects (a js strength/weakness is its flexibility). It appeared to be used where you might usually use a static class or the singleton pattern in other languages.

Thankfully, only an hour after a colleague and I puzzled over this Dustin Diaz posted an article which illuminated it fully for us. The exposure of many Yahoo! staff via their blogs continues to be a compelling part of the support network for this library (and our saviour twice now!).

I think that YUI needs the continued support of Yahoo! to continue the good base that has been established. The library has clearly facilitated some great developments for Yahoo! with some very impressive product releases of late. The gains are measureable but the potential future gains from continuing to support and improve the library are also very real. Don’t do it for us - do it for your own developers. And then put it out to us