Improving a portlet usability model

Abstract

Second-generation portals are far from being monolithic pieces of software. Their complexity calls for a component-based approach where portlets are the technical enabler. That being the case nowadays portals tend to be constructed by means of portlets, i.e. a multi-step, user-facing application to be delivered through a Web application. The proposal for and ample support given to the WSRP (Web Services for Remote Portlets) portlet standard predict an emerging portlet market. A main requirement for the blossoming of this market is the existence of portlet quality models that assist portal developers to select the appropriate portlet. This paper focuses on usability. The aim, therefore, is to develop a usability model for portlets. The paper presents such a model and its realisation for a sample case.

Appendix A: Attributes definition

1.1 A.1 Understandability attributes definition

The meaning of the attributes is explained as follows:

• Interface language: WSRP portlets have a generic interface to achieve interoperability (similar to Servlets). That being so, the interface as such does not give us any hint about the aim of the portlet. Therefore we only consider as an attribute the interface language defined as: “the portlet interface supports different languages”.

• Documentation: the portlet vendor provides the portlet with documentation on line. Hence additional information, which can help the portal administrator to understand the portlet, is provided.

• Documentation language: the documentation is provided in several languages.

• Description: this refers to the existence of a description of the portlet functionality, helping the end-user to understand it. This information can be obtained through the method getPortletDescription.

1.2 A.2 Learnability attributes definition

The meaning of the attributes established for this dimension is:

• Help: the portlet vendor provides help. Its domain is a natural number among 0 and 2, where 0 means that the portlet does not provide on-line help or help mode, 1 means that it provides one of them and 2 means that it provides both.

• Documentation: the portlet vendor provides the portlet with documentation on line. Therefore, additional information is provided.

• Predictability: portlet interface icons are easily related to the actions the portlet performs.

• Screens: it refers to the number of screens for achieving one functionality.

• Structured presentation: the presentation of the portlet is structured and easy to understand.

1.3 A.3 Customizability attributes definition

The meaning of the attributes is explained as follows:

• Location: the portlet captures information about the location from which it is accessed.

• Localization: is the capacity to tailor one portlet to the idiosyncrasies of a given culture- this is becoming an increasing concern. The aspects of cultural diversity that need specific support are normally arranged around two features, namely, language and country.

• Time: the portlet allows the adaptation of the application with respect to certain timing constraints.

• Device: this attribute discusses the demand of ubiquitous Web applications for any media, in terms of multi-channel delivery, and it provides basic information about the hardware and software capabilities of the device accessing the application. This feature can be split into Markup_Type (e.g. HTML, WML20, OR VoiceXML), and User_Agent (e.g. Netscape 702, mise60, or nokia7650).

• Network: the portlet can adapt itself to different networks. This attribute considers adaptation from the network viewpoint, and whether network context information, e.g. bandwidth or package losses, affects the application.

• User: the portlet takes into account the personal characteristics of the user. This attribute regards the need for personalization, i.e. how the user profile (e.g. demographic data, knowledge, skills and capabilities, interests and preferences, goals and plans) is considered by the application.

• Window states: space left for portlet rendering. WSRP defines five window states: normal, indicates the portlet is in all likelihood sharing the aggregated page with other portlets; minimized, the portlet should not render visible markup, but it is free to include non-visible data such as JavaScript or hidden forms; maximized, specifies that the portlet is probably the only one being rendered in the aggregated page, or that the portlet has more space compared to other portlets in the aggregated page; solo, denotes that the portlet is the only portlet being rendered in the aggregated page; custom, for consumers to declare additional custom window states.

• CSS: the portlet considers aesthetic guidelines for preserving the identity of the portal.

• Edit mode: the portlet provides the end-user with a mode for configuring the portlet. Within this mode, a portlet should provide content and logic that let a user customize the behaviour of the portlet.

• Necessary parameters: relation between the number of parameters which are requested of the end-user and the number of parameters that the portlet really uses in order to adapt the portlet to him/her. In order to measure the number of necessary parameters we define the next ratio:

  $$ {\rm Ratio}\,{\rm of}\,{\rm necessary}\,{\rm parameters} = \frac{{\it Parameters\_user\_fill\_in}}{{\it Parameters\_portlet\_use}} $$

  Where:Parameters_user_fill_in: is the number of parameters that the user must provide to the portlet. Parameters_portlet_use: is the number of parameters that the portlet really uses.

  The ideal case is when “necessary parameters” takes the value 1 because this means that the portlet uses all the parameters it asks the user for.

• Categories of users. The portlet supports communities: the content generated depends on the category of the user who is interacting with the portlet.

• Content depends on configuration: The portlet can tailor its generated content (in the mode view) to specific users depending on the configuration (window state, categories of users, user profile, user's preferences, etc.).

1.4 A.4 Compliance attributes definition

The possible standards for portlet usability are:

• ISO/IEC 9241 compliance (ISO/IEC, 1999): provides detailed guidance on the design of user interfaces (parts 12–17). ISO/IEC 9241 provides requirements and recommendations relating to the attributes of the hardware, software and environment that contribute to usability, and the ergonomic principles underlying them.

• ISO/IEC 14915 compliance (ISO/IEC, 2000): contains recommendations for multi-media interfaces. It provides recommendations for navigation structures and aids, media controls, general guidelines for media selection and combination, etc.

• IEC CDV TR 61997 compliance (IEC CDB TR 61997, 2000): contains recommendations for multi-media interfaces. To be specific, this technical report gives general principles and detailed design guidance for media selection, and for mechanical, graphical and auditory user interfaces.

• ISO DTS 16071 compliance (ISO/IEC, 2000): this technical specification provides guidelines and recommendations for the design of systems and software that will enable users with disabilities to have greater accessibility to computer systems (with or without assistive technology). These users include those with low vision, users with impaired hearing, or who are deaf, those with physical and cognitive impairments, and the elderly.

• Usability Engineering Process Model compliance (Granollers et al., 2003): the Usability Engineering Process Model integrates software engineering with a set of well-organized activities addressing usability, such as structured requirement analysis activities where usability is vital from the very beginning, or iterative evaluation activities of the usability goals.