Ceci est une ancienne révision du document !

Table des matières

Business Model Designer From Sticky Note To Screen Interaction

Master of Science in Information Systems

Boris Fritscher

Supervised by Prof. Yves Pigneur and by Prof. Thibault Estier

December 2008


Business model innovation is getting more and more traction and there are new methodologies to help identify new business models, unfortunately tools to assist in this task are scarce. The difficulty is to have an application which respects all the constraints imposed by the methodology, without infringing onto the creative thought process. This project focused on a very intuitive paper based methodology and reproduced it with a digital artifact. The design focus is set on creating a very intuitive visual prototype. This document traces the design choices and results obtained, tracing the steps from brainstorming the prototype to its final testing. Strongly related to design process of such an application are the technical choices of working with complex data structures, therefore a secondary objective covering the impact of requirements changes on the evolution of future iterations is also discussed.


I would like to thank Yves Pigneur and Thibault Estier for supervising this master thesis and always having their doors open for me. This work has benefited from many insightful discussions we had this past semester.

Alexander Osterwalder thanks for providing real world examples of business models. Your optimism and comments have always motivated me to push farther.

Particular thanks go also to all individuals who helped test the prototypes and provided invaluable feedback.

Chapter 4 The Technology Behind

In this chapter we cover the technical details of the prototypes and explain the technical choices made. The presentation of the technical and architectural aspects of the prototypes is followed by the limitation discovered during development and also an overview of different alternatives which could have been chosen.

A quick reminder of the challenges presented by this software:

  • A dynamic user interface supporting drag and drop interaction between most of its elements.
  • A complex data structure in which each element depends on the others.
  • The possibility to change attributes of an element or event to add new types of elements as the tool and the underlying model it has to support evolves.
  • Provide the possibility of a future integration of additional modules or tools which could provide statistical, financial or other data to different elements.
  • Provide extension to further analyze a business model by comparing it to other models, applying patterns or evaluate it with a survey.
Figure 4.1: Overview of both prototype’s architecture

4.1 Prototype 1

4.1.1 Architecture

The data structure has been created in MySQL. Then the data itself was quickly input through a web page built with CakePHP and its powerful scaffolding feature. The remainder of the code uses the predefined database access methods and conventions provided by the framework to generate HTML/CSS pages as well as XML call endpoints for the JavaScript queries. Most of the dynamic functionality is done via JavaScript with libraries like [http://extjs.com/|ext js]] and script.aculo.us who call the aforementioned endpoints.

The data structure can be seen in figure 4.229Prototype 1 database schemafigure.4.2. Product is the first name given to the layer feature before it was identified as such. Also in this version of the prototype there is a table for the building block, this allows for renaming of the blocks and provides the possibility to add new blocks for further evolutions of the model. This possibility has been replaced in the second prototype by the fact that a block is defined as an aggregation of sub classes of elements.

Figure 4.2: Prototype 1 database schema


A modern MVC framework can largely reduce the number of lines of code that have to be written, mainly conventional code which can be replaced by naming and usage conventions.

The fact that the HTML structure has to be altered through DOM each time new information is received is not near to the business object model. It is therefore a better solution to create these graphical elements through helper widgets in JavaScript like some JavaScript libraries provide.

However, the use of JavaScript especially the combination of different effects quickly renders the code un-maintainable. Patterns should therefore be applied to avoid problems especially with dynamic language like JavaScript. Otherwise, existing code will become very difficult to be debugged or altered.

In this prototype, there is no separation of concerns between client and server, but its rapid development has allowed to generate new ideas for a future version and also proved the feasibility of such a tool.

4.2 Prototype 2

4.2.1 Intention

The first prototype has a data structure created for a relational database, for this second prototype the goal was to try a more object oriented solution. Also, since the prototype was to be recreated from the ground up, an implementation of a separation of concern between client and server was tried. For the client side the choice was to find an alternative for not having to manage the low level technical details that are required when doing HTML/CSS/JavaScript coding.

4.2.2 Architecture

In this version, the client is a flash application loading and saving data from a server. The server is a Java application server that persist the data to a database. The client and the server share a domain class object model of the BMO, which is close to the real model.


As with the previous prototype, the choice was to use a framework which uses convention over code to facilitate integration of Java Enterprise products like Spring and Hibernate without losing too much time in initial configuration. In this case the choice was Grails , like other framework of its kind (RubyOnRails, Django), it is build around the MVC pattern and uses strongly the specificities of the dynamic language which it is built on. Grails is programmed in Groovy, which provides the advantage that it does execute in the Java Virtual Machine. This way the proven enterprise products and their APIs which are available to the Java Language can be relayed upon.

Grails allows defining domain classes and their relationships between each other, its Object Relational Mapping engine (GORM) will then take care of doing the proper mapping to Hibernate. This allows to persist and retrieve the objects without having to write custom SQL queries, and reduces time and coding when working with persistent data. Appendix C.185Prototype 2 server domain classes and attributesfigure.C.1 contains a figure of the domain classes with their attributes and relationships.

There is also a plugin that allows transformation of methods into RPC services for Flex, this by automatically configuring object conversion through BlazeDS’s Java API. This part takes care of transforming the Java object into an ActionScript object and vis versa.


Having already prior knowledge of Flex, the idea was to be able to work directly with the objects received from the server. Flex also has a large number of visual components that facilitated the creation of interfaces. Therefore, it seemed that it would be a good alternative to the combination of HTML/CSS/JavaScript. In addition with the support system provided on the server side, the configuration of the remoting access points is largely simplified.

Flex also has a system of databinding and proxy on collections which facilitates the real-time modification and filtering of data without having to be concerned with the display objects. On the other hand to avoid passing references to the data between the different visual elements, it is advisable to use some patterns (singleton for the data model holder, events, commands and controllers). Adobe offers an additional library called Cairngorm to address this problem. For a more detailed structure of the client see appendix ??.

4.3 Features Details and Choices

In this next section are covered some of the implementations and the reason behind their choices.

4.3.1 User System Implementation Possibilities

Table 4.132Comparison of user management systemstable.4.1 displays four alternatives systems which can be used to implement user management. Scenarios range from simple to complex in their feature spread and implementation difficulty.

Simple Profile tableheaderSharing Collaboration tableheader Stateless Stateful tableheader User logs in to access his BMs User logs in to access his BMs User logs in to access his BMs User logs in to access his BMs No sharing (only uncontrolled through using same account twice) User can share his BM with other users User can share his BM with other users User can share his BM with other users Two users editing the same document will result in unknown behavior Two users editing the same document is impossible due to a lock system Edits on a BM will be sent to all other views connecting to the same BM Like: Desktop application profile, computer login Like: - Like: wiki, file access Like: google docs, chat Impact: a BM belongs to a user Impact: a BM has many users Impact: a BM has many users, a user can get a lock on a BM for editing Impact: a BM has many users, publish/subscribe messaging model, a message for each action Use case: used like an application, works in group if looking at one screen Use case: Use as central place for BM, sharing mainly usable for viewing A BM should have only one User with write permissions to minimize errors Use case: same as stateless, but multiple users can have write permissions due to lock security Use case: Online collaboration, without needing additional desktop sharing software except voice/chat comm. Message bus could be used to connect other editing views Table 4.1: Comparison of user management systems
Options ACL user and BM relation can be augmented with permissions (view, edit),groups. Components under the BM can be tracked separately (track annotations to a specific user, last edit on object by…) Table 4.2: Options available for sharing and collaboration systems

Since the user system was only added in the last iteration of the project only the simple stateless sharing options has been chosen. The choice was more about the ability to clean up the listing of the front page, which was becoming quite long, than to offer new possibilities. But because the model had already an edit and a view mode adding different permission was an easy task and has been implemented. Comment tracking was not implemented since it would have required too much code changes. Instead, a user can simply add his name to the comment itself if he wants to identify himself.

4.3.2 Snapshot and Merging

Snapshot is implemented using a somewhat controversial borderline effect produced by the conversion of java objects into ActionScript. If when mapping the java object to their ActionScript version the version and id attributes are omitted, and then the objects are sent back to the server to be saved, the whole graph gets saved as a new object by the ORM system. This enables to create recursive deep copies of the objects without having to code anything. The disadvantage being that the snapshot cannot be produced only on the server side, but has to roundtrip through the client.

Merging also occurs on the client side for the same reasons, except that the client asks for multiple models and joins them into one before sending it back to the server for saving.

4.3.3 Example Roundtrip of a Query

For this example, let’s take the action of creating a link between two elements. The action is decomposed into different events: first there is the drag operation, then the hover and the drop who will initiate an interaction with the server. Once the server responds, this will in turn initiate some actions on the client configuring the right data to be able to display the newly created link. For a more detailed description see figure and explanation in appendix C.382Detailed Example Roundtrip of a Querysection.C.3.

4.4 Problems Encountered

4.4.1 Prototype 1

JavaScript libraries: there is no single library which can do everything, each has its own methods, but between them there are many redundancies.

The successive nesting of JavaScript effects makes the maintainability of the code very difficult.

The common problem of schema evolution when using relational database cannot be avoided even when using framework that generates most of the SQL code. When transforming schema with existing data in it, the cumbersome operations of manually extracting, converting and importing has still to be done.

4.4.2 Prototype 2

The choice to move to a more object oriented data structure has made the structure closer to the real representation of the model, but not necessarily simplified the project, mainly due to all the looping dependencies between elements. This adds complexity saving the data and also exchanging it between the client and the server. The implementation used requires to send a complete object graph with all its dependencies to the client. In addition, the client has to have corresponding domain classes to the server’s, thereby creating a strong dependency between the client implementation and the server’s. In the end, the possibilities to navigate from one object to another through their object relationships comes at a high cost, perhaps an other solution using REST services and xml data structure (source) would have been better.

On the server side some beginner mistakes have created some problems. For example choosing the enum data type to represent some of the element’s attributes is very limiting and not flexible for future changes. A better solution would have been to create a modifiable list or just store the information in a text field and let the client side impose some restrictions in the user interface. During deployment of the server to a real database, some of the chosen attribute names where too generic and therefore were in conflict with reserved words of the database language. It is advised to not use generic words like for example type or date for future naming of attributes.

The client implementation posed not so much problems except its complexity of numerous events firing at the same time or in a chained way. But the debugging possibilities offered by flex are very good and helped in identifying bugs rapidly. The greatest workaround that had to be done is a custom implementation of the double click since for some odd reason on touch devices the existing implementation is too restrictive to detect a double click on an approximate location.

4.5 Tradeoffs

4.5.1 Web vs Desktop

Web applications and desktop applications both have their advantages and disadvantages. Most of the time, the advantages of one are the disadvantages of the other. A short overview of some respective advantages is given in table 4.335Advantages of the Web and the Desktop over each othertable.4.3. It is also noteworthy that the separation between web and desktop application is blurring. There exists on the one hand technologies to bring web applications to the desktop, and on the other hand features of web applications are directly integrated into desktop applications. For example, there is respectively the possibility to use Google docs in an offline mode, or to have Microsoft Office Live directly integrated into the Microsoft Office desktop applications.

Web [advantages] Desktop (standalone) [advantages] Multiplatform Offline work Without installation Response time (no delay between client-server) Always up to date Possibility to use older versions Social sharing Interaction with the desktop (D&D) Automated backup (server-side) Privacy Table 4.3: Advantages of the Web and the Desktop over each other

4.5.2 Client-Server

In a client-server architecture there is always the question on which side to put the business logic. In order to support a large number of clients, it is advisable to keep the states and most part of the logic on the client side. The server’s role is limited to persisting and synchronizing the client’s data. However, unlike when the business logic is centralized on the server, all different clients have to be updated individually whenever changes occur.

One advantage of putting the logic on the client side is to leave the opportunity open to allow, in a future version, to work in an offline mode.

4.6 Framework

As experienced with the two prototypes, the new kind of web framework can help accelerate the creation of web applications by replacing many lines of code through convention. Moreover, these conventions require a fairly clean architecture. This makes the code reusable and easier to evolve from. Nevertheless, the conventions have still to be learnt when being used for the first time, a hurdle which has to be crossed before being productive.

Certain limitations linked to the conventions have to be taken into account, but if the framework is mature enough, there are few exceptions which do not already have a documented workaround. A good framework should also allow direct access to its underlying components to be able to circumvent these limitations.

4.7 Data Persistence

In my opinion it seems that the key part to allow an application to evolve freely is to find an optimal compromise concerning data persistence.

4.7.1 Traditional Methods

Object serialization: allows simple saving of a graph of objects, but does not allow easy retrieval of only parts of it, plus it prevents the evolution of objects.

Relational database: provides a good way to store data, but is heavily dependent on its schema.

Object Relational Mapping: allows storing objects in a relational database in order to level the limitations of serialization, but the limitations of the relational database remains. In addition, there is the added complexity of mapping the objects to tables.

Schema evolution: In an attempt to solve the limitation of schema evolution, there exist solutions of change tracking and migration of schema like liquidebase. Efficiency of such solutions has yet to be proven.

4.7.2 Non-conventional methods

Google AppEngine: Is the new python based Cloud Computing solution offered by Google. In my opinion the services is, at the moment, not evolved enough to handle the client side application’s needs. Nevertheless, the datastore API has some interesting features for a server side. The data is represented by classes, but unlike with ORM, storage is not done in relational databases. In addition to standard class attributes the systems also allows for dynamic defined attributes, thereby the schema could evolve. From the start the system is design to be scalable, which in itself is a positive point, in this first version it does however not allow for joins when executing a query. Therefore there is no way to take advantage of the knowledge acquired on relational databases.

CouchDB: Is a prototype of a new type of data store specially design for web applications. It is based on the JSON data model which is used by more and more websites for their data transfers.

Recently the project has gotten support from the Apache Software Foundation, the project defines itself as: distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. What I find of particular interest is the fact that it is schema free and that it could be access directly from the client without having to through a backend server.

F2 Python DBMS: prototype of a schema less database, the data defines the schema. If there were a JDBC driver to connect it with hibernate it could be a solution that could even work with a framework like Grails

Jena & SPARQL: Another idea is to use a semantic solution and store the data directly in the owl file which defines the structure. A Java server using the Jena API could store the data and queries could be done in SPARQL on the triplet store. This solution would need some testing, but I am not convinced of its scalability, as well as the technical difficulties it involves.

Generic database: A relational database could also be used in a more abstract way, creating only tables for meta objects with which the needed object can be constructed. For accessing data as with a normal schema, there could be views which assemble the required information, but the problem is for storing new data, on the server side there will have to be quite a lot of code to decompose each information into its basic parts which then can be stored in this generic system which would not need to be changed. The evolution problems is in this solution transferred from the database schema to the application implementation which has to manage the decomposition of the information before saving it, taking away development time of business code, but giving the opportunity to quickly change the business items themselves.

4.8 Other technologies

4.8.1 Clients

Silverlight: Microsoft has developed their own alternative to Adobe’s Flash/Flex, but judging by some small tests their product is not mature enough to allow for a rapid development. In addition, other than giving access to the .Net framework it has for now, no special functionalities over its alternatives.

Google Web Toolkit: GWT is a very promising technology which allows the creation of HTML/JavaScript based client applications written entirely in Java. Google’s compiler takes care of generating the necessary changes. This solution has the major advantage to ease debugging, and imposes stronger controls at compilation time instead of runtime, mainly due to the usage of Java which is a static typed language unlike JavaScript. At the moment, the main effort is focused on the compiler technology. There are still high level features or a nice framework missing, which would allow for developer friendly usage without having to create a lot of classes to build simple operations.

4.8.2 Offline

Google Gears: Gears is a plug-in for the web browser that extends the possibility of JavaScript to provide offline solution for dynamic web pages. This way entire web application can be made available offline. Choosing this solution implies that the business logic will have to be on the client side.

Adobe Air: Is a solution that enables to program for the desktop using web technologies like HTML/JavaScript and Flex/Flash. Like with gears this allows to create offline web applications, but unfortunately there is no synchronization mechanism to go back online. Another difference is that being in a dedicated standalone container the application, contrary to web applications hosted in a browser, can interact with files from the desktop and the drag and drop operations of the operating system.

As in the last Firefox version, both Google Gears and Adobe Air rest on a local SQLite database to guarantee persistence.


The separation of concern between client and server and especially the usage of framework and their patterns requires an extra investment in time, but should prove to be more flexible for future changes and improvements. The modular structure of the frameworks used for the second prototype will easily allow adding custom sub modules, different clients and more attributes. But changes in the domain class objects will always require changes in the client and server side, a more xml/services API oriented solution would have limited this problem. Also the deletion or modification of existing data structure is still a hard problem. Nonetheless, continuing to pay attention to problems emerging from future evolutions of the prototype can still bring insightful knowledge for further research.

From the overview emerges the observation that web application or desktop application, for the most part relay on a relational database to guarantee the persistence of their data. There is also a trend of standardization of methodologies across the languages, temporary trend or ongoing optimization has still to be seen, but one certain thing is the convergence between web and desktop.

The question, if in this world of complexity, change and reuse of services, the relational database still is a good solution to guarantee data structure and persistence, remains.

Chapter 5 Validating The Prototype

For a couple of reasons, user interaction and feedback during development of the application was not very extensive. Naturally, there were time constrains, but the priority was also set on doing quick iterations to allow testing of new features. In addition, to be able to use the application a prior knowledge of the model is required. Therefore, for the first version only feedback from experts was possible. Even if the interactions are heavily inspired by the physical usage of sticky notes, there are new ways to interact with the application. Some of these have to be learned. Testing them too early when the whole system isn’t complete might make them get strongly rejected by users which are not in the habit of using them.

In the end, having made important design choices with limited user feedback, while creating the application, strengthens the need for testing usability as well as usefulness.

For the usability part, the questions are:

  • Will the user perceive the application as a web based page or interact with it like a desktop application?
  • Do the defined actions, menu labels, highlights have enough affordance to allow usage without having to read the complete manual?
  • Is the paradigm of the sticky note interactions still visible? And is it useful for people who did not use the paper based methodology?
  • Can the application be used on small screen as well as big screens?

Since we transformed and augmented a manual process into a digital one, the question about complexity and usefulness are also very prominent:

  • Is it as easy as with sticky notes?
  • Does the additional meta-information add sufficient value to be useful?
  • Can the tool support and help collaboration?
  • Can the tool stimulate the same thinking in a brainstorming session as does the paper based version?
  • How does the persistence and versioning affect new alternatives?

5.1 Testing Methodology

To allow for testing without needing the user to study the handbook, or become an expert of the model, testing was done using the walkthrough methodology.

A quick introduction to BMO was given as well as a fifteen minute demonstration of the tool. After which, the user was asked to perform different operations and his actions were carefully observed. When he was blocked or performed strange operations the tester asked for the reasoning and gave advice on how to continue. Participants were also encouraged to give feedback on ideas, expected interactions and other comments.

For all the following tests the premise is that the user knows at least the basics about BMO. The actions of creating an account or connecting to it are not tested.

5.2 Data Entry Test

5.2.1 Scenario 1

The business model is already defined. It only has to be input into the application to allow tracking of its evolution and allow annotation and detailed description of its elements. (SuperToast, Apple)


  1. Create a new empty business model
  2. Add desired elements and layers
  3. Move elements, inside and between blocks
  4. Create links between strongly depended elements
  5. Display the links

5.2.2 Scenario 2

A business model is already created in the system. A new alternative or evolution has to be added. (Amazon: classic and S3, Apple: iPod and iTunes)


  1. Open the business model that has to be edited.
  2. Add new layers and elements, and add existing elements to new layers as needed to represent the new aspect of the business model.

Alternative 1

  1. Create a new empty business model containing only the new parts.
  2. Merge the new business model with the initial model.
  3. Edit the duplicate elements.

Alternative 2

  1. Work with the snapshot manager to create alternatives.

Problem: the two alternatives are not visible at the same time.

5.3 Annotation Test

5.3.1 Scenario 3

Evaluate an existing business model by using annotations or answering to assessment questions.

Alternative (Direct)

  1. Add annotations directly to the model, the perspectives or the blocks
  2. Edit the annotations (change text, type)
  3. Filter annotations
  4. Delete annotations

Alternative (Wizard)

  1. Open the wizard
  2. Choose a question set either assessments or innovation.
  3. Answer some of the question, edit business model as needed.
  4. Add custom annotations.

5.4 Feedbacks

The three scenarios and other small interactions have been tested with multiple users on the final prototype during the month of September 2008. They all had knowledge of BMO ranging from novice to intermediate. Computer knowledge for the majority was intermediate, except for one who was an expert (see table 5.144User summarytable.5.1 for a summary).

User BMO knowledge Computer knowledge Tested Scenario Assistant Intermediate Expert 1,2 and 3 Assistant Intermediate Intermediate 3 Assistant Intermediate Intermediate 1 and 2 Assistant Intermediate Intermediate 3 Consultant and a developer Intermediate Expert Defining a new Business Model and exploring future alternatives Professor Expert Expert Miscellaneous Observations Student group Novice Intermediate On TouchWall develop a new model Consultant Expert Intermediate On TouchWall wizard, annotations and some editing Table 5.1: User summary

Globally feedback was positive. The testers managed to use the prototype without having too much trouble identifying the right action for their intensions. On the usefulness side of things, there were no real test, but the general opinion is that the reporting features as well as the versioning and layers features may certainly help in providing value over the paper based static solution.

Interestingly, users with greater knowledge of the model or who had more expertise in IT identified more defect in usability, and users with less experience were looking for features that were not available (usefulness). This combination of testers allowed identifying possible usability inconsistencies and also generating ideas for new features.

In the following section are analyzed mostly actions that were not providing the expected results, since covering the success of common actions like drag and drop or clicking a simple link seems to be pointless. Moreover, failures due to clearly identifiable bugs of coding and not choices of usability have not been taken in account and will simply be corrected in a new revision of the prototype.

5.4.1 Usability

An example of a bug that also influenced usability for a user was list highlighting which had not been turned off. Thereby, sometimes an element would get highlighted with a blue background without having any meaning or functionality. In this case, the user was informed not to pay attention to the artefact and testing was able to continue without interference of the bug.


Clicking on an empty space inside the menu or perspective border toggles the appearance of the zone by resizing it. In collapsed form even the title of the perspective is hidden to maximize available space for the visible elements.


  • The toggle border for the menu is too hard to identify.
  • For novice user of the model hiding the perspective’s title is disturbing.
  • Wrongly collapsing a perspective can happen because target zone is every empty space.
  • A feedback indicating that the toggling will happen if clicked was expected.


Limit the toggle interactions to the title of the perspective. Display the title of the perspective also in collapsed mode. Generate a feedback on hover by changing the cursor or font of the title to highlight the possibility of an action.

5.4.3 Drag and Drop


Drag and drop elements, from one place to the other or into the trash can.


There were no problem drag and dropping elements. Some concern was expressed concerning the ability to delete a whole layer with all its elements without warning.


Since the trash can permanently delete’s the object that is released onto it, it could be wise to ask for confirmation when the action has serious repercussions like when deleting a layer. Additionally, the dialog box could propose to take a snapshot before deletion.

It should also be taken into consideration to change the artifact’s image. A document shredder would perhaps be a better metaphor than the trash can based on the knowledge that ’Visual metaphors leverage real-world knowledge of objects, but metaphors that are very literal may introduce information that is irrelevant or misleading to a task’ Rosson and Carroll, 2002, Tradeoff 4.7 p. 129]

5.4.4 Click Interaction and Menu


Clicking on an element displays a menu to view details, display links or change layers.

Double-clicking an element filters on the selected elements and displays its links.

Double-clicking an empty space in the building block (list of elements), creates a new element in this block or when displaying links switches back to normal view mode.


It is unclear if the double affectation of double-clicking a block is used. Quitting the link view was mostly done by clicking on the message bar, which also provides this functionality. There were also no attempts to create a new element in the link mode, although the creation of new elements by double-clicking in the normal mode was intuitive for everyone.

The biggest problem was the expectation from the action of double clicking an element. Every user novice or expert expected to display the detail window and not to display its links. Also since renaming an element can only be performed from the detail window, in contrast to prior prototypes where it could be done directly on an element generated some hindrance in the usage flow.

Advanced user had trouble with the fact that there are no right click possibilities, this indicates for one that even thought the application was running inside the browser it was perceived as a desktop application. Furthermore, these users were also more disturbed by the small delay there exist between clicking an element and the menu being displayed.

Some user did not know what action to expect behind the link menu, if it would create a link or display them.


Some of the failure in usability observed in the mentioned click interactions can be traced back to the merging of the two modes create and link that were used in the first iteration of the second prototype. In hindsight, obviously the wrong interaction was favored for the double click action. This merger also removed the possibility to rename an element directly by simple click in favor of a menu. This menu although not optimal, is a necessity since we cannot use right click or any other interaction that would not be available across the multiple devices on which the application should be able to run. If there were to be special version for each input device the menu delay could be reduced and different actions could be chosen, the tradeoff being to lose consistency of use between inputs.


Change the action occurring when double-clicking an element to displaying the detail window. Try to reduce the delay of the menu appearing. Rename the label of the menu entry from link to something more explicit like view links. Try if adding a rename option in the menu with the possibility to directly rename the element without displaying the detail window can increase the flow in the model creation phase.


Creating links by dragging one element over another in a different block if the model permits a relationship between these two blocks.

Deleting a link by drag and dropping a highlighted link onto the trash can symbol.


Link creation is well understood. After creation everyone does display the link he created.

One user thought that the highlighted link meant that a menu would appear if clicked, and not that it is ready to be dragged.


Automatically display the created link after creation, currently the model refreshes and does not filter on the newly created link.

Perhaps find an alternate way to delete links than to have to get them highlighted and then dragged onto the trash can.

In the current version there is no way to know if an element is linked except to display his links, perhaps some sort of highlight in the normal view mode could be of use.

5.4.6 Detail Dialog


Edit attribute fields and close the dialog with the x in the upper right to save changes.


Most of the users were looking for a close/save button or typed enter to validate/confirm changes.

An advanced user wanted to interact with the listed links that are read-only.


Add a button to close the dialog. Perhaps to resolve problem with the link selection from previous case add possibility to edit links from this dialog as well as directly dragging the displayed links.

In the current version of the prototype the general purpose detail dialog does suffice and adds consistency, but in future iterations with more specialized need for each block, a different approach will have to be chosen to provide desired functionalities. Rosson and Carroll, 2002, Tradeoff 3.3 p. 84]

5.4.7 Layers


A layer can be renamed by clicking its name.

Double clicking a border creates a new layer.

Visible layers define to which layers a newly created elements belongs.


Average users intuitively found the click to rename functionality, but had problems using the double click to create a new layer action.

Basic users didn’t really understand the layer selection and element creation dependence and the expert user was bother by it. He was expecting to have two types of selection one for dependence attribution and one for visibility like it is the case in design products from Adobe.

It is true that hiding layers for not getting their reference when creating new alternatives is disturbing because of the inability to see what has already been added to the model.


Add a button, menu or increase the zone that enables the creation of a new layer.

Make visibility, and layer dependence for new elements two separate options. Either by adding a second selection column or by selecting the layers in the new element dialog. Still it is a good idea to keep in mind that ’Displaying all active task entities enhances understanding and feelings of control, but each display elements adds to the complexity of the user design’ Rosson and Carroll, 2002, Tradeoff 4.1 p. 115]

5.4.8 Annotations


Toggle new annotation pane by clicking on an empty space. If there are no annotations the pane is displayed, otherwise it is hidden by default.

Filter displayed annotations by type or level if they are to-dos. The range can be defined by moving both sliders.

Double click an annotation to edit it.


When looking at the annotations, many users did not find the answer annotations, because they are by default filtered. This can be related to ’Dynamic hiding of controls that are not in use conserves space and simplifies the display, but also conceals the controls’ affordances from the user’ Rosson and Carroll, 2002, Tradeoff 4.5 p. 125]

Most of the users expected to be able to click on an annotation to edit it, instead of having to double click it.

One tester was confused when creating a new annotation and mixed-up between the filter checkboxes and the drop down selection to specify the type of the new annotation.

When using the range filter for the first time it is unclear to most users that both sliders can be moved, but once the interaction is shown it is well understood.

One particular user imagined a correlation between visible layers and annotations displayed, which is not the case. This same user also wanted to be able to drag and drop annotations from one window to another.


It seems that hiding information is misleading and even if at start the screen is a bit cluttered, it would be better to display all annotations as well as the new annotation pane, and then let the user hide the elements he does not want to be displayed.

The range sliders is a new concept not seen in daily usage of computers, therefore showing a simple help information at first runtime could help to train the new users.

It would be interesting to study the usefulness of a possibility to drag and drop annotations, for now the same result can be achieved by copy pasting the old text into a new annotation.

5.4.9 Wizard


Answer or comment a question to keep track of the thought process.


There was a mix-up between a question’s answer and creating new element as a response in the block displayed underneath.


Give the possibility to create a new element from a selected portion of the answer. Or perhaps change the placement of the block and the questions.

Although the wizard can guide novice user to identify missing elements and provide assessments question for more advanced users, a more open view should always be provided. This because ’Decomposing complex plans into chunks aids learning and application of action plans, but the sequence may create arbitrary or unnatural step boundaries.’ Rosson and Carroll, 2002, Tradeoff 5.5 p. 166]

5.5 Touch Interactions

To see if the prototype is useable and could be useful on a projected wall, this mainly in the intent to be as near as possible to the original sticky note experience, it was first tested on Tablet PC. Tablet PC gives the user the same display size as the normal screen experience, but instead of using a mouse the user can directly manipulate the objects on screen with a pen. This first experience revealed that most of the action are working as well as with the mouse, or even easier for some drag and drop operations. Naturally since the keyboard is still available it is the preferred input method for text, even if handwriting recognition is available. As explained in the technical chapter, early on such a test revealed that click interactions are somewhat imprecise and have to be taken into consideration for detecting the double click actions.

The next step was to test the prototype on a real big screen solution. It was choosen to augment a normal projector with the e-Beam1 interact solution to test the application. The setup can be seen in figure 5.152Prototype 2 projected onto a wall and eBeam interact as pointerfigure.5.1. This solution acts as a single touch cursor that can be calibrated over any flat surface onto which can be projected with a beamer. The idea was to test not only usability, but also to see how working with a projected solution would compare to the paper based system concerning group interactions, brainstorming possibilities and other design aspects. Unfortunately, during testing mostly usability problems were observed and there was not enough time to see the real impact on the usage side. Further testing with expert users and a greater time allocation is needed.

Figure 5.1: Prototype 2 projected onto a wall and eBeam interact as pointer

As for the usability, it has become clear that touch solution are even more approximate for registering clicks and pointer location. For example, involuntary perspective collapse occurred frequently due to unintentional clicking on empty space of a perspective. Link selection was nearly impossible since the highlighting of a link is required and occurs only if the cursor is exactly over it.

First, text input was done through on screen handwriting recognition, which worked great, but was very slow. On screen keyboard is as well slow since keys have to be pushed one at a time. During testing these were abandoned in favor of entering the text directly on the laptop keyboard. This would suggest that for easiest usage a small wireless keyboard would be the optimal solution. Other possible solutions that could be tested would be mobile devices input via Bluetooth, or even voice recognition.

Bigger screen does not necessarily mean more space. In fact, screen resolution had to be turned down to eliminate some font size issues. During this testing it was the first time that users complained about the vertical text that is used for the wizard panes. This could be related to the font size problem.

In our temporary setup projection was done from the front which generated lots of shadows when people were trying to touch the wall. This had an impact on the number of persons that could be in front at the same time and limits testing of large group interactions. It would be ideal to find a better projection setup for further testing of interactions on the wall.

5.6 Usefulness

Usefulness was not tested with a statistical comparison between different methods and by defining meaningful metrics. The current prototype is more a proof of concept. Its usefulness was judged by the reactions and the interest of the participants and also by their eagerness of proposing new features.

One session which was very encouraging was done with an outside consultant comparing his model to ours. He was very interested by the possibility to generate a report from the acquired information, and would be delighted to see more detailed information in it. The parts that are missing from the BMO like environment and competitors can still be put onto our representation by using the annotation features. Also the layers proved to be very useful to input alternative evolution scenarios.

The introduction of annotations is certainly a useful feature judging by the interest it generated. One participant who has some experience with collaborative tools was especially interested to see the dates of annotation and changes since his last visit. This strengthens the fact that for a next iteration it would be interesting to explore more in deep the possibility of online collaborative features.

Even if mostly every element can be commented on, some tester wanted even more possibilities like annotating links, or to flag an element for later review directly on the element itself without creating an annotation on the block or adding a comment in the element’s description. In my opinion, adding too much visual flags could overload the model and take away its efficiency given by its simple visual layout.

The choice to let the layering system be as generic as possible has paid out. As predicted, people had different approaches to take advantage of the layering system. Some people prefer to use it to model evolution scenarios, while others identified different parts of their model with it. For example, in the case of a multisided business model, a user made the choice to separate upstream and downstream customers in different layers. The ability to use layers to model evolution does on short term testing limit the usage of the more advanced versioning possibilities, but it is clear that the possibility to freeze a state of a model in time and track the relations between states is also necessary as a long term alternative.

Merging has first been seen as a way to compare two BMO, but in the end is even more useful. It can be used to make a copy of a model by only merging one model. It can be used to merge more than two models. And finally it can also be used to merge two alternative states of the same model to more easily compare them.

In most tests the detailed attribute of the different elements were not used. I do not believe this is because there are not useful, but more due to the short testing run and the lack of knowledge about these attributes which were not used in the sticky note version. Another hint that confirms the usefulness of some of these attributes is the fact that one user suggested to display them directly on the creation dialog box so that he may be aware of them without having to go look for them afterwards in the detail window.

Some of the less knowledgeable user of BMO would have appreciated an overlay that explains the blocks their position and meaning of the links between them. This can be interpreted as interest for the model.

Lastly it is unclear how useful the wizard view mode actually is. It would be interesting to test its usage from beginning to end against a more sporadic usage. Naturally this can also be done on the paper based version.

Chapter 6 Further Research

What is next? Certainly the next iteration of the prototype will mainly focus on fixing the identified usability issues and implement some of the proposed features, which can be integrated into the current code base, without too many changes. But where to go after this is still open.

The project being very limited in time, it could not cover many of the ideas it generated during its iterations. Here are the ones that seem very promising, in no particular order and not necessary in the same direction of evolution.

6.1 Answer Questions with Weights

Expanding on the idea of wizard displaying questions to help assess the model, a set of more closed questions, which could be answered by a weighted value could be used to feed indicator. These indicators could then display an average health of each part of the business model or the model in general. This could also help to find where to focus a study for a future evolution of the business opportunities. The hard work on this idea is mainly to define a meaningful question set which also supports to be aggregated.

6.2 Pattern Wizard

Custom helpers could be created to help in special cases of well known business model situations. For example, creating a wizard that helps identify an asset’s type and rights like proposed by Gartner, 2007] based on the typology defined by Weill etal., 2004]. The classified model can then be assisted with more specific questions and model validation constraints.

Another type of custom wizard could be to apply patterns, for example, asking specific question when planning to do known transformations like: outsourcing, insourcing, establishing a R&D branch.

6.3 Sub Modules (SWOT, personas, costs)

The nine blocks of BMO could also be expanded. Each block has the possibility of hosting one or more detailed model for its specific topic. Client segments can be enhanced by personas profiles, a SWOT model can be added as enhancements to the elements as well as defining costs, margin and revenue for each element.

It is also imaginable to use the current BMO view as a dashboard if enough information can be mapped through the sub modules.

6.4 Model Constraints Validation

Since all the links between the blocks have been defined, this could be used to define implication rules like proposed in the article ’Modeling the Business Model Ontology with Protégé and OWL’ Pigneur, 2004]. This would then allow the application to display warning for missing elements or links between them and help strengthen the consistency of the entered business models.

6.5 Simulation

Having viable validation of the links and the ability to add cost information or even production percentages, could as a final step help in simulating the outcomes of alternate future business model innovation ideas.

6.6 Alignment

BMO model can also be used in alignment with IT like is shown in the e-Business course of Prof. Pigneur. This methodology could be used for example to generate a report of needed IT infrastructure based on the current business model or a model could be validated based on a list of provided IT infrastructure that are available. In more specific approach given a good knowledge of a chosen ERP and its modules, we could imagine an activation and configuration of the modules of the ERP based on the business model.

6.7 Other Views (Strategy Map)

The BMO display of components being mainly a way to represent data, this data could also, given the right transformations rules, be represented in other formats. A Strategy map vision of the BMO model could therefore be possible especially if the elements have more properties and information given by mentioned sub modules.

The following ideas are more influence by the technical side than the business requirements.

6.8 More flexible Database Schema

As discussed in the technical chapter different technologies could be used to make schema evolution more flexible and allow easier implementation of some of the above mention features.

6.9 Import/Export BMO

To be able to reuse the data without having to connect to the application’s database or to share the model with other people not using the same application, it would be interesting to be able to export a business model. Also to be able to share a model between separate instances of the application it would be nice to be able to import a model. Sharing of a model between the application instances can be done for example with a custom xml file. But sharing the data with another application would require choosing a defined standard format. Using the existing owl definition seems to be a good choice.

6.10 Offline Mode

In the current trends of web applications an offline mode is not a priority, but it would certainly be nice if a business man could manage his business model while being on a plane.

6.11 Multi-Touch

To allow for a more dynamic collaboration on the big screen, multi touch support could allow multiple participants to drag and drop elements at the same time. This is useful if different group work on different parts of the model, or to debate on ideas for alternatives. Multi-touch gesture could also be used to enhance the possible interactions with the application like zooming, throwing elements aside to dispose of them and so on.

6.12 More Sharing and Semantic Annotations

If the prototype is transformed into a social platform for sharing business models, all the modern web 2.0 activities could be imagined like tagging resources, sharing parts of models, rating combination of elements, tracking changes and notifying followers.

6.13 Real-time Collaboration (JMS)

While the current application can be used collaboratively on a big screen, perhaps there is also a need to allow online collaboration in real-time. This can be accomplished by using a desktop sharing tool or with quite some technical changes could be implemented directly as a feature of the prototype using the JMS capabilities of flex and Java. But except for the technical challenge I do not see the added benefits which could be provided over a desktop sharing solution.

Chapter 7 Conclusion

The prototype that was created and studied has proven that it is possible to take a very unrestrictive paper based approach to business model innovation and support it with a digital application. The prototype in its first version does not solve more problems that the paper based version, but acts as a platform on which new functions can bring new opportunities. Some have been tried out, like annotations to keep better track of the reflexions which guided the choices made on the business model, development of alternatives through versioning or layers and also helping the creative process by assisting it with a wizard. Other ideas have been proposed, which require future investigation. The implemented features have been tested with a variety of users, as well as on different display technologies and resulted in satisfactory results in usability and usefulness. It was always possible to input and use the business models developed during testing. This alone is as useful as a paper based version which has to be photographed to be digitally available. But the visualisation of alternatives, which can be easily edited and compared, adds another element of usefulness to the proposed application. Tests on projected screen and touch devices show promises to further facilitate collaborative thinking, but have to be explorer further with application configurations which are specially design for their interaction paradigms.

As contributions to knowledge from this project, the viability of a digital solution for the BMO methodology can be mentioned as well as the successful design of an application which works on different screen technologies and crosses the boundaries between web and desktop application. To the BMO itself the contribution was mainly the necessity to clarify the visual representation and naming of all the elements and links of its current iteration. The model can also certainly gain from the enhancement that brings the layer system in the digital version, but further work is necessary to see how this could be adapted to the paper based process, like for example colored sticky notes.

On the technological side, it was proven by the creation of the second prototype that the proof of concept of the interaction between Groovy / Java and Flex / ActionScript is possible in more complex application than a simple example. Also with the choice to test current Frameworks, another example of their usefulness as well as their known limitations has been shown.

The feasibility of creating a tool which helps in the creation business model innovation has been shown. It would be interesting to see further research on how to elaborate on more specific guides, as well as explore if after the creation of a business model, such a tool can also assist in the simulation, implementation and monitoring of the new business model.

Appendix A User Guide to The Final Prototype

A.1 Quick Reference

Figure A.1: Design screen with main actions highlighted

A.2 Terminology

Users can have a view or an edit right on a model.

A model can have a normal or a snapshot state.

A snapshot is a picture of a model taken at a specific time.

A branch is a model that started as a copy of a snapshot.

If a model is in a snapshot state it can only be viewed. The only difference between having edit or view rights on a snapshot is that with edit rights the title and description of the snapshot can be changed as well as its permissions.

A business model has four perspectives (offer, client, activity and financial). Each perspective regroups one or more blocks.

There are nine Blocks or Building Blocks in a business model. Each block can have many Elements. There is a special tenth Block called Elements inside the menu for storing non-assigned elements.

An element is one instance of a block; it represents a sticky note of the physical business model methodology.

An element can have different details depending of the building block he is in.

An element also belongs to at least one Layer.

A Layer helps to regroup elements that have a strong relationship or that are used to create the same offer.

In addition to layers, there is also the possibility to link two elements to show an even stronger interaction between them.

Finally, annotations can be put on the model, perspectives, layers and building blocks.

There are three types of annotations: comments, to-dos and answers to questions (for more information see corresponding section).

A.3 Login Screen

[login screen] [registration screen]

A.3.1 Logging-in

Existing user can connect and be redirected to their home screen by providing the right credentials (username & password).

A.3.2 Register new user

New users can create a new account by clicking the register link. Once they confirm their registration by providing their password twice they are forwarded to their empty home screen.

A.4 Home Screen

Figure A.2: Home Screen

On this screen the users can see all the models to which he has rights (figure A.264Home Screenfigure.A.2).

A model or a snapshot is represented by its name and a thumbnail. There is also additional information provided like the total number of annotations and a list of all the high priority to-do’s annotations. Only level 1 and 2 are shown with their category and text.

Model with only view right are shown with a * in their title.

Snapshots are kept in a separated tab which can be accessed by clicking on the snapshot title bar.

A.4.1 Loading a model

Clicking on a model or snapshot will load the selected model or snapshot into the model screen and switch to it.

A.4.2 Creating a new model

A new empty model can be created by selecting New Model on the top right menu bar. A dialog box will appear asking for a name and a description. Once a model is created the view is automatically switched to the model screen with the newly created model loaded.

A.4.3 Creating a copy or merging models

Copying or merging one or more existing models is done by clicking their checkmark and then clicking on New by merge Selected the view will automatically be switched to the model screen with the new model loaded. Warning! Copying a model this way creates a copy that is not linked to the old model. A model to which a user has only view rights can also be copied, thereby acquiring edit right on the new copy.

By checking multiple models at once a new model which contains all data from the selection can be created. Merging can be used to compare two or more models or to create a new model from parts by deleting the unused once.

A.4.4 Logging-out

A user can logout clicking on the title “Business Model Designer”, this is not needed the browser page can also simply be closed.

A.5 Model Screen

Figure A.3: Model Screen

A.5.1 Going back to the Home Screen

On this screen, by clicking on the title Business Model Designer the application is switched back to the Model Selection screen.

Notice: Before going back the application refreshes the thumbnail that is shown on the home screen for this model. Therefore it is better to go back to the home screen before quitting the browser window.

A.5.2 View/Edit Mode

Figure A.4: Message Bar

When the application is in view mode a green notification bar appears. In this mode drag and drop is disabled and no modifications are saved. When viewing a snapshot the state is always set to viewing, switching to edit mode for a snapshot implies creating a branch, since by definition the snapshot must not be editable.

If a user has only view rights the edit mode is disabled.

Notice: a trick to edit a model or snapshot to which a user has only view right is to make a copy of it in the Selection Screen.

A.5.3 Changing a model’s name & description

Clicking on the name of the model located besides the title “Business Model Designer” pops-up a dialog box that will allow editing the current model’s name and description. This also applies for editing the name and description of a snapshot, even when in view mode.

A.5.4 Show or Hide a perspective

Clicking inside a perspective but not on a building block will toggle the visibility of the clicked perspective. The other parts resize automatically to fill up the gained space.

A.5.5 Show or Hide The Menu

Figure A.5: The Menu

By default the menu is collapsed to a small vertical bar on the left side. The visibility can be toggled by clicking inside the boarder of the menu. The other parts resize automatically to fill up the gained space. Dragging an item over the collapsed menu will trigger it to expand.

A.5.6 Elements

Quick start:

  • Double-click on Building Block: new element.
  • Click on element: menu (Detail, set layers, show links).
  • Double-click on element: show links.
  • Drag & Drop element: move, order, copy, delete.

Adding a new element

A new element can be added to a building block by double-clicking on it. This only works in Edit mode. A prompt will appear asking for the name to give to the new element. The actions can be canceled by clicking on the x of the prompt, or executed by clicking on create. Pushing enter after entering a name also creates the element without requiring to click the create button.

When an element is created it is automatically added to all the currently selected layers.

Notice: It is good practice to wisely check which layers are currently selected before creating a new element as to reduce the amount of correcting actions that have to be taken afterwards.

Moving, Reordering, Copying elements

An element can be drag and drop inside the same block or between blocks, holding the shift key while dragging acts as a copy otherwise the element is moved. The only case when an element does not lose its details attributes is when it is reordered inside the same block.

Notice: before dropping be sure to see the horizontal marker that indicates the new position and not a link icon, otherwise the elements will get linked and not moved or copied.

Renaming an element and adding details and layers

[click menu] [detail window] Figure A.6: Get access to detail window trough the click menu

Clicking on an element pops-up a menu with three options: Detail, Layers and Links.

Clicking on details brings up a dialog with extra fields for the specific type of element and also information on the links this element has. Changing the name in the detail window will change the displayed text of the element on the general model view. Changes are automatically saved once the window is closed.

The layers tab on the detail window has the same functions has the layers item on the click-menu: it allows adding and removing the selected element to or from the clicked on layer.

The Links item has the same effect has double clicking an element: going into link mode (see link mode section).

Deleting an element

Deleting an element is as simple as dragging it into the trashcan that can be found on the menu sidebar. Warning a deleted element cannot be recovered!

A.5.7 Layers

Layers can be found on the menu sidebar. There is always at least one layer for each model.

Add a layer

A new layer can be added as simply as a new element by double-clicking somewhere inside the layers list.

Change selection

By changing the state of the checkbox between the layer’s color and name, the model’s element will be appropriately shown or hidden depending if they belong to a layer that is checked or not. The selections are saved, so when the model is reloaded it is in the same state.

Change color

Figure A.7: Layer color palette

When clicking on the color of a layer a color palette appears. A new color can be selected from the color palette or a custom RGB Hex value can be entered into the input field.

Rename layer

Clicking on the layer’s name transforms the text into a text field which can be edited. Clicking outside of the text field updates the name of the layer.

Delete layer

Drag and drop a layer into the trashcan to delete it and all its elements that have no other layer. Warning this operation cannot be undone and can quickly delete a large number of elements!

Figure A.8: Link Mode

Link mode is identified by a yellow message bar listing the related elements. In addition, only the related elements have their color, and there are links drawn to visualize the relationships.

In addition to seeing links of one element in its detail window, the whole dependence tree of links between related elements can be shown in what is called link mode.

Entering link mode is done by double-clicking an element from which to start the graph, or clicking on it and choosing link in the menu that pops-up.

It is not needed to exit link mode to focus on a different element.

Exiting link mode can be done by clicking the yellow message bar or by double-clicking on an empty space in a building block.

Creating links involves drag and dropping an element onto another element. The dragged element has to be release when a grey link icon with an arrow appears. Once a link is created, its creation can be verified by going into link mode on one of the two elements involved in the operation.

Notice: a horizontal line, it is the indication for a move or copy operation and not a link creation.

To delete a link, link mode must be active and the link to be deleted has to be visible. By moving the cursor over the desired link, it gets highlighted (the lines gets fatter). When a link is highlighted it can be dragged and dropped onto the trashcan located in the menu to be deleted.

Warning this operation is not reversible!

A.5.9 Annotation

Figure A.9: Annotation Window

Annotations can be used at different levels: model, perspective, building blocks… but they share all the same interface.

Accessing the annotation interface is done by clicking a small note icon. There are three versions of the icon:

  • there are no annotations for this item there are annotations for this item there are annotations for this item, including high priority to-do’s

Hovering over the icon with the cursor will display a tooltip indicating the number of annotations.

The annotation window can be resized using the lower right corner.

New Annotation

Clicking on an empty space in the annotation list toggles the lower half into a section which can be used to add new annotations (this section is also directly shown when there are no annotations available).

The sections is composed of three parts, a dropdown to specify the type of the annotation, a text area and the save button.

An annotation can be either a comment (the note icon), or a to-do (icon from 1 to 5, 1 being the most important). Lastly an annotation can also be an answer to a question (see Main Wizard section for more details).

Notice: creating an annotation of type answer from here will have no reference to a question (see Main Wizard section for more details).

Edit Annotation

To edit an existing annotation double-click it in the list. The type and text of an annotation can be changed.

Notice: Changing an annotation type from answer to something else will make it lose its reference to the original question (see Main Wizard section for more details).

Delete Annotation

To delete an annotation drag and drop it onto the trashcan which is located in the sidebar menu.

Warning this action cannot be reversed!

Filter annotations

The annotation list can be filtered with the options available at the bottom of the annotation window. Comments, Answers, To-dos can be toggle to appear in the list as a whole. For to-dos there is a finer grained filter that allows selecting a range of priorities. The range can be modified by moving the two triangular sliders.

A.6 Main Wizard

Figure A.10: Main Wizard

The wizard can be launch by clicking its link on top right of the model screen.

The wizard uses the same building blocks as the model screen, but displays only one at a time. The lack of relationship to the other blocks is compensated by the display of questions that can help identify new elements or annotations in relation to the current block.

There are three type of questions grouped in what we will call questions sets: Describe, Assessment and Innovation.

Navigating the blocks is done by clicking on the desired vertical accordition menu tab.

A.6.1 Answer a question

To answer a question click on it, a text area will appear where the answer can be written into. Clicking outside the text area will save the answer. If the question icon () is colored this indicates that there is an answer for the corresponding question.

A.6.2 Delete an answer

To delete an answer go into the annotations menu for the concerning block, be sure that the answers filter is selected and then the annotation representing the answer can be drag and dropped into the trashcan.

A.7 Snapshot Manager

Figure A.11: Snapshot Manager
[click on snapshot] [menu] [click on active model] Figure A.12: Actions available on Snapshot Manager

Quick start: double-click thumbnail to select

When the current model has no snapshots, the snapshot manager window will be empty.

Interactions can be done through the menu or the buttons on the bottom of the window. The currently loaded model or snapshot is identified by a red glow.

There are two different menus depending if the click model is the currently loaded one or not.

Clicking on a snapshot or model that is not currently loaded will allow selecting, renaming or deleting it. Selecting a model or snapshot will load it as the current model. This can also be done by double-clicking one of the thumbnails in the graph.

Clicking on the currently active model/snapshot will allow renaming, generating a report or branching/taking a snapshot depending if the active item is a snapshot, or a model.

A.7.1 Generating Report

The report is a webpage listing all entries of all the elements as well as all the annotations. When the report is generated new pictures are taken of the snapshot manager and the model to be displayed on the page.

A.8 Sharing Manager

Figure A.13: Sharing Manager

The sharing manager allows granting and revoking user’s view right or edit right to the current model. It is accessed from its link located in the options group on the sidebar menu.

The window is composed of three lists one for users with no rights to the model, one for edit right, and one for view right. The permissions can be changed by drag and dropping a user from one list to another.

Notice: the active user cannot remove himself.

A.9 Known Issues

If it is difficult to move an element form one block to another because the link symbol appears, the element can first be moved to the bottom of the new block (empty space) and then in a second drag and drop movement reordered it inside the same block (which will not trigger the link icon).

A.9.2 Application frozen

If the application seams unresponsive or frozen you can always reload the page / the application and continue without having lost changes since every small step is saved.

A.9.3 Layer refresh

In some cases the layers to which an element belongs to are not correctly refreshed. In this case the best thing to do is to reload the model by going back to the Selection Screen or reloading the model through the Snapshot Manager.

A.9.4 Keyboard navigation

In flex/flash application Space is the default key to select/activate a button instead of the commonly used enter key. For some special input fields enter has been added manually as an option.

Appendix B Sample Business Models

Figures B.179Amazon: classic and S3 servicesfigure.B.1 and ?? show two real world examples of models entered into the prototype. Images are exported from de report generation feature. Business models courtesy of Arvetica.

Figure B.1: Amazon: classic and S3 services
Figure B.2: Apple: iPod and iTunes

Appendix C Technical Supplements

C.1 Prototype 2 Server Domain Classes

Figure C.185Prototype 2 server domain classes and attributesfigure.C.1 shows the class diagram of the domain objects representing the business model ontology. There is no class representing the building blocks instead there exists a class for each element of a building block. These classes all inherit their common attributes from a common element parent class. Elements have all at least one layer. Some subclasses of element have additional custom attributes, while others do not. Every possible element is modeled, this to allow the creation of all the linked relationships defined by the BMO. On the figure the dashed lines symbolize these many to many relationships.

A business model is composed by all its layers, elements and annotations. A business model can also have many children to create the branch graph of the snapshot manager.

A user can own many business models through the permission mapping.

Questions are grouped into question sets, but there is no relationship with annotation for saving an answer. The reference to the question’s id is currently stored in a text field of the annotation.

There are also java enum classes to define the value range of some of the attributes.

Figure C.1: Prototype 2 server domain classes and attributes

C.2 Prototype 2 Client Classes

Figure ?? illustrates the file structure of the flex client application. Each rectangle is a folder, the bold text being its name. Since the Cairngorm framework was used we can identify the Model, View, Controller structure it advocates. In blue are the model components, in orange the views and in green the controllers.

The model part is composed of business services which are the connection points to the backend server. The Value Object are a local representation of the server domain classes, they need to be defined to allow proper mapping between Java and ActionScript. The model class itself is a singleton regrouping all the state information and data for binding to views.

The views are for the most part all defined in mxml and organized in subfolders only for clarity. The appcontroller class connects the events to commands. One event can have multiple types, but each type of an event is mapped to a unique command.

Figure C.2: File structure of the 2nd prototype’s client

C.3 Detailed Example Roundtrip of a Query

The client being a user interface and object oriented program, most of the actions are initiated by events. Figure C.387Event sequence of a link creation after drag and dropfigure.C.3 shows the event call history for a link creation between two elements.

Figure C.3: Event sequence of a link creation after drag and drop

Dragging an element will start an event that registers the drag operations. Whenever the dragged element enters in contact with another element, a new event is started which will check if the two elements can be dragged onto each other (1.1). If this is the case, the icon of the dragged element will change, the underlying element will get highlighted and the correct operations are set in the drag manager. This allows, when the element is dropped (1.2), to execute the link creation event between the two elements(1.2.1-3). This action will call the appropriate method on the server via the service endpoint (4-6). The server looks up the correct elements from the database, validates if linking this two types of element is allowed and then creates the associations that represents the link between the two elements. After receiving confirmation of success from the server (6-7), the client starts another event that will do a refresh of the model (8-10). The refresh event, will contact the server to get the last version of the complete graph of object and then parse it (11-14). While parsing the data, objects are put in their respective lists which are watched by the graphical objects which display the model (15). Also additional listeners are added to be able to interact easily with the data from the different user generated events (15.1). Finally flex’s automatic data binding will triggers its own refresh events on the subscribed view elements (16).

C.4 Versions of Software Used

C.4.1 Prototype 1

C.4.2 Prototype 2





  • [Eppler and Burkhard, 2004] Eppler, M. J. and Burkhard, R. A. (2004). Knowledge visualization towards a new discipline and its fields of application.
  • [Fowler, 2004] Fowler, M. (2004). Is design dead? http://martinfowler.com/articles/designDead.html.
  • [Gartner, 2007] Gartner (2007). Getting the right IT: using business models. EXP CIO signature, (octobre2007).
  • [Hevner etal., 2004] Hevner, A. R., March, S. T., Park, J., and Ram, S. (2004). Design science in information systems research. MANAGEMENT INFORMATION SYSTEMS QUARTERLY, 28(1):75–105.
  • [Osterwalder, 2004] Osterwalder, A. (2004). The Business Model Ontology-a proposition in a design science approach. PhD thesis.
  • [Osterwalder, 2007] Osterwalder, A. (2007). How to describe and improve your business model to compete better (Draft 0.8).
  • [Osterwalder, 2008a] Osterwalder, A. (2008a). Outsourcing, entrepreneurship & business model prototyping, guest lecture at hec lausanne.
  • [Osterwalder, 2008b] Osterwalder, A. (2008b). What is a business model? http://business-model-design.blogspot.com/2008/07/what-is-business-model.html.
  • [Pigneur, 2004] Pigneur, Y. (2004). Modeling the business model ontology with protégé and OWL.
  • [Pigneur, 2007] Pigneur, Y. (2007). e-Business lecture, HEC lausanne.
  • [Rosson and Carroll, 2002] Rosson, M. B. and Carroll, J. M. (2002). Usability engineering : scenario-based development of human-computer interaction. Morgan Kaufmann series in interactive technologies. Academic Press, San Fancisco.
  • [Stacey and Eckert, 1999] Stacey, M. and Eckert, C. (1999). CAD system bias in engineering design. In Proceedings of the 12th International Conference on Engineering Design, volume 2, pages 923–928.
  • [Weill etal., 2004] Weill, P., Malone, T. W., D’Urso, V. T., Herman, G., and Woerner, S. (2004). Do some business models perform better than others? a study of the 1000 largest US firms. MIT Center for Coordination Science Working Paper.
tm/business_model_designer_from_sticky_note_to_screen_interaction.1232118361.txt.gz · Dernière modification: d-m-Y H:i de boris
chimeric.de = chi`s home Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0 Fristcher.ch