Modelling Safe Interface Interactionsin Web Applications

Marco Brambilla1, Jordi Cabot2 and Michael Grossniklaus1

Politecnico di Milano1

Open University of Catalonia2

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Introduction

Web has evolved from navigation of simple hypertext documents to a a platform for complex business applications

Now, complex events and business logic + RIAs and AJAX

Original interaction paradigm (static content pages + hyperlinks) is not valid anymore

Browsers themselves are inadequate for the current web complexity Back and forward button

The same application behaves differently depending on the

browser and settings defined

Examples: GMail and Amazon bug

… but many more

Linkedin, iGoogle, survey monkey, gap, hostel world, lastminute,….

Solutions are site-specific (e.g. GMail moving from using a single URL for the application to a different URL for each message; blocking of browser buttons)

But still, sites are unable to – Preserve the complete navigation history– Offer rollback/compensation of side effects when backward navigation– Fine-grained back and forward management

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Goal

Proposing a method for modeling and running web applications with a safe interface interaction behaviour

1. Users can freely navigate through Web applications

2. Tool developers do not need to implement this safe behaviour from scratch

3. Our method is complementary to existing web modeling approaches

1. Moving from a browsing paradigm based on Pages with related Back and

Forward buttons to a full-fledged interactive paradigm based on States

2. Offering design-time and run-time support to create web applications

under this new paradigm

Benefits

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Modeling safe interfaces

MOF-compliant metamodel based on the state machines sublanguage of the UML

Adapted to the web application domain by means of adding web concepts like Page and GraphicalElement

Concrete syntax for the language not yet formally defined

Graph Transformation by Example: Metamodel

PredefinedActionType

GraphicalElement

-id-name-type

ActionParameters

-name-type

Action

-id-type-do_specification-undo_specification

PageParameters

-type-name

TriggerEvent

-type : EventType

Transition

-id

<<enumeration>>EventType

ButtonClickListSelect...

ExceptionState

Page

-id-url

State

-name-id

Transaction

Application

-id-name

InitialState FinalState

Contains

1..*

1

-outgoing0..*

-target

1

-source

1-incoming

0..* TriggeredBy1..*1

Effect

{ordered}0..*

1

1..*1

On

1

0..*1..*

0..1

Includes1..*

1

Has1..*1

0..* 1

/ LinksTo

**

Modeling safe interfaces – Example (1)

Show the internal workflow of the Mail page It is now clear when to go back to the previous page and when to stay

Modeling safe interfaces – Example (2)

The transaction (dashed box) clarifies that an undo in the Delete message state should undo the delete and move the user back to the show inbox page

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Run-time support

We need to insure that the web application behaves as expected

This requires to keep the execution trace of all events, visited states, accessed pages and executed actions executed so far

Mandatory to be able to retrieve previous states of the application when moving back and forth (or undoing Txs)

We provide:– The data structures to store this information– An API to manipulate and query these data structures

The API facilitates the development of web applications

Metamodel for the run-time support

ActionExecutionParam

-value

TransactionExecution

-startTime-endTime

ApplicationExecution

-id-startTime-endTime

TransitionExecution

-timestamp GraphicalElement

ActionParameters

PageParameters

ActionExecution

-timestamp

EventExecution

-timestamp

TriggerEvent

PageAccess

-timestampTransaction

InputParam

-value

Application

Transition

Page

User

-id-name

Visit

-id-timestamp

Action

State

0..*

1

10..*

-value

ElementState

ElementState

0..*

1

0..*1

1..*1

CurrentVisit1

0..1

TriggeredBy

1..*

1

1

1..*ExecutedBy

1 0..*

1 0..*

1

10..*

1

1..*

1

1

0..*

-from1

-next

1

-to

1

-previous

1

1

PartOf0..1

1..*

Some API functions

State::getNextState(Event e): State informs about the next state to go based on the current one and the given event

Visit::getNext(): Visit queries next visit Visit::getPrevious(): Visit queries previous visit ApplicationExecution::do (EventExec e, Parameter[] p): Visit moves to

next visit ApplicationExecution::redo():Visit moves to the (previously visited) next

visit ApplicationExecution::undo():Visit moves to previous visit reversing all

executed actions Visit::clone():Visit creates a clone of the visit ActionExecution::do (ActionExecutionParam[] params) executes the

action ActionExecution::undo (ActionExecutionParam[] params) undoes the

effect of the action TransitionExecution::undo() undoes all actions associated to the transition TransactionExecution::rollback() rollbacks the transaction

Let’s see now how with our API we can force a correct behaviour

of the “Back” browser action

[ ]

loop

in : TransitionExecution : ApplicationExecution : ActionExecutionprevious : Visitcurrent : Visit

cloned : Visit

: User

undo()10:

undo()2:

cloned12:

getCurrentVisit()3:

getPrevious()4:

assignNextVisit(current)7:

clone()5:

getIncomingTransition()8:

undo()9:

getPageAccessAndParams()11:

6:

Back()1:

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Methodology

Two ways of using the method

Standalone approach: More oriented to traditional developers that may use the API for

getting immediate benefits during the development The most they are willing to do is to adopt a simple notation to

describe the basic structure of the application

Integration with existing Web Development Methods: Decide whether to create a new view or blend with existing views

(e.g. navigation model) Add new primitives and resolve semantic conflicts

Methodology: Integration with existing methods

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Implementation

Screenshot?

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Related work

Several other approaches have proposed using state machines to specify the interface of web applications.

Recent extensions to existing Web Eng. Methods have covered RIAs

Specific solutions to the problem of using the back button in a browser have been proposed as well

We propose A generic method For the fine-grained definition of web interfaces With predefined support for their implementation With undo/redo support and taking into account the interaction

with the browser

Index

Introduction

Goal

Modeling Safe Interfaces

Tracking user-interaction

Methodology

Implementation

Related work

Conclusions

Conclusions and further work

We have presented a new method for the modeling and implementation of safe interface interactions in web applications

Based on state semantics and with transactional and full-fledged undo/redo capabilities to improve the browsing user experience

As future work we would like to test the methodological guidelines by – extending the code generator of WebML to support our new features and validate

the scalability and completeness of our primitives– Developing a simple code generator for the standalone approach that transforms

the models to skeletons of JEE code that invoke our API