Microsoft & .NET.NETAvoiding Annoying Mistakes in Your ASP.NET Web Applications

Avoiding Annoying Mistakes in Your ASP.NET Web Applications

Thinking about technology alone, developing a feature-rich, performing, and secure ASP.NET web application is a challenge. However, a great web application is not just about backend code; instead, it is a combination of skillful design and coding.

In this article, you will learn to tackle subtle, yet common, web application mistakes, and thus create cleaner, easier to use ASP.NET web applications. Although some of the mistakes are not specifically tied only to to ASP.NET applications, the solutions given will use C# code.

However, you should keep in mind that this kind of article is not a complete list of all possible design and development oversights that can exist in ASP.NET applications. Instead, the focus is on issues that users commonly encounter, but are not generally listed on higher-level design fault lists.

Note: This article talks mostly from the perspective of a global web sites open to everybody. Of course, you might be developing your ASP.NET web applications for a very limited audience. In these situations, not every annoyance listed here might apply.

Ten Common, Six Smaller but Yet Annoying

If you do a quick search with Google, Yahoo!, or Live about web design, you might find lists such as those shown in Listing 1.

Listing 1: High-level web application design mistakes.

  1. Not taking into account different browsers and operating systems.
  2. Creating invalid (X)HTML code, and/or using deprecated tags.
  3. Failing to bake security in from the start: not validating parameters, and allowing code injection.
  4. Creating sites in Flash only (would apply to Silverlight sites as well).
  5. Using tables for visual layout.
  6. Trying to detect the browser version (incorrectly).
  7. Using too many popup windows, which fail in many browsers.
  8. Naming CSS styles after what they look like rather than what they represent (for instance, green_checkmark vs. feature_enabled in a feature comparison table).
  9. Making a web page of fixed width, and then specifying it too wide.
  10. Using JavaScript to move and resize browser windows.

Such general lists often mention that you should make sure your web application runs on all major browsers, generates valid HTML, and so forth. Of course, these are important rules. Nevertheless, sometimes the smallest of the annoyances irritate users most, and so you should not forget being a little pedantic and tackling even the smallest details.

Next, you will learn about six small mistakes that are easy to solve, yet are irritatingly common. These are summarized in Listing 2.

Listing 2: Those small, yet annoying mistakes often overlooked.

  1. Failing to accept input with spaces, and not trimming spaces properly.
  2. Using too much JavaScript.
  3. Forgetting that other nationalities exist.
  4. Disabling the backward and forward browser buttons.
  5. Using browser windows and tabs the wrong way.
  6. Trying to be clever with language and/or country-of-origin detection.

Getting the Little Things Right: Spacing

You can start with a concrete example of such small things. Say your web application accepts credit card payments by allowing the user to enter his or her credit card number and expiry date. However, it is quite common for such web shops to fail the credit card authorization if the user enters spaces between the credit card numbers.

In the worst case, the web application simply gives the user an error message such as “Invalid credit card number.” This can be very annoying, especially because the credit card itself has the number punched in groups of four digits.

To avoid this, you should develop your web application so that it accepts the card with or without spaces in the middle. The .NET String class contains a convenient Trim method, but this method only trims spaces from the beginning and end of the given string. What you need is a method that removes spaces from everywhere in the string.

Probably the simplest way to do this is to use the String class’ Replace method, like so:

string creditCardNum = " 1234 1929 5922   9289 ";
string trimmedNum = creditCardNum.Replace(" ", "");

If you are already using C# 3.0, you could even create a static extension method to the String class and name it, for example, TrimWithMiddle (note the this keyword in the parameter specification):

internal static class MyStringExtensions
   internal static string TrimWithMiddle(this string input)
      string trimmed = input.Replace(" ", "");
      return trimmed;

Then, you could call this method by using any string variable without the need to remember special utility classes: “creditCardNum.TrimWithMiddle()”.

Too Much JavaScript Is Too Much

Many web sites today would not function without JavaScript support enabled, and indeed many web sites benefit greatly from scripting. For example, things like complex interactivity, slick user interfaces, and rich-client like data validation often mandate the use of JavaScript.

However, JavaScript is prone to errors, and not all web browsers support it exactly the same way. There are hundreds of web applications out there that require JavaScript to be enabled, but still contain errors. In the worst situation, the user is filling his or her contact details on a shopping site, and then finds s/he cannot complete the order because the web site didn’t create valid JavaScript for his or her browser.

How would you avoid such failures? The solution is not to rely on JavaScript in key functions, such as order processing. JavaScript is a great aid, but make sure data validation (and so on) also happen on the server.

By default, ASP.NET applications support the combination of both JavaScript and server-side based data validation, but for sites that are more complex, you might need to write custom code. In these cases, it is best not to interfere with the normal form processing that web browsers do. That is, keep the buttons (the submit button in HTML parlance) as they are, and avoid the “not invented here” anti-pattern.

In ASP.NET web applications, a basic button (an instance of the System.Web.UI.WebControls.Button class) creates the following HTML code:

<input type="submit"
       value="My Button"
       id="MyButton" />

If you need to verify at submit time that all mandatory fields are filled in, use the ASP.NET validator classes. An example of these classes is the RequiredFieldValidator class. If you enable its EnableClientScript property, ASP.NET will generate valid JavaScript code to do validation in the browser.

You also can use the validator classes at the server side to check whether the form fields had valid values by either using the page class’ IsValid property, or the similarly named properties on each individual validator class.

Remember, the World Is Round

The Internet is a serious test for proper globalization. It is easy to develop web applications that are focused on your own nationality, but it is much harder to make sure people from all nations would be able to use your web site, even if you would keep it in English.

Address details and phone numbers are good examples of globalization issues that you must keep in mind when writing web applications for public use. For example, many web sites allow the user to fill in a form, and then expect somebody from the company to contact the user.

It sounds easy enough to develop such a form, but sometimes, developers cannot resist the temptation to over-engineer. The classic example is the selection of state in contact detail forms. Very often the state is marked as a mandatory field, but not all countries have states. Similarly, phone numbers might be expected to be entered in a certain format—for example requiring a three-number area code when many countries around the world do not have it.

ASP.NET doesn’t have a ready-made telephone number entering field; therefore, a regular textbox would do in most situations. In many cases, a simple textbox without too much formatting checks would work best. If you must make sure the format is correct, only accept for example numbers, spaces, parenthesis, and the plus sign in the number, nothing more. The .NET Regex class from the System.Text.RegularExpressions namespace is a good way to make sure the given input string is valid.

Failing to Support Backward and Forward Navigation

When comparing generic Windows applications and web applications, maintaining state and navigation is one key difference between these two application types. Web browsers allow the user to navigate backward and forward in the web pages they surf, and this happens to be the way web browsing is taught in schools and educational institutions.

However, from a web application design perspective, this backward and forward navigation can be an issue. The traditional example in interactive web applications (versus static pages) is the shopping cart: When you update the contents of the shopping cart, you will generally move to a new page. If you now click the back button on your browser, you will get the older page, which now displays incorrect information. Does the user realize that this just happened?

For these kind of reasons, the backward and forward buttons are effectively disabled in many web applications. One solution is to use JavaScript to disable the navigation, and another is to make sure the web browser won’t cache the data. It is hard to decide which of these two is more irritating to the user, because both can be.

Thus, you should spend time designing how your application ought to work. In ASP.NET web applications, you can use the HTTP 1.1 protocol “Cache-Control: no-store” directive to specify that the browser must not cache the returned page, and instead must always refresh it from the server.

It is easy to add this directive to the server response by calling Response.Cache.SetNoStore in the ASP.NET page code (the older Response.Expires property has been deprecated), but this quickly leads to problems if you use the POST HTTP method (ASP.NET uses this by default for postbacks). However, for regular GET requests, the SetNoStore method works well, if you do not consider additional server load to be a problem.

That said, your basic rule of thumb should be not to interfere with the backward and forward buttons, unless confusion is likely to occur (think the shopping cart). GET requests work best, because the web browsers usually display a message box before navigating back to a POST page if the SetNoStore method has been called. It is also worth noting that the “Cache-Control” directive requires HTTP 1.1.

Incorrect Usage of Browser Windows and Tabs

Not so long ago, web browsers only had the notion of a single page, and the only option to display two or more web pages at the same time was to open new browser windows. This possibility quickly led to the popup window craze, and in turn created a lucrative business opportunity to sell popup blocker software.

However, with all the major web browsers now supporting tabbed browsing, it is time to adapt web applications accordingly. That is, many web sites still can open popup windows, when the user might have opted to use tabs instead. For example, in Internet Explorer 7, you can specify whether popup windows should be opened in windows or tabs.

The key thing is to let the user choose. If the user prefers tabs, do not force him or her to see popup windows. When creating HTML links, the A tag’s target attribute is the key to specifying whether a link should open in a new windows or tab, depending on user’s preferences. For instance, this link would open the target page in a new browser window or tab:

<a href="mywebform.aspx" target="_blank">Link to a popup window</a>

If you were to use the ASP.NET Hyperlink control, then you could write code like this:

MyHyperLink.NavigateUrl = "mywebform.aspx";
MyHyperLink.Target      = "_blank";

However, it is worth noting that the target attribute isn’t anymore part of the XHTML “Strict” DTD (Document Type Definition), which implies it will be phased out at some point in the future. Thus, you should try to avoid using it in new web applications, especially if you write XHTML-compatible code.

Furthermore, it is important to remember that the user can click the links in your web applications together with modifier keys. For instance, Internet Explorer 7 and Firefox both support clicking links with the Shift and Ctrl keys pressed down. The former key would open the link in a new window, and the latter in a new tab.

Once the users discover this somewhat hidden feature in their browsers, they generally love it. Unfortunately, many web applications, especially those with heavy, frame-link menu systems, fail to work with the Ctrl key. If this won’t work, your users might consider your web application inefficient to use, and could even change to another site.

The lesson is to make sure your web applications work the way users expect. In this case, it is often best to let the user choose, and not choose on their behalf.

Correctly Determine the User’s Location

Web applications have become more sophisticated, and the best web sites are able to “guess” the user’s place of origin and display content based on that information. For instance, a news web page could display local news based on the user’s geographic location.

There are two major ways to do this. Firstly, you could sniff the user’s language or locale (often part of the HTTP request fields), or you could purchase a map of IP addresses mapped to geographic locations. For example, MaxMind’s GeoIP and GeoLite are products that contain a database that maps IP addresses to countries or even cities.

Although such databases can be great, you should not rely on them one hundred percent. Furthermore, you should always provide the user the option to easily change his or her location information. For example, think a businessman traveling abroad and picking up a hotel WLAN connection. In this case, his IP address would say he is in Berlin, Germany, when he would like to see his local news in London, UK. If the news page would only use the IP address to location mapping as its only source of information, the user could become irritated because the web site tries to be smarter than it actually is.

Similarly, if you are going to detect the user’s language, you can use the ASP.NET’s Request.UserLanguages array of strings. But even if you do this detection, still let the user choose the language he or she wants to see. It’s better to be safe than sorry.


In this article, you looked at small, yet unfortunately common web application mistakes. These mistakes are not actual shop stoppers if your ASP.NET web site is otherwise working correctly, but in the end keeping the users happy should be your main objective.

Although many, many issues could be listed in these kinds of articles, starting with these six problems and fixing them would raise your web site’s usability. Then again, it is worth remembering that overall correctness is more important than the little details. But once you get them right, the devil could be in the details.

About the Author

Jani Järvinen is a software development trainer and consultant in Finland. He is a Microsoft C# MVP and has written dozens of magazine articles and published three books about software development. He is a group leader of a Finnish software development expert group at His frequently updated blog can be found at You can send him mail by clicking on his name at the top of the article.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories