Search-friendly UI for the Adobe ColdFusion bug tracker

G'day:
It's one thing having a bleat about how dismal a UX the official ColdFusion bug tracker is, it's another thing to do something about it. I've raised all the shortfalls I've found with Adobe (the bug tracker can be used to raise bugs about itself), but given how slow to react Adobe are to deal with issues with their products that they actually care about, I don't hold out much hope that they'll do any maintenance work on the bug tracker itself.

So, anyway, I've had a complete gutsful of trying to use the thing - I use it a lot in the course of researching stuff for this blog, as well in my day to day work - so I've decided to write my own search UI for it. This was inspired by Elliott Sprehn's efforts to do the same with the old bug tracker.



I was hoping to embed the UI in this blog (it's mostly Javascript, with just one small CFML file to convert some JSON to JSONP), and whilst I got that working last night, some of the Blogspot CSS conflicted with some of the JQuery Tabs CSS, preventing the trends from rendering properly. Plus I needed to work or how to get rid of the right-hand column on that page so as to give the thing enough space. I haven't quite cracked that yet, so I'm hosting it externally at the moment.

I don't actually have access to a public-facing ColdFusion server, so I've opened an account with cfmldeveloper, and popped the code up there. This is a free service, and is not intended for production web sites, so I'm hoping this thing doesn't count as one of those. I'll check. If it does, I'll need to find a new home for it: I'm not going to pay for hosting one file...

You're welcome to use the thing if you like.  Which'd be easier for you to do if I ever get around to telling you the URL! I just needed tod o as much waffling as possible first.  Anyway... it's at http://adamcameroncoldfusion.cfmldeveloper.com/cfbugs/search.html.

Update

One of my work colleagues was using this on his mobile phone (I'll find the make/model, but it is a recent Android one), and after a while he found it crashed his browser and locked up his phone.  Unfortunately we cannot replicate this at the mo'. It might be a one off, but if anyone else encounters this, please let me know.  If I can replicate it, I can fix it.  Cheers.

This is a work in progress, and I make no apology for the distinct lack of styling: I don't care about clutter like that. It's fairly minimalistic in its functionality, as it specifically careers for how I want to search for things. But it works (as far as my testing had determined), and it's more useable than the "official" site IMO.  The things it does that the official one doesn't do is:

• It has a single, unified, free-text search input.  This searches all the significant text fields: title, description, reporter, test config.  It does not search comments or votes.
• It doesn't require one to select a CF (or CFB) version before searching.  If a specific version is not selected, it searches all versions.

Part of the exercise was to improve my Javascript skills, which are sadly lacking. I was also wanting to minimise the server-side requirement because:

1. I wanted to embed it in a blog page;
2. as an exercise to improve my JS & JQuery;
3. other than Adobe not returning JSONP when needed (which I'm fixing by proxying the requests - and responses - through a CF file which converts it to legit JSONP), I didn't actually need any server side component for this.

There's quite a lot of code involved in getting all this working... well not a huge amount, but more than I want to embed in this article.  I'm shifting all the code I write for this blog to github, and all the code for this app is publicly accessible here. If you notice anything wrong or want to know why the hell I did some of the things they way I did, please sing out.  I make no apology for the quality of the Javascript code: I suck at Javascript.


For the hell of it, I decided to play around with JQuery events in doing this, so have implemented a bunch of the logic using triggers and listeners to get stuff done, eg: the search form says "I need some results" when one presses "search", which the SearchProxy is listening out for, and after it's got some results, it declares as much, which the SearchForm is listening out for, which then renders it in the table.  I've also tried to compartmentalise as much of the logic and config as possible, as well as keeping logic that relates to what Adobe returns separate from the logic to make my UI work.  This is why there's a separate DetailExtractor.js library: if Adobe change the schema of their bug detail page, I just need to change a method in that file, instead of wading through the application to sort it out.

If you can think of any improvements I could make to it, please sing out.  Equally, my testing has only been superficial so far, so if you find any bugs... lemme know.

Righto.

--
Adam