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?
You can absolutely change the look and feel of crosstabs and lists using the support Cognos skinning system. I've done a complete look-and-feel overhaul of Cognos for a previous employer which including changing the way dynamic elements looked.
If you look at the default styles in the GlobalReportStyles.css, all of these styles can be over-ridden in custom CSS files in your skin. That method would be safer than modifying the GlobalReportStyles.css directly as a custom skin directory will not be modified by an upgrade but the global stylesheet surely will be.
Unfortunately, you can't be certain that any modifications you create via the skin facility will render exactly the same way from version to version. Cognos could rearrange the UI or tweak the general appearance enough to break your changes. However, this is the only way I know of to effectively create universal, automatic look and feel modifications to the default Cognos objects.
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:
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.
I'm working with Cognos 10.1 now and getting ready for launch. The way I'm handling the installation, configuration and any tweaks is the an auto build/configure process that pulls data from a revision control system. This way even when upgrading I don't loose any customization and can easily merge in changes from the upgrade.