Regarding a Legacy Support Center in 4.0

[jstanden]

Requests for a legacy Support Center are common enough that we'll likely build a community tool for it in the next couple days.

I've added a knowledgebase article regarding it:
http://www.cerberusweb.com/kb/article/000017

I imagine the knowledgebase wouldn't be part of the new Support Center in the same way that it used to due to the new Public Knowledgebase community tools. They do a much better job than what we had before.

However, I can definitely see Fetch & Retrieve in the Support Center which allows a single search to give results across all resources (any public kb, forums, wikis, docs, bug tracking, etc.)

Thoughts about what the new Support Center should involve are welcome.

Thanks!

[IreneF]

These functions are important for us:

- Customers have to login to create a new ticket.
(For 3.5.1 we did a LDAP-integration and allow only people from the LDAP-directory to login.)
- Customers can see their ticket history and reply to (and reopen) extisting tickets.

For me it's absolutely ok if the public KnowledgeBase becomes separated from the support center.

Irene

[Botham]

We need to display html code snippets in the knowledge base.

The current functionality allows one to write articles inlcuding html snippets however when an article is re-edited the html code snippets are rendered into html rendering the article un-useable. So need a 'code' function or 'pre' function - or ability to disable wysiwyg prior to re-editing an article.

[darren]

We would definitely want a public support centre to accompany v4.

The ability for clients to be able to login and view past tickets, reopen them if necessary and track correspondance online would be essential for us.

The KB can be separate, but a "client area" would be a must have addon.

[bcrooker]

One of the major things that we use our support center for is to provide a file download section to our users. These downloads are protected on a per-organization basis. We have written this in as a add-on to the widgets portion of the 3.x support center, but if something like this could be built-in that would be great.

Basically, we have a list of applications. Each application has a "latest stable version" which is published at the main file listing layer. Each application also has a release notes link which brings you to a page that lists all revisions (both beta versions which are newer than the latest stable as well as legacy stable versions and links to these files.

[chrisdowns]

A Support Centre similar to Kayko is good with news links, forum links, New & Old Tickets, Knowledge Base ect.... Even if the support centre & KB are seprete but we have the ablity to place a link it would be useful

[dfroberg]

We have a similar setup as IreneF but auth againsta postgress DB using a custom plugin,
will this kind of plugins be supported in the future?

[jstanden]

Alright! Just a status update here. This may get a bit technical!

I'm in the middle of coding the new 4.0 Support Center (SC) as a community tool.

This is shaping up better than I was hoping -- and you guys are going to get more than you're even asking for. ;)

So far I have the community tool created as a new Cerb4 plugin, so you can simply enable it to have the option to spawn Support Centers and deploy them like the other community tools (contact form builder and public KB).

I've also written the sub-plugin hooks for the SC, and gone a step further by making all the default components of the SC use these plugins. This means:

You can add a new SC module to do basically anything (with an active login required or not). From these modules you can access any Devblocks/Cerb4 functionality. This means you can make download sections, licensing, billing or even proprietary tools -- anything we aren't covering out of the box. Industrious community members can make, share or sell these sub-plugins with pretty minimal effort. As well, WGM can offer additional functionality to those who want it without complicating the core app.
This also has another interesting implication. With our baseline functionality (say, "Open a Ticket") also being implemented as extensions, you'll be able to "overload" the default functionality with your own code -- without actually touching our code. You can simply write a plugin that will replace our menu item for "Open a Ticket", and our code will defer to you. This means if the community is split on how we prefer something should work, the default behavior can be changed incredibly easily without losing stability by editing Cerb4's own code. You can have it both ways.Style-wise, the new SC looks a lot like the simple theme of the new Public Knowledgebase tool. We're going with this approach because it's really easy to let you link to a different stylesheet to theme it, versus the horrible hacking required in the Cerb3 SC to embed it. Not to mention the specialized images (gradients, etc) used in the 3.0 SC, or the fact it didn't use all of the available screen width.

Currently, the knowledgebase components in the original SC will be replaced by Fetch & Retrieve (F&R). There are very logical reasons for doing this -- namely, you can now spawn completely independent public knowledgebases and deploy them on different domains. You obviously don't want to hassle with permissions on every knowledgebase in the Cerb4 UI, because it would be incredibly confusing associating all the proper KBs to the right portals. Since our public KBs share their info through RSS (articles by tag, search results, etc.) the process now consists of just plugging in the relevant KBs to the SC as an F&R resource (quite a mouthful, eh?).

That last bit probably deserves an example. Let's imagine WebGroup Media's KB needs:

Cerb3 KB
Cerb4 KB
PortSensor KB
Devblocks KBThen let's imagine the SC portals:

cerberusweb.com
portsensor.com
devblocks.comI'd want to provide the answers from #1 and #2 on cerberusweb.com; from #3 on portsensor.com; and #4 on devblocks.com.

That means I'd just be entering the F&R URLs for the tools, such as:
http://www.cerberusweb.com/kb/rss/search/mask

Where that last bit ("mask") is really what your customer is searching for, what F&R calls "#find#".

That's all well and good between the SC and the KB, and it might seem slightly excessive if that's all we were dealing with. But the real power is when we start to really use F&R adapters to find other useful data. For example, we also have info scattered in all these other places:

Cerberus Helpdesk 3.x Forums (Vanilla)
Cerberus Helpdesk 4.x Forums (vBulletin)
PortSensor Forums (Vanilla)
Cerberus Helpdesk 4.0 Wiki/Docs (Mediawiki)
PortSensor Wiki/Docs (Mediawiki)
Devblocks Wiki/Docs (Mediawiki)
Cerberus Helpdesk Devblog (Wordpress)
PortSensor Devblog (Blogger)
Cerb3 KB/FAQ (Cerb4 Community Tool)
Cerb4 KB/FAQ (Cerb4 Community Tool)
PortSensor KB/FAQ (Cerb4 Community Tool)
Cerb4 Beta Mailing List (Mailman)
PortSensor Beta List (Mailman)
...more!Now that's a lot of places to be sending customers all the time. It's a lot of places to even remember we *can* send customers. Finding the right direct links is a pain. This is what Fetch & Retrieve was built for.

So if we integrate Fetch & Retrieve with the new SCs, that means you can give your customers a single search form that will scour different sets of all these resources (by project, product, etc). I could have a Cerb3 SC (#1, #7, #9), a Cerb4 SC (#2, #4, #7, #10, #12), a PortSensor SC (#3, #5, #8, #11, #13) and so on. Those resources are all already defined from inside Cerb4->Configuration->F&R so you don't need to do any extra work on the SC to add them. Just check off the ones you want to expose for that SC instance -- 15 seconds of work.

Now with that going the SC would deserve being called a portal, as a real focal-point for people to start their search for the proper information on your site.

You can even go steps further assuming the SC can reorganize the F&R searches and even provide those results as RSS. So you could really create another level of mashups or integration on your website (or in your apps/tools) before you even send people to the SC. For example, you could show a list of the most popular support resources on your homepage -- which you would know because F&R is tracking clicks from search results, and then handing you that data as a feed called "Most popular resources in the past 24 hours", etc.

The same kind of feeds are planned for the public KBs -- being able to show the latest changes or most popular articles.

I also figure we'll use the feeds concept to put some content on the front page of an SC, since those big icons were a waste of space in the old version. It would be much more useful to display your latest blog posts, announcements, popular articles or forum posts, etc. That's all trivial with RSS.

Registration/Logins in the new SC can also be abstracted, so you could authenticate against the old login info in the Cerb database (from the address book) or you could use something like LDAP. The key is really the customer's e-mail address and a second form of verification.

I have more in the pipeline, but I get the feeling this is probably long enough already. ;) But it should give you guys an idea of what Cerb4/Devblocks make possible. This is the reason we didn't just hack together a Support Center from the start, or clone the old one.

Thanks for the feedback! I'll try to get something you guys can play with in the next day or two.

[edddeduck]

Hi,

I have a question on Cerberus Support Center AKA Customer Interface. We have a heavily modded version of this tool covering support for all of our Products we ship.

We have been having lots of issues with the php email parser in 3.0 and we would love to update to 4.0 however we have just finished this our customer interface and it looks great and works pretty well. Customer Support (http://support.feralinteractive.com)

We don't want to have to spend lots of time rewriting this entire interface but from the docs it looks like the database and code behind cerberus is now very different in 4.0 and hence we would need to do a lot of work to update it to support the 4.0 version of the software.

This thread was really interesting as it appeared to suggest you could run your old 3.0 support center alongside a 4.0 backend.

Could you please clarify if this is indeed the case? I don't think it is but if someone could let me know if you can run a modified 3.0 support center while being able to have a 4.0 back end that would be great.

I suspect that we would have issues as the database stores KB articles in different ways now(?) and likewise with tickets meaning that the web form ticket system will also no longer work. Could someone let me know what the current situation is?

Thanks,

Edwin

-
Feral Interactive

[jstanden]

Hey Edwin,

You're right, your modified Support Center does look great!

This is tricky. It's not possible to run most features of the 3.x Support Center (SC) because it's tied to the database format of Cerb3 -- which is entirely different in the new version.

However, it looks like you guys follow my line of thinking in your SC and don't use the logins for online "track tickets" functionality. That makes things quite a bit easier.

Because you're just opening tickets or browsing the KB, it would be pretty easy to map that over to the new 4.x concepts because both of those things can be abstracted from either version.

I wouldn't even recommend you use the new 4.0 SC if you move to 4.0 because your custom interface covers what I imagine you need.

Opening a ticket can simply be tweaked to send an e-mail to the appropriate address. You could develop a custom mail form to do anything you wanted here. It could behave exactly like the old one -- no users need to know the difference.

Viewing the knowledgebase would take a little tweaking but it's entirely possible. The 4.x way is to create a standalone public KB, where each instance has its own root, articles, L&F, etc.

But having that separate KB instance doesn't mean you need to make it part of your site. Since your categories will map to tags ( like you can see on http://www.cerberusweb.com/kb/ ) you'd be able to pull the data for each major tag -- each of your games -- via RSS ( like: http://www.cerberusweb.com/kb/rss/tags/cerberus+helpdesk ). That lets you set up the top-level navigation however you want, and embed the KB results on your website directly without the need of the SC. You could retrieve the full content of an article for display on your site as well ( http://www.cerberusweb.com/kb/rss/article/000018 ) -- though the tags feed currently provides this as well.

It's a much more flexible system in 4.0, because we let you access your data in a variety of open ways without the requirement of using our version of the public tools. Or worse, you having to modify the old SC so much to get it to match your L&F (which turns out wonderful, but is undoubtedly a harrowing experience.)

Summarized, you should keep the same shell you have going now but drop the integration with the 3.x SC (just don't include the cerberus-support-center/main file). Instead in that space of your website you'd do a little more custom code but you'd have total control of the layout and functionality. Our 4.x tools would provide the data to you externally in a way they can also be shared with Cerb4 (e.g., Fetch & Retrieve). I'd be happy to help you out on those tweaks when the time comes.

Thanks for posting!

[jstanden]

I moved the Support Center 4.0 announcement here:
http://www.cerb4.com/forums/showthread.php?p=238#post238

Enjoy!

[dsugita]

Progress update:

http://www.cerb4.com/blog/2008/03/14/progress-report-time-tracking-support-center-translations/