There’s so much to love about the web. It’s a wonderful place, after all. But a few areas could certainly use some improvement. In this post, I enumerate ten annoying web problems I’ve encountered as a user, and suggest ways in which developers can avoid them—or at least make them less annoying. I’ve also included the solution I personally use to eliminate or alleviate the problems client-side. I use Firefox, so all the add-ons and menu items mentioned can be found there. I’m currently using version 3.0.11.
JavaScript links
The middle click is my friend. I almost always open links in a new tab. So do a lot of other users.
The problem
I get middle-click happy and later realize that the new tabs are blank windows with javascript:popup() (or something of the sort) in the address bar.
The solution
Progressive enhancement. Write the markup first, then write the stylesheets, and save the scripting for last. Make sure that the entire site (not just the links) works without JavaScript. Afterward, scripting can intercept links, but still allow them to open in a normal way (e.g., middle-clicking) if the user so desires.
For example: On my site’s recent work section, clicking on a thumbnail opens the image in a modal window, but middle-clicking on the same thumbnail opens the image in a new tab. Everybody wins. (Thanks to Slimbox 2 and JQuery!)
User solution
There isn’t any that I know of. Any suggestions?
Pop-up windows and dialog boxes
Who doesn’t hate pop-ups?
The problem
Pop-ups are made to attract attention—but they just end up annoying users. I especially dislike pop-up dialog boxes for functions such as form validation.
The solution
For forms, use server-side validation. You may also use client-side validation in conjunction, but do it unobtrusively. Don’t use dialog boxes.
User solution
To avoid pop-up ad windows, Firefox has a built-in pop-up blocker. I also use Adblock Plus. (I’ve been blocking ads for so long that I’m briefly bewildered whenever I see them on other people’s computers.) They’re awesome, but they do have their limitations. They have no power against persistent developers who really want to tell you, via dialog box, that you have a private message. Which happens to be spam. Ah well, such is life.
Multi-page posts without one-page versions
If I wanted to turn pages, I’d read a book.
The problem
To be fair, if you’ve got a very long document that no one can finish in one sitting, I suppose dividing it into parts makes sense. But if I’d like one page to bookmark and keep coming back to, or if I’d like to save it to my computer for future reference, a single page option would really help. I’m disappointed when this doesn’t exist.
Why do people create multi-page posts? Maybe because they want to increase ad coverage and revenue. Or they don’t want you to be intimidated by the length of the post. Or they’re stuck in the print media way of seeing things. (I most often see multi-page posts on news and magazine sites.)
The solution
Two pages is enough for an average post. One for the summary or an excerpt. One for the entirety of it.
For very long posts, a one-page option is always welcome.
User solution
I check the print version of the post. This works most of the time. But I’ve encountered some print versions that only display the current part, for some bizarre reason.
Undefined background color
White is too stark and bright for me, so my window background is light green wherever possible. I have green paper on MS Word, a green screen in Firefox’s no-style mode, etc.
The problem
I sometimes encounter websites that don’t define a background color and use the default, which was probably white for the developers but green for me. This also happens a lot with form input backgrounds, which require separate styling.
The Moonfruit website doesn't define a white background.
The solution
A few lines of CSS, such as:
body { background: #ffffff; }
input.text { background: #ffffff; }
/* text inputs need a class="text" in markup */
textarea { background: #ffffff; }
User solution
If I visit the site often, I solve the problem with style. A stylesheet, that is—using Stylish.
For example:
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("website.com") {
body { background: #ffffff; }
}Lucida Grande without Lucida Sans Unicode as the secondary font
Facebook and Twitter look lovely. On a Mac, that is.
The problem
Lucida Grande and Lucida Sans Unicode are (obviously) both from the Lucida family. Lucida Grande is shipped with Macs. Lucida Sans Unicode is shipped with Windows. So why do some stylesheets use anything other than LSU as a secondary font to LG?
Facebook uses Tahoma, with its awfully narrow body and tight letter spacing.
body { font-family:"lucida grande",tahoma,verdana,arial,sans-serif; }
Facebook in Tahoma: small, narrow, and compressed.
Twitter doesn’t care how it looks on your browser if you don’t have LG:
body { font:.75em 'Lucida Grande',sans-serif; }
Twitter in Tahoma
The solution
Since LG and LSU are from the same family, just make LSU the secondary font.
body { font-family: "Lucida Grande", "Lucida Sans Unicode", sans-serif; }User solution
Stylish again. This is the user style I use for Facebook:
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("facebook.com") {
body { font-family:"Lucida Sans Unicode" !important; }
}
Facebook in Lucida Sans Unicode, thanks to Stylish.
This one for Twitter:
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("twitter.com") {
body { font-family: "Lucida Sans Unicode" !important; }
.status {
/* for better readability */
font-size: 13px;
line-height: 16px !important;
}
body#profile .latest-status .entry-content {
line-height: 26px;
}
textarea#status {
/* larger textarea */
height: 120px !important;
background: #ffffff;
font-family: "Lucida Sans Unicode" !important;
}
}
Twitter in Lucida Sans Unicode. Much better!
Careless liquid layouts
Liquid layouts can be done well—but it’s harder to please more users with them than with fixed layouts.
The problem
Some liquid layouts fail to consider the type of content and the range of resolutions that will be used to view it. Long rows of thumbnails would probably look pretty on a large screen, but long rows of text can be very difficult to read.
For example, I have a 19″ widescreen monitor. I find it uncomfortable trying to read the text on this page:
Default vBulletin forums have a careless liquid layout.
And I’m sure that visitors with larger, wider screens would find it nearly impossible. The lines are simply too wide.
The solution
Using a fixed layout could solve the problem. But if you really want a liquid layout, make sure that you also define the maximum widths (in addition to minimum widths) of containers. It will save your users from having to resize the window just to read your content.
User solution
For sites I don’t often visit, I usually just resize the window. For frequented sites, I use Stylish as usual.
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("forums.digitalpoint.com") {
.page { width: 800px !important; }
}Too small font
Staring into a large rectangle of light at work is harsh enough for my eyes. Having to squint in order to read minuscule text is just wrong.
The problem
Not everyone has great vision—and even those who do don’t always have microscopic vision to read 8-, 9-, and 10px body text. Take this example:
TipidPC uses very small font.
To be fair to TipidPC, its crowd is dominated by guys who like computers. It’s been said that males can read small font more comfortably than females. But for most websites, it’s ideal for each user, male or female, young or old, to be able to read the text without unnecessary eye strain or client-side intervention.
The solution
Think of your users. For body text, try not to use a size lower than 12px. For metadata and other minor content, don’t go lower than 9px.
User solution
With Zoom Text Only turned on, I zoom in by pressing Ctrl++. (It’s technically Ctrl+= since you’re not shifting, but it’s easier to remember this way.) Thankfully, Firefox remembers zoom settings for various websites.
Unfortunately, zooming in doesn’t always work. Which leads me to the next annoying web problem.
Sites that break when zoomed
Let’s say you find this great site on the web. The design is absolutely amazing; all the elements are pixel-perfect. Except for the text, that is. It’s much too small. So you make the text larger, thinking the site will look even better. You may be wrong.
The problem
Some web designs are so fine-tuned (or you could say not fine-tuned enough) that it works only “as is”—and breaks when the text is zoomed. If the design breaks after 1 or 2 notches of zooming, I am very disappointed. I can understand if it breaks after I zoom 3 notches or more. But it’s worth remembering that if your user has to zoom 3 notches or more on your site, that’s a problem in the first place.
The solution
Leave enough allowances. Include zooming as part of your website testing routine. Best of all, don’t make the font too small to begin with.
User solution
Content is king, and if I can’t read it properly, then I banish the design that enslaves it. I usually do this by viewing the page without styling: View > Page Style > No Style. The shortcut is Alt+V, Y, N.
I also use this solution when reading the content of a site whose design I find especially tawdry. However, this doesn’t always work. Which leads me (again) to the next annoying web problem.
Unnecessary Flash
Flash is a great way to add more fun and action to a website. But some developers forget that not all websites are made for fun and action.
The problem
I enjoy Flash used for games, sleek photo galleries, and the occasional multimedia spectacle. But I don’t appreciate it when Flash is used for site elements—and even entire websites—for which a simpler implementation would be more appropriate.
An example of a site that really has to be in Flash. (They're in the rich media production business.)
It takes long to load. It doesn’t allow you to save images. It often plays sounds without your permission. A lot of the time, it doesn’t allow you to select and copy-paste text. It rarely allows you to zoom text—and unfortunately, many full Flash sites also happen to use tiny font sizes.
Tiny, tiny text. On a red background.
I should probably also say that search engines don’t index Flash content as well as regular web page content. There are solutions that deal with this. But in general, Flash has considerable problems. Flash objects rely on the user’s installed version, for one. They also take more time to edit and redesign.
I’m personally unimpressed by the following:
- full Flash sites without HTML versions
- HTML websites with Flash used for the navigation area (less bad if the links are repeated elsewhere—in the footer, for example—where right- and middle-clicking are possible)
- HTML websites with Flash elements that can’t be muted
- Flash splash pages without a skip intro option (or with a skip intro option in the Flash movie itself)
The solution
In general, I would recommend using Flash only for websites or applications for which it is really appropriate.
A splash page introduction is unnecessary for most types of websites. But if the website calls for it, then make sure the visitor has the option to skip the intro, and that this option is present before the Flash object even begins to load.
For a full Flash site, have enough concern and foresight to develop an HTML version for users who would prefer it.
User solution
Whenever I see a full Flash site that’s better off in HTML but has no HTML version*, I close the tab. The shortcut is Ctrl+W in Firefox.
*Unless I’m desperate to see the content, or I’m being asked to write the HTML version myself, test the Flash, proofread the copy, etc.
Image saving restrictions
I’ve encountered right-click prevention on text content a few times, but disabling JavaScript gets rid of the problem pretty quickly. I don’t think people use this trick anymore. The Internet is a more open place than before, for sure. But another annoyance has come along—methods that prevent users from saving images.
The problem
People want it all these days. Take photographers on Flickr, for example. They share their photos publicly, hoping to get praise, constructive criticism, recognition, comments from their friends, etc. But they just want you to look at their photos, not to save them to your computer for future inspiration (which I like to do). So they restrict access to photos by allowing Flickr to overlay a transparent gif on them. (This beautiful photo is an example.) When you right click and choose Save Image As, you get to save an image called spaceball.gif—which essentially contains nothing.
The solution
Once an image is displayed in a user’s browser, the user will be able to save it, no matter what restriction method is used. I hesitate to tell anyone not to use restriction methods, since they can deter image saving by casual users. But please remember that instead of forbidding image saving, all any method can do is forbid image saving by users who don’t know any better.
Meanwhile, photographers who strongly don’t want users to save their images locally should simply take all their photos off the Internet, print them, create real-life photo albums, and show these albums to whom they choose. Only in this way can they make sure viewers won’t be taking the photos home.
User solution
Take a screenshot. One way to do this is by using the Print Screen key, which copies a screenshot of the current screen onto the clipboard. Copy-paste it to your favorite image editor, extract the image, and save.
A better way to do this is by using Abduction.
For the Flickr example, you could opt to save the actual image that’s displayed, which would be of higher quality than a screenshot. But since Save Image As isn’t working, you’ll have to delve into the code using View > Page Source.
Search for .jpg and you will easily find the file. The path and file name should look similar to this:
http://farm3.static.flickr.com/2429/3678658167_bd05c8de2c.jpg
But since you’re taking all this time just to save an image, you might as well save a higher resolution copy (if you’d like). All you have to do is append _b to the file name (before the extension), like so:
http://farm3.static.flickr.com/2429/3678658167_bd05c8de2c_b.jpg
A photographer who knows what he’s doing wouldn’t upload a high-resolution photo in the first place, and the latter suggestion won’t work. Either way, copy-paste the file name on the address bar and save the image to your computer. And keep it there. Don’t redistribute it (especially not commercially!) without permission.
In summary
The annoying web problems I’ve encountered as a user are:
- JavaScript links
- Pop-up windows and dialog boxes
- Multi-page posts without one-page versions
- Undefined background color
- Lucida Grande without Lucida Sans Unicode as the secondary font
- Careless liquid layouts
- Too small font
- Sites that break when zoomed
- Unnecessary Flash
- Image saving restrictions
Generally, developers can avoid or alleviate these problems by caring more about their users and everything that comes with them—browser specifications, software, default appearance settings, eyesight, age, patience level, goals for visiting, etc. But caring about users isn’t enough. They should also write great code and do adequate testing to make sure everything goes well.
Meanwhile, users can make up for developers’ shortcomings by actively solving the problems client-side. A good way this can be done is by using Firefox and the awesome add-ons that I’ve mentioned, and generally knowing the right techniques that will help them acquire what they’re looking for on the web.
