According to new research from HTTP Archive, which regularly scans the internet’s most popular destinations, the average size of a single web page is now 965 kilobytes (KB), up more than 30% from last year’s average of 702KB.

This rapid growth is fairly normal for the internet — the average web page was 14KB in 1995, 93KB by 2003, and 300KB in 2008 — but by burrowing a little deeper into HTTP Archive’s recent data, we can discern some interesting trends. Between 2010 and 2011, the average amount of Flash content downloaded stayed exactly the same — 90KB — but JavaScript experienced massive growth from 113KB to 172KB. The amount of HTML, CSS, and images on websites also showed a significant increase year over year.

There is absolutely no doubt that these trends are attributable to the death throes of Flash and the white knight, if-only-the-internet-was-a-damsel-in-distress emergence of HTML5 and its open web cohorts. It’s curious that the amount of Flash content hasn’t shrunk, though, which suggests that this year’s 33% increase in web page size is mostly down to a significant increase in website complexity and functionality, and not some kind of wholesale shift from Flash to HTML5.

The only real problem with the data is that HTTP Archive only began operating in October 2010 — and so there’s no way to find out the long time growth (or decline) of Flash. HTTP Archive, incidentally, constantly scans 16,000 websites — a list that was cobbled together from sources like Alexa and Fortune 500 — and records the total data downloaded, the number of individual HTTP requests required to fetch all of the content, the size of the JavaScript, Flash, and image content, and a bunch of other metrics. If you’re wondering about the odd spike towards the end, that’s where HTTP Archive increased its sample size from 16,000 to 50,000 — so presumably, the web’s top sites are smaller (or better written?) than the dregs.

So, what’s the actual significance of web pages that are almost 1MB in size? Not a whole lot, when you consider that caching will reduce that amount by 70 or 80% — and the more important statistic, at least as far as latency and rendering times are concerned, “total requests,” only increased from 74 to 85 over the last year (and again, caching will reduce that by 70% or more). One valid concern is mobile 3G and 4G surfers, where carrier data caps certainly haven’t increased by 33% over the last year — but even then, many popular sites have mobile versions that use significantly less than 1MB, and again, caching!

We would now expect the size of web pages to slow down a little, too. 2011 will have been the year in which many developers switched from Flash (or other technologies) to HTML5, and it’s unlikely that their first attempts will have been all that optimized. In 2012, JavaScript libraries will be refined, and cleaner ways of using CSS and HTML will be popularized. Even so, expect more mobile offerings that compress data, like Amazon Silk and Opera Mobile, to emerge as well.

Some people think there is no ‘right’ or ‘wrong’ way to code. I agree and disagree. I’m not saying there is only one right way and all developers should live by this method. I’m saying that there is a wrong way for anything. People can go about the same thing in many ways and it would be considered right. Each developer has their own style and comfort zone in how they do things and as long as it is efficient, doesn’t bear on page performance and doesn’t fall into the ‘wrong’ category then it’s still considered good code.

Right

• Following the rules that the W3C has defined for creating websites
• Following Web Standards, Best Practice and the KISS principle
• All code validates and runs error free
• Separate content from presentation
• Semantically correct markup
• Fully minimized and clean
• Makes sense

Wrong

• Using things in a manner they were NOT meant for (ex. tables for layout)
• Hacks that are unneeded (hacks are normally only needed for bad code)
• Overly complex (adding in some code because it was too simple)
• Re-writing built in functions (re-inventing the wheel of php)
• Doesn’t make sense

Right

To fully explain things there is the W3C which is an organization that standardizes Web technologies. They are the people who define how the web works in terms of HTML. Following these rules will not only keep the need for hacks at bay but it will also keep your code valid because that is what you are validating against when it comes to HTML and CSS. Yes… you are validating your code against the rules they have outlined for you. So tell me again why we wouldn’t follow the rules?

As for fully minimized and clean I mean can I look at it and point out anything not being used? Did the old stuff get cleaned out? Are there unnecessary things? Are there too many unneeded wrapping divs? Is the programming of the code logical? Can it be done in a simpler way? Basically take the code and remove everything you can from it. Make it as small and compact as you can without losing any functionality. Once you’re done it is minimized and clean.

Overall when I say there is a ‘right’ way I mean when any knowledgeable developer can look at the code and figure it out almost instantly because it is done the way it was intended and follows Web Standards and common sense then it is good code.

Wrong

Ahhhh the ‘wrong’ way. Man oh man is there a definite wrong way of doing anything in life. Let’s take going to a grocery store that is half a mile down the road. What is the right way to get there? There are a few ways that would work I mean you could walk, take a bus, ride your bike or even drive your car. All these work and are logical. Well what about walking 1 mile the opposite direction to get on a bus that takes you to the airport where you fly round trip to the furthest destination and on return get a rental car and drive straight to the grocery store. This in my eyes is wrong.

It may seem dramatic to some but you have to admit that’s not the most efficient way to get to the grocery store. You might catch yourself thinking ‘Why would anyone do that?’… And that is a good indicator question that determines bad code.

On a less obvious side there are other things that make it the ‘wrong’ way including invalid, erroneous, weighted, hacked and non-logical code. When people use tables for layout it is actually wrong because it is invalid. If errors pop up or it takes triple the time to load due to controllable factors it is wrong. If you use JavaScript to apply CSS classes or inline styles when there is no JavaScript functionality on the page then it is wrong. If you are re-writing built in functions for any scripting language then it is wrong. These are just a few examples that there are wrong ways of coding things.

Conclusion

In conclusion I understand that some developers use floats and some use positioning this is their style and both methods work. There is a difference between that style factor and the just plain wrong or outdated factor.

I know I can’t make everyone a believer overnight, some will just always believe if it runs then it must be good code. However I encourage you to Google the ‘benefits of web standards and best practices‘ and after a few good reads go ahead and try to search for the ‘downfalls of web standards and best practices‘. Since I don’t know of any downfalls please comment below if you do find any.

Also stay tuned for more blog posts about this topic.

This checklist is not all-inclusive but it covers some major areas that need to be tested with any major development.

• Accessibility (SortSite http://www.powermapper.com/products/sortsite/)
• HTML Validation (W3C http://validator.w3.org/)
• JavaScript Validation (JSLint http://www.jslint.com/)
• CSS Validation (W3C http://jigsaw.w3.org/css-validator/)
• Performance  and speed (GTmetrix  http://gtmetrix.com)
• Design (PixelPerfect http://pixelperfectplugin.com/)
• Test in all browsers listed in the requirements
• Test without JavaScript, Flash and other plug-ins
• Print version

Lastly take a look at the logic and code itself to ensure that it follows Web Standards, Best Practice and the KISS principle (http://en.wikipedia.org/wiki/KISS_principle).

With the rise of mobile devices, web development and debugging is more complex than ever. We have more browsers and platforms to support. We have more screen sizes and resolutions. And we’re building in-browser applications instead of the flat, brochure-ware sites of yore.

Luckily, we also have better tools. The JavaScript console is a standard feature of most major browsers. Both JavaScript and the HTML DOM offer native error handling. We also have services and applications that help us remotely debug our sites.

Read Full Article...

The subject of HTML5 has been the buzz amongst Beacon’s Web Designers, who are anxious to try it out.  It’s been called “the future of the web” (see one of my developer’s articles about this).  The problem is that we support such a wide variety of browsers that it’s hard to jump on the HTML5 bandwagon because none of the older browsers (IE 7/8, Firefox 3.0, etc.) fully support HTML5.  However, now that IE 6 is out of our collective hair, IE 7′s grave plot is being dug, and Firefox 3.0 seems to be gone, so we’re slowly moving towards only supporting browsers that comply with HTML5 standards.

Another reason it’s hard to jump on the HTML5 bandwagon is that the W3C / WHATWG team hasn’t finished the standards for it yet, and likely won’t do so until 2014.  I found all of this in an interesting article on CNET, “W3C officially opens HTML5 to scrutiny“.  Essentially, the article says that the W3C thinks that the standards for HTML5 are solid enough to have organizations review them and see if they can garner support, so they put it out for “last call”.  In other words, we’re a long way from having finalized standards.

Bits and pieces of HTML5 are supported in a lot of browsers (some browsers support more bits than others), but it’s hard as a Web development company with such a wide user base to code stuff that a good number of people couldn’t even see.

With that being said, as more browsers support HTML5 code, Beacon will be keeping a close eye on the progress of browser acceptance of new tags.  Our CMS of choice, Cascade Server, now has limited support of  HTML5 with its latest release (6.8), taking an important step towards becoming more compliant.  Hopefully soon, I can turn my developers loose on HTML5…they’re all anxious to take on a new challenge.

You Are The Pride (University of Houston)
(http://www.youarethepride.com/)

Before Beacon became involved, the University of Houston developed a social media-focused website, named after their slogan, “You Are The Pride”. This project aimed to centralize all of their social media outlets, including ones that the various users created (students, alumni, etc.) along with videos and photos that could be uploaded.  Beacon Technologies was brought in to enhance the current site with the following:

· Provide cross-browser and Section 508 compliance by re-writing the HTML/CSS/JavaScript applications;

· Migrate the entire site from its current format into Cascade Server CMS;

· Add a Blog listing feature into the Cascade Server implementation, which categorizes each blog site entry, and pulls in data from each blog’s RSS feed;

· Add a Social Media listing page, which organizes each link by category, and type (Facebook, Twitter, YouTube);

· Develop PHP-based registration and login functionality, including an Administration section for managing user access;

· Insert a commenting application (Echo) on certain pages;

· Provide customized Cascade Server documentation and training.

Kudos go to Tiffany May and Gary Synan (transactional development), Annette Fowler (business analysis & requirements), Justin Klingman (project management / CMS leadership),  and  Tracy Dirks (executive management).

What will the future hold for web design? Smartphones and tablet sells have hit an all-time high which means mobile web is beginning to grow at a fast rate. Social networking sites like Twitter and Facebook have become a great way to not only connect with friends and family but to connect with companies and consumers. And with new development tools like CSS3 and HTML5 on the horizon we may be looking at a whole new way the web is designed. So what is 2011 going to bring for web design?

Mashable.com released an article at the beginning of the year with four Predictions for Web Design in 2011.

To read the full article: http://mashable.com/2010/12/30/web-design-predictions/

To Slice or Not to Slice: What’s the Big Deal?

Let me start off by explaining the bigger picture a bit and why this issue is worth writing about in the first place. In the past, I have had to deal with badly organized design files where nothing is in any particular order, nothing is named appropriately, and there are no slices. Trying to sort through it in order to make a simple update is like a guessing game. It wastes a lot of time and can be very frustrating. Just because you know how everything works in the design file, does that mean when the client asks for a change months later that someone else will be able to come behind you, open the file, and be able to clearly discern where everything is and how it’s organized? Will you remember months down the road? I can tell you from experience that if things are not organized and named well in a design file, the answer to that question is an emphatic “No”.  Some design files can have 80+ layers containing hundreds of graphics and things can get pretty complex. Trust me, it always helps to find things in the file if the layers, groups, and slices are well organized and named accordingly… and it helps to have slices. This really isn’t an option, at least it shouldn’t be.

The Old Photoshop “Crop & Undo” Doesn’t Cut It

There are bigger issues than simple file organization and naming. I have had to make updates to websites that required updating the graphics. A basic example of this would be that the company logo has been updated and the new version of the logo needs to replace the current logo image on the site. This should be a simple change and will be if there is a design file with a slice path for the logo graphic. If not, this might not be so easy. This can especially be troublesome if the logo sits on a gradient background. In order to have the gradient line up when the logo is replaced, you need to know exactly where the logo image sits on the background. If you crop the logo out of the design and you’re just one pixel off, it will show because the gradient will not match up. One solution may be to save the logo out as a transparency, but what if that’s not an option? Because in some situations it won’t be an option for one reason or another. This scenario demonstrates the problem with the old Photoshop crop and undo method. Because with that method, there is no record of where the graphic elements were cut out of the design. This can really be a problem when you have to go back to the design file and figure out where and how something was cropped originally, because sometimes it is not so easy to get it to match up.

But What About Slices? What Are They Anyway?

Glad you asked! Okay, so obviously the slices I’m referring to have nothing to do with bread. Instead, it’s a neat tool for cutting a design up in smaller bits. Both Photoshop and Illustrator have a Slice Tool (formerly called “Knife Tool”). Of course, just like with most of the other tools Photoshop and Illustrator have in common, the Slice Tool works a bit differently in Photoshop than it does in Illustrator. I prefer Illustrator slices because in my opinion, they are easier to work with.

In order to make a website, you have to cut the design up in pieces sort of like a puzzle and then cleverly put it back together using HTML and CSS. In Illustrator, using the Slice Tool allows us to cut the design up in the necessary puzzle pieces. Basically, you use the Slice Tool to draw out rectangles (paths) over the graphic area you wish to cut out of the design. That is the sole purpose of slices, to carve the graphics out in rectangular pieces from the design file. The best part is that the slices are saved in the file, so you have a record of it. In Illustrator you can make a Slice Layer and have all your slice paths under that layer. This makes the slice paths easy to find, and allows you to maintain the exact dimensions of all the graphics that were originally cut out of the file. You can hide the slices so that you don’t see all the slice path outlines, show the slices when you need them, and you can lock the slices, which is usually a good thing to do to ensure you don’t accidentally move the slices around. So if you come back to a design file a year later in order to update some of the graphics, you can use the original slices in order to make sure the graphics are cut out exactly like they were when the website was originally developed.

Before You Slice…

Before you create slices it is a good idea to create a new layer at the top of the layer stack and name it “Slices”. The reason for this is that the Slice layer is a “special” layer and you should treat it differently than other layers. Once you make a Slice layer, you can then make slice paths and place them within that layer. I will explain more about this and why they should be at the top of the layer stack a little later on.

During the process of creating a website design there comes a point when screenshots are needed in order to present the design to the client for feedback and approval. This is the point where I always create a Slice layer in the design file. So often times, once I hand a design file over for development, it already contains a Slice layer at the top of the layer stack with a layer named “screenshots” that contains all the slice paths I used to make the screenshots within it.

Name That Slice!

Whenever you make a slice path, Illustrator gives it the name “<Slice>” by default. It is a good idea to rename the slice. To do this, double click on the path in the layers palette and a window will pop up where you can type a name for the slice.

What’s In a Name?

Meaning… names give things meaning. It does not make sense to use a name for a slice that is in no way related to what the slice is being used for. Just like with programming and development, typically it is a good idea to give variables, id’s, and classes meaningful names related to their purpose, so it is with slices in a design file. For example, if you are creating a slice path for a submit button, then a meaningful name for that slice might be “submit” or “submit btn”. Whatever you choose to name it, just be sure it is relative to the graphic that the slice is being used to cut out of the design. The reason this is important is because not only do some website design files contain tons of layers and graphics, but they will also need many slices in order to cut all the graphics out. Again, it is very difficult for someone else to open up the design file months later and figure out which slice goes to which graphic, and it only makes matters worse when there are 80 slice paths that are in no particular order, and they all have arbitrary names or even worse, they’re all named “<Slice>”.

Slices Are Special

Earlier I referred to the Slice layer as “special”. The reason for this is that you can do things specifically with slices that you cannot do with other graphics layers. In Illustrator you can choose to “Show Slices”, “Hide Slices”, and “Lock Slices”. When you choose one of these options, it only affects the Slice layer and slice paths. It does not show, lock, or hide, any other layers. The other thing that makes slices special is that they should be placed at the top of the layer stack in order to maintain your sanity. Trust me on this.

Where Did it Go?

The Slice layer containing slice paths should reside at the top of the layer stack. As a best practice, nothing should ever be placed on a layer above the Slice layer. This is because slices should always be above the graphics they are meant to cut out. Imagine trying to carve a space out of something located on a shelf above your head, but you cannot see it because you are unable to look up, you can only look down. That is sort of the way slices work, they cannot see what’s up above them very well, only what’s below them. Thus, the graphics you want to cut out should always reside below the slices. As a matter of fact, Illustrator sort of does it for you.

If you have a graphics layer selected and switch to the Slice Tool in order to create a new slice path, by default Illustrator will create a new slice above your current layer (the one you had selected before you made the slice path). That’s a neat trick and it’s great Illustrator does that for you, right? Sure it is. But it is also a great way for you to lose track of where your slice went. So keep track of where you create your slice paths in the layer stack and if you happen to accidentally create a slice path while you have a graphics layer selected, grab that slice and move it up under the Slice layer. If you don’t, you may encounter some puzzling side effects of buried slices. I’ll refrain from telling what those side effects are, I’ll let you figure that out on your own. If the problem ever presents itself you aren’t likely to forget it again. The best way to avoid it altogether is to make sure all your slice paths end up under the Slice layer!

Saving Sliced Images

With slicing, you can either save each slice as you go, or you can wait until you have all the slices done. When saving out slices, slice order matters, really matters. Generally it is a good idea to move the slice path you want to save to the top of the stack in order to make sure there are no overlapping slice paths above it. If there are overlapping slices, the topmost slice wins and this can produce some strange results. So put the slice you want to save on the top, that way it will win every time!

When you are ready to save your slices, you will need to use “Save For Web & Devices” instead of the traditional “Save” or “Save As”. When Saving For Web, you will be presented with various options. Different people like to set their Save For Web options differently. You can have Illustrator write out HTML for you (I don’t usually use Illustrator’s generated HTML), you can choose the file type (.jpg, .png, .gif) and specific settings for each type, have Illustrator save out multiple slices at a time, specify a naming convention for slices, a naming convention for the saved images, and also choose to have Illustrator save all the images to a specific place automagically. Feel free to explore all the options and decide which ones work best for you.

Extra Tips & Tricks

Now that you know how to use slices, below you will find some extra tips for a few of the peculiarities I have experienced when using slices.

Dealing With Decimal Pixels

Depending on how you look at it, or rather how you use Illustrator, one downside can be that Illustrator allows for decimal measurements and placement of graphics. This can be a problem with web graphics because in HTML and CSS, there is no such thing as a .5 pixel. If you make a slice and its x-position on the Artboard is at 100.725 pixels and its width is 200.256 pixels, well that does not compute in HTML and CSS. In order to resolve that issue, Illustrator forces the slice to use whole numbers instead of decimals when it is saved out. You will see your slice path outline, and then a second outline showing the actual size and location of the slice. This second outline is Illustrator compensating for the decimal numbers, and it always rounds up and chooses the ceiling of the decimal number for width and height values. So if you have a slice path 200.256 pixels wide, Illustrator will make the actual size 201 pixels. Also, if the slice has an x-position or y-position that includes a decimal, Illustrator will force the positions to be whole numbers as well. Again, you will see your path outline and a second outline showing the actual location/size of the slice.

In Illustrator, one of my favorite tool panels available is the Transform Panel. The transform panel makes it very easy to measure and place elements to the exact pixel needed. The thing I love the most is that you can do math right inside the Transform Panel. If you need to move an element to the left or right 20 pixels, then you can just add or subtract 20 pixels from the x-position. You can add, subtract, multiply, and divide in the Transform Panel.

The Transform Panel also works well with slices. If you create a slice and you see the slice path and a second outline showing the actual size and location of the slice, then you already know that the slice dimensions are not whole numbers, or the slice x & y positions are not whole numbers, or all of the above. You can use the transform panel to size the slice correctly and put it in the exact place you need it. In the transform panel, choose the registration point that coincides with the top left corner. Once you have done that, you can set your x-position, y-position, width, and height to whole numbers and the slice will adjust accordingly.

Missing or Blank Images

Sometimes you may try to slice out a graphic but when you save it out, either nothing is saved, or the image that was saved is blank. If this happens, try turning on the Artboard and see if the graphic you are trying to slice out is positioned outside the Artboard area. If it is, you can adjust the size of the Artboard to include the graphic you are trying to slice out. This should fix the problem.

If you’re a developer or have ever messed around with html and style sheets you will know that getting it to look the way you desire isn’t always the easiest job. What’s worse is when you finally get it perfect just to find things are much different in other browsers. Personally I use a variety of tools when developing and quite a few specifically for cross browser testing and ensuring an exact design to development match. These tools include:

General Browser Testing:

Spoon.net – http://spoon.net/browsers/

This website will allow you to run a variety of browsers as if they were installed on your computer. This is by far the best overall browser testing tool I have run across.

IE Tester – http://ietester.com

For general testing in Internet Explorer I often use IE Tester as a quick check to ensure all development is coming along as it should in Internet Explorer 6, 7 and 8. I also like the Dev Tools offered in this software that allows me to get a closer look at the code.

Specifically for Matching Design to Development:

Pixel Perfect – http://www.pixelperfectplugin.com/

This is one of my favorites, it is a Firefox add-on that allows you to overlay the design image on top of the developed HTML to match it up Pixel Perfect.

Microsoft Expression Web 3 SuperPreview – http://expression.microsoft.com/en-us/dd819431.aspx

For internet explorer I use the trial version of Microsoft Expression Web 3 SuperPreview. It allows you to overlay the design image on top of the developed HTML like the Pixel Perfect Firefox add-on.

Every usability expert, designer or developer could give you different opinions about what makes forms more usable, less confusing and less daunting. I sought out to research all the experiments and form a general list of things that developers, designers, and gurus should and should not do. The rest, as usual, always depends on the context of the project.

After combining this research with fellow co-workers and everyone’s combined knowledge, I generated a short list of common things you can do to improve your forms, but I want to discuss what types of forms I’m talking about first.

One type of form is the generic one: I’m talking about the generic “contact” form on the web, the one with fields that aren’t even new to my grandmother anymore. Fields are empty areas for you to fill in data, usually personal data. Fields like “Name”, “E-Mail Address” and “Comments” are very well known. Also, forms like “Request for Quote”, “Search” or “Sweepstakes” have much in common with the “Contact” form: they are generic, no task required, “enter in that information yet again”, forms.

The other type of form is one that requires more thought on the user. Forms like these include insurance quotes, submitting payment, government forms, loan requests, etc. These are the types of forms you receive in the mail in a booklet and have an instruction book accompanying it. These forms are quite different from the “generic” forms I mentioned above. The more data and thought necessary required from the user, the more division and instruction is needed in the form itself. In general, I think each form in this division should be designed in each instance, so I don’t think general tips apply all the time, but most of the ones I will list can apply.

So we will only be discussing the generic form, which is a good base for any working professional in this area I think. This form shares a commonality with many others, your contact form will be at least 50% identical the next guy’s contact form, and this means that already your user base is experienced with your form. Which brings me to the first tip:

#1 Don’t break convention just because it looks neat or you think it’s better
Break convention only if it works better. Your forms should be putting your user first. They are active participants ready to endure your form gauntlet – do not change their minds! Making your forms work should be the number one priority. What’s the only way to know if it’s working better? Field testing.

#2 Do field testing
I can’t agree with the usability experts more: field testing always shows you what went wrong or right with your forms. I understand that many companies lack the resources to hold usability tests, but they are a necessity. My favorite thing to do is actually allow the client to field test by bringing them in and watching them use your form. Make your coworker do it. Make your mom do it. Don’t tell them you’re testing the usability, make something up. If you are able to watch them use it, you did not guide them through it and you learned something from the experience, congratulations, you just did usability testing. Now take notes and correct what went wrong. This won’t be as accurate as some measurement tools the experts have, but it’s just as helpful and it was free. Have to say, nothing is more embarrassing then to watch that client months later use it and complain because it makes them frustrated or simply does not work. Field test before it’s too late.

#3 “Use the right field for the right task”¹⁸
Crescimanno and Nielsen argue that every field type should be appropriated correctly with the label. For example, if your label said “First Name” you should not use a radiobox for your field because then the user cannot correctly fill in their first name. A more complex example would be if your label said “Expiration Date” and you gave the user 3 drop down menus, 1 for month, 1 for day and 1 for year. The month and day fields have an absolute beginning and end, 01-12 for month and 10-31 for day. The year field, on the other hand, is a bit arbitrary since we are concerned with when said subject expires. Do you list the years until 2012? 2050? Should the user have to endure a very, very long drop down menu or should the user face having their year not even listed? If you put into too many years or not list enough, respectively, this could happen. Why not just make all 3 fields free entry? Or why not require just month and year in the same format and make it easier not only for the user, but also your developer? Usually there is a good solution to every type of data you need. And like Crescimanno suggests, stay away from multiple-selection boxes that are confusing (and may not even work in all browsers).

#4 Don’t let your clients pick your form structure for you
Unless your client is a certified master in creating usable forms, don’t allow them to pick what type of data they “think” they need. Have a good sit down with them and ask considerate questions about why they think they need this form, what do they expect from the user, what data are they looking for, how do they intend on using the data, and so on. I guarantee that your company (full of qualified, wonderful people) can create not only a more usable form, but also a form that integrates better with the database, integrates better with the graphical design of the website it is in, does not deter the user away, that takes the least amount of time to fill in, etc. Clients are blind-sighted by the bigger picture, take control of this crucial analysis process.

#5 Use informative error messages¹
Don’t tell me the form encountered a critical error after I hit “submit”. Don’t tell me my e-mail address is invalid when I only have not registered with it yet. Don’t tell me my password is not strong enough, tell me why. Please.

#6 Use better placed labels¹²³
Do not make them bold, do not place them far away, make them consistent with other labels, right-align if you won’t place the label above the field and don’t use illegible fonts.

#7 Quit putting in a reset button⁴
Reset buttons are accidentally hit instead of the “submit” button when the user submits a form, so what purpose does it serve?

References:
1 A List Apart: Sensible Forms: A Form Usability Checklist
2 UX Matters: Evaluating the Usability of Search Forms Using Eyetracking: A Practical Approach
3 UX Matters: Label Placement in Forms
4 Creating Good Websites: Usability
5 Sitepoint: 7 Steps to Usable Forms
6 Krug, Steve. “Don’t Make Me Think: A Common Sense Approach to Web Usability”, 2000, New Riders Press.
7 Nielsen, Jakob. “Designing Web Usability”, 1999, Peachpit Press.