Warning: Declaration of action_plugin_authad::register(Doku_Event_Handler &$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/authad/action.php on line 89

Warning: Declaration of action_plugin_editsections::register(&$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/editsections/action.php on line 72

Warning: Declaration of action_plugin_importoldchangelog::register(&$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/importoldchangelog/action.php on line 157

Warning: Declaration of action_plugin_tag::register(&$contr) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/tag/action.php on line 79
Chapter 3 Design of The Prototype [HEC 4 ALL]

Chapter 2 Business Model Ontology Refinement and Visualization

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

Figure 3.1: Screen captures of the first prototype
BMO design mode (a.) wizard mode (b.)

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

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

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

tm/chapter3.txt · Dernière modification: d-m-Y H:i par boris
chimeric.de = chi`s home Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0 Fristcher.ch