Why I Can’t Stand Using Cerb3
Community, Debate September 4th, 2008
posted by Jeff StandenCerb3 was a bumpy patch in the rear-facing road of Cerberus Helpdesk updates. It’s a point where we had already realized that Cerb2 was making many daily tasks more difficult than necessary, but in finding a solution with that knowledge we made the major mistake of trying to introduce new ideas without removing any old ones. That rookie mistake was driven by a false sense of loyalty to the most conservative (and vocal) segment of our community who, in hindsight, will be “appalled” by the prospect of having to retrain their users regardless of our thinking. The final result of Cerb3 under those conditions, completely by our own hand, and in present agreement with the outcry at the time, came off as “gimmicky”. At the Cerb3 release, several long-term users said the project now felt like a “Frankenstein mix of ideas plucked from different places”.
Before I’ve completely assassinated Cerb3’s character, let me temper the above with a few facts: (1) I’ve been the lead designer on every version of Cerberus Helpdesk since the beginning in Jan 2002; (2) while pushing Cerb3 after its release, we did genuinely feel it was the best collection of answers we had to offer at the time; and (3) the simple and elegant solutions we’ve discovered since wouldn’t be nearly as poignant without Cerb3’s “com-mutiny” and our first real prospect of losing the community’s trust by trying to please everyone and ultimately pleasing no one.
I say this to establish the fundamental point about Cerb4: we knew the most important thing for the long-term survivability of the project was to return the focus to our original purpose — giving teams a low-hassle tool specifically built to share high-volume webmail — and that our best option for accomplishing that goal was to remove much more than we added. Instead of risking another Frankenstein, we started over and individually crafted each feature to support a singular, consistent vision for the project. For that reason, it’s a huge mistake to look at Cerb4 and compare it to earlier versions in terms of feature parity.
When Cerb3 reigned we knew about the “Frankenstein Factor”, but it was still just a disclaimer to say there were better ways to do everything. We hadn’t explored what those better ways were; and because of that, it was only ideologically painful to work with the system — as in, “there has to be a better way”.
What the Cerb4 rewrite has done to our marketing is interesting; it’s difficult for me to sit down and make a list of “killer” features in Cerb4, because, like any good tool, I’m not thinking about the steps required to use it — it just naturally extends my own capabilities. The fact the software gets out of the way *is* the killer feature.
That’s been our marketing challenge since the rewrite has started producing results: if you’re a user who hasn’t upgraded, how do we convince you it’s worth upgrading if we can’t be any more specific than “better workflow”? It turns out we have an endless litany of examples, and all we have to do to uncover them is to park ourselves in front of Cerb3 and try to use it again. With our inefficiency-forgiving habits broken, a trip back to Cerb3 land is like an HBO Late Night Comedy special — “what were the *beepers* thinking who designed this *beeping* thing?”
I could go into the striking differences for me — “peek”, inbox filters, buckets, Overview, Dispatch — but I promise you that the most effective way to evaluate, and benefit from, the improvements in Cerb4 for yourself is to use it long enough that your existing habitual bias starts to waver.
-Jeff@WGM
Hi Jeff,
good to hear this statement. How far is the importer for cerb3 to cerb4. Last thing I read is that it still doesn’t do comments? This is a killer-feature and we are still running on 3.6 therefore.
Any news when the importer will finally be fully functional?
thanks
Philipp
Hey Philipp!
Our original process for migrating from Cerb3 to Cerb4 involved dumping all the tickets back to RFC-2822 e-mail and importing them through Cerb4’s parser. That’s what made comments difficult. It actually made a lot of things more difficult than they needed to be — the only thing it saved time on was the fact the parser existed and could handle normal e-mail.
Dan@WGM and I have spent a lot of time over the past couple weeks creating a universal import/export (ImpEx) system for Cerb4 that works with XML. Tickets are self-contained and include all meta, messages, attachments, comments, etc. There’s an exporter from Cerb3, and even one directly from Cerb2 to save time.
I plan to write a lot more about this on both the wiki and the blog. The only thing we really need to polish for the ImpEx is fringe cases where some systems (including Cerb2) allowed abnormal e-mail addresses into the database that won’t pass Cerb4s validation (e-mail addresses with spaces and no quotes). These are rare, and won’t stop an import, but they will prevent a handful of oddball tickets from importing.
Since it may take me a little longer than I’d like to get to that blog post, you can go ahead and take a look through the new ImpEx tool from SVN here:
http://svn.webgroupmedia.com/cerb4-impex-java/trunk/
We’ve tested it with million+ ticket helpdesks without any major issues.
Thanks for the comment!
wow, that’s great news. I will test it!
Thanks
Philipp
The SVN copy includes the source and binaries. The quickest way to get it to work is:
1) Copy one of the sample config files and plug in your info.
2) java -jar Cerb4-ImpEx.jar [/path/to/config]
You could also move the binaries to a separate location, which is what we’d do on a distribution. To do that simply copy Cerb4-ImpEx.jar, your config file, and the “drivers” and “libs” directories.
(Note for posterity: The precompiled JARs should work with JRE 1.5+ — if you end up wanting to build them yourselves, the /trunk checkout should import as a workspace into Eclipse (Ganymede). There’s an ANT build script to make the JARs.)
I should also mention that the latest Cerb4 can import anything the ImpEx can export (KB, tickets, orgs, contacts, etc). Be sure to SVN update your Cerb4, then copy the subdirectories from your ImpEx “output/” into /cerb4/storage/import/new. Just include the subdirectories, so you end up with something like: /cerb4/storage/import/new/02-tickets-000123/*
Once you’ve done that, make sure your “Background Importer” scheduled task is enabled from Helpdesk Config->Scheduler. That will take care of importing your content, and it won’t monopolize your POP3/parser jobs like the original import process.
I’d be happy to answer any questions that pop up. Hopefully I’ll get some time this weekend to write up some proper docs. :)
We did not upgrade from 2.x to 3.x because upon reviewing Cerberus 3.x it was too different and did not meet our requirements, especially workflow and procedures that our business depended on.
So we were stuck with 2.x
We would consider to review and possibly upgrade to 4.x if
- there will be a clear, error-free, upgrade path / instructions and support because we can not afford to lose tickets, we need to be able to review past customers tickets
- we can get an evaluation license for testing on our server, so that we can test e-mail handling for various domains and addresses to make sure everything would work like it works for us in Version 2.x
Hey Melanie!
With the Import/Export (ImpEx) tool I was talking about above, you’ll have a direct upgrade path from Cerb2 to Cerb4 (you can skip Cerb3 entirely). You won’t lose any tickets.
We can definitely set you up with a license for evaluation. When you install Cerb4 it’ll prompt you to send in a feedback form for a free 3 worker license. That’s fully functional outside the worker limit.
Thanks for your comment!
-Jeff
Hi Jeff,
I’m interested in building a custom exporter for Trouble Ticket Express MySQL edition.
The wiki article at http://wiki.cerb4.com/wiki/Building_a_New_Exporter describes the process, but only partially. (At this stage there is only an example for importing a worker via an xml file).
How would I go about importing a complete ticket (i.e. e-mail thread from TTX) via xml.
I’m more than happy to code the exporter myself, but I will need to know the xml format that Cerberus requires.
Thanks a mil,
Sam
Hi Sam!
I’ll go ahead and flesh out that wiki page for you now that we’ve finalized the format for workers, orgs, contacts, and tickets/messages/comments/attachments.
Take another look at the page you linked in 1-2 hours. ;)
Thanks!
-Jeff
Alright, Sam. ;)
Since I knew there were some people anxious to write new exporters, I just spent a couple hours writing documentation for ImpEx. I’m currently documenting the XML format for all the supported objects.
Here’s what we have so far:
http://wiki.cerb4.com/wiki/ImpEx
http://wiki.cerb4.com/wiki/ImpEx:WritingDrivers (super detailed)
http://wiki.cerb4.com/wiki/ImpEx:OutputXML
Thanks!
-Jeff