While I agree that allowing for the use of rich client side technologies is highly desirable, we need to remember that not all user agents will be able to support said technologies. I'm thinking specifically of the myriad of WML devices out there. Since this is an initial spec, I'm much happier that it is capable of working with user agents of limited ability than if such user agents were forgotten altogether or simply tacked on at the end.
Let's get a foundation in place first, then we can tweak it. It reminds me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the foundation for later revisions which were actually usable. -- Marc On Tue, 2003-08-05 at 19:47, Gerry Reno wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
