Slashdot Mirror
Bugzilla Delivered to the Desktop
sereda writes "Deskzilla released their desktop client for the Bugzilla bug tracking system today. The Deskzilla system promises to deliver features for greater productivity and improved working environment for the users of Bugzilla." There are also a few screenshots posted on their site.
I thought we were moving away from fat client technology. So let me get this straight:
We went from decentralized, to centralized back to decentralized...... now back?
If bugzilla actually was a nice looking, easy to use application this probably wouldn't be necessary. Web-based is the way to go. Updating is as simple as updating once on the server -- you don't have to worry about a whole ton of client versions floating around.
Bugzilla is still one of those first-generation looking web apps that was designed (in the visual sense) by programmers, and you can tell. From my experience, most programmers are very bad at making user interfaces (myself included) and really it's a job that should be left to web designers (a subset of graphic designers). Compare bugzilla's interface to say, gmail, and you can see there is just no comparison.
Sure, the usability may be there, but if it's just awkward to use and hard on the eyes, people won't like it. Oh, and apparently they'll revert to developing old client/server style interfaces for it.
Speak before you think
Call them 'smart clients' or 'fat clients' or whatever, but AJAX or not these babies are starting to make a comeback. The proliferation of web services and simple, secure client stacks to talk to them in whatever language one happens to use (C#, VB, Python, Perl, Ruby) simply make a far better solution than spankfangled 'rich' browser apps that are, for all their coolness, still difficult hacks. The desktop is still the best environment for creating useable apps. Give me a fast, stable widget library over crappy slow spaghetti JavaScript any day.
We've been evaluating a few request/bug/issue tracking products.
The first thing I tell the vendors is that I'm not interested in client side software. I want it to be fully usable from most modern web browsers on most common OSs. This makes it accessible by any of our users without the need to install additional software on their computer (and we don't have to worry about updating it when a new version is released).
Bugzilla is already a web application. I can't fathom why would anybody waste so much time making a client version that most sane administrators wouldn't want?
Honestly, Bugzilla's web interface is awful. Sure, it does what it's supposed to, but that doesn't negate the fact that it's confusing and intimidating to many users. Personally, I could see a desktop front end being great for an in-house help desk. The backend's already there and solid, this just provides (what appears to be) a friendlier interface.
For ease of use and offline usage
Personally I like the appearance of this application and I think it would be _MUCH_ easier to use than the actual web interface - and the offline usage ability is a wonderful feature
It's nice that they offer free copies to members of established OSS projects
if they get $99/copy for this i should write one for trac!
If you cannot keep politics out of your moderation remove yourself from the Mod Lottery.. NOW!
Several comments in this thread point out that web-based interfaces are mandatory for a bug tracking system, which is absolutely true. If you *require* a client to use the system, well, there go half of your potential users.
:)
But that's not the point here. It looks like this product just connects to an existing Bugzilla database, so you get to keep all of the web based access you crave, but your frequent users can augment that with a rich client interface.
If you work with bugzilla all the time, there are features that a web interface just can't give you. The biggest one: being able to work with Bugzilla offline (bug database behind a firewall, for instance). The ability to do bug triage from a coffee shop instead of the office could easily justify the price tag.
Of course, it has to acutally install and run first.
Lets see, first came the client/server applications and all was well! Well, not exactly first, but for the purpose of this discussion I'll say client/server came first. Companies grew faster than tech services could scale-out servers and management shouted "Oh no! This monolithic application will not scale!"
Then came the browser with all the promises of client side scripting and the developers shouted "I can do anything in a browser using sweet javascript code that you old client/server developers can do in a thick client! It will scale to tens of thousands!!"
2 years go by as developers embed thousands of lines of sweet javascript code to accomplish what you can do in a thick client in maybe 100 lines (I'm exaggerating here).
Management shouts "Oh no, my thin web application is taking 10 seconds to load as it parses 50K lines of sweet (now a spaghetti mess) javascript code!"
The new age of developer shouts "I can accomplish everything your antiquated web application can do, using XML web services while still providing a thin client with increased functionality in half the development time! Not to mention the application will be self updating so you will never need to support older versions of the application!"
And managment shouts "WTF!"