Skip to main content

ERROR-BT_SPORT:VC040-NFR:0xFF-FAIL

Screen Shot 2015-09-15 at 21.38.05BT's Sports online player - which being polite is piss poor and with the UX design provided by a six year old - is a fine example of how not to deal with errors in user interfaces. "User" being the key word here...

Rather than accepting users are human beings in need of meaningful error messages, and perhaps in-situ advice about what to do about it, they insist on providing cryptic codes with no explanation and which you need to google the meaning of (ok, I admit I ignored the FAQ!). This will lead you to an appalling page; clearly knocked up by the six year olds senior sibling on day one of code-club, littered with links you need to eyeball which finally leads you to something useful telling you how to deal with the idiocy of BT's design decisions.

In this particular case the decision some halfwit architect made which requires users to downgrade their security settings (e.g. VC002 or VC040)! So a national telecom provider and ISP is insisting that users weaken their online security settings so they can access a half arsed service?...

Half-arsed since when you do get it working it performs abysmally with the video quality of a 1996 RealAudio stream over a 28.8 kbps connection. This likely because some mindless exec has decided they don't want people watching on their laptops, they'd rather they use the "oh-god-please-don't-get-me-started-on-how-bad-this-device-is" BT Vision Box - I feel sick just thinking about it...

In non-functional terms:

  • Form - Fail

  • Performance - Fail

  • Security - Fail

  • Operability - Well all I know is that it failed on day one of launch and I suspect it's as solid as a house of cards behind the scenes. Lets see what happens if the service falls over at champions league final kick-off!


Success with non-functionals alone doesn't guarantee success - you need a decent functional product and lets face it, champions league football is pretty decent - but no matter how good the function, if it's unusable, if it makes your eyes bleed, if it performs like a dog, if it's insecure and if its not reliable then you're going to fail! It's actually pretty impressive that BT have managed to fail on (almost) every count! Right, off now to watch something completely different not supplied by BT... oh, except they're still my ISP because - quelle surprise - that bit actually works!

Comments

Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.