Moving the Web (and the supporting browsers) from the browsing paradigm based on Pages, with related Back and Forward actions, to a full-fledged interactive application paradigm, based on the concept of State, that features Undo and Redo capabilities, and transactional properties

1. Modelling Safe Interface Interactions
in Web Applications
Marco Brambilla1
, Jordi Cabot2
and Michael Grossniklaus1
Politecnico di Milano1
Open University of Catalonia2

2. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

3. 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

4. Examples: GMail and Amazon bug

5. … 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

6. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

7. 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

8. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

9. 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

10. 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
ButtonClick
ListSelect
...
ExceptionState
Page
-id
-url
State
-name
-id
Transaction
Application
-id
-name
InitialState FinalState
Contains
1..*
1
-outgoing
0..*
-target
1
-source
1
-incoming
0..* TriggeredBy 1..*1
Effect
{ordered}0..*
1
1..*1
On
1
0..*
1..*
0..1
Includes
1..*
1
Has
1..*1
0..* 1
/ LinksTo
*
*

11. 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

12. 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

13. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

14. 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

15. 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
-timestamp
Transaction
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
CurrentVisit
1
0..1
TriggeredBy
1..*
1
1
1..*
ExecutedBy
1 0..*
1 0..*
1
1
0..*
1
1..*
1
1
0..*
-from
1
-next
1
-to
1
-previous
1
1
PartOf
0..1
1..*

16. 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

17. [ ]
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:

18. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

19. 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

20. Methodology: Integration with existing methods

21. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

22. Implementation
 Screenshot?

23. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

24. 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

25. Index
 Introduction
 Goal
 Modeling Safe Interfaces
 Tracking user-interaction
 Methodology
 Implementation
 Related work
 Conclusions

26. 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