Portlet Design Guidelines

Portlet Design Guidelines

General Guidelines

Multiple log-ins/sessions from the same computer

The new architecture will store user session on the server vs. the current that stores session information on the client. An advantage of this is that we will have higher security and concurrent log-in sessions is limited to certain browsers and users may need training. Popup windows will always share the browser session with the window that launched them.

* Internet Explorer

o Using File -> New Window OR CTRL-N will create a new browser window that is be part of the existing session.

o Clicking the Internet Explorer link on the desktop or program files will create a new browser instance i.e. a new session.

o All pages open in different tabs within the same browser share the same session.

Internet Explorer 6

Tools -> Internet Options -> Advanced:

Uncheck "Reuse windows for launching shortcuts".

Internet Explorer 7

Tools -> Click Internet Options -> Click Settings

Select Always open pop-ups in new tab.

The Yahoo! Toolbar is known to cause the browser to have only one session open in some cases.

* Firefox

o By default, Firefox shares one session across all browser window instances. There are hacks available online to disable this.

* Safari

o Safari shares one session across all browser windows.

Take advantage of the ability of a portlet being aware of the different modes and states

* The view mode should usually be simple and not have any interactive capabilities.

* As much as possible, configuration capabilities should reside in the edit mode of the portlet.

* Portlet level help is always nice.

The normal state of a portlet web application should be simple

The normal state should contain minimal interactivity or be read only. Unless strict style guidelines are put in place, the portlets should easily adjust to varying widths (avoid pixel widths) in the normal state.

The full application, with all its interactivity, should be available once the user maximizes the portlet since only one portlet can be maximized at a time. This addresses the following issues that arise when making the normal state interactive.

* Limited real estate: Since real estate is limited and not always guaranteed, it may be difficult to design a normal state that will play well with other portlets that may be added to the page in the future. This could be addressed by having more detailed style guidelines for portlets.

* Server load: If a page has 2 or 3 portlets, displaying a lot of information or interactivity, adds to server load when viewing the page. It is useful to remember that, whenever a user interacts with the page the entire page is redrawn.

* CSS issues: The default state is the normal state. The more complex the state is, there more chances there are for CSS definition collision, especially since portlets are not developed in tandem and can be added or removed from a page easily.

* Visual clutter: Usually a portlet addresses a specific goal. A page rarely has only one portlet. With several portlets, each with a lot of interactivity, it may become difficult for a user to interpret the page.

In most cases, combine portlets that need to talk to each other into a single portlet

Portlets are intended to be independent, so that moving them from one location to another is simple. Additionally, communication between portlets should be minimized. If essential, only minimal information should be passed to the other portlets and due to technology restrictions the end result may not be ideal from a usability perspective.

Internationalization

Identify all culturally dependent data. Text messages are the most obvious example of locale-specific data, but there are many other parts of a service that can vary with language or location. These include: images, UI labels and buttons, icons, sounds, graphics, dates, times, measurements, honorifics and titles, phone numbers, and postal addresses. The title bar for the portlet must also be localized, as explained in Portlet Title Bar below.

E.g. Do not use compound messages (concatenated strings) to create text. Compound messages contain variable data. For example, in the text string "You have XX credits," only the integer "XX" will vary. However, the position of the integer in the sentence is not the same in all languages. If the message is coded as a concatenated string, it cannot be translated without rewriting the code.

Accessibility

We need to take care how much JavaScript is utilized (includeing AJAX or rich-UI functionality). JavaScript commands that dynamically update portions of a page or that expand or reveal different elements can not be read in a predictable manner by a screen reader. The preferred method is to design the advanced interactions using a technique called progressive enhancement. The rich functionality is initially coded in plain HTML to ensure that the page works without AJAX, then JavaScript is used to enhance or change that content.

Minimize the use of pop-ups

Interactions within the portal are state-based, which means that the portal tracks your trail through the pages and portlets. Using the browser's back button or creating pop-up browser instances containing portlets can cause portal to lose track of your current state and cause problems. Other than using JavaScript prompts, there is no safe way to spawn pop-ups within the portal, unless the new link takes you to an external page (using a new browser window), outside the portal. Additionally, in new browsers like