What's That Noise?! [Ian Kallen's Weblog]

All | LAMP | Music | Java | Ruby | The Agilist | Musings | Commute | Ball
« Debugging a resume | Main | expiring application... »

20040309 Tuesday March 09, 2004

portals here, portals there I've been working on web-based management consoles for a long time now. Some of these projects I consider enduring successes, others, well, not so much. But over the years, the state-of-the-art for web-based management interfaces has grown more sophisticated -- everything these days, so it seems, is implemented as a portal.

The content management stuff I used to do at Salon.com has flourished; going from being an ill-conceived spin-off business to a successful open source project (Bricolage) [warning: I like java as much as anyone but I also like Perl, if you're a Perl-phobe, don't click that link!]. The web server management stuff I did at Covalent was also admittedly ill-conceived but in the end it was an interesting exercise in identifying the customer's pain points, pinning down their concrete scenarios and appropriately scoping a product to fulfill those needs. These products had little in the way of end-user customization. The display that the user saw was the display that was coded into the UI logic. As a reference point, that's not necessarily a bad thing. But as one sees the different roles that end-users fulfill using an application, allowance for end-user customization of the display seems increasingly important. Thus, the value of decomposing the display elements into portlets and allowing them to be aggregated by a portal framework.

The next product I worked on at Covalent was an application management web interface. The first version had a nice dashboard oriented entryway portal but had hardly any end-user customization as it displayed system objects. The architecture that was decided upon for the next generation ("two oh") product specified that just about everything be presented as a portal, ostensibly allowing the varyingly-role-filling end-user to see what was important to them at all times.

The framework used for the portal was a homebrew built on struts and tiles, for two oh we had a homebrewed jsr-168'ish framework underway. I'm certainly glad we didn't paint ourselves into a costly, proprietary corner with one of the Big Commericial Portal Frameworks. I'm actually wondering how the traditional big boys in the web infrastructure market can sustain six-figure price tags for frameworks like that when there has been so much activity around jsr-168 and open source portals. ( Mar 09 2004, 08:20:45 AM PST ) Permalink


Comments:

Post a Comment:

Comments are closed for this entry.