Browsers:

Bug: Stopped Stop button

 

Reported by: Gijs van Soest

 

Duration: Serious since the invention of plug-ins, java scripts and various other client side auxiliary apps, ca. 1996 I'd say.

 

Supplier: browser builders

 

Alias: Can't stop running

 

Product: all browsers that I know of

 

Bug: Stop button only applies to loading of page, not to child processes.

 

Class of Error: “It’s not my job.”

 

    Principle: New capabilities need to be fully integrated into the overall design

 

Proposed Fix: The stop button of a browser should also control child processes started by the browser app, such as plugins, scripts, time-consuming database lookups, etc. Possibly, the functionality of the stop button could be extended with features like "run in background", "continue process in new tab" (cf. Mozilla's browsers).

 

Discussion: Currently, the STOP button of a browser can only stop loading a page. The STOP button serves the user by providing the possibility to terminate any actions resulting from mistakes, or actions that take to much time for the user's patience or purpose. Unless you have a very slow connection and the author included tons of graphics, loading the page itself is seldom the most time-consuming process when visiting a web site. Loading a plugin, however, can take ages, and it may even provide extra service by automatically downloading FREE DEMO UPGRADES and the like. Likewise, scripts are prone to bugs and often stall. Terminating these processes requires a lot of technical knowledge and the consultation of dreaded task managers to locate the culprit between tons of other vital processes with equally cryptic names.

 

However, the user did not start the process, the browser did. It is the browser's responsibility that a stalling child process can be addressed in an orderly manner to terminate it, or e.g. to continue it in the background so the user can go on with his business and check back later.

 

Bug first observed: late 90s

 

Bug reported to Supplier: OK, mea culpa, not.

 

Bug on list since:: Jan 2005

 

Bug:  State & Country pop-ups

 

Reported by:  ee

 

Duration: [in years]

 

Supplier: Every website I have made purchases from in the past several years.

 

Alias: 

 

Product: 

 

Bug: When typing in an address in a browser window one tabs between fields.  This works well until one gets to the "state" field, where the user is forced to click on the pop-up and scroll down the list.

 

Class of Error: Horrible Human Interface

 

Principle: user-impediments ˆ <$

 

Proposed Fix: In the not very distant past, one was allowed to tab into the "state" or “country” pop-up fields and type the designator for the state or country, whereupon the pop-up would actually change to reflect the correct entry.  No mouse clicking was required, so the users did not need to remove a hand from the keyboard, click on the pop-up, then scroll down the list, then move their hand back to the keyboard to type in the zip.

 

Discussion:   I don't know why this changed to make the user experience difficult.  Was the best user experience patented and the fees were too high?

 

Discussion by Tog: Two reasons for this:  First, the feature never “came free.”  The browser toolkits are, in many respects, more primitive than what we had in BASIC back in the 1960s and 1970s.  Had the Mac been released with a toolkit as weak as these, it would have ended up an interesting footnote in history.

Second, because the web has become the universal means of shopping, as the “bricks and mortar” stores have so quickly dropped away, website developers have realized that they need not go through the extra hour of programming, just to save each user perhaps 20 seconds.

Oh, I’m sorry.  The bricks-and-mortar stores are doing just fine?  The predicted revolution never took place?  Perhaps it’s because website developers think they can get away with torturing their users.  Perhaps people are fed up with half-fast interfaces that throw impediments in their path.

 

Bug on list since:: Jan 2005

 

Bug: URL Naming Bug 2

 

Reported by: Earl A. Killian

 

Duration: >10 years

 

Supplier: Browser Builders

 

Alias: Forward/backward naming

 

Product: All Existing Browsers

 

Bug: URLs are needlessly inconsistent and cryptic (not to mention hard to pronounce). They contain both right-to-left (paths) and left-to-right naming (hosts).

 

Class of Error: Concatenate two incompatible standards and expose implementation details to the user

 

Bug:

 

A typical URL looks like

 

http://www.example.com/foo/bar.html

 

but sometimes

 

http://support.example.com/foo/bar.html

 

etc.

 

Note that part of the URL is a hostname, which has the top of the naming hierarchy on the right, and part is a path, which has the top of the naming hierarchy on the left. The distinction between the host and the path is really of no interest to the user. Second, the need for the “www” is a failure to implement a decent DNS directory (e.g. the SRV RRs); it is typically (but not always) redundant with the http:// portion of the URL. Similarly the .html is typically redundant, or a convenience to the website instead of the user (websites don’t typically have more than one of .html, .txt, .php, etc. extensions for a page).

 

Proposed Fix:

 

The above URL could be represented instead as http/com/example/foo/bar which is less typing and simpler.

 

The browser would contact DNS for the COM domain asking for the HTTP server for EXAMPLE and get back a pointer to the EXAMPLE domain DNS server. Next it would contact the DNS server for the EXAMPLE domain and ask for HTTP server for FOO. Now it would get an IP address for www.example.com and the port number to connect to. It would connect and pass the whole URL to the HTTP daemon. The HTTP daemon would Þgure out whether the Þlename is supposed to be “.html” or “.php” etc. The user would never need to know that “support” is sometimes part of the hostname and sometimes part of the pathname; software would figure that out for her using DNS (e.g. SRV records).

 

Bug Þrst observed: 1991

 

Bug on list since:: Jan 2005

 

Bug: Rollovers

 

Reported by: Darrin Cardani

 

Duration: ~5-8 years

 

Supplier: Web designers

 

Alias: It's more important to look cool to other designers than to make things work for users!

 

Product: Any web page that uses rollover-style buttons, Netscape Navigator, Microsoft Office.

 

Bug: You can't tell an object is a clickable button unless you move the cursor over it.

 

Class of Error: It looks cool, so it must be better!

 

Principle: When an object on a web page or in an application can be clicked it should give the user some sort of indication that it can be, such as the border around a button does or the coloring and underlining of a link does.

 

Proposed Fix: Pass legislation to lock up designers who make unusable crap? OK, we can probably just train them not to do it.

 

Discussion: I first started seeing this bug it Netscape's browser UI. Once they did it, web designers started thinking it was good design and repeated it. (Since when are computer programmers any good at design? I'm one of them so I know most are not!) I don't know if Microsoft started doing it in Office before or after that, but it does it, too.

 

Bug first observed: Sometime around 1996-2000.

 

Bug reported to Supplier: Never - I no longer use Office, IE, or Netscape. They can keep their crummy designs for all I care.

 

Bug on list since:: Jan 2005

 

Websites:

 

Bug Name: Browser specfic web pages

 

Reported by: Joe Corda

 

Duration: since 1995

 

Bug: I hate sites that require me to use IE when I’m on a Linux or Firefox system.

 

Discussion by Tog:  Joe said it all.  No matter how clever you think you’ve been in kowtowing to the Microsoft monopoly, you are now beginning to lose real money.  The US Dept. of Homeland Security, in the Summer of ’04, recommended people stop using IE because of the rampant security flaws.  Those who have now switched to a tabbed browser are not going back. That particular monopoly is no more.

 

There are several million Mac users out there, too, and the color of our money is pretty good, too. 

 

When, at WebMD, we first put up our website, upper management absolutely, positively refused to put any engineering resources into even testing whether the site worked on a Mac. A couple of us, of course, elected to do a little skunk-works test, and indeed the site failed, right as it came into the home page.  We changed one line of JavaScript to fix that, just so we could see what else was wrong.  Nothing else was wrong anywhere on the entire rest of the site.  Management was prepare to exclude millions of potential users to save perhaps two hours of engineering time.  They looked pretty foolish in hindsight.

 

How are you looking?

 

Bug on list since:: Jan 2005

 

Bug Name: Hit the Tab key, stupid!

 

Related to: The “let’s you save me some work” bug

 

Reported by:  Robin Harris

 

Duration: Since 1994

 

Supplier:  too many to list

 

Alias: You tell me when you’ve entered all the numbers

 

Product:  web site credit card entry fields, phone number fields, SSN fields, some software serial number entry fields, etc.

 

Bug: Entering a standard number, like an area code & phone number, into a series of fields, when the appropriate number of digits are entered, the application does not tab to the next field, so if the users don’t, their original entry gets overtyped and they get to start over.

 

Class of Error: Pure laziness

 

Principle: It is your job as designer or programmer to reduce the work of the user, not make their life more difficult so you can save some work.

 

Proposed Fix: after the appropriate number of digits has been entered, tab over to the next field.

 

Discussion: What is so &#@$% hard about this? Area codes are three digits. Once three digits are entered, just tab over the next field and get on with life. Same with every other standardized number we deal with. Properly done this solves the chunking requirement to really help users.

 

Discussion by Tog: I’m not in favor of multiple-boxes for a single entry, such as a phone number.  I’d rather users be able to type it in in their normal fashion, using spaces or hyphens, with the web page parsing it appropriately.  However, if you must chunk it up because you don’t know how to parse, at least do it properly, as Robin suggests. I’ve abandoned web purchases when hitting a crude checkout form like this.  How many sales can your company afford to lose?

 

Bug first observed:  This one dates back to before GUIs — even command lines would do this.

 

Bug reported to Supplier:  OK, I never reported it. But enough sites get it right that it should be obvious.

 

Bug on list since:: Jan 2005 

 

Bug Name: Internationalizing Time

 

Duration: >10 Years, since web became popular

 

Product: Many, many websites.

 

Bug: What is 10:00PT?

 

Class of Error: Everybody is from US

 

Principle: Don’t assume everybody is from US or UK or your home country.

 

Proposed Fix: Write time in a standardized GMT format along with your local PT, ET or whatever time.

 

Discussion: I am not sure how many times I have to say WTH?, whenever websites mention time in the form of PT, ET and other format, what is the rationale for assuming that all the people coming to your website are from a specific country? Even google and Microsoft are culprits.

 

Reported by: Imanpreet Singh Arora

 

Bug on list since:: Jan 2005 

 

Bug Name: Senseless Search

 

Reported by: Denis McKeon

 

Duration: 5-10 years

 

Supplier: Far too many web sites

 

Alias: Go fish again

 

Product: many “bolt-on” site search tools

 

Bug: Simplistic search functions return no results at all, and often require re-entry of search terms.

 

Class of Error: “go away kid, yah bother me”

 

Principle: Visitor/user effort should return some potentially useful result, and user effort should be preserved by web site designer.

 

Proposed Fix (Denis): Search functions should return whatever was asked for, but if *no* material matches the initial search, user should be provided with some “nearby” content, perhaps with a an “edit search?” or “see Ônearby’ results?” choice.

 

Proposed Fix (Tog): Use Google.  If you don’t use Google, emulate Google’s rules, such as assumed-AND, minus for exclude, quotes for string search, etc.  Your users believe that was the way God intended, and your search system will fail otherwise.

 

Discussion: Almost all reasonably designed web sites with significant content offer some search function - indeed, absence of a both a search tool and a site map almost suggests that a site is trying to hide their content.

 

But, far too many sites offer a search tool that lets a user make very specific searches - “find any page on the site with the words widget and wadget last changed in June of 2003”, but fail to reward the user entering search terms with any result.

 

The user enters or selects the search parameters, clicks on a “Search” button, and a metaphorical loud buzzer rings, during the display of a screen stating: “No results found for search.”

 

In the worst case, the user then has to go back to the search screen, and start fresh with empty selection boxes - enters a slightly different search, and gets no results again.

 

After two or three iterations, the user leaves in disgust, and the site’s precious pages remain inviolate by the prying eyes of the visiting stranger.

 

Why not design a search function that offers “nearby” results - pages containing widget OR wadget, perhaps in all of 2003?

 

And why not offer a “search again” form on the results page, with the search boxes already populated with the terms from the first search?

 

Google gets this right, preserving search terms and offering spelling corrections as a form of “nearby” match, but a remarkable number of sites get it quite wrong - no results, no “search again”, and the user’s search terms are blown away like dead leaves.

 

Discussion by Tog:  In case anyone hasn’t notices, Google has pretty much solved the search problem.  It’s not perfect, but it’s about 10 times better than what came before.  Use it.

 

I must make special mention of Apple.  In 1991, they developed a search mechanism that, at the time, sucked.  They’ve finally replaced it with a real search engine on their website, but OS-X’s help system still uses it, making the help system all but worthless.  When I need help on the Mac, I use Google on the web.  It’s faster than the built-in help and you have a much better chance of finding something.

 

Honorable mention also goes to the many, many manufacturer sites that, instead of returning a link to the product page or pages, dumps out 27 PR releases, dating back to 1893, with no link at all to the product itself!  Totally brain dead!  This was understandable, if not forgivable, in 1995.  In 2005, it just makes them look like fools.

 

Bug on list since:: Jan 2005 12/05

 

Bug Name:  Links in Disguise

 

Reported by:  Connor

 

Duration:  >10 years

 

Supplier:  Many web designers

 

Alias:  ”Finger Hunting” or “Link Hide-and-Seek”

 

Product:  Graphical Web Pages

 

Bug:  No visual indication of what can be clicked

 

Class of Error:  Design over usability

 

Principle:  Usability comes before impressing the design community

 

Proposed Fix: Let the browser do its job.

 

Discussion:  When bandwidth was relatively limited, navigating web pages was pretty simple—hyperlinks showed up in Blue Underlines. But more recently, web designers have decided to make it more difficult for us—sometimes going out of their way (either with images or CSS) to create links that don’t look like ordinary text.

 

Countless commercial web sites use images for their links instead of text. There’s nothing especially wrong with that by itself, except that those images are indistinguishable from all of the other images on the site. The result is that users end up having to move the mouse over practically the entire page looking for the pointing finger to see what can be clicked and what can’t.

 

And sometimes they do it just to be mean. Go to amazon.com. At the top of the page are a series of images—“View Cart”, “Wish List”, “Help”, and so on. There’s nothing in these images except black text on a white background. In fact, the only reason for using images instead of text is to make the links not look like links.

 

It gets worse. Every now and then, I come across sites that actually uses CSS to remove the underlines from all of their links. Web browsers are designed to make links look different from regular text, but web designers continue to insist on subverting this feature.

 

Discussion by Tog: My user-observations have shown that normal users do not “scrub” screens looking for hidden links. In fact, I’ve only found two classes of people who do:  web designers and programmers.

 

If you have a pure puff site like Coca Cola, make it as arty as you want.  If they can’t use it, they’re still going to buy the product. If, however, your company expects your site to actually close sales, you might want to make the site actually usable.

 

Bug reported to suppliers:  To countless websites...

 

Bug on list since:: Jan 2005  

 

Both:

 

Bug Name: My way or the highway

 

Reported by: E. Elliot

 

Duration: >10 years

 

Supplier: web designers everywhere

 

Alias: Ach! Meine Augen!

 

Product: too many websites to count

 

Bug: web pages override user’s viewing preferences

 

Class of Error: Works for me, it must work for you

 

Principle: Users set viewing preferences for good reason; these should be honored.

 

Proposed Fixes:

OSs (Tog): Supply information on screen density, etc., to the browser so it can make reasonable choices.

All Browsers (E. Elliot):

Offer better view preference settings (maximum brightness, minimum contrast ratios, font selection, min/max font sizes) that are strictly enforced in web browsers.

Disallow absolute font size settings in html and css.

Ship browsers with better default view settings.

Smack web designers with a clue bat.

Browsers for Macintosh & other non-Windows OSs (Tog):  Make browsers display “in the standard way,” i. e., the Windows way, so website developers don’t have to build conditional style sheets for each system

Website Developers (Tog): Don’t remove control of preferences from users. It’s not only a bad idea, it’s against the law if you make your site unreadable by the differently-abled.

 

Discussion: The plethora of different operating systems, monitors, screen resolutions, and browsers guarantees a one-size-fits-all approach to page layout is doomed to failure. 14-point fonts can be grotesquely large on a 15” 640x480 screen and illegible on a 20” 1600x1200 display. White backgrounds can be simultaneously soothing on soft LCDs and retina-burning on bright CRTs.

 

Almost every desktop application respects the system color settings. Web browsers let the user choose default fonts and colors that work best for him, but hardly a webpage exists that doesn’t override at least one of those choices. Apparently each site designer knows best what colors and font sizes create the least eye strain for the user. Especially endearing are those sites that alter the main body text with a tag like “font-size: 80%” because the user’s font choice is just too darn big.

 

Current browsers offer minimal control over these settings. Typically they’re an all-or-nothing proposition: always use my colors or fonts, or never use them. The former is nearly as worthless as the latter, destroying judicious use of color to differentiate sections of a web page. Enforcing the main background color doesn’t have to mean eliminating all color on the page. Even the draconian “always use my settings” choice can frequently be obviated with CSS, which somehow bypasses rendering checks.

 

The web is an information exchange conduit, not a graphic design medium. Web sites should have limited control (subject to user approval) of alterations to viewing preferences.

 

Discussion by Tog:  Graphic designers spent the first twenty years of the computer revolution getting no respect.  When the web came along, they went a little nuts.  A few stayed that way.  So let me repeat what Mr. Elliot said:

 

“The web is an information exchange conduit, not a graphic design medium.”

 

If your site wins a graphic design award, be afraid.  Be very afraid.  Exceptions exist, but you’re probably selling a lot less product than you could.

 

Bug first observed: the mists of time

 

Bug reported to Supplier: Oct 1994 (first CSS draft published)

 

Bug Name: We don’t all live in the USA

 

Reported by: Tuna

 

Duration: Since the beginning of the web

 

Products affected: Browsers & Websites

 

Bug: Filling in forms that force you to enter information even though the field is irrelevant.  Worst example that keeps coming up are websites that ask you to enter your address - you select a country that isn’t the USA - and they then still force you to select which state you live in (and don’t give a N/A option).

 

Class of Error: Provincialism

 

Principle: Localize for increased sales

 

Proposed Fixes by Tog: 

 

á        Website stopgap:  Localize your forms based on user’s country selection

á        Website development tools:  Facilitate this by offering standard form stationery

á        Browser suppliers: Allow users to enter options/preferences indicating their country, etc., then allow websites to present standard form blocks by a single call, blocks such as name and address, phone numbers, etc.

á        W3C:  Come up with safe, secure standards for this activity, so we don’t all have to use a single browser to get the capability.

Discussion: 

 

Unintelligent web forms. 

 

Bug on list since:: Jan 2005 

 

Bug: “We don’t all live in Afghanistan”

 

Reported by: Tog

 

Duration: Since 1996

 

Supplier: ecommerce websites

 

Products affected: Browsers & Websites

 

Bug: Many ecommerce sites are laboring under the delusion that most of their customers reside in Afghanistan

 

Class of Error: idiot design

 

Principle: Defaults should be chosen to maximize, not minimize, the odds of their being the user’s choice

 

Proposed Fix:

• Website stopgap:  Place the four or five countries from whom you receive the most orders at the top of the list, with a line beneath.  Follow with the balance of the countries. Alphabetize both lists
  
  
• Website development tools:  Prompt for this configuration by developing a Country object
  
  
• Browser suppliers: Allow users to enter options/preferences indicating their country, etc.
  
  
• W3C:  Come up with safe, secure standards for this activity, so we don’t all have to use a single browser to get the capability.

 

Discussion: If 99% of your sales come from the USA, why offer an alphabetical list of 50 countries, headed by Afghanistan, with USA 7 fieldfuls down?

 

Bug on list since:: Jan 2005

 

Bug Name: “Ha! Ha! We don’t ship there”

 

Reported by:  Rainer Heilke

 

Duration: Since the beginning of e-commerce

 

Supplier: Various

 

Typical user response: Why the <bleep> didn’t you say so? 20 minutes ago!?

 

Product: e-commerce web sites

 

Bug: Not telling users (potential clients) that you’ll only ship within your city/state/country on an e-commerce web site.

 

Class of Error: I’m too lazy to tell you up front.

 

Principle: If there are any types of restrictions, the visitors to your web site should be told up front, not after they’ve spent however long filling in their billing, shipping, and credit data.

 

Proposed Fix: Full restriction list up front on the website, or at least before you request the buyer’s data.

 

Discussion: A variety of e-commerce web sites have restrictions, and this is understandable. As examples, Amazon.com won’t ship consumer electronics to Canada (and Amazon.ca doesn’t carry many of them), while Edmund Scientific won’t ship *anything* to Canada (or anywhere else but the US). This is fine, but the user isn’t made aware of this until AFTER they have filled in their shipping data (and often after they must fill in their payment data). Due to laziness on the web designers’ part (and again, laziness on their bosses’ part for letting them get away with this), the user finds out at the very end of an occasionally ridiculously long process (several pages, slow loading, etc.) that the one or seven items they want to buy cannot be shipped.

 

What makes this even worse, is that these sites use a standardized form, ripped off from the first e-commerce site every made (probably some pr0n site circa 1995) that has, as the country field, a drop-down list of every nation on Earth. If you refuse to ship to anywhere but the US (or wherever the company calls home), then why have this drop-down list at all? If you are too lazy to tell the user up-front where you will or won’t ship to, this field, fixed to the one nation you”ll ship to, or at least pared down to the few nations you will ship to, would be a very strong clue to the (now non-)client that (s)he is never going to get their product, so don’t bother getting your credit card out and filling in all of the payment data, etc. etc.

 

There is an additional twist on this, demonstrated by Edmund Scientific. If the user has to crash out of the order because you won’t ship to them, DO NOT act surprised and email the user, and DO NOT add the user to your email newsletter/new products email list. If your form results in a “we won’t ship there” message (and it shouldn’t be allowed to get that far, remember?), capture that and deal with the error intelligently.

 

Discussion: You may think this nasty practice has no downside. After all, the person the site just made murderously angry doesn’t live around here.  Unfortunately for them, some of those so badly mistreated do live around here.  I’ve had this happen to me when I was on a business trip, in need of some emergency supplies.  I would be home in a couple weeks, but I certainly wouldn’t be buying from them again ever.

 

Bug on list since:: Jan 2005 Dec 2004

 

Bug Name: The Back That Doesn’t Go Back

 

Reported by: Joseph Luk

 

Duration: At least 11 years (since the advent of dynamic web pages & forms)

 

Supplier: Browser manufacturers, web server manufacturers

 

Alias: The Back Hole, The Event Horizon, The Back Gamble

 

Product: All browsers, including those for PC’s, mobile devices, and everything else

 

Bug: The back (and forward) buttons don’t work, except in rare cases (browsing the circa-1994 NCSA Mosaic site, for instance).

 

Class of Error: Finger-pointing. “You don’t understand the technical reasons why it has to be like this. It’s a ( client | server | developer ) issue, so I can’t fix it.”

 

Principle: The back and forward buttons should simply take you back and forth through history states. This is simply one of the most basic principles of UI design: provide the user with an “undo”.

 

Proposed Fix: Browsers should diligently cache history states, including (especially) user-entered information. For tasks that are inherently difficult to undo (note, I did not say impossible) — for example, pressing the final “Place and Ship Order” button in a shopping task — developers should provide useful functionality, such as modifying or canceling the order. Browsers and servers should support markup and programming models to allow developers to easily implement Back, and ensure that they do not forget to consider it.

 

While we’re at it, quitting the browser (which still lacks a confirmation dialog box, by the way) shouldn’t throw away all of the user’s data. Rather, the user should be returned to the same state as before, with the information preserved and Back functionality still available.

 

Discussion: Once upon a time, we browsed static web pages, and our input to the system consisted of clicking on links. The Back button provided a great way for the user to Undo their input and to recover from errors in those days.

 

Fast-forward to 2004, when most web pages are dynamic, involving user-entered data and tons more functionality. Now, say you want to recover from an error in a multi-step task. Pushing Back is a little like Russian Roulette these days. It might:

 

Give you a completely blank screen

Go to an error page, carefully crafted by the developer, telling you something like: “Bad boy, don’t do that again.”

Kick you out of the session, forcing you to login again and start over (but wait, did those actions I triggered in the intermediate steps actually go through or not?), or

It might actually take you back to the last form you entered, only to find that all your data is gone.

 

Recently, some large sites that trade on ease-of-use and possess lots of spare developer time have begun to implement sane Back functionality, but the effort required with current tools isn’t usually cost-effective. Browsers have migrated to mobile devices, where the emphasis on “slim” often relegates Back to “that pile of Hard^(tm) technical problems that we just won’t deal with now.” Nevermind the fact that mobile devices, with their smaller screens, often require more steps for tasks, making Back even more important. And other applications, like the Mac OS X Finder, have adopted a “Back / Forward” model, but I wonder how much trust users place in such features, given the typically poor mapping to the mental model.

 

And we haven’t even started talking about what happens when you go Back and push Forward again (hint: if the chance of success with Back are 1 in 4, and the chance of success with Forward are 1 in 4, what’s the chance of a successful round-trip?).

 

If a model includes Back / Forward, users should be able to rely on going back to the previous page. At a minimum, browsers should attempt to automate this as much as possible, which would put pressure on web developers to implement error handling for those exceptions when the default doesn’t make sense. Programming tools need to place more emphasis on state models that match the user’s mental model.

 

Discussion by Tog:  Unlike Joseph, I’ve had functioning Back and Forward on my machine for years:  I open each and every link in a new window or, more recently, in a new tab.

 

I do suffer those rare occasions that Joseph mentions when Back doesn’t make sense, such as after pressing the final “Place and Ship Order” button, but generally things work out just fine.

 

The fact that this strategy works, and works well, both demonstrates that browsers already can cache history states and that their designers have been asleep for the last eight years, pretty much since the day that Netscape was driven into the ground by Microsoft’s decision to give away the browser for free.

 

Of course, the exception are those pitiable websites, driven by Flash, that don’t know from windows or tabs, adding yet one more way to slow users down to a crawl.

 

Browsers were originally designed to take up little memory room in an era when memory was still at a premium.  Throwing away mass quantities of pages after their painful trip through the tiny Internet pipeline seemed like a good idea.  Today it makes no sense at all.  Not only should users be able to go backwards and forwards, they should be able to see and select from the extended tree of all the pages they have visited.

 

The 1993 browser was weak in 1993.  Why are they still shipping it today?

 

Bug first observed: 1993

 

Bug reported to Supplier: Lots and lots of times, and dismissed an equal number of times.

 

Bug on list since:: Jan 2005