Replace the Java applet with a booking page that needs no plugin, works on phones and shows dates and prices as text. Until then, put the phone number and the season's dates beside the booking box.

The site

A whale watching company on southern Vancouver Island runs two boats from a harbour, from spring into the fall. Its website was built several seasons ago and has hardly changed.

The home page opens with photographs of orcas and humpbacks. A tours page describes the three-hour trip and the longer one, with what to bring.

The Book Now button leads to a booking page built around a Java applet. It shows a calendar of tour dates, departure times and seats left, where visitors pick a date, enter their party and pay.

The applet came with a booking package bought years ago, and nobody now at the company knows how it was set up. On the office computer, the calendar loads as it always has.

The inference a visitor makes

Planning a summer trip in January, a couple opens the booking page. Where the calendar should be, they see a grey box, or a warning that an application has been blocked.

On a tablet, they see nothing at all, just a blank space below the heading.

The reasonable inference is that the booking system is broken, or the company has closed, or the site is not safe. Another company's site, a search away, shows its dates.

What shows where the calendar should be

The same page shows visitors one of five things, depending on their device and software:

Only the last shows tour dates, and it is the version the company's own staff see every day.

Why Java now asks first

Java in the browser has been the route for a long run of attacks on ordinary computers. Browser makers responded by asking before running it, or by blocking older versions outright.

Java's own update, released yesterday, goes further. At its default setting it blocks applets that are unsigned or signed only by their own author. Many small booking applets built years ago are exactly that.

A visitor could add the site to an exceptions list in Java's settings. Almost nobody planning a whale watching trip will, and the company can hardly ask them to.

A warning reads as a threat

The warnings use words like blocked, security and unknown publisher. A visitor reasonably takes them to mean the site is dangerous, and the safest choice is to leave.

Browsers word these messages to protect the visitor, not the business. They make no distinction between a harmless old applet and a harmful one.

Even a visitor who clicks through has been told to distrust the site just before typing a card number. That is the worst moment for doubt.

Phones and tablets never could

iPhones, iPads and Android phones have never run Java applets. For every visitor planning a trip on a tablet, the booking page has always been empty.

Holidays are often planned on a tablet on the couch or a phone on the bus, exactly where the applet cannot run.

Staff never saw this, because they check from a desktop in the office. The gap is invisible from the one place anyone looks.

Dates only the applet can read

The tour dates, departure times and prices live inside the applet. Search engines cannot read them, so a search for the company's July departures finds nothing.

No single tour date can be linked to or shared, and a screen reader cannot read the calendar. When the applet fails, nothing on the page takes its place.

Because the dates exist nowhere else on the site, a visitor who cannot run the applet has no way even to see whether the company sails in July.

A worked example

Another whale watching company, further up the island, met the same problem in the autumn. A regular customer phoned to say the booking page showed a warning and asked whether the company was still running.

Testing on a new laptop, a tablet and a phone showed the warning, the grey box and the blank space. Only the office computer, on an old version of Java, still showed the calendar.

That afternoon the phone number and next season's dates went up in text beside the booking box, so no visitor would leave without a way to book.

The applet was then replaced with a booking page built in ordinary web code. Dates and departure times are listed as text with the seats left beside each, and payment happens on the payment company's hosted page.

The tours page now lists the season's dates and prices in text, and the phone number is a tappable link on every page.

Nothing on the new page needs a plugin, so there is nothing for a browser or Java to block. It works on a phone, and its dates are text that search engines and screen readers can read.

The counter-case within the site

The applet could be signed properly with a certificate from a recognised authority, with the settings Java's latest version expects. It would then run on computers with current Java, after a prompt.

With the phone number and a plain list of dates beside it, that is a reasonable stopgap while a replacement is built. A signing certificate costs money and must be renewed, so treat it as a bridge.

But phones and tablets will never run it, and every prompt is a reason to leave. Signing buys time; a booking page without a plugin is the fix.

What to change

  1. Open the booking page on a new laptop, a tablet and a phone.
  2. Note what each shows where the calendar should be.
  3. Put the phone number and the season's dates beside the booking box today.
  4. List dates and prices as text on the tours page.
  5. Replace the applet with a booking page that needs no plugin.
  6. Take payment on the payment company's hosted page.
  7. Test again from outside the office.

Step five is where the problem actually ends. Signing the applet or asking visitors to change their Java settings only postpones it, while a page without a plugin works on every device visitors bring.

An events calendar showing an empty month looks at another calendar that misleads visitors: a month grid with nothing in it, though the next event is already booked.

Frequently asked questions

Why does the booking calendar show a grey box?

Browsers now ask before running Java, and the latest Java update blocks applets that are unsigned or self-signed. The grey box is where the applet would have run.

Why does it still work on the office computer?

Office computers often run an older version of Java that has not been updated, so the applet still loads there. Visitors with current software see the warning instead.

Do phones and tablets run Java applets?

No. iPhones, iPads and Android phones have never run them, so the booking page has always been empty for visitors using those devices.

Would signing the applet fix it?

It would let it run, after a prompt, on computers with current Java. Phones and tablets still could not run it, so signing is only a stopgap.

What should replace the applet?

A booking page built in ordinary web code, listing dates, times and seats as text, with payment on the payment company's hosted page. Nothing needs a plugin.

What can be done today?

Put the phone number and the season's dates in text beside the booking box, so visitors who see a warning can still find a way to book.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Booking calendar showing a grey box?

Send us your booking page's address, and we will check it on current browsers and phones and outline a replacement.

Start a Conversation