Siebel OpenUI - the good, the bad and the ugly Dr. Manuel Breschi
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?).
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).
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...
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 184.108.40.206 to 220.127.116.11, 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:
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
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:
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...
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.