So you've made the decision. You're going with Kendo UI. Great choice! :)

As you venture out into the wildnerness of building software that solves real world problems, you are probably going to have some moments of crisis. That's what we do! We're developers by god. We come up against the issues that nobody can solve and we find a way through.

How To Get Help

Now that you have Kendo UI as your partner, we're here to help you through these times of crisis. When you run into a roadblock (sometimes right away), there are a few good steps to go through to get a quick and timely resolution. I call this the FAST system for Kendo UI success!

  1. irst Check The Basics
  2. sk Google
  3. earch the forums
  4. ime for a ticket

First, Check The Basics

There are some very simple things you can check right away to make sure you haven't missed something very simple.

  • Did you include jQuery?
    • Don't include jQuery more than one time!
  • Did you include Kendo UI?
    • Don't include kendo.all.js AND kendo.web.js
  • Did you include jQuery BEFORE Kendo UI?
  • Did you include all of the correct Kendo UI CSS and assets?
  • Did you check your browser developer tools for errors or other problems?

Some of these seem too simple and frankly laughable, but I do this ALL THE TIME. Something isn't working. I spend 30 minutes and finally realize that I have included the wrong file or files in the wrong order. When in doubt, refer to the Getting Started documentation. Read through it from start to finish. Don't scan. You will be shocked at how many of your issues can be resolved by a quick read through of these guides.

Another quick check for basics is to look at the demos.kendoui.com site. We've put together an exhaustive list of demos to help you in virtually any and every scenario. Not only does this showcase the capabilities of Kendo UI, but it doubles as a invaluable resource of code and "how did they do that" samples. Ever notice most of the demos include wrapper and server side code?

Of course, we can't forget the docs. Reading documentation is never fun, but we've been refining our docs over the past year and a half to provide better description, more code samples, and easier discoverability.

Ask Google

You've checked the basics. Everything looks good. Now what? Sometimes a quick Google search can solve your problem. For instance, I once got confused about how I could add a bunch of items to a Kendo UI DataSource without having to add them one at a time. I checked the docs, and there was no method for it in Kendo UI. So I googled it.

adding multiple items to a Kendo UI DataSource

StackOverflow to the rescue. Emiliano, our Kendo UI MVP had the solution for this one and it works great! I liked it so much, that I wrote a blog post on it.

Kendo UI has an enormous user base, so you will be surprised at the availability of information. If you have a question now, chances are someone else has already had that question and posted it on StackOverflow.

Search The Kendo UI Forums

Sometimes you can't find what you need from Google or StackOverflow. You can then check the forums. For instance, I once wondered if it was possible for me to show the "loading" indicator in Kendo UI Web with JavaScript. Sure enough, Atanas Korchev from the team had already answered this one, and a quick search of the forums got me the answer.

I liked that one so much that I tweeted about it!

Open A Support Ticket

You've checked the basics, asked Google, and searched the forums. Much like U2, you still haven't found what you're looking for. You need a second pair of eyes. Since you are a Kendo UI customer, you have the luxury of that second pair of eyes belonging to an engineer from the Kendo UI team. That's right. The same engineers that write the code are the ones that answer support tickets.

Getting Your Ticket Answered NOW

Time is our most precious non-renewable resource. I used to work with a development manager who would tell our stakeholders "You can have it ontime, cheap, or done right. Choose two." This means that your back is usually against a wall, and every second you burn stuck on an issue is excruciating when you look at your deadlines. We know EXACTLTY what that feels like. We release three times a year with a service pack between each major release. We know deadlines.

Telerik has an exceptional history of support. It is unparalleled in the industry. You usually have a 24 hour guaranteed response time on your ticket (depending on product and package). That's fast considering you are getting direct access to an engineer, but every back and forth that you have with the support team takes up valuable time. You need to make the most of your ticket the first time. You need that first response from the team to contain your answer, not a request for more information.

The trick to obtaining a "one response resolution", is to give as much information as you can about your issue in your ticket when you initially submit it. If you are able to do this, it will pay huge dividends for you in terms of success in getting your questions answered in the first 1 to 2 exchanges. We use this strategy internally and it is a thing of beauty. Here is how it works.

Provide a concise explanation of your issue

This seems logical, but sometimes it's hard to just vocalize the issue. Primarily because you may not be sure exactly what it is. The best way to think about this is like this: "What is it that I think should be happening vs what is actually happening?".

For instance, lets say I have an issue with MVVM. I have a simple piece of code that isn't updating. It's tempting to phrase the problem as "My model is updating with the page". However, a better explanation might look like this...

I have an MVVM Observable with 3 fields. The first two fields update correctly when I change the UI, but the third field does not. Why does the third field in this model not get updated?

Notice how I made that last sentence bold? It draws the eye to the main issue. It also helps you to exercise condensing your issue down into a quickly digestable scenario by virtually anyone who reads it.

Provide A Runnable Recreation Of Your Issue

The great thing about Kendo UI is that it's just HTML, CSS and JavaScript. That means you can use one of the many online code editors to share a working sample of your issue with comments! You can show someone EXACTLY what isn't working the way you think it should. This is the most important thing you can do to clearly demonstrate your issue.

For instance, along with my MVVM question, I could include a runnable JSBin that shows exactly the issue that I'm facing and put comments where I think things are going wrong.

JSBin is GREAT! It's also the preferred way to share code with the Engineering team. All you have to do is create a new JSBin, and then select the "Add Library" button and select the latest version of Kendo UI. It includes all of the files for you and in the right order. Everytime we have a major release, we update JSBin so it always shows the past two releases. This means it's always up-to-date!

But My Project Is HUGE!

Most real world projects are. Rarely do you get to use something as clean as the Northwind database. However, you almost always can replicate your issue on a very fundamental level by pulling out the relevant pieces. This not only removes clutter and helps you focus, but also makes it 1K times easier to create your sample.

On top of that, you stand a VERY good chance of solving your own issue just going through the excercise of recreating it. Honest. When I am about to email the team with an issue I'm having, I create a JSBin replicating the problem. About 8 times out of 10, I find my own issue in the process and the email never gets sent. I also get my solution hours sooner!

But My Data Is A Core Part Of The Problem!

Often, your data is as wrapped up in your issue as Kendo UI is. The two become like conjoined twins, and it takes an act of surgery to show one without showing the other. You can't very well expose your data for the world to see. You also can't just zip up your terabyte Oracle database and email it over. So what now?

Again, the key here is to break this down into it's core pieces; replicate the essential data structure with as little effort as possible. You also don't want to go to the trouble of building a complete set of web services for the sole purpose of opening a ticket.

Here are a few ways to pull this off...

  • Use JSON Files to replicate your data with Plunker - Plunker is an online editor that has the special power of allowing you to actually create files for use in your project. This is great because you can just dump your JSON output from your services into a .json file and call it. No cross-domain issues. No database required.

  • Use an AJAX Mocking tool like MockJax - You can also just fake your data and the actual request itself using something like MockJax. MockJax is a JavaScript library that you simply include before any AJAX calls, and it will intercept them and return whatever you tell it to return. It's incredibly handy for mocking just bits and pieces of your service and data.

  • Public Northwind Service - Service stack actually exposes parts of the Northwind database for you to consume as a JSONP service. This means you can call it cross-domain without issue. For more information on same origin policy and xhr cross-domain restrictions, make sure you read MDN's great article on the subject.

Replicating your issue is no doubt the most time consuming part, but it's going to play the biggest role in your success at demonstrating your issue clearly the first time. It often feels easier to copy and paste the relevant portions of your code into the ticket. The problem with this approach is that the pieces have to be reassembled by somebody who doesn't know what the assembled creation is supposed to look like or accomplish. This is somewhat akin to having car trouble, dissasembling your car into it's peices and then taking them to the mechanic who then has to reassemble them. This is why you will frequently see people ask for a runnable example on sites like StackOverflow.

But I'm Using The .NET MVC Wrappers

In this case, JSBin, JSFiddle or Plunker are probably not an option. Your best bet is to create a simple .NET project that replicates your issue using as few files as possible. Of course, you still need your data. You can attach an express version of the Northwind Database. Even easier, you can use a static List<T>` and populate it with some sample data. Need to show persistance? Just use a simple session store. Here is a simple boilerplate you can use for creating this persisted static data.

Simple Session Persistance With List<T>

public IList<Product> Products() 
{
   var products = Session["products"] as IList<Product>;
 
   if (products == null)
   {
      products = new List<Product>
      {
        new Product
        {
        },
        new Product
        {
        }
      };
 
      Session["products"] = products;
   }
   return products;
}  

FAST Answers Are The BEST Answers!

As a Kendo UI customer, we are here for you. We want to partner in success. We are only successful when you are successful. We will stick with you as long as it takes to get your ticket resolved. We want you to help you be as productive as possible, and following these steps will lay a solid foundation for years of HTML5 success with Kendo UI!


Burke Holland is the Director of Developer Relations at Telerik
About the Author

Burke Holland

Burke Holland is a web developer living in Nashville, TN and the Director of Developer Relations at Telerik. He enjoys working with and meeting developers who are building mobile apps with jQuery / HTML5 and loves to hack on social API's. Burke works for Telerik as a Developer Advocate focusing on Kendo UI.

Related Posts

Comments

Comments are disabled in preview mode.