First off, thanks for supporting Cerberus Helpdesk development by previously purchasing a version 3.0 license! Contributions like yours have allowed us to push forward full-time for over six years.

Over those six years, the project has gone through some big changes while striving to stay agile for a growing community. The early community was mostly made up of techies; but over the past few years we’ve had increasing interest from people in all industries who are still taking the plunge to web-based e-mail from POP3/IMAP mailboxes and desktop e-mail clients.

We’ve never been the type of project to increase major versions for marketing reasons. We increment our major version when we feel the project and its concepts are going through a fundamental metamorphosis that, despite increasing version numbers, doesn’t require us to stay trapped by a compatibility with the inefficiencies and missteps of the past.

The latest metamorphosis has been version 4.0, which is our answer to the question “What would you do differently if you could start over with what you know today?”.

At first glance you’ll probably notice things are different (and slimmer). Please don’t let this deter you, as it’s part of the process. 4.0 places its major emphasis on customization, which means plug-ins can add or change functionality based on the needs of specific groups. It means you aren’t boxed in by a “one-size-fits-all” mentality. This clean slate allows you to add, build or share the pieces you need without having to deal with the bloat of the pieces you don’t.

For example, at WebGroup Media we’ve added custom tools to our helpdesk to manage our forums, CRM opportunities and product licensing. We’re able to quickly know more about our specific customers when looking at a ticket without cluttering the project for everyone else. A big part of 4.0 development is going to be building and fostering the development of similar tools for various groups. For this reason, we want to keep the core (shared) project as slim as possible.

If you feel your past investment in our project has been worthwhile, please consider upgrading to 4.0 and supporting this effort. As a 3.0 license owner you’ll receive a 50% discount. Don’t wait around for the perfect project to suddenly materialize without your input, stop by the forums and tell us what your ideal helpdesk should do.

We’ve been asking you guys what you feel about the new $50 per worker pricing ($25 per worker on upgrades) since we made the switch. The change to per worker pricing has freed us from having to hold functionality hostage, since we really feel every feature is helpful to organizations of all sizes (heck, I use most of them on my own webmail!) So far the reception has been positive, but with a few lingering issues to work out.

The main remaining contention is about where the cutoff should be for unlimited workers. Many people feel that the cutoff being 50 workers is too high. It’s true that the average number of workers on licenses since we’ve been asking has been quite a bit less than 50. We can also sympathize with organizations that have a lot of community volunteer or part-time workers.

Looking at the data from recent orders, we feel a better cutoff for an unlimited license is probably around 20 workers. That still gives a good discount to smaller teams while keeping the price reasonable for larger teams. Unlimited workers after 20, coupled with a small business or upgrade discount, reduces the unlimited worker license by up to 60%.

We’ve decided to trial offering the unlimited license at 20 workers through April 15^th 2008. The 50% discount for 2.0 and 3.0 license upgrades still applies as well. That’s $995 for unlimited workers on new purchases or $497 for an upgrade from 3.0. Both prices include all version 4.0 updates.

If you already purchased or upgraded to 4.0 and paid for more than 20 workers, contact us and we’ll upgrade you to an unlimited license at no cost. If you paid for less than 20 workers, we’d be happy to upgrade you to an unlimited license using your initial purchase price as a discount.

Thanks for the constant stream of candid feedback!

Here’s a quick progress report on the top three responses (by a huge margin) from the “Which 4.0 major feature do you want WGM to focus on next?” poll in the community voting booth.

• Time Tracking: I just finished a big Configuration area cleanup to allow plugins to contribute new tabs. Time Tracking needed its own little setup area. Beyond that, this is a really straight forward plugin/feature. In Devblocks-speak, we just need to create the DAO/Model/AbstractView for time slips and allow them to link to Organizations, Tickets or Calls like Tasks work.
• Support Center Revamp: The “Communities” area was finally moved into Configuration area since it’s an administrator feature. The Configuration area cleanup also made Community Tools a lot easier to configure and install than they were on the old communities page. The next steps here will be combining the Knowledgebase (KB) and Support Center (SC) plugins to reduce setup confusion, and to allow the SC to show KB articles. We’ll likely bring back KB categories, but unlike Cerb3 you’ll be able to have multiple KBs. Workers will be able to manage the KB from the worker GUI instead of having to create and use editor accounts on the KB community tools. We’ll also finish up the documentation for making new SC themes.
• Translations: We finally sorted out the Western Latin special character issues that have been plaguing Cerb4. This was a big step to getting translations going, since externalizing the strings would have been pointless if characters like umlauts wouldn’t display properly. Now we just need to move the rest of the strings (i.e. words, sentences) out of the templates and into the strings.xml files in each plugin.I’ve been thinking about creating a simple translation plugin that translators can use to edit the strings.xml files from the GUI with side-by-side comparison of English and the destination language. We’re using the TMX standard for localization, and Cerb can take care of formatting everything properly without translators having to edit XML across a dozen different plugins. A built-in TMX editor could also give translators a list of only new strings, which would be a big time saver versus scouring files.

It’s not too late to add your feedback to the poll. Stop by the Community Voting Booth in the forums.

We started Cerb4 with the idea of supporting MySQL, PostgreSQL, MSSQL, Oracle, etc. As development has progressed, we’ve hit several issues where our database functionality needs won’t abstract or overlap effectively.

The major benefits of Cerb4 standardizing on MySQL 4.1+:

• Fulltext searching: Right now we’re implementing database-driven functionality where our supported platforms (MySQL and PostgreSQL, at the moment) overlap. On text searching, this currently centers on basic SQL-92 “LIKE” syntax searches. The downsides here are pretty obvious; there’s no boolean support, wildcard searching is grossly inefficient when looking for multiple words and the order of keywords must be precise. The ideal situation is to have the full feature set of MySQL’s FULLTEXT index type, which, while not perfect, opens up a more Google-like syntax that’s much more useful than what we’re currently doing.
• Internationalization: It’s much faster and cleaner to be able to depend on MySQL’s encodings and multibyte behavior than to abstract how each platform approaches i18n. MySQL has its own tricks too, like “SET NAMES utf-8;” being issued per connection to ensure the client and server are handling multibyte encoding the same way.
• Sub-queries/Foreign Keys/Cascades/Joins: With day-to-day functionality we haven’t had much of a problem avoiding sub-queries or foreign keys for MySQL 3.23’s benefit. However, to support this rather old version of MySQL we lose the ability to be efficient in database patches and maintenance tasks. While not exclusive benefits of MySQL 4.1+, cascaded deletes on foreign keys, sub-queries and joins in UPDATE/DELETE would make patching and maintenance much more efficient. We end up with a lot of N+1 queries presently, where if ‘N’ is based on a table like ‘ticket’ it may end up around 1 million repeats of a query. This ends up clashing with the default PHP execution time of 30 seconds (which is fine for rendering a typical page, and an eternal pain for upgrading/maintenance tasks in PHP when the execution time can’t be overloaded at script level).
• Transactions: Another needless concession to MySQL 3.23, without transactions we have a much harder time making sure partial data isn’t written to the database — especially while parsing tickets. Transactions ensure everything is successful or none of the changes are applied. We’ve always needed this, and MySQL 3.23 support has always been in the way.

All of these issues contribute to the speed of development.

That’s the case to be made on our end. Making this change would unstick several big feature requests, that are far more important to us than the marketing bulletin of ‘database independence’. We’d really like to hear from you if this change would be a problem for you.

Please take a moment to vote on this issue in the forums.

I think we’ve solved most of the issues with special characters (such as umlauts) in Western, single-byte languages for Cerb4.

Cerb4 Build: 563

Due to a few lingering obstacles for full internationalization, we’re still using ISO-8859-1 encoding. That should completely cover English, German, Spanish, Italian, Norwegian, Icelandic, Swedish and others. It should mostly cover Dutch and French (with the exception of a few rare characters).

Warning! Dear Non-Techie friends, the rest of this post gets a bit nerdy.

The recent issues were caused by a couple things:

• META/Content-Type: We were a bit over-eager and had the browser using Unicode (UTF-8) encoding while the data was still Western Latin (ISO-8859-1). Display-wise this is entirely fine because of backwards compatibility — but when input, like forms, was sent from the browser to PHP, it could include multi-byte characters that the database would split up into seemingly random single byte characters. This affected things like umlauts and the British pound sign, not just fully multi-byte languages like Japanese, Chinese and Russian.
• Ajax/XHR: Modern browsers default their XHR requests (how Ajax happens) to UTF-8 encoding when no Content-Type header is provided. This is why even with ISO-8859-1 encoding, umlauts would break on dynamic functionality in the helpdesk (ticket peek, reply, templates).
• UTF-8 vs Unicode: Unicode is a variable byte encoding which overlaps with ISO-8859-1 completely on the first byte. UTF-8 overlaps with ISO-8859-1 over the first 7 bits (which is basically all the characters printed on the keys of a standard US Keyboard, including the SHIFT characters). Extended characters, such as umlauts, are expected in a second UTF-8 byte (0xC3BC vs 0xFC).

We’d love to switch over to UTF-8 immediately and support almost every language, but here’s what’s in the way:

• PHP6 is on the way with native Unicode support for all strings. This is much cleaner than anything we can do with the mbstring extension.
• mbstring function overloading (e.g. substr() -> mb_substr()) can simulate native UTF-8 strings with PHP5, but it requires php.ini changes. These changes will usually affect all PHP scripts on your webserver. Under ideal conditions we can control this with Cerb4 and only affect our script. However, real-world conditions are rarely ideal and this would make for a terrible minimum requirement.
• Our database abstraction (MySQL, PostgreSQL, etc.) makes UTF-8 support in the database layer more complicated. This would be much easier if we knew we were always dealing with MySQL 4.0+. We may need to make some tough decisions here (though they’d allow us a lot more efficiency on things like fulltext index searching versus our current watered-down alternatives).
• Converting existing databases to UTF-8 isn’t a one-click process. Ideally we’ll only have to help people convert their existing database if they need UTF-8 support. It can also be the new default. Our current goal is to make sure we can support UTF-8 optionally without breaking every existing Cerb4 helpdesk to get it. Data-wise we’re probably fine here, but we’d run into the same issues as described above until the database was converted to UTF-8. The MySQL default is ISO-8859-1 (which it dubs “latin1”).

UTF-8 hangups aside, this should fix the main issues with Cerberus Helpdesk for our friends in Germany, Austria, France, Belgium, Italy, Sweden, Norway, Spain and the Netherlands (who have been rightfully banging down our door about it!)

After many months of hard work, we released Cerb4 into a world of overflowing inboxes and overworked people. A crowd started to take notice.

“Welcome to the party!” we said.

“Oh, this is a nice little get-together,” said the crowd. “But it’s not a party without Custom Fields!”

Being good hosts, we promptly set down our plastic cups of punch and disappeared into the WGM development labs. Keyboards began to click away rhythmically like locust. The shouts of developers rang out, intermingled with the squeaking of whiteboard markers.

Some time passed. Suddenly, the doors of development burst open and we programmers emerged, looking like zombies; but smiling — unlike any zombie I’ve ever met.

“Everybody,” we shouted in unison, “we’d like to introduce Custom Fields!”

Then we had ourselves a party.

(That’s pretty close to what happened, anyway.)

Late-night delirium aside, here’s the scoop:

• You can now create custom fields at the global and group levels. At the global level you may want to re-create custom statuses or ticket priorities. At the group level you can track more localized data, like product or department-related fields.
• You can view custom fields as columns on any worklist.
• You can use custom fields as search criteria.
• You can associate custom fields with the situational questionnaires on the Support Center to have answers captured in ticket fields automatically. This also allows you to build more detailed contact forms, using single-line text fields, multi-line text boxes, dropdown menus, checkboxes and date fields.

Enjoy!

Goodbye, Group Workspaces… We’re sorry it didn’t work out!

Alright, so Group Workspaces was an idea that looked great in development and fell apart in the real world. While there were advantages to creating a private workspace for each group, the community was really clear about a collective desire to not be constantly clicking back-and-forth to work on tickets for different groups.

The feedback against Group Workspaces led to the development of Overview, which has turned out to be one of those things you can’t imagine living without once you’ve used it. Piles of tickets can now be explored by group, SLA or assignment from a single screen without any setup required from workers. It’s strangely fun to work toward an empty Overview.

For the past couple months Overview has been doing its job admirably, and the conversation has shifted from its predecessor’s faults to what can be done to make Overview even better.

So, driven by your feedback, we’d like to introduce the following improvements:

Overview Amnesia Cured
The Overview screen will now remember what you were looking at if you navigate away and come back. In the past, Overview would constantly reset to the “All Tickets” list.

Auto-Refresh Pile Totals
The totals for groups, buckets, SLAs and assignments will now refresh automatically after you perform a worklist action, such as moving tickets or reporting spam. Several actions are performed without refreshing the page, and this was causing a continuity problem for many psyches.

Quick Move Links
After moving tickets, quick links to the most popular groups and buckets are provided beneath the Overview worklist. This saves the repetitive motion of clicking, scrolling and selecting your desired option in the “move to” dropdown menu.

Take/Surrender
Two new shortcut buttons have been added to the “more options” menu: the ability to assign the selected tickets to yourself (take) and the ability to remove your assignments (surrender). Previously this could only be done from the ticket “peek” pop-up or from Bulk Update.

Super Sorter: Subject Prefixes
The Super Sorter is often the quickest way to distribute large piles of tickets from group inboxes while using Overview. While it could detect similar subjects or senders in a worklist, it didn’t have the ability to discover patterns at the beginning of a subject line for you. Now it does!

Super Sorter: Shortcuts
Another tedious task when using the Super Sorter involved scrolling to the bottom of each pile’s dropdown menu for the Close, Spam and Delete options. We’ve placed shortcut links next to each dropdown that will quickly select these options with a single click.

Enjoy!

As requested, we’ve finally put a development blog back into action! For a project with 6 years of history, it’s going to look pretty empty around here in blog land for a couple days.

Here’s a quick update to get the things rolling:

Cerberus Helpdesk 4.0 progress is in full-swing, with daily feedback coming in through e-mail, live chat and posts on the community forums.

The major functionality we’re currently working on is:

• Translations/Localization
• Custom Fields
• Improved Mail Rules (header rules)

We’ve finally updated the design of the project website. The old site served us well for years, but it was starting to show its age. The new site aims to keep things simple, since Cerberus Helpdesk is best experienced by jumping right in with the demos, instant evaluations or downloads.

The new project website is especially interesting because it’s completely driven by Cerberus Helpdesk 4.0 and Devblocks as a “community tool” — no different than the Support Center or Knowledgebase. This lets us do some pretty powerful things with very little work required, like giving you an all-encompassing “Fetch & Retrieve” search box to simultaneously look for answers in the forums, roadmap, changelog, wiki documentation, knowledgebase/faq and this blog.

We recently added a live chat option to the new site. Currently we’re using LivePerson – ideally we’d already be using the Cerberus LiveHelp project that over 1,200 of you are interested in. We’re making a lot of notes about how we can better integrate live chat with the helpdesk.

You’ll also notice we’ve removed our old store in favor of simple Paypal purchase options. We were never thrilled with having to maintain a storefront just to let you guys buy licenses – it really overcomplicated things. There’s also no reason we needed to store your credit card information (or even ask for it). If you dislike Paypal for any reason, we’re still able to take care of you with our merchant account for Visa/Mastercard and AMEX. We still accept checks, wires and corporate purchase orders too.

On the project roadmap end of things, I recently wrote a (fairly tongue-in-cheek) post over on my personal blog about the things that have been nagging me about the project portal, where we accept feature requests and bug reports. We could really make it a lot simpler for you guys to leave feedback and help collaboratively drive the project roadmap – voting on what you want to see done first and having an easy way to be notified when they’re done. The current system is too developer-centric.

We’ll make a new habit of summarizing anything interesting going on throughout the community here on the blog. Make sure you subscribe to our RSS feed to stay aware of project news – upgrade announcements, security notices and the occasional request for comment regarding the community’s thoughts on new functionality.

-Jeff