The following list is in no particular order.
1) Writing old school HTML
Mistake: The early days of the internet had much less options for markup than we do today. However, old habits die hard, and many still write their HTML as if we were still in the 20th century. Examples here are using <table> elements for layout , <span> or <div> elements when other semantic-specific tags would be more appropriate, or using tags that are not supported in current HTML standard such as <center> or <font>, or spacing items on a page with a large number of entities.
Impact: Writing last decade's HTML can result in over complicated markup that will behave inconsistently across multiple browsers.
How to avoid: Stop using <table> element for layout of content, and limit usage for it to displaying tabular data. Get acquainted with the current markup options available such as seen at https://html.spec.whatwg.org/multipage/semantics.html#semantics. Use HTML to describe what the content is, not how it will be displayed. To display your content correctly, use CSS (http://www.w3.org/Style/CSS/).
2 ) "It works in my browser…"
Mistake: A developer may be fond of a particular browser or really despise one, and might primarily test web pages with that bias in view. It is also possible that code samples found online may be written without factoring how it would render in other browsers. Also, some browsers have different default values for styles.
Impact: Writing a browser-centric site will likely result in very poor quality when displayed in other browsers.
How to avoid: It would not be practical to test web pages in every browser & version during development. However, having a regular interval of checking how your site will appear in multiple browsers is a good approach. Sites such as http://browsershots.org/ show snapshots of how a given page would render over multiple browsers/versions/platforms. Tools such as Visual Studio (https://www.visualstudio.com/en-us/visual-studio-homepage-vs.aspx) can also invoke multiple browsers to display a single page you are working on. When designing with CSS, consider "resetting" all the defaults as shown at http://meyerweb.com/eric/tools/css/reset/.
If your site is using any CSS features created specific for a browser, be cautious as to how you will approach vendor prefixes such as -webkit-, -moz-, or -ms-. For guidance on industry trends in this regard, it would be worth your time to examine the following references:
While the above references explain a movement away from vendor prefixes and why, this site http://davidwalsh.name/goodbye-vendor-prefixes provides practical suggestions on how to work through this today.
3) Bad form
Mistake: Prompting a user to provide any information (especially when entered into a text field) and assuming the data will be received as intended.
Impact: Many things can (and likely will) go wrong when user entry is trusted. Pages may fail if required data is not provided, or data received is not compatible with an underlying data scheme. Even more serious is the intentional violation of the site's database, perhaps through Injection attacks (see https://www.owasp.org/index.php/Top_10_2013-A1-Injection).
4) Bloated responses
Impact: The time to have a page completely render becomes long enough for some users to give up or even impatiently re-request the whole page again. In some cases, errors will occur if page processing is waiting too long.
How to avoid: Don't adopt the mindset that access to the internet is getting faster and faster - thus allowing for bloated scenarios. Instead, consider everything going back and forth from the browser to your site as a cost. A major offender in page bloat is images. To minimize the cost of images that slow down page loads, try these three tips:
- Ask yourself: "Are all my graphics absolutely necessary?" If not, remove unneeded images.
- Minimize the file size of your images with tools such as Shrink O'Matic http://toki-woki.net/p/Shrink-O-Matic/ or RIOT http://luci.criosweb.ro/riot/.
Before we leave this topic, strive to be current with HTML (see mistake #1) and use good judgment when using <style> or <script> tags in HTML.
5) Creating code that *should* work
Impact: Sites without proper error checking may reveal the errors to the end users in an ugly way. Not only can the user experience be dramatically impacted, the type of error message content could provide clues to a hacker as to how to infiltrate a site.
Failures in server-side code should be caught without the user seeing any of the nerdy details. Reveal only what is necessary, and be sure to set up friendly error pages for things like HTTP 404s (see http://en.wikipedia.org/wiki/HTTP_404).
6) Writing forking code
Mistake: With the noble notion of supporting all browsers and versions, a developer creates code to respond to each possible scenario. The code becomes a heap of if statements, forking in all sorts of direction.
Impact: As new versions of browsers update, management of code files become bulky and difficult to manage.
How to avoid: Implement feature detection in code versus browser/version detection. Feature detection techniques not only dramatically reduce the amount of code, it is much easier to read and manage. Consider using a library such as Modernizr (http://modernizr.com/) which not only helps with feature detection, it also automatically helps provide fallback support for older browsers not up to speed with HTML5 or CSS3.
7) Designing unresponsively
Mistake: Site development assumes viewing in the same size monitor as the developer/designer.
Impact: When viewing the site in mobile devices or very large screens, the user experience suffers with either not being able to see important aspects of the page or even preventing navigation to other pages.
How to avoid: Think responsively. Use responsive design (see http://en.wikipedia.org/wiki/Responsive_web_design) in your sites. A very popular library ready to serve in this area is Bootstrap (http://getbootstrap.com/).
8) Making meaningless pages
Mistake: Producing public facing pages with content that might be very useful, but not providing any hints to search engines. Accessibility features are not implemented.
Impact: Pages are not as discoverable through search engines and therefore may receive little or no visits. The page content may be very cryptic to users with impaired vision.
How to avoid: Use SEO (search engine optimizations) and support accessibility in HTML. Regarding SEO, be sure to add <meta> tags to provide meaning to a page with keywords and description. A good write up on that is found at http://webdesign.about.com/od/seo/a/keywords-html.htm. To enable a better accessibility experience, be determined to provide an alt="your image description" attribute in each of your <img> or <area> tags. Of course, there is more to do and further suggestions can be investigated at http://webdesign.about.com/od/accessibility/a/aa110397.htm. You can also test a public web page at http://www.cynthiasays.comCythiaSays.com to see if it is compliant with Section 508 (http://www.section508.gov/).
9) Producing sites that are too refreshing
Mistake: Creating a site that requires full refreshes of a page for each interaction.
Impact: Similar to bloated pages (see mistake #4), performance of page loading time is affected. The user experience lacks fluidity, and each interaction could cause a brief (or long) resetting of the page.
10) Working too much
Mistake: A developer spends a long time creating web content. Time might be spent doing repetitive tasks, or simply typing a lot.
Impact: Time for initial web site launch or subsequent updates is too lengthy. Value of the developer diminishes when it appears other developers are doing comparable work in less time and with less effort. Manual labor is prone to mistakes, and troubleshooting mistakes takes even more time.
How to avoid: Explore your options. Consider using new tools or new process techniques for every stage of development. For example, how does your current code editor compare to Sublime Text (http://www.sublimetext.com/) or Visual Studio (https://www.visualstudio.com/en-us/visual-studio-homepage-vs.aspx)? Regardless of what code editor you are using, have you recently dived into its features? Perhaps a small investment of your time perusing the documentation could unveil a new way to do something that could save hours & hours of time later. For example, note how an extension to Visual Studio can increase productivity for web developers as seen in this post http://www.palermo4.com/post/WebCamp-Essentials.aspx.
Don't miss out on tools available on the web to help! For example, check out the tools at http://dev.modern.ie/tools/ to simplify testing (across multiple platforms and devices) and troubleshooting.
You can also help reduce time and mistakes by automating processes. An example of this is using a tool like Grunt (http://gruntjs.com/) that can automate things such as the minifying of files (see mistake #4). Another example is Bower (http://bower.io/) which can help manage libraries/frameworks (see mistake #9).
How about the web server itself? With the help of services such as Microsoft Azure Web Apps (http://azure.microsoft.com/en-us/services/app-service/web/), you can quickly create a site for virtually any development scenario that can easily scale with your business!
By identifying common mistakes, web developers can eliminate much frustration that others have already endured. Not only is it important to acknowledge, but when we understand the impact of a mistake and take measures to avoid it, we can create a development process catered to our preferences – and do so with confidence!