NOTICE : Codejock Support Policy

Hi Everyone!

Due to recent policy changes, Codejock Developer Support will be limited to individuals who have an active support and maintenance subscription. If you require support directly from Codejock you must submit your request to support@codejock.com or fill out our online support request form. This will generate a support request in our ticket system and you will be able to interact directly with our support personnel.

As always, we will continue to monitor the forums and will provide answers to general questions, however we will not be able to provide detailed in depth support unless you have an active support subscription.

Kind regards,

Support wrote: As always, we will continue to monitor the forums and will provide answers to general questions, however we will not be able to provide detailed in depth support unless you have an active support subscription.

I'm fine with that. However I prefer to see features, improvements, bugs and general questions to be discussed on the forum rather than through a ticket system. I've only created a ticket for individual problems in the past.

Thirded...this forum has been extremely valuable not only thanks to the help I have received from fellow (non-Codejock) members, but by watching threads for problems that I haven't encountered yet...If many of those posts move to the private ticket system in the future, it will be a big loss indeed. I think that it would be better if the forum membership was tied to our Codejock account so that everything can stay open and visible to all paying members.

The forums will remain as they always have, this is a place to discuss features, improvements and bugs. This notice is intended to inform users that individual support requests have to be handled via our ticket system, this policy has not changed.

Your feedback is appreciated, thank you and we are always open to your suggestions.

Regards,

ABuenger wrote: And your feedback to our feedback (requests) would also be appreciated. You never know if (even small) requests will be incorporated in the next version.

Thanks for your feedback to my feedback . What would you like to see done differently from what we are doing now? We could create a product road map or maybe could go back thru each forum post as features are added and post "Added to next release"? We are open to any suggestions or ideas that you have, but updating old forum posts may be very time consuming.

ABuenger wrote: Almost 6 month now since the last release and we still don't know what we get for our renewed subscription. How do you expect us to plan our software releases? Waste our resources on features that might be incorporated in the next XTP release?

It has only been 2 MONTHS since our last release and NOT 6 months, see what's new page.

Your subscription covers TECHNICAL SUPPORT and not just PRODUCT UPDATES. That is why I posted this topic about support policy so everyone knows that we can only provide technical support to customers that have an active subscription.

Our target goal for product release is 2 major versions each year. This is in addition to any maintenance versions that may be released. The next release is scheduled for around June / July 2009 time line.

ABuenger wrote: I hope that 13.1 has some major features, because currently it seems like you have a "disinvestment strategy".

Actually you couldnt be further from the truth, we are working very hard on the next release. As I mentioned above, please give some ideas what information you want from us and how you want it delievered (forums, dedicated web page, etc.).

I'd like to take this opportunity to request something that I've seen requested a few times before. Better documentation. (help file)

Don't get me wrong. I think CJ is the best gui toolkit available, and the support is second to none. The documentation, though, could greatly be improved. I own several 3rd party development libraries, and the documentation on all of them is terrific. With CJ, though, I find myself searching the forums and the examples to discover how to use certain features of the library. I shouldn't have to do this... it should be spelled out in the documentation HOW to use all the different features in the library. Having more detailed documentation would also reduce the number of posts in the forum, since many posts would be answered by better documentation.

Other than that, keep up the great work!

Agree with ABuenger. Many users in here have great knowledge of the XTP framework, so asking in this forum often yields a solution for a given problem within a couple of days.

ABuenger wrote: Support wrote: We could create a product road map or maybe could go back thru each forum post as features are added and post "Added to next release"? We are open to any suggestions or ideas that you have, but updating old forum posts may be very time consuming. A product roadmap would be great. If you are looking for biannual releases than post the roadmap 3 month in advance so that we can refine our requirements and then a Beta 1 Month in advance. This allows you to be ahead of your competitors and us to plan our releases better.

My two cents...

I would like to see some kind of roadmap...It doesn't have to be super detailed, but it would be very valuable to be able to have an idea of what is coming down the pipe. This would help the decision making process in regard to our products own futures. For example, knowing whether input objects will be coming to the ActiveX markup implementation would change whether I focus on certain parts of the UI of my software right now or not. I agree with ABuenger that the advance Betas are necessary...They help us experiment a bit and I'm happy to help squash bugs...

The other reason the roadmap would be nice is to keep our expectations in check. I saw a post from SuperMario along the lines of "Just wait, 2009 is going to be a good year" (paraphrased), and then 13.0 came out and it basically felt like a maintenance release (at least the ActiveX suite).

In regard to documentation, I don't want a lot of resources thrown at it, but one thing that would be nice is that if it were broken into separate files for each product. Currently searching is basically useless when the index shows dozens of like named pages. It would be great if pressing F1 in the VB6 IDE took you to the appropriate page in the help file (instead of just saying "Unable to display help"), but perhaps this is too big a job, so I can continue to live without it. The samples are great, but some better comments might be useful...

It would also be nice if the ActiveX suite was kept on par with the MFC suite...there are things missing from the ActiveX suite that would be very useful (like the Explorer List & Tree, and IP entry for the PropertyGrid, the ability to interact with the frame caption area with CommandBars, amongst others). Sometimes it feels like we are second class citizens in the ActiveX/VB6 world (okay, maybe we are ;)).

Overall, I really hope this new support decision doesn't hurt the forums too badly, because they are definitely a competitive advantage for Codejock...I often find myself wishing that other control vendors that I have licensed with would have such an active, vibrant and helpful community (if they offer a forum at all).

SuperMario wrote: jpbro wrote: The other reason the roadmap would be nice is to keep our expectations in check. I saw a post from SuperMario along the lines of "Just wait, 2009 is going to be a good year" (paraphrased), and then 13.0 came out and it basically felt like a maintenance release (at least the ActiveX suite). You will see, it will be good.  2009 is far from over.

Hi

SuperMario wrote: I assure you that we have no plans to stop MFC and ActiveX development

znakeeye wrote: My sixth sense tells me we are about to see a Fish Eye button in the next release.

As long as they don't call it Fish Eye button ....

http://forum.codejock.com/forum_posts.asp?TID=14129

terrym wrote: ABuenger wrote: http://forum.codejock.com/forum_posts.asp?TID=14129   Cheers :)  Not sure we've got use for that, but you never know in the future ;)

The whole issue of resources used for support, documentation etc etc is a very difficult one to get a correct balance.

For my part, we've been operating help desk and support forums for many years now. It took us a while, but eventually we came to a realisation:

Customer's won't buy your product if they can't get it working.

For this reason we offer whatever support is required to all-comers.

As for forums vs private tickets. Both have advantages and disadvantages. Private tickets are just that - private. Others can't benefit from them. If you have a widespread problem, it can be better to solve it in the forums, so others can learn of it. However, not all customers frequent the forums, many prefer a more personal approach via help-desk. You can also better track how many people are experiencing a problem if they all submit a support ticket, and re-using responses can make responding quite efficient.

As for documentation, perhaps an MSDN-online approach should be considered. The problem with shipping docs, is that they go out of date. Online solutions like MSDN allow for some great advantages, such as community contribution, and you can address issues that come up by tweaking your documentation and then you only need to do it once. A wiki is another option, although it really needs some form of overall document structure and navigation. There are wikis that provide this.

In the end, from a developer's standpoint, you want to consume the minimum developer resources in support you can. Anything you can do to reduce the amount of time your expensive devs need to spend on support is time they can then spend improving the product to overtake your competitors and benefit your customers.

But again you don't want to go too far the other way either, since if devs are completely isolated from support they don't see and fix problems the same. We found when we had our devs isolated we didn't know what problems were happening in a timely manner (support always tried to deal with them for a long time first) nor how big the problem was (how many people it was affecting and in what way), so our priorities couldn't be aligned to that. So we have a policy for the amount of time a ticket can be running before escalated to dev.

We also find that devs patrolling the forums is a great way to get new ideas for development, and this can come from any source.

It's always tempting to say only support for paid customers, but my experience is that it costs you money in the end. The best approach we've found so far (and we aren't anywhere near perfect) is to minimise the amount of support required. Keep in mind with CJ that the target market are devs. We've all been there so most (certainly on these forums) I've seen are very reasonable, accomodating, knowledgeable and helpful people.

just my 2c, thanks for all your hard work guys, we already renewed since for us it's a complete no-brainer.