Posts Tagged ‘portlet’

Does HTML5 spell the end of Portals?

March 17, 2011

The portal has just about always been the future of the web. A home page of information that helps bring links and information together, proponents have stated for more than a decade that the portal represents the key gateway to knowledge. As a concept this will persist, but as a specific technology well I believe soon, it will simply seem like a pathway to the past.

The reason is simple: HTML5. The last twelve months have seen HTML5 transition from a next-generation-maybe to the probable future of the web. Big companies, such as Apple and Microsoft, have been open in their support of the framework. In short, everyone has started to recognise the huge momentum behind HTML5.

But before we look at why HTML5 represents a death knell for yet another legacy technology, let us first understand why people use portals. The first reason is UI consistency; portals provide a nice easy way to provide a common look and feel across all portlets (applications).

The second reason, interoperability. Enterprise portals and public web portals – such as Yahoo! and iGoogle – allow organisations and individuals to run multiple apps, bringing together disparate apps running from different servers into a single browser window. These apps maybe running on very diferent server platforms, but once the app is viewed on a portal page, the user is none the wiser that it is actually coming from a different source.

Third, portals allow portlets to communicate and share data. This is a powerful feature that allows one application to “tell” another about anything. For example you may in one portlet find a person, once selected it “tells” another portlet who the user found. That second portlet might now show that persons account details, without the user having to do anything. Of course that interaction can happen with multiple portlets at the same time, powerful !

So, people use portals for UI consistency, application interoperability and application interaction. But the hype surrounding portals has dived since the dot com days of the late 1990s. Analyst Gartner reports the portal provider market has narrowed considerably, dropping from more than 50 vendors in 2003 to fewer than a dozen in 2010.

This brings us neatly to the future direction of portals – and the inevitable rise of HTML5. Portals are convenient, but they are also a pain. Small app windows mean only limited information can be shown.

Portals came out of an era when running one browser window sapped computing power. Now users can easily run multiple sessions, so why limit your information horizons to a collection of small windows?

HTML5 helps to overcome technical concerns, too. New APIs within HTML5, such as cross document messaging, mean information can be communicated in a secure manner regardless of the source domain. Consistency, meanwhile, can be addressed by CSS, which helps ensure the look and feel of HTML5 documents.

With a free HTML5 offering benefits across the key selling points of the portal, why would users choose to pay for and implement a separate technology? As HTML5 continues its march to glory, they will not.

Client Side Session Management (part 2)- Sharing is good

July 31, 2008

In my first article we covered the issues of server side session management and the benefits from a server perspective of session data being managed client side within a browser. These benefits are mainly technology related, but what about the user benefits? Yes faster more responsive applications can be achieved with client side session management, but from a user perspective the ability to share data across applications would be very powerful indeed.

The concept of being able to share data across disparate applications is not new, indeed as a windows programmer I’ve gone through the journey of DDE (dynamic data exchange), OLE (Object Linking Embedding), COM etc… However windows also had other mechanisms such as Global Atoms (anyone remember those ?) as well as traditional approaches like local databases or files.

However a browser based model is more difficult because of the sandbox security model. A server based solution does exist in the Java world this is the area of WSRP and Portlets. WSRP allows portlets to publish data to other portlets using standard interfaces. So if you had a window with a directory of your contacts listed, you might click on a name and your other windows (portlets) would respond by bringin back data about the person you clicked on.

Again however, if only browser developers would open their eye’s to client side session management, we could have very dynamic applications WITHOUT portlets and the server side overheads associated with portlets. (Remember a portal view of 5 portlets, means 5 times the number of sessions being managed by the server – hmmm you thought you had redundancy and performance licked until you deployed portlets ;o)

So how could this be done? I’m sure there are a number of ways, but if it’s been done before and worked well then I’m all for plagarising. Global Atoms ;o) Basically you should be able to define a global variable and provide a publish/subscribe model for that data item. This then would allow you to share data across browser applicatons (a bit like Google auto fill, but with application definable fields).

 The consequence? We reduce carbon footprints whilst creating more dynamic applications.