Brad Abrams recently posted tips he has for someone interviewing for a Program Manager position at Microsoft. In his post he references different questions and situations he likes to put candidates through. One section titled Design and Bahh Questions got me thinking not so much about the interview process, but how I might design a blender for a blind person. That train of thought caused me to jump tracks to designing software.
First, let me describe some thoughts I had on my new blender. First I would reduce the number of buttons to control speed. I can see fine with my glasses or contacts, but I think I rarely use more than 3 buttons; Stop, Fast and Slow. The other 50 or so are really just a waste of plastic to me. Ok, so that last statement is an over simplification, but serves a point. But reducing the choices allows me to utilize larger buttons. Larger buttons serve two purposes, easier to touch and more room for Braille. Despite the photo to the right, I would make sure the buttons were also ‘old school’, meaning they were buttons and not membranes. I am sure the tactile nature of membrane buttons is nice, but if you cant see the keyboard, that is very frustrating. Get up tonight, keep the kitchen lights off and make a milk shake and see what I am talking about.
The next feature I would certainly implement is some sort of locking mechanism for the top that must be secure before any of the blend buttons would actually start the blender. Remember the user cannot see if the top has been secured or not and we don’t want milkshake spewing all over the kitchen or worse yet a finger getting accidentally caught. I tried to think about some sort of audible feedback as to the blended state, but I think even I rely more on the sound of the blender to let me know when everything is good an liquefied!
So what does this have to do with designing software you ask? Quite a bit. I think most developers have above average computer IQs and problem solving skills. So we tend to have a higher success rate when learning how to successfully use software. But I know from personal experience there are still many web sites and software applications that I struggle learning how to use. Seriously if I cannot solve my problem or at least get a sense I can solve my problem in a few minutes of launching an application, without reading a manual, then I am on to the next solution. I hear the term discoverability mentioned a lot, which means a user can easily discover how to use an application and naturally discover more advanced features without having to try too hard.
Think about how much more this is the case for a normal person? I call this the Mom Factor (yes mom I am talking about you again). My mom is what I would consider to be pretty autonomous when it comes to using a computer, but she still calls me from time to time, asking how to do things. But there are many mothers, sisters, aunts, uncles, brothers, friends (do dads really call their sons for help, not sure about that one) out there that routinely call their geeks (that would probably be you) for help.
I have built hundreds of sites in the last decade, all in .NET since the summer of 2001. Back then I was in my first year of running my own thing and really starting to watch users learn to administer and interact with my web sites. I started learning a lot, mostly that normal folks don’t get it. I wont go into gory details today, but just because you or I just know what to enter in an input field does not mean a real user will. We must hold their hands.
Back to my blender, I would reduce the number of buttons and make the remaining buttons larger. That exact same principle can be seen on many modern web sites. You see large buttons, large input fields and reduced forms. Most modern sites make registration as simple as an E-Mail and Password. Then once you are registered you can add other information, etc. The Tumblr.com registration form is a good example of these very principles.
Another rule I learned early on is never assume anything, even if a field is clearly labeled. So I have learned to add input masks, tooltips and strict validation rules. All of these measures are placed on the client, or the browser, to guide users to the correct input. Hence, why I would force our blind user to close the lid before they could engage the motor. We have to validate data, on the client, in the middle and sometimes even in the data store. The data we work with has to have some sort of expected integrity. Users will enter the most unexpected stuff. I never thought the requirement for a date a few years back would mean ‘Summer’ would be entered by the user. So sometimes you have to clarify even what the most obvious requirement actually means.
We have to do this because we want users of our application to just know how to use our software. Microsoft says they just want developers to ‘Fall into the Pit of Success’, and this has to ring true with the software we ultimately create.
A few years ago I wrote a book review about Why Software Sucks by David Platt. The premise of the book, is as software developers we know how to build great applications from a functional perspective, but we suck at making it usable by normal people. It is a book I highly recommend all software development related professionals read.
When the book was first released I think the modern concepts of AJAX were really starting to emerge. AJAX has segued into user experience (UX, see there we go, being true geeks and creating another acronym). This is why developing modern software is not as simple as just dropping controls on a form, compile, test and ship anymore. The UI layer is a very complicated matter that we have to consider when developing any application. This is why I think code generation is so important. Platt points out that we can build fantastic backend logic to do all sorts of logical decision making for us, but we have not yet translated that energy to the front of the application, where the normal person lives.
To me the whole essence in WPF and Silverlight application development center not around the markup used to create the UX, but in the creative nature REQUIRED to build WPF and Silverlight applications. These modern UX requirements are not lost on AJAX sites as well. Just look at all the UX related plugins available for JQuery alone.
I have gotten interested in researching UX design patterns lately. Mostly these sites are a collection of common design elements we see all the time and give them a name. While they typically do not tell us how to create the effects, they are good references to see what is being used so you can begin to apply the principles to your sites.
So as you work on your applications think about how you are going to make a blender for the blind, or really do your best to think like your user. And think hard at the worst user scenario you can and plan for that. Make your application as much an extension of your user’s thought processes as you can.
One of the most common questions I see on ASP.NET forums relates to sending E-Mail. I have addressed many of those issues already, so I wont get into how to send E-Mail from an ASP.NET web site.
This week I have been working on testing applications and had a chance to meet Donovan Brown of Notion Solutions. Donovan is all about testing and has some fantastic tools to test all aspects of applications and is a Team System freak!! This afternoon I was having a great conversation when he mentions he created a little SMTP server to test E-Mail functionality called Neptune.
All you need to do is download Neptune from Donovan’s Blog, run the installer and then run Neptune whenever you need an SMTP server to receive E-Mail sent from your application.
You can either explicitly set the SMTP server in the SMTPClient or in the web.config to ‘localhost’ or ‘127.0.0.1’ and E-Mail will be sent to Neptune. It does not really process the message, only consumes it. So it does not relay the message anywhere and you do not have to have a preset E-Mail address configured. It is really point and shoot. Each time a message is sent to Neptune it increments the Messages count. It can be reset at anytime or stopped. Stopping the SMTP server is important to make sure you application fails gracefully when it cant reach the destination SMTP server.
Neptune supports commands from RFC 821 and 2821; HELO, EHLO, MAIL, RCPT, DATA, NOOP, RSET and QUIT. It also stores the messages in memory so you can interrogate them with your testing framework, like a Visual Studio Web Test. There is also accompanying plug-in, extraction and validation rules included with Neptune.
Port 525 is used for administrative purposes. There is complete documentation included with the installation that details everything about administrating the server, testing, etc.
What Neptune isn’t or does not do, well relay E-Mail for one. It does not simulate response codes from the destination server. For example lets say the message was not delivered because the destination address does not exist or their inbox is full.
Despite those limitations I think this is a must have for software developers to have on their development machines. Even though I have my own mail server at my disposal I really like the idea of having my own little SMTP test server.
The past few months I have been trying to learn more about user experience and design patterns. This has led me to learn more about how to use the tools available to me to provide better user experiences, namely CSS and JQuery. I have been writing quite a bit about JQuery stuff lately, so today I am going to shift gears a little and talk about leveraging some CSS layout goodness to lay out a web form.
First though I want to talk quickly about form layout choices. I like an article written by Luke Wroblewski about Web Application Form Design. I am going to summarize the article. There are essentially 3 form layout types; vertical labels, left-aligned labels and right-aligned labels. I tend to like left-aligned labels and Luke seems to favor that style as well. It has two key advantages in the labels are easy to scan and there is a reduction in vertical space requirements. It does have a disadvantage because the labels have a separation from the corresponding input field.
Traditionally forms have been laid out with Tables, as has just about everything on web pages. While I am still a fan of using tables to perform layout in a web page, I find my self relying on it less and less these days. As with most things there is a harmonious balance that needs to be found between tables and CSS layouts. The balance comes from weighing the extra time to accomplish a layout with CSS versus tables. But I am not going to get into that debate today. Instead I want to show how to build a web form using CSS layout techniques.
The reason why you want to try and use CSS to define as much of a web page’s appearance instead of element attributes is separation. By this I mean you can provide a more consistent feel to a site by driving the appearance and layout via CSS. If you have looked into this philosophy you have no doubt experienced CSS Zen Garden as an example playground of this principle. It also means your page should download and render slightly faster. There are real trade offs, that many CSS zealots ignore, which primarily much more time to complete. But with practice this time is reduced.
In my opinion there are three key concepts you have to grasp to be able to leverage CSS layouts effectively; the CSS Boxing Model, the differences in the boxing model between browsers (and this is the case will all browsers, not just Internet Explorer) and CSS selector syntax. I will use some CSS selectors for this article, but not much on the boxing model implementations.
Lets continue working with the contact form I have been using for the past few months in my Thin ASP.NET series. So far the form has been laid out in a series of P elements. Inside the P elements is a Label element, which is associated with a text Input field. And of course if the field is required there is a red star image, etc.
<p>
<label id="lbllastName" for="LastName">
Last Name :
</label>
<input name="LastName" type="text" maxlength="25" class="required" /><em><img src="images/required.png"
alt="required" /></em>
</p>
So far that has been acceptable, but now we want to start extending this to a more ordered format. As I have started to adopt CSS layout methodologies in my common practices I have really rediscovered lists, both ordered <ol> and unordered </ul>. For most cases there is really no difference between the two. For the contact form I chose to go with an ordered list. Each field has a dedicated list item <li> that now holds the label and input or select elements.
<ol>
<li>
<label id="lblFirstName" for="FirstName">
First Name :
</label>
<input name="FirstName" type="text" maxlength="25" class="required" /><em><img src="images/required.png"
alt="required" /></em> </li>
</ol>
This pattern continues right down to the submit button. To make a more complete form I have also chosen to add a Reset and Cancel button to the form. This list of buttons is contained inside of another list that will ultimately be displayed horizontally, more on that later.
<li>
<ul>
<li>
<button id="btnReset" name="btnReset" type="button">
Cancel</button></li>
<li>
<button id="btnReset" name="btnReset" type="reset">
Reset</button></li>
<li>
<button id="btnSubmit" name="btnSubmit" type="submit">
Submit</button></li>
</ul>
</li>
Of course it has become pretty common to wrap the form in a Fieldset to set it off from the rest of the page. The Fieldset works with the Legend element to render a title on the form that can be formatted using CSS. Making the wrapper and the Legend pop effectively it must be styled. This requires the use of an element selector, in this case fieldset and legend for each of the element types. Since we only have one of each on the page we can just set it one. As I progress through the CSS I will expand selector syntax.
The Fieldset sets a margin of 20 pixels at the top and the bottom of the form and 5 on each the left and right. The border rule tells the browser to render the border of the fieldset as a dark grey (#333333) thin line. Next the padding or inside spacing of the box is set to 10 pixels for the left and right sides. This means the content will be forced to an internal margin of 10 pixels on each side. I set the background color to a grey color. Finally the width of the fieldset is set to 640 pixels.
fieldset
{
margin: 20px 5px 20px 5px;
border: thin solid #333333;
padding-right: 10px;
padding-left: 10px;
background-color: #E5E5E5;
width: 640px;
padding-top: -5px;
}
legend
{
font-family: arial, Helvetica, sans-serif;
font-size: 1em;
color: #FFFFFF;
font-weight: bold;
background-color: #333333;
border: thin solid #999999;
padding: 2px 5px 2px 5px;
margin-left: 15px;
margin-bottom: 5px;
}
The legend uses margins and padding too, but since it is going to display text I set the font properties; family, size, weight and color. Nothing earth shattering there, but I am using em for font size and not pixels. This is the preferred method for setting font sizes because each browser will scale better. I also set a dark background color with a slightly lighter border.
Now to set the style for a Label. The labels need to be left-aligned, so I chose to clear any float they may inherit from a parent element. The next important setting is the width, which I set to 125px. This is important because this will cause all the labels to have that width and ultimately cause the associated Input/Selection elements to align along a consistent line.
#dMakeContact label
{
clear: both;
float: left;
margin-bottom: 5px;
padding-right: 10px;
text-align: left;
width: 125px;
}
The next style defines the look of the text input fields. Again floating left, a margin of 10 pixels on the bottom and a consistent 150 pixel width. This makes them all line up just to the right of their associated labels. To make this work against just text inputs I have used a slightly more advanced CSS selector, one that defines the type attribute for a text input.
#dMakeContact input[type=text]
{
float: left;
margin-bottom: 10px;
width: 150px;
}
Now to define the layout of the list itself. First the ordered list, which is designated with a selector that selects any <ol> in the element dMakeContact, or the wrapping DIV element of the form. I chose to create some inside padding to keep the form elements from touching the edges. To avoid displaying a list marker, like a dot or a circle the list-style is set to none. Finally the display type is set to inline-block, I found this to be helpful with earlier versions of IE, otherwise the layout is all out of order.
#dMakeContact ol
{
padding: .2em .2em 0 .2em;
list-style: none;
display: inline-block;
}
The <li> that compose the list have a few unique style rules defined. I like to place a little padding at the top and the bottom to help space items out. It think this makes the form more readable. Setting the display to inline-block is something I found ensures the list displays as desired in older versions of Internet Explorer and some other older browsers.
#dMakeContact ol li
{
height: auto;
display: inline-block;
padding-bottom: .25em;
padding-top: .15em;
list-style: none;
width: 500px;
}
If your form contains sub groups, it is pretty common to enclose them inside additional lists and sometimes even fieldsets. When you do this you can define additional rules to control the way these elements are rendered as well.
#dMakeContact ol li ul
{
margin: 4px 20 4 150;
padding: 0;
float: right;
}
#dMakeContact ol li ul li
{
display: inline;
list-style: none;
margin: 0;
padding: 0;
}
Finally the rules to control how the form’s buttons are rendered. First a default rule for any button, it sets a border style, the colors for each side of the button, text color and the background. The next rule defines what the submit button looks like. Notice I defined slightly different color scheme for this button. This provides some contrast between the button types, making it apparent to the user what button submits the form.
#dMakeContact ul li button
{
border-style: outset;
border-color: #CCCCCC #5C5C5C #4D4D4D #999999;
margin: 5px 25px 0px 5px;
background-color: #515151;
color: #CCCCCC;
border-top-width: thin;
}
#dMakeContact ul li button[type=submit]
{
border-style: outset;
border-color: #CCCCCC #5C5C5C #4D4D4D #999999;
margin: 5px 25px 0px 5px;
background-color: #000000;
color: #EEE;
border-top-width: thin;
}
Don’t forget you can download the latest version of my Contact Form web site.
Back in March I posted a quick announcement about the release of Internet Explorer 8 and a common problem I was having at the time. I think I finally determined what the issue was, and it was not really Internet Explorer 8, but rather sites that were down. I am not sure I like the way IE handled the issue, but it did force me to figure out a real problem.
Today many web sites utilize contextual advertising for support. Google’s Adsense is the most popular service, but not the only one. There are hundreds available. These advertising services inject their ads through JavaScript/AJAX scripts. As I started interrogating the sites that seemed to fail they all seemed to have either custom advertising or obscure third party sources. It seems the servers their ads were originating would occasionally timeout, leaving IE to either hang trying to load a script or it would ultimately lead to the error displayed above.
So in my frustration I decided to start looking at the markup of the pages that would fail to load, then load upon making a 2nd request. I noticed these ‘off-color’ ad services. At the same time I had been poking around my home router and saw that I could block or black list urls in the router. For the record I have a NetGear router, the following figure shows an example of blocking sources of ads.
Once I did this, to an even deeper extreme than displayed above, the errors in IE went away. I honestly have not had any of those issues in a few months now.
Last month I discovered another method to block these potentially error prone sites and that is with a custom Hosts file on your system. My friend David Penton pointed me to a custom hosts file available designed to block all known ad sources. At this point I have not implemented this file on my laptop, primarily because I have sites I am working on that use contextual advertising and I need to ensure they are displaying.
A little background on what a Hosts file is or does. When a request is made for an address we typically do it using a domain name, not an IP. Ultimately this domain needs to be translated to an IP address so your computer knows where to send the request. This is typically done by calling a DNS server. I wrote about how domains are translated over a year ago if you need a primer on this process.
Every Windows computer has a Hosts file that is used as a local DNS server. In this file you can control where a domain resolves before it jumps to the whole DNS routine. The ad blocking Hosts file sets the IP for all these ad sources to 127.0.0.1, or your computer! This creates a local black lists that is going to be active not matter what network you are attached. This is a great idea, but at the same time you have to realize you are not going to see advertising, which sometimes can be useful to you. Plus this is how many sites are monetized and afford to stay online. So I do suggest going to this extreme with some caution. I am not personally offended by most advertising techniques and appreciate its place in our exchange of information, entertainment, etc. But sometimes it is excessive or just poorly implemented, which ultimately caused me to perceived IE issues.
You can customize the Hosts file, it is only text after all. The source file is also periodically updated as well, so when new sources appear your blacklist can get updated too.
Often users are required to ‘read’ or ‘acknowledge’ a terms of use, license agreement or some other form of legal disclaimer before they can either use the software, web site or tool online. Microsoft does it all over the place as a CYA measure when we download many patches, tools or other utilities that are hosted or promoted by Microsoft. For example when you download code from CodePlex.com.
I have had several clients over the years require some sort of acknowledgement before allowing a user to proceed. Of course 99%+ of us never read any of the legal speak, I mean we do have lives after all. But no matter, the agreeing to the disclaimer is a key legal action on the part of any web site owner that needs to have something to fall back on when a customer complains or worse yet, tries to sue them.
Over the years I have built a mechanism to handle this requirement, but as I learn and adopt JQuery I have decided to scrap that work in favor of the JQuery UI Dialog. There are many good tutorials available on the net on implementing the Dialog component of JQuery UI, but I found I still needed to customize the experience to truly get a confirmation dialog.
I have added another page to the Contact Form sample, ConfirmDialog.aspx, I have been working with the past few months in my Thin ASP.NET series. This page invokes a confirmation dialog when the page is loaded. Of course you could invoke the dialog from a link or button click or any other event available in the page’s DOM.
First you need to get JQuery UI library from JQuery. You can customize it, but I have not had any success getting a customized zip file from the site, so customize at your own risk (see there is a disclaimer). Once you have downloaded the library you need to add the script, CSS and image files to your web site.
- jquery-ui-1.7.1.custom.js
- jquery-ui-1.7.1.custom.css
- The Images in the css/smoothness/images folder (see Figure Below)
Now of course you need to add references to the CSS and JS file in your web page:
<head id="Head1" runat="server">
<title>JQuery Contact Form with Confirmation</title>
<link href="jquery-ui-1.7.1.custom.css" rel="stylesheet" type="text/css" />
<script src="js/jquery-1.3.2.min.js" type="text/javascript"></script> //....
<script src="js/jquery-ui-1.7.1.custom.js" type="text/javascript"></script>
// Other includes .....
</head>
Now you have to add a script to launch the dialog. Now I am doing an inline script for this demonstration, I do encourage you to place it in a script file for a final production version.
<script type="text/javascript">
$(function() {
$("#IAgree").dialog({
bgiframe: true,
resizable: true,
height: 640,
width: 640,
modal: true,
closeOnEscape: false,
overlay: {
backgroundColor: '#000',
opacity: 0.65
},
buttons: {
'I Agree': function() {
$(this).dialog('close');
}
, 'Cancel': function()
{ window.location = 'privacy.aspx'; }
}
});
$(".ui-dialog-titlebar-close").hide();
});
</script>
Now lets evaluate this script block. First I am of course using the familiar JQuery Ready function, $function(){}. Then I call the ‘dialog’ method from the DIV that is serving as our dialog (more on it later). The next few lines set various properties associated with the dialog itself. Such as if it is resizable (which I like to do), dimensions and if it is model. Now if you set it to modal this means the page content behind the dialog is not accessible, which for a confirmation dialog is the desired behavior.
Setting closeOnEscape to false is important for a confirmation dialog because allowing a visitor to access the form/content, etc without clicking the all important ‘I Agree’ button is not acceptable. I am going to jump ahead in the code, but come back to this point later. While we are keeping the user from closing the dialog without confirming by eliminating the escape key, we also have to eliminate the dialog’s close icon in the top right corner. I could not find a setting to control the display of this icon, nor did I have the patience to adjust the dialog’s CSS. So I wrote a quick JQuery selector and called the ‘hide()’ function of the element.
$(".ui-dialog-titlebar-close").hide();
The overlay setting designates what color will be displayed behind the dialog and of course what its opacity is. I generally set this to black with a mid-range opacity. You want the user to realize the page is there, otherwise many will get confused. Setting opacity at 65% seems to be the most optimal in my experiences.
Now for the Buttons. We use two buttons on the dialog, the ‘I Agree’ of course, and a ‘Cancel’. You could easily rephrase the cancel button to ‘I Decline’ or any other suitable phrase. The phrases are set in the function itself. Both of the functions have an inline function defined that is used to designate their actions upon clicking. The ‘I Agree’ button simply closes the dialog, $(this).dialog('close');. You could also extend this if you wanted proof the user chose to agree by sending a notification back to the server via AJAX, but that is another post all together.
The ‘Cancel’ button does not close the dialog, but redirects the user to the site’s privacy policy page. Again you could perform any action you wanted to in this custom function definition. It is important to understand why I redirected the user to another page. You need to make sure they cannot access the page content without agreeing to the terms. This takes care of that, as long as they have JavaScript enabled. So in those rare cases you are going to have to be creative in how you handle that. In most cases you are going to need to do an old fashion (they do have JavaScript turned off after all) from a confirmation page to the real page.
The dialog markup is a simple DIV tag with the id of ‘IAgree’. Inside the DIV is the actual content of the dialog the user needs to read. Do not worry if the content is long, the dialog will automatically display scroll bars as needed. The Dialog’s title is derived by setting the Title attribute of the DIV element. In this case I am just saying ‘Usage Terms’ but you can say anything here. I do place this DIV at the bottom of my content, so it is ‘out of the way’ in the markup. Legally you could place it just about anywhere in your markup.
<div id="IAgree" title="Usage Terms">{Important Content Goes Here}</div>
Finally, with all that done we can view the dialog. Voila, a confirmation dialog that will force the user to agree to our terms of use before using the page!
As always, the Contact Form Tester Web Site Code is available for download. The new page I added is named ‘ConfirmDialog.aspx’.
Today I was working on a Web Form and noticed a property in the TextBox control called AutoCompleteType. I had never noticed it before and my interest was piqued. My first thought was it must be an injected property from an AutoComplete extender on the page, but no there was none available. Then I started to wonder if maybe there was some sort of crude AJAX auto complete facility built into the Web Form infrastructure that had not noticed before. Again no, and a big whew at the same time.
Turns out this is an answer to one of those questions I have had over the past few years, “Can I have some more control over what the browser injects into form fields?” The answer is yes and here is how this property helps. From what I can tell it was quietly added to the TextBox Control in ASP.NET 2.0.
Browser AutoComplete in Action
First, in case you do not know what I am talking about, when a user begins typing a value in an input field with its type set to text most browsers will offer suggestions from previous times an input of the same name was submitted. Some toolbars will also be so bold as to automatically fill in the user’s information for them if it can reasonably determine what they will enter. I do not use any toolbars and honestly recommend removing them to anyone who asks because that cause more headaches than they prevent. But that is another topic. Users can also turn this feature on and off in Internet Explorer.
Configure AutoComplete in IE 8
So how does this work? Microsoft has written a nice article on what is going on when you use AutoComplete in HTML Forms. And from what I can tell this is not limited to Internet Explorer, but so far IE seems to be the only browser I can find information about controlling the AutoComplete functionality through markup. I did find a few mentions of turning off the AutoComplete feature for an input field, but I think most articles on the subject are going to be obfuscated in search results by AJAX AutoComplete articles.
When you set the AutoCompleteType value in a TextBox Web Control you will see a dropdown list of choices, both setting it from the properties window or in the source. These choices are derived from the AutoCompleteType enumeration. You will see many familiar personal identifiers in the list; FirstName, LastName, HomePhone, HomeStreetAddress, etc. These are all common vCard attributes.
Setting AutoCompleteType in Visual Studio
If you are not familiar with the vCard specification then I encourage you check it out. Basically a vCard is used to organize contact information for a person or entity. When you add someone’s contact information to Outlook it creates a vCard data structure that can be imported or exported to and from other applications supporting vCard. If you read my HttpHandlers eBook or saw one of my presentations on handlers last year you saw me demonstrate this functionality.
Internet Explorer looks for a custom attribute called vcard_name to drive the AutoComplete behavior. This attribute should specify the particular vcard property you want to suggest values, like vcard.firstname for example.
vcard_name Attribute in the HTML
For a complete list of potential property names refer to the Microsoft article on implementing the AutoComplete functionality.
One thing to note here is the use of a custom attribute in the input tag. This will cause you to fail validation tests, but is not legally wrong. From what I know browsers will either use the field or ignore it gracefully. I am not looking to start any sort of debate on using custom attributes or not, that is up to you. I have not formulated an opinion at this point, but do find adding custom attributes very useful, especially when creating more complex JQuery selectors.
Since the AutoComplete functionality is driven by HTML and not specific to the Web Control itself you can add this to any page you need. Since I am trying my best to wean myself away from Web Controls right now this is good news. I did look through the MVC extension methods for TextBoxes and did not see where this feature was accounted for, but I could have missed it. I have not formally started doing any MVC at this point, so take my comment for what it is worth. But I hope this helps you make your user’s experience a little better.
Today I want to keep extending my series on Thin ASP.NET by adding some more user experience features, Default Focus and Default Button. Early in my windows experience (circa 1992) I learned a truth, that keyboarding through a form is so much faster than using the nifty little mouse I could now really leverage. That’s right, good old fashion TAB, or Ctrl+N, etc is much more efficient than using the mouse to move, point, click, move click, etc. Another truth of computer use I have also found universal is people who spend the majority of their work time entering data into software forms know the truth of keyboarding and use it 100% of the time, without even thinking why.
I hope these two truths have also been accepted by you even before you just read it, or at least you said to yourself ‘that makes sense’. Because folks entering data over and over want to be as efficient as possible and not have to think. There are two things we can easily do to a web form to create a superior user experience through the use of the keyboard, define the initially focused input field and the default button, or the button/action that will be executed when a user presses the ENTER key.
This always seemed to be an issue with the earlier versions of ASP.NET because there was nothing just built into the Web Form and Web Controls infrastructure to just designate these defaults. When ASP.NET 2.0 was released a DefaultButton property was added to both the Form and Panel controls. Simply put, all you needed to do was set the DefaultButton property to the ID of the button you wanted to be clicked when the user hit the ENTER key. The controls would then generate some inline JavaScript to set this feature up for you. The Form control also added the DefaultFocus property, which when an input control’s ID was passed to it would also cause JavaScript to be generated on the page to set the initial TextBox, DropDown, etc to be in focus when the page was loaded by the browser.
<form id="form1" runat="server" defaultbutton ="btnSubmit" defaultfocus="FirstName">
But this is not a series about working with ASP.NET Web Controls, but rather how to architect our ASP.NET web pages to be leaner and meaner. In the past few installments I started demonstrating how to leverage JQuery to accomplish these goals. Today I am going to show how to set a form’s initially focused input element as well as the default button.
JQuery defines several event handlers, focus is triggered when a user enters an input field. By defining a function to be called when an element receives focus you can cause the page to perform designated actions. This is identical in nature to event handlers we are all familiar with when defining server-side event handlers, but all handled on the client-side. The focus event can be triggered by simply calling the focus method from the element(s) itself. Using a JQuery selector the focus event for all matching elements can be triggered. Typically you would only want to set this for the initial input field like this:
$(document).ready(function() {
$('#FirstName').focus();
});
Note you must include an id attribute in the input field to select using the above syntax. I forgot this when I first tested my script and I do not want you to waste time like I did being a numskull.
<p>
<label id="lblFirstName" for="FirstName">
First Name :
</label>
<input name="FirstName" id="FirstName" type="text" maxlength="25" class="required" />
</p>
Now when the page is loaded the user’s cursor is already in the first input element of the contact form. Now they can just start typing and filling in the form naturally, without thinking.
Now to set the default button for the form. Typically you will have more than one button as part of a form’s composition. Maybe a Cancel, Submit and possible Apply or Reset. Most likely the Submit button holds the key to the desired behavior when the user presses the ENTER key. I found a good article explaining how to set a form’s default button behavior with JQuery. I did change the code from the article by making it only return true. I did this because returning false from the method ended processing and therefore no validation would be executed and of course the form would not be submitted to the server. By returning true you allow the next natural activity occur, in the case of the contact form that would be validation.
$(document).ready(function() {
$("form input").keypress(function(e) {
if ((e.which && e.which == 13) || (e.keyCode && e.keyCode == 13)) {
$('button[type=submit] .default').click();
return true;
}
});
});
The selector to designate the keypress event functionality contains a form and input element. This is key because this selector, ‘form input’, tells JQuery to assign this function to be executed anytime the ENTER key is pressed when the focus is on any input element inside of any form. If you have a few year’s development experience under your belt you understand the use of the keycode and which properties. The number 13 is the ASCII code for the ENTER key and the keycode and which properties deal with keyboard input from the browser.
If the ENTER key was pressed the next selector calls the click event for any button element of type=”submit” with the CSS class of ‘default’. All of those items are really important to understand because it is a more advanced CSS selector designation. But basically it will match any submit button with the class of ‘default’ assigned to it. This will force a strong delineation from any other buttons on the page. You still have the responsibility to limit assigning the ‘default’ class to only one button. You could extend the selector and add a form id, etc. I plan on writing more about CSS selectors soon, but if you want the primer on CSS selectors, visit the w3.org site.
These are a couple of very simple tips to help you make a more effective user experience on your forms. Just like we saw in the entry on JQuery Validation, this script will also work using the selector scheme with ASP.NET Web Controls. This makes it very easy to leverage the JQuery framework to set these features for any ASP.NET web page.
Several times over the past week I have had some conversations with folks about code generation, some pro (like me), some con and some that find it scary. My first real exposure to a serious code generation tool was at TechEd 2003 in Dallas. I remember an 8 AM session on the last day given by a Microsoft Engineer from Grenoble France. He showed a tool he called Oly Mars to a packed room. Right then and there I knew I was seeing something I wanted in my daily routine.
The demonstration showed how to point the tool at a database with the application’s tables, indexes, keys, etc defined and it would generate stored procedures, DAL, BLL and several user interfaces. The UIs included ASP.NET, WinForms, Mobile and Web Services if I remember it all correctly. All that was left to do was customize the UI’s final look and feel and add any customization to the application’s code that fell outside of the standard CRUD operations. Think about it, that means you could generate about 85% of the code and focus just on the user experience and custom features.
This experience opened my eyes to something very powerful. Eric J. Smith must have been in the room with me because he soon went on to create CodeSmith, my current code generation tool of choice. I think it has the largest user base and community as well.
I also like Miguel Castro’s CodeBreeze and plan on working with it more over the coming months. You can view Miguel demonstrating CodeBreeze on two different episodes of DNR TV, 77, 133.
Visual Studio also has the T-4 generator that is starting to get some traction. I am not a huge fan of it yet and have found it to be rather cumbersome to use. It is the way Visual Studio creates new content for projects, etc. Also do not forget about Visual Studio’s Code Snippet library or just adding common textual patterns to a custom toolbox tab.
The Figure above shows how to use Code Snippets in Visual Studio from either a contextual menu (Right Mouse Click). The example shows how to insert a Try Catch Block. It can also be added by typing ‘TryC’ and pressing the TAB key. More info on using Code Snippets is available on the MSDN site. A Visual Basic Code Snippet editor is also available to help create your own snippets.
Then there are third party add-ins like CodeRush, Refactor and ReSharper (C# tool) that also add code generation and management facilities at our fingertips. If you create either an Entity Framework or Linq to SQL model, those are also code generated. Finally Visual Studio allows you to export entire web sites/applications as project templates or just a form, class or other project file.
All of these tools add value to the development process. And as far as I know all of them allow you to customize templates for code. Most can also be used to generate just about anything that is textual in nature, not just code.
I don’t want to get into how various Code Generators work or pros and cons of each one. I do want to discuss why Code Generation is important to an efficient developer and why EVERY developer should be using Code Generation as a standard part of their development routine.
Reduced Time to Market
This should be obvious, but is not necessarily a truth. On just about every application I develop I generate around 80-85% of the final code in one way or another. This obviously means I can typically create a brand new site from scratch much faster than if I did everything by hand. But, as I will discuss a little later, it leads to adding more functionality or improving the UI itself.
Here is where many developers get scared. They assume that because 80% of their application can be generated in literally seconds they will soon be out of a job. This is far from the truth, in fact it should help them keep their job. Any employer that does not see the value in developers using code generation in their standard routine is probably not one you really want to work for in the first place.
Think about how much more valuable you are using Code Generation over say outsourcing it to cut and paste developers for $10 an hour. You are also adding value by following (your) standard design patterns for your code. And ultimately you do not waste time on routine coding work, like a Data Layer for example. You spend your time working on the real business code or the parts that really make the difference in the application. Anyone can make a standard CRUD application, that code is the first thing that should be code generated. That means a developer using code generation does not waste their time and thoughts on mundane code.
Working with as many small businesses as I have over the last decade I learned early on they want something they can touch and play with within hours of signing a contract with me. Technology scares them and they need to be comforted you are producing a site for them. Having something for them to touch the next day is a huge confidence factor. I have also found this fact to hold true for larger businesses as well. This is where writing a bunch of unit tests before writing any application code will cause a lot of tension with customers, and that is my opinion based on my experience. So having a solid set of code generation scripts is a huge gain.
Reduction of Errors
I was having a conversation with one of my peers on unit testing a few weeks ago. In that conversation I asked if I should code gen unit tests for my generated code? A true TDD conformists would say never, but my friend and I were on the same page that if I had already tested the pattern that I generate code from there was little to no value in writing a unit test from scratch for that code. In reality it would generally be an integration test and not a true unit test in most cases. So having some tests to verify everything is working is a good idea, so I do not want to discount the value of having the tests.
But unit tests are there to help developers reduce development time (at least in theory) and errors sent to Q&A and production. To me code generation serves the same purpose, but in reality, not theory. To me unit testing and code generation have a symbiotic nature in the code development process. When I create a new coding pattern I have to test it in one way or another to make sure it works. Once I am satisfied with the pattern I then I create or add the pattern to my code generation scripts.
By using this proven pattern that is replicated through code generation templates I reduce the chance I make typos and other bugs while writing code. For example I do not forget to add caching code in a get method of a repository. Or maybe a try catch block or data validation routine, etc.
The following code is a standard method pattern I use to get a list of entities from a database. There are two features it has that are ‘optional’; caching and filtering for active records. This is real code generated from a Code Smith template, which is in the screen shot above. I did not have to write one single character in this method by hand.
Public Function Getinforeqs(ByVal vActive As Boolean) As List(Of ContactRequest)
Dim key As String = CacheKey & "_List" & "_Active_" & vActive
If EnableCaching AndAlso Not IsNothing(Cache(key)) Then
Return CType(Cache(key), List(Of ContactRequest))
End If
Dim lContactRequests As List(Of ContactRequest)
inforeqctx.ContactRequests.MergeOption = Objects.MergeOption.NoTracking
Dim tempList As IQueryable(Of ContactRequest) = (From lContactRequest In inforeqctx.ContactRequests)
If vActive Then
tempList = (From lContactRequest In tempList Where lContactRequest.Reponded = False)
End If
lContactRequests = tempList.ToList
If EnableCaching Then
CacheData(key, lContactRequests, CacheDuration)
End If
Return lContactRequests
End Function
I like to show this method when talking about Code Generation because it has evolved over the years. At its core it was essentially a ‘Select * from X’ type of wrapper. As I added functionality to the method and made sure the patterns worked, I updated the code generation template. I can have full confidence the generated method will work without testing.
You can still create integration tests for this method, but I would simply code gen those as well. If I think of a new way to test the method I will add it to my testing script too. So ultimately using code generation drastically increases the quality of my code and ultimately my applications.
There is a down side and that is replication of bad code. Yes there it is, if you have a script that generates a method with buggy or just smelly code you will replicate it everywhere, right? Yes you will. But I have found this to not be a real issue because I try my best to put my generated code into partial classes. By leveraging a partial class I can create one file that is fully maintained by code generation and one that is custom code and maintained by me. If I find I need to regenerate the code I can do it, feel confident in it and just replace the entire file or method from the regenerated code without breaking my customizations. Remember it takes only a few seconds to generate an entire DAL and BLL layer for my applications. Where I do have a problem is in the user interface code, and I have learned to live with it since it is so highly customized once it is generated in the first place.
Increased Product Functionality
Now that I have talked about reduced development time and increased quality I can talk about the product of the first two, increased product functionality. If you think about it, a 6 week project where you can generate 85% of the application’s code in a few minutes leaves you with a lot of time to improve functionality.
There are always custom queries and methods that every application needs to make it unique. How well those features are developed and matured makes a big difference as to how well the application is accepted by users.
There is also a lot more time to sculpt and refine the user interface and experience. This is becoming so important these days as users are expecting more and more richness in applications. If you had to spend that time writing the plumbing and wiring code the application you will have a hard time achieving that rich interface.
Summary
These are my primary observations of using Code Generation in my daily development practice for over 5 years. I know there are many more points I could have made, but I want to hear from you. So please comment either way with your opinions of code generation.
Yesterday I walked through applying the JQuery Validation plugin to an ASP.NET web page. Today I want to extend the concept of guiding user input as they complete an online form by demonstrating the JQuery Masked Edit plugin. The ASP.NET AJAX Control Toolkit contains over 30 AJAX enable controls and web control extenders. One of those controls is the MaskEdit Control Extender. By adding it to your ASP.NET Web Form and pointing it to a TextBox control you can apply an input mask to the TextBox and ‘guide’ the user’s input. When you apply an input mask to an input control you are helping them understand the proper format for the data you are requesting. In case you have not read yesterday’s entry, I want to emphasize that driving correct user input is very important to having a successful web form.
In the contact form we have been working with there are two fields that masked input are useful; the Zip Code and the Phone Number. Each have known formats, and I am using the US formats for both. The JQuery Masked Edit plugin invokes the desired masked for the input field as soon as it gains focus, i.e. the user either tabs to the field or clicks the mouse in the field.
In the above screen snippet the zip code is filled in, but as you type it only accepts numbers and only 5, no more. As you are typing numbers an underscore is displayed in the remaining space.
The phone number mask, displayed above, does the same thing in that it only allows numerical inputs and uses the underscore as a placeholder. There are several common acceptable formats for a US phone number. The format displayed above uses parentheses to offset the area code and a dash to separate the local exchange from the number.
Applying the Masked Edit plugin is pretty straight forward. Just like I did to apply the validation routines to the input fields I am also going to define a class selector for the particular field. To keep things unique I decided to add a ‘Mask’ suffix to the class selector name. For the two examples in this sample I call them ‘ZipCodeMask’ and ‘PhoneMask’. I could have leverages the same CSS selector name (phone for example) the Validation plugin uses, but I want to emphasize this application for demonstration purposes.
<p>
<label id="lblZip" for="txtZip">
Zip :
</label>
<input name="txtZip" type="text" class="ZipCodeMask"/>
</p>
<p>
<label id="lblPhone" for="txtPhone">
Phone :
</label>
<input type="text" name="txtPhone" class="phone PhoneMask"/>
</p>
All that is left is to actually assign the rules within the $.ready function. I want to extend the use of selecting DOM elements using JQuery by assigning the mask rules only to input elements with the two class selectors I defined earlier. This is done by referencing all elements like $(‘input.PhoneMask’). Therefore if there were more than one phone number field on the page they would all have the same mask applied. Using the input type also limits the application of the mask to only input fields, which should be a given. I could have just references the ‘PhoneMask’ selector and the result would have been the same, but I wanted to demonstrate a little more advanced technique. ;).
The Masked Edit plugin adds a ‘mask’ function to the DOM elements. It accepts the mask as an argument and will apply it to the elements that match the selector criteria.
$("input.PhoneMask").mask("(999) 999-9999");
$("input.ZipCodeMask").mask("99999");
While these two masks both make use of numbers you are not limited to numerical input. An ‘a’ is used to indicate an alphabetical character, ‘9’ numerical and ‘*’ for any alpha-numeric character. Optionally you can define the placeholder character by passing it in to the mask function:
$("#product").mask("99/99/9999",{placeholder:" "});
You can also define a method to be executed with the mask is complete or define your own mask definitions. The Masked edit plugin is very simple to use and will work with both pure HTML elements and ASP.NET Web Controls. Just like I showed yesterday, JQuery selectors are ignorant of a DOM element being the product of a Web Control or just plain old HTML since Web Controls produce plain old HTML in the end. Also style selectors are applied to a Web Control in the CssClass property.
If you have not noticed I keep adding code to the Contact form web site for each demonstration. The Code I added yesterday already had the Masked Edit plugin code applied, so the download is the same for this entry as yesterday’s. The new file is ‘JQueryValidateForm.aspx’.
Download the Code!
Now that I have demonstrated how to create a thin Contact form in ASP.NET using JQuery and some AJAX it is time to start making it even better. One of the first rules I learned back in my youth was users will enter anything in any field despite what logic should dictate. They will also not follow explicit instructions. Don’t believe me? Then put a form on a web site with no filtering what so ever and examine what data you catch, amazing isn’t it?
To force, or help users enter valid information in a web form or any application you may design you have to add validation, hints and other visual clues. The ASP.NET Web Forms framework (see how we are expanding our horizons now) has included a pretty good set of validation controls that naturally work with web controls. I am not going to review them today since they have been around for a decade now. Peter Blum has probably the best package of custom ASP.NET validator controls available that go above and well beyond the out of box set available in ASP.NET.
Since the contact form I have built so far leverages JQuery I want to demonstrate how to implement the JQuery Validation Plugin to embed validation and data hints.
When you implement an ASP.NET Validation control you set several properties on the control to drive its behavior. In particular you need to indicate which control is being validated unless it is a custom validator. The JQuery validation plugin leverages a CSS selector like syntax to apply validation rules. Which of course once you understand how JQuery works, leveraging CSS selectors makes sense. Any element in the DOM, which is just about all of them, can have a class selector attribute defined. I think anyone that has done HTML development knows this, what many may not know is you can define multiple CSS selectors in this attribute (Ah Ha!!).
<input type="text" class="prettyForm required phone" name="txtPhone"/>
This opens up a world of opportunities to us as developers because now we can really leverage this feature to manipulate the elements on the page. Another thing to note is the class does not actually need to be defined in a style sheet definition for it to be valid to use in the markup. Of course it is a good idea to do so, but not a requirement.
In the above example the input field has three style sheet selectors assigned to it: prettyForm, required and Phone. The first selector, Prettyform, is actually used to control the appearance of the input, at least in my example. The other two selectors may or may not have a CSS definition, but instead will be used by the JQuery Validation plugin to perform client-side validation to the data entered by the user. In this example the field is required and must be a valid US Phone Number. The Validation Plugin already has routines in place to verify a value has been entered for the required fields and where indicated meets a criteria for a valid US Phone number.
There are other custom methods defined for other input types, such as e-mail, dates, numbers, etc. There is even an additional methods add-on included with the package. In fact you can even define your own validation routines and add them to the list. This provides for the ultimate flexibility when defining form validation rules.
Implementing the JQuery Validtion plugin is relatively straight forward. In addition to the JQuery script reference you need to reference the validation script file (shown with the additional methods reference):
<script src="js/jquery.validate.pack.js" type="text/javascript"></script><script src="js/additional-methods.js" type="text/javascript"></script>
Next you need to actually register the validation routine for the form in the JQuery Ready function. This is done by calling the validate function from the form object. If you have a JQuery background this is pretty natural, if not then I encourage you to read up on JQuery fundamentals.
$("#ContactForm").validate();
I find it is also a good idea to hide any object with the .error CSS selector applied to it just in case they may be unnecessarily displayed when the page is loaded. The Validation plugin automatically adds these DOM elements to display the validation message to the user and they should not be visible when the form is first loaded, but I had a few trial instances early on where they were displayed.
Now opening the form in a browser will look just like our previous exercises, except now I have added a red star next to the required fields. I have also added a few CSS rules to define the look of the text boxes. Simply clicking the Submit button will cause the validation rules to be executed and messages displayed to the user letting them know what they did wrong.
Once these fields have content in them the form will submit, as long as the e-mail field has a value that meets the criteria of a valid e-mail pattern.
Notice I was able to enter anything I wanted in the textbox, but it was not valid and the validator plugin let me know as soon as I started typing. While numbers are valid in an e-mail address, not having an @ (or in some cases a #) sign and a TLD is the standard e-mail format. If I has added characters to match this pattern the validation message would be suppressed.
At this point you may be asking yourself if the JQuery Validation Plugin works with ASP.NET Web Controls? Absolutely!! Again all you need to have are the script references to JQuery and the plugin and you are in business. Then use the CssClass attribute of the Web Control to assign the CSS selector(s) needed for validation of the control. I have included a ASP.NET Web Form version of the contact form using the JQuery validation plugin in the sample code. Here is a snapshot of it in action:
The JQuery Validation plugin provides some very efficient client-side validation. There is much more that can be accomplished with the plugin as it comes out of the box and can be customized to meet just about any client-side validation rule you need to meet. I plan on exploring more options with the validation plugin in the near future. I also want to emphasize that just because you perform client-side validation you should never assume the data your users are providing your application is valid in any way shape or form. You should always perform server-side validation and scrubbing as needed. Client-Side validation should be looked as as a user convenience or user experience feature. You should use it to drive user input and not assume it filters bad stuff from being submitted. After all – Garbage In = Garbage Out.
Download the Code!
Back in January I wrote about making a thin contact form in an effort to demonstrate how to make ASP.NET forms lighter and much more user responsive. The key to making the form more responsive was to avoid using the WebForm and UpdatePanel conventions. I demonstrated how to leverage ASP.NET AJAX without the UpdatePanel to introduce some nice user interactions and reduce payloads.
ASP.NET AJAX’s unique position is its ability to interact with ASP.NET Web Controls. To do this is produces a pretty heavy client-side payload or code that is sent from the server to the client. Often the payload cannot be cached on the client because it is dynamically generated, causing JavaScript files to be downloaded on each request and a lot of unnecessary JavaScript to be emitted in the HTML markup, a very bad practice.
The second part of the first tutorial demonstrated how to accomplish the same feat without the UpdatePanel. This really helped reduce request payload with a good user experience. But I was still not happy, there is still a lot of extra code generated because of the ASP.NET AJAX framework and the ScriptManager. Plus each round trip to the server using the UpdatePanel has to send and receive the entire ViewState.
As you can tell I am still not satisfied with the results, so lets press it further. Unless you are under a rock or buried deep in a corporate cubicle completing TPS reports you have at least heard of JQuery. Where ASP.NET AJAX is a top notch AJAX framework for ASP.NET WebForms to leverage, JQuery is, what I consider safe to say, the king of AJAX frameworks. It is super easy to work with, there is a great community of resources available around it and it works great with ASP.NET.
There are numerous Plugin libraries available for JQuery. In this tutorial I am going to work with the JQuery Form Plugin. The JQuery Form Plugin makes it really easy to manage the form submit process. The way it works is you setup or assign the form’s submit action to be handled by the plugin. For this example I am going to simply copy the HTML from the ThisContactForm.aspx and place it in the JQueryContact.aspx page. (note: I cleaned up the intro text on both forms to make it a little shorter ;).
So the DIV elements will remain the same. Each of the INPUT fields has their id attribute changed to name, which is the normal attribute to use for a form. You can still use the id attribute, but it is not needed in this example. What does change is how the submit action is handled. In the previous page the Submit button assigns a JavaScript method to the onclick event. With the JQuery Form plugin you instead set the submit action in the JavaScript. I am not going to get into the details of how to work with JQuery in this tutorial, but there are a few things to understand. With ASP.NET AJAX to get a reference to a DOM element you use the $get function, with JQuery you use $(). In the previous example I used the HideElement and the ShowElement functions, JQuery has built in methods; hide() and show().
The JQuery Form Plugin adds the ajaxSubmit method, which accepts a series of ‘settings’ that define how the submission process works. In this example I set the ‘url’ property to the URL of a generic handler, not a web service. While you can post to a web service I found it cumbersome for this simple process, again another post if forthcoming. I found that using a generic handler was a quick and dirty way to solve the issue. The ‘success’ property is set to a function and accepts a result parameter.
$('#ContactForm').submit(function() {
$("#dMakeContact").hide();
$("#dThinking").show();
// submit the form
$(this).ajaxSubmit({
url: "ContactHandler.ashx",
success: function(result) {
$("#dThinking").hide();
$("#ContactResponse").show();
alert(result);
}
});
The ajaxSubmit method will automagically serialize the form’s values to POST data that is POSTED to the Handler. The Handler then processes and returns a good or bad response. The handler receives the data, you can then retrieve it using the Request.Form call to a ContactInfo object and returns either ‘good’ or ‘bad’. Of course I am not doing any real work here, just simulating it again.
Public Sub ProcessRequest(ByVal context As HttpContext) Implements IHttpHandler.ProcessRequest
context.Response.ContentType = "text/plain"
Dim lContactInfo As New ContactInfo
lContactInfo.FirstName = context.Request.Form("FirstName")
lContactInfo.LastName = context.Request.Form("LastName")
lContactInfo.Address1 = context.Request.Form("Address1")
lContactInfo.Address2 = context.Request.Form("Address2")
lContactInfo.City = context.Request.Form("City")
lContactInfo.State = context.Request.Form("State")
lContactInfo.Zip = context.Request.Form("Zip")
lContactInfo.Phone = context.Request.Form("Phone")
lContactInfo.EMail = context.Request.Form("EMail")
lContactInfo.Request = context.Request.Form("Request")
Try
'Do something here.....
Threading.Thread.Sleep(1000)
context.Response.Write("good" + Environment.NewLine)
Catch ex As Exception
context.Response.Write("bad" + Environment.NewLine)
End Try
End Sub
For this demo I decided to just return ‘good’ or ‘bad’ to indicate submission success. When the handler returns, the page will update to let the user know their request was received. So lets do a little visual compare with Fiddler one more time.
First the ThinContact form from the previous example:
There are 6 files or resources downloaded totaling 99339 Kbs. The page itself is 5,894 Kbs, which is not a ton, but there are 4 JavaScript file downloaded for ASP.NET AJAX that account for a lot of the request. Granted these files should be cached on the client, but the reality is ASP.NET AJAX dynamically serves the JS content based on what it thinks is needed on the page. So the optimization caching gives you is lost.
Now for the new JQueryForm:
Now we are talking, 4 resources, totaling 84,939 Kbs. The page itself is smaller, as is the JQueryContact.js file. Additionally there are two JQuery .js files downloaded that are cached the first time they are retrieved on the client. So this is a big savings.
Notice how little there is involved in building the page. There are only three references to JavaScript files. In fact you could combine all the plugin and local site code into a single file if you wanted to do so and reference the actual JQuery file from a public host, like Google, http://code.google.com/apis/ajaxlibs/.
The real measure is in how many bytes are sent across the wire to and from the client. As you can see it is not much and the reaction on the client is really fast.
Download the Demo Source
I tell a story about my very first assigned development task to my development friends because it really sets the development practice tone of reality to me. The first day I was on my first job after graduate school I was given a simple task of creating several reports for a plant manager to review over his morning cup of coffee. I really do not remember the content of those reports, but I do remember Sybase, Stored Procedures and PowerBuilder (I do not do Sybase, PowerBuilder or reports anymore). It was actually a pretty simple task to complete and a good starter project to get my feet wet in the new corporate culture I had entered.
I hit the ground running and knocked out a solution for the plant manager in 2 weeks (10 business days). He was really excited to finally have this information available anytime he wanted. He was currently wading through a lot of printed material the shift managers would leave waiting for him, etc. I was excited because I had pleased my customer (the plant manager) with my first project. I was very proud of myself and was beaming confidence. All I had to do now was get my new reports integrated in the nightly system updates. (play evil music here)
So I filled out the forms (which if I remember correctly took about an hour just to find them all), submitted them and fully expected to have my new reports available to the manager in a few days. Boy was I wrong! A week goes by and I get a phone call telling me that I needed to have three code reviews (DBA, Stored Procedures and PowerBuilder). I did not even know what a code review was! I am a self taught developer and had degrees in Polymer Chemistry and Textile Engineering (I was in a textile company by the way) and had done a lot of development all by myself. So I said, fine, when and where.
I was ripped all over the place in the first code review (PowerBuilder), it was brutal. The other two reviews were just as bad. I then had 7 inches of 3 ring binders containing PowerBuilder coding standards promptly dropped on my desk. Then came the SQL coding standards and a bloody introduction to an extremely hard to use CASE tool. I really could not believe what I was being hit with, why did they not even tell me this in the first week? I still have no clue.
Looking back having a peer code review is not a bad thing. I am still very independent and plan on staying that way. I try to remain consistent in my coding practices, hence Code Smith and other code gen techniques. But in reality technology changes rapidly and a pattern or technique that is great today, is out dated in a few months. But I do like to share code with peers and get feedback, I do want to be the best I can after all.
The CASE tool on the other hand was bad and I still think pretty useless. I saw it as only adding a great deal of impedance to a simple task. The company had thousands upon thousands of custom data types. This means there were literally hundreds of data types that were nothing more than an integer with a new name. Of course I had to pick the right one and hope I was not wrong, etc. The CASE tool itself was very complicated and I could easily have 20-30 individual windows open at once.
Ultimately the task I satisfied the paying client with in 2 weeks took another 6 months to get deployed. By that time the manager had solved his problem another way and even forgot I had created the reports for him. Ultimately they were never used, which to me is the ultimate insult to a developer. It also wasted several thousand of the company’s dollars (I spent about 2/3 of my time on this project for 6 months remember). The code review did not change the operation of the application. It did help me code more inline with the company’s standards and be more organized with my coding. The CASE/SQL side of things was just atrociously unneeded. Overall the extra 26 weeks of work it took to solve the problem was unneeded and a complete waste of money. This is why I know many business units try their best to keep the IT department from knowing about software solutions they create. Hence the large number of rouge Access applications sitting on assistant’s and manager’s computers. This will always be the case.
I consider myself a very pragmatic developer. I make mistakes, everyone does. Most of my biggest mistakes come from putting energy into trying to abide by theoretical development guidelines. I see them all the time, their practitioners are loud, but a minority. A recent Blog I read talks about the CSS layout zealots and how their arguments are impractical. I have to agree with the points made. I am gong to use this example because it is recent and serves my point well. I have spent a lot of time the last year getting comfortable with CSS layout techniques. While I am getting comfortable with them, it takes so much longer to get a layout done in CSS than just using a table that it is almost to expensive to use CSS. I do see it as a partial ‘job security’ route to take. There are benefits, no doubt, but they are so expensive in comparison more often than not. I do not know about you, but my experience has proven out that clients want something they can touch as fast as possible and table layouts get you there in a minute or two, whereas a CSS layout may take a few days or weeks to accomplish the same thing. Clients want to pay less, not more, again Tables win, sorry. Getting a site online sooner typically means the client makes money sooner and they pay you sooner (both good). At this point getting a 100% CSS layout done is a secondary choice for me. Getting the application up is much more important. Updating the CSS features can be done after the site is up and creating revenue.
There are many more examples to point out in today’s software development climate. Yes, I have heard the spending a day writing a unit test for a function can save you 5 days of work a year later ad nauseum. I don’t buy it. Get It Done Today gets you money tomorrow. Upgrading next week and the week after is just fine. You are going to be applying upgrades and changes throughout the life of the application anyway. This is why you should take notes as you work. Write down things you want to come back to, Visual Studio has a nice TODO feature in it. Other tools like TFS and OnTime also are great for listing tasks.
The bottom line you should always remember: The Client could care less what technology you use to solve their problem. They just want their problem solved today. So solve it as quickly as you can, minimize the introduction of new problems and use continuous improvement to make the solution better over time.
This morning I noticed some timeouts when checking against the DSBL.org servers for incoming SMTP traffic to my E-Mail server. So I checked the website to find the DSBL SPAM blacklilst have been taken offline. They explain that SPAMMERS have changed their targets from open relays to using "spam zombies" they can easily lure computer users into installing on their local machines.
If you are wondering what DSBL is or was, it was a volunteer run organization that would check the source of a SPAM message to see if it had some common vulnerabilities that would allow spammers to leverage the server to send massive amounts of unsolicited E-Mail. Typically these were known as open relays.
Today the common way to send SPAM is by getting computer users to install some software, like an innocent browser toolbar or something else fun and innocent looking. Inside the application is a hidden package that will install a hidden application that works for the spammer to send out their junk from your computer. I talked about this a couple of years ago.
There are still active blacklist available to check for likely sources of SPAM, these include Spamcop.net, njabl.org and SpamHaus.org. These blacklist have been the frontline of blocking SPAM on my E-Mail servers for years. Blocking the source is so much more effective than parsing the message content and scoring it, and it uses much less bandwidth and server resources. Until the SMTP protocol is modified we are always going to be fighting this war and much like the war on drugs it is almost futile I think.
Today Microsoft released the Release version of Internet Explorer 8 (I would provide the link here but I am waiting for it to load in my browser..
), which is great there are some cool new features surrounding microformat support, etc. I started used the Release Candidate of version 8 three months ago. Since ‘upgrading’ I get the following friendly screen greeting me about 10% of the time. At least another 5% I get only partial page loads. I have to say I am very frustrated because for the first time I have to honestly say FireFox is performing better for me than IE. I am also finding many pages take forever to load, then work just fine, even with a primed cached.
For the record I have yet to get a diagnosis from clicking the button. Typically if I hit refresh the page loads. I hope this issue gets resolved soon, but today after downloading and installing IE 8, no luck….
I was trolling the ASP.NET forums tonight and found a very good question from ctrlctrl, . He wanted to know how to ‘grey’ out the page while he was waiting on a long running process on the server. The answer is pretty simple, it involves a little AJAX and CSS trickery. I am going to demonstrate this by calling a web service to simulate some server-side process and since I explained this a few posts back, Making a Thin Contact Form, I will not explain it here.
The trick lies in displaying and hiding a DIV element that covers the entire page. The DIV itself only contains a single image to visually indicate work is happening. Of course you can add anything you want to the DIV.
<div id="PopUpBackGround">
<img src="loading.gif" alt="Performing Long Running Task...." />
</div>
The next step is to define a CSS rule for the DIV. The first CSS property to note is setting the z-index to some high number, 1400 in this example. This places the DIV above the working surface of the page. This is important because you do not want users interacting with the page while the background process is running. The next, the filter property is set the opacity of 70%. The first line sets the opacity for Internet Explorer, the second for FireFox and other browsers. The height and width are set to 100%, which makes the DIV cover the entire viewable page, which is important because you do not want users interacting with the page. Finally the background color is set to a grey, #333 so as to emulate a disabled page.
#PopUpBackGround
{
z-index: 1400;
position: fixed;
top: 0;
left: 0;
height: 100%;
width: 100%;
filter: alpha(opacity=70);
opacity: 0.7;
display: none;
background: #333;
padding-top: 15%;
padding-left: 15%;
}
Now JavaScript must be used to display and hide the PopUpBackGround DIV. When the page is loaded the DIV must be hidden, so the script file enforces this by hiding it when it is loaded. The actual display and executing the process must be invoked by something, which in this case is hyperlink set to load an AJAX function. The function calls the process to be executed on the server, and displays the PopUpBackGround DIV.
HideElement('PopUpBackGround'); //Hides the DIV.
function RunDataProcess() {
ShowElement('PopUpBackGround'); //Displays the DIV.
GrayOutService.DataIntensiveProcess(OnDataProcessConplete, OnDataProcessException);
}
Now the background process runs, eventually returning a result. For this example it returns the time the process ended. The OnDataProcessComplete function is invoked when the web service finishes. This will hide the the PopUpBackGround DIV again and the time is displayed.
function OnDataProcessConplete(result) {
HideElement('PopUpBackGround');
var dResult = $get('dResult');
if (null != dResult) {
dResult.innerHTML = 'The Process Completed at - ' + result;
}
}
The actual result looks like the following:
Download Code