A colleague on the project I am currently working on suggested we should have an auto-reply on the email address our web app uses to send email to users. My initial reaction was that it was a waste of time, and no one would see it, as clearly everyone was going to see the email address (no-reply@....), and know to not reply to it.
In the intervening few days, I have re-assessed my initial hesitance. In part it was due to the post from Jeff Atwood (This Is All Your App Is: a Collection of Tiny Details), I recommend reading that. My personal take away was "Getting the details right is the difference between something that delights, and something customers tolerate." Take the old adage, look after the cents, and the dollars will look after themselves. That is as applicable to your application as it is to most things, pay attention to the little things, and the rest will look after itself.
Another great point on this issue was this TED talk given by Renny Gleeson, where he runs through a selection of great 404 pages. Imagine taking what is generally a horrible experience (an error page), and transforming it into a great experience for your customers.
So back to our auto-replier. This gives your business a great touch-point to the customer. A chance to turn a potentially bad experience into a good one. The opportunity to direct them to the right channel, or even better still, a real person can get in touch with them and sort out the issue.
When it comes down to it, it is the small experiences that make the difference. You should focus on making every little interaction that a customer has with your application as great as possible.
I recently came across a problem in an application i’m working on where we had a modal dialog being opened, with the contents coming from a jQuery ajax request. In general this was working fine, however while testing I came across an issue where, randomly, the dialog did not show up. Further investigation revealed this to be due to the session expiring, and therefore the user losing authentication.
When using jQuery ajax, that results in a 302, the browser tends to act on the 302 before jQuery gets a chance to examine the HTTP status.This has been solved before in many different ways. However none of them seemed generic enough, and each had issues, for example, any 302 resulted in the user being redirected to the sign in page if the 302 is the result of an ajax call.
Our final solution to the problem involved creating our own HTTP status (308, which is currently unused), and sending that back. So, on to the code.
Firstly in your global.asax file, we need to intercept ajax sourced 302’s. Once we have identified those requests, clear the response, and set our status code to our pretend code of 308.
protected void Application_EndRequest()
{
var context = new HttpContextWrapper(Context);
if (Context.Response.StatusCode == 302 && context.Request.IsAjaxRequest())
{
Context.Response.Clear();
Context.Response.StatusCode = 308;
}
}
Now to deal with this nicely in your jQuery calls, make sure you have a generic scripts.js file on every page to collate all your general scripts, and add the below.
$(document).ajaxError(function (e, request, errorThrown, exception) {
if (request.status == "308") {
window.location = request.getResponseHeader('location');
}
});
Here, we bind the ajaxError function to our own custom function so that we can deal with these little 308 responses. This function will get called every time jQuery encounters an error in the ajax call (jQuery treats everything other than an Http200/ok as an error). We check for our 308 status, and if that’s the case, redirect the user to the location as set by the redirect.
So this works perfectly for every case we have encountered so far, MVC controller redirects, authentication fails etc.
Hoping this helps somebody.
Console.WriteLine("Hello world");
I wanted to start this blog with a quick introduction. My name is Chris and im a .Net dev based in Hamilton, New Zealand. I do a bunch of web stuff (Webforms & MVC), with the odd bit of WPF/WinForms thrown in for fun. So in general my posts are going to be about C#, MVC, WPF, Webforms, JavaScript/jQuery and the odd other tidbit as well.
So what will I be posting?
Essentially if I have any issues while doing my day-to-day that I think may be useful for you lot, i’ll post it and it can hang around as a reference. From time to time i’ll post some thoughts on testing, and architecture, and UX. If i’m playing with some cool new stuff, i’ll probably post what i’ve made, and my thoughts. There will be the odd how-to post as well.