DICO- Università di Milano

Presentazione sul tema: "DICO- Università di Milano"— Transcript della presentazione:

1 DICO- Università di Milano
Meta design: approcci al progetto collaborativo di sistemi interattivi da parte degli utenti per gli utenti Piero Mussio DICO- Università di Milano .

2 Scaletta Il punto di vista di uno studioso della scienza dei calcolatori attivo nel campo dell’interazione persona-macchina Il contesto: produsage Il brodo primordiale dell’evoluzione: la comunicazione digitale Un caso: il museo Virtuale Tarchna L’utente come progettista: strumenti ed architetture

3 1- Il contesto: produsage
HCI and web technologies evolution makes user to evolve from content and data consumer to content and data producer (produsers)[Bruns 2006] “Meta-design characterizes objectives, techniques, and processes for creating new media and environments allowing ‘owners of problems’ (that is, end users) to act as designers” [Fischer et al. 2004, CACM]

4 Co-evolution of users and systems
Produsage emerges from a co-evolution process social & organizational context technology cycle 2 Social organizations & technologies evolve culture cycle 1 artifacts The user culture and the artifacts evolve materialization interpration interpretation Users’ appropriation of the artifacts evolves their practice -we see the emergence of users as developers and of new metodologies and tools as a co-evolution process in which the sharp distinction between users and developers is fading: they are no more considered as two mutually exclusive communities of people. se si dev citare al movimento 1 niellsen/carrol (ma carrol forse al 2) PER L’APPROPRAIZINE dix Al 3 borugin/mussio/costabile et al. Carroll, J., M., Rosson, M.B.: Getting around the Task-Artifact Cycle: How to Make Claims and Design by Scenario. ACM Transactions on Information Systems (TOIS) 10, (1992) Bourguin, G., Derycke, A., Tarby, J.C.: Beyond the Interface: Co-Evolution inside Interactive Systems - a Proposal Founded on Activity Theory. In: IHM-HCI, pp Springer Verlag (2001) P. Mussio, E-Documents as tools for the humanized management of community knowledge, Keynote Address, ISD 2003,Melbourne, Aug in Henry Linger, et alt. (eds.),"Constructing the Infrastructure for the Knowledge Economy: Methods and Tools; Theory and Practice", Kluwer, Costabile, M.F., Lanzilotti, R., Marcante, A., Mussio, P., Parasiliti Provenza, L., Piccinno, A.: Meta-Design to Face Co-Evolution and Communication Gaps between Users and Designers. Universal Access in HCI.LNCS 4554, pp Springer, Berlin (2007) Produsage: collaborative, continuous building and extending of existing content in pursuit of further improvement Toward user-led content Wikipedia: “ any one can edit”

5 2.Il brodo primordiale dell’evoluzione: la comunicazione digitale

6 Comunicazione tra umani
[after Tondl 81] communicant I communicant II subjective cod-decod a a cod-decod subjective Due interpretazioni per ogni messaggio (modello Ogden-Richards: il triangolo cibernetico) channel world methods methods world 3 3 2 2 a 1: perceives : messaggio 2: refers to 3: stands for A SA I B SA II 1 1 I(II) SA I ( II ) : State of affairs referred to by message as perceived by comunicant Comprensione (valutabile sperimentalmente) Equivoco Gap comunicazionale Semantizzazione progressiva Phenomena to which the conversation relates

7 Il messaggio digitale ha una forma interna ed una esterna
La comunicazione digitale Il messaggio digitale ha una forma interna ed una esterna Forma interna (Contenuto) Programma 1 Programma2 Programma 3 Forme esterne (percepibili dall’umano) suono video stampa il supporto di memorizzazione è diverso dal supporto che rende il messaggio percepibile la materializzazione del messaggio è mediata dai programmi che localmente traducono forma interna in esterna

8 Il contenuto è persistente ma la forma esterna è labile
Novità rispetto ai messaggi orali e scritti. La forma esterna è determinata dal programma che la genera permane fintantoché il programma la fa permanere dipende dal programma ( e quindi dall’autore del programma) il sistema ricevente può adattarla all’utente ed al contesto Il contenuto è persistente ma la forma esterna è labile il messaggio è interattivo e pro-attivo (non tace come il libro) interazione e pro-attività dipendono da programmi (e quindi dai loro autori ) l’autore crede di produrre un segnale in forma esterna ma produce una forma interna che solo un programma può interpretare. L’autore: - non può garantire la forma esterna - non può garantire l’accessibilità della forma interna

9 Comunicazione tra persona e sistema
Il programma ha un ruolo attivo nella comunicazione che nessuno strumento ha mai avuto. Codifica e de-codifca secondo criteri programmati dal progettista Designer Designer's SA User a User's SA Mondo percepito dal singolo Ma l’uomo interpreta la forma esterna ed il programma quella interna

10 La comunicazione… Il sistema è un proxy del progettista (de Souza 2006) Designer Designer's SA User a User's SA b Il sistema interattivo è un messaggio attivo (b): Un messaggio pro-attivo che il progettista invia all’utente. Un messaggio che genera e interpreta altri messaggi (a): un meta messaggio che si comporta come è programmato a fare

11 Nuove possibilità Documento Utente Utente:
L’utente come produuser: può generare nuovi contenuti- ad esempio mediante sistemi di annotazione. SCHERMO Annotazione creata dall’utente 4. Decide di salvare l’annotazione Documento 3 studia il documento e l’annota 5. l’annotazione viene archiviata, e diviene un documento gestibile Utente 2. Il documento ritrovato viene mostrato 1 .Richiesta documento Utente: da consumatore a produttore di conoscenza Archivio Documenti In caratteri Agency: azioni che l’utente fa usando il sistema come strumento (ricordare i 4 ruoli) In caratteri tahoma: azioni che il sistema esegue come secondo agente nella conversazione Armour: il software è un nuovo medium di conoscenza (Comm.Acm, 2003)

12 Sfruttare le opportunità, superare i trabocchetti
Riconoscere l’utente come “owner of the problem” l’utente come co-autore della forma esterna, interazione, e organizzazione dei contenuti (progettazione partecipativa) Riconoscere i nuovi problemi i gap comunicazionali tra utenti e progettisti tra diverse comunità di utenti

13 2- Un caso: il museo Virtuale Tarchna e l’emersione di un nuovo medium di conoscenza

14 The T.Arc.H.N.A. project The UE funded T.Arc.H.N.A. project is aimed at making Etruscan Cultural Heritage accessible, understandable and attractive to large public (and remunerative for Museums and Archeological sites) Problem: findings, monuments and documents are dispersed throughout European museums. Visitors can see them, but cannot understand their context of production, employment and role in the Etruscan life. Etruscan era: 1200 BC- 100 BC

15 Goal: reunify and make accessible Etruscan Cultural Heritage
Create an IT structure federating existing European Etruscan archives to allow: Archeologists to restore the unity of Etruscan cultural heritage, virtually connecting findings and documents to reconstructs their original context of use, focusing on geographical, spatial, anthropological and functional information. Visitors: to contextualize a real Etruscan item exposed in an European museum or archeological site by accessing the T.Arc.H.N.A. system through Totems, PDAs, PCs ….

16 Archeologist foreseen strategy
Reconstruction of the unity of the Etruscan Cultural Heritage by creating an hypertext (T.Arc.H.N.A. system).. T.Arc.H.N.A. reconstructs contexts by linking electronic documents describing the monuments and different findings which constitute it.

17 Each finding is associated to several meanings
A crater is built to contain liquids….. used in aristocratic banquets and symposia ..contains wine in a cerimony. A symbol of life, joy and amusement ..but it can assume different functions and play different roles …but also used as a funerary container as explained by the context in which is discovered ...contains ashes and bones, A symbol of death and sorrow

18 Archeologist foreseen strategy
Archeologists need to associate each finding to its practical and symbolic meanings studying its roles and functions in different contexts of the Etruscan life reconstruct the spatial context in which it was found and functional and anthropological contexts in which it was plausibly used. describe the different functions and roles the finding played in in different life situations, from the use in everyday life to the use in rituals. create texts (narrations) which introduce the different cultural issues connecting findings and documents.

19 Information scientists foreseen strategy
Create the an hypertext presenting the Etruscan Cultural Heritage as unified whole (T.Arc.H.N.A. system). Archeologists Visitors Archives of 7 European Museums Derive T.Arc.H.N.A. ontology from CIDOC Conceptual Reference Model* ontology Use T-ontology to federate existing European archives. *The CIDOC CRM is official ISO 21127:2006 standard ontology for Cultural Heritage

20 The start: a clash between the two cultures
Different views on reality, different ways of reasoning and teaching - abstraction, observation, measurement, evaluation model based vs analogy based algorithmic vs. heuristic -knowledge representation, organization and diffusion computer based vs paper based explicit information vs implicit information - communicating, teaching and learning : formalization based vs practical observation different balance between explicit and tacit knowledge

21 An observed phenomenon
Communicational and reasoning gaps - Same word used with different meaning - Different naming techniques (use of synonymy and context) - use of tacit knowledge in the development and interpretation of documents leads to misunderstandings and equivoques

22 To overcome the gaps Both Archeologists and Computer Scientists
admitted that dealing with such a complex achievement, they had to accept to teach and instruct each other. (simmetry of ignorance) recognized the Need of performing a progressive semantization process to create a common language as a common field of interaction and not only a common terminology

23 The progressive semantization process
Started from CIDOC Conceptual Reference Model ontology used as a boundary object for reaching a common understanding Based on the development of incremental prototypes used to externalize stakeholders’ tacit knowledge and as boundary objects Results: A portal “Virtual Museum” The emergence of the new digital communication media “Narration”

24 1° risultato : un Museo Virtuale
Il museo Virtuale è costituito da un sistema interattivo (Tarchna System o T-system) T-system permette agli archeologi di creare narrazioni digitali di che descrivono aspetti della civiltà etrusca. T-system è capace di interpretare queste narrazioni, e presentarle ai visitatori dei musei T-system permette ai visitatori di esplorare la civiltà etrusca interagendo con le narrazioni.

25 2° Result: emergence of a new communication media
A NARRATION appears to visitors as a narrativeTEXT (A) and a set of documents (B) which contextualize the issue in its anthropological and historical context (CS-CONTEXT )

26 Narration creation (1) A two step activity
First step: an Archeologist interacts with T-system in domain oriented languages to define TEXT CS-CONTEXT DESCRIPTION. CS-CONTEXT DESCRIPTION defines which documents may be of interest T-system supports archeologists authoring TEXT and CONTEXT DESCRIPTION makes available scientific abstracts created from narration texts and literature providing a well suited internal form of TEXT and CONTEXT

27 Archeologist defines indirect narration
Music had a great importance in the Etruscan society TEXT Select all instruments made of bronze material CONTEXT Description A Narration Builder was designed in which interaction occurs according to archeologist mental models and languages allowing them to exploit their tacit knowledge in defining CONTEXT DESCRIPTION without becoming acquainted in computer science.

28 Narration creation (2) Second step: On user demand, T-system
interprets the CS-CONTEXT DESCRIPTION, retrieves the documents in the web, creates on the fly the NARRATION displaying TEXT and CSCONTEXT (the set of documents). Observations: CS-CONTEXT DESCRIPTION is a program T-system federates the db of the museums to create the CSCONTEXT on the fly

29 An overview of the Tarchna system
Narration Builder: T-system support archeologists and organizes a narration archives Archeologist Creates narrations Narration archives T-system support users On demand, selects a narration, interpret it, creates the contexts, present the result to visitors Visitor

30 Narration features A narration cannot be predicted in advance: the TEXT (A) is permanent as defined by the text author. The CONTEXT (set of documents B) is built on the fly: it depends on the number and current state of the data bases available in the web

31 New roles for Archeologists, Systems and Visitors
A NARRATION is the result of: social activity the of community of archeologists, in the creation of TEXT, CONTEXT DESCRIPTION and of the documents in the federated data bases. T-SYSTEM mediation: T-system interprets CS-CONTEXT DESCRIPTION to create CONTEXT. T-system as a proxy of Archeologits who create it Visitors become active builder of their experience

32 Archeologists as produsers
In content creation: Shift from dedicated individuals and team as producer to a distributed generation of content. Fluid roles in production: fluid movements as leaders, participant and users Artifact generated are no longer products in traditional sense: continually under development (evolutionary, iterative)

33 Each stakeholder’s knowledge complements the ignorance of the others
La lezione (confermata da molte esperienze) Il progetto di dì sistemi che supportano processi di interazione così complessi richiede l’esperienza di diversi specialisti (un approccio partecipativo) che operino alla pari ( simmetria dell’ignoranza (Rittel)) Each stakeholder’s knowledge complements the ignorance of the others una adeguata infrastruttura digitale di supporto

34 3- una generalizzazione: la metodologia Software Shaping Workshops

35 Meta-design Our view: A design paradigm that includes end users as active members of the design team and provides all stakeholders in the team with suitable languages and tools to foster their personal and common reasoning about the development of interactive software systems that support end users’ work. Two-phase process the first devoted to design the design environment the second one to design applications using the design environment To allow EUD activities, we have to consider a two-phase process… The definition is due to Fisher et al. in CACM. In other words, meta-design is… This two-phase process requires a shift in the design paradigm, which must move from user-centered and participatory design to meta-design

36 Our meta-design approach
A design methodology (SSW methodology) aimed at designing interactive infrastructures that address the needs of different communities of end users and allow them to design their tools A software infrastructure is composed by software environments, and communication channels Each software environment is devoted to a specific community of stakeholders, organized as virtual workshops, called Software Shaping Workshops (SSW) A metaphor for conceptual design: artisan workshop (Not workshop as a people meeting) In the last few years we have developed a design methodology aimed at ….. The basic idea is that a software system is composed of a set of software environments, each devoted .to aspecific community of users, They exploit the metaphor of the artisan workshop, i.e. a lab, a work room where people find only the tools they need to carry out their activities. Sme people do not understand the word workshop since in the scientific community it means a short meeting of people, but we refer to the artisan workroom. This methodology appeared first in 2003, poi raffinata in , applied to difdferent case studies: in mechanical enginnering, in medicine, in geology, etc. And we always find it consistent with people needs. In its original formulation we did use use the term meta-design that Fisher later introduced, but meta-design was actually what we wer discussing about.

37 The software infrastructure
PROVIDES LANGUAGES to support each stakeholder in reasoning on the activities to be performed expressing her/his own view of the interaction process PROVIDES channels to support each stakeholder in communicating her/his view with the others during all the stages of the design & development &use process

38 Interactive system as SSW network
Meta-Design Level high low high low W-SE To Use level W-RReprX W-HCI To Use level Design Level Usability for end users Computational power … W-ReprX W-ReprY W-ReprZ W-ReprW Use Level … W-EU-X1 … W-EU-Z1 W-EU-X2 … W-EU-Z2 An interactive system is designed as a network of environments, called SSW The SSW network is organized in three different levels : at the bottom, the use level includes workshops that are used by end users to perform their activities the design level includes workshops for designing and adapting the application workshops in accordance with the evolving users and ssystem the meta-design level includes the system workshop for software engineers, which allows them to generate and maintain all the workshops in the network. But, and is a novelty in our case study with respect to previous domains, end users may perform meta-design, since they may design workshops that are modified by other people (indicare un percorso nella slide) The interaction languages in the SE workshop at the top level are characterized by high computational power (Turing Machine equivalent) but cannot in general be understood and managed by end users, i.e., they have low usability with respect to end users computational power decreases going from top to bottom level, while usability with respect to end users increases. … W-EU-Y1 … W-EU-W1 W-EU-Y2 … W-EU-W2 Each SSW provides only the tools to perform the desired activities

39 Turing Tar Pit Turing Tar Pit: “Beware of the Turing Tar Pit, in which everything is possible, but nothing of interest is easy.” Inverse of Turing Tar Pit: “Beware of the over-specialized systems, where operations are easy, but little of interest is possible.” [G. Fischer 2006] Designing a system as a network of environments, as suggested by the SSW methodology, avoids to design a system that is a TTP, where the user can do everything is possible but everything is difficult to do, too diffcult for end users. It also avoids the design of system that are the inverse of TTP, where operations are easy, but very difficult to generalize.

40 Case study A web application to support the CIDD activities
CIDD (Consorzio Italiano Distribuzione Dolciaria) is a consortium of Italian companies operating in confectionery field The application provides the consortium companies with several services price lists order management discounts …. to exchange information and cooperate through the Web First release of the application did not satisfy the CIDD manager He wanted to be more powerful, to shape companies Web pages Next release was developed with SSW methodology, to allow end users to be co-designers of their tools Our case study refers to the development of a web application to support the activities of a consortium of small and medium-sized Italian companies operating in the confectionery field, called CIDD (“Consorzio Italiano Distribuzione Dolciaria”). The application provides the consortium companies with several services such as price lists, discounts, order management, etc. and permits some of the consortium stakeholders to exchange information and cooperate through the Web

41 Three types of end users
Power user: sales manager (and his secretary) To visualize, insert, modify and delete workshop contents To define access rules To design workshops Associated companies: companies representatives To access contracts, catalogues, promotions, competitions To make orders To design workshops for their customers Registered guests: company customers, partners To access to specific contents Each type of user has different interests, responsibilities and skills, and performs different activities sales manager (and his secretary who works on his behalf): they use their workshop to… ..

42 The SSW network in the CIDD case study
Meta-Design Level high low high low SE To Use level SalesManager HCI To Use level Usability for end users Computational power Design Level … AssocRep1 AssocRepN Use Level … Assoc1 … AssocN Cust1.1 … Cust1.H The workshops in the architecture are of three types: Meta-design workshops support the software engineers in designing and evolving all the other workshops in the architecture, according to the requests of the different stakeholders. Interacting with SE workshop, software engineers perform their activities using programming languages and other development tools; they have high professional competence on software, low competence on domain activities. SalesManager and HCI workshops support the members of the design team in designing and evolving the application workshops. Such stakeholders have no (or little) competence in computer science; some of them have competence on HCI design, so that they can bring human factors in the system design; other stakeholders have competence on domain activities. Workshops at design level are devoted to team members using specialized interaction languages that have less computational power than the ones used by software engineers, in that they permit a limited set of operations. However, they are more usable for end users in that they can be correctly interpreted by the end users. Workshops at the use levl are devoted to end users to perform their activities in the real world. Interacting with application workshops, end users perform their well-defined set of activities using domain-oriented languages that reflect and empower their traditional notations. … Partner1 … PartnerN CustN.1 … CustN.K

43 SalesManager workshop
Through their system workshop at the top level of the network, software engineers design and develop a first release of the system workshops for different experts (in the case study, sales manager and representatives of associated companies). In this screen shot SalesManager workshop where the sales manager finds tools that allow him to design workshops for other end users Let us suppose that the sales manager wants to design the system workshop to be used by the representative of an associated company, also providing it with some services. He designs this workshop by direct manipulation. Specifically, he selects the company from a drop-down list available in the central area of his workshop, he selects a service from another lists and clicks on the association button to associate the service to that company in the resulting workshop, that is shown in the following slides. The sales manager designs the workshop for representatives of an associated company, providing it with some services. He selects the company from a list, a service from another lists and clicks on the association button to associate the service to that company

44 Workshop for associated company representatives
Communication area for exchanging messages in the network Services for the workshop users are on the left The company representative is creating the catalogue for a customer, that will appear in the customer workshop. He selects companies that provide products to the customer, indicating prices, % of revenues, etc. the workshop for the representatives of the selected company is created, shown in this slide. Nine services are available and they are listed in the left panel of the workshop. The slides actually shows a situation in which the user has selected a service from the left panel and the central area shows the tools available to the user for using that service. the associated company’s representatives use their workshop (shown in this screen shot) to design the workshops to be used by their customers (registered users). Here the user is defining the product catalogues for a customer, with prices and percentage of revenues, and how it can be visualized. The central area shows all companies that provide products to the customer and for each company, the user can specify the percentage of revenues, and also decides whether to show prices in the catalogue or not, by clicking on a radio button the user activity is specified through direct manipulation of the elements of the interaction language implemented in that workshop

45 SSWs permit to design and evolve a system through collaborative negotiations
The negotiation is based on the exchange along the SSW network of two types of messages: executable specifications of workshops (XML-based documents) annotations about these workshops A stakeholder designs or updates a workshop (e.g. sales manager) by using a domain specific language. His actions modify the executable specification that, when interpreted by the browser, generates the new workshop Software will increasingly be part of integrated, heterogeneous, and continuously developing infrastructures This means that the design, development, and use of software changes

46 SSWs permit to design and evolve a system through collaborative negotiations
The negotiation is based on the exchange along the SSW network of two types of messages: executable specifications of workshops (XML-based documents) annotations about these workshops A stakeholder designs or updates a workshop (e.g. sales manager) by using a domain specific language. His actions modify the executable specification that, when interpreted by the browser, generates the new workshop Software will increasingly be part of integrated, heterogeneous, and continuously developing infrastructures This means that the design, development, and use of software changes

47 Communication paths in the network
Communication path along which the exchanges of data and programs occur Exchange paths: among the workshops at the same level Request paths: concerned with the communications going from low levels to higher levels trigger the co-evolution process, carrying on the feedback from end users (requests for workshop modification or extension) Generation paths: represent the activity of using workshops at a high level to generate, modify or extend workshops to be used at the lower level new or evolved workshops are made available to lower levels along such generation paths In order to favor the co-evolution process, communication paths must be guaranteed among workshops. In this way, once the overall interactive system (all workshops of a network) is in use, the design team has the possibility to observe end user activities, the new usages of the system, the new procedures induced by the evolving organization. Thanks to the communication possibilities the network offers, the design team also receives end user complaints and suggestions about the workshops they interact with. On the basis of these observations, the design team updates the system and sometimes also the underlying software technologies. In this way, co-evolution is supported. At the use level, end users exchange data related with their current task, to achieve a common goal. At the design level, HCI experts and domain experts exchange data and programs specifying workshops. HCI experts and domain experts also communicate with software engineers when it is necessary to forge new tools for their activities. Moreover, requests for workshop modification or extension can be sent to the design level or to the meta-design level from the lower one. Finally, when new tools or workshops are created at high levels, they are made available to the lower ones.

48 Communication paths in the network
Exchange paths: among the workshops at the same level Request paths: concerned with the communications going from low levels to higher levels trigger the co-evolution process, carrying on the feedback from end users (requests for workshop modification or extension) Generation paths: represent the activity of using workshops at a high level to generate, modify or extend workshops to be used at the lower level new or evolved workshops are made available to lower levels along such generation paths In order to favor the co-evolution process, communication paths must be guaranteed among application and system workshops. In this way, once the overall interactive system (all workshops of a network) is in use, the design team has the possibility to observe end user activities, the new usages of the system, the new procedures induced by the evolving organization. Thanks to the communication possibilities the network offers, the design team also receives end user complaints and suggestions about the workshops they interact with. On the basis of these observations, the design team updates the system and sometimes also the underlying software technologies. In this way, co-evolution is supported. At the use level, end users exchange data related with their current task, to achieve a common goal. At the design level, HCI experts and domain experts exchange data and programs specifying workshops. HCI experts and domain experts also communicate with software engineers when it is necessary to forge new tools for their activities. Moreover, requests for workshop modification or extension can be sent to the design level or to the meta-design level from the lower one. Finally, when new tools or workshops are created at high levels, they are made available to the lower ones.

49 Communication paths in the network
Exchange paths: among the workshops at the same level Request paths: concerned with the communications going from low levels to higher levels trigger the co-evolution process, carrying on the feedback from end users (requests for workshop modification or extension) Generation paths: represent the activity of using system workshops at a high level to generate, modify or extend workshops to be used at the lower level new or evolved workshops are made available to lower levels along such generation paths In order to favor the co-evolution process, communication paths must be guaranteed among application and system workshops. In this way, once the overall interactive system (all workshops of a network) is in use, the design team has the possibility to observe end user activities, the new usages of the system, the new procedures induced by the evolving organization. Thanks to the communication possibilities the network offers, the design team also receives end user complaints and suggestions about the workshops they interact with. On the basis of these observations, the design team updates the system and sometimes also the underlying software technologies. In this way, co-evolution is supported. At the use level, end users exchange data related with their current task, to achieve a common goal. At the design level, HCI experts and domain experts exchange data and programs specifying workshops. HCI experts and domain experts also communicate with software engineers when it is necessary to forge new tools for their activities. Moreover, requests for workshop modification or extension can be sent to the design level or to the meta-design level from the lower one. Finally, when new tools or workshops are created at high levels, they are made available to the lower ones.

50 Una possibile realizzazione
Un sistema SSW può essere realizzato con diverse architetture: qui ne vediamo una sviluppata da una collaborazione Milano-Bari nell’ambito PCL. L’architettura richiede la definizione di tre linguaagi e viene istanziata interpretando un insieme di documenti scritti nei tre linguaggi che definiscono il profilo dell’utente, del suo ruolo nell’interazione e della piattaforma usata.

51 http(s) transport User
Per creare un’infrastruttura dalle caratteristiche volute: architettura comune ai singoli ambienti Browser client Client ricco, con interazione grafica, possibilità di annotazione ricorsiva, indicizzazione di annotazione e documenti HTTP request http(s) transport XML data Knowledge Management Engine Basato su ontologia di dominio. Espone servizi SOAP Interface Server-side systems Gestisce l’ inizializzazione del processo, la gestione dell’interazione e della base di conoscenza db1 db2 dbn

52 Descrivere il sistema a diversi livelli di astrazione

53 L’architettura comune
http(s) transport HTTP request XML data Server-side systems Browser client BANCO client-side application BANCO engine BANCO configuration specification ECMAScript call DOM Viewer user interface User Web Server BANCO server-side application IM2L TL LML Instantiation and Interaction Libraries (ECMAScript) XSLT Processor XSL rules L’architettura realizzata rispetto utilizza i linguaggi di specifica in particolare rispetto allo stato precedente i documenti IM2L sono realmente astratti rispetto alla rappresentazione del sistema interattivo e i processi di materializzazione e localizzazione su varie piattaforme e per diverse culture risultano meno costosi in termini di tempo e di interventi sul motore ECMAScript. La formalizzazione di un linguaggio di template libera l’architettura dai vincoli software di cui è stato già detto, rendendola portabile rispetto al software utilizzato per la visualizzazione. L’altra novità introdotta riguarda invece il BANCO Engine con l’utilizzo della tecnologia XSLT per la trasformazione dei documenti di configurazione, come già detto nell’architettura preesistente era il motore ECMAScript ad occuparsi della trasformazione nodo-per-nodo dei documenti, quest’operazione può essere però svolta in modo più efficiente, flessibile e portabile ricorrendo all’XSLT e definendo un set di regole di conversione in linguaggio XSL, indipendenti dal contenuto dei documenti di configurazione. 53

54 Il processo di materializzazione
Transformation Rules XSLT Localized Template XSL Template La materializzazione consiste nell’applicazione delle regole contenute nel documento di templating (TL) al W-Garden, ottenendo così un documento fruibile da un viewer. Anche per il processo di materializzazione sono definiti due passi consecutivi (vedi schema di dettaglio a destra): il primo per trasformare le regole di materializzazione in formato XSL e il secondo per l’elaborazione del documento finale da passare al viewer. IM2L document XSLT SVG Full DOM tree 54

55 Il processo di localizzazione
Transformation Rules XSLT LML document XSL Localization La localizzazione dei template viene eseguita qualora il profilo utente in uso sia associato ad una cultura differente da quella del progettista (nella fattispecie quella italiana). Il risultato del processo di localizzazione è un documento nel linguaggio di templating (TL), con le impostazioni della cultura adatta all’utente. Come si nota dallo schema di dettaglio di fianco, le elaborazioni XSLT necessitano di un primo passo per trasformare il documento TL in formato XSL (utilizzando un altro XSL “di sistema”), quindi si esegue la localizzazione vera e propria, applicando al documento LML le regole di trasformazione ottenute dal primo passo. TL document XSLT Localized Template 55

56 Future scenario for Software
Recent projects describe a future scenario for software systems Software will increasingly be part of integrated, heterogeneous, and continuously developing infrastructures End users will actively change the tools they work with and orchestrate different services as building blocks to provide the functionality they need In cases where the required functionality cannot be obtained by simple tailoring, they will communicate and cooperate with local and other professional designers who in turn might call upon a network of peers or developers of the base products and frameworks used New languages and new architectures are arising to respond to this evolution Some recent projects describe a future scenario for software systems Software will increasingly be part of integrated, heterogeneous, and continuously developing infrastructures This means that the design, development, and use of software changes

57 References Arias E. et al. (2000), Transcending the Individual Human Mind—Creating Shared Understanding through Collaborative Design-, ACM TOCHI, Vol. 7, No. 1, March 2000, Pages 84–113. Bagnasco 2002: Bagnasco Gianni, G. (ed.) Cerveteri. Importazioni e contesti nelle necropoli, Quaderni di Acme, 52. Bologna 2002 Bonghi Jovino, M. (ed.). Tarchna series, I-III, L’Erma di Bretschneider (Roma) Mussio P. et al.,, Visual Interactive Systems for End-User Development: a Model-based Design Methodology,. to appear IEEE TSMC, available TR LACAM Rittel, H Second generation design methods. In Developments in Design Methodology John Wiley and Sons, Inc., New York, NY, 317–327. Schŏn, D Designing as reflective conversation with the materials of a design situation. Knowl.-Based Syst. J. 5, 1, 3–14. Shneiderman, B. (2002). Leonardo's Laptop: Human Needs and the New Computing Technologies, MIT Press. Snow, C. P The Two Cultures. C. P. Cambridge University Press, New York, NY. Wulf,W., Panel position, Bridging Art and Science with creativity support tools,CC2007, June 13, Washington. Bruns, A., Blogs, wikipedia, second life, and beyond: from production to produsage ,Peter Lang, New York, 2008 SCHÖN, D Designing as reflective conversation with the materials of a design situation. Knowl.-Based Syst. J. 5, 1, 3–14. Costabile, M.F., Fogli, D., Fresta, G., Mussio, P., Piccinno, A. Computer Environments for Improving End-User Accessibility. LNCS, Volume 2615, Springer-Verlag, pp , 200 M.F. Costabile, D. Fogli, P. Mussio, A. Piccinno. End-User Development: the Software Shaping Workshop Approach. In H. Lieberman, F. Paternò, V. Wulf (Eds), “End User Development”, Springer, pp M.F. Costabile, D. Fogli, P. Mussio, A. Piccinno. Visual Interactive Systems for End-User Development: a Model-based Design Methodology”, IEEE Trans. SMC - Part A: Systems and Humans, Volume 37, No. 6, 2007, pp