Experiences and requirements for a User Interaction Modeling Language

48
Experiences and requirements for a User Interaction Modeling Language Marco Brambilla marcobrambi Politecnico di Milano and WebRatio Emanuele Molteni emanuelemolteni WebRatio Code Generation 2012, Cambridge, March 28, 2012

description

User Interaction is one of the most overlooked aspects by software modeling practices. Some approaches exist for describing user interfaces in terms of buttons and items to be put in the forms, but they mostly consist of WYSIWYG form building environments. Furthermore, no standard notation exist for modeling these application aspects.This session will present the ongoing activities at OMG towards the standardization of a Interaction Flow Modeling Language (IFML): we will discuss the requirements and the scope of the sought standard, and we will propose a solution based on our 15-year experience in Web interaction design. We will be inspired by our WebML language, but we will also explain how to go beyond that, so as to cover mobile, multi-touch, collaborative applications, independently from the implementation platform.We will also show how a dedicated interaction modeling tool like WebRatio can ease the development through a plethora of facilities supporting the developer, including: visual debugging, quick prototyping, multi-platform and cloud deployment, and so on.

Transcript of Experiences and requirements for a User Interaction Modeling Language

Page 1: Experiences and requirements for a User Interaction Modeling Language

Experiences and requirements for a User Interaction Modeling Language

Marco Brambilla marcobrambi

Politecnico di Milano and WebRatio

Emanuele Molteni emanuelemolteni

WebRatioCode Generation 2012, Cambridge, March 28, 2012

Page 2: Experiences and requirements for a User Interaction Modeling Language

2

User Interaction complexity

The gap in UI modeling standards

Features, focus and objectives

Metamodel and UML profile

IFML by example

WebML and WebRatio

Agenda

Page 3: Experiences and requirements for a User Interaction Modeling Language

The Problem of User Interaction

Page 4: Experiences and requirements for a User Interaction Modeling Language

4

UI has been neglected in the MDE communityComplexity of UIs increase in time

• New events, devices, use cases, interactions

Crappy tools for UI programming around• Widgets drag&drop• Hooks to execution

No real MDE attempt to address the problem

UI Modeling Problem

Page 5: Experiences and requirements for a User Interaction Modeling Language

5

UI blends into visualization and graphics

Distinguish Interaction from Interface

User interaction focus:Previous attempts failed because of:

• Low usability and effectiveness of notation• Missing solid implementations with vendors support

User Interface vs. Interaction

Page 6: Experiences and requirements for a User Interaction Modeling Language

The Standardization Gap

Page 7: Experiences and requirements for a User Interaction Modeling Language

7

A perceived gap in the standardization efforts User interaction has been overlooked in modeling proposals

Previous attempts failed because of:• Low usability and effectiveness of notation• Missing solid implementations with vendors support

Standardization gap

Page 8: Experiences and requirements for a User Interaction Modeling Language

8

Exploit the possible relations withBPMN -- Already in place

Structure models (Class, components, CWM …)

SOAml

SysML

Others

Support the standardizationRefine the metamodel

Implement appropriate injectors to MOF-compliant models

WebML in the OMG framework

Page 9: Experiences and requirements for a User Interaction Modeling Language

The Standardization Effort: towards IFML

Page 10: Experiences and requirements for a User Interaction Modeling Language

10

Expressing

Content of interfaces

User events and interaction

Binding to business logic

of the front-end of applications belonging to diverse domains

Objectives of IFML

Page 11: Experiences and requirements for a User Interaction Modeling Language

11

formal specification of the different perspectives of the front-end

Isolate implementation-specific issues of UIs

separation of concerns in the user interaction design

enable the communication of interaction design to non-technical stakeholders

automatic generation of code also for the application front-end part

Advantages

Page 12: Experiences and requirements for a User Interaction Modeling Language

12

The VIEW part of a software application

view components

view modules

events

interaction between components

Interaction between the user and the components (events)

the distribution of view components and referenced data and business logic at the different tiers of the architecture

Focus

Page 13: Experiences and requirements for a User Interaction Modeling Language

14

Multiple views for the same application

Mobile and multi-device applications

Visualization and input of data, and production of events

Components independent of concrete widgets and presenation

Interaction flow, initiated by the user or by external events

User context: the user status in the current instant of the interaction (position, history, machine, platform,…)

Modularization of the model (design-time containers for reuse purposes of model fragments)

User input validation, according to OCL or other existing constraint languages

But not:

inference rules that make model specification simpler and more concise

Mandatory application requirements

Page 14: Experiences and requirements for a User Interaction Modeling Language

The IFML metamodel - 1

15

Page 15: Experiences and requirements for a User Interaction Modeling Language

The IFML metamodel - 2

16

Page 16: Experiences and requirements for a User Interaction Modeling Language

The IFML metamodel - 3

17

Page 17: Experiences and requirements for a User Interaction Modeling Language

18

Static aspects

The UML profile for IFML

« p a g e »AlbumSe arch

« p a g e »Albums

« p a g e »Album

Album Se arch Album Inde x Album De tail

« in d e x»M e ssage

Inde x

« in d e x»M Box List « lin k»

Page 18: Experiences and requirements for a User Interaction Modeling Language

19

Static aspects

Signals with tagged values

Dynamic aspects

The UML profile for IFML

« s ig n a l»Se le ctM ailM e ssage s

mBo x :s tr in g

T a g g e d va lu e s.

Pa ra me te r mBoxo u t n a me : se le c te d MBo xin n a me : mBo x

« in d e x»M Box List

« in d e x»M e ssage

Inde x

Se le ctMa ilMe ssa g e s(mBo x)

Page 19: Experiences and requirements for a User Interaction Modeling Language

20

IFML concrete syntax by example

Page 20: Experiences and requirements for a User Interaction Modeling Language

22

IFML concrete syntax by example

Page 21: Experiences and requirements for a User Interaction Modeling Language

23

IFML concrete syntax by example

Page 22: Experiences and requirements for a User Interaction Modeling Language

A real example.. The complete Gmail UI

24

Page 23: Experiences and requirements for a User Interaction Modeling Language

A solid foundation: WebML

Page 24: Experiences and requirements for a User Interaction Modeling Language

27

1998: Born within the W3I3 EU project• Visual modeling of Web application interfaces

2003: Evolved to the management of Web services (WebSi EU project)

2005: Evolved to the support of business processes (WebSi EU project)

2006: Added support to semantic web aspects (SWS Challenge)

2007-2010: continuous improvements, metamodel definition, support for additional aspects: reuse, async interactions, ...

Currently adopted in more than 300 universities worldwide for research and education purposes

Some words on the WebML history

Page 25: Experiences and requirements for a User Interaction Modeling Language

28

A visual modeling language (DSL) ...

Oriented to the high level design

Incorporating all the details that are needed for refined specification

... Effective and essential ...

Including only the concepts relevant to the domain

No overhead because of verbose notation or orthogonality

... For user interaction design ...

Page contents

Navigation paths and UI events

... Within web applications

Born bottom-up from the features of dynamic web applications

Effective and essential

Page 26: Experiences and requirements for a User Interaction Modeling Language

29

Role and positioning

Contents: ER, class, ..

Process:BPMN

User Interaction: WebML

Style:CSS, ...

Backend:soaML, WSDL..

BPMN model

Services

Page 27: Experiences and requirements for a User Interaction Modeling Language

Two pages

Retrieval of session data (CurrentUser)

Review Page• Lists of (prefered) artists • Links to artist details

Albums Page• List of albums of selected

artist• Checkbox and deletion of

albums

The WebML notation exampleReviewPage

CurrentUser

CurrentUser

AllArtists

Artist Artist

ArtistDetails

Albums

DeleteAlbum

Album

OK

KO

AlbumIndex

Album[PlayedByArtist]

GetUser

CurrentUser

Artist[UserPreference]

PreferredArtists

Page 28: Experiences and requirements for a User Interaction Modeling Language

31

A WebML unit is the atomic information publishing element

A “view” defined upon a container of objects:The instances of a concept

Based on one or more complex selection conditions (called selectors)

A unit may need some inputs and produces some outputsInputs are required to compute the unit itself (params of the selector)

Outputs can be used to compute other unit(s)

Content publishing units

UnitName

Concept[Selector (Param1, ..., ParamN)]

UnitType

IN:Param1, ... ParamN

OUT:Params

Page 29: Experiences and requirements for a User Interaction Modeling Language

Links

AllArtists

Artist Artist

ArtistDetails

Source Destination

Links in WebML have 3 purposesDescribe navigation paths

Transport parameters between units

Activate computation of units and execution of side effects

Normally, links are rendered as one or more anchors/buttons based on the dataset and semantics of the source unit

Various behaviors are allowed (automatic, asynchronous, transport ..)

Transport links: only carry parameters, no navigation nor side effects

Page 30: Experiences and requirements for a User Interaction Modeling Language

33

Execution of operations and business logic

Simple failure/success model of operationsSuccess: green “OK link” is navigated

Failure: red “KO link” is navigated

Chains of operations can be definedControl dictated by links

Basic control flow elements available (loop, switch)

Operation units

OperationName

Concept[Selector (Param1, ..., ParamN)]

OpType

OK

KO

Page 31: Experiences and requirements for a User Interaction Modeling Language

34

Content publishing Data Index MultiData Entry Scroller Multichoice HierarchicalIndex

Session management Web Services Login Logout Get Set Request-Response ….

CRUD OperationsCreate Modify Delete Connect Disconnect

Units coverage

Page 32: Experiences and requirements for a User Interaction Modeling Language

35

The language foundationsBasic set of units

Connection to a content model for data retrieval and management

Links for control and data flow

Page computation algorithms for execution semantics• The page content is automatically calculated also in case of complex topologies• Incoming links and dependencies among units are considered

The language is openNew units and operations can be specified

For implementing ad-hoc business logics

Foundations and extensibility

Page 33: Experiences and requirements for a User Interaction Modeling Language

WebRatio

Page 34: Experiences and requirements for a User Interaction Modeling Language

37

An Eclipse-based development environment allowing:Modeling: ER + WebML + BPMN

100% code generation of standard JEE applications• Clear separation between design time and run time• No proprietary runtime

Quick and agile development cycles

Extending the generation rules• Defining new presentation styles• Defining new components

Versioning, teamwork, full lifecycle mgt

What is WebRatio

Requirement Analysis

Solution Modeling

Prototype Generation

Results Verification

Page 35: Experiences and requirements for a User Interaction Modeling Language

38

... for designing, building and maintaining your custom enterprise applications

A fertile environment ...

Page 36: Experiences and requirements for a User Interaction Modeling Language

39

You capture business requirements in abstract, technology independent models

WebRatio – Step 1

BusinessUser

WebRatioModeller

Page 37: Experiences and requirements for a User Interaction Modeling Language

40

Design the model

Process ModelDefine business processes managed by the application

BPMN notation

Application ModelDefine data, services, logic and presentation details

WebML notation

Page 38: Experiences and requirements for a User Interaction Modeling Language

41

You customize the environment by defining your own generation rules

WebRatio – Step 2

LayoutDesigner

JavaProgrammer

Page 39: Experiences and requirements for a User Interaction Modeling Language

42

Customize the generation rules

Layout templatesfor a perfectly fine-tuned layout, tailored to your visual identity

Custom componentsfor implementing any kind of business logic, integration or complex task

Page 40: Experiences and requirements for a User Interaction Modeling Language

43

You get a tailored, yet standard, Java Web applicationwith no proprietary runtime

WebRatio – Step 3

WebRatioModeller

BusinessUser

Page 41: Experiences and requirements for a User Interaction Modeling Language

Get the application

WebApp

DBMS

Browser

SOACustom

InformationSystem

Standard execution environment

Standard JavaApplication

Server

44

Page 42: Experiences and requirements for a User Interaction Modeling Language

Involve business users in the development process and converge quickly to the target

An evolutionary prototyping dev cycle

Requirement Analysis

SolutionModelling

ApplicationGeneration

ResultsValidation

Page 43: Experiences and requirements for a User Interaction Modeling Language

47

3 reasons in favour of Code Generation

Execution environment is as standard as possible• standard architecture, standard libraries• fitting corporate IT policies

Two degrees of freedom instead of one• not all the requirements can be modelled• define, use and reuse your own generation rules

No vendor lock-in• generated code is human-readable, applications can be easily maintained without the

tool

Why we chose Code Generation

Page 44: Experiences and requirements for a User Interaction Modeling Language

Model

GenerationRules

GenerationEngine

49

Do you want to touch the generated application ?Touch the generation rules instead !

How you can keep on generating

GeneratedApplication

?

Page 45: Experiences and requirements for a User Interaction Modeling Language

50

Kinds of application

Corporate Operations

Human Capital Management

Product Life Cycle Management

CustomerRelationshipManagement

Enterprise Resource Planning

Supply Chain Management

Knowledge Support

Sales and LeadManagement

Marketing Resources Mgt

Web CustomerServices

B2C/B2BE-Commerce

Learning Management

Document Management

Project Management

Customer Information Mgt

Partner Relationship Mgt

Recruitment

Training

Workforce Management

Supplier Relationship Mgt

Business Intelligence

Web Content Management

Knowledge Management

Risk and Compliance

Enterprise Governance

Order Mgt

Payment Services Orchestration

Web Front-End of accounting sys.

Front-Office Process Mgt

Financial Services

Page 46: Experiences and requirements for a User Interaction Modeling Language

51

Some relevant experiences

worldwide web site + CMS and product

cataloguewww.acer.com

www.packardbell.com

Web-based, multi country,End-to-end Front-Office

Process Mgt platform

• Unsold items mgt system• Warehouse mgt system

Web-based, IT budget monitoring system

• Web-based security law compliance system

• Green energy department internal knowledge base system

Fashion & Furniture

Finance

Energy & Utilities

Public Sector

Electronic invoice mgt system

• Web-based cash control system• Internal training system

Mobile public portal

IT industry

Ecuador cooperative network cash flow compensation system

Web site + CMS + online customer services

Public transport pass e-ticketing system

Page 47: Experiences and requirements for a User Interaction Modeling Language

WebRatio is

now at its 6th major release (the 7th due since the end of 2012)

on the market since 2001

WebRatio customers

120+ companies and 500+ users

in Italy, Europe and South America

WebRatio adoption

15,000+ users of the free edition

Used in hundreds of universities all over the world

WebRatio partners

40+ software houses and system integrators

300+ universities worldwide, 12.000+ students

Summary

Page 48: Experiences and requirements for a User Interaction Modeling Language

[email protected]

marcobrambi

emanuelemolteni elenawebratio

Come and visit us at booth

Visit us at the booth and win 5 free copies of upcoming MDSE book and full access to

Morgan&Claypool library for 1 month!