aspnet considerations top image 870x220

In this 5-step guide, Jeff Hadfield helps you select and implement the right commercial ASP.NET controls as efficiently as possible so you can get back to coding. 

You’re a development professional, which you’d think means you get to spend all day developing software. Instead, your time is often hijacked by meetings, coordination, communication, and choosing the right development tools.

I’ve created this guide to help you select and implement the right commercial ASP.NET controls in the most efficient way possible. I’ve created this guide to help you get back to developing software as soon as possible, confident in your controls choice.

That’s the challenge, isn’t it? Your job is to get the project done. You need to deliver reliable, secure, user-friendly sites on time. You know that using commercial controls and tools can speed that process, but sometimes having to choose those tools makes it seem overwhelming and not worth the time.

While it’s posted on the Progress Telerik blog, that’s not what this guide is about. (Go ahead and put them to the test: you decide.) Instead, I’ll share a framework for making a solid, defensible choice for your ASP.NET controls vendor and products.

Let’s get started.

Your Decision Framework

Before we dig into the details, it’s important to understand the process. Many guides suggest that you start with a list of potential vendors. We don’t. Here’s why.

If you know what you need before you shop for vendors and products, your process of searching and selecting will go much more easily. It’s like going to the hardware store and wanting to build a shed before you decide what you’re going to use it for, how big it’s going to be, what kind of weather it needs to withstand, what kinds of features it should have (windows, power, etc.), and how much you’ll need to customize it.

It’s the same with your ASP.NET controls: when you know what you’re planning to build, you can better define your needs, and thereby better know what tools you need.

So our decision framework looks like this:

Descision Framework

 

We’ll discuss each of these steps in the following sections.

Step 1. Determine Needs

Before we search for products and vendors, we need to know what we need those products and vendors to do for us. It’s essential to start with this needs analysis: by doing it first in the process, you’re less likely to make a critical error when you’re in the final selection, or, worse, after adoption.

If you’re addressing a specific need for a specific project, list those needs first. Then, be practical: how might you use the tools in the future, and for other projects you see coming down the pipeline? Do you need flexibility for use in other projects?

Now, here’s where the time spent early in the process pays dividends later. Here’s a list of questions you should ask yourself while listing needs. All may not apply to you, but many will, and hopefully will help you consider all aspects of your upcoming controls purchase.

  • What languages do you need your controls to support? What IDEs and platforms do you need it to work with? For example, if your team has standardized on Visual Studio, you may give higher precedence to a vendor and toolset designed to work with VS.
  • Who’s planning to use the tools? Just you? A team? Your whole company? Who will need to be involved in licensing and the purchase, and do they have any guidelines or recommendations you need to consider?
  • We’re listing this early in the list because in today’s world, it’s essential. What security considerations do you need? Is it to be used internally or externally, and are there company policies or technologies you need to ensure compatibility with?
  • What’s your policy about source code? Do you just prefer, or does your company require access to the source code of any control you purchase? Does the customization you have in mind require access to the source code itself? In some cases, source code escrow is sufficient: where you don’t have direct access to the source code, but were anything to happen to the vendor, you’d receive the source code for your licensed products to ensure business continuity.
  • Consider vendor reliability. Is this a small, one-off project you don’t plan to maintain, so it’s OK if you just get some code from GitHub and call it good? In most businesses, the answer to that is no. Instead, ask yourself: would you prefer an ongoing relationship with support, updates, and so on? And if something happens to the vendor, what happens to your code? Is there, as discussed above, source code escrow so your controls continue to work, or are alternate controls relatively easy to swap in?
  • What kinds of pricing models are you comfortable with? Do you prefer a one-time price or a subscription? (Most commercial controls operate on a subscription basis.) What happens if you let your subscription expire? Do the controls stop working when your subscription ends, or do updates and support simply cease? Does the licensing agreement require royalties if you are reselling software that uses the controls?
  • What’s your expectation for the controls’ general features? Do you need a grid control now and perhaps others in the future? What are the absolute must-haves for functionality? Do the controls support mobile, responsive, and touch UIs? Similarly, do the controls include accessibility and localization capabilities?
  • How frequently do you update your app, and how frequently are the controls updated? Since no software project is ever “done,” thanks to bug fixes and feature requests, does the vendor’s update cadence match that of your projects sufficiently well? Is the vendor responsive to security and feature concerns, regularly updating its controls, and providing an easy way for you to implement those updates?
  • What versions do you need the controls to be compatible with? Are you maintaining or updating a legacy app? Which versions of ASP.NET do you need to be supported?

Whew! That should give you the scope of what you should consider as you evaluate your needs. The aim was not to cover everything you could possibly consider, but instead to help you work through the process of asking crucial questions. Notice that many were business-related: those have a tendency to torpedo even technically valid products, so it’s better to know what to consider early on.

Once you’ve made that list, we recommend you take a moment before we move on to the next step and prioritize it by essential, nice to have, and nice but not essential, or whatever variation of those works best for you. It’ll be useful as we hit future steps.

Step 2: Find Vendors and Products

In this step, you’ll make a big list of potential products and vendors. It’s easy to spend too much time on this step because there’s always one more link to look at… but resist the temptation. Instead, allocate a finite amount of time to spend on this step: say, no more than three hours.

For your search, consider these sources:

  • General web searches
  • Yours and colleagues’ experience
  • Friends recommendations
  • Reviews and publications
  • Partner listings

A spreadsheet is helpful: you may want to create one that includes data like product, vendor, website, source (as listed above), and any notes that occur to you during this first pass.

List all the products that look even a little viable: you’re making the big, comprehensive list, not evaluating. Keep this step as short as possible, since in the next step you’ll be narrowing this list dramatically.

Step 3: Create Your Shortlist

Now that you’ve created your master list of potential products, it’s time to narrow that list to something manageable. Our goal here: a list of no more than three products.

We recommend you work your way methodically through the list, with an initial pass through the list to eliminate products and vendors who don’t fit these critical characteristics:

  • Microsoft partners (they’re getting early access to technology and have direct support from Microsoft)
  • Established vendors (they’re more likely to be around when you need them - and in a few years)
  • Those with active community support (on their site or on sites like Stack Overflow)
  • Full trial or evaluation software with full support before buying
  • Any product or vendor who otherwise raises a “caution” flag in your mind - like hidden pricing, unprofessional sites, unclear features, and so on.

That should knock off a major chunk of the list. Now, compare the remaining products and vendors to the priority list you made in Step 1. Of course, the essential characteristics are showstoppers: if the products don’t have those, you eliminate them from the list.

The goal of this more detailed review is to get your list down to no more than three products for your final evaluation, so go as deep as you need to to achieve that. Why three? First, that’s why we laid out the detailed needs analysis in the first step: so you wouldn’t waste time deeply evaluating products that wouldn’t match your needs. Also, if your project is of any decent size, you won’t be wanting to build a proof of concept for more than three. And, practically speaking, anyone reviewing or approving your recommendations won’t really want to deal with an in-depth review of more than three, either.

Thus, do all the research you need to to narrow the longer list to your shortlist of no more than three products to take to the next step. We’re getting there!

Step 4: Evaluate

Before we begin this step, just a reminder: take good notes during your evaluations. In most situations, you’ll be sharing your observations and assessments with others for feedback or purchase approval, so the better your assessment, the more likely you are to get buy-in.

For each of your no-more-than-three final candidates, you’ll want to download the free trial or evaluation software and register for support. In each case, if possible, try implementing the controls in your same sample app (even a fork of your current codebase). If that’s impractical, you can find sample code from the vendors that approximates what you’re trying to do.

Be sure to reach out to each vendor to gauge the responsiveness and helpfulness of support, including online knowledgebase, any community forums, and, of course, human support via chat, phone, etc.

Since you likely had to register for support, if not also to download the trial software, odds are that a member of the software vendor’s sales team has also reached out to you. You’re at the stage of your evaluation that talking with one of the technical sales folks is a good idea, so go ahead and have a conversation with them. The quality of that conversation should be factored into your final assessment.

Consider how those customization capabilities are implemented. Are the straightforward? Do they use configuration wizards? Is the API straightforward? As mentioned before, be sure to test and use documentation, samples, and support.

And since we’re talking about ASP.NET controls, we can’t overlook one of the most critical factors for Web sites and apps: performance. Make sure the controls are not unnecessarily slowing down your pages and are as lightweight as possible. Especially for e-commerce sites, every millisecond delay in page load represents lost revenue.

For each of your final three candidates, be sure to note less objective things, too. Those might include how easy to use the products seemed to be, how intuitive it seemed, and even how attractive the controls were and if they were complementary to your UI design. Consider how each products’ conventions and nomenclature line up with with what you’re used to using, or are easily parsable. Note how much customization you need to do with each to make it do what you want. While it’s nice to have unlimited customization capabilities, by the same token, you don’t want to have to customize everything every time.

In your summary spreadsheet, if it works for you, add point values, color codes, emojis, or whatever makes it easiest for you to do a final tabulation and summary.

Summarize your findings, recommend the best, and get sign off from any stakeholders: your team, manager, etc.

Step 5: Buy and Go

Since this guide covers how to choose the best ASP.NET controls for you, not how to implement them, this section will be brief. Remember to rely on your vendor, however, and get the support you paid for, especially with the initial implementation. Your vendor, too, wants you to be successful.

Good luck and happy coding.


Jeff Hadfield
About the Author

Jeff Hadfield

Jeff has worked as a developer and with developers since last century. He has served developers as part of CodeProject, Visual Studio Magazine, VSLive!, JavaPro magazine, Enterprise Architect magazine, VBPJ and many more. He now works with clients around the world focused on the developer market to help them better serve developers and their unique needs. He enjoys working with technical teams, music, family and herding his dim but sweet herd of canines.

Related Posts

Comments

Comments are disabled in preview mode.