“Beautiful webpages created with years of real programming expertise”
Web page design studio - Part two: Client-side technical considerations, HTML and stylesheets authored correctly
Part 2
Design studio
This is part two of our design studio.
If you haven't already read part one, we suggest that you review it before continuing here.
Like any large project, creating a high-quality on-line presence requires attention to some technical details. These un-glamorous considerations are easily overlooked, especially during the initial excitement of getting a new project on-line when attention is focused on visual appeal and features. However, mistakes here can severely impact basic functionality and reliability, and by extension, erode business credibility.
Many of the common mistakes that we highlight in this part of the design studio can remain well hidden during the development process if you are not aware of them and don’t know what to look for. Consider all of the following aspects in your webpage design work, and you should be very well prepared against any embarrassing future breakage of your site on a new or unusual device.
Valid HTML and CSS
What is it?
HTML is the markup language used to turn plain text documents into the sort of content you see on webpages, with links, paragraphs, in-line images, and so on. Like any computer programming language, there are sets of rules that define how it should be written. Breaking those rules results in behaviour that is, by definition, undefined, meaning that a browser can potentially interpret your code in absolutely any way it wants to. Web pages published on the public internet shouldn’t contain errors in their HTML. But a very large number of pages do.
CSS is a markup language used alongside HTML to describe the artistic look and feel of webpages. Whereas HTML describes documents terms of structure, such as paragraphs, headings, annotations, and so on, CSS describes colors, fonts, borders, and other such attributes. Just like HTML, CSS also has published standards, and webpages on the public internet should follow them.
Why does it matter?
Putting aside for a moment some definite technical reasons why validation does in fact matter very much, we find ourselves asking exactly why anybody who is capable of writing standards-compliant code would purposely create something that doesn’t validate? HTML that doesn’t comply with the published standards is by definition buggy, and delivering any IT project with known bugs simply isn’t professional. Even if the content renders acceptably in a selection of modern web browsers, using other browsers or an updated version of one that the buggy HTML has been tested against could break the design completely at any time. Even worse, it could break the functionality of your page in subtle and frustrating ways, leaving customers unable to login, unable to complete an ordering process, and more. Finding subtle breaks in functionality caused by non-validating HTML can be difficult. Do you really want to pay to update your site each time this kind of breakage happens? Standard compliance will likely save you time and effort in the future.
Many years ago, back when HTML was still an immature standard, there were visual effects that were difficult or even impossible to create without using unofficial tricks that broke standards compliance. For the most part these techniques just worked on the handful of browsers in common use at the time, but the world wide web was a much simpler place back then. Users’ expectations were lower, and a visually broken website wouldn’t necessarily impact their opinion of your business. These days are long gone, and this has not been the case for well over 15 years. Just about any layout and visual effect can be created with compliant HTML and CSS. You’re looking at a fully standards compliant webpage right now, just like all of the pages hosted at exoticsilicon.com.
Before the development of CSS, certain now depreciated controls existed directly within HTML to handle this artistic side of the content presentation. Use of this kind of HTML markup has been obsolete for a very long time, and they should not be seen at all on current webpages. Using them breaks responsive design and severely limits your creative possibilities. CSS was developed for a reason!
“Code that validates shows that the developer took the necessary care and attention to do the job correctly. HTML that doesn’t validate indicates developer laziness, or lack of ability.”
How does non-compliance happen?
In our experience the most common reason that developers create HTML that doesn’t validate is because they have built a website using pre-written, off the shelf modules that they do not fully understand and lack the ability to customise. This in itself should make the paying customer suspicious.
Additionally, some developers simply lack the ability to produce work of a high technical quality. Their work might look nice visually, but a developer who passes off work that doesn’t comply with published standards by covering it up with glitzy visual effects, is demonstrating a lack of discipline and aptitude.
We occasionally hear claims that validation against published standards is simply not necessary. Our response to that is this entire design studio article explaining why it is.
From a technical point of view, valid markup is the best assurance that your website will work correctly across a wide range of current and future web browsers, not only on computers, but on mobile phones and tablets, too. Responsive designs - those which adapt to different devices and screen sizes - are especially difficult to make work reliably without valid HTML and CSS.
Valid markup is the best assurance that a webpage will work for the majority of users across most devices.
The official standards process does not help
Sadly, here at Exotic Silicon, we’ve come to hold the opinion that the official HTML standard has now developed into a sprawling mess. This process started around the time when it became a ‘living document’, and turned from a series of neatly versioned published standards into a continuing development effort without any more distinct freezing and versioning. The people and organisations responsible for this process should feel absolutely ashamed at feeding the desires of those calling for more and more features to be added as quickly as possible, with insufficient thought to the long-term practicality and manageability of the implementation of the standard, as well as the effect it has had on those who actually care about writing quality code with a high degree of standards compliance and interoperability.
This stupid, lazy, and slap-dash approach towards standards development simply encourages lackluster implementation of the published standard. This is most noticeable in webpages themselves, which are almost always full of technical errors nowadays, but it’s also visible in browsers, which may or may not implement any particular feature, or may even decide to ‘partially’ implement them as they please, leaving everybody involved somewhat clueless as to what to expect.
Of course, browser non-compliance has always been a problem since the early days of HTML, but at least then it was possible to point a finger and direct valid criticism at the programmers responsible, because at that time the HTML standard was, with a few exceptions, strictly defined. Either an implementation was compliant or it wasn’t.
Strictly speaking, it is no longer technically possible to write HTML that can be 100% guaranteed to validate against ‘the standard’, as the standard itself is now a moving target. Code that correctly validates today, might not validate tomorrow. The best we can hope to achieve is to write code that validates against the standard as published at the time of writing, and then update it as required.
Thankfully, HTML itself has been somewhat mature for a number of years, and little of what has been added since about 2017 seems to be of much value. Most of the interesting development seems to have happened in CSS which, whilst it has also unfortunately been turned into a ‘living standard’, doesn’t seem to have suffered quite so much from an overload of dubious feature additions at the expense of clarity and implementability.
Nevertheless, absolutely none of the above criticism of the ridiculous HTML standards process should be considered as an excuse to write sloppy and non-compliant code yourself! Stand up for quality, and insist on material that, to the best of your knowledge, complies with the published standards.
“Even though the official HTML standards process has become a slap-dash sprawling mess, this is not an excuse to write non-compliant code!
How to check
Probably the easiest way to check a webpage for valid HTML markup is by using the on-line validation tool of the W3C, the organisation originally responsible for overseeing the creation and management of the published HTML standards.
The HTML validator can be found at this address:
[Note: External link will open in a new window]
Simply visit that page, type in the address of the page you would like to check, and click the validation button. Within a few seconds you will receive a report back telling you that the page is valid HTML, or alternatively, detailing any errors that the validator discovered.
An on-line CSS validation service is also available from the W3C, at the following address:
[Note: External link will open in a new window]
All of our own webpages should report no errors or warnings whatsoever in their HTML and CSS, and validate as HTML 5 documents.
You will likely see various errors and warnings from time to time when checking other peoples’ pages. Obviously an occasional error may be due to an oversight, or because of an update in progress - it’s not necessarily an indication of truly bad workmanship. However, the inability of a developer to fix such errors when brought to their attention, or excuses and claims that it doesn’t matter, should be considered as red warning flags for anyone planning a serious webpage design project.
Top tip!
If you ever find that one of our pages produces errors or warnings and does not validate, please let us know and it will be corrected.
Text broken at the wrong points ✘
What is it?
In HTML, paragraphs of text naturally wrap from one line to the next, with lines being broken at the end of words. Words with hyphens in them are also points at which lines can wrap, as the following example shows:
This text wraps neatly
over two lines.
This longer text wraps super-
neatly over two lines as well.
Unfortunately, real names, telephone numbers, e-mail addresses and other things often contain spaces or hyphens that are not adequate places for a line break. Correctly authored webpages have these characters specially marked up to avoid such ugly line breaks.
If this is not done, it might not be at all obvious at first as it likely won’t show up straight away in testing. Only when the browser window is resized in such a way that a line break happens to occur in an undesired place does the problem reveal itself. Competent webpage designers should be aware of the markup requirements and insert them everywhere where they are approprite, without waiting to see breakage first.
Otherwise, at some point the design element containing the text that hasn’t been correctly prepared will suddenly render differently, and lead to a display such as the following example:
Call our London office on (020) 7946-
0000. Ask to speak to Winston
Smith or Alice Jones.
Text wrapped incorrectly
Clearly this kind of formatting that breaks real names and phone numbers over two lines should be avoided, and the text should correctly flow something like this:
Call our London office on
(020) 7946-0000. Ask to speak
to Winston Smith
or Alice Jones.
Text wrapped correctly
HTML and CSS have facilities to avoid breaking words incorrectly like this, but still allow text to re-flow automatically to fill the available space. Unfortunately, many webpage designers don’t bother to use these features, or even worse implement them incorrectly. This can, in turn, affect document searching and indexing by search engines.
Why does it matter?
Being aware and pro-active in implementing these non-breaking spaces and hyphens is important, because the problem only becomes visible when the browser happens to break text at that particular point.
You might never notice this effect during testing, as it all depends on the exact size of the browser window and how the text flows. Yet when it does happen, and a user sees a real name or telephone number split over two lines, it looks very unprofessional.
Long URLs breaking page layouts ✘
What is it?
This is the evil twin of the above problem. Whereas before we were discussing the breaking of lines where they shouldn’t be broken, it’s also sadly common to see long lines completely unbroken, to the point that they extend off of the side of the screen. Website URLs are the most common culprit, but any text can potentially cause this problem. Let’s take a look:
Visit our fantastic new e-commerce website at:
and purchase the latest products in our range.
Why does it matter?
This undesired effect not only looks very ugly and unprofessional, but it can impact usability as well. When viewed on a mobile device, the whole page will often be, ‘zoomed out’, to fit the long line on the screen horizontally without scrolling. This in turn causes the rest of the page to render in a thin column on the left-hand side, usually leaving the text far too small to read.
Best way to fix it?
In the case of a long URL, it's probably best to specify potential breaking points after some of the forward slashes. In the markup, this just means adding some <wbr> tags. This allows us to control exactly where text is allowed to break when necessary, without affecting it’s display elsewhere:
On the other hand, if the content contains multiple long lines and requires them to be maintained in order to be unambiguous, (for example, console output), then it can be more effective to allow the element to scroll horizontally.
In this case, we also need to avoid the mistake of allowing the background to only cover the portion of text that is initially visible and scroll away itself when the user wants to see the rest of the content.
Visit our fantastic new e-commerce website at:
and purchase the latest products in our range.
Incorrect horizontal scrolling
Visit our fantastic new e-commerce website at:
and purchase the latest products in our range.
Correct horizontal scrolling
Just like the previous problem of text broken at the wrong point, this effect of unbroken text may also never show up naturally during testing. Neither will either mistake, in itself, cause the page to fail HTML validation tests. However a user with an unusual screen or font size can trigger it, and once again it makes your pages look ugly and badly thought out.
Mojibake ✘
What is it?
Mojibake is the term used to describe the effect of text that contains non-english characters being displaying incorrectly due to the wrong character set being selected. Some characters are replaced with others:
Primeira página
Primeira página
A lower case letter a with an acute accent is replaced by two other characters
Japanese hiragana is replaced with a long string of arbitrary characters
If your web content is all in English, this might seem like an unlikely problem. If you’ve only ever browsed web content written in English you might not even have be familiar with this issue at all. In the early days of the web it was actually much more noticeable for two reasons; the vast majority of English language operating systems completely lacked fonts and support for character encodings common in Asian countries and search engines did little or nothing to return results in a specific natural language, so searching for a technical term or a model number would often return pages written in unsupported scripts. As a result, even correctly designed webpages in languages other than English would often produce mojibake. Almost all modern operating systems now have very good international text support, so it now only really occurs due to errors in the markup or webserver mis-configurations.
Why does it matter?
A presence on the internet is global. Even if the content on your pages is written entirely in English, sooner or later you might want to quote a review or comment by a user that contains a foreign word, name, location or something else with non-English characters. This becomes even more likely if you decide to allow user submitted comments on any of your pages.Webpages that primarily display English text don’t usually suffer from this problem, as the normal unaccented latin alphabet, numbers, and punctuation are almost universal in all character sets. Often you can select the wrong one and not see any change in the display. This makes mojibake an easy issue to overlook, but a possibly difficult one to find and resolve if the problem shows up suddenly when adding new content at a later date. If the website programming uses a mix of different character sets internally, the task of fixing it can be daunting. Being aware of the the potential problems from the outset, and programming accordingly, is the best way to avoid users being confused by seeing mojibake later on.
Using raster graphics when vector graphics could be used ✘
What is it?
Most digital photographic imagery is represented by rows of pixels, so called raster images. However, graphics such as logos and icons that are made up of lines, curves, and solid blocks of color, can be represented in a very different way known as vector graphics.
If the artwork is originally supplied as a more common raster image, the process of manually converting it to a vector image can be time consuming. This leads many lazy webpage designers not to bother, instead leaving the graphics as inferior raster images.
Why does it matter?
Vector graphics have several advantages over raster images. They almost always have much smaller file sizes, making them load more quickly. Visual quality remains very high when the image is scaled to different sizes, meaning that you get nice crisp, razor-sharp edges on your company logo and smooth color gradients without ugly compression artifacts. Lastly, vector images can be animated in all sorts of interesting ways, adding subtle touches such as a metallic glint or color change to part of the graphic.
Vector graphics
363 bytes, (inline SVG)
Lossless raster graphics
978 bytes, (webp)
4505 bytes, (png)
Lossy raster graphics
723 bytes, (arithmetic jpeg)
744 bytes, (huffman coded jpeg)
The magnifying glass image above uses a mere 366 bytes to represent as vector graphics. As a raster image the file sizes are larger at 723, 744, 978 and 4504 bytes, depending on the format, (arithmetic jpeg, huffman table jpeg, lossless webp, or png), yet the quality is obviously inferior.
Vector graphics have enjoyed support in all mainstream web browsers for a very long time now. They are used to good effect on a fair number of webpages, including our own, but some developers still shun them and continue using inferior raster images in their place, losing you the benefits described above.
With more and more devices having larger, higher-resolution displays, the best possible rendering of your company logo and other non-photographics webpage elements is important to maintain an image of brand quality and professionalism.
Designing for specific browsers or devices ✘
What is it?
In extreme cases, this can mean a webpage designer writing invalid HTML that doesn't even validate against the specifications, but just 'happens to work' in their browser of choice.
Alternatively, it can mean mis-using features of CSS that allow us to design responsive pages by trying to second-guess the exact specifications of a specific subset of browsers or devices, and force a particular rendering on them. The code might, (or might not), be valid HTML and CSS, but this is still very bad practice.
The correct, most flexible, and futureproof way to use responsive design features is to design your pages in terms of generic device capabilities, such as screen size, resolution and orientation. This allows diligent developers to tailor the look and feel of a website to the complete spectrum of different devices, and optimise the user experience across a range of platforms.
Why does it matter?
In the worst cases, the page design breaks completely if the user changes any of the browser settings, such as font size, from their default values.
Even if this doesn't happen, new mobile devices are constantly entering the market. Pages designed to target a specific selection of current models can easily become obsolete within a year, requiring them to be updated or redesigned, which in turn creates an on-going administrative burden.
In contrast, pages which are designed around generic device capabilities usually have a much higher likelihood of working correctly unchanged on a browser where the user has changed the settings from their default, and on future devices that haven’t even been released yet.
Designing for specific devices is a long obsolete technique, which shows that a designer doesn't understand the fundamental concept of interoperability between systems. It has no legitimate place on the web today’s.
“A website that targets specific devices is out of date as soon as a new device launches.”
Pages that use mouse pointer hovering for essential functions ✘
What is it?
Hover over this area to change the background to blue
Click this area to change the background to red
Elements on webpages can not only be made to react to mouse clicks, but also to the fact that the user is hoving the mouse pointer over them. This can be seen in the simple demonstration above.
Most users of desktop computers will be able to do both actions using a mouse without any difficulty.
Users of touchscreens, though, which includes just about all users browsing on a mobile phone or tablet, generally don’t have any easy way to hover the mouse pointer without clicking. Exceptions exist, such as tablets operated with a stylus instead of finger gestures, but in the vast majority of cases a tap on the touchscreen is usually interpreted as a click, and may even trigger two actions - that for hovering, and that for clicking.
Users of computers without a mouse, or who can’t use a mouse due to dexterity problems, typically select items and links from a webpage using keyboard shortcuts to move the focus from one element to the next. In many cases this presents the opposite problem to that suffered by users of a touchscreen, in that elements can be focused, which is usually equivalent to hovering the mouse, but often only links or form buttons can be ‘clicked’.
Why does it matter?
Some users can’t hover, and other users can’t click on anything other than a link or a form button.
A website may be completely unusable for these users if it is programmed to do different things to the same element when it is clicked or hovered over, or if non-link elements need to be clicked.
Common culprits include drop-down menus, as well as buttons and links that have been badly implemented with Javascript.
Beyond this, many power-users simply prefer to ditch the mouse and navigate the web exclusively from the keyboard for speed.
“Not everybody using a desktop computer wants to rely on using a mouse.”
Page elements that can’t be focused from the keyboard or focus in an illogical order ✘
What is it?
Closely related to the previous issue, this is the problem that arises when webpage elements that have some kind of action associated with them either cannot be focused at all from the keyboard on desktop browsers, or when ‘tabbing’ from one element to the next results in the currently chosen active element jumping all over the page instead of progressing in a logical order such as from top to bottom, or left to right.
What causes it?
The first situation arises when the developer just didn’t bother to set the tabindex attribute on an element such as a div which is not automatically focusable. It’s perfectly operable using a mouse or other pointing device, but there is no way to reach it purely using keyboard controls.
In the second case, it’s usually that the visual positioning of the page elements in the HTML has been changed using CSS, making the order they appear on-screen different to that which they appear in the page source code. Moving the focus from one element to the next with keyboard controls will by default follow the order that the elements appear in the source, unless they have a tabindex attribute to change this behaviour. It can also happen if the tabindex attribute has been set incorrectly.
Both problems are trivial to fix. The difficulty is noticing that they exist in the first place.
Why does it matter?
Filling in a web form with a lot of fields is usually much quicker using the keyboard to move from one to the next - unless bad webpage design makes this a tedious experience.
Pages that are unusable with Javascript disabled ✘
What is it?
Javascript can be used to enhance functionality and add basic interactivity to webpages, but creating pages that are unusable or have broken basic functionality without it is extremely bad design practice.
This website requires Javascript.
To many users, it might as well say:
Just hit your back button and never return.
Why does it matter?
Since javascript is a major vector for web-based malware, as well as other irritations such as pop-ups, many knowledgeable users and especially power users simply prefer to browse un-known and un-trusted websites with javascript turned off entirely. For these users, when your website loads with a blank screen, throbber graphic that never disappears, or broken navigation because it requires javascript, they just hit their back button. You probably don’t even know that they visited your site, or were intending to, because in your webserver logs the single entry they made probably just looks like a webcrawler. It wasn’t, it was a potential visitor that you lost. They went elsewhere and found the content they were looking for on somebody else’s website, and never came back.
Given that all modern mainstream browsers include Javascript functionality, some webpage designers take a lazy and unprofessional approach, creating pages that do not provide any fallback and become unusable when it’s disabled. Even worse is when they treat the user as if they are completely ignorant, redirecting them to a silly generic website with instructions on how to enable this technology. It’s almost certain nowadays that a user browsing with javascript disabled is doing it out of choice, and not by accident. Trying to bully them into opening their browser up to more malware is not likely to be productive, and can present a very arrogant image of your company being uncaring or unsympathetic to their freedom of choice.
If you think that this represents a minority of users, just the knowledgeable IT types who might not be your target audience anyway, be aware that avoiding malware is not the only reason that some users deliberately disable Javascript entirely. Reasons can include increased browsing speed, lower bandwidth utilization, avoiding tedious pop-up adverts and avoiding browser profiling to name just a few.
Even today, some users may be using a browser that does not even support Javascript. The text mode browser Lynx is the most common example, but some browsers designed for use with assistive technologies may either lack support, or more commonly have difficulty parsing the particular use of Javascript on your pages.
Drop-down menus implemented in Javascript, which require a mouse-pointer hover to ‘open’, followed by a ‘click’ on the chosen item are a classic design failure that can make whole websites un-usable on mobile devices or on a computer without a mouse when they provide no other method of site navigation.
In many cases, a site that requires javascript is an irritation, and represents a severe failure in terms of user experience.
How to fix it?
Look at all of the amazing things we’ve done here on exoticsilicon.com. Not one of the website features relies on javascript to make it work. You can browse the entire exoticsilicon.com website with javascript disabled, and not miss out on anything.
Designs using drop-down menus can now be implemented in pure CSS, avoiding the need for javascript in this use case.
Pages that break completely when cookies are disabled ✘
What is it?
Pages that remain blank and continuously re-load themselves in a loop when they can’t set a cookie on the user’s browser.
Why does it matter?
Even if a particular function of your website genuinely requires the use of cookies to be practical, such as an on-line shopping cart, take the time to handle cookie-less browsers gracefully. A message advising that the site requires cookies for correct operation looks much more professional than a browser caught in a continuous loop of page re-loading.
Requiring the user to allow cookies just to read static content on your site also makes little sense.
Excessive backwards compatibility ✘
What is it?
Webpages that use excessive amounts of non-standard markup, or large third-party Javascript libraries, (so called, 'polyfills'), to make themselves function on older web browsers.
Note that we're talking here about the extreme cases. It's fine to avoid CSS features that only gained good browser support 'last year', because not everybody upgrades their software in a timely manner. But bending over backwards to support Internet Explorer 6 in 2022? That's just counter-productive, if not downright harmful.
Why does it matter?
“Facilitating the on-going use of ancient browsers just to get easy website traffic is obnoxious and selfish. Do your customers a favour and ditch the third-party polyfills!
Going to great lengths to make your content work on old browsers simply encourages a culture of laziness and complatentcy in keeping the client software up to date. Unlike years ago, these days very few users are genuinely in a situation where they cannot easily upgrade the browser they are using. By making it easy to avoid doing this, you are providing a dis-service and leaving them open to many more security vulerabilities.
Making your site work on ancient browsers with the use of third-party 'polyfills' isn't professional. In fact, it's just selfish, because you are prioritising your own interests, (easy website traffic), over the user's interests, (security and reliability). Who wants to deal with a business like that?
Besides the moral argument, there are plenty of technical reasons to embrace the latest standards too:
Avoid the temptation!
What's the better alternative?
The correct solution is to design pages that use HTML and CSS in a way that degrades appropriately on less capable browsers, rather than trying to force all of your design features to work everywhere. In this way, your site can deliver a more appropriate experience for users who happen to access it with an older browser whilst not impeding the full functionality for those accessing it with a more capable system.
A message such as, 'Your browser lacks full support for some of our website features. Upgrade for the best experience!', gently encourages users to upgrade their software at a convenient moment.
Using generic and bloated third party libraries to ensure that any ‘missing’ features in older browsers don’t break your site, harms the browsing experience to some degree for all of your visitors. Instead, take the time to choose carefully the features you use for essential functionality from those with the best native browser support, and use similar alternative fallbacks to allow the pages to render sensibly on older hardware.
As a bonus, designing your pages without excessive backwards compatibilty is usually quicker and easier. Perhaps that's why many designers who are paid by the hour will encourage you otherwise!
“Programming webpages that degrade gracefully on less capable browsers is the best way to deliver a good user experience to the widest audience.”
Mobile redirects breaking URLs ✘
What is it?
Some websites are implemented with a separate ‘em-dot’ site for mobile users, and configure the main website to automatically redirect accesses from a mobile browser to the dedicated mobile site:
Not recommended, but common in legacy websites
Unfortunately, this often causes problems when somebody passes a link from the desktop site to another user who is browsing from a mobile device:
✘ The user doesn’t see the intended page
Of course, the opposite problem can also occur, when a user passes a bookmark from the mobile site to somebody browsing with a desktop web browser.
Why does it matter?
We generally discourage the practice of separate ‘em-dot’ sites altogether. When the first mobile devices with real web browsers appeared on the market, there wasn’t really much choice but to implement a mobile site in this way. It even seemed logical, as WAP sites had enjoyed a brief period of popularilty, and they were implemented in WML rather than HTML, so the mobile site really was different. Sites developed in C-HTML and delivered using i-mode also effectively required a completely separate design.
This is no longer the case. All modern smartphones are designed to access regular webpages now, and creating a new ‘em-dot’ site basically makes no sense whatsoever. Decommissioning any existing separate ‘em-dot’ sites in favour of a single responsive layout neatly avoids this problem of passing links from one to the other altogether.
If you still run an existing legacy ‘em-dot’ site alongside your regular website, it’s very important to ensure that users are either redirected to equivalent content on the mobile site, or simply given the option to visit the desktop site on their mobile device. If your desktop site is well designed and standards compliant, adding responsive design features to optimise it for mobile devices should be a straightforward and uncomplicated task.
“Avoid creating separate ‘em-dot’ sites unless you have content which is highly specific to mobile users.”
Excessive input validation ✘
What is it?
Rejecting valid input as invalid, or requiring fields to be filled in when they shouldn’t need to be:
Phone number
!Phone number must contain only digits
Rejecting a valid international phone number
Order number
!Order number is required
Requiring information that a user doesn’t have
Why does it matter?
Validating user input is very important when the information is to be processed automatically. It can also help to ensure that users include all necessary information when completing contact forms and other actions that are to be processed manually.
However, it is good practice to consider cases where the user is genuinely missing certain information, but their request could still be processed without it.
In addition, care should be taken to ensure that any validation of user input doesn’t erroneously detect correct data as invalid, and prevent the submission.
What's the better alternative?
Phone number!
!Non-US numbers will not receive automatic tracking updates
Advising the user but allowing submission
Phone number!
!This telephone number appears to be invalid
Advising the user but allowing submission
In the first example above, the user has entered an international phone number complete with the country code, indicated by a leading plus sign. This may be rejected by validation code that expects phone numbers to only contain digits.
Better ways to handle this situation are shown here. The system advises the user that the number doesn’t appear to be as expected, but allows them to continue.
Order number
I don’t have an order number
Confirming missing information
In the second example, the user may be trying to make a pre-sales enquiry and therefore not yet have an order number, or alternatively may have placed an order but never received the confirmation message with their order number due to a system error. If the form cannot be submitted without this field filled in, the user is forced to insert a dummy number, or else find an alternative way to contact you.By including a checkbox for the user to indicate that they really don’t have an order number, we can avoid incomplete forms being submitted unnecessarily whilst at the same time ensuring that users are not prevented from making contact.
Top tip!
Testing on real devices ✓
It’s worth noting that to be sure of the quality and usability of a website on a mobile device, there is no substitute for testing on the device itself.
Re-sizing a desktop browser window to match the resolution or dimensions of a typical handset is convenient, but relying exclusively on this during the development process can hide a lot of usability issues that become immediately obvious as soon as you try to interact with the site using a touch screen instead of a mouse.
Elements that are placed closely together with limited space between them are probably the most obvious problem that can slip through the development phase when testing is not performed on real devices. Drop-down menus are another item that can cause unexpected usability problems. If they open directly underneath the user’s finger, it’s easy for the user to inadvertently select an option they didn’t intend to.
Having to be extra careful exactly where your finger lands to avoid clicking a neighbouring link is quite tedious!
Testing a mobile site on a real handset can hilight problems that might otherwise remain un-noticed.
Broken phone number links and silly non-standard number formats ✘
What is it and why does it matter?
Some webbrowsers on mobile devices will interpret any sequence of numbers on a page as a potential telephone number. If the user long-taps on the number, they might be given an option to dial it, or simply be taken directly to their phone dialer screen with the number already filled in. The exact behaviour depends on the specific device.
If you present your telephone numbers in invalid and non-standard formats on your pages, which is bad practice anyway, users can easily inadvertently end up dialing an incorrect number. Worse still, if they don’t pay attention to the number that the browser has picked up on and filled in automatically, they may then just assume that your line is out of service and move straight on to one of your competitors!
When does it happen?
Browsers with this feature are usually intelligent enough to ignore dashes separating groups of digits, and brackets indicating an area code. However, a common but incorrect and very bad practice is to mix both local and international dialing codes in the same number. The resulting string of digits is neither a valid national or international number, it’s simply wrong, and the browser will typically pass a truncated number to the dialer.
Telephone numbers in the North American dialing plan don’t usually cause confusion, as the leading 1 indicating a trunk call is identical to the international +1 prefix.
However, consider the international format UK phone number +44 1632 234567. This would be dialed nationally as 01632 234567, where 0 is simply a prefix to indicate trunk dialing, 1632 is the area code, and 234567 is the local number. The representation +44 (0) 1632-234567 is occasionally seen, but this is not a valid format for a UK phone number and a web browser trying to auto-detect phone numbers in a page may well end up passing just 1632234567 to the dialer, truncating the leading 0, which will result in a failed call.
Correct automatic parsing of arbitrary numbers in webpages cannot be guaranteed in any case, especially as the behaviour of this functionality is browser dependent. However, using a non-standard format to display your phone number is almost certainly going to make things worse rather than better, not to mention that it just looks wrong and un-professional anyway.
Users might not be paying close enough attention to notice if any automatically parsed strings of digits they are about to dial actually match what is displayed on your website.
How to fix it?
Always use a standard format and commonly accepted representation of your telephone number, preferably the full correct international dialing format including country code.
Of course, you can create explicit telephone number links with the tel: link scheme, but support for this is browser specific and in any case many of the same considerations apply.
Simply using the full international number everywhere on-line is probably the safest bet.
“The web is an international medium. Display your telephone numbers accordingly, including the country dialing code.”
Textual content that doesn’t match the visual layout ✘
What is it?
Quite simply, it’s when the text of your webpage doesn’t correspond to what users are seeing. For example, “the image on the right”, when it’s actually underneath.
When does it happen?
Commonly when an existing website is converted to a responsive design, and the stylesheets for small displays place all of the elements vertically. Written references contained within the body text are overlooked and not changed.
How to fix it?
Proof-read your pages from time to time! This will not only catch these sorts of errors, but other mistakes, broken links and outdated information too.
The obvious simple fix for this specific problem is to change references that mention, for example, “the image to the right”, to a more generic phrase such as, “the following image”. However, a more sophisticated approach is possible using the CSS :before selector together with a content specification. This allows you to conditionally insert text into your document based on CSS media queries, so you can make sure that the description in the text matches the actual layout.
The above example displays the color gradient to the right of the text on larger displays, but moves it below the text on smaller, narrower displays. The text changes accordingly, and we didn’t need to use javascript for this, either.
Top tip!
Text mode web browsing ✓
The vast majority of modern webpages are completely unusable in text-only browsers. Given that graphical browsers have pretty much been the standard for more than twenty years now, this might not seem like an issue even worth considering - it's entirely possible that nobody will ever visit your page with a text-mode browser.
However, if you follow all of our guidelines for good webpage design and ensure that you create pages with standards compliant HTML and CSS, the chances are high that they will simply work acceptably well in text mode browsers with no further effort required. So this effectively comes for free.
Ensuring that your pages render correctly and are navigable in non-graphical webbrowsers that only display text, a small subset of the IT industry will be impressed by your diligence in creating a truly interoperable and accessible website.
Our pages render just fine in plain text. Yours can too!
Lazy loading of images ✘
What is it?
Replacing the images on your pages with low-resolution placeholders, and having the full resolution images loaded after the page has been rendered.
Why is it a bad idea?
For several reasons. Firstly, it almost always breaks when javascript is disabled in the browser. This leaves the user looking at a collection of blurry blobs of color instead of the images, which is often more visually distracting than simply having the images missing altogether. Secondly, it doesn’t always improve page loading speed, in fact on a fast connection where the images would have come in quickly anyway, it can actually slow down the final rendering. Thirdly, a broadly similar effect can be achieved by using progressive jpeg images and ensuring that the dimensions are correctly specified in the corresponding stylesheet.
So overall, you basically lose on all fronts and gain nothing. Yikes!
Overuse of web fonts ✘
What is it?
Support for downloadable fonts in modern web browsers has given us the ability to freely use arbitrary fonts on webpages, downloading them just like any other resource and without the need to install them in the host operating system.
Why does it matter?
For many reasons!
Although the limitless use of different typography is potentially great for creativity, there are reasons to limit the use of web fonts and in some cases prefer use of the built-in system fonts.
In rare cases, web fonts from third party providers can actually completely break your site.
In general, and independent of the technology, using a massive array of different fonts in the same document has long been considered bad typesetting practice anyway. Unless you have a very specific effect that you want to create by doing so, it almost always looks awful.
However, web fonts bring their own specific technical problems, and these issues can show up even if you only use a single non-operating system native web font on a page.
Firstly, the browser cannot even begin rendering the final layout until the font has loaded. Either rendering is completely blocked, usually leaving the user staring at a white screen, or the text is first rendered in a system font and then changed to the downloaded font once it is available. This is visible as the text ‘snapping’ into place, unless the page uses some javascript to block the visual effect and replace it with something even more irritating, such as a throbber, a technique which has problems of it’s own.
So you can’t get away from the fact that web fonts add a lag to your page loading time. This might be acceptable if they noticeably improve the content, but it can’t be avoided, unless the particular font already happens to be in the browser cache from a previous request.
To make things worse, although web fonts can be created yourself and hosted on your own webserver just like any other content, a lazy option exists which many or even most webpage designers usually take, which is to use a third party font hosting service. So now you have to fetch render-blocking content from a separate domain. That’s not at all good for performance, but it also carries a greater risk.
We once informed an ISP of a problem with their support pages and customer service portal. Suddenly, when accessed with a certain combination of web browser and operating system that had previously worked fine, the browser crashed almost immediately on page loading. This had never happened before. The ISP denied having made any changes to the code running the support portal. Although the bug was ultimately a browser issue, the problem disappeared as soon as the link to a third party font server was removed. Clearly, changes had been made to the code served by the third party which had triggered the browser bug. The problem is, though, that these support pages were the main way for customers to get in touch, so total breakage here made it somewhat difficult for any affected customers to even report the problem. The key point to take home from this is that including any content on your pages which needs to be fetched from a server which is not under your control, is a risk. You simply don’t know when buggy third party content could make your pages inaccessible, and in the case of a support and service portal that’s obviously a very serious problem. If you want to use web fonts, hosting them on your own server is a much better approach.
Lastly, because it’s easy to get a different ‘look’ just by reaching for another web font, the mere availability of web font technology seems to have created a lot of laziness in terms of actual design. There is so much you can do with just a single system font using CSS alone. Add SVG to the mix, and you can do even more.
The Exotic Silicon website doesn’t use any web fonts at all. All of the text effects that you see here on our pages are rendered using the fonts on the host operating system, (except for our logo, which is created in pure SVG as a vector image and is not text in the normal sense anyway).
“Limit the use of web fonts, and get creative in other ways.”
Banner adverts, tracking cookies and captchas ✘
Pure evil!
Just remove them and make your users happier. We have nothing more to say here.
Design studio summary so far
We see the mistakes presented above repeated time and time again on public web pages published by businesses large and small.
In this section of the design studio, we’ve demonstrated just some of the less obvious pitfalls that need to be avoided to deliver a truly credible and professional website, but there are still plenty more.
Choosing your developers wisely, and dedicating sufficient development time to testing edge cases, will help to ensure that you are finding the unusual bugs before your customers find them.
Attention to these important technical details should be considered an essential part of the website development process, and not an optional extra.
Now let’s move on to part three where we will uncover some more common technical issues that could be lurking un-noticed server-side!
Continue learningDesign studio indexExotic Silicon main menu
“You might never see these issues during testing, but users who see them will develop a bad impression of your business and associate it with a lack of professionalism.”