Question

My team has been working with creating dashboards and drill-through reports. We’ve moved past our proof-of-concept phase and are now working to build the “production ready” reports. In our meetings it has been brought up that the overall styles for the reports should be changed from the Cognos defaults.

We became aware of Cognos’s skin system. We saw that there was skinning for the portal and UI elements that are used within the report display and portal. This is not necessarily what we wanted. We ideally wanted to be able to change the portal to company branding AND change the way lists and crosstabs looked (as well as other elements of the actual report).

I was able to look at the page source generated for a report and saw that it is including styles from:

cognos\c10_64\webcontent\schemas

While poking around the webcontent directory I also found this path:

cognos\c10_64\webcontent\reportstyles

Both of these paths contain css files with similar names. The included styles for the report HTML point to the “schemas” directory, however my logical thinking self would like to believe that the “reportstyles” directory is used somewhere within the Cognos report display even though I have not seen it included in any page source I have viewed.

I have begun making my modifications to the css in the “schemas” path using a system of taking the included css file, copying the css out of it and placing it into a “xxx_system.css” file, and then including that file in the original css file.

This process works and we are able to see the changes, but we are still wondering if there is a better or “more correct” way of doing this. Can anyone elaborate on the best way to skin/style the actual reports?

Answer 1

My approach to customizing the UI is significantly different – imagine me coming into a company where they’ve been doing the same thing for 6+ years and I want to start changing everything around. It was met with some resistance, so I hope my experience can help you get started.

I come from a strong UI-based background and immediately wanted to contribute my knowledge to the reports we were designing. That required tact, as I wanted to show the value of a well-designed UI without shocking/scaring everyone that uses it (change adversity and the like). I handled this by working within the reports, not on the Cognos files themselves.

The minute you start working with the core files, whether they be CSS, Javascript, or CGI itself, there’s an immediate and glaring risk that it will entirely break on upgrade. I got around this by creating HTML items in my reports and calling resources from there. For example, this HTML item is in virtually every header of my reports:

<link type="text/css" href="cognos8/common/css/ui-lightness/jquery-ui-1.8.5.custom.css" rel="Stylesheet" />
<link type="text/css" href="custom.css" rel="Stylesheet" />
<script type="text/javascript"
 src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script type="text/javascript"
 src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/jquery-ui.min.js"></script>
<script type="text/javascript">
jQuery.noConflict();
jQuery(document).ready(function() {
}); // End Ready
</script>

So now I’ve got access to jQuery, the UI Framework, and everything else. I specify overrides in my custom.css and build my look from there. This might seem cumbersome, but IBM has a knack for upgrading major versions and completely wiping out naming conventions and functions, so if your CSS selector is off, it “defaults” to IBM’s original style.

This is just how I’ve had to get around it and I’m not sure entirely that it’s the best way. I’ve been working with what I have, which is no access to the server files or anything like that. Just consider this a super-safe approach.