Stay up-to-date with Internet Explorer…?

Microsoft rigorously changes their support policies for Internet Explorer it seems. 

After January 12, 2016, only the most recent version of Internet Explorer available for a supported operating system will receive technical support and security updates. For example, customers using Internet Explorer 8, Internet Explorer 9, or Internet Explorer 10 on Windows 7 SP1 should migrate to Internet Explorer 11 to continue receiving security updates and technical support. For more details regarding support timelines on Windows and Windows Embedded, see the Microsoft Support Lifecycle site.

This is pretty drastic. Until today IE8 would be supported until the supporting platform (e.g. Windows 7) would be no longer supported in either mainstream or extended fashion. This means that in less 17 months IE8 support is no longer (read: security updates) available. That said, Windows 7 will move into extended support per 1st of January next year too… Extended support for 5 more years. With Windows 9 on the horizon Microsoft’s focus is to move customers in a much faster pace away from Windows 7. 

Smoothing Siebel Open UI view navigations

The default behavior Siebel respond to view navigations seems a bit odd if you look at it closely.

You see more or less the UI destroying the current view while rendering the new view.

Not very nice at all. But… there is a nice and simple solution for it using view transitions.

View transitions? You find these under “User Preferences – Behavior”.


A couple of default transitions are defined (more for fun than for anything else…). But adding one is pretty straight-forward.

What does it require? One LOV and a bit of CSS. That’s all :-)

Just add a LOV as per below. Important is the Language Independant Code. I choose “FADE” as the LIC for a “Fade In Fade Out” transition.

FadeInFadeOutNext, define the transition. You can build on the existing ones if you like.

A “transition” occurs when you leave one view and move to the next. By default, nothing special happens. The new view is loaded into the same div element as the old view. By selecting a transition, some alternative functionality is activated which first copies the existing view content to a temporary div and then loads the new view into the a new div. The way in which the the old div then switches to the new div is called a transition and is something over which you have control using CSS.

The primary view content is always held in a div with the id “_svf0“. Once a transition is in effect, the contents of “_svf0” are copied to “_svf0_temp“. Then a set of CSS classes are applied in the following order:



<trans> is set to the LIC of the selected transition after converting to lower-case.

The CSS to be added to your custom theme:

.siebui-prev-fade-begin {
width: 100%;
height: 100%;
opacity: 1;
position: absolute;
.siebui-prev-fade-end {
width: 100%;
height: 100%;
opacity: 0;
transition: opacity .01s ease-out, visibility 0.01s linear;
visibility: hidden;
.siebui-next-fade-begin {
width: 100%;
height: 100%;
opacity: 0;
position: absolute;
.siebui-next-fade-end {
width: 100%;
height: 100%;
opacity: 1;
transition: opacity .01s ease-in;

Now, make sure you clear your browser cache, activate the new transition (User Preferences) and see the effect. The performance penalty is zero to none in my own testing. I have asked Oracle development to make this default behavior in IP2014, as it benefits all customers. It makes rendering much more appealing to the eye ;-)


Portable Browsers for Open UI testing to the rescue

You come across the problem that a feature does not longer seem to work with a certain release of a browser. The frequency at which Mozilla and Google release their browsers is at a high pace. And when software change, regressions can occur. Portable apps to the rescue. Just download your portable browser (e.g. Firefix Release x) from SourceForge. The positive side of potable browsers is that they require not an actual installation and hence you can typically also bypass any desktop policy restrictions too. Nice to run different browsers side-by-side without having to install/uninstall them. 


Take advantage of the SWECmd=AutoOn Siebel Test Automation feature

Documented here on MOS you will find information with regards to the net effect of adding the SWECmd=AutoOn instruction. It’s essentially a STA (Siebel Test Automation) feature, but can be handy at times to quickly identify an Object in Tools. Especially the “RN” attribute.

Quoted from My Oracle Support (Doc ID 1594954.1):

OpenUI framework would provide the automation attributes in the HTML DOM

RN – Siebel repository name of the element 
UN – Display name that logically identifies the HTML element
OT – Object type of Siebel HTML element (e.g. Button, JComboBox, etc.)

SweCmd=AutoOn is needed when you launch the application. 

DOM structure for New Button/Combobox with Automation support:
<button id=”s_1_1_7_0_Ctrl” class=”appletButton” type=”button” data-display=”New” title=”Accounts:New” ot=”Button” rn=”NewRecord” un=”New” style=””>New</button>
<input type=”text” name=”s_2_1_87_0″ value=”NY” aria-labelledby=”State_Label” aria-label=”State” style=”height: 24px; width: 120px;” maxlength=”10″ class=”ui-autocomplete-input siebui-input-popup” autocomplete=”off” role=”textbox” aria-autocomplete=”list” aria-haspopup=”true” ot=”JComboBox” rn=”State” un=”State” aria-disabled=”true” readonly=”readonly” aria-describedby=”s_2_1_87_0_icon”>

Enjoy it :-)

Siebel Innovation Pack 2014 & Open UI – Statement of Direction

Siebel Innovation Pack 2014 – Statement of Direction
Siebel Open UI – Statement of Direction

The IPxx numbering scheme will be Oracle’s major delivery vehicle, as most Siebelists know. Every year, scheduled late Q4. Honestly the IP numbering is just so much more informative. Despite that fact that yes, there will never be a “Siebel 9″ release (as competition of Oracle likes to market it towards Siebel customers). I have always found it hard to tell what a major release entails, most of all marketing driven. The IP numbering scheme is honest and clear to all customers. No more fuss?

Siebel IP2014 will bring a number of important improvements to the table.

To name two enhancements in particular: direct editing of attachments and iHelp.

Both were features lost in Open UI.

Direct editing of attachments due to browser limitations (especially the fact that browsers to not consistently support the HTML5 FileIO specification yet). For OpenUI to have this feature enabled again, it will require Java.

iHelp because it required extensive re-factoring of both the iHelp designer UI as well as the iHelp pane and highlighting feature. But IP14 will bring this feature back, sigh :-)

Further list of OUI improvements:

  1. OpenUI rendering performance (see also my other post)
  2. Calendar Alarms
  3. Drag and Drop of items
  4. Catalog Browse – The Siebel Catalog Browse for Quote and Order has been evaluated to support a drag-and-drop functionality for adding products to the shopping carts
  5. Product Configurator User Interface – The Siebel Product Configurator web artifacts have been updated to uptake all of the design principles of Open UI. This will allow our customers to refactor their customizations into the new Configurator framework. Style and theme changes are also available for web artifacts to complement the new framework. Additionally, all administration views that support Siebel Product Configurator are now available in Siebel Open UI.
    SmartScript Designer
  6. Smart Answer for Service
    Siebel Scheduler Administration View
  7. Gantt Chart Resource Scheduler
  8. Partner Portal (Quote/Order Home Pages)
  9. Organizational Chart or Global Account Hierarchy View (Account and Contacts)
  10. Expression Rules Designer
  11. Organizational Analysis View
  12. Barcode Scanning and Quick Search
  13. Email/Print Invoice (Siebel Service Mobile)
  14. Funnel Chart (Sales Pipeline Analysis Chart)
  15. Loyalty Program Designer

How deceiving SunSpider could be for Siebel OpenUI browser comparisons…

How deceiving the results of the SunSpider benchmarking tool are!

Well, at least if you would use SunSpider as relevant factor to decide which browser is best to run Siebel OpenUI…

SunSpider gives more than great results for IE11 compared to Chrome and Firefox. Is Microsoft still cheating [note: I have no personal opinion here :-)]

On my local i5

Chrome 36.0.1985.125

RESULTS (means and 95% confidence intervals)
Total: 197.0ms +/- 1.1%

Chrome 38.0.2109.0 canary (64-bit)

RESULTS (means and 95% confidence intervals)
Total: 218.3ms +/- 2.4%

Firefox 31

RESULTS (means and 95% confidence intervals)
Total: 208.7ms +/- 3.9%

And now, let’s see how IE11 (11.0.9600.17207CO) does….

RESULTS (means and 95% confidence intervals)
Total: 118.2ms +/- 5.2%

Awesome! IE11 seems to perform about twice as fast either either Firefox or Chrome.
No question, we should go for IE11. Or wait… should we?

Let’s see how Siebel OpenUI IP13 Patchset 9 (also known as – July patch set) performs on these browers.

But then… how are we going to effectively measure the rendering time other than using stopwatches?

With the great help of Duncan Ford a small performance testing framework for OpenUI has been developed. Just a small add-on (more about that in a separate post). What it will basically do is measure the time spent between “Preload” and “Postload” events. That is, it will exclude any CSS processing. Just raw JScript processing time. And we all know, Siebel OUI executes quite a bit of JScript (and with that respect JQuery functions).


Even without true measurements anybody would spot that IE11 is slower than both Chrome and Firefox. The latter two seem to be pretty much on-par.

But to take a more scientific approach we took a customized view from a customer real-life implementation. And used the same navigation pattern in the different browsers for five subsequent iterations. Just to cancel out any “warming-up” issues. And we accessed two different views. One known as “breakdown” the other known as “complaint”. What should be taken into consideration is that the views in this example are pretty large. They contain both large form applets as well as several list applets.

Where Siebel High Interactivity clients won’t really complain in terms of rendering performance when one would add a lot of controls, Open UI sees more or less a linear degradation based on number of exposed controls. Obviously because the compiled nature of the Siebel HI ActiveX control.

So, show me the money! You can see that IE11 is about 2½ times slower than Chrome and twice as slow as Firefox.

Firefox and Chrome are pretty much on-par.


The “PS9” column shows performance of standard

The “PS9 + Improvements” shows performance of JScript code changes which have been developed recently by Oracle Siebel development, and will likely be released with PS11 (October).

Especially where list applets are concerned (the “Complaint” view in this test contains 4 list applets, the “Breakdown” only 2) the further code improvements made a real difference of up to 33%.

Brief summary: don’t base your decision for browsers on Sunspider, and yes, there are more than significant performance differences between IE11 and Chrome/Firefox.