Is anyone happy...

[gibbscam]

I have been a Cerberus user for several years. I am extremely unhappy with the direction the development of this software has taken. Is anyone happy with the current look and feel? We do standard technical support for a CAD/CAM software so I don't feel like we are in a special industry or anything. Who is making use of this software in its current iteration?

[idigital]

I'm in the same boat. I'm still using 2.7.0 and it's doing the job. Didn't install v3 after reading problems and the new forum board didn't help.
I'll probably wait a bit and see.

[jstanden]

I have been a Cerberus user for several years. I am extremely unhappy with the direction the development of this software has taken. Is anyone happy with the current look and feel?

Many people seem happy, but we've been very clear that 4.0 is a work-in-progress. It's just been opened up to the community to gather feedback and fine-tune.

Have any examples of things you specifically take issue with?

[jstanden]

I'm in the same boat. I'm still using 2.7.0 and it's doing the job. Didn't install v3 after reading problems and the new forum board didn't help.

You're better off doing your own instant evaluation (www.cerberusdemo.com) and drawing your own conclusions. ;) Then we can talk about what your specific concerns are.

Be sure you read the New Changes page to really get an understanding of how the changes fit together:
http://wiki.cerberusdemo.com/index.php/New_Changes

[neenach2002]

We are very happy with Cerberus 4.0. Since we needed to develop a custom client interface using PERL (so we could integrate that end with the rest of our application), the fact that Cerb4.0 is just the "core" makes it absolutely perfect for us to use. It is lightweight, the server requirements are reasonable, and it was very simple to get everything setup and working. The only thing we need is automatic refresh (ajax-based) to refresh the ticket list. It gets annoying to have to refresh it manually, and it doesn't make sense for any of us to switch browsers just to be able to use a plugin that will refresh the page for us.

[jstanden]

The only thing we need is automatic refresh (ajax-based) to refresh the ticket list.

That actually makes more sense than how I interpreted the feature request initially -- which was refreshing the whole workspace.

Auto-refreshing a worklist/view will still cause issues if you're in the middle of doing previews or checking rows. I suppose doing any action on a view could delay the refresh by something like 30 seconds -- but that adds a lot of complexity for no good reason.

I still think if automatic refreshing of tickets is a big requirement, there's probably another way we can do it that's more suited to your purpose (such as displaying on a projector in a data center, etc.)

[neenach2002]

Hey Jeff,

Actually, I have experience doing AJAX-based refresh of certain sections on a page. This is actually really easy to handle! All you have to do is set a JS variable depending on what view is set currently. Then when you go to refresh the area, check that variable! If it's a view that you would want to refresh (tickets) then refresh it, otherwise, don't. It is about 5-6 lines of code. Though, I do use the XAJAX framework for all AJAX stuff, I'm sure it's still fairly simple without it.

What you would do is set a checkbox at the top that would be something like "LOCK VIEW" or something, that doesn't allow auto-refresh. Or tie it to a key on the keyboard (like you did with workspace switching). Then it's as simple as hitting that key, or clicking the checkbox/button to keep the view from refreshing when the user is doing something.

Too bad we can't link computers to the user's brains efficiently. Then we wouldn't need to worry about this as it would be 100% automatic based on what the person was thinking! ;)

[jstanden]

Too bad we can't link computers to the user's brains efficiently. Then we wouldn't need to worry about this as it would be 100% automatic based on what the person was thinking! ;)

haha, yeah, mind reading would be the ideal solution for a lot of functionality. :D

The 'lock view' concept is a decent solution, but it requires so much proactive clicking that I can't really see it being the default implementation in core. It would upset people who were in the middle of checking a large list when it refreshed because they forgot to check it, etc.

Though offered as a plugin it makes perfect sense.

[jstanden]

Hey guys!

Another good reference post for the subject of "is anybody happy?" is over here:
http://www.cerb4.com/forums/showthread.php?p=571#post571

From what I've been hearing, I think more people are happy with 4.0 than aren't. Any time something changes we risk upsetting some existing users.

We're all for frank and open discussion, even in complete contradiction to everything we hold dear as a company. BUT, it's important for you guys to bring up specific contentions rather than a general "woe is me" attitude -- that's not productive. :)

[gibbscam]

ok...specifics:

1) What happened to the knowledgebase? v3 had some very nice improvements but v4 seems to have removed most of these. It is nearly unusable in its current state.

2) Where are the custom fields? These are critically important to us.

3) My statuses changed from words (v2) to stars (v3) to nothing (v4)

4) Pre-parser has been removed

5) Most of the Global settings have been removed.

The list goes on. I can't imagine that anyone who purchased v2.xx based on the feature-set advertised would make the same decision with v4. I have no choice but to move to a different helpdesk package...and this pisses me off. I spent a lot of hours configuring Cerberus to work for me only to be blindsided by a company that is unclear of its own development direction. Not to mention that I made the original purchase decision and am now forced to admit to my superiors I made a mistake.

[neenach2002]

Custom fields are still here - sort of. Using the contact form builder you can capture "custom fields" from the user as separate questions.

Statuses will hopefully come back as a plug-in (in fact, I'm sure they will;))

WGM has never let us down before, and I'm sure they won't do so this time! Keep in mind Cerb4.0 is still in beta, so don't expect all features right away! :)

[bessette]

ok...specifics:

1) What happened to the knowledgebase? v3 had some very nice improvements but v4 seems to have removed most of these. It is nearly unusable in its current state.

2) Where are the custom fields? These are critically important to us.

3) My statuses changed from words (v2) to stars (v3) to nothing (v4)

4) Pre-parser has been removed

5) Most of the Global settings have been removed.

The list goes on. I can't imagine that anyone who purchased v2.xx based on the feature-set advertised would make the same decision with v4. I have no choice but to move to a different helpdesk package...and this pisses me off. I spent a lot of hours configuring Cerberus to work for me only to be blindsided by a company that is unclear of its own development direction. Not to mention that I made the original purchase decision and am now forced to admit to my superiors I made a mistake.

Another thing that missing is tagging. It was finally added to 3.X and now it's gone again. I can't believe how frustrating working with your company is.

Also, you can't choose to sort a ticket thread in reverse chronological order or have the option to NOT group notes together. What if we want them to be in thread order?

Also, all the great information that was on the ticket details page, like the audit log and customer ticket log (both invaluable) are gone. Just vanished.

I can't use Helpdesk 4.0 and don't see how anyone who has used a previous version of Helpdesk for any real world email customer service can. It's unfortunate, because 3.X can't scale to the amount of email we're starting to receive and we'll be forced to move to an application made by a more professional company.

You should charge more for you product so that you can hire more people. I foresee you losing a lot of customers, like me, if you can't turn this around.

[bessette]

Custom fields are still here - sort of. Using the contact form builder you can capture "custom fields" from the user as separate questions.

This only works if your Helpdesk application is publicly available. Ours isn't due to security reasons.

[bessette]

Oh, forgot to add that saved searches are missing. Another reason I can't use 4.0 for my company.

[neenach2002]

Apparently you still haven't realized that Cerb4.0 is still in beta....and that Jeff has said at least some of the features you are complaining about are scheduled to make it into the standard Cerb4.0 package.

You're also forgetting that you can completely customize Cerb4.0 and override the standard code without touching it, using Devblocks... You could, in actuality, make Cerb4.0 as tailored to your specific needs as you could writing your own Helpdesk system! The problem with that statement is that....Cerb4.0 takes ALL OF THE GRUNTWORK out of designing your own helpdesk backend. Their system is tried and true.

I expect that once Cerb4.0 is out of beta, there will also be a wealth of plugins available for download...

[neenach2002]

I will further add that it seems a LOT of people are screaming for custom-fields.

I am going to say that I think custom fields suck. You make your users enter that info EVERY TIME they submit a ticket?! How about you setup your client area so they can enter this information into their profile, and have it automatically populated into Cerb via the standard mail form? With Cerb4.0 this is especially easy due to the new plugin system! Something like that would be custom fields any day (at least in my mind). Custom fields are almost always just more headache for the customer trying to contact you. The idea of them is good, but the implementation has almost always been BAD!

I am standing behind WGMs new approach. They have almost a perfect balance here, and I'm sure once 4.0 is official, the balance WILL be perfect.

[jstanden]

1) What happened to the knowledgebase? v3 had some very nice improvements but v4 seems to have removed most of these. It is nearly unusable in its current state.

You create the knowledgebase as a Community Tool now (make sure your 'Community Tools' plugin is enabled in Configuration->Plugins).

There are many reasons for this, but primarily it's so you can instance autonomous knowledgebases -- each with their own root and tag namespace.

Coupled with the RSS feeds and Fetch & Retrieve these instances give you MUCH more flexibility than the 3.x versions. But they definitely are different.

However you also need to consider the hassle of installing and upgrading the Support Center (with embedded KB) in-sync with Cerb3 in the past. In Cerb4 you simply drop the index.php in any location (even on a different server) and you have a fully functioning knowledgebase. You generally don't need to update any of your Community Tool index.php files when you update the helpdesk (it's automatic). You can even run the KB on a remote PHP4 box. You could technically run the KB in an ASP.NET box without PHP at all.

2) Where are the custom fields? These are critically important to us.Custom fields are definitely important to a lot of people. As I've mentioned on other threads, we decided to open up the 4.0 Beta development process to everyone for feedback. The alternative was keeping things behind closed doors until everything was "perfect" (which, obviously, it never would be).

That means some of these plugins, like Custom Fields, are still being developed. I'm just about to release the new E-mail Notifications/Watchers plugin.

You can see from the attached screenshot how much more useful this will be. We're taking the time on each plugin to really consider how it's going to be used -- instead of just cloning all our old functionality.

3) My statuses changed from words (v2) to stars (v3) to nothing (v4)Priorities, right? The priority property on tickets was so arbitrary. It required extra steps to categorize tickets by priority (or due date) and then have everyone look at ticket lists in priority/due descending order.

We've focused on making it easier to handle all your e-mail quick enough that priorities would be a pointless step.

If you're concerned with urgent issues slipping through the cracks, simply make a bucket called 'Urgent' in the appropriate group.

No doubt we'll end up with a better SLA and auto-assignment system in 4.0 as time goes on. But that's really going to be driven by what people find themselves needing in 4.0 -- not based on purely what we noticed is different from 3.0.

4) Pre-parser has been removedCorrect. Either set of mail rules haven't been reimplemented yet.

That's another job for plugins and our 'event point' system in 4.0. The important thing to realize about event points is that you can now create your own plugins to watch an event (like "pre parse" or "post parse") and you can do pretty much _anything_ you want, not just the outcomes that you were boxed into in the past.

We'll still likely provide the simplicity of a default 'mail rules' implementation, but people with specific needs won't be limited by the constraints of having to have a simple user interface for defining rules. For example, you could now create a pre-parse plugin to check the billing status of each sender before admitting a ticket. That's not something we could ever really do in the past.

5) Most of the Global settings have been removed.Sure they have, as most of the global settings didn't need to exist. What options are you specifically missing?

I can't imagine that anyone who purchased v2.xx based on the feature-set advertised would make the same decision with v4.
...
I have no choice but to move to a different helpdesk package...and this pisses me off. I spent a lot of hours configuring Cerberus to work for me only to be blindsided by a company that is unclear of its own development direction.Wow! You are seriously jumping the gun here. You've already admitted you're mostly happy with 3.x -- why don't you just keep using that until you feel 4.0 meets your needs? What's with the need to rush to the conclusion that we've completely lost it after just glancing at the 4.0 beta?

I consider it a strength in our project that we're willing to share what we're working on practically the moment it's functional. We have a lot of collaboration going on with you guys to help refine things.

As I said above, the alternative is that we don't release anything out of paranoia until we feel we've covered every possible complaint. And at that point, we'll be so hard-coded in a particular direction that your feedback wouldn't be able to change it, right?

I don't understand your motivation for needing to be so negative.

[jstanden]

Whoops, that thumbnail was way too small.

Here you go:
http://www.cerberusweb.com/cerb4-content/images/c4_watcher.png

[neenach2002]

<snip>
However you also need to consider the hassle of installing and upgrading the Support Center (with embedded KB) in-sync with Cerb3 in the past. In Cerb4 you simply drop the index.php in any location (even on a different server) and you have a fully functioning knowledgebase. You generally don't need to update any of your Community Tool index.php files when you update the helpdesk (it's automatic). You can even run the KB on a remote PHP4 box. You could technically run the KB in an ASP.NET box without PHP at all.
<snip>


Or, in our case, create a custom perl-interface that does whatever we want (like allowing a requester to close their own tickets ONLY when they are the first requester on that ticket...just in case *we* open a ticket for them.)

Or, let the original requester add any other requesters onto the ticket.

[jstanden]

Custom fields are still here - sort of. Using the contact form builder you can capture "custom fields" from the user as separate questions.

Custom Fields, similar to how they existed in the past, will make a comeback as a plugin as well. They just add complexity we didn't want to exist in the 'core' functionality that somebody coming from webmail would intuitively understand.

We'd rather have a plugin to enable and configure things like that, than having everything on by default with configuration options to disable or tune 50 things.

The huge benefit in Cerb4 with plugins is that when you disable a plugin the code for it disappears completely. No cycles are spent checking if something is enabled or not, and the code isn't cluttered with logic in multiple places where something like custom fields would modify the UI.

Statuses will hopefully come back as a plug-in (in fact, I'm sure they will;))Technically, a status property (as it existed in 2.x/3.x) would just be a custom field on a ticket.

However, we found that people were using custom statuses (beyond open/closed) to be more workflow-oriented than status-oriented.

Buckets allow for better workflow where you're moving tickets through an assembly line (order, payment verification, shipping, filing).

We'd also love to do a 'Checklist' type plugin where you could define workflow steps like 'Filling an Order' or 'Setting up a hosting account'. The checklist would be associated with the ticket, and would essentially be the 'status' of the ticket (but in multiple contexts, as you may have multiple checklists going on).

The checklists concept would be really powerful, because it ensures the same problems/tasks are handled uniformly, and it could be used to help train (and give confidence to) new helpdesk staff.

WGM has never let us down before, and I'm sure they won't do so this time! Keep in mind Cerb4.0 is still in beta, so don't expect all features right away! :)Thanks! :D We aren't the "owners" of Cerberus Helpdesk, we're the custodians. That means we're taking the aggregate feedback of thousands of people and trying to make something sensible and useful out of it.

The "out of the box" product may not meet 100% of the needs of somebody, but it's specifically not designed to. It's designed to work and be intuitive, and allow you to quickly add (and share) the specialized parts you need. That's also why we put 100% of the source code out there, at the risk of rampant piracy. The collaboration is more important.

It's strange when people fly off the handle, considering all that. ;)

[jstanden]

Another thing that missing is tagging. It was finally added to 3.X and now it's gone again. I can't believe how frustrating working with your company is.

Tagging was added in 3.x to help associate the context between knowledgebase articles and tickets. Tagging replaced 'trigrams' from 2.x which tried to do the same thing.

In 4.x we've moved to 'Fetch & Retrieve' and Community Tools, where you can now find many more useful resources (blogs, wikis, forums, docs, bug tracking, KBs, FAQs, etc). It would be time-consuming (and ultimately futile) to try and categorize all this content with tags -- because nobody is going to sit there and tag every forum post, wiki page or blog entry with the same consistent set of tags. That's why Fetch & Retrieve is a much better solution.

You can still tag Knowledgebase articles in 4.x, because the free-association of tags is highly-preferable for browsing instead of a rigid tree structure that only looks at the resources from one perspective.

For example:
http://www.cerberusweb.com/kb/browse/cerberus%20helpdesk+faq

Also, you can't choose to sort a ticket thread in reverse chronological order or have the option to NOT group notes together. What if we want them to be in thread order?If you thread notes with messages, then you lose the ability to notes to call attention to specific messages. You also lose the ability for notes to clearly reply to other notes, which allows you to have a small threaded discussion on a ticket while working on it.

I think you're mistaken on the ticket order. You currently always view new ticket messages in reverse (descending) chronological order. The reason for this is so you don't have to scroll down -- you can simply expand the past messages if you need more history/research.

With the 'Next Worker' option, it's expected the same person will efficiently receive most of the replies to messages they send out. And in that case you don't need the entire history displayed each time you get a response.

Also, all the great information that was on the ticket details page, like the audit log and customer ticket log (both invaluable) are gone. Just vanished.We've mentioned on other threads that the audit log will make a return, also as a plugin. It can be implemented much cleaner with our new event point system, and defining each audit log entry as an event allows 3rd party plugin developers to also create any functionality they want on the same events (when a worker replies, when a ticket is created, when a property changes, when a ticket is deleted).

It's *far* too simplistic to say something like that vanished for no reason. The reason is the same as with everything in 4.0 -- features aren't being added back until we can do them properly and with the attention they deserve.

As for the customer history on Display Ticket, click the 'Ticket History' tab while displaying a ticket. It moved to a tab so all the work that goes into building that list isn't done until you specifically ask to see it. Tweaks like that make viewing tickets far faster in 4.x than any past version.

I can't use Helpdesk 4.0 and don't see how anyone who has used a previous version of Helpdesk for any real world email customer service can.Even though we're still working on bringing the more complicated plugins into the project, I think to make such an abject statement you just aren't taking the time to understand the new concepts and development process.

You clearly don't understand that the platform of Cerb4 is *far* more extensible and scalable, and that's it's stupidly simple out of the box by design. That means you aren't boxed into our way of doing anything, and you can enable the plugins (from WGM or otherwise) that build off it to meet your needs.

It's unfortunate, because 3.X can't scale to the amount of email we're starting to receive and we'll be forced to move to an application made by a more professional company.Again, I don't understand the ironic need to take jabs at our professionalism. We've been very transparent about the development process in 4.0 and that it's intentionally not doing everything in the past.

By your logic, we would:
* Delay showing you what we're working on for several more months
* Develop features by reading your mind without asking for your input to create them

That's rather unreasonable, isn't it?

You should charge more for you product so that you can hire more people. I foresee you losing a lot of customers, like me, if you can't turn this around.Look, I say this out of love (really!), but if we lost every customer who freaked out and cried the sky was falling every time something evolved we'd be in a much happier place, with much more time to dedicate to the people who 'get' the ongoing collaboration. ;)

But I'm not looking to divide people into groups based on how much they agree with me. The diverse range of needs and opinions is what makes the product better. But that requires you're reasonable and understand that when we open up our process, almost nothing is going to be 100% perfect right away. Because the entire point of opening up the design process is to gather feedback to make things work like people desire.

It doesn't say anywhere that you have to take the absolute latest development progress and rush to replace your current production helpdesk. The people who feel it's ready will upgrade, and the others can productively chime in about what they feel is stopping them from making the leap.

If you're simply pissed because we don't have a 4.0 completely done that meets 100% of your needs the second it left development, then this seriously isn't the right project for you anyway. Our market research is giving our community early and complete access to the code and the ability to give feedback that is actually discussed and implemented.

Don't get me wrong, I'm all for discussing anything you want to talk about. But your doomsday messages aren't constructive.

[jstanden]

Oh, forgot to add that saved searches are missing. Another reason I can't use 4.0 for my company.

Saved Searches are obviously not something we'd just nuke for no good reason either.

At the moment saved searches aren't implemented because the new Custom Workspaces improved the way we're persisting the state of a ticket worklist (view).

The framework is evolving along with the visible functionality. The simpler (and more powerful) we keep the framework, the more plugin developers are going to be able to do.

We ripped out all the (relatively) ugly code in views to add a system which allows people to build AbstractViews -- which basically means you can make a "view"-like list for any entity in our database automatically (contacts, addresses, workers, tickets, messages, articles, etc). They'll automatically inherit the ability to choose columns and search criteria (specific to that entity), and do the ajax paging/sorting/actions. We turned something that used to be the most complicated piece of code in 3.x into a commodity widget in 4.x's toolkit.

You don't see a lot of that work getting done because it's entirely invisible from the interface. But you can see it indirectly when plugins are getting knocked out in days with 4.x that would take us weeks with 3.x. We can also now offer two directly-contradictory plugins to solve something in completely different ways.

Saved searches are on the roadmap, but like many things they won't get priority status until people are saying how much they need them. Because at any given time I can point to the 'Top 10' things people are saying they can't live without.

[jstanden]

So a summary so far (for people who fear the huge replies): ;)

* If you're just impatient and wish 4.0 was fully-functionality right this minute, then hey -- I'm with you. ;) But it will be better because we stopped and democratically asked what people would like to see next, and how it should work.

* If this was still behind closed doors, people would be here complaining that we're taking too long without showing anybody anything.

* If we had reimplemented everything like 3.x, people would be saying it doesn't do anything new and doesn't solve any long-standing 3.x issues (conceptually and technically).

* If we had implemented everything differently but without asking people, people would be here complaining that we boxed them into a specific way to do it that doesn't work for them at all.

So what's left? It's releasing what we're working on early and giving people ample opportunity to give feedback as it's developed. Right?

We've been around long enough to realize that's part of the business. There will always be people who rush straight to complaining -- perhaps it's the stress of business life, or impatience to make progress (which I am absolutely guilty of myself), or they just choose to hate us for some arcane reason. ;)

[jstanden]

Apparently you still haven't realized that Cerb4.0 is still in beta....and that Jeff has said at least some of the features you are complaining about are scheduled to make it into the standard Cerb4.0 package.
...
You're also forgetting that you can completely customize Cerb4.0 and override the standard code without touching it, using Devblocks... You could, in actuality, make Cerb4.0 as tailored to your specific needs as you could writing your own Helpdesk system!
...
I expect that once Cerb4.0 is out of beta, there will also be a wealth of plugins available for download...

You definitely seem to understand what's going on. :)

The smaller we make the "core" product, the more useful it is as a "clean slate" starting point to customizing. Customizing doesn't insinuate that everyone has to edit their own code.

I fully expect there will be an incredible amount of plugins available for 4.0, developed lovingly by people who are passionate about their own approach to a problem. For a lot of things that I'm not passionate about, I'd be faking it. It's obvious when a developer fakes it.

[jstanden]

Custom fields are almost always just more headache for the customer trying to contact you. The idea of them is good, but the implementation has almost always been BAD!

I agree for the custom fields in the old Support Center.

But I can definitely see the utility of custom fields adding new properties to tickets or customer records.

If you're able to associate some custom information with those entities, then your own plugins can use them to do things like looking up customer billing status when displaying or accepting a ticket. Whatever identifier your billing system uses would be a custom field on the organization record in Cerb4.

It makes a lot more sense to use custom fields as a generic property store/registry for any object/entity in the API, because then each plugin doesn't have to concern itself with how to map a new setting to each ticket, each worker or each contact.

And that's a big reason that custom fields aren't just copying what we did in the past. We have a chance to make them much more useful if we give it a little bit of extra thought and planning, so that it meshes beautifully with the new concepts and enables even *more* exciting functionality to be created (faster and with less code or reinventing the wheel).

[jstanden]

Or, in our case, create a custom perl-interface that does whatever we want (like allowing a requester to close their own tickets ONLY when they are the first requester on that ticket...just in case *we* open a ticket for them.)

Or, let the original requester add any other requesters onto the ticket.

Sure! We also made our Support Center plugin separate from the other community tools so someone could simply copy it into a new plugin and completely change it.

That will be a lot more realistic when we fill the wiki with more API/plugin examples, but that time is coming. ;)

[cellmonsters]

Well I would like to say that although I still have not had a chance to test run Cerb4 Im very excited to see the new look and features. As a past user of cerb3, i can say that cerb4 is a big clean step up from the cerb3 version.

As always, its sad how some can so quickly snap at a program still under beta... if your not ready for beta then wait for the stable version. Jeff has pretty much given a full and good explanation on why things are the way they are now.

I have to really admit the fact that if we heard a rumor on cerb4 we probably be complaining when it will be availabe.. so now that is is available.. why attack it while still in its early stages?

Now, as the designer and feature implementer of our online store, i can say that certain features and changes take time to implement when a system is already running. When i was doing the updates to the design of the store and re-implementing the features to report a problem with your ticket and have the system look up the order number before problem ticket was sent to us was a bit time consuming.. specially because i had added a code that totally broke the whole code once a user clicked on submit.

You see we cant be living in a world where we think as soon as we see something.. it should work 100%... not even our every day lives are 100% fool proof.. if it was.. it be quite boring... at least in my opinion.

[cbtrussell]

Even though we're still working on bringing the more complicated plugins into the project, I think to make such an abject statement you just aren't taking the time to understand the new concepts and development process.Actually, I think this is the key to a large part of the issue here.

Don't get me wrong, given the choice between the early looks at Cerberus that WGM provides, versus some of the here-it-is, take-it-or-leave it attitudes of some of other software vendors we deal with, we'd much rather have it this way.

That said, the real issue for some of us is we shouldn't have to "take the time" to understand the new concepts! I'm all for simplicity. I get the value that the new architecture provides. I think it's definitely a Good Thing. But you guys seem to believe in revolution over evolution for each successive release, for better or worse. 'Understanding new concepts' can be a lot to ask, don't you think? I don't want to spend all day figuring out how v4 is going to have to be configured to give us the functionality we currently utilize; I want to run my business! ;) I remember when v3 first came out your customers - myself included - were begging for quick-start guides, best practice recommendations and other documentation so we could figure out just how to use the thing relative to our 2.x implementations. I'm not really sure why you guys seem to think this is perfectly normal and acceptable.

I'm a gearhead, I love this stuff. Hell, we're in the application development business just like you guys and face many of the same issues. BUT... and here's the rub... as much as I'd like to some times, it's frustrating to be forced to invest a lot of time 'understanding the new concepts' when the current product is working just the way we want it, just the way we've trained our users and customers to use it. I want to upgrade to get the benefit of bug fixes and new features, but I shouldn't have to invest as much time in a product upgrade as I would in a migration to a completely new solution, which how v2 > v3 felt.

At this point maybe I'll just go back under a rock and wait until v4 is available with plugins that provide all the functionality we currently use in v3. Hopefully v4 will finally be the right platform so future upgrades are more evolutionary in nature. (I sure hope so!)

Bottom Line: I do appreciate what you guys do, I continue to be a fan of Cererus, but I think you (sometimes) have a tendency to overlook some of the more practical issues your customers have to deal with as a result of your never-ending quest to build a better mousetrap.

Brandon

[jstanden]

Hey Brandon!

That said, the real issue for some of us is we shouldn't have to "take the time" to understand the new concepts!

Really, I don't think it's a problem of people having to understand the new concepts. It's rather simple.

The problem is people having to unlearn the bias that our past versions give them in looking at the new system.

I don't want to spend all day figuring out how v4 is going to have to be configured to give us the functionality we currently utilize; I want to run my business! ;) True. You might have to spend a day to get it set up, but then you'll save weeks or months of your time as you extend it more easily, fight with it less during upgrades/bugs, and have your workers spend less time on steps that don't contribute to answering your customers' tickets. ;)

We want you to just run your business too! We could have ignored some of the issues in 3.x and continued to hack at it, but we'd all eventually have to pay for that someday. Every change was getting more expensive, and those problems went right to the core of the code. That codebase was never intended to be as popular as it was.

I remember when v3 first came out your customers - myself included - were begging for quick-start guides, best practice recommendations and other documentation so we could figure out just how to use the thing relative to our 2.x implementations. I'm not really sure why you guys seem to think this is perfectly normal and acceptable.I wouldn't say we feel it's acceptable that somebody needs any documentation to understand how to use a piece of software.

3.x had two major faults:
* We tried to not change things too much, and the result was a muddy mess.
* Most users will impulsively compare 2.x to 3.x (or 3.x to 4.x) without considering the fresh approach. The mindset is "How do I do deprecated action?" because it's become habit, and often we've found a cleaner, simpler, faster, "better" way (aggregated from thousands of people and hundreds of thousands of support issues from users on our end).

That's why new users come to the project and they're thrilled, and some long time users are among the unhappiest. (The same thing is happening with 4.0, but there isn't much of a fiasco).

But in either regard, it was bad how muddled 3.x became. We learned a lot from that. But ironically, considering this discussion, we learned it was better to make more radical changes than to limit ourselves to dispassionate tweaks that were heavily encumbered by past bad decisions (and slow tweaks to develop, at that).

Really though, if you think about the 2.x->3.x "commutiny" (as I like to call it) -- this is nothing like that. Mostly people want to know where their favorite feature is, and for a lot of those we simply haven't finished them yet. We have no objection to the features. We've just never released something completely rewritten this early for feedback.

I'd do it again. This process is *far* more preferable because we're doing what we 100% believe in, opposed to what we feel the market is demanding from us.

I want to upgrade to get the benefit of bug fixes and new features, but I shouldn't have to invest as much time in a product upgrade as I would in a migration to a completely new solution, which how v2 > v3 felt.I actually agree with you from a business owner's perspective. I've frequently mentioned to the guys over here that I'm not as passionate about most things I use as many people are about Cerberus -- and that's really magical. It can (and does) distort our sense of importance to the average user's business at times.

But really, why shouldn't a major revamp (as this is billed) be just like a migration? From a protectionist standpoint, it would be safer for us to lock people in and not give them the opportunity to survey our competition when it's as much work to use another package or our next big version. But while that line of thinking might be good capitalism, it's bad for the genuinely enthusiastic passionate user who trusts us to do our best.

While 2.x->3.x changed some big things, we've never done a complete overhaul this significant (a total rewrite/re-imagining) in our nearly 6 years of project history. If anything, we should have done it sooner. I'm amazed our thinking from 6 years ago held up as well as it did. But to be relevant on through the next couple years we absolutely had to embrace PHP5 and more collaborative development.

We always risk losing a chunk of the community when we do a discontinuous change like that. It's tragic. It literally keeps me up at night that some people would feel like we betrayed them (or have the impression we took their money and not their feedback).

But it's worth the risk. 3.x was falling apart. Change was expensive. Our interest/enthusiasm was waning. As I said, I'm constantly amazed it all held up as well as it did.

It goes to show:
* Many people are still coming from IMAP and personal desktop e-mail clients
* Nobody is really doing this right yet

At this point maybe I'll just go back under a rock and wait until v4 is available with plugins that provide all the functionality we currently use in v3. Hopefully v4 will finally be the right platform so future upgrades are more evolutionary in nature. (I sure hope so!)You don't have to disappear though, you could always set up a beta install and give feedback. But for what it's worth, I assure you the "revolution" is worth it. It'll be more obvious in a couple months than it is now. Cheap change, beautiful code and enthusiastic/re-energized developers. Without that, Cerb has no soul. ;) I think soul sold a lot of copies of Cerb.

Bottom Line: I do appreciate what you guys do, I continue to be a fan of Cererus, but I think you (sometimes) have a tendency to overlook some of the more practical issues your customers have to deal with as a result of your never-ending quest to build a better mousetrap.Historically, we're absolutely guilty of that. But it's part of the ethos of our company. Not so much overlooking that customers have to jump through hoops -- trust me, the 3.x installation process sickened us (standalone parsers in C with XML config files! Permissions, cron jobs, and being dumped to the system with no guidance!).

But we don't allow ourselves any margin of complacency, because every day we're talking to dozens/hundreds of people who are using the project. Some are new users and some have been around for 5 years. You may have this equilibrium where you feel everything "mostly" works, but with thousands of users we haven't had 5 seconds where it felt like most people were getting by as well as they should be. ;)

That's not so much our fault. That's technology.

[raffaelmeier]

hello jeff, hello guys

we use cerb3 in our company with great success. we are concerned about 4 too, because we still see a lot is missing at this time. is there a map where i can see which features or so called community tools are or should or are planned to be comming up in let's say next 6 month?
what we need is:
- classify tickets (we did this with tags, could be an other solution, doesn't matter as long as I can do saved searches for keywords especially set up by operators, e.g. "sales" or "upgrade customer" or "send bill")
- set a deadline date, due date. as long as the date is not reached, ticket should be searchable or showable in a list of all "undue" tickets for the next 2 weeks ("to do list")
- great idea was a calendar tool with links to tickets on a choosable date

thank you very much for all your efford to otipize the great product! we are looking forward to use cerberus in future and hope, that there will be a few more intelligent community tools or plug ins available.

as is say, i find it a bit unpleasant and disquieting that there is no public list of WHAT PLUGINS ARE PLANNED or in THE PIPELINE.

[cjbengtsson]

I must admit that I agree on this...
What happend with everything that was working well in 2.7?
4.0 is so stripped that it can't be used at all up front.
I can't add a user or company in the addressbook??? (need to send a mail first)
I can't find anywhere to open a new issue in the application (other than sending a mail).
SLA, Custom fields, the great overview page, the search page, my cerberus, advanced options, etc... are all gone or modified so badly that they are almost impossible to use.

What happend?
I have never seen version 3, but question is if that is similar to 2.x and if you will continue to develop that?

[jstanden]

Hey guys,

The things you're mentioning are being added to 4.0 almost daily. The pace of new development is something we could have never done with the 3.x versions and codebase.

New tickets overview page (by service level, group, assignment):
http://demo.cerb4.com/admin/tickets/overview

Service levels:
http://demo.cerb4.com/admin/config/sla

as is say, i find it a bit unpleasant and disquieting that there is no public list of WHAT PLUGINS ARE PLANNED or in THE PIPELINE.

I'll try to keep the wiki current, however the order we're doing things on the roadmap is mostly driven by community democracy. ;)

[networke]

I had to register, been a user since the 2.x days.

I upgraded to v3.6 and it is awesome, however v4 is a let down.

Firstly no support center is a major letdown, and then having to import tickets to v4 is a major no-no. Before, it was just running the upgrade script which handled everything perfectly.

I don't know why companies who have a hit product decide to one day start changing everything that made them successful, look at ModernBill. They've changed so much regarding their billing system, it bombed and now they've been bought out and people are leaving in droves.

Requiring v4 to support all these additional extensions (e.g. mailparse) is just going to make it harder for more people to install and support your products unless there is a HUGE speed improvement, which I don't see in v4.

Guys, please keep supporting v3.6. We don't want to migrate over to Kayako, because unlike you, they've STUCK to what made their product unique.

Whenever you change something, you just alienate all your users. A better way is to introduce a yearly subscription fee, so you can make more money off your existing base, they'll understand and will keep supporting you.

If you want to tap into a different market, then release a SECOND product, like Cerberus Enterprise... but please NEVER EVER change the core product and kill off your old users.

I will stay on 3.6 until there is a new release that lets me upgrade WITHOUT having to IMPORT all my tickets again. I'd be happy to pay for the upgrades.

Why dont you change v4 cerberus now to Cerberus Enterprise or Cerberus Core (so people know there is no helpdesk and its still a "work in progresss"

[pk4]

I just wanted to weigh in here. We have been using v4 for a few months now and it is already an indispensible foundation of our business process.

You asked: is anyone happy?

YES!

Are there things left to improve?

Absolutely!

[bcavish]

Hahah!

Thanks, we know we have a long way to go still. Cerberus 4 was still in its infancy when this thread began. I'd like to think we have come a long way with everyones help these past 6 months.

[userworthy]

Today's Thought:
"You can please some people all the time; you can please all
people some of the time; but you can't please all people all
of the time".

I offer your team an enthusiastic "two thumbs up". I've looked
high and low, and your platform is the best so far. Cerberus 4
is built as a shell, with user-driven feedback as its guide.

The absolute best way to develop a product is to ask your customers
exactly what they want and give it to them --within reason.

I deem your development team "the true Web 2.0 Helpdesk Developers".

Admittedly, I am new to Cerberus. But, I will have to agree with
your words here:

* Most users will impulsively compare 2.x to 3.x (or 3.x to 4.x) without considering the fresh approach.
The mindset is "How do I do deprecated action?" because it's become habit, and often we've found a cleaner,
simpler, faster, "better" way (aggregated from thousands of people and hundreds of thousands of support
issues from users on our end).

That's why new users come to the project and they're thrilled, and some long time users are among the unhappiest.


Human nature makes us creatures of habit. Even if we learn to do something
in a most ineffecient manner, we really hate to have to learn a new way,
even if the new way is much more efficient.

Maybe everyone can keep in mind that 4.0 is a beta. This is stated by the
developers all over this forum. If someone isn't happy with the beta version,
who says they have to upgrade at this moment.

Just my two cents,
Tommy.

[Hildy]

Thanks, Tommy! It's always good to hear that we've managed to make somebody's life easier. :-)

[DBowsky]

Huh, quite the thread here.

In answer to the OP: I am pretty satisfied thus far, although as I am setting this up for multiple groups of corporate internal support teams, I feel I am not *exactly* the target for this product.

The thing is though that we've been using it since 2.7 (for one team) and moved to 3.x (integrating all three teams). The 3.x releases as well as 4 seem to be aimed at outward facing (customer, not co-worker) support teams. Which is fine, because in order to get the multiple mailbox functionality of Cerberus in a typical "Help Desk" product like TrackIT or c.Support we'd have to spend 10-20x the money on the software.

So I'll have to do some creative thinking in order to make Buckets and Custom Fields work for our teams. Fine. It's not like we had rock solid reporting on the "Tags" we used in 3.x.

Someone mentioned not being able to add contacts. Um, Import much? I simple did a csvde export from my LDAP directory (win2k3 AD domain), edited out the fields I didn't want, and BAM, address book populated.

I'd really like to see lots of things added, and in that vein is there ANY resource for people to find plugins or (shock and awe) upload their own? This would be the single biggest boon to your development paradigm. Give your user base the ability to share their own tweaks with the community as a whole. Also give your developers a way to see how people are using the tools.

Slightly OT question: If I add custom plug ins (for example, a yaml reader to computer and network asset information from a separate application - may not even work right, but is a long term goal), is Subversion going to kill those changes when I run updates?

Okay, back to topic.

Overall I am happy. There are improvements to 4 that answer some of the complaints my staff has had about earlier versions. Hell, I sold the upgrade to my boss just because of the ability to mouse over a ticket age listing in hours (36 hours old) and show the actual DATE.

That being said, there are lots of tweaks necessary to make this a workable app for an internal support team. For example, we're not going to move things from one "bucket" to another, but would rather be able to categorize work by problem type - so we can later report on how many hardware failures, how many questions that could have been resolved preemptively with better user training, etc..

I guess my main question is - why the focus on outward facing support? How about a little love for us internal Help Desk (Or Facilities, or Business Reporting) teams?

[kappy]

Maybe everyone can keep in mind that 4.0 is a beta. This is stated by the
developers all over this forum. If someone isn't happy with the beta version,
who says they have to upgrade at this moment.


Actually, we have been told repeatedly that 4.0 is NOT beta, and hasn't been for quite some time now. I disagreed with that when we switched over, as it sure FELT like a beta. However, it is not a beta and they have not called it that for a long time.