



Business Model Designer From Sticky Note To Screen Interaction [HEC 4 ALL]

Ceci est une ancienne révision du document !

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/inc/parser/handler.php on line 1427

Warning: Declaration of syntax_plugin_flash::handle($match, $state, $pos, &$handler) should be compatible with DokuWiki_Syntax_Plugin::handle($match, $state, $pos, Doku_Handler $handler) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/flash/syntax.php on line 17

Warning: Declaration of syntax_plugin_flash::render($mode, &$R, $data) should be compatible with DokuWiki_Syntax_Plugin::render($format, Doku_Renderer $renderer, $data) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/flash/syntax.php on line 17

Warning: Declaration of syntax_plugin_math::handle($match, $state, $pos, &$handler) should be compatible with DokuWiki_Syntax_Plugin::handle($match, $state, $pos, Doku_Handler $handler) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/math/syntax.php on line 217


Warning: Declaration of syntax_plugin_note::handle($match, $state, $pos, &$handler) should be compatible with DokuWiki_Syntax_Plugin::handle($match, $state, $pos, Doku_Handler $handler) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/note/syntax.php on line 130



Warning: Declaration of syntax_plugin_tag_tag::render($mode, &$renderer, $data) should be compatible with DokuWiki_Syntax_Plugin::render($format, Doku_Renderer $renderer, $data) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/tag/syntax/tag.php on line 106



Warning: preg_match(): Compilation failed: invalid range in character class at offset 3227 in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/inc/parser/lexer.php on line 118

{{main001.gif}} Master of Science in Information Systems\\ **Business Model Designer\\ From Sticky Note\\ To Screen Interaction**\\ Boris Fritscher Supervised by Prof. Yves Pigneur and by Prof. Thibault Estier December 2008 **Abstract** 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. ====== Acknowledgements ====== 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 1 Introduction ====== Business model innovation is getting more and more traction in today’s fast passed global economy. New methodologies arise to help invent, transform and identify these new business models, but unfortunately there are few computer based tools capable of assisting in this task. Working on paper or with whiteboards has certainly its benefits regarding creativity and freedom of action, nonetheless, at one point the captured idea has to be digitalized for it to be shared, edited or enhanced. Business models could always be recorded in a classical text based fashion, but as we know from other visualization domains, //’Visual representations are superior to verbal-sequential representations [...] and the brain has a strong ability to identify patterns’//[ [[#eppler_knowledge_2004|Eppler and Burkhard, 2004]]]. Therefore, there is a need for a more specialized artifact which is aligned with the metaphors of the methodology it has to support. However, //’IT artifacts have to be conceived not as independent of people or the organizational and social contexts in which they are used but as interdependent and coequal with them in meeting business needs’//[ [[#hevner_design_2004|Hevner etal., 2004]], p83]. For this thesis the choice was to support a very intuitive and visual paper based methodology called Business Model Ontology (BMO) developed at HEC Lausanne[ [[#osterwalder_business_2004|Osterwalder, 2004]]]. The model has nine blocks which help describe a business. The power of the method originates from its visual positioning of the block and the relationship they have between each other. Simply adding, removing or changing sticky notes, containing a short title, to the blocks helps identifying existing business models, as well as new opportunities. The challenge is to provide enough specialized functionality to enforce the rules of the methodology, without compromising the freedom of creativity. The application has to be extremely intuitive to use, not to interrupt the creative process each time a new item has to be added. Like with CAD tools, the risk is very real to infringe on the creative process, if too many presets or standardized actions are imposed on the user. //’CAD tools push designers towards producing conservative designs, by making it easy to use particular design elements in preference to others, standard choices and default parameter values, and to recycle previous design.’//[ [[#stacey_cad_1999|Stacey and Eckert, 1999]], p5]. Or this is exactly what could limit creativity. The key is to find the right balance between supporting the model by enforcing its rules and still give the user enough degrees of freedom to allow him to follow his own path of creation. The application should be flexible enough to allow switching between actions without having to manage application specific interactions. To illustrate theses two paradigms a good example is to compare the task of creating a new business model in a non guided process of a mind mapping applications, versus entering it in an ontology application like Protégé. Doing it in a mind mapping form is lightweight, ideas can directly be added to the blank canvas and then be regrouped and arranged to form the model’s pattern. The application specific actions are reduced to a minimum and focus is entirely on defining the right components of the business model. The drawbacks, however, are the lack of validation and the missing guidelines. Except for having a guideline document next to the user and manually checking it, there is no way to enforce the models constraints. Applying the manual control process in its turn will distract the user from concentrating on the main task of creating the new business model. The Protégé example has the opposite problem. The models constraints are imposed by the application following the defined ontology. This lets the user, in theory, focus on the creative process, but in the case of Protégé too many applications specific interactions are deteriorating the user experience. There is for instance no global overview, so there cannot be any benefit of visual pattern recognition. To add or edit entries the user has to navigate into multiple sub menus making him interrupt his thought process or write it down on a piece of paper negating the purpose of the application. Therefore, for the prototype of this thesis the objective is to reproduce the paper based experience and its ease of use, finding the right equilibrium to allow for validating model constraints without infringing on the creative process. To procure additional usefulness to the design, the idea is also to augment the model with new functionalities made possible by the fact that the sticky notes now are digital. Once the step of creating the model is complete, new data can be added without infringing onto the creativity, and provide additional value to the augment model. Designing such an application will inevitably trigger new ideas and request for changes during its iterations. Therefore, we already know that it is an application which has to be able to evolve with its changing requirements. Fowler writes that //’one way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect.’//[ [[#fowler_2004|Fowler, 2004]]]. This triggers the need to plan ahead and perhaps leave some doors open knowing they might be used in a future version, or to decide to abandon some features knowing, that they can only be added later at great expenses. Even if the main focus is set on supporting the BMO methodology, keeping an eye on the evolution requirements seems to be a good addition to utilize the knowledge gained by the creation of the artifact, not only for the business productivity provided by the design, but also for the more technical side of design. This thesis is divided into seven chapters. The first chapter is the introduction to the specified problem domain and the proposed prototype. The second chapter is about the consolidation of different version of the BMO and an overview of some visual modeling tools. Chapter three describes the design process and iterations, from the brainstorming done to initiate the project through to the final prototype. Chapter four is a discussion about the technologies used for the prototypes and an overview of other possibilities. This part is for the more technical persons and does also cover comments about requirements of an application that evolves. Chapter five is about feedback from validation done on the final prototype. Following, chapter six is taking a look at what could be the next iteration. Finally, in chapter seven the conclusion of the experience is drawn. In the appendix there is a user guide for the final prototype and some additional schemas and business model examples, as well as some additional technical schemas to chapter four. ====== Chapter 2 Business Model Ontology Refinement and Visualization ====== This chapter has two parts, the first part covers the refinement work which was done to BMO, and the second part takes an overview at available tools to represent visual models like the BMO. ===== 2.1 Business Model Ontology Refinement ===== Refinement of the model was done between the first and the second prototype but since the model is introduced here, it is a good opportunity to explain the choices applied to the model during the development of the application. Since BMO’s definition in the thesis of A.Osterwalder in 2004 , the BMO has been used and adapted in different versions (figure [[#fig:bmo1|2.1(a)6Subfigure 2 2.1(a)subfigure.2.1.1]]). These changes are mainly due to the usages made of the model, notably by Y.Pigneur for the e-Business course at HEC Lausanne (figure [[#fig:bmo2|??]]) and by A.Osterwalder for his activity with Arvetica in the private banking sector (figure [[#fig:bmo3|??]]). As can be seen on figure [[#fig:bmo4|2.1(d)6Subfigure 2 2.1(d)subfigure.2.1.4]] the terminology as well as the position of the elements has changed. Links have sometimes become arrows even if the meaning is still bidirectional. The detailed attributes that were define for each element in the thesis have somewhat bean put aside. This is mainly explained through the usage which is only putting the title of each element on a sticky note and then assigning it to one of the nine blocks. Figure [[#fig:bmos|??]] illustrates four distinct version of the BMO. Subfigure [[#fig:bmo1|2.1(a)6Subfigure 2 2.1(a)subfigure.2.1.1]] is the initial canvas proposed by Osterwalder in his thesis. It defines not only the blocks but also instances of each block and has two additional blocks actor and profit. Subfigure [[#fig:bmo2|??]] shows another layout of the initial canvas and has already dropped the special blocks. This presentation which is closer to the strategy map visualization is used vertically to allow for alignment with the IT infrastructure. Subfigure [[#fig:bmo3|??]] simplifies the initial canvas and changes the wording of the block to be more non-technical. The introduction of arrows can also be observed pointing all from the left to the right. Subfigure [[#fig:bmo4|2.1(d)6Subfigure 2 2.1(d)subfigure.2.1.4]] expands on subfigure [[#fig:bmo3|??]] but has the position of the blocks changed to have more symmetry between the left and right hand sides. | {{bmo1.png?320}}\\ (a.) Initial version [ [[#osterwalder_business_2004|Osterwalder, 2004]]] | {{bmo2.png?320}}\\ (b.) e-Business version [ [[#pigneur_e-business_2007|Pigneur, 2007]]]] | | {{bmo3.png?320}}\\ (c.) Simplified [ [[#osterwalder_presentation_2008|Osterwalder, 2008a]]] | {{bmo4.png?320}}\\ (d.) Latest version [ [[#osterwalder_blog_2008|Osterwalder, 2008b]]] | | Figure 2.1: Variations of Business Model Ontology visualizations || To facilitate development with clear defined objects and their attributes, a meeting was held together with Y.Pigneur and A.Osterwalder to define these conventions. The result can be observed in figure [[#bmolinkfin|2.29BMO with financial linksfigure.2.2]] and the attributes are listed in the next section. For the current position of the blocks the last version used by A.Osterwalder was chosen, mainly due to the fact of the nice symmetry it provides between the left side and right side. Another argument in favour of moving the position of the partner network is that more and more businesses enfasis the importance of partnerships over internal resources, especially in the service area. As for the terminology the choice was also to use the publicly tested wording and the one that will be available in the future book. Only the central block is a bit of a dilemma. If the user is business savvy offer could be replaced by the more precise name value proposition. As stated before, links are all bidirectional never the less we decided to draw arrows to help with the naming of the relation. Except links connecting to cost and revenue, every link has a unique verb that can be used to identify it and its direction, or inverted to follow the link into the other direction. During this session an idea was to test if arrows could be used to simulate either the flow of the product or the flow of money or even highlight the central role of the value proposition / offer. But as can be seen in figures [[#bmolinkoffer|2.310BMO with links centered on offerfigure.2.3]] or [[#bmolinkactivity|2.413BMO with activity linksfigure.2.4]] this syntax overloads the model and does not provide a strong additional value. Therefore, the naming of links was principally intended to be used internally, if identification is required. ==== 2.1.1 Decided Terminology for this Project ==== 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. An **element** is one instance of a block; it represents a sticky note of the physical BMO method. An **element** can have different details depending of the **building block** he is in. All **elements** share the name and optional description property. In addition, here is the list of properties that has been decided to be kept or added to the original definition of the model. * **Partner Networks:** none or perhaps partner importance * **Key Activities**: none * **Key Resources**: ResourceType defined as TANGIBLE, INTANGIBLE, HUMAN, FINANCIAL, OTHER * **Cost Structure**: costSum, percentage * **Offer:** valueLevel defined as ME_TOO, INNOVATIVE_INNOVATION, EXCELLENCE, INNOVATION\\ priceLevel defined as FREE, ECONOMY, MARKET, HIGH_END * **Client Segments:** criterions or personas * **Client Relationships**: relationshipType defined as ACQUISITION, RETENTION, ADDON_SELLING, AUTOMATION\\ valueLevel defined as ME_TOO, INNOVATIVE_INNOVATION, EXCELLENCE, INNOVATION\\ priceLevel defined as FREE, ECONOMY, MARKET, HIGH_END * **Distribution Channel**: priceLevel defined as FREE, ECONOMY, MARKET, HIGH_END * **Revenue Flows:** revenueType defined as SELLING, LENDING, LICENCING, TRANSACTION_CUT, ADVERTISING, OTHER ==== 2.1.2 Assisted Construction ==== Another aspect of the model used in the developed application is the construction sequence proposed in the draft from Osterwalder, A. (2007) ’How to Describe and Improve your Business Model to Compete Better’.\\ \\ **Sequence** - Client Segment (Customer) - Offer (Value proposition) - Distribution Channel (Channel) - Client Relationships (Relationships) - Revenu Flows (Revenu) - Key Resources (Capability) - Key Activities (Value Configuration) - Partner Network (Partner/Partnerships) - Cost Structure (Cost) This sequence and the additional questions which are proposed in the mentioned document have been taken and used to create what will be called the wizard mode. > {{main006.gif}} Figure 2.2: BMO with financial links > {{main007.gif}} Figure 2.3: BMO with links centered on offer > {{main008.gif}} Figure 2.4: BMO with activity links ===== 2.2 BMO and Other Visual Modelling Tools ===== Until now BMO was mainly applied as brainstorming tool on paper or on whiteboard in combination with sticky notes. The primary users are Arvetica and HEC Lausanne, but due to the simplicity, the powerful expressiveness, the fact that the model is free and mainly the good evangelism job done by its creator, Alexander Osterwalder, on his web site<sup>[[#note4|1]]</sup> and talks. The model attracts more and more users, enough that different individuals have created or intent to create a support application for it. Although none of the current versions seem to be a good replacement for the paper based interaction. The simple prototype that is available on the web (figure [[#webpostitproto|??]]), is more a proof of concept than a real application and for now focuses only on imitating the sticky notes in a virtual form. > {{main009.gif}} Figure 2.5: Simple web prototype [[http://seedea.free.fr/wiki/index.php?n=BMI.BMItest|http://seedea.free.fr/wiki/index.php?n=BMI.BMItest]] > {{main010.gif}} Figure 2.6: IBM prototype in Microsoft Visio™ Another version is done internally by IBM and use Microsoft Visio™as platform (figure [[#ibmproto|2.614IBM prototype in Microsoft Visio#X2122;figure.2.6]]). This allows storing more information than the paper based version, but comes with the burden of a generic modelling tool like Visio™. Meaning, the user has to be proficient with the program and moving or creating links between the elements or even adding information can sometimes be complicated for a non-technical user. > {{main011.gif}} Figure 2.7: Sticky note BMO on a wall (Arvetica) > {{main012.gif}} Figure 2.8: BMO Amazon in PowerPoint™ From the original thesis of the BMO there is also an owl file available which can be edited with programs like Protégé. Sadly, as with the Visio™solution the visual representation is very abstract and even if all the information and links are present and browsable, it is hard to get an overview picture of the model. Protégé also being a generic Ontology editor has too many unused options which clutter the interface for the novice user. Digital versions of the paper based BMO are either captured with a photograph or recreated on a PowerPoint™presentation. Figure [[#bmopaper|??]] illustrates a normal paper based workshop session and figure [[#bmoamazon|2.815BMO Amazon in PowerPoint#X2122;figure.2.8]] shows the final PowerPoint™output after tedious work of transcribing and aligning shapes. An application that can recorded and help create the model directly in a digital form is certainly useful, but must not be a burden or take away the brainstorming capabilities provided by the paper based version. Naturally an electronic version will be a bit slower or a bit less forgiving than simply working with the physical artefacts. Therefore, the application should provide other benefits to justify its usage over the traditional way. Before turning to the requirements of such an application, here is an overview of other models and their digital applications in comparison. See table [[#tabledesktopmodel|??]] and [[#tablewebmodel|2.211BMO and Other Visual Modelling Toolstable.2.2]] for comparison and figure [[#screen_overview|2.916Screenshots of applications mentionned in the overviewfigure.2.9]] for screen captures. > Table 2.1: Overview of desktop applications **Application** **Main Model** **Pros** **Cons** **Sticky notes** generic fast, can be used everywhere, low tech hard to share, lack of interactive filtering, no additional properties for storing information **PowerPoint™** generic somewhat digital version of sticky note, limited skill necessary model agnostic, editing, no properties **Visio™** generic and specific (with templates) Relations and properties can be defined made for developers, no view mode **Protégé**<sup>**[[#note5|2]]**</sup> Ontology editor powerful, simple for ontology’s hard for users without knowledge of ontology **Consideo-modeler** <sup>**[[#note6|3]]**</sup> complete workflow end to end solution from design to simulation Specific to its workflow, knowledge of the application and the workflow required **StrategyMap** <sup>**[[#note7|4]]**</sup> StrategyMap Guide through the steps knowledge of the application and the model required **MindManager**<sup>**[[#note8|5]]**</sup> MindMap Flexible way to represent information for some information too loose representation > Table 2.2: Overview of web applications **Web application** **Main Model** **Pros** **Cons** **MindMap** <sup>**[[#note9|6]]**</sup> MindMap Same as desktop version, easy sharing No real-time collaboration **Lombardi BluePrint** <sup>**[[#note10|7]]**</sup> Process process outlining, web based and collaborative, intuitive hosted service > [Strategy Map] {{main013.gif}} [Lombardi BluePrint] {{main014.gif}} [Protégé] {{main015.gif}} [MindManager] {{main016.gif}} [Consideo-modeler] {{main017.gif}} [Consideo-modeler] {{main018.gif}} Figure 2.9: Screenshots of applications mentionned in the overview From this quick, very shallow, overview of applications that digitally support in one way or another a model, we can see some common observations. Generic applications need specific knowledge to identify the right tools to be used and sometimes lack the visual forms to accurately represent the model. As for the specific applications designed to support their specific model, they have the visual representation but are too often not very user-friendly. This can be explained by the fact that they are geared towards the experts and try to have options for every variation allowed by the model. Web technologies have evolved enough to allow applications to be created for the web and therefore facilitate collaboration and sharing, as shows the example of Lombardi BluePrint or the many online MindMap services. As a small experience reproducing a BMO model in a mindmap (see figure [[#fig:mindmap|??]]), shows the information can be represented and there are possibilities to add comments and move elements easily form one topic to the other, but the relationships and the structure of the BMO does not really emerge. The corollary of this small overview is that for our application there has to be a compromise between complexity and usability. A novice user has to be able to create his business model as easily as on paper and the prototype has still to have enough advanced options to allow experts to do more than with a digital capture of a paper version. ---- * **1** [[http://business-model-design.blogspot.com/|http://business-model-design.blogspot.com/]] * **2** [[http://protege.stanford.edu/|http://protege.stanford.edu/]] * **3** [[http://www.consideo-modeler.de/|http://www.consideo-modeler.de/]] * **4** [[http://www.strategymap.com.au/|http://www.strategymap.com.au/]] * **5** [[http://www.mindjet.com/|http://www.mindjet.com/]] * **6** [[http://www.mindomo.com/|http://www.mindomo.com/]], [[http://www.mindmeister.com|http://www.mindmeister.com]], [[http://www.mind42.com|http://www.mind42.com]], [[http://www.bubbl.us|http://www.bubbl.us]] * **7** [[http://www.lombardisoftware.com/|http://www.lombardisoftware.com/]] ====== Chapter 3 Design of The Prototype ====== Design of the prototype was started with a brainstorming session and then followed by some iterations of building the prototype with different technologies and functionalities. After brainstorming, the first prototype was quickly developed to test if the basic imagined function made sense. Since the prototype was convincing and generated a lot of new ideas a second prototype was created. At that time the focus on application evolution was still at hand, therefore the decision was taken to try another set of technologies and data structure for the second prototype. The development of the second prototype took a bit longer, but resulted also in a satisfactory solution on which more iteration could be applied. Since the development took more time, ongoing changes were made without defining clear iterations, but the second prototype can be decomposed into two sub iterations: the first being the state until functionality of the first prototype was matched and the link systems implemented. This system was the main reason for which the second prototype was built. The second part, which is the last iterations of the second prototype, was the addition of features that were discussed along the road, but which implementation was deferred until finishing the basic functionalities. At this point it was time to test the prototype on normal screen and later on touch enabled screens. ===== 3.1 Brainstorming The Prototype ===== Once it was decided to explore the possibilities of creating an application that can support the BMO digitally, a brainstorming session was organized to identify the key components needed by such an application and plan for future nice to have features. The session was very productive, especially due to the fact that there were people with different backgrounds and objectives participating in it. One part was more focused on the research of new interactions and solutions, while the other had a strong economical and practical focus. This helped to, on the one side explore the limitless possibilities of creativity, while having a strong incentive to focus on core features that could be developed with limited resources and time. The practical reflection was directed towards identifying the main users of the application. Four distinct categories where defined: the creator, the explorer, the analyst and the implementer. The creator wants to construct his new business model or recreated one he is observing. This role is generally taken by small business owners or by students. The explorer wants to browse through existing business model to allow him to get new ideas. A consultant could also use this role to identify patterns or benchmark business models in the same industry. The analyst owns his business model or at least part of it, representing the process to which he is accountable. He wants to monitor dependencies, check for model validation and resource utilization. On a global level, the analyst wants to know if their resources are used efficiently, identify outsourcing or insourcing opportunities to reduce cost or optimize lead time. The implementer is mainly interested by dependencies which can be shown in the model. These could help him identifying, systemic problems which could occur during the integration phase of the business model, into the current production environment. On the creative side, the session produced a list of possible modules and functionalities that far exceeds the time frame and capabilities of this project, but none the less is interesting for planning future evolutions. ==== 3.1.1 Designer ==== This are the basic function expect from the application: the ability to browse models and their components and naturally also edit existing elements. Navigation should enable to follow the dependencies of elements which have a strong relationship with each other. The application should also be able to capture new models, not only in the way of a data entry form, but as a support tool for brainstorming. This implies being able to easily move element from one block to another, as well as allowing the creation of temporary elements that shall be classified later. A function which could merge different parts of two models would also be of great help. ==== 3.1.2 Versioning ==== The idea of versioning has different visions. One is the normal tracking of the evolution of the model to be able to go back or even to do undo’s. Another vision is more a feature of comparing two or more versions like for example, the current model against one or more of its future alternative. ==== 3.1.3 Assessment and Wizard ==== Creating a wizard who helps in the creation of the model is the first step of an assessing module. The wizard can display questions that enable the user to see if he has missed something. Further along the assessment path, it would be nice to be able to tell the user directly if he is missing some elements because his other elements match a given pattern. Not only could these pattern identify missing parts of a given business model, but the user could also select new patterns to help him compare and evolve his model. Another helpful tool would be if the business model could be mapped to other views like a strategy map, an organisational chart or a process map. ==== 3.1.4 Support and Simulation ==== Speaking of process it would be nice if the digital business model canvas could also function as a monitoring tool like a dashboard. A reporting feature could also be imagined showing the cost of elements depending on their interactions or even simulating usage or revenue based on some basic information gather through a wizard. ==== 3.1.5 Evolution Choices ==== Even before beginning to create the prototype, it is clear that some choices have to be made and will impact how the application will originate and be able to evolve. One decision that has been made since the start is to create an application which can be used as well on a computer screen than on a touch device like a tablet pc or a projected wall with touch interaction. This is imperative if the prototype is to be able to replace the sticky note interaction and still allow brainstorming with multiple individuals. The other decision was even if the first version does not focus on multiuser interaction and sharing possibilities, these features which are at the time very popular on the Internet, should not be excluded in future versions. Therefore the application is web based to allow such evolution. ===== 3.2 First Prototype ===== > {{main019.gif}} > [BMO design mode] {{main020.gif}} [wizard mode] {{main021.gif}} Figure 3.1: Screen captures of the first prototype The first prototype was built very rapidly as a web based application. The goal of this first iteration was to test if a representation of the BMO was possible on a computer screen without the need for scrolling and to see if the drag and drop interaction on text elements was a good enough substitute to the real world sticky note experience. The first application was built on the example of the Amazon case which had two models on one slide distinguished by colors. This pushed to implement not a color attribute to the elements, but to introduce the new concept of layers. An element belongs to one or more layers, this allows to define the usage of this element in different sub model of the main business model, or can also be used to represent alternatives. A nice effect provided by the digital property of the program enables the user to select which elements are visible by toggling the visibility of the different layers. In addition to the layers the fact that in a digital environment components can easily be reused triggered the idea to test alternative representations of the BMO. The combination of the creation sequence and questions defined in the draft document [[[#osterwalder_draft_2007|Osterwalder, 2007]]] generated the idea of the wizard mode. The wizard mode consists of paginating the building blocks in the sequence defined by the document and displaying on each page the corresponding questions. As there are different types of questions, these were regrouped in what is called question sets. The prototype uses the three sets defined by the above mentioned document: Describe (key questions), Assessment, Innovation and Improvements, but new sets could be added at any time to create more specialized wizards. It is noteworthy to point out that when designing a digital experience by copying a physical interaction, certain actions are so natural in the real world that we might forget to model them in the digital world. And if we do model them, they can reveal to be much more complicated than we might have thought. One example is the action of storing miscellaneous sticky notes of elements that have come up, but have not yet been attributed to a specific block. In the real world these sticky notes can be put anywhere on a border of the board or a table, but in the computer application a specific block for temporary elements has to be created and its action made available. This has been done and put into the menu that can be hidden to enable a cleaner view of the model.\\ \\ **Features of the first prototype** * Create, edit, delete elements * Drag and Drop elements between the 9 blocks + 1 temporary list * Assign elements to layers with a context menu * Layers can be filtered * View the classic model or display a wizard mode with additional questions For technical details and reasons for technological choices see chapter four. ===== 3.3 Second Prototype ===== The main objective behind the second prototype was to recreate the interactions of the first prototype and additionally allow testing the possibility to link two elements. Also the new prototype should be a base that allows easy testing of new ideas without having to change too much code. When creating the new data model for this prototype some choices were made to reduce complexity of an already complex model. Therefore, it was decided that the perspectives and building blocks do not have a separate data entity, but are visual construct. For example, the building block is a container simply listing instances of elements. This implies for views to know which elements they have to display, depending on which block they represent. On the data side, the content of a block is only given by aggregation of elements of a specific type, there cannot be any properties saved for a block or a perspective. Another choice was to represent a link between two elements only by the association between these two elements. This choice implies for a link that he is defined or not, but cannot have any attributes. In our model a link represents a strong relationship between two elements, if we had allowed the creation of specific links between two elements with a name, a description and a purpose, the question would have been raised if two elements can have more than one link connecting them, each for a special purpose. In my opinion, this hides information from the model. A better solution would be to create new elements and link them, thereby bringing into the main view the existence of theses interactions. Since the application will have to be able to run on tablet pc or touch screen, all interactions have to be limited to single or double click. Right click or using modifier keys cannot be expected to be available in all devices and should not be used except for optional features. ==== 3.3.1 First Iteration ==== > {{main022.gif}} > {{main023.gif}} Figure 3.2: Screen capture of the first iteration of prototype 2 When recreating the same visual as in the first prototype, the perspective zone have been made collapsible, this was one of the first feature identified as necessary by the earlier prototype, mainly to be able to use the tool on smaller screens. With each element having special attributes, a detail screen for each type of element has been created. This detail screen displayed by double clicking an item also has a tab to allow assignment of the element to layers. A right click context menu like it was used in the previous prototype is forbidden by the defined conventions. The need for a possibility to comment on an element emerged from the first prototype, in this iteration of the prototype it was solved by adding a description attribute to each element. Finally, the special names defined for links was not used in coding, but shows up as labels for the different possible links on the detail screen. Link creation was implemented by drag and dropping one element over the other. The application checks if the operation is authorized by the model constraints before allowing the drop. Since the functionality for link creation was added afterwards and that click operations are limited to single and double click, the simplest solution was to create a second mode for the editor. Therefore, in this first iteration of the second prototype the user had always to change between link or create mode depending on the actions he wanted to execute. In link mode double clicking an element filters the view and shows only the clicked elements and recursively his linked neighbors and their own linked items. Creation of a new element is done through a pop-up appearing when the user double clicks an empty space in a building block. At first the text field had auto complete functionalities, but rapidly it became clear that it was not bringing any value and sometimes even broke the flow of user experience. When the pop-up was launched the user already knew what text he wanted to write in it and did not need suggestions. One argument for the auto complete was facilitating the duplication of an element, but this has been resolved in the second iteration of the prototype by allowing the transformation of the move action into a copy action by applying the ctrl modifier key. ==== 3.3.2 Second Iteration ==== > {{main024.gif}} > {{main025.gif}} Figure 3.3: Screen capture of the second iteration of prototype 2 The first correction that had to be made to the second prototype was merging the two modes (link and create). Working with the model has to be as natural as possible without breaking the workflow by forcing the user to change mode to specify his intentions. Once this was done new features which had been put aside could be added. From the first version of the second prototype emerged the observation that just enabling comments in the form of a description attribute for the elements is not enough. This influenced the creation of an annotation module which enables the creation of annotations for any object that can be drawn in a view: the model itself, layers, perspectives and blocks. To add to the value of annotations different types of annotations are introduced: comments, to-do’s with a priority level and answers to questions of the wizard. The answer to a question is associated with the corresponding question and building blocks, this captures the information of which question inspired the creation of which element. Naturally it would be even better if this information could be directly attached and stored with the element, but this would have required changes in the data model. Having digital systems without some kind of versioning or ability to track changes would not have been of much more value than a paper alternative. Therefore a versioning system had to be implemented. The choice was to implement a system with a combination of branching (cloning) and snapshots. The system works like the snapshot manager from VMware Workstation. At any time, the currently loaded model can be taken as snapshot. This creates a read-only copy of the current state to which the user can go back to. From a read only snapshot a branch can be created. A branch is a copy of a read-only model that can be edited. Initially the system was design to display one model with multiple layers, but the desire was to be able to compare different models. The simplest solution was to allow a merge mode which creates a new model with multiples layers containing all models selected to be merged. Naturally, this system could be improved for future versions to allow a more selective comparison than to put everything on one big canvas. Finally, a concern which had to be addressed was to allow a way to extract in a flat and human readable way, all the information put into one model. These requirements lead to the possibility to generate a report displaying all the information of a model on a webpage. This report contains a thumbnail of the model, all the annotations and all elements with all their attributes and relationships. A more advanced layout or even directly generating other type of files like a PDF or a PowerPoint™presentation could be a possibility. For technical explanations of the prototype and reasons behind technical choices read the next chapter. ====== 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. > {{main026.gif}} 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<sup>[[#note11|1]]</sup>. Then the data itself was quickly input through a web page built with CakePHP<sup>[[#note12|2]]</sup> 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 ext js<sup>[[#note13|3]]</sup> and script.aculo.us<sup>[[#note14|4]]</sup> who call the aforementioned endpoints. The data structure can be seen in figure [[#fig:prot1_db|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. > {{main027.gif}} Figure 4.2: Prototype 1 database schema ==== 4.1.2 Comments ==== 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. === Server === 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<sup>[[#note15|5]]</sup> , 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<sup>[[#note16|6]]</sup>, 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 [[#fig:proto2_vo|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<sup>[[#note17|7]]</sup>, this by automatically configuring object conversion through BlazeDS’s Java API<sup>[[#note18|8]]</sup>. This part takes care of transforming the Java object into an ActionScript object and vis versa. === Client === 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<sup>[[#note19|9]]</sup> to address this problem. For a more detailed structure of the client see appendix [[#sec:client_detail|??]]. ===== 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 [[#tbl:ums|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** tableheader**Sharing** **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 [[#sec:link_call|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<sup>[[#note20|10]]</sup> 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 [[#tbl:tradeoff|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<sup>[[#note21|11]]</sup> . Efficiency of such solutions has yet to be proven. ==== 4.7.2 Non-conventional methods ==== **Google AppEngine**<sup>**[[#note22|12]]**</sup>**:** 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**<sup>**[[#note23|13]]**</sup>**:** Is a prototype of a new type of data store specially design for web applications. It is based on the JSON<sup>[[#note24|14]]</sup> 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**<sup>**[[#note25|15]]**</sup>**:** 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**<sup>**[[#note26|16]]**</sup>**:** 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**<sup>**[[#note27|17]]**</sup>**:** 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**<sup>**[[#note28|18]]**</sup>**:** 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**<sup>**[[#note29|19]]**</sup>**:** 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**<sup>**[[#note30|20]]**</sup>**:** 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<sup>[[#note31|21]]</sup> database to guarantee persistence. ===== 4.9 Comments ===== 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. ---- * **1** [[http://www.mysql.com/|http://www.mysql.com/]] * **2** [[http://cakephp.org/|http://cakephp.org/]] * **3** [[http://extjs.com/|http://extjs.com/]] * **4** [[http://script.aculo.us/|http://script.aculo.us/]] * **5** [[http://grails.org/|http://grails.org/]] * **6** [[http://groovy.codehaus.org/|http://groovy.codehaus.org/]] * **7** [[http://www.adobe.com/products/flex/flexdownloads/index.html|http://www.adobe.com/products/flex/flexdownloads/index.html]] * **8** [[http://opensource.adobe.com/wiki/display/blazeds/BlazeDS|http://opensource.adobe.com/wiki/display/blazeds/BlazeDS]] * **9** [[http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm|http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm]] * **10** [[http://fbflex.wordpress.com/2008/07/26/nine-lessons-from-building-a-grails-flex-flash-website/|http://fbflex.wordpress.com/2008/07/26/nine-lessons-from-building-a-grails-flex-flash-website/]] * **11** Liquidebase: is a library for tracking, managing and applying database changes. [[http://www.liquibase.org/|http://www.liquibase.org/]] * **12** [[http://code.google.com/appengine/|http://code.google.com/appengine/]] * **13** [[http://incubator.apache.org/couchdb/|http://incubator.apache.org/couchdb/]] * **14** [[http://www.json.org/|http://www.json.org/]] * **15** [[http://isi.unil.ch/radixa/recherche/F2/|http://isi.unil.ch/radixa/recherche/F2/]] * **16** [[http://jena.sourceforge.net/|http://jena.sourceforge.net/]] * **17** [[http://silverlight.net/|http://silverlight.net/]] * **18** [[http://code.google.com/webtoolkit/|http://code.google.com/webtoolkit/]] * **19** [[http://code.google.com/apis/gears/|http://code.google.com/apis/gears/]] * **20** [[http://www.adobe.com/products/air/|http://www.adobe.com/products/air/]] * **21** [[http://www.sqlite.org/|http://www.sqlite.org/]] ====== 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) === Tasks === - Create a new empty business model - Add desired elements and layers - Move elements, inside and between blocks - Create links between strongly depended elements - 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) === Tasks === - Open the business model that has to be edited. - 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 === - Create a new empty business model containing only the new parts. - Merge the new business model with the initial model. - Edit the duplicate elements. === Alternative 2 === - 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) === - Add annotations directly to the model, the perspectives or the blocks - Edit the annotations (change text, type) - Filter annotations - Delete annotations === Alternative (Wizard) === - Open the wizard - Choose a question set either assessments or innovation. - Answer some of the question, edit business model as needed. - 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 [[#tab:UserSummary|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. ==== 5.4.2 Main Menu and Perspectives ==== === Action === 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. === Observations === * 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. === Suggestions === 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 ==== === Action === Drag and drop elements, from one place to the other or into the trash can. === Observations === 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. === Suggestions === 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_usability_2002|Rosson and Carroll, 2002]], Tradeoff 4.7 p. 129] ==== 5.4.4 Click Interaction and Menu ==== === Action === 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. === Observations === 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. === Analysis === 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. === Suggestions === 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. ==== 5.4.5 Link ==== === Action === 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. === Observations === 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. === Suggestions === 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 ==== === Action === Edit attribute fields and close the dialog with the x in the upper right to save changes. === Observations === 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. === Suggestions === 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_usability_2002|Rosson and Carroll, 2002]], Tradeoff 3.3 p. 84] ==== 5.4.7 Layers ==== === Action === 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. === Observations === 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. === Suggestions === 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_usability_2002|Rosson and Carroll, 2002]], Tradeoff 4.1 p. 115] ==== 5.4.8 Annotations ==== === Action === 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. === Observations === 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_usability_2002|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. === Suggestions === 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 ==== === Action === Answer or comment a question to keep track of the thought process. === Observations === There was a mix-up between a question’s answer and creating new element as a response in the block displayed underneath. === Suggestions === 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_usability_2002|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-Beam<sup>[[#note32|1]]</sup> interact solution to test the application. The setup can be seen in figure [[#fig:prot2wall|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. > {{main028.gif}} 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. ---- * **1** [[http://e-beam.com/|http://e-beam.com/]] ====== Chapter 6 Further Research ====== > {{main029.gif}} 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_gettingright_2007|Gartner, 2007]]] based on the typology defined by [[[#weill_dobusiness_2004|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_modelingbusiness_2004|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 ===== > {{main030.gif}} 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] {{main031.gif}} [registration screen] {{main032.gif}} ==== 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 ===== > {{main033.gif}} Figure A.2: Home Screen On this screen the users can see all the models to which he has rights (figure [[#help:home_screen|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 ===== > {{main034.gif}} 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 ==== > {{main035.gif}} 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 ==== > {{main036.gif}} 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] {{main037.gif}} [detail window] {{main038.gif}} 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 === > {{main039.gif}} 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! ==== A.5.8 Link Mode ==== > {{main040.gif}} 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. === View links === 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. === Exit link mode === Exiting link mode can be done by clicking the yellow message bar or by double-clicking on an empty space in a building block. === Create links === 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. === Delete links === 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 ==== > {{main041.gif}} 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: * {{main042.gif}} there are no annotations for this item{{main043.gif}} there are annotations for this item{{main044.gif}} 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 ===== > {{main045.gif}} 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 ({{main046.gif}}) 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 ===== > {{main047.gif}} Figure A.11: Snapshot Manager > [click on snapshot] {{main048.gif}} [menu] {{main049.gif}} [click on active model] {{main050.gif}} 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 ===== > {{main051.gif}} 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 ===== ==== A.9.1 Difficulty drag and dropping (move vs. link) ==== 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 [[#bm_amazon|B.179Amazon: classic and S3 servicesfigure.B.1]] and [[#bm_apple|??]] show two real world examples of models entered into the prototype. Images are exported from de report generation feature. Business models courtesy of Arvetica. > {{main052.gif}} Figure B.1: Amazon: classic and S3 services > {{main053.gif}} Figure B.2: Apple: iPod and iTunes ====== Appendix C Technical Supplements ====== ===== C.1 Prototype 2 Server Domain Classes ===== Figure [[#fig:proto2_vo|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. > {{main054.gif}} Figure C.1: Prototype 2 server domain classes and attributes ===== C.2 Prototype 2 Client Classes ===== Figure [[#fig:proto2_struc|??]] 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. > {{main055.gif}} 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 [[#fig:call_link_demo|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. > {{main056.gif}} 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 ==== * [[http://apache.org/|Apache 2.2.9]] * [[http://mysql.com/|MySQL 5.0.51]] * [[http://php.net/|PHP 5.2.6]] * [[http://cakephp.org/|cakephp 1.2 RC1]] * [[http://extjs.com/|ExtJS 2.0]] ==== C.4.2 Prototype 2 ==== **Client** * [[http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK|Flex 3 SDK]] * [[http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm|Cairngorm]] MVC framework for flex * [[http://code.google.com/p/flexlib/|flexlib]] advanced visual components * [[http://code.google.com/p/birdeye/wiki/RaVis|birdeye libRaVis]] graph used for Snapshot Manager * [[http://www.wietseveenstra.nl/blog/2007/04/flex-superpanel-v15/|SuperPanel]] resizable panel used for annotations **Server** * [[http://java.sun.com/|Java 1.6]] * [[http://mysql.com/|MySQL 5.0.32]] * [http://grails.org/|Grails 1.0.4]] * [[http://grails.org/Flex+Plugin|Grails-flex plugin 0.2]] **Assets** * [[http://www.famfamfam.com/lab/icons/mini/|fam fam fam]] icons for annotations * [[http://www.kde-look.org/content/show.php/home+and+trash+icon+set?content=63129|trashcan]] ====== References ====== * **[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|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-mod%el.html|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.1232113026.txt.gz · Dernière modification: d-m-Y H:i par boris