- Roger Chang <Roger.Chang@sympatico.ca>
- Problem 1: Bookmarking applets
- - Users want to be able to bookmark a Java applet using their typical
interaction with the browser and maintain the Java applet's context even
though the HTML URL does not change (typically and optimally) since Java
applets maintain their own context within session. This applet could by
default spawned either in a browser or outside the browser by choice of
the UI designer and possibly the application as a preference.
- Changing the URL in a browser location field would cause the applet
to initialize losing it's context albeit this could however define a
default view. Initializing an applet will cause it to lose its memory
and flush its history which disables a "back" feature. Even signed
applets do not have access to locating and over-writing bookmark files.
- How do users' bookmark an applet using the browser? Should the user
interact with the applet or the browser for storing this state
information? How would this interaction work for applets outside the
browser?
- Problem 2: Cascading style sheets support
- - An application produces reports in HTML and charts in GIF format with
HTML legends. Currently and administrator is allowed to change
background colors of frames, tables, chart elements and the foreground
colors of HTML elements and chart text as well typical settables in HTML
such as background images of pages. The administrator also is currently
allowed to set a target monitor size and other properties for display.
All of the display setting are currently stored on the server and
displayed to the user as server-side includes.
- Now the client has requested CSS level 1 support. Some display
settings noted above are not currently supported by CSS; there are an
extremely large number of elements in CSS that allow more settings to be
adjusted that are not currently supported by the current application.
In the end, this application must also still be compatible with level 3
browsers (i.e., Netscape 3 and IE3) but the developers are willing to
detect the browser. Level 3 browsers might only get a subset of the
functionality since Netscape 3 has no CSS support.
- What is the UI that supports changing current display settings while
also supporting editing of a CSS? How much information should be
included in the CSS and how much information if any should be hard-coded
into the HTML? How much flexibility do we allow the administrator in
tweaking the ASCII CSS file manually? Should there a single
consolidated UI for display settings or not?
- Problem 3: Simulation of menus in level 3 browsers
- - An application is being migrated ("screen-scraped") from typical fat
client to HTML thin client (Netscape3 and IE3). The UI currently
supports menus that allow immediate actions, store mutually exclusive
menu selections as well as multiple concurrent selections that must be
ported over into an HTML based UI. The menus are context sensitive so
the number of elements in the menu probably would change within or
between sessions. The monitor floor of the application is 640*480
pixels.
- What is the best way to simulate menus that only use HTML3.2 and
JavaScript 1.0? How do you simulate disabled states given that menu
real-estate might be prohibitive? What characters should be used inside
a menu for the various interactions that must be supported using only
the Latin-1 character set but still be internationalizion friendly?
What is the limit on number of items that should be imposed on a context
sensitive menu?
|