Seeking WebSphere Portal Server advice

I am currently involved in a huge public sector Web portal project that will be based on IBM’s WebSphere Portal Server. One of my responsibilities in the project is to provide guidelines and recommendations for all front-end code, including HTML, CSS, JavaScript, and RSS.

Not knowing a whole lot about WebSphere Portal Server I am slightly worried that the software will make it difficult (or even impossible) to achieve and maintain the high quality standards I would like all front-end code to meet. By high quality front-end code I mean lean, valid, semantic, and accessible HTML, CSS, and JavaScript.

Learning more about the possibilities of customising the code it outputs is on my agenda, but I’m very interested in other people’s impressions from doing front-end work in projects based on WebSphere Portal Server. More specifically I would like to find answers to these questions:

  • Does it allow full control of the code sent to user agents?
  • How difficult is it to edit the preinstalled themes and skins?
  • Is editing themes and skins advisable or will doing so lead to maintenance problems down the road?

During a one day workshop on WebSphere that I attended I noticed that the default markup used is far from up-to-date. It didn’t seem quite as bad as that produced by most Microsoft products, but I did not like what I saw. If the end result is going to adhere to the Swedish Guidelines for public sector websites, much of the default front-end code has to be heavily modified.

After seeing the default code, the following quote from the Redpaper WebSphere Portal Best Practices was a little surprising:

A portal is an open, standards-based framework supporting a wide array of options across databases, directories, platforms, and security.

Perhaps the developer who created the default installation forgot to read up on standards-based markup. Either that, or “standards-based” is only referring to the back-end systems.

In 3.2.3 Markup generation in the same document I found the following encouraging words about the use of iframes:

We do not like to see iFrames on portal pages. Years ago, the main reason was that Netscape 4.x browsers did not support it, but we do not see these browsers frequently any more. More concerns are regarding security and the portal concept. iFrames are just browsers on their own. With an iFrame in your page, WebSphere Portal would not be in control of the iFrames content, which is converse to the concept and might lead to unexpected problems.

Good. Avoiding iframes will make it easier to keep the front-end code under control.

As noted by Johan Berndtsson (who is also involved in this project) in WebSphere Portal UI design (in Swedish), the document warns the developer of promising too much customisation:

Be careful what you agree to regarding customizing the portal theme. […] Understand that customizing a portal theme to match an exotic, elaborate, or complex Web site can be very time-consuming.

Yes, but is customising a theme to deliver valid, semantic, and accessible markup exotic, elaborate, or complex? I hope not.

Any tips, suggestions, or pointers to good documentation are very welcome.

Posted on December 6, 2006 in Content Management


  1. It’s been a while since I worked with it, but I do remember a mess of code. It is entirely possible to rip the themes to shreds and replace the markup with something much more practical.

    On the project where I was exposed to it, I figured out how to clean up the themes, but the client was afraid of making changes to the markup. I prototyped a working version with clean markup, but they thought it safest to just use the markup that comes with Websphere. In the end, all we did was add a few classes and ID’s to hook into and keep the styling to a minimum.

    I can’t provide a whole lot of detailed advice, but I can say that there is hope. Only it’s not easy. Hit me up on IM if you want more details.

  2. December 6, 2006 by Tobias

    “Not knowing a whole lot about WebSphere Portal Server I am slightly worried that the software will make it difficult (or even impossible) to achieve and maintain the high quality standards I would like all front-end code to meet.”

    Welcome to the real world.

    I am watching the whole standards-movement for quite a while and I think I am into it, too. Different CMS and frameworks often make it hard to reach certain goals.

    The experience I made - which probably will be revealed in the near future more frequent than I’d like to - is, that you often are better off when you are completely on your own.

    No technical tip from me, sorry. I just want to encourage you to raise your voice for a coherent design as soon as you can to ensure that you actually can concentrate on what you are being paid for. Because it’s just tremendously awful not being able to show what you really can just because you didn’t assure your own prerequisites.

    I hope you manage it.

  3. December 6, 2006 by Tobias

    Oh in addition: If you can’t assure your clients that your work will be meeting your personal quality standards, be honest with them. Damage control will definitely leave a scratch onto your ego. I know how hard it is to hand in something you couldn’t do correctly in the first place. And it probably will never find the way into your portfolio. So sometimes there is the question: Why should I care?

  4. December 6, 2006 by Roger Johansson (Author comment)


    I can’t provide a whole lot of detailed advice, but I can say that there is hope.

    Thanks, that’s encouraging :-).


    Welcome to the real world.

    I never left the “real world” - I am exposed to substandard code generated by systems created by people who don’t know as much as they should about front-end code every day ;-). WebSphere is new to me though.

    If you can’t assure your clients that your work will be meeting your personal quality standards, be honest with them.

    They are fully aware of the fact that the platform may make compromise necessary. Thanks for the advice though!

  5. December 6, 2006 by Fredrik

    I don’t know much about the latest version (6?) But it was rather difficult in earlier versions of the portal, but it’s possible (We removed almost all tables (sometimes 4 levels deep) and converted those to corresponding divs or equivalents in a demo project a few years ago).

  6. It’s also been awhile for me, but I have done customisation of skins/themes of WebSphere Portal server a couple of times.

    Be prepared to spend MANY hours on it, no matter how you approach it, it will be a lot of work. For some reasons clients expect their ready-to-wear to be just as elegant as Haute Coture (or however you spell it).

    Make sure that you do your best to contain the portlets, or they will come back to bite you later on. By this i mean, that assume the worst for the portlets, some will have horrendous and invalid markup, even with nesting errors, unclosed tags, etc. Make sure you prepare for this.

    Forget about using strict rendering, portlets will have crappy markup, which are mostly outside your control. For WS Portal, you will for once appreciate loose, sloppy and forgiving rendering.

    Choose the simplest of themes, and play around with it for a couple of days, to get the mechanics of it, and then decide whether your want to customise their CSS or just scrap it entirely.

    Global Whitespace Reset is your friend[tm]

    Install WS Portal in Parallels, VMWare or whatever, and make sure you have a copy, of the finished, and untampered system, before making ANY modifications. It can be a bitch to get it running properly, and won’t take much tampering, before it’s broken.

    Stock up on plenty of ram for your workstation for this job.

    …. oh, and don’t call me when you’re crying at 2am :P

    Best of luck! Morgan

  7. December 7, 2006 by Mateo Nares

    I worked on a major WebSphere portal project with a high-visiblity client…it was difficult to enforce best practices and standards, specifically with the “back” button issues and the way the navigation is dynamically created…it was difficult to use CSS to its full extent…you are right to be afraid.

    The best tool to counteract potential pitfalls would be to get someone a product manager/specialist at IBM and stick to them like flies on shit…it worked wonders when asking for customizations.

    Thank you,

    Mateo Nares

  8. I’m working on a WebSphere Portal 5 (soon to be 6) implementation for my current employer. It’s for an intranet serving some 200 users.

    Most of the above comments are true. I’ve stripped table after embedded table after embedded table out of the cleanest of sample themes, and still I’m left with horrid markup to drudge through and manipulate.

    I’ve managed to get a CSS-based header, content and footer happening but the content columns (be it 1, 2 or 3 columns) are still table-based and difficult to get a grip on—there are no classnames or IDs to refer to and no way to implement them as far as I’ve learned.

    For skins (which style the portlets), there’s not an awful lot you can do either. I’ve wrapped the portlet ‘parts’ such as header and content in divs, but you can not control the mess of embedded tables within.

    As far as accessibility goes, well I’m afraid I can’t offer much hope.

    It’s a long and painful process - enjoy!

  9. I can’t understand why people choose this kind of software for a HUGE public sector Web portal project.. It’s the front-end, that makes the site accessible via valid and nice markup, so this is the first thing that has to be discussed before development/implementation.

  10. Rafal: I am with you on this one … I can’t understand that so many people make so many uneducated choices when it comes to technology. I think a lot of it stems from not trusting your in-house advisors (you and me, baby), but listening to the vendors salesforce instead.

  11. I’ve been working with BEA Portal for over a year now. Not the same product, but the same space of course. I can only echo what others are saying: be prepared for MANY many hours of hard work wrestling with the product.

    In the end, you’ll make a certain amount of progress, but you likely won’t be able to do everything you’d like. The people at BEA seem to be aware of web standards and tried to do their best (I think) to use sensible markup when they could.

    The problem is when you want a flexible portlet system that is extremely dynamic, they don’t really know how to do it any other way than with tables. That means even though portlet specific markup and nav markup might be all well and good, the ‘containers’ are all going to be tables (at least it is for us).

    I can easily look into a portlet and suddenly see that we are 8-10 tables deep, with good markup mixed up within it :(. We’ve done work to avoid it, but when you get into the deepest parts of the basic ways the portal works, you just can’t do it for a variety of reasons.

    And those are only markup problems. We have at least 7 style sheets, and don’t even get me started on the JavaScript issues. I wish we would have just written a custom piece of software instead.

    I don’t know how much better (if at all) Websphere is. But in the enterprise portal space, it would be nice to have a product that played nice on the front end. If there is one, I’d be interested to know what it is (Maybe it is websphere.)

    Good luck! You’ll need it.

  12. Rafal/Morgan - to answer your question - it’s because you are only looking at it from one perspective. In the real world there are business issues to deal with, and there are issues of engineer cost to deal with. To build a portal like these products offer from scratch is a massive effort that would require a large team, or long periods of time from a smaller smarter team. Maybe you don’t realize all the things these portals can do.

    BEA Portal does allow us to put out a fairly complex product using a small team of 3 engineers. That is very attractive to an enterprise. However, the problems many are mentioning are part of that consequence. It’s a juggling act you have to balance.

    It reminds me of what Jared Spool talks about. You can’t “sell” usability or web standards - the business doesn’t care about that. You can sell return on investment, or increased sales, or money saved - and portal software offers these things, and more.

    I do think that the person who figures out how to marry a complex, enterprise level portal that has a sensible front end that we can work with will end up being a very rich person.

  13. @Those who question why products such as these are ever implemented: You have to keep in mind that established businesses and organizations often have older software that they have no choice but to maintain and, if possible, improve. It’s hard for many of us — who see so-called Web 2.0 companies spring up and die in the span of months or even weeks — to remember that some custom software is written over the course of years, or even decades, using whatever language or technology that was “the best of what’s around” at that time.

    Even if the business logic is kept apart from the interface (in many cases, text-only, “green screen” type stuff), updating the application to a more modern language or technology would require not only a complete re-write, but also complete re-training of those who have been hired to write and/or maintain the existing code.

    Hence, you have IBM coming up with a product like Webfacing, which essentially takes your text-only, “green screen” interface and “webifies” it. In the eyes of the aforementioned software curators, it takes what they have and brings it into the 21st century, quickly and cheaply. Unfortunately, visual standards don’t carry very well between terminal (where organization is directed by how many charaters wide and tall a screen is) and web-based interfaces. Nor does IBM do much in the way of trying to generate accessible, standards-based markup by default.

    @Roger: Having some experience with Websphere and Webfacing, I can tell you that it’s going to be no easy task. As with most IBM products, there’s a fairly high barrier of entry, and by default, as previously mentioned, virtually no thought given to things like user interface and accessiblity. Go luck, and be prepared pull your hair out here and there.

    Also, the advice about finding someone within IBM and attaching yourself to them like a leech is spot on. Otherwise, you’ll end up bouncing from one “support specialist” to another. And trust me, they have a lot of support specialists.

  14. December 8, 2006 by Pierre

    I have done a large government project 3 years ago with WPS:

    All the above comments are true: Websphere is messy at best and you will need to work very hard (sometimes even bend over backward) but you can achieve a reasonable quality of work if you can manage some compromise. And forget about lean code.

    In my case, one of the key factor of (relative) success was working next to the guy who implemented the templates and being able to convince him of the importance of standards, content separation from design, etc. And being able to react to every problems that arose daily.

    In the timeframe we were given, we didn’t had time to remove the numerous nested tables. One other problem of WPS is the whitespace it leaves in the generated code: on a test page, I was able to remove 50% of file size by removing whitespace. This is not trivial.

    Wish you best.

  15. @Blair: Yeah, that’s the other issue. In this particular organisation we have a number of IBM products floating about the place (Notes/Domino, Rational bits and bobs, etc etc) as well as a number of other products spread across numerous vendors. Having something that works and integrates with them all is a must, and so is having someone who can support you from point A to point B. IBM Business Partners are great, but pricey. IBM support, if you get a local call center are great, but with thousands of support staff all over the world, it can be a nightmare getting someone to look at your priority support requests.

    Anyway, a bit off topic. In terms of accessibility, your best depends on how much time you’re willing to spend ripping it up.

  16. I’m currently on a project involving WebSphere as the company I work for has decided to make it an enterprise standard and all three of our portals (intranet, extranet, and public)MUST be delivered through it.

    Though it is possible to get in and change the markup, it is long and tedious and irritating. Software that costs this much shouldn’t be so hard to use and so resistant to being used “corectly.” If you are in a position at all to voice an opinion, do so NOW!

    This is actually the second time the company I work for has gone this route. They started with Vignette Application Portal (VAP) and man, did that ever suck. WebSphere isn’t working much better.

  17. I’ve just been part of a WPS6 launch. Luckily it was only for internal use.

    WPS6 is not standard compliant out of the box and the there be tables within tables within divs within tables and the nightmare goes on. And on.

    Rational Application Developer 7 (compatible with WPS6) wasn’t released when we started the project so I did what I could deciphering the dynamic files and their locations.

    I installed RAD7 yesterday and created a new THEME (affects the portal) based on the IBM them included. Tomorrow I will look into creating a new SKIN (affects the portlets).

    I think I might be able to remove the cobweb of tables and inline styles as the RAD is somewhat helpful in telling me what files I should work with when editing a theme.

    And the portal logic seems (at second glance) to be separated and easily identifiable for a non-programmer like me.

    So, my tip to you is to get a copy of RAD7, create a new theme and take it from there.

  18. I’ve been involved with a websphere portal implementation, and am now currently involved with a weblogic portal build-out.

    I won’t bother echoing out the same exact sentiments as everyone before me because I’ve gone through the same exact things. It takes a lot of patience and forethought and group buy-in to get something like this to work out optimally. The problem is - when groups are as big as these teams usually are, the preachings from one (or few) usually fall upon deaf, or ignorant, ears. It’s difficult.

    The problem I’m most running into currently is this whole cross-browser css development thing. I’ve begun refusing to use all these css filters and hacks and have been pushing HARD to use the conditional commenting that the versions of IE execute. It’s clean, it’s easier to debug, scale, and fix for those future browser releases. I’ve gotten some feedback from my partner engineers that they want the browser-specific styles to be kept in styles that will be pulled in no matter what browser is being used.

    The only way things work in that manner - Hacks. Filters.

    Can anyone here tell me the relative ease or difficulty in placing these static blocks of conditional includes in between the begin and end head tags generated by weblogic portal?

    I’m hoping maybe someone’s run into this before, and if not this will be food for thought for those who’ll be dealing with this in the future.

  19. Wow, I am currently starting up a new regional Portal Project for my company and I am facing the question if I will purchase something like WebSphere or not.

    Actually I have never worked neither with WebSphere nor with BEA. However after reading all your comments my conclusion would be not to purchase any of these solutions but rather developed an individual portal not using WebSphere or BEA. Did I get that right?

  20. Also I am initiating in the world of the Websphere and already install one in the company. I am responsible for the part of the Design, JSP and CSS of the project. Our current problem is the cache, we does not obtain sucesse to see in the same hour what we modify!!

  21. vendors are now addressing some of these challenges -

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.