Almost 4 years have already passed since the first appearance of Open UI, the first serious Oracle commitment to the future of the once leader of CRM applications, Siebel. Its advent has been disruptive at the point that some professionals decided (together with other more obvious reasons) to abandon their career as Siebel professionals rather than learning this new framework.
I think it's time to closer analyse what Siebel Open UI represents for both business and technical people, because the final goal of a software should be that of simplifying it's users' lives and - eventually - expand its user-customer base... (or not?).
The Good
These could be obvious and well-known facts, still it is quite important to reinforce some points. A BIG limitation of Siebel in terms of user adoption and likeability was the old High Interactivity user interface, stuck with Internet Explorer browsers... I don't need to remind you that Internet Explorer has been officially declared dead (no future developments for it) to appreciate how necessary OpenUI was for Siebel customers - but maybe I need to remind you how users were frustrated to use an old user interface on laptops for work while during the day they were able to access new appealing applications on any device they liked (...and I am NOT talking about facebook - yuck!).
You may also appreciate the goodness of OpenUI and above all its latest releases (2014-2015) by reviewing the latest Salesforce.com UX reshaping, the Lightning Experience. You don't need a clinical eye to evaluate how much similar in many ways the new Salesforce UI is to the design of the standard Aurora theme of Siebel OpenUI... not only the three line menu navicon (that has become quite common in mobile-friendly web design - you might want to check the left-side of the search field on top of this linkedin page...) but also the advertised responsiveness of the design, so that you can use the same user-interface on different devices - with no changes. You might argue that this is the current state of the art in the entire web design, yet OpenUI has been the first one introducing this in CRM applications (not even Oracle Cloud is aligned in this sense).
Even the idea of having an open reusable and extendible Framework is a good one in a business context... so good that SAP thought of adding the 5 of HTML5 to OpenUI... by creating an open framework "built on web standards like javascript, HTML5, CSS3": OpenUI5 ... tah tah!
Probably managing the tangle of Hana was not enough for SAP... OK, I feel a hint of embarrassment... let's move on...
So, we all agree that OpenUI did really good for Siebel and that the Oracle development team did a great job by introducing this framework - and by all I mean also the competition, that took notes... but let's check out the less bright side of things...
The Bad
Other people before me have argued the difference between UX and UI: you cannot simply enhance the user experience by beautifying the user interface - it's probably a necessary but not sufficient condition. But we are here to talk about OpenUI and not CX so - if I have to point out some functionalities that decreased the user experience in terms of user interface usability, than I would like to refer to a list made by Jim Morse on his How To Siebel blog, called the top 10 most annoying features of OpenUI. Here you go:
- No vertical scroll in list applets.
- No hour glass for system processing.
- No popup multi-line text areas.
- MVG lost shuttle applet.
- Attachment drag and drop doesn't work.
- On the fly attachment update is not supported.
- Product configurator is slower than HI product configurator
- Screen real estate is not utilized properly in 8.1.1.9 to 8.1.1.14, lot of blank spaces left on UI.
- Keyboard shortcuts doesn't work properly.
- Document title is not static.
Actually some of these points are specifically referable just to IP2013 and have been later on addressed by Oracle (IP2014+), like the availability of shuttle applets. To this list, I would like to add two more general points:
- changing direction every year can be quite annoying for end customers that need to adopt OpenUI, above all when - for example - you first give the ability to use a Javascript class to dynamically change the themes (ThemeManager), just to deprecate it one year later.
- When you add new possibilities, like the Event Helper, it would be nice for the user to easily understand which is the best approach to achieve business and functional requirements
Siebel was successful as it embedded functional and business best practices, not because it represented a new custom development environment...
If we need to pass to a strictly technical standpoint, also not having a dedicated IDE for OpenUI is not something you expect from a thorough Packaged Application like Siebel. But if we talk about the framework, that's where I can really feel...
... The Ugly
And here comes the worse part of all... because if on one side all the previous "features" are bad, you can still use the extendible framework to change those behaviours (yes, it would be better having them as out of the box options and for sure not having to write hundreds of lines of javascript code, but still...). What you cannot absolutely change yourself, is of course the design of the framework itself - and I am all about design.
Working with OpenUI means that you have to remember, without any pre-built,easily consumable canvas, all the javascript API classes and events in order to customize the behaviour / appearance of a GUI component... and you still have to manually associate your new javascripts to the components you want to change. You might even be the best javascript developer on the market (actually - do wereally want that?), but if you don't remember all the OpenUI classes hierarchy you might want to double check each time you have to write something like this...
SiebelAppFacade.MyownDamnedPR.superclass.Init.apply(this, arguments);
Someone out there has just published on-line a piece of code of over 100 lines just to adjust the length of an applet's controls to the maximum text length. And you still want to call this a packaged application framework? I don't think so... a spontaneous question arise... why the hell do I have to manually extend every time the same god damn classes myself?! Shouldn't it be implied? Shouldn't the initialization and setup phases of a Presentation Model -for example- being filtered and modelled so that a developer can concentrate only on implementing the logic the business requested?
But here comes the best - once you have finished your coding, you have to go to your administration views and enter the name of the files manually; yes, because there is no automatic recognition by List of values or even a normal open folder dialogue... so if you are using a third party library, for example, you could need to manually write something like the following:
3rdParty/DynaTreeNav/javascript/dynatree/src/jquery.dynatree.js ...
Even the classic customization best practices always mentioned to avoid usingfree text for end users - the fact that in this case the end user is a developer does not mean that design best practices should not be followed... otherwise, guess what - there will be a lower user adoption...
In order to help and put some structure on this far-west coding, we @e-Up have introduced an intellisense editor embedded in e-Tools, by which you can work on both CSS and Javascript files, including pre-built templates and reusable snippets associable to the e-Tools visual diagrams' components. At the same time, we have structured for you the analysis of the rendering part of GUI components by using our #visuanalysis approach to easily show how they are rendered in Open UI. And we still have a pile of new functionalities on track that aim at putting order to chaos...
Just to reinforce what I'm aiming at, look at how the original good Siebel design has been applied to Web templates in the latest IP2015: rather than continuing accessing Siebel Web Templates in an editor, now that kind of information is structured in records and fields so that also Siebel web templates can be customized as a Packaged Application should be - by simply changing parameters, not writing code...
This might appear a purely technical matter, but that's not entirely true, because no one - included business - wants to adopt new technologies that - directly or indirectly - complicate their life rather than simplifying it.
Where am I pointing at, you may wonder? I am of course considering all those businesses that followed a cloud adoption as a way to simplify their IT infrastructure... if, on one side, corporations got an easier deployment process of their CRM/CX solutions, on the other side the Cloud - as promoted by someone - brought back custom development and new coding paradigms...
Cloud might have simplified business applications' delivery, but for sure it has not simplified the customization process.
Packaged applications had the benefit to give a working canvas to the business, without the need of starting coding from scratch - they were supposed to be less expensive than greenfield implementations, remember?... Have you looked around at what we have now? No software slogans... ahem... sure... if you say so. All I have witnessed is a proliferation of proprietary or derived programming languages. Corporations might remain satisfied for a while, but the typical programming practical issues will soon come back to hurt every single CRM/CX project out there...
So, to Oracle, my piece of advice... continue the right path with the CRM composer, not with open frameworks where you have to manually extend and control every single part - every time. At least in this case, Salesforce.com doesNOT docet.