Statechart of the Browsing portal 

Contexts in source publication

Context 1

... parameters determine the finale rendering of a page. But this does not mean that the designer has to set these parameters for each of the portal pages. Indeed, ensuring a common look-and-feel throughout the portal pages is one of the main concerns for the portal designer to improve usability and the user experience. To this end, skins have been proposed, i.e. templates defined at the portal level that set some presentation properties and are then inherited from all the portal pages. Besides ensuring presentation homogeneity, this mechanism accounts for maintainability as (some) changes in the presentation uniquely involve updating the skin rather than modifying the distinct portal pages. However, this mechanism can be too coarse grained, i.e. presentation is defined at either the portal or the page level. There is nothing in between. For large portals where pages can be grouped into clusters based on content or functional grounds, finer grained skins could be most convenient. The idea is to use the statechart for this purpose. Both states and transitions will have a presentation counterpart (see next subsection). Rather than attaching presentation parameters to pages, now these parameters are associated with states, and their scope includes all substates. That is, a parameter set for state S affects any widget associated with any substate directly or transitively below S . A parameter is overridden if newly defined in a substate. This approach offers a balance between the generality required to provide a common look-and-feel along the portal while at the same time addressing specificities of certain tasks or task clusters where presentation singularity is sought. Traditional skins correspond to presentation parameters defined for the upper state (e.g. Browsing ) whereas it is still possible to completely override the skin for a particular atomic state (e.g. IEEESearch ). Table 1 describes the presentation model complementary to our Browsing statechart. In Table 1 we can see that at Browsing state level the designer has specified that the font type and size for displaying portlet information will be Times and 12, but at the IEEESearch state has redefined them, and she has decided that specifically the ieee portlet will show its information in Courier font and 14pt. Moreover at Browsing state the designer has defined that the anchors will be detached and they will be shown with a solid 5px border-line and in a italic font-style, by default. At the PaperSearch state, she has redefined the description and the anchors with origin in PaperSearch will be shown with a dotted 7px border-line. As we can see in figure 2 the presentation of the page follows this specification. The states that are not in the table do not have a specific presentation model, they inherit from their parente state. Both models are independent, and using the same deskflow (statechart) it is possible to describe different presentations. In our example, for the statechart in figure 1 the designer could have decided another presentation model; for example, in Browsing state: fontSize=12pt; borderStyle=solid; borderWidth=3px; ...} .... In this case, the first page of the portal would have been as shown in figure 3. All anchors are together in the same row, and in normal 12pt font with a thinner border-line than before. In order to get the presentation configurations (portal pages) from the state configurations, statecharts are extended with two mapping functions, ...

Context 2

... is a function that maps from states to their presentation counterpart. Only basic and OR states are considered. Only basic states can be mapped to portlets 2 . In our example our six basic states (ISIWok, DeliciousStore, IEEESearch, ACMSearch, CiteSeerSearch, DBLPSearch ) are mapped to six portlets: isi, delicious, ieee, acm, citeseer and dblp. AND states are not mapped into widgets, and its unique purpose is to express concurrency in statecharts. An AND state indicates that information in widgets associated to its substates is to be shown simultaneously. This function also maps from transitions to anchors (the portal widget to perform the navigation). a2e is a function that associates anchors to statechart events that control the fir- ing of transitions. A statechart transition must have a unique event, although an event may appear in multiple transitions. In this way, HMBS supports reuse of link components, as transitions and events may be reused to define anchors in different navigational contexts. An anchor within a page must be mapped into a transition originating from one of the states of the state configuration associated to the page. In figure 1, for example, an anchor in the widget associated to state PaperSearch should be mapped to the transition fired by 2AuthorSearch . We can see that anchor inside the black dotted box in Figure ...

Context 3

... portal defines a workspace, i.e. a compendium of front-end tasks. From a portal perspective, a task is a unit of behaviour: you are either visualising the task or you are not. How the task itself achieves its duty is outside the portal realm. The portal responsibility is to define a semi-structured flow among the contained tasks, i.e. the “deskflow”. Statecharts are used to define the “deskflow”. Statecharts constitute a visual formalism for describing states and transitions in a modular fashion. It extends the classical formalism of state transition diagrams by incorporating the notions of hierarchy, orthog- onality (concurrency), a broadcast mechanism for communication between concurrent components, composition, and refinement of states. Specifically, an OR-type decomposition is used when a state is to be decomposed into a set of exclusive substates, whereas an AND-type decomposition is used to decompose a state into parallel, or orthogonal substates. Each concurrent region in an AND state is delimited by a dashed row. As an example, consider that the following tasks can be achieved within a portal: the IEEESearch task, which comprises a subset of the functionality of the IEEE portal; the ACMSearch task, which covers part of the offering of the portal.acm.org for the ACM organization; the CiteSeerSearch task, which includes the functionality for author searching at citeseer; the DBLPSearch task, which embodies the functionality for author searching at Ley’s site; the DeliciousStore task, which provides the functionality available at del.icio.us for keeping track of references found in the Web; the ISIWoK task, which permits to obtain distinct quality parameters of a journal (e.g. impact factor) or paper through the ISI Web of Knowledge portal. From the portal perspective, tasks are basic states. These tasks can be arranged along a deskflow as illustrated in figure 1. Here the portal designer initially considers two states: you are either searching for something on the Web, or you are storing your finding in del.icio.us . At any time, you can move to the ISIWoK task to consult the impact. Search is an abstract state which contemplates two situations: searching for a paper or searching for an author. Papers can be looked for at either IEEE or ACM. These options are simultaneously available, and hence, they are represented as an AND state (i.e. dotted line). On the other hand, author information can be obtained through the CiteSeerSearch task or DBLPSearch task. Both tasks can be simultaneously available, hence, they are also modeled as another AND state. At a given moment, the system is in a certain configuration state , i.e. the set of currently active states of the statechart [7]. Basically, a configuration state comprises a basic state (e.g. ACMSearch ), and its container states (i.e. PaperSearch and Search ). The substates of an OR decomposition are not allowed to be active simultaneously, whereas the substates of an AND decomposition are simultaneously active as long as their container states remains active. For our sample problem four state configurations are possible: – configuration1: {Browsing, ISIWoK} – configuration2: {Browsing, DeliciousStore} – configuration3: {Browsing, Search, PaperSearch, IEEESearch, ACMSearch} – configuration4: {Browsing, Search, AuthorSearch, CiteSeerSearch, DBLPSearch} By mapping each state to its widget counterpart, state configurations are mapped into “presentation configurations”. Figure 2 shows the result for the first state configuration. Next section addresses how this mapping is realized. Portal structure refers to the presentation counterpart of the deskflow . To this end, we adapt the extensions proposed by the HMBS model to the portal setting. Specifically, HMBS [5] extends statecharts with mappings to those primitives found in hypertext applications. Hence, we first introduce the presentation model (e.g. rendering concerns in a portal setting), and next, the mapping from a state configuration to a presentation configuration. Basically, the presentation model refers to the GUI widgets and layouts used for sup- porting portal pages. For our case, GUI widgets are portlets, anchors and texts. Style and layout parameters are used to govern the aesthetic and layout of these widgets. Next paragraphs describe the main parameters which, with distinct variations, can be found in IDE for portal development such as eXo, Oracle Portal or IBM’s Web Sphere 1 . Style parameters include background-color, border-style (values include none, dotted, dashed, and so on), border-color, border-width, font-family, color (often referred to as the foreground color), font-size, font-style (values include normal italic and oblique), text-align (i.e. how text is aligned within the element) and transition. The latter indicates how transitions are realized. The options include anchor (e.g. a button) or helping text where the transition is achieved by clicking on the underlined text. As for the layout , it indicates how the artifacts are arranged along the presentation workspace. This is specified through a template function that takes a state configuration and produces a template where each corresponding artifact is placed in a cell of the template. This template is then ready to be rendered as an HTML <table> tag. Therefore, for the purpose of this paper, a table-based page is the rendering counterpart of a state configuration . However, to avoid cluttered pages in dense configuration states, other template functions can be envisaged where frames or tabs could be used to distribute the presentation artifacts along distinct presentation areas. The description of how artifacts are distributed along the table’s cell is achieved through the following ...