10 things a web developer should be careful of

I am a bit old-fashioned when it comes to web development. As much as I like the fancy new ways of doing things, I see so many websites where things go wrong and end up frustrating users.

Viewing websites on mobile phones is often the most frustrating, particularly responsive websites where the same website is designed to run on both a "resource-limited" mobile as well as a "resource-rich" desktop.

Here's my list of ten things web developers should be careful of.

1. Browser detection

   I have a Windows phone (yes, I am the one) and there's one company that sends me a regular email with an offer that sometimes I want to activate so I click the link in the email on my phone and it takes me to a web page. The "clever" developers have decided that because they don't recognise my browser's user agent that they will just show me an error message that my browser is not compatible. The offer doesn't get activated and I can't view any other pages on that website either. They have decided that their precious website can only be used if they know what browser is in use, just so it can display a message saying an offer has been accepted.

   In this case it would be much better to at least perform the server-side action of activating the offer, and attempt to display a success message.

   Here's another case of browser detection gone too far. A front end developer creating a new website for a large organisation decided that he should display a (non-dismissable) message across the top of every page of the website if he detected that the user was using an old browser that wasn't fully compatible with whatever HTML/CSS features he had used. Something like this...

   "Your browser is out of date. Please visit xxx to update your browser."

   Nice. Unfortunately the several thousand staff in this organisation were all locked into using a specific browser that just happened to be old enough that they would all see this message and they were not actually able to update their browser due to organisational policy.

   So please don't tell people what they probably already know. Chances are users know they are not operating on the latest browser, and are either unable to update it for some reason or don't want to update it.

2. Make your website accessible

   Many web developers know just the basics of web accessibility and nothing more.

   My advice to every web developer is to actually try a screen reader and other assistive technology yourself and see what it's like to navigate a web page.

   You'll soon learn how frustrating it must be for people to use web pages even if the website is properly accessible. And how infuriating it must be if it isn't done well.

   You'll learn the importance of properly structured navigation, content and why often a blank image "alt" tag is better than your 50 word description of some image that you just used to make the page look nice. And you'll find out all about the joys of HTML tables and accessibility.

3. Be careful about what you do on page load

   Don't you hate it when you go to a web page, one that is a little slow to load fully, and you start reading down the page, then some clever web developer decides that the page has now fully loaded and you should be scrolled to a specific part of the page, or you start typing into a text box and suddenly the focus is given to a different control?

   Be careful with what and when you do these types of things.

4. AJAX is great, but...

   AJAX has some great advantages and can make pages operate quicker and more like "desktop" applications, but you have to get them right.

   Here's some things that can go wrong:

   History: many people rely on the back button. If you have some nice infinity load list and someone clicks through to one of the items on the list and then clicks back, what happens? Are they taken back to the exact same list they just saw? Or are they taken back to the top and then have to infinity load back to where they were? Many websites don't get this right (because it can be difficult).

   Bookmarks: On a list page, maybe there's a bunch of filters and I've set them up with how I want to see the list and bookmarked it so I can always come back to that list. Imagine my surprise when they filters are all AJAX and the URL is not updated so I just bookmark the standard page instead!

5. Allow open in new window/tab

   Some websites accidentally block opening of hyperlinks in new windows/tabs. Middle-clicking the hyperlink just opens in the same window/tab, and/or the actually hyperlink is not a "proper" html hyperlink, just some other element with some JavaScript to make it work so right-clicking doesn't bring up a hyperlink-appropriate context menu.

   Some people (like me) often like to open a heap of items from a list page at the same time without having to keep going back to the list.

6. Speed

   Google know how frustrating slow websites can be, so they rank slow websites below similar faster websites. They even back AMP (Accelerated Mobile Pages) in an attempt to speed the web up (I don't like AMP very much though).

   I think that one of the biggest threats to performance is too much JavaScript. These days many web developers seem dependent on front-end frameworks that have a heap of JavaScript plus dependencies on other frameworks and libraries that also have a heap of JavaScript.

   I'm guilty of this too with my preference towards Bootstrap and jQuery (and their dependencies). Part of this is just laziness. See youmightnotneedjquery.com for how simple it is to do most things without jQuery.

   But advertising scripts are probably the worst offenders. We've "advanced" from simple banner and text advertising to complex dynamic advertisements that scroll through pages of items you previously looked at on some other website.

7. Times have changed, people are used to seeing more on the page

   In the early days of the web, pages with lists - such as products on an ecommerce website - used to be short, like maybe ten products per page.

   These days people are used to seeing a lot more items per list before they have to load the next page, or even be able to see everything perhaps with infinity scroll.

   I still see many recent websites that have ridiculously small lists that requires a lot of pagination to get through a long list, and an equally frustrating trip through browser history to get back to that other page you want to have a second look at.

   As per tip 4, using AJAX for lists pagination or infinity scrolling needs to be done very carefully otherwise it can be equally frustrating. The middle ground is perhaps non-AJAX pagination but with a generous amount of items per page.

8. Don't hide too much on mobile

   Some websites have separate mobile versions or are responsive and hide a lot of features that are available on a desktop.

   This can be very frustrating if you know about that feature from using on a desktop previously but can't find it when viewing on a mobile.

   I'm all for hiding superfluous content on the mobile, sometimes even things like breadcrumbs that can take up valuable real estate at the top of the page, but generally every feature should be accessible and available on all device versions.

9. Test properly

   Often web developers have high-end mobile phones and desktops and do a lot of testing in their own high-speed development environment.

   You won't really know how well your website works in the "real world" unless you test in a similar environment to what your users will be doing. That means possibly a low-end phone, wi-fi or 3G, away from your local server network, and on a typically loaded server.

10. Don't override normal behaviour

    I recently visited a website that had an autocomplete type search.

    The problem was that as I was typing, it was performing an AJAX query, and while it was waiting for the server response any keystrokes were ignored.

    I typed "the quick brown fox jumps over the lazy dog" and it showed as "the quck brown fox umps ve the lay dog". And I'm not even a fast typist.

    Best to let the browser do it's job here, and just listen in to what's being typed without intercepting it.