When is Banking On Line going to be updated to not require Java?

Tow

Hi,

It appears that support for Java plugins is being removed from current and is not in the next generation of web browsers.   With this in mind, can you tell me when Banking On Line is going to be updated to run without Java.

Thanks,
Tow.

testicle

So, what browsers is Java support being removed from?

Tow

testicle wrote: »

So, what browsers is Java support being removed from?

Current version of Chrome (without jumping through hoops) and there is no support in Microsoft Edge, which is the Windows 10 browser.

Bank of Ireland: Janet

Tow wrote: »

Hi,

It appears that support for Java plugins is being removed from current and is not in the next generation of web browsers.   With this in mind, can you tell me when Banking On Line is going to be updated to run without Java.

Thanks,
Tow.

Hi Tow, 

Thanks for your post.

Our Online Development team are always reviewing our services and security certification in line with best practice.

We'll pass on your feedback, and thanks for bringing this to our attention.

Janette

Red Alert

I don't think the Java plugin is going anywhere per-se.  What's happening is that Chrome has (and I suspect other browsers will) remove the NPAPI interface from browsers, which is currently used by the Java (and other like DVR/CCTV) plugins to embed applets in the page.

What isn't going anywhere, from what I've seen, is the Java Web Start facility. This is where a "fat client" application is launched directly from the web. So, if BoI's team have a well-coded applet for BoL it should be a minimal undertaking to change it over to Java Web Start.

Tow

You will still be able to download/Run IE on Windows 10, I am sure MS will keep patching it for a few years more. But it just adds to long term support costs for BOI, having to talk through customers with their newly upgraded Win10 machines.

ROS appear to believe Java is going and are currently moving customers to JavaScript, with a deadline of the end of it year. I believe ROS and BOL were both originally from Accenture, so I assume share much the same technology.  What worries me about BOI is the lack of in-house IT expertise, their appears to be no proactive centralised consolation or planning to their systems.  It will just be a case of fix it, until it is good enough, it for the lowest cost.  For example, how often do we see posts about account balances being wrong on this form, as the different systems synchronise!

Red Alert

I agree with you overall: I don't think there's anything that requires client-side Java in BoL.  You've also hit the nail on the head about one of the key problems with BoI's online banking: it's still an afterthought both in terms of vision and technology. 

Irish Steve

Guys,

A reality check. BOI are only now, with the latest reincarnation, moving away from only supporting IE for the business banking, and at last moving on from the VGA 800 x 600 fixed size screen that went away sometime around 15 years ago, and they're still playing catch up with so much of the newer technology,

Concepts like real time, interactive, and the like are just not part of the mind set or the vocabulary, which is why they are still using batch updates that result in wrong balances on the system while they are running, and in the "retail" package,  a CSV system that has the closing balance for the day's transactions on the first line of the CSV file entries for that day, which makes it almost impossible to automatically validate a running balance in a spread sheet, but the gurus that run the asylum see nothing wrong with either of these fundamental logic flaws that most self respecting programmers would refuse to perpetuate.

Expecting anything significantly upgraded any time soon is going to be a false hope, the culture just is not there to deal with even fundamental issues that are glaringly obvious to the majority of users, and what's even more galling, most users are still tolerating the failures, and accepting them as "the norm".

Even basic things like the PC based application log in crashing with very misleading error messages if you log out of account A and log in to account B without closing the browser are still there, due to incomplete handling and management of cookies, but while the users are not complaining about the issues, they are not going to bother to fix them.

I needed to transfer funds to Germany a few days ago, and between problems with the data needed to set up a SEPA transfer, and other issues related to cookies, and the crazy short timeout period that's set up for the system, I ended up having to log in 9 times in order to complete one transfer. 

The expertise in the core area of the BOI systems was got rid of a number of years ago, with the result that so much of the new stuff that was needed for SEPA wasn't truly integrated into the core, it was hung on to the edges using a hybrid mixture of real time and batch programming, which has all manner of limitations on it, the most fundamental being that there are significant periods of time when the information reported on line cannot be relied upon to be "the truth, the whole truth and nothing but the truth", and if you don't know what to watch out for, it can be very misleading indeed.

I've been involved with on line banking for over 40 years, in the UK and Ireland, on both sides of the fence, and the reality is that in many areas, the core concepts haven't changed in over 100 years. How the transactions arrive into the system, yes, that's changed massively with the advent of the newer types of smart cards, the rise of internet access and payment methods, and more recently contactless transactions, but the manner in which accounts are managed and controlled in terms of debits and credits is still fundamentally the same as it was. There's more information in some areas, and perversely, in some areas, like the automated In Branch Teller systems, there's now less information that we had for years when we used lodgement books, as there's no longer a unique transaction reference to identify the transaction, if you use the same machine every day for a month to make lodgements, you'll have the same reference number every day on the statement, which makes reconciling that statement an audit nightmare, but those same asylum gurus see nothing wrong with no longer having any way to specifically identify a lodgement by something other than the date or balance, like the reference number concept that was an automatic part of the lodgement book system for years. 

I guess that what I'm saying is don't expect anything proactive any time soon, the changes that are being seen are ALL reactive to outside forces that have meant that BOI has had no option about implementing them, and the end result in too many cases has been that the core functionality has suffered as a result. I don't see that changing any time soon, unless there's a fundamental change in the mindset of the people making the decisions at the top of the organisation, and looking at their recent history and their track record, I see very little grounds for optimism

Red Alert

You couldn't have put it better Steve. The fact is, as a lecturer in computing, many of BoI's decisions are ones I use as examples NOT to make!