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]

Reply via email to