Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révision Les deux révisions suivantes | ||
tm:business_model_designer_from_sticky_note_to_screen_interaction [d-m-Y H:i] boris |
tm:business_model_designer_from_sticky_note_to_screen_interaction [d-m-Y H:i] boris |
||
---|---|---|---|
Ligne 10: | Ligne 10: | ||
December 2008 | December 2008 | ||
- | **Abstract** | + | ===== 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, | 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, | ||
- | ====== Acknowledgements ====== | + | ===== Content (Html Version) |
- | 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. | + | * [[tm: |
+ | * [[tm: | ||
+ | * [[tm: | ||
+ | * [[tm: | ||
+ | * [[tm: | ||
+ | * [[tm: | ||
+ | * [[tm: | ||
+ | * [[tm: | ||
+ | * [[tm: | ||
+ | * [[tm: | ||
- | [[http://business-model-design.blogspot.com/|Alexander Osterwalder]] thanks for providing real world examples of business models. Your optimism and comments have always motivated me to push farther. | + | * [[http://www.fritscher.ch/ |
- | Particular thanks go also to all individuals who helped test the prototypes and provided invaluable feedback. | + | ===== Other Formats ===== |
- | ====== | + | < |
+ | <object id=" | ||
+ | </ | ||
- | 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: | + | < |
+ | <object id=" | ||
+ | </ | ||
- | * 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, | ||
- | * 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 | + | ===== Acknowledgements ===== |
- | ===== 4.1 Prototype 1 ===== | + | 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. |
- | ==== 4.1.1 Architecture ==== | + | [[http:// |
- | The data structure has been created in [[http:// | + | Particular thanks go also to all individuals |
- | + | ||
- | The data structure can be seen in figure [[# | + | |
- | + | ||
- | > {{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/ | + | |
- | + | ||
- | ==== 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 [[http:// | + | |
- | + | ||
- | 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 [[# | + | |
- | + | ||
- | There is also a plugin that allows transformation of methods into RPC services for [[http:// | + | |
- | + | ||
- | === 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/ | + | |
- | + | ||
- | 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 [[http:// | + | |
- | + | ||
- | ===== 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 [[# | + | |
- | + | ||
- | > **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/ | + | |
- | + | ||
- | > **Options** ACL user and BM relation can be augmented with permissions (view, edit), | + | |
- | + | ||
- | + | ||
- | 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 [[# | + | |
- | + | ||
- | ===== 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 ([[http:// | + | |
- | + | ||
- | 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 | + | |
- | + | ||
- | ===== 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 [[# | + | |
- | + | ||
- | > **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, | + | |
- | + | ||
- | 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: | + | |
- | + | ||
- | ==== 4.7.2 Non-conventional methods ==== | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | Recently the project has gotten support from the Apache Software Foundation, the project defines itself as: distributed, | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | **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, | + | |
- | + | ||
- | ===== 4.8 Other technologies ===== | + | |
- | + | ||
- | ==== 4.8.1 Clients ==== | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | ==== 4.8.2 Offline ==== | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | **[[http:// | + | |
- | + | ||
- | As in the last Firefox version, both Google Gears and Adobe Air rest on a local [[http:// | + | |
- | + | ||
- | ===== 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/ | + | |
- | + | ||
- | From the overview emerges the observation that web application or desktop application, | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | ====== 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, | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | === 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, | + | |
- | + | ||
- | > **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, | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | 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’ [[[# | + | |
- | + | ||
- | ==== 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 | + | |
- | + | ||
- | Advanced user had trouble with the fact that there are no right click possibilities, | + | |
- | + | ||
- | 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/ | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | ==== 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, | + | |
- | + | ||
- | 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’ [[[# | + | |
- | + | ||
- | ==== 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, | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | ==== 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. | + | |
- | + | ||
- | ===== 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< | + | |
- | + | ||
- | > {{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, | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | 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:// | + | |
- | + | ||
- | ====== 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 [[[# | + | |
- | + | ||
- | Another type of custom wizard could be to apply patterns, for example, asking specific question when planning to do known transformations like: outsourcing, | + | |
- | + | ||
- | ===== 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’ [[[# | + | |
- | + | ||
- | ===== 6.5 Simulation ===== | + | |
- | + | ||
- | Having viable validation of the links and the ability to add cost information or even production percentages, | + | |
- | + | ||
- | ===== 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/ | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | ===== 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, | + | |
- | + | ||
- | 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 // | + | |
- | + | ||
- | 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, | + | |
- | + | ||
- | There are three types of annotations: | + | |
- | + | ||
- | ===== 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 [[# | + | |
- | + | ||
- | 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”, | + | |
- | + | ||
- | ===== 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, | + | |
- | + | ||
- | 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/ | + | |
- | + | ||
- | ==== 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/ | + | |
- | + | ||
- | ====== Appendix B Sample Business Models ====== | + | |
- | + | ||
- | Figures [[# | + | |
- | + | ||
- | > {{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 ===== | + | |
- | + | ||
- | | + | |
- | + | ||
- | 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 [[# | + | |
- | + | ||
- | 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 [[# | + | |
- | + | ||
- | > {{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:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | + | ||
- | ==== C.4.2 Prototype 2 ==== | + | |
- | + | ||
- | **Client** | + | |
- | + | ||
- | * [[http:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | + | ||
- | **Server** | + | |
- | + | ||
- | * [[http:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | * [[http:// | + | |
- | + | ||
- | **Assets** | + | |
- | + | ||
- | * [[http:// | + | |
- | * [[http:// | + | |
- | ====== References | + | ===== References ===== |
* **[Eppler and Burkhard, 2004]** Eppler, M. J. and Burkhard, R. A. (2004). Knowledge visualization towards a new discipline and its fields of application. | * **[Eppler and Burkhard, 2004]** Eppler, M. J. and Burkhard, R. A. (2004). Knowledge visualization towards a new discipline and its fields of application. |