Proposal: Jetspeed View Interaction Model
Author: Gerry Reno
Date: July 17, 2003
Need:
The Jetspeed portal needs to provide users with a good view
interaction (browser) experience where portal pages and portlets behave
in a fast, responsive and intuitive manner. Highly server-coupled view
interaction models which require every user action to cause a new page
request to be sent to the server result in slow, non-intuitive user
interfaces that often exhibit undesirable side-effects and place
unnecessary loads on networks and servers. What is needed is a
minimally server-coupled view interaction model that permits all
locally-achievable view modifications to be made on the client. This
results in minimal reloading of the document object model (DOM) and
provides the user with a rich, responsive, and intuitive user
experience.
Demonstration of Highly Server-Coupled Problem:
A good example of the type of problems that can occur under a highly
server-coupled view interaction model can be found in Jetspeed 1.4b4
using the IFramePortlet. This portlet implements the IFRAME tag on the
portal page which has a 'src' attribute that contains a URL that is
loaded in the frame whenever the tag is rendered during loading of the
page. The IFRAME tag has no means of maintaining state and will always
load the 'src' URL into the frame whenever it is rendered. This
behavior is typical of HTML tag elements. Under the highly
server-coupled view interaction model that is currently used in
Jetspeed 1.4b4 this very useful IFramePortlet is rendered nearly
useless by the fact that view actions on any portlet within the portal
page cause new requests to be sent to the server which result in page
reloads that in turn result in the IFramePortlet being rerendered and
its 'src' attribute URL being reloaded. What this means is that if a
user is interacting with the IFramePortlet and clicking on links until
they find a page of interest perhaps a shopping site with forms, etc.
and then they were to interact with any of the portlet view action
buttons on any portlet within the portal page such as minimize or
maximize, the entire page would reload and the users place within the
IFramePortlet would be lost since the IFRAME tag would be rerendered
and it would reload its 'src' URL. Try this for yourself to see the
problem. This is completely counter-intuitive to users general
experience with IFRAMES. Under the minimally server-coupled view
interaction model proposed herein the IFramePortlet would behave
completely intuitively as users expect.
Proposed Solution:
Providing for a consistently good view interaction experience for
users requires by definition, minimizing requests to the server and the
use of rich client-side scripting in conjunction with keeping the same
document object model (DOM) loaded in the browser for as long as
possible. The DOM can be manipulated using client-side scripting
languages such as DHTML and Javascript to accomplish local user view
actions. Actions that cause new page requests to be issued to the
server should be kept to an absolute minimum to avoid unloading and
reloading of the DOM. User actions that affect only the view such as
maximize, minimize, delete, print-friendly can then easily be
implemented locally through manipulation of the DOM within the browser.
In fact, all view interactions that can be locally-achieved by
manipulation of the DOM should be done strictly on the client and never
by a request to the server. Adopting this type of view interaction
model results in a user interface that feels very crisp and responsive.
While on a portal page, only when it is absolutely necessary to
send/retrieve server-side business data should a new page request be
sent to the server such as when a form needs to be submitted, for
example.
Implementation:
(I do not have familiarity with Jetspeed internal design or source
code and perhaps someone could provide some assistance here)
Considerations:
Internet Explorer broken CSS box-model:
IE 5 has a broken CSS box-model which causes misalignment of things
like sliced images when placed in <div> elements. There are ways to
directly detect broken CSS box-models (without relying only on
user-agent strings which can be masqueraded) and apply corrective
offsets to box parameters to compensate for this problem.
Browser Usage Stats:
source: http://www.doctor-html.com/agent_stats/
As you can see as of 7/05/2003 at least 95% are at a browser level
of 5.x or higher.
Cascading Style Sheets (CSS):
All browsers worth supporting (5.x or higher) are capable of CSS1.
------------------------------------------------------------------------------------------------
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
