I just finished reading the article " Introducing the Portlet Specification, Part 1" in JavaWorld. I was hoping to find there some latitude in the portlet spec that would allow for a portlet interaction model such as I had proposed to the JSR-168 team in response to the public release of the spec and in these two threads: http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2
http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2 Unfortunately there appears to be no latitude in the spec. The JSR-168 spec is supposed to permit creation of Enterprise Information Portals (EIP) using standardized portlets that are portable. This is good. But, I think that a lot of people have got themselves so caught up in the portlet lifecycle and the API and the storing of persistent portlet data and how do I create a ______ type portlet and all the rest that they are failing to look at a bigger picture of some of the human-factors and user-experience perspectives and expectations with regard to web enterprise information portals. From my perspective this is very important since JSR-168 is going to be declared *the* standard. The standard should provide enough flexibility to accomodate all the common types of paradigms and technologies to which users have come to use when utilizing the Web. The portlet spec as currently written is analogous to having a number of browsers open on your desktop and each one would represent a portlet and if you were to hit the reload button or minimize or maximize or submit a form from any of them, then all of them would reload their pages. Well this works great if you don't mind losing any client-side processing that is going on. The problem is that users are accustomed to having client-side processing and in fact expect a consistent context when interacting with client-side technologies. As it stands now, the portlet spec is dictating that every portlet mode or window state change causes an action request to be sent to the server. If you understand how the browser and pages and the document object model and browser client-side technologies work you immediately realize that constantly reloading pages is not a good thing. Ok, let's look at a real simple example. A user is interacting with an information rich JSR-168 portal. In the portal there is a media player portlet that allows the user to select from a list of available videos to view and there are other portlets on the page for various other information purposes. While the user is viewing a video presentation, one of these other portlets is doing something distracting and the user would like to minimize it so that the user can concentrate on the video presentation. Under the current JSR-168 spec the user's action to minimize this portlet results in a page request being sent back to the server which in turn results in the page being reloaded. What that does is destroy the original document object model (DOM) in the browser representing the original page and the subsequent creation of a new DOM representing the newly reloaded page. All running embedded client-side technologies such as applets, DHTML, javascript, Flash, SVG, etc. etc. are destroyed losing their contexts. The browser then redraws the reloaded page and all the portlets and initializes and starts all client-side scripts, modules, applets, objects, etc. once again. Well, for our user watching the video what happens is that the media player in the portlet is destroyed, recreated, initialized and starts over waiting for the user to make a video selection. Not exactly what the user would expect. Users are used to doing things like expanding and contracting lists, boxes and tables without seeing an expensive round trip to the server and a page reload. These are all things that are very easy to do on the client using DHTML, javascript, Flash, SVG or any other of the client-side technologies that can manipulate the DOM. In a broader perspective, under the current JSR-168 spec, all uses of client-side technologies are severely limited due to the interaction model dictated by the spec. Another issue is the user's perception of performance. I submit that a better model is one in which Java dovetails with client-side technologies to minimize round-trips to the server. Try testing a Jetspeed portal from a dial-up connection. If you are interacting with its portlets and using any of the buttons controlling portlet mode or window state, each button press results is a new page being served with the net experience being a portal that is painfully slow. What I notice a lot of the current Jetspeed sites doing is completely removing any of the portlet mode or window state buttons from the portlets and forcing the user into a rigid predetermined layout. This reduces the abilty of a user to cause a page reload but it defeats nearly all of the user preference flexibility of the portal. To create a portal model that will provide for a good user experience is going to require both server-side and client-side technologies working together. I would much rather see portlets implemented as either all iframes that can be controlled and reloaded individually or even better as something like CSS <div> elements that can dynamically be controlled on the client-side by DHTML, javascript, Flash, SVG, etc. for things like minimizing, maximizing, print-friendly, help, edit. That way the only thing that is going to cause a trip to the server is something like a form submit and even that should be done in a iframe so that the rest of the page doesn't reload. Please take some time to think about this spec and the type of portal behavior into which users will be locked. For a portal operating under my suggested model, when the user want to maximize a portlet, the portlet is nearly instanteously maximized with enhanced content and none of this is requiring a trip to the server. Additionally the user can now maximize, normalize, and minimize the portlet as many times as they like all without any requests being sent to the server. The portal can now even operate in an offline mode, the DOM integrity has been maintained so client-side technologies function as expected, portlets such as Jetspeed's IFramePortlet function properly, and the user is experiencing near instanteous response from the user interface and their overall experience will be much more satisfying. rgds, Gerry Reno __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
