As someone who interacts day-to-day with BI developers, consumers and the IT folks, who make the whole BI infrastructure function, I have firsthand, in-depth knowledge of the range of logistics that’s required to successfully bring an application from server to client user, regardless of whether the user is sitting in a corporate cubicle or perched on a coffee house stool, somewhere downtown.
I like to break these logistical things down into 2 categories.
Things WE have control of:
- Network access security (how and who can access our applications)
- Database access security (who can access our data using our applications)
- Data content access (controlling what an individual can see, data-wise in our applications)
- Application user experience (how our application is used)
Things WE have NO control of:
- Browser compatibility (trying to decide what browser to use so each users can access)
- Plugins (for purposes of this blog, just think Java Runtime Engine)
What we DO have control of, can effectively and efficiently be managed and these things can evolve at a pace that we determine, as an organization, be that organization small or large. It’s not necessarily always simple to do, initially, but its end result, when properly designed and maintained, is a ‘known’, that WE own.
What we have NO control over is what we DON’T own. Unless you are reading this article, sitting in a Google or Mozilla office in Mountain View or a building on the campus of Oracle in Redwood City or a building in Redmond, WA, you don’t own the browser or the plugin that comes with your PC, laptop or smartphone. THEY do.
If I had a dollar for every time I have answered a phone call or an email, requesting a solution for a “new, never-before seen” behavior of an application, because of a JRE or browser update/upgrade, I would have a whole lot of dollars. (Think annual paid trip to Hawaii, for a week)
As you read this blog post, literally thousands of developers are toiling away at their keyboards, carrying out the ongoing, unstoppable, never-ceasing evolution of the browser/plugin infrastructure that we all rely on.
This fact leads me to REASON 1 to move to HTML5: Using an HTML5 client means you do not need JAVA.
- A Java applet requires that your client device have a Java runtime engine plugin installed and enabled. No Java applet, no runtime engine. When informed of this, your Help Desk and other Desktop personnel in your organization would likely convene a large, raucous, impromptu party to celebrate. User productivity will increase accordingly, your application will always successfully launch and function properly, regardless of whether a client device has the “auto update” setting in their Java control panel turned on or not.
REASON 2 to move to HTML5: The HTML5 client can run on literally almost every device known to man. Can you say “Bring Your Own Device!” (BOYD)
REASON 3 to move to HTML5: Mobile BI will make you choose your application data content wisely.
- One of the knocks on HTML5 has been performance. The reality is, you can only put so much information on the limited real estate that the given mobile device has. Porting existing, data-bloated reports onto an iPhone or Galaxy S is a recipe for confusion and frustration. Taking the needed time to re-design your applications, one time and only one time with the Design Once Run Anywhere (DORA) functionality provided by arcplan 8, will dictate that you look at your data and how it is represented in new and likely much more efficiently creative ways. Use and choose your data wisely. Doing so will help you achieve peak performance and a really great user experience, which is what we all want.
With all that being said, developers from companies all over the world are ready for the changes needed to move away from the world of Java. Let’s not forget though, for years and years Java was the gateway to having and using a fully functioning application solution/deployment. But now with the new emergence of HTML5 and arcplan version 8, Java is now and will potentially become a figment of the developers imagination and will no long be used as frequently and regularly as before. Get ready to see HTML5 become the next best thing and the one thing companies all over the world will be asking all their developers to read up on as it is making Java a thing of the past. What do you think, HTML 5 or Java?
