Include the following code in the <head> tag, or in the common.js file in your website(hoping that you call it in the master page or the relevant form).
function disableEnterKey()
{
if (window.event.keyCode == 13) window.event.keyCode = 0;
}
And in the form that you want to disable the Enter/Return key, add the following code.
<form id="form1" runat="server" onkeypress="disableEnterKey()" >
Its completely situation dependent, but I use it at the master-page level itself.
I have been developing web-applications in one form or the other over the past 4-5 years at various capacities. And over the years of developing, learning, failing and rebounding, I have compiled a list of tips that I found were very useful for any developer per-se.
Clarity of text/content
When you land on a web-page, chances are you wont sit and read every word on the page. That would mean that one needs to be smart enough to decide what constitutes the content of a page, and ensure that the text/content reaches its intended audience. However, in an event that the audience does not quite follow you, help icons should be there on every page to describe the user about the page.
Way to display data with message to be conveyed (the web 2.0-ish style : bigger fonts, contrasting colors)
One of the noticable and praise-worthy achievements about the web 2.0 revolution is the simple fact that sparing the eye-candy, it ensures that the human eye catches the information that the designer really intended for the eye to catch. I wont go into further detail on this, but the web 2.0 trend does a good job in this regard (bigger fonts, contrasting colors, curved borders, shadow effect, pop-outs[not pop-ups], animation while opening windows, to mention a few).
Data to be retrieved on demand (Async web-services)
With all the hype around the "Software as a Service", the real message it is trying to convey is that "Dont transfer large amounts of data fewer times, instead transfer small amounts of data on a more frequent basis. The reasoning behind this is that the real-estate you have on the monitor is pretty limited, and you can show only so much amount of data at a time. However, with the sudden surge in the usage of tabs to show more data (atleast the simulation of showing more data), you don't need to retreive all the information inside all the tabs when the page is loaded for the first time. Load it exactly when you need it(when the user clicks on the tab).
Get rid of the flicker
As we go more and more into the web 2.0 enabled web-sites/applications, we will get used to less and less flickr. Not that its wrong to render the whole page everytime, its just that as users, we expect every site to behave similarly.And when we find anamolies, we tend to switch to the vendor that provides the web 2.0 look and feel. Getting rid of the flicker makes you look more abreast with the latest trend, and thereby improves acceptance. Heck, even though you are a developer, you would prefer a more jazzy looking site than your own non-jazzy one anytime.
Cross browser support(atleast IE6/7, Firefox, Opera) (include Safari as well)
Nothing new about this. However, IE7, Firefox x.x, support most of the css and xhtml standards. So development should be oreinted towards being properly visible in a minimum of the above mentioned browsers. Javascript is always an issue, but the wider the platforms you support, the wider your audidence is gonna be.
Fewer pop-ups
Most pop-up blockers are now enabled on every browser, and its futile to sit and find out how each pop-up blocker works.Instead you are better off trying to work-around it by using non-obtrusive pop-outs in conjunction with blurry backgrounds to do the same job. The end-result is some good eye-candy, and at the same time it makes your application more usable.
Shorter length web-pages (as much as possible)
One of the cardinal rules of web-content development is to avoid junk on a page. Keep your page a no-nonsense page.Am not referring to advertisements here. But make your page less cluttery and short. No one wants to sit and go through a long page.
Less data required to create a new entity (eg : Project name, User registration)
Sparing a few exceptions, like maybe banking applications, insurance applications, and some other very important services that are using the internet as a delivery mechanism, no user-registration page should be more than a single screen long. It makes it boring. And I personally hate the CAPTCHA controls being used pretty widely across all the registration pages. They are not necessarily a bad thing per se, but they are kinda annoying and go against the whole idea of a pleasant user-experience.
Page anchors/navigation for long pages
Sometimes, you cannot avoid having long-pages. Terms of Service, Copyright information, etc are a few examples where you want to save yourself, and in turn end up displaying a 70 page long document on a web-page. While its doing its job of covering your ass, I think its best to give use some kind of "Jump to top of page" links positioned in your page at places that are beyond the scope of a single screen.
Considerably descriptive tool-tips/call-outs
Tool-tips/Call-outs are nicer ways to represent hints, validation messages, and other small bits of information that not necessarily fall into the content section of the page, but they would be falling into the "nice-to-have" stuff to better user-experience. Use judiciously.
For web-applications, an offline model support via windows applications
With the concept of rich-internet applications floating around for the greater part of the past two years, web-applications deliver to most of their hype. However, we need to remember that its very dependent on the connection speed. Yes, we have been promised amazing speeds, but the truth remains that we wont have anything noticable within the next 10 years with our existing ISP's. Unless a new company comes up with fiber-optic cables providing every computer with blazing fast connection speeds. Good to have stuff, but long time to deliver. Google gears is worthy to note here because of its offline model. Obviously, it wont be long before Microsoft and Yahoo follow suite. But the likelyhood of Microsoft to succeed in this area is far higher than others simple because they already have an offline model.
The whole idea of having an offline model is that we wont have to rely on those connection-speeds to deliver rich functionality to the end-user. Why should you put a restriction on him regarding his internet connection. This brings up the concept of occassionally connected systems.(a topic for some other day)
For web-applications, an open API in the form of web-services
This tip follows suite to the offline model concept. Just that it makes the amount of development and maintenance bearable in the long run.
Color-coding with legends
Not always a good thing, but its mostly relevant to tables/reports and charts.
Longer grids should be shown with scrollable divs
While paging is a good thing to have, scrollable divs dont necessarily replace the paging concept. Just that it make the UI look better. Same amount of space is used no matter how many real-records are being displayed. The end user is welcome to scroll up/down as he choses. And based on relevance, ensure that you allow the end-user to add a new entry of the type in the grid.
When showing dashboards with lists, ensure to show top n records with no-search condition. No one wants to search when they land on that page first. Make searching an option.
There are two schools of thought in this regard. One school believes that show the minimal information to user. If the user wants, he will search whatever he wants. While the second school of thought believes that when the user lands on a page, he should have to do almost close to nothing to see data.
When showing stats (generally in a dashboard), supplement textual data with a graphical layout
This is a very basic rule of thumb in terms of user-friendliness, but its important that color combination you choose plays a big role in retaining his attention. Another big player in this field, is what you can do with the graphical layout. Stuff like changing the default format of the chart, making annotations on the chart, peforming what-if analysis on the chart, etc, are few things that end-users expect to see in the chart. The flip side of charting is that once the end-user sees a chart in a web-application, the general tendency is to see charts all-over. This tendency sky-rockets when it comes to web-applications showing lots of numerical data in the form of reports.
The above set of tips is by no means complete or intended to be comprehensive. However, it attempts to cover the major milestones in a humble approach to web-development for the end-users. Should there be something that I missed, please feel free to leave a comment or send me a message, and I shall be glad to oblige.
When using ActiveDirectoryMembershipProvider, default login options mandate your username to be [username]@[domainName].[extn].
However, should you want to use just the username, and nothing else, then the simplest option would be to add the attributeMapUsername attribute in the configuration file (membership section).
Example :
<membership defaultProvider="ADProvider">
<providers>
<clear/>
<add name="ADProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADConnectionString" attributeMapUsername="sAMAccountName" />
</providers>
</membership>
Options for attributeMapUsername are :