JACKSON MATTHEW O (US)
ZHANG BEILIN (US)
WANG STEPHANIE W (US)
YUAN MIAO WALTER (US)
JACKSON MATTHEW O (US)
ZHANG BEILIN (US)
WANG STEPHANIE W (US)
| WHAT IS CLAIMED IS: 1. A method comprising: receiving, using one or more processors, a signal to create a playlist from a first user; creating, using the one or more processors, an empty playlist, responsive to receiving the signal; receiving, using the one or more processors, a first template for a first game; and populating, using the one or more processors, the playlist based on the first template for the first game. 2. The method of claim 1 comprising: receiving, using the one or more processors, a second template for a second game; and populating, using the one or more processors, the playlist with the second template for the first game. 3. The method of claim 2 wherein the order of the first template and the second template in the playlist determines an order in which the first game and the second game are executed. 4. The method of claim 2 wherein the first game and second game simulate real- world economic interactions. 5. The method of claim 2 comprising: receiving, using the one or more processors, a signal to modify an order of the first and second game; modifying, using the one or more processors, the order of the first and second game in the playlist; and executing, using the one or more processors, the first game and the second game in the modified order. 6. The method of claim 1 wherein the playlist may be shared by the first user with a second user. 7. The method of claim 1 comprising: receiving, using the one or more processors, at least one parameter for the first game; and executing the first game using the received parameter. 8. A computer program product comprising a computer usable medium including a computer readable program, wherein the computer readable program when executed on a computer causes the computer to: receive a signal to create a playlist from a first user; create an empty playlist, responsive to receiving the signal; receive a first template for a first game; and populate the playlist based on the first template for the first game. 9. The computer program product of claim 8 wherein the computer readable program when executed on a computer also causes the computer to: receive a second template for a second game; and populate the playlist with the second template for the first game. 10. The computer program product of claim 9 wherein the order of the first template and the second template in the playlist determines an order in which the first game and the second game are executed. 1 1. The computer program product of claim 9 wherein the first game and second game simulate real-world economic interactions. 12. The computer program product of claim 8 wherein the computer readable program when executed on a computer also causes the computer to: receive a signal to modify an order of the first and second game; modify the order of the first and second game in the playlist; and execute the first game and the second game in the modified order. 13. The computer program product of claim 8 wherein the playlist may be shared by the first user with a second user. 14. The computer program product of claim 8 wherein the computer readable program when executed on a computer also causes the computer to: receive at least one parameter for the first game; and execute the first game using the received parameter. 15. A system comprising: a processor; and a memory storing instructions that, when executed, cause the system to: receive a signal to create a playlist from a first user; create an empty playlist, responsive to receiving the signal; receive a first template for a first game; and populate the playlist based on the first template for the first game. 16. The system of claim 8 wherein the memory also stores instructions that, when executed, cause the system to: receive a second template for a second game; and populate the playlist with the second template for the first game. 17. The system of claim 9 wherein the order of the first template and the second template in the playlist determines an order in which the first game and the second game are executed. 18. The system of claim 9 wherein the first game and second game simulate real- world economic interactions. 19. The system of claim 8 wherein the memory also stores instructions that, when executed, cause the system to: receive a signal to modify an order of the first and second game; modify the order of the first and second game in the playlist; and execute the first game and the second game in the modified order. 20. The computer program product of claim 8 wherein the computer readable program when executed on a computer also causes the computer to: receive at least one parameter for the first game; and execute the first game using the received parameter. |
[01] The specification relates to electronic services. In particular, the specification relates to online interactive experimentations.
BACKGROUND
[02] With advent of personal computer, smart phones and tablets, there have been attempts to augment the classroom experience with these devices as well as use the for distance learning. Classrooms have typically been used for lectures augmented by chalkboard and more recently overhead slides and PowerPoint presentations. However, this lecture format even when a Socratic method is used is not the best vehicle for teaching students and providing clear education about complex topics. One problem with the lecture format is that it is not interactive, and is not the way many learn. With the increased use of technology in society, students learn better with experience and narrative. Especially, future generations of students learn differently from us, as technology is an integral part of their upbringing. Existing methods and systems do not provide effective teaching constructs for learning complex and abstract concepts in the classroom. One way to teach complex and abstract concepts is by through playing games and relating with concrete context through games. Sometime past teachers have run games or experiments as a teaching vehicle, but the time required to collect and collate data takes up too much valuable class time. Moreover, it is difficult to modify the games, rerun them or adapt them to different uses in the classroom. Finally, there are not mechanisms in the prior art to share and reuse content, games and game results. Therefore, there is a need for systems and method that provide better interactivity between students and the teacher to learn new concepts. SUMMARY
[03] The specification overcomes deficiencies and limitations of the prior art at least in part by providing a system and methods for providing interactive experimentations to users.
[04] In one embodiment, a system includes a processor and a memory storing instructions that, when executed, cause the system to: receive a signal to create a playlist from a first user; create an empty playlist, responsive to receiving the signal; receive a first template for a first game; and populate the playlist based on the first template for the first game.
[05] In one embodiment, the method comprises receiving, using one or more processors, a signal to create a playlist from a first user; creating, using the one or more processors, an empty playlist, responsive to receiving the signal; receiving, using the one or more processors, a first template for a first game; and populating, using the one or more processors, the playlist based on the first template for the first game.
[06] Other implementations of one or more of these aspects include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.
[07] The features and advantages described herein are not all-inclusive and many additional features and advantages will be apparent in view of the figures and description. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and not to limit the scope of the subject matter disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS
[08] The embodiments are illustrated by way of example, and not by way of limitation in the figures of the accompanying drawings in which like reference numerals are used to refer to similar elements.
[09] Figure 1 A illustrates a system for providing interactive experimentations to users according to one embodiment.
[010] Figure IB illustrates a system for providing interactive experimentations to users according to another embodiment. [011] Figure 2A is a block diagram illustrating an experimentation server according to one embodiment.
[012] Figure 2B is a block diagram illustrating an experimentation server according to another embodiment.
[013] Figure 3 is a block diagram illustrating an interactive experimentation module according to one embodiment.
[014] Figure 4 is a flow chart illustrating a method for creating a playlist according to one embodiment.
[015] Figure 5 is a flow chart illustrating a method for creating a playlist according to another embodiment. [016] Figure 6 are flow charts illustrating a method for setting up an account for a user according to one embodiment.
[017] Figure 7A is a flow chart illustrating a method for allowing users to join games according to one embodiment. [018] Figure 7B is a flow chart illustrating a method for adding users as participants to a playlist according to one embodiment.
[019] Figure 7C is a flow chart illustrating a method for allowing users to play games according to one embodiment.
[020] Figure 8 is a flow chart illustrating a method for running a demo according to one embodiment.
[021] Figure 9A is a flow chart illustrating a method for generating a result for a game according to one embodiment.
[022] Figure 9B is a flow chart illustrating a method for analyzing user behavior in a game according to one embodiment.
[023] Figure 10 is a graphical representation illustrating a user interface for allowing users to create a class according to one embodiment.
[024] Figure 11 is a graphical representation illustrating a user interface for displaying class information to users according to one embodiment.
[025] Figure 12 is a graphical representation illustrating a user interface for displaying a class code to a user according to one embodiment.
[026] Figure 13 is a graphical representation illustrating a user interface allowing users to share a class with other users according to one embodiment.
[027] Figure 14 is a graphical representation illustrating a user interface for creating a playlist for users according to one embodiment.
[028] Figure 15 is a graphical representation illustrating a user interface for copying a playlist to a class according to one embodiment. [029] Figure 16 is a graphical representation illustrating a user interface for displaying instructions about how to populate a playlist according to one embodiment.
[030] Figure 17 is a graphical representation illustrating a user interface for displaying a created playlist according to one embodiment.
[031] Figure 18 is a graphical representation illustrating a user interface for displaying a configuration setting for a Bargaining game according to one embodiment.
[032] Figure 19 is a graphical representation illustrating a user interface for requesting a user to input the number of players that the user wants to play with in a demo of a game according to one embodiment.
[033] Figure 20 is a graphical representation illustrating a user interface for displaying a demo of the Bargaining game according to one embodiment.
[034] Figure 21 is a graphical representation illustrating a user interface for displaying a result of the demo of the Bargaining game according to one embodiment.
[035] Figure 22 is a graphical representation illustrating a user interface for displaying a summary of the demo for the Bargaining game according to one embodiment.
[036] Figure 23 is a graphical representation illustrating a user interface for displaying an analysis result of the demo for the Bargaining game according to one embodiment.
[037] Figure 24 is a graphical representation illustrating a user interface for displaying an analysis result of the demo for the Bargaining game according to one embodiment.
[038] Figure 25 is a graphical representation illustrating a user interface for displaying a class roster according to one embodiment. [039] Figure 26 is a graphical representation illustrating a user interface for displaying a list of available playlists for a user who registers with a class according to one embodiment.
[040] Figure 27 is a graphical representation illustrating a user interface for displaying an indication that the instructor of the class has allowed students to join a playlist according to one embodiment.
[041] Figure 28 is a graphical representation illustrating a user interface for displaying the available playlists for a user according to one embodiment.
[042] Figure 29 is a graphical representation illustrating a user interface for displaying an indication that one participant is playing games in a playlist according to one embodiment.
[043] Figure 30 is a graphical representation illustrating a user interface for displaying information of the participant who is playing games in a playlist according to one embodiment. [044] Figure 31 is a graphical representation illustrating a user interface that allows users to choose different patterns to replay a game according to one embodiment.
[045] Figure 32 is a graphical representation illustrating a user interface that allows users to input notes according to one embodiment.
[046] Figure 33 is a graphical representation illustrating a user interface that displays tools for users to learn about a game in the library according to one embodiment.
[047] Figure 34 is a graphical representation illustrating a user interface for displaying a manual of how to play a game according to one embodiment. [048] Figure 35 is a graphical representation illustrating a user interface for displaying a demo of a game according to one embodiment.
[049] Figure 36 is a graphical representation illustrating a user interface for displaying class instructions for a game according to one embodiment. [050] Figure 37 is a graphical representation illustrating a user interface that allows users to view different categories of games from the library according to one embodiment.
[051] Figure 38 is a graphical representation illustrating a user interface that displays a guide of the online interactive lab system according to one embodiment.
[052] Figure 39 is a graphical representation illustrating a user interface that displays parameters for configuring an Ultimatum game and a Dictator game according to one embodiment.
[053] Figure 40 is a graphical representation illustrating a user interface that displays parameters for configuring a Trust game and a Herding game according to one embodiment.
[054] Figure 41 is a graphical representation illustrating a user interface that displays parameters for configuring a game of Market for Lemons and a Continuous Market game according to one embodiment.
[055] Figure 42 is a graphical representation illustrating a user interface that displays parameters for configuring a game of Matching Pennies according to one embodiment.
[056] Figure 43 is a graphical representation illustrating a user interface that displays parameters for configuring a Matrix game according to one embodiment.
[057] Figure 44 is a graphical representation illustrating a user interface that displays parameters for configuring a game of Prisoner Dilemma and an Election game according to one embodiment. [058] Figure 45 is a graphical representation illustrating a user interface that displays parameters for configuring a game of Ascending Clock Auction and a game of Descending Clock Auction according to one embodiment.
[059] Figure 46 is a graphical representation illustrating a user interface that displays parameters for configuring a game of Private Value Auctions and a game of Common Value Auctions according to one embodiment.
[060] Figure 47 is a graphical representation illustrating a user interface that displays parameters for configuring a Guessing game and a game of Tragedy of the Commons according to one embodiment. [061] Figure 48 is a graphical representation illustrating a user interface that displays parameters for configuring an Oligopoly game and a Minimum Effort game according to one embodiment.
[062] Figure 49 is a graphical representation illustrating a user interface that displays parameters for configuring a game of Linear Public Goods and a game of Threshold Public Goods according to one embodiment.
[063] Figure 50 is a graphical representation illustrating a user interface that allows users to input questions according to one embodiment.
[064] Figure 51 is a graphical representation illustrating a user interface that allows users to play the ultimatum game according to one embodiment. [065] Figure 52 is a graphical representation illustrating a user interface that displays how users play the Dictator game according to one embodiment.
[066] Figure 53 is a graphical representation illustrating a user interface that allows users to play the Trust game according to one embodiment. [067] Figure 54 is a graphical representation illustrating a user interface that allows users to play the Herding game according to one embodiment.
[068] Figure 55 is a graphical representation illustrating a user interface that allows users to play the game of Market for Lemons according to one embodiment.
[069] Figure 56 is a graphical representation illustrating a user interface that allows users to play the Continuous Market game according to one embodiment.
[070] Figure 57 is a graphical representation illustrating a user interface that allows users to play the game of Matching Pennies according to one embodiment.
[071] Figure 58 is a graphical representation illustrating a user interface that allows users to play the Matrix game according to one embodiment.
[072] Figure 59 is a graphical representation illustrating a user interface that allows users to play the Prisoner Dilemma game according to one embodiment.
[073] Figure 60 is a graphical representation illustrating a user interface that allows users to play the Election game according to one embodiment.
[074] Figure 61 is a graphical representation illustrating a user interface that allows users to play the Election game according to another embodiment.
[075] Figure 62 is a graphical representation illustrating a user interface that allows users to play the game of Ascending Clock Auction according to one embodiment.
[076] Figure 63 is a graphical representation illustrating a user interface that allows users to play the game of Descending Clock Auction according to one embodiment.
[077] Figure 64 is a graphical representation illustrating a user interface that allows users to play the game of Private Value Auction according to one embodiment. [078] Figure 65 is a graphical representation illustrating a user interface that allows users to play the game of Common Value Auctions according to one embodiment.
[079] Figure 66 is a graphical representation illustrating a user interface that allows users to play the Guessing game according to one embodiment.
[080] Figure 67 is a graphical representation illustrating a user interface that displays how users play the Guessing game according to one embodiment.
[081] Figure 68 is a graphical representation illustrating a user interface that allows users to play the game of Tragedy of the Commons according to one embodiment.
[082] Figure 69 is a graphical representation illustrating a user interface that displays how users play the game of Tragedy of the Commons according to one embodiment.
[083] Figure 70 is a graphical representation illustrating a user interface that allows users to play the Oligopoly game according to one embodiment.
[084] Figure 71 is a graphical representation illustrating a user interface that displays how users play the Oligopoly game according to one embodiment.
[085] Figure 72 is a graphical representation illustrating a user interface that allows users to play the Minimum Effort game according to one embodiment.
[086] Figure 73 is a graphical representation illustrating a user interface that displays how users play the Minimum Effort game according to one embodiment.
[087] Figure 74 is a graphical representation illustrating a user interface that allows users to play the Linear Public Goods game according to one embodiment.
[088] Figure 75 is a graphical representation illustrating a user interface that allows users to play the Threshold Public Goods game according to one embodiment. [089] Figure 76 is a graphical representation illustrating a user interface that displays an analysis result for the Election game according to one embodiment.
[090] Figure 77 is a graphical representation illustrating a user interface that displays an analysis result for the game of Ascending Clock Auction according to one embodiment.
[091] Figure 78 is a graphical representation illustrating a user interface that displays an analysis result for the game of Private Value Auctions according to one embodiment.
[092] Figure 79 is a graphical representation illustrating a user interface that displays an analysis result for the game of Common Value Auctions according to one embodiment.
[093] Figure 80 is a graphical representation illustrating a user interface that displays an analysis result for the Guessing game according to one embodiment.
[094] Figure 81 is a graphical representation illustrating a user interface that displays an analysis result for the Oligopoly game according to one embodiment.
[095] Figure 82 is a graphical representation illustrating a user interface that displays an analysis result for the game of Linear Public Goods according to one embodiment.
[096] Figure 83 is a graphical representation illustrating a user interface that displays an analysis result for the Ultimatum game according to one embodiment.
[097] Figure 84 is a graphical representation illustrating a user interface that displays an analysis result for the Dictator game according to one embodiment.
[098] Figure 85 is a graphical representation illustrating a user interface that displays an analysis result for the Prisoner Dilemma game according to one embodiment.
[099] Figure 86 is a graphical representation illustrating a user interface that displays an analysis result for the Herding game according to one embodiment. [0100] Figure 87 is a graphical representation illustrating a user interface that displays an analysis result for the game of Market for Lemons according to one embodiment.
[0101] Figure 88 is a graphical representation illustrating a user interface that displays an analysis result for the continuous market game according to one embodiment.
[0102] Figure 89 is a graphical representation illustrating a user interface that displays an analysis result for the game of Matching Pennies according to one embodiment.
[0103] Figure 90 is a graphical representation illustrating a user interface that displays an analysis result for the Matrix game according to one embodiment.
[0104] Figure 91 is a block diagram illustrating a system for providing interactive experimentations to users according to yet another embodiment.
[0105] Figure 92 is a block diagram illustrating architecture for the system that provides interactive experimentations to users according to one embodiment.
[0106] Figure 93 is a block diagram illustrating architecture for data service included in the system that provides interactive experimentations to users according to one embodiment.
[0107] Figures 94A adm 94B are flow charts illustrating a method for processing payments by the monetization module according to one embodiment.
DETAILED DESCRIPTION
[0108] A system and method for providing online interactive experimentations to users is described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the
embodiments. It will be apparent, however, that the embodiments can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the embodiments. For example, one embodiment is described below with reference to user interfaces and particular hardware. However, the present embodiments apply to any type of computing device that can receive data and commands, and any peripheral devices providing services. [0109] Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment. [0110] Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like.
[0111] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms including, for example, "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
[0112] The present embodiments also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, including, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, flash memories including USB keys with non-volatile memory or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.
[0113] The embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. An exemplary embodiment is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. [0114] Furthermore, the embodiments can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. [0115] A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
[0116] Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. [0117] Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
[0118] Finally, the algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present embodiments are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the embodiments as described herein. System Overview
[0119] Figure 1A illustrates a block diagram of a system 100a for providing online interactive experimentations to users according to one embodiment. The illustrated system 100a includes client devices 1 15a and 1 15n (also referred to collectively as client devices 115 or individually as client device 1 15) that are accessed by users 125a and 125n (also referred to collectively as users 125 or individually as user 125), an experimentation server 101a, and a third-party server 109. In the illustrated embodiment, these entities are communicatively coupled via a network 105. The third-party server 109 is merely an example and the system 100a in some implementations can include a document server, a blogging server, a news feed server, a video sharing server, a photo sharing server, a map server and any other third party server, etc.
[0120] The client devices 115 in Figure 1A are used by way of example. While
Figure 1A illustrates two client devices 115, the present specification applies to any system architecture having one or more client devices 1 15. Furthermore, while only one network 105 is coupled to the client devices 115, the experimentation server 101 and the third-party server 109, in practice any number of networks 105 can be connected to the entities.
Furthermore, while Figure 1A illustrates one experimentation server 101, the present specification applies to any system architecture having one or more experimentation servers 101. Furthermore, while only one third-party server 109 is shown, the system 100a can include any number of third-party servers 109.
[0121] In one embodiment, an interactive experimentation module 220a is included in the experimentation server 101 and is operable on the experimentation server 101, which is connected to the network 105 via signal line 104. In another embodiment, an interactive experimentation module 220b is included in the third-party server 109 and is operable on the third-party server 109, which is connected to the network 105 via signal line 118. In yet another embodiment, an interactive experimentation module 220c is included in the client device 1 15a and is operable on the client device 1 15a, which is connected to the network 105 via signal line 112. In yet another embodiment, an interactive experimentation module 220n is included in the client device 115n and is operable on the client device 115n, which is connected to the network 105 via signal line 114. It will be recognized that the interactive experimentation module 220a/220b/220c/220n (referred to generally as the multimedia publisher module 220) can be stored in any of one or more experimentation servers 101, one or more third-party servers 109, one or more client devices 115 or a combination thereof. In some embodiments, the interactive experimentation module 220 includes multiple, distributed modules that cooperate with each other to perform the functions described below. Details describing the functionality and components of the interactive experimentation module 220 are explained in further detail below in reference to Figure 3. [0122] While shown as operational on one of the experimentation server 101, the third-party server 109 and the client device 115 in Figure 1A, in some embodiments, all or part of the interactive experimentation module 220 may be operational on any other servers which the system 100a can include and are connected to the network 105. The interactive experimentation module 220 interacts with the servers 101, 109 and other servers via the network 105.
[0123] In one embodiment, the interactive experimentation module 220 can be integrated with an application program interface (API) on a third-party platform so that the interactive strategic games for unprecedented large-scale social science studies can be combined with the access of vast human subject pool available on the third-party platform. [0124] The network 105 enables communications between client devices 1 15, the experimentation server 101, the third-party server 109 and other servers. Thus, the network 105 can include links using technologies including, for example, Wi-Fi, Wi-Max, 2G, Universal Mobile Telecommunications System (UMTS), 3G, Ethernet, 802.11, integrated services digital network (ISDN), digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc. Similarly, the networking protocols used on the network 105 can include the transmission control protocol/Internet protocol (TCP/IP), multi-protocol label switching (MPLS), the User Datagram Protocol (UDP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), lightweight directory access protocol (LDAP), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications (GSM), High-Speed Downlink Packet Access (HSDPA), etc. The data exchanged over the network 105 can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), JavaScript Object Notation (JSON), Comma Separated Values (CSV), etc. In addition, all or some of links can be encrypted using conventional encryption technologies, for example, the secure sockets layer (SSL), Secure HTTP (HTTPS) and/or virtual private networks (VPNs) or Internet Protocol security (IPsec). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above. Depending upon the embodiment, the network 105 can also include links to other networks.
[0125] In one embodiment, the network 105 is a partially public or a wholly public network, for example, the Internet. The network 105 can also be a private network or include one or more distinct or logical private networks (e.g., virtual private networks, Wide Area Networks ("WAN") and/or Local Area Networks ("LAN")). Additionally, the communication links to and from the network 105 can be wire line or wireless (i.e., terrestrial or satellite-based transceivers). In one embodiment, the network 105 is an IP-based wide or metropolitan area network.
[0126] In the illustrated embodiment, the client devices 115a and 1 15n are coupled to the network 105 via signal lines 112 and 1 14, respectively. The user 125 a can interact with the client device 1 15a. Similarly, the user 125n can interact with the client device 115n. In one embodiment, a client device 115 is an electronic device. In one embodiment, the client device 1 15 interacts with the various servers 101, 109, and other client devices 1 15 of the system 100a via the network 105. The client device 115 can be, for example, a laptop computer, a desktop computer, a tablet computer, a mobile telephone, a personal digital assistant (PDA), a mobile email device, a portable game player, a portable music player, a television with one or more processors embedded therein or coupled thereto, or any other electronic device capable of accessing a network. It will be recognized that other types of client devices 115 are possible. In one embodiment, the system 100a comprises a
combination of different types of client devices 1 15. For example, a combination of a personal computer and a mobile phone. The user 125 is a human user of the client device 1 15. In some embodiments, the client device 1 15 includes Android and iOS devices, including iPod Touch, iPad and iPhone, in the form of native apps, as well as all major web browsers that support HTML5 and JavaScript. [0127] Figure IB illustrates a block diagram of a system 100b for providing online interactive experimentations to users according to another embodiment. The illustrated system 100b includes the same or similar components as those in the system 100a, for example, the client devices 1 15a and 1 15n (also referred to collectively as client devices 1 15 or individually as client device 115) that are accessed by users 125a and 125n (also referred to collectively as users 125 or individually as user 125) and a third-party server 109. The illustrated system 100b also includes an experimentation server 101b and a template server 107 which is connected to a library 130 via signal line 102. In one embodiment, the combination of the experimentation server 101b and the template server 107 implements the functionality of the experimentation server 101a in the system 100a. In other words, the experimentation server 101a also includes a template server 107 connected to the library 130, as shown in Figure 2A which will be described in further detail below. In the illustrated embodiment, these entities 101b, 107, 109, 1 15 are communicatively coupled via a network 105. The servers 107, 109 are merely examples and the system 100b in some
implementations includes a document server, a blogging server, a news feed server, a video sharing server, a photo sharing server, a map server and any other third party server, etc.
[0128] In one embodiment, the template server 107 is a server having one or more processors, memory and communication capabilities for creating and managing templates of games. In one embodiment, the template server 107 also constructs the library 130 that stores the templates of games. For example, the library 130 may be a NoSQL database. The template server 107 is coupled to the network 105 via signal line 1 16 for communication with the other components in the system 100b. For example, the template server 107 receives queries about one or more templates of games from another entity, e.g., the experimentation server 101b, the third-party server 109, the client device 1 15, searches for the one or more queried templates in the library 130 and provides the one or more templates to the server via the network 105. In one embodiment, the template server 107 creates templates for games. For example, the template server 107 generates templates based on economic models. In one embodiment, the template server 107 retrieves templates for games from one or more resources via the network 105, e.g., other servers providing economic templates or models.
[0129] In one embodiment, a game template is a template including information about a game or information for constructing a game. For example, a game template can have a set of parameters that allow one or more games to be configured and extended. In one embodiment, a game template may be generated by combining distilled information from relevant academic papers with past experiences. For example, the template server has a module (not pictured) that filtered the information from economic academic articles based on past education and research experience and generate a game template as a result of the combination of the filtered information. Therefore, the game template contains not only the set of parameters to allow one or multiple concrete games to be extended, but also a robust flow of logic to ensure game execution at runtime. The game templates may correspond or mimic any variety of real world social or economic interactions between parties/users.
Example Experimentation Server 101a, 101b
[0130] Figure 2A is a block diagram of an experimentation server 101a for providing online interactive experimentations to users 125 according to one embodiment. As illustrated in Figure 2A, the experimentation server 101a includes a network adapter 202 coupled to a bus 204. According to one embodiment, also coupled to the bus 204 are at least one processor 206, memory 208, a graphics adapter 210, an input device 212 and a storage device 214. The memory 208 stores one or more modules, which are executed by the processor 206. In one embodiment, the functionality of the bus 204 is provided by an interconnecting chipset. In one embodiment, the experimentation server 101a also includes a display 218, which is coupled to the graphics adapter 210. In one embodiment, the experimentation server 101a also includes a template server 107 connected to a library 130 via signal line 102, which is depicted in Figure IB as a separate server from the experimentation server 101b of the system 100b. The functionalities of the template server 107 will not be repeated herein. [0131] The processor 206 may be any general-purpose processor. The processor 206 comprises an arithmetic logic unit, a microprocessor, a general purpose controller or some other processor array to perform computations and execute code and routines. The processor 206 is coupled to the bus 204 for communication with the other components of the experimentation server 101a. Processor 206 processes data signals and may comprise various computing architectures including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. Although only a single processor is shown in Figure 2A, multiple processors may be included. The experimentation server 101a also includes an operating system executable by the processor including but not limited to WINDOWS®, MacOS X, Linux or UNIX® based operating systems. It will be recognized that other processors, operating systems, sensors, displays and physical configurations are possible.
[0132] The memory 208 is a non-transitory storage medium. The memory 208 holds instructions and/or data that may be executed by the processor 206. In one embodiment, the instructions and/or data stored on the memory 208 comprise code for performing any and/or all of the techniques described herein. The memory 208 may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory or some other memory device. In one embodiment, the memory 208 also includes a nonvolatile memory or similar permanent storage device and media, for example, a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device known for storing information on a more permanent basis. The memory 208 is coupled by the bus 204 for communication with the other components of the experimentation server 101a. In one embodiment, an interactive experimentation module 220 is stored in memory 208 and executable by the processor 206 of the experimentation server 101a. [0133] The interactive experimentation module 220 includes code and routines executable by the processor 206 for providing online interactive experimentations to users 125. In one embodiment, the interactive experimentation module 220 is a set of instructions executable by the processor 206. In another embodiment, the interactive experimentation module 220 is stored in the memory 208 and is accessible and executable by the processor 206. Details describing the functionality and components of the interactive experimentation module 220 are explained in further detail below in reference to Figures 3.
[0134] The storage device 214 is any device capable of holding data, like a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The storage device 214 is a non-volatile memory device or similar permanent storage device and media. The storage device 214 stores data and instructions for processor 206 and comprises one or more devices including a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device. In one embodiment, the storage device 214 stores data and information of a user 125.
[0135] The input device 212 may include a mouse, track ball, or other type of pointing device to input data into the experimentation server 101a. The input device 212 may also include a keyboard, for example, a QWERTY keyboard or any other physical or soft keyboard in any language. The input device 212 may also include a microphone, a web camera or similar audio or video capture device. The graphics adapter 210 displays images and other information on the display 218. The display 218 is a conventional type, for example, a liquid crystal display ("LCD") or any other similarly equipped display device, screen, touchscreen or monitor. The display 218 represents any device equipped to display electronic images and data as described herein. The network adapter 202 couples the experimentation server 101a to a local or wide area network. [0136] As is known in the art, an experimentation server 101a can have different and/or other components than those shown in Figure 2A. For example, the experimentation server 101a can have speakers or another form of audio output. In addition, the
experimentation server 101a can lack certain illustrated components. For example, in one embodiment, the experimentation server 101a lacks an input device 212, graphics adapter 210 and/or display 218. Moreover, the storage device 214 can be local and/or remote from the experimentation server 101a (e.g., a storage area network (SAN)).
[0137] The experimentation server 101a is adapted to execute computer program modules for providing the functionality described herein. As used herein, the term "module" refers to computer program logic utilized to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are executed by the processor 206.
[0138] Embodiments of the entities described herein can include other and/or different modules than the ones described here. In addition, the functionality attributed to the modules can be performed by other or different modules in other embodiments. Moreover, this description occasionally omits the term "module" for purposes of clarity and
convenience.
[0139] Figure 2B is a block diagram of an experimentation server 101b for providing online interactive experimentations to users 125 according to one embodiment. As illustrated in Figure 2B, the experimentation server 101b includes a network adapter 202 coupled to a bus 204. According to one embodiment, also coupled to the bus 204 are at least one processor 206, memory 208, a graphics adapter 210, an input device 212 and a storage device 214. The memory 208 stores one or more modules, which are executed by the processor 206. In one embodiment, the functionality of the bus 204 is provided by an interconnecting chipset. In one embodiment, the experimentation server 101a also includes a display 218, which is coupled to the graphics adapter 210. In one embodiment, an interactive
experimentation module 220 is stored in memory 208 and executable by the processor 206 of the experimentation server 101b.
Example Interactive Experimentation Module 220
[0140] Referring now to Figure 3, the interactive experimentation module 220 is shown in more detail according to one embodiment. Figure 3 is a block diagram of the interactive experimentation module 220 included in an experimentation server 101a or 101b, a third party server 109, a client device or any other servers. [0141] In one embodiment, the interactive experimentation module 220 comprises a communications interface 302, an account module 304, a class management module 306, a playlist creation module 308, a game configuration module 310, a demo generation module 312, a result management module 314, a player control module 316, a robotic player module 318, an user interface module 320, an interactive game module 322, a game analytics module 324, a monetization module 326 and a socialization module 328.
[0142] It will be recognized that the modules 302, 304, 306, 308, 310, 312, 314, 316,
318, 320, 322, 324, 326, 328 comprised in the interactive experimentation module 220 are not necessarily all on the experimentation server 101a or 101b. In one embodiment, the modules 302, 304, 306, 308, 310, 312, 314, 316, 318, 320, 322, 324, 326, 328 are distributed across the experimentation server 101a or 101b, the client device 115 and the third-party server 109. For example, in one embodiment, the player control module 316 is included in the client device 1 15, while the other modules 302, 304, 306, 308, 310, 312, 314, 316, 318, 320, 322, 324, 326, 328 are included in the experimentation server 101a or 101b. In another example, in one embodiment, the modules 302, 304, 306, 308, 310, 312, 314, 316, 318, 320, 322, 324, 326, 328 are distributed across multiple experimentation servers 101a or 101b. It will be recognized that the preceding are merely examples of distributing modules across multiple computing devices and that other examples exist.
[0143] It will be also recognized that some of the modules 302, 304, 306, 308, 310, 312, 314, 316, 318, 320, 322, 324, 326, 328 can be, in some embodiments, combined to implement multiple functionalities. For example, the game configuration module 310, the result management module 314 and the interactive game module 322 can combined as a signal module (e.g., a game module) to implement the functionalities of the three modules 310, 314 and 322. For example, the game module can configure games, generate game results as well as handle user interactions during the games.
[0144] The communication interface 302 includes code and routines for handling communications between the account module 304, the class management module 306, the playlist creation module 308, the game configuration module 310, the demo generation module 312, the result management module 314, the player control module 316, the robotic player module 318, the user interface module 320, the interactive game module 322, the game analytics module 324, the monetization module 326, the socialization module 328, the sub-modules thereof and other components of the experimentation server 101a or 101b. In one embodiment, the communication interface 302 is a set of instructions executable by the processor 206. In another embodiment, the communication interface 302 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the communication interface 302 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0145] In one embodiment, the communication interface 302 receives data from one or more of the client device 1 15, the third-party server 109 and other servers not depicted and delivers the information to one or more other appropriate sub-modules of the interactive experimentation module 220. For example, the communication interface 302 receives, via the network 105, registration information from a client device 1 15 operated by a user 125 and delivers the registration information to the account module 304 for creating an account for the user 125. For example, the communication interface 302 receives a request for joining a playlist from a client device 115 operated by a user 125 and delivers the request to the player control module 316.
[0146] In one embodiment, the communication interface 302 receives data from the one or more sub-modules of the interactive experimentation module 220 and delivers the data to one or more of the client device 1 15, the third-party server 109 and other servers not depicted. For example, the communication interface 302 receives graphical data describing game results from the user interface module 320 and sends the graphical data to the client device 115 for presenting the game results to a user 125 operating on the client device 115. In one embodiment, the communication interface 302 also handles communications between the one or more sub-modules of the interactive experimentation module 220. For example, the communication interface 302 communicates with the game configuration module 310 and the demo generation module 312, to pass an output of the game configuration module 310 (e.g., a configured game based on parameters) to the demo generation module 312 for generating a demo for the configured game. For purpose of clarity and convenience, the above description may occasionally omit mention of the communication interface 302 and the above scenario may be described as the game configuration module 310 passing the configured game to the demo generation module 312 for generation a demo for the configured game.
[0147] The account management module 304 includes code and routines for creating and managing accounts for users 125. In one embodiment, the account management module 304 is a set of instructions executable by the processor 206. In another embodiment, the account management module 304 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the account management module 304 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0148] The account management module 304 receives registration information of a user 125 from a client device 115 via the network 105 and the communication interface 302 and creates an account for the user 125 based on the registration information. For example, the account management module 304 cooperates with the user interface module 320 to provide a user interface allowing a user 125 to input information (e.g., a user name and a password) for registration with an online lab website, and when the user 125 inputs the information and sends a registration request through the user interface the account management module 304 receives the information and the registration request. The account management module 304 can then create an account for the user 125 based upon the information and the registration request.
[0149] Examples for registration information can also include, but not limited to, an email address, affiliation information, an occupation, student identification (ID), age, gender, race, a school, a year of school, a major in school, an address, residence, etc. In one embodiment, the account management module 304 can generate a profile for a user 125 based on the registration information. The profile for users 125 can later be used by the game analytics module 324 to analyze the game results based on the profile. For example, the game analytics module 324 can use demographic data (e.g., age, gender, race residence, etc.) to analyze the game results. [0150] In one embodiment, the account management module 304 also cooperates with the user interface module 320 to require the user 125 to choose a type of account via a user interface. For example, the user interface can allow the user 125 to choose from a list of different types of account. For example, the types of account can include a student account, an instructor account, a teaching assistant account, etc. In another example, the types of account can include a basic account, a premium account, a VIP account, etc.
[0151] In one embodiment, the account management module 304 also verifies the information for registration provided by the user 125. For example, the account management module 304 communicates with another server (e.g., an authentication server, a notary server) for verifying the information provided by the user 125. Once the account management module 304 receives verification for the information, the account management module 304 creates an account for the user 125 using the information.
[0152] The class management module 306 includes code and routines for allowing users 125 to create and manage classes. In one embodiment, the class management module 306 is a set of instructions executable by the processor 206. In another embodiment, the class management module 306 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the class management module 306 is adapted for cooperation and communication with the processor 206, other components of the
experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0153] In one embodiment, the class management module 306 cooperates with the user interface module 320 to generate one or more user interfaces that allows a user 125 to create and manage a class. For example, the class management module 306 controls the user interface module 320 to generate a user interface allows the user 125 to indicate that the user 125 wants to create a class. When the user 125 expresses the desire of creating a class through the user interface (e.g., by clicking a button for creating a class, etc.), the class management module 306 receives a signal indicating that the user 125 is willing to create a class. The class management module 306 can then cooperate with the user interface module 320 to provide one or more other user interfaces for allowing the user 125 to input information for creating the class. For example, the one or more other user interfaces can require the users 125 to input a name for the class, an ID for the class, a brief description for the class, etc. After the user 125 inputs the information, the class management module 306 can receive the information and create the class based on the information. In one embodiment, the class management module 306 also cooperates with the user interface module 320 to provide a user interface for presenting class information to the user 125.
[0154] In one embodiment, the class management module 306 generates a class code for a class that allows other users 125 to join the class. For example, the class management module 306 creates an economics class for a user 125 who is an instructor of a school and generates a class code for the economics class. The class management module 306 can control the user interface module 320 to present the class code to the instructor 125 and the class code can allow the instructor 125 to invite one or more students 125 to join the economics class. For example, the instructor 125 can provide the class code to students 125 and the students 125 can join the class using the code. In one embodiment, the class management module 306 generates a class roster for a class to register users 125 (e.g., students 125) with the class. For example, when a student 125 enters a class code for a class through a user interface, the class management module 306 registers the student 125 with the class and adds the student 125 into the roster for the class once verifying that the class code is correct. In another example, the instructor 125 can upload information for a set of one or more students 125 through a user interface, the class management module 306 receives the information for the set of one or more students 125 and adds the set of one or more students 125 to the roster for the class.
[0155] In one embodiment, the class management module 306 also cooperates with the socialization module 328 to allow the user 125 to share the class with other users 125. For example, the class management module 306 receives a request from a first user 125 for sharing a class with one or more second users 125 when the first user 125 indicates so through a user interface. The class management module 306 cooperates with the
socialization module 328 to share the class to the one or more second users 125 indicated by the user 125. For example, the class management module 306 controls the socialization module 328 to share the class through email addresses. In one embodiment, the class management module 306 can cooperate with the socialization module 328 to allow the user 125 to permit other users 125 to modify parameters or configurations for games in the shared class.
[0156] The playlist creation module 308 includes code and routines for creating playlists for users 125. In one embodiment, the playlist creation module 308 is a set of instructions executable by the processor 206. In another embodiment, the playlist creation module 308 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the playlist creation module 308 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0157] It should be understood that the terms "playlist" and "game" are used throughout this specification, but are merely convenient labels used to describe the present invention. Other terms, such as but not limited to, activity list, game activity, activity agenda, game agenda, session list, session agenda, game list, game room, game collection, collection of activities, set of game or group of games could be used in place of the term "playlist." The play list may be a group, set or collection of games or activities to be played a group of people at certain time (in class or in a TA session). An analogy would be an activity list a party host has. You can change the activities depending on the situation. The assumption that a group of people all present and more or less stay is important, which enables replays and makes repeated plays easier. Just like when a party host is entertaining a party with some activities (decided prior to the party or on the spot), he needs the guests to be at the party. The playlist is more useful to the host than to the guests. The guests just need to come to the party (game room) on time; they do not need to know about the activity list. The games or activities can be of different types and can be executed in any order, including repeated or skipping. In the context of a class or course, it represents a flexible way of organizing games to play in and out of class and in online classes. More specifically, a play list may be a collection of games, quizzes, polls, or other interactive modules, to be engaged with students or participants in general, either synchronously or asynchronously. When the order of the games does matter, it often serves to create a unique path or experience or a specific pedagogical purpose for the users. Similarly, other terms, such as but not limited to, activities, quizzes, polls may be used in place of the term "game."
[0158] In one embodiment, the playlist creation module 308 cooperates with the user interface module 320 to provide a user interface that allows users 125 to indicate they want to create a playlist. When the users 125 indicate so, the playlist creation module 308 receives a request for creating a playlist and controls the user interface module 320 to provide another user interface for requesting the users 125 to input information about the playlist, for example, a name for the playlist, etc. The playlist creation module 308 can then create the playlist based on the information. At this point, the created playlist can be only a frame, which can be populated with games later. For example, the playlist creation module 308 can cooperates with the user interface module 320 to provide a user interface that allows the users 125 to select one or more games to be added into the playlist. For example, the user interface allows the users 125 to choose from a library of games. In one embodiment, a playlist can be a list of games that associated with a class. For example, a class can include one or more playlists and each playlist can include one or more games relevant to the class. For example, if the class is an economics class, the playlists in the class can include one or more games related to economics.
[0159] In one embodiment, the playlist creation module 308 can generate a syllabus based game catalog. For example, the playlist creation module 308 can package games based on syllabus of popular classes and textbooks for classes. [0160] In one embodiment, the playlist creation module 306 can cooperate with the user interface module 320 to generate multiple skins of user interface for presenting a game to users 125. For example, the playlist creation module 306 can allow the instructor 125 of a class to choose between an abstract user interface and a user interface having a specific storyline based on the level and subject of the class. [0161] In one embodiment, the playlist creation module 308 can send queries to the template server 107 and retrieve templates for games from the library 130. The playlist creation module 308 can generate games based on the templates and provide the games to users to choose.
[0162] The game configuration module 310 includes code and routines for configuring the games. In one embodiment, the game configuration module 310 is a set of instructions executable by the processor 206. In another embodiment, the game configuration module 310 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the game configuration module 310 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0163] In one embodiment, the game configuration module 310 cooperates with the user interface module 320 to provide a user interface that allows users 125 to input configuration settings for games. For example, the user interface allows the users 125 to enter parameter values for games and the game configuration module 310 can receive the parameter values entered by the users 125 and configure the games based on the parameter values. The parameters for the games can be any parameters necessary for setting up the games. For example, for a bargaining game, the parameters can include turn duration, a total pie, a discount factor, the number of rounds, etc. Parameters for games are described in more detail below in Graphical User Interfaces (GUIs) with references to Figures 10-90. In one embodiment, the game configuration module 310 sends the configured games to the demo generation module 312 or the interactive game module 322.
[0164] The demo generation module 312 includes code and routines for generating demos based on game configurations. In one embodiment, the demo generation module 312 is a set of instructions executable by the processor 206. In another embodiment, the demo generation module 312 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the demo generation module 312 is adapted for cooperation and communication with the processor 206, other components of the
experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0165] In one embodiment, the demo generation module 312 receives game configuration for a game from the game configuration module 310 and once users 125 requests a demo for the game through a user interface, the demo generation module 312 generates a demo of the game based on the game configuration. For example, a user 125 enters parameter values for configuring a game and clicks to preview the game through the user interface; the demo generation module 312 generates a demo for the game configured based on the parameter values. During the demo, the demo generation module 312 also controls the user interface module 320 to provide a user interface allowing users 125 to play with the demo. For example, the user interfaces allows the users 125 to make inputs or actions to the demo and upon receiving the inputs or actions the demo generation module 312 generates a next stage of the demo based on the inputs or actions.
[0166] In one embodiment, the demo generation module 312 cooperates with the robotic player module 318 to generate robotic players to join the demo and play with the users 125. In one embodiment, the functionality of the demo generation module 312 can be implemented by the interactive game module 322. For example, the interactive game module 322 can generate demos based on game configuration and incorporate robotic players into participants for the demos.
[0167] The result management module 314 includes code and routines for generating and managing game results. In one embodiment, the result management module 314 is a set of instructions executable by the processor 206. In another embodiment, the result management module 314 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the result management module 314 is adapted for cooperation and communication with the processor 206, other components of the
experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0168] In one embodiment, the result management module 314 generates result data based on how users 125 play the games. For example, the result data describes a result that a user 125 has obtained by playing the game. For example, the result indicates that the user 125 won or lost; how much payoff the user 125 obtained; how much payoff the competitor achieved; etc. In one embodiment, the result data also include descriptions based on nature of the games. For example, the result data include statistical analysis about the result of the game.
[0169] In one embodiment, the result management module 314 can generate instant game results during games. For example, instead of generating a result for a game at the end of the game play, the result management module 314 can generate an instant result when the game is ongoing, responsive upon receiving a demand from a user 125 who is playing the game. The result management module 314 can cooperate with the user interface module 320 to present the instant result to the user 125 during the game. [0170] In one embodiment, the result management module 314 sends the result data to the user interface module 320 for generating graphical data to present the results of the games to users 125. In one embodiment, the result management module 314 stores the result data to the storage 214 for being used by the game analytics module 324 to analyze user behaviors during the games. [0171] The player control module 316 includes code and routines for allowing users
125 to join playlists. In one embodiment, the player control module 316 is a set of instructions executable by the processor 206. In another embodiment, the player control module 316 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the player control module 316 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0172] In one embodiment, the player control module 316 cooperates with the user interface module 320 to provide a user interface that allows users 125 to join playlists. For example, the player control module 316 can monitor the system to check if the user 125 who created the playlist under a class (also referred to as the creator 125 or the instructor 125, hereinafter) allows other users 125 to join. For example, the player control module 316 controls the user interface module 320 to provide a user interface, through which the instructor 125 can allow the students in the class roster to join. In another example, the player control module 316 controls the user interface module 320 to provide a user interface allowing the creator 125 to permit any other users 125 to join the playlist. Once the player control module 316 determines that the instructor 125 or creator 125 allows other users 125 to join the playlist, the player control module 316 can cooperate with the user interface module 320 to provide a user interface indicating to the other users 125 that the playlist is ready to j oin and they can j oin now.
[0173] In one embodiment, if one of the other users 125 indicates through the user interface that the one of the other users 125 wants to join a playlist of a class, the player control module 316 receives a request of the user 125 willing to join the playlist. The one of the other users 125 who requests to join the playlist will be referred to as the requesting user 125 hereinafter. Upon receiving the request, the player control module 316 controls the user interface module 320 to provide a waiting image for the requesting user 125 so that the requesting user 125 can wait for an approval of starting to play. In one embodiment, the player control module 316 may also determine if the requesting user 125 is a member of the roster for the class. If the requesting user 125 is registered with the roster for the class, the player control module 316 controls to provide a waiting image for the requesting user 125. In one embodiment, while keeping the requesting user 125 waiting, the player control module 316 may monitor the system to check if the creator 125 or instructor 125 starts one or more games in the playlist. If the player control module 316 detects that the creator 125 or instructor 125 starts a game in the playlist, the player control module 316 cooperates with the interactive game module 322 to retrieve the game in the playlist from the storage 214 and determine an instance of the game. The player control module 316 can then allow the requesting user 125 to play the game. For example, the player control module 316 controls the interactive game module 322 and the user interface module 320 to provide a user interface based on the instance of the game and through the user interface the requesting user 125 can start playing the game.
[0174] In one embodiment, the player control module 316 allows requesting users
125 to join and play a game after the game has started. For example, the player control module 316 can monitor the system after the game has started and been ongoing to check if any other users 125 indicate that they want to join the playlist of the game. If the player control module 316 detects that any other users 125 want to join the playlist, the player control module 316 adds the other requesting users 125 to join and play the game as participants after the game has started and been ongoing. In this way, users 125 are conveniently allowed to play the games whenever they want and don't have to wait until all other participants 125 are ready. In one embodiment, the player control module 316 can also allow participants 125 to drop a game at any point of the game. For example, after the game has started, the player control module 316 can also allow a participant 125 to quit the game without affecting other participants' playing. For example, the player control module 316 can cooperate with the robotic player module 318 to generate robotic players to fill the spot of the quit participant. [0175] In one embodiment, the player control module 316 can select a set from the requesting users 125 as participants for a game based on certain criteria. For example, the player control module 316 may allow the first 10 requesting users 125 to play the game and keep the following requesting users 125 waiting until the first 10 have done the game. In another example, the player control module 316 can select a set of participants for a playlist based on rules specified by the instructor 125 or creator 125 of the playlist. One skilled in the relevant art will recognize other criteria can be used by the player control module 316 to determine the set of participants for a game.
[0176] In one embodiment, the player control module 316 assigns participants 125 into groups. For example, the player control module 316 divides the participants 125 into sets of optimized size. For example, if there are 20 participants 125, the player control module 316 can group the participants 125 into three sets having six, seven and seven members, respectively. In one embodiment, the player control module 316 can cooperate with the robotic player module 318 to add one or more robotic players or computerized players into the groups. For example, the player control module 316 can add a robotic player into the group of 20 participants 125 to make it 21 and divide the 21 players into three sets, each having seven members.
[0177] The robotic player module 318 includes code and routines for generating robotic or computerized players. In one embodiment, the robotic player module 318 is a set of instructions executable by the processor 206. In another embodiment, the robotic player module 318 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the robotic player module 318 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0178] In one embodiment, the robotic player module 318 can generate robotic or computerized players based on player behavior models. For example, the robotic player module 318 can analyze player behavior and determine a pattern or a model describing behavior of an average player. The robotic player module 318 can then generate a mimic robotic player based on the pattern or model. In another example, the robotic player module 318 cooperates with the game analytics module 324 to obtain the pattern or model describing behavior of an average player. In yet another example, the robotic player module 318 retrieves the pattern or model describing behavior of an average player from other servers, storage, or any other resources. In one embodiment, patterns or models can describe players with different attributes. For example, a variety of different patterns or models can describe a slow player, a reactive player, an aggressive play, a defensive player, an offensive player, etc. In one embodiment, the robotic player module 318 can generate different types of players based on the variety of different patterns or models.
[0179] The user interface module 320 includes code and routines for generating graphical data that can be used to provide user interfaces to client devices 115 of users 125. In one embodiment, the user interface module 320 is a set of instructions executable by the processor 206. In another embodiment, the user interface module 320 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the user interface module 320 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220. [0180] As described above, in one embodiment, the user interface module 320 cooperates with other sub-modules of the interactive experimentation module 220 to generate graphical data for providing user interfaces to client devices 115 of users 125. For example, the user interface module 320 cooperates with the account management module 304 to generate graphical data based on a request of creating an account for a user 125 and sends the graphical data to the client device 1 15, causing the client device 115 to present a user interface that allows the user 125 to input account information for creating the account. In another example, the user interface module 320 generates and sends graphical data to the client device 1 15, causing the client device 1 15 to present a user interface that allows the user 125 to input parameter values for configuration of a game. [0181] The interactive game module 322 includes code and routines for allowing users 125 to play game interactively. In one embodiment, the interactive game module 322 is a set of instructions executable by the processor 206. In another embodiment, the interactive game module 322 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the interactive game module 322 is adapted for cooperation and communication with the processor 206, other components of the
experimentation server 101a or 101b and other components of the interactive experimentation module 220.
[0182] In one embodiment, the interactive game module 322 determines an instance of a game in a playlist and cooperates with the user interface module 320 to provide the instance of the game for users 125 to play with. In one embodiment, the interactive game module 322 also receives inputs from the participants of the game and provides a next session of the game based on the inputs. In one embodiment, the interactive game module 322 generates feedback based on inputs of a first participant and sends the feedback to a second participant so that the first and second participants can play the game interactively. In one embodiment, the interactive game module 322 cooperates with the result management module 314 to generate instantaneous results based on the playing of the game.
[0183] The game analytics module 324 includes code and routines for analyzing games. In one embodiment, the game analytics module 324 is a set of instructions executable by the processor 206. In another embodiment, the game analytics module 324 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the game analytics module 324 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220. [0184] In one embodiment, the game analytics module 324 receives game data including configuration of the game, inputs of the participants to the game, outputs during middle stages of the game, result data describing results of the game, profiles for the participants of the game and any other data associated with the game and the participants for the game, and analyzes the game data to determine behavior data describing user behavior during the game. In one embodiment, the game analytics module 324 also identifies bias in the game based on the analysis of the game data so that the bias can be used later to adjust the model of the game. In one embodiment, the game analytics module 324 also uses the analysis of the game to determine if there are any technological issues associated with the game and obtain better understanding of the game, etc.
[0185] In one embodiment, the game analytics module 324 uses demographic data
(e.g., age, gender, race, residence, etc.) in the profile for participants to analyze user behavior in games. For example, the game analytics module 324 analyzes the user behavior by partitioning the game results based on the demographic data. For example, the game analytics module 324 can determine race as a factor or attribute and analyze user behavior of participants with different race. For example, the game analytics module 324 may determine that Asian do well at trust games but poor at bargaining games; etc. One skilled in the relevant art will recognize that any demographic characteristic can be used to partition, analyze and process the results of games. [0186] The monetization module 326 includes code and routines for monetizing the playlists of games. In one embodiment, the monetization module 326 is a set of instructions executable by the processor 206. In another embodiment, the monetization module 326 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the monetization module 326 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220. One embodiment of a payment process is described below in Appendix A and referenced in Figures 94A and 94B.
[0187] In one embodiment, the monetization module 326 generates a marketplace where users 125 can purchase products included in the market place. For example, the products include ebooks, software products, hardware products, videos, written publications, etc., associated with the playlists of games. The products can be free or paid-for resources. For example, the marketplace provides a software product of a game including an access to a link to purchase the software product. In another example, the marketplace includes software of a game that can be downloaded for free as long as an account is provided. In one embodiment, the monetization module 326 rewards users 125 who rank high in a game. For example, if a user 125 plays well with a game and ranks the top one among other users 125, the monetization module 326 determines a reward for the user 125.
[0188] The socialization module 328 includes code and routines for allowing users
125 to share classes and playlists. In one embodiment, the socialization module 328 is a set of instructions executable by the processor 206. In another embodiment, the socialization module 328 is stored in the memory 208 and is accessible and executable by the processor 206. In either embodiment, the socialization module 328 is adapted for cooperation and communication with the processor 206, other components of the experimentation server 101a or 101b and other components of the interactive experimentation module 220. [0189] In one embodiment, the socialization module 328 generates a social community where users 125 can share with other users 125 classes and playlists of games that they created. For example, the socialization module 328 cooperates with the user interface module 320 to provide user interfaces that allows users 125 to share classes and playlists with other users 125 through email, messaging, blog, microblog, social network, etc. In one embodiment, the socialization module 328 also allows users 125 to connect to other users 125 and construct a social graph for users 125 that describes how the users are connected to each other. In this way, the socialization module 328 can provides a list of connections for a user 125 when the user 125 wants to share a class or playlist of games to others 125. [0190] Figure 92 is a block diagram illustrating an architecture for another embodiment of the system 100 that provides interactive experimentations to users 125. Figure 93 is a block diagram illustrating an architecture for a data service included in the system 100 that provides interactive experimentations to users 125. Additional embodiments of the system 100 of the present disclosure and further features and functions are disclosed below in Appendices B and C.
Example Processes
[0191] Figures 4, 5, 6, 7A-7C, 8 and 9A-B depict various methods 400, 500, 600,
700, 800, 900, 950 performed by the system described above in reference to Figures 1A, IB, 2A, 2B and 3.
[0192] Figure 4 is a flow chart illustrating a method 400 for creating a playlist of games according to one embodiment. In the illustrated embodiment, the method 400 can include receiving 402 signal of creating a playlist of games from a user 125. For example, when a user 125 indicates through a user interface that the user 125 wants to create a playlist of games, the playlist creation module 308 receives a signal of creating a playlist of games via the network 105 and the communication interface 302. The method 400 can include creating 402 an empty playlist as a placeholder. For example, the playlist creation module 308 creates an empty playlist based up the request. The method 400 can also include receiving 406 one or more templates for games. For example, the playlist creation module 308 receives one or more templates for games from the template server 107 for creating games. The method 400 can include populating 408 the playlist based on the one or more templates for games. For example, the playlist creation module 308 populates the empty playlist based on the one or more templates for games. [0193] Figure 5 is a flow chart illustrating a method 500 for creating a playlist of games according to another embodiment. In the illustrated embodiment, the method 500 can include receiving 502 signal of creating a playlist of games from a user 125. For example, as described with reference to Figure 4, when a user 125 indicates through a user interface that the user 125 wants to create a playlist of games, the playlist creation module 308 receives a signal of creating a playlist of games via the network 105 and the communication interface 302. The method 500 can also include providing 504 a first user interface for the user 125 to enter a name for the playlist. The method 500 can include receiving 506 a name for the playlist from the user 125. For example, the playlist creation module 308 cooperates with the user interface module 320 to provide a dialog box that allows the user 125 to input a name for the playlist, as depicted in Figure 10. Once the user 125 inputs a name and submits it, the playlist creation module 308 receives the name for the playlist.
[0194] The method 500 can include providing 508 a second user interface for the user
125 to select one or more templates of games for the playlist. For example, the playlist creation module 308 cooperates with the user interface module 320 to provide a list from which the user 125 can select one or more templates of games. The method 500 can also include retrieving 510 template data describing the one or more templates of games. For example, the playlist creation module 308 retrieves template data from the template server 107 describing one or more templates of games. The method 500 can include generating 512 the playlist based on the name and the retrieved templates of games. For example, based on the retrieved template data, the playlist creation module 308 generates a playlist of games. [0195] Figure 6 is a flow chart illustrating a method 600 for setting up an account for a user 125 according to one embodiment. In the illustrated embodiment, the method 600 can include receiving 602 a request for an account from a user 125. For example, when a user 125 indicates through a user interface that the user 125 wants to register an account with the online interactive lab system 101a or 101b, the account management module 304 receives a request indicating that the user 125 is willing to have an account with the system 101a or 101b. The method 600 can also include providing 604 a first user interface for the user 125 to enter account information. For example, upon receiving the request for registration of an account, the account management module 304 cooperates with the user interface module 320 to provide a user interface that requires the user 125 to input account information. For example, the account information can include a name, a password, an age, a gender, a school, a year of school, a race, a maj or in school, an address, etc. So the account management module 304 can register the user 125 with the system 101a or 101b using an account and creates a profile for the user 125 based on the account information. [0196] The method 600 can also include providing 608 a second user interface for the user 125 to choose a type of account. Though the step 608 can be an optional step for the method 600, this step provides the user 125 an opportunity to choose a type for the account. For example, the user interface may allow the user 125 to choose from a student account, an instructor account, a basic account, a premium account, an advanced account, etc. The account management module 304 can assign the user 125 different privileges based on the different types of account once the account management module 304 determines that the user 125 is qualified for the type of account the user 125 chooses. The method 600 can also include verifying 610 account information input by the user 125 and creating 612 an account for the user 125 based on the verification of the account information. For example, the account management module 304 verifies the account information through another server or system and if the account information is verified, the account management module 304 creates an account and generates a profile for the user 125 based on the account information and the type of the account. The profile can later be used as data for analyzing user behaviors and generating demographic data. [0197] Figure 7A is a flow chart illustrating a method 700 for allowing users 125 to play games in a playlist according to one embodiment. In the illustrated embodiment, the method 700 can include providing 702 one or more user interfaces for allowing a set of users 125 to join a playlist as participants. The step 702 will be described in further detail below with reference to Figure 7B. The method 700 can also include providing 704 one or more user interfaces for allowing the participants to play one or more games included in the playlist. The step 704 will be described in further detail below with reference to Figure 7C.
[0198] Figure 7B is a flow chart illustrating a method 702 for allowing users 125 to join a playlist as participants according to one embodiment. In the illustrated embodiment, the method 702 can include providing 722 a code for allowing a set of first users 125 to join a roster. For example, the class management module 306 can provide a class code and by using this code users 125 can join a class and register with the roster of the class. The method 702 can also include adding one or more first users 125 into the roster based on the code. For example, when one or more first users 125 input the code, the class management module 306 can add the one or more first users 125 into the roster. In another embodiment, the class management module 306 can allow an instructor (or creator) 125 of the class to add one or more first user 125 to the roster of the class. For example, the class management module 306 allows the instructor of the class to upload information of one or more first users 125 (e.g., students of the class) to the system 101a or 101b and the class management module 306 adds the one or more first users 125 into the roster. [0199] The method 702 can also include providing 726 a user interface for a second user 125 to allow the one or more first users 125 in the roster to join a playlist. For example, the player control module 316 cooperates with the user interface module 320 to provide a button clickable for the instructor 125 of the class to allow students to join the playlist. The method 702 can also include determining 728 if the second user 125 has allowed the one or more first users 125 to join the playlist. For example, the player control module 316 can keep tracking if the instructor 125 has clicked the button to allow students 125 to join the playlist. If the second user 125 has allowed the one or more first users 125 to join the playlist, the method 702 can include adding 730 the one or more first users 125 in the roster as participants for the playlist. For example, when the instructor 125 clicks the button to allow the one or more first users 125 to join the playlist, the one or more first users 125 can be notified through a user interface that the playlist is ready to join. If any of the one or more first users 125 indicates to join through the user interface, the player control module 316 adds the user 125 to the playlist as participant. [0200] If the second user 125 has not allowed the one or more first users 125 to join the playlist, the method 702 proceeds back to the last step of keeping providing 706 the user interface for the second user 125 to allow the one or more first users 125 in the roster to join the playlist. The method 702 can also include providing 732 a user interface for allowing users 125 to join the playlist after the playlist starts. For example, after the player control module 316 adds one or more of the first users 125 as participants to the playlist, the player control module 316 can control the interactive game module 322 to let the one or more of the first users 125 to play games in the playlist. For example, the player control module 316 can allow the second user 125 (e.g., the instructor of the class) to start a game in the playlist. When the second user 125 starts the game through a user interface, the player control module 316 can control the interactive game module 322 to allow the one or more of the first users 125 to start playing the games in the playlist. After the one or more of the first users 125 start to play the games in the playlist, the player control module 316 can still allow more first users 125 to join the playlist and play the games.
[0201] Figure 7C is a flow chart illustrating a method 704 for allowing users 125 to play games in the playlist according to one embodiment. In the illustrated embodiment, the method 704 can include determining 752 an instance of a game included in the playlist. For example, the interactive game module 322 determines an instance of a game in the playlist for participants to play. The method 704 can also include selecting 754 a set of participants for the game. For example, the player control module 316 can select a set of participants based upon if the one or more first users 125 have joined the playlist. The method 704 can include assigning 756 participants into groups. For example, the player control module 316 can divide the participants into groups and cooperates with the interactive game module 322 to let the groups compete in the games.
[0202] The method 704 can include either providing 758 a user interface allowing the participants to play the game synchronously or providing 760 a user interface allowing the participants to play the game asynchronously. For example, the player control module 316 can allow users 125 to join and play the game any time before or after the game starts playing. The method 704 can also optionally include adding 762 robotic/computerized players into the groups. For example, the player control module 316 can control the robotic player module 318 to generate the one or more robotic/computerized players and add the robotic/computerized players into the groups of participants.
[0203] Figure 8 is a flow chart illustrating a method 800 for running a demo of a game according to one embodiment. In the illustrated embodiment, the method 800 can include providing 802 a user interface for a user 125 to input configuration information for a game. For example, the game configuration module 310 cooperates with the user interface module 320 to provide one or more input boxes for the user 125 to input parameter values for configuring the game. The method 800 can also include receiving 804 configuration information entered by the user 125. For example, the game configuration module 310 receives the parameter values set by the user 125 through the input boxes. The method 800 can include receiving 806 a request for a preview of the game from the user 125 and generating and presenting 808 a demo of the game based on the configuration information. For example, when the user 125 indicates through the user interface that the user 125 wants to preview the game, the demo generation module 312 receives a request indicating that the user 125 is willing to preview the game and then generates a demo of the game based on the configuration. The demo generation module 312 can also present the demo of the game to the user 125.
[0204] Figure 9A is a flow chart illustrating a method 900 for generating a result of a game according to one embodiment. In the illustrated embodiment, the method 900 can include receiving 902 a request for a result of a game played by a user 125. For example, when a user 125 finish playing a game, the user 125 may want to see a result. The result management module 314 can cooperate with the user interface module 320 to provide a user interface through which the user 125 can order a result of the game. The result management module 314 can receive a request if the user 125 orders the result of the game through the user interface. The method 900 can also include generating 904 result data based on playing of the user 125 and presenting 906 the result data to the user 125. For example, the result data can be used to show a result graph or description to the user 125. The method 900 can also optionally include storing 908 the result data.
[0205] Figure 9B is a flow chart illustrating a method 950 for analyzing user behavior in games according to one embodiment. In the illustrated embodiment, the method 950 can include capturing 952 user behaviors in a game. For example, the game analytics module 324 captures user behavior when users 125 play a game. The method 950 can also include analyzing 954 the user behavior and storing 956 the user behavior. For example, the game analytics module 324 can analyze captured user behavior, generate statistical analysis data describing the user behavior and store the analysis data. The method 950 can include providing 958 a user interface for playing back the user behavior in the game at different speeds. For example, the game analytics module 324 can cooperate with the user interface module 320 to provide a user interface through which the user 125 can play back the played game at the original speed or a higher speed, e.g., two times speed, three times speed, etc.
Example Graphical Representations
[0206] Figure 10 is a graphical representation illustrating a user interface 1000 allowing users 125 to create a class according to one embodiment. In the illustrated embodiment, the user interface 1000 requests users 125 to input a class name.
[0207] Figure 11 is a graphical representation illustrating a user interface 1 100 for displaying class information to users 125 according to one embodiment. In the illustrated embodiment, the user interface 1100 allows users 125 to review and modify class information (e.g., a class name, the number of playlists in the class, etc.) for a class.
[0208] Figure 12 is a graphical representation illustrating a user interface 1200 for displaying a class code to a user 125 according to one embodiment. [0209] Figure 13 is a graphical representation illustrating a user interface 1300 allowing users 125 to share a class with other users 125 according to one embodiment. In the illustrated embodiment, the user interface 1300 allows a user 125 to input the email or username of another user 125 to be shared with. [0210] Figure 14 is a graphical representation illustrating a user interface 1400 for creating a playlist for users 125 according to one embodiment. In the illustrated embodiment, the user interface 1400 allows the users 125 to input a name for the playlist to be created.
[0211] Figure 15 is a graphical representation illustrating a user interface 1500 for copying a playlist to a class according to one embodiment. In the illustrated embodiment, the user interface 1500 allows users 125 to input a class to copy a playlist to.
[0212] Figure 16 is a graphical representation illustrating a user interface 1600 for displaying instructions about how to populate a playlist according to one embodiment.
[0213] Figure 17 is a graphical representation illustrating a user interface 1700 for displaying a created playlist according to one embodiment. In the illustrated embodiment, the user interface 1700 displays the playlist that includes one or more games (e.g., a
Bargaining game, a Trust game and a Herding game).
[0214] Figure 18 is a graphical representation illustrating a user interface 1800 for displaying a configuration setting for a Bargaining game according to one embodiment. In the illustrated embodiment, the user interface 1800 allows users 125 to enter parameter values for configuring the Bargaining game.
[0215] Figure 19 is a graphical representation illustrating a user interface 1900 for requesting a user 125 to input the number of players that the user 125 wants to play with in a demo of a game according to one embodiment. [0216] Figure 20 is a graphical representation illustrating a user interface 2000 for displaying a demo of the Bargaining game according to one embodiment.
[0217] Figure 21 is a graphical representation illustrating a user interface 2100 for displaying a result of the demo of the Bargaining game according to one embodiment. [0218] Figure 22 is a graphical representation illustrating a user interface 2200 for displaying a summary of the demo for the Bargaining game according to one embodiment. In the illustrated embodiment, the user interface 2200 includes a history table.
[0219] Figure 23 is a graphical representation illustrating a user interface 2300 for displaying an analysis result of the demo for the Bargaining game according to one embodiment. In the illustrated embodiment, the user interface 2300 includes a bar graph illustrating a result for the first round of the game.
[0220] Figure 24 is a graphical representation illustrating a user interface 2400 for displaying an analysis result of the demo for the Bargaining game according to another embodiment. In the illustrated embodiment, the user interface 2300 includes a bar graph illustrating results for two rounds of the game.
[0221] Figure 25 is a graphical representation illustrating a user interface 2500 for displaying a class roster according to one embodiment. In the illustrated embodiment, the user interface 2500 includes the class roster containing a list of student users 125. [0222] Figure 26 is a graphical representation illustrating a user interface 2600 for displaying a list of available playlists for a user 125 who registers with a class according to one embodiment. In the illustrated embodiment, the user interface 2600 display the status of two playlists as stopped, which indicates that the instructor 125 of the class has not yet allowed students to join the playlists. [0223] Figure 27 is a graphical representation illustrating a user interface 2700 for displaying an indication that the instructor 125 of the class has allowed students 125 to join a playlist according to one embodiment.
[0224] Figure 28 is a graphical representation illustrating a user interface 2800 for displaying the available playlists for a user 125 according to another embodiment. In the illustrated embodiment, the user interface 2800 displays the status of one playlist as ready, which indicates that the instructor 125 of the class has allowed students to join the playlists and the user 125 can join the playlist.
[0225] Figure 29 is a graphical representation illustrating a user interface 2900 for displaying an indication that one participant is playing games in a playlist according to one embodiment.
[0226] Figure 30 is a graphical representation illustrating a user interface 3000 for displaying information of the participant who is playing games in a playlist according to one embodiment. [0227] Figure 31 is a graphical representation illustrating a user interface 3100 that allows users 125 to choose different patterns to replay a game according to one embodiment.
[0228] Figure 32 is a graphical representation illustrating a user interface 3200 that allows users 125 to input notes according to one embodiment. In the illustrated embodiment, the user interface 3200 allows users 125 to input class notes and playlist notes. [0229] Figure 33 is a graphical representation illustrating a user interface 3300 that displays tools for users 125 to learn about a game in the library according to one
embodiment. For example, the tools can include description about how to play the game, a demo of the game and class instructions for the game.
[0230] Figure 34 is a graphical representation illustrating a user interface 3400 for displaying a manual of how to play a game according to one embodiment.
[0231] Figure 35 is a graphical representation illustrating a user interface 3500 for displaying a demo of a game according to one embodiment. In the illustrated embodiment, the user interface 3500 showing the demo of the game can pop up when the user 125 clicks the tool of demo. [0232] Figure 36 is a graphical representation illustrating a user interface 3600 for displaying class instructions for a game according to one embodiment.
[0233] Figure 37 is a graphical representation illustrating a user interface 3700 that allows users 125 to view different categories of games from the library according to one embodiment.
[0234] Figure 38 is a graphical representation illustrating a user interface 3800 that displays a guide of the online interactive lab system according to one embodiment.
[0235] Figure 39 is a graphical representation illustrating a user interface 3900 that displays parameters for configuring an Ultimatum game and a Dictator game according to one embodiment. For example, the parameters for configuring the Ultimatum game can include turn duration and a total pie. The parameters for configuring the Dictator game can include a game duration and total pie.
[0236] Figure 40 is a graphical representation illustrating a user interface 4000 that displays parameters for configuring a Trust game and a Herding game according to one embodiment. For example, the parameters for configuring the Trust game can include turn duration, a multiplier, player endowment, etc. The parameters for configuring the Herding game can include the minimum player number, the maximum player number, turn duration, a percentage of majority, payoff, etc.
[0237] Figure 41 is a graphical representation illustrating a user interface 4100 that displays parameters for configuring a game of Market for Lemons and a Continuous Market game according to one embodiment. For example, the parameters for configuring the game of Market for Lemons can include turn duration, buyer configuration including beta and initial cash, seller configuration including a low value and a high value, etc. The parameters for configuring the Continuous Market game can include the minimum player number, the maximum player number, game duration, demand (pennies) including the minimum value and the maximum value, supply (pennies) including the minimum cost and the maximum cost, initial cash, value/cost increment, etc.
[0238] Figure 42 is a graphical representation illustrating a user interface 4200 that displays parameters for configuring a game of Matching Pennies according to one embodiment. For example, the parameters for configuring the game of Matching Pennies can include a game duration and a payoff matrix including rows and columns.
[0239] Figure 43 is a graphical representation illustrating a user interface 4300 that displays parameters for configuring a Matrix game according to one embodiment. For example, the parameters for configuring the Matrix game can include a game duration and a payoff matrix including rows and columns.
[0240] Figure 44 is a graphical representation illustrating a user interface 4400 that displays parameters for configuring a game of Prisoner Dilemma and an Election game according to one embodiment. For example, the parameters for configuring the game of Prisoner Dilemma can include a game duration and a payoff matrix including rows and columns. The parameters for configuring the Election game can include the number of voters, the number of polls, the voter distance minimum, the voter distance maximum, a voting duration and payoff.
[0241] Figure 45 is a graphical representation illustrating a user interface 4500 that displays parameters for configuring a game of Ascending Clock Auction and a game of Descending Clock auction according to one embodiment. For example, the parameters for configuring the game of Ascending Clock Auction can include the maximum number of players, the minimum number of players, bidder cash, start price, price increment, increment duration, the lowest bidder value, the highest bidder value, etc. The parameters for configuring the game of Descending Clock Auction can include the maximum number of players, the minimum number of players, bidder cash, start price, price increment, increment duration, the lowest bidder value, the highest bidder value, etc.
[0242] Figure 46 is a graphical representation illustrating a user interface 4600 that displays parameters for configuring a game of Private Value Auctions and a game of
Common Value Auctions according to one embodiment. For example, the parameters for configuring the game of Private Value Auctions can include the maximum number of players, the minimum number of players, a game duration, bidder cash, price increment, the lowest bidder value, the highest bidder value, price rule, with sealed bid or not, etc. The parameters for configuring the game of Common Value Auctions can include the maximum number of players, the minimum number of players, game duration, bidder cash, price rule, price increment, the lowest common value, the highest common value, common value (CV) signal low, CV signal high, with sealed bid or not, etc.
[0243] Figure 47 is a graphical representation illustrating a user interface 4700 that displays parameters for configuring a Guessing game and a game of Tragedy of the
Commons according to one embodiment. For example, the parameters for configuring the Guessing game can include the maximum number of players, the minimum number of players, game duration, payoff, fraction of average, etc. The parameters for configuring the game of Tragedy of the Commons can include the maximum number of players, the minimum number of players, game duration, total fishing hours, etc.
[0244] Figure 48 is a graphical representation illustrating a user interface 4800 that displays parameters for configuring a Oligopoly game and a Minimum Effort game according to one embodiment. For example, the parameters for configuring the Oligopoly game can include the maximum number of players, the minimum number of players, game duration, market capacity, maximum production, marginal cost, etc. The parameters for configuring the Minimum Effort Game can include the maximum number of players, the minimum number of players, game duration, minimum effort level, maximum effort level, cost of effort, payoff of effort, etc.
[0245] Figure 49 is a graphical representation illustrating a user interface 4900 that displays parameters for configuring a game of Linear Public Goods and a game of Threshold Public Goods according to one embodiment. For example, the parameters for configuring the game of Linear Public Goods can include the maximum number of players, the minimum number of players, game duration, endowment, rate of return, etc. The parameters for configuring the game of Threshold Public Goods can include the maximum number of players, the minimum number of players, game duration, endowment, return on threshold, threshold, rebate, refund, etc.
[0246] Figure 50 is a graphical representation illustrating a user interface 5000 that allows users 125 to input questions according to one embodiment.
[0247] Figure 51 is a graphical representation illustrating a user interface 5100 that allows users 125 to play the Ultimatum game according to one embodiment.
[0248] Figure 52 is a graphical representation illustrating a user interface 5200 that displays how users 125 play the Dictator game according to one embodiment.
[0249] Figure 53 is a graphical representation illustrating a user interface 5300 that allows users 125 to play the Trust game according to one embodiment. [0250] Figure 54 is a graphical representation illustrating a user interface 5400 that allows users 125 to play the Herding game according to one embodiment.
[0251] Figure 55 is a graphical representation illustrating a user interface 5500 that allows users 125 to play the game of Market for Lemons according to one embodiment. [0252] Figure 56 is a graphical representation illustrating a user interface 5600 that allows users 125 to play the Continuous Market game according to one embodiment.
[0253] Figure 57 is a graphical representation illustrating a user interface 5700 that allows users 125 to play the game of Matching Pennies according to one embodiment.
[0254] Figure 58 is a graphical representation illustrating a user interface 5800 that allows users 125 to play the Matrix game according to one embodiment.
[0255] Figure 59 is a graphical representation illustrating a user interface 5900 that allows users 125 to play the Prisoner Dilemma game according to one embodiment.
[0256] Figure 60 is a graphical representation illustrating a user interface 6000 that allows users 125 to play the Election game according to one embodiment.
[0257] Figure 61 is a graphical representation illustrating a user interface 6100 that allows users 125 to play the Election game according to another embodiment.
[0258] Figure 62 is a graphical representation illustrating a user interface 6200 that allows users 125 to play the game of Ascending Clock Auction according to one
embodiment.
[0259] Figure 63 is a graphical representation illustrating a user interface 6300 that allows users 125 to play the game of Descending Clock auction according to one
embodiment.
[0260] Figure 64 is a graphical representation illustrating a user interface 6400 that allows users 125 to play the game of Private Value Auction according to one embodiment.
[0261] Figure 65 is a graphical representation illustrating a user interface 6500 that allows users 125 to play the game of Common Value Auctions according to one embodiment. [0262] Figure 66 is a graphical representation illustrating a user interface 6600 that allows users 125 to play the Guessing game according to one embodiment.
[0263] Figure 67 is a graphical representation illustrating a user interface 6700 that displays how users 125 play the Guessing game according to one embodiment. [0264] Figure 68 is a graphical representation illustrating a user interface 6800 that allows users 125 to play the game of Tragedy of the Commons according to one embodiment.
[0265] Figure 69 is a graphical representation illustrating a user interface 6900 that displays how users 125 play the game of Tragedy of the commons according to one embodiment. [0266] Figure 70 is a graphical representation illustrating a user interface 7000 that allows users 125 to play the Oligopoly game according to one embodiment.
[0267] Figure 71 is a graphical representation illustrating a user interface 7100 that displays how users 125 play the Oligopoly game according to one embodiment.
[0268] Figure 72 is a graphical representation illustrating a user interface 7200 that allows users 125 to play the Minimum Effort game according to one embodiment.
[0269] Figure 73 is a graphical representation illustrating a user interface 7300 that displays how users 125 play the Minimum Effort game according to one embodiment.
[0270] Figure 74 is a graphical representation illustrating a user interface 7400 that allows users 125 to play the Linear Public Goods game according to one embodiment. [0271] Figure 75 is a graphical representation illustrating a user interface 7500 that allows users 125 to play the Threshold Public Goods game according to one embodiment.
[0272] Figure 76 is a graphical representation illustrating a user interface 7600 that displays an analysis result for the Election game according to one embodiment. [0273] Figure 77 is a graphical representation illustrating a user interface 7700 that displays an analysis result for the game of Ascending Clock Auction according to one embodiment.
[0274] Figure 78 is a graphical representation illustrating a user interface 7800 that displays an analysis result for the game of Private Value Auctions according to one embodiment.
[0275] Figure 79 is a graphical representation illustrating a user interface 7900 that displays an analysis result for the game of Common Value Auctions according to one embodiment. [0276] Figure 80 is a graphical representation illustrating a user interface 7800 that displays an analysis result for the Guessing game according to one embodiment.
[0277] Figure 81 is a graphical representation illustrating a user interface 8100 that displays an analysis result for the Oligopoly game according to one embodiment.
[0278] Figure 82 is a graphical representation illustrating a user interface 8200 that displays an analysis result for the game of Linear Public Goods according to one embodiment.
[0279] Figure 83 is a graphical representation illustrating a user interface 8300 that displays an analysis result for the Ultimatum game according to one embodiment.
[0280] Figure 84 is a graphical representation illustrating a user interface 8400 that displays an analysis result for the Dictator game according to one embodiment.
[0281] Figure 85 is a graphical representation illustrating a user interface 8500 that displays an analysis result for the Prisoner Dilemma game according to one embodiment. [0282] Figure 86 is a graphical representation illustrating a user interface 8600 that displays an analysis result for the Herding game according to one embodiment.
[0283] Figure 87 is a graphical representation illustrating a user interface 8700 that displays an analysis result for the game of Market for Lemons according to one embodiment. [0284] Figure 88 is a graphical representation illustrating a user interface 8800 that displays an analysis result for the Continuous Market game according to one embodiment.
[0285] Figure 89 is a graphical representation illustrating a user interface 8900 that displays an analysis result for the game of Matching Pennies according to one embodiment.
[0286] Figure 90 is a graphical representation illustrating a user interface 9000 that displays an analysis result for the Matrix game according to one embodiment.
[0287] Figure 91 is a block diagram illustrating a system for providing interactive experimentations to users 125 according to yet another embodiment.
[0288] The foregoing description of the embodiments has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the present embodiments to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the present embodiments be limited not by this detailed description, but rather by the claims of this application. As will be understood by those familiar with the art, the present embodiments may take other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, routines, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement one embodiment or its features may have different names, divisions and/or formats. Furthermore, as will be apparent, the modules, routines, features, attributes, methodologies and other aspects of the embodiments can be implemented as software, hardware, firmware or any combination of the three. Also, wherever a component, an example of which is a module, is implemented as software, the component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future. Additionally, the embodiments are in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure is intended to be illustrative, but not limiting, of the scope, which is set forth in the following claims.
Appendix A
Monetization Module 326 Payments
Business Objectives:
1. To introduce a payment process to the MobLab system that allows for student payments and institutional license codes.
Table of Contents
Payments
Table of Contents
School Calendar Database
Database Contents
New School Entry
Updating Faculty with new database entry
Default Course Length
Instructor Free
Trial
Free Trial Quota
Free Trial Start Date
Free Trial End Date
Free Trial Class Deletion by Instructor
Instructor Institutional
License
Purchasing an Institutional License
Using an Institutional License
Instructor Class
Creation and Completion
Prompt to add a class
Free Trial Available
Free Trial Used
Class Start Date/Term
Class End Date
Data Available Post End Date
Student Course Registration
Email Invitation
User without MobLab Account
User with MobLab Account
Add class using Key from instructor
Determine Class Payment
No Payment
Full Payment
Discounted Payment
Payment not processed
Join Class
Outstanding Questions
1. School Calendar Database
A Database of the school's calendar will assist MobLab in determining the current term and term end dates for courses 1.1 Database Contents
MobLab will compile a database of Schools and their term start and end dates.
Engineering will determine the best way to map new instructor accounts to an existing school. This may be through an Institution field (autofill/dropdown), institutional email account, etc.
1.2 New School Entry
When a new Instructor signs up for MobLab with an institution that is not part of the MobLab Database (1.1 ), MobLab will attempt to find that school's calendar and add it to the database.
1.2.1 Updating Faculty with new database entry
When a school associated with a new instructor has been added to the database, the instructor account should be updated to reference the new database entry.
1.3 Default Course Length
The default course length will 12 weeks from the course start date (3.2) if a course is created by an instructor without an institution in the School Calendar Database.
2. Instructor Free Trial
2.1 Free Trial Quota
When an instructor account is created, they will be given a free trial quota of one class. If an instructor wishes to try multiple classes, they must contact MobLab sales/support directly.
2.2 Free Trial Start Date
The duration of the free trial class is determined by the term in which the free trial class plays its first game at or above the threshold number of students (10). If a game is run with 10 or more students on the roster, the free trial period has officially begun.
2.3 Free Trial End Date
The end date of the free trial is determined by the end of the quarter or semester for the institution that the instructor registered for their account with. If the school or institution is unknown, the free trial class will end 12 weeks after the free trial start date.
2.4 Free Trial Class Deletion by Instructor
If an instructor deletes their free trial class, they will not be able to recreate a free trial class. They can contact MobLab support if they have issues.
3. Instructor Institutional License
3.1 Purchasing an Institutional License
Institutional licenses will not be available for purchase on the MobLab website. They will require an individualized contract for each institution.
3.2 Using an Institutional License Institutional license holders will be provided key codes to be used when instructors create a class. Instructors will choose an institutional license option when adding new classes that will not prompt students for payment. 4. Instructor Class Creation and Completion
4.1 Prompt to add a class
When an instructor adds a new class, the system will first check if they have already created a free trial class.
4.1.1 Free Trial Available
If the Free trial is available, instructors will see a prompt with three options to create 1 ) A free trial class, 2) A paid class, or 3) use an institutional license to create a class.
4.1.2 Free Trial Used
If the Free trial has been used, instructors will see a prompt two options to create 1 ) A paid class, or 2) use an institutional license to create a class.
4.2 Class Start Date/Term
The class start date is determined by the day in which the first game is played with a playlist of 10 or more players (the player threshold). If the course is at an institution in the database, we are only concerned with the term that the start date began. If they are not, the default course length is applied from the start date. 4.3 Class End Date
If an instructor's school is in the School Calendar Database (1 ), the class end date will be the end of the term in which the start date was present.
4.4 Data Available Post End Date
A class ending means that no more playlists can be added and no more games can be played. All data for the class will remain in the instructor's account indefinitely.
5. Student Course Registration
Students can register for courses two ways: Through an email link or via the key provided by an instructor
5.1 Email Invitation
Instructors can invite a list of Students to a class based on a list of email addresses. Students will receive an email with a two URLs containing the class code as a parameter appended on the URL. Clicking the email link is the equivalent of typing in the key code manually and is merely a convenience. There is no class associated with a student account in the database.
5.1.1 User without MobLab Account
One link take users to the registration page (if they don't already have an account)
5.1.2 User with MobLab Account
The other will take users to a login page (if they already have an account). If a user with an account accidentally navigates to the register page, they can click navigate to the login screen. 5.2 Add class using Key from instructor
Students can also add a class by creating their own MobLab account first and adding a class via the key provided by an instructor. This is the same process that the email invitation simulates.
5.3 Determine Class Payment
Classes will first be determined as requiring payment or not. If they require payment, then the system will have to determine whether or not it's the student's first class in the term or not.
5.3.1 No Payment
If a class is determined to not require payment from students (either free trial or institutional license), no payment information is needed or presented and the student will be enrolled in the class.
5.3.2 Full Payment
If the class a student is enrolling in requires payment, then the system will check to see if the student is currently enrolled in any other paid classes (because of the school-based system, this means it should be in the same term). If they have not yet paid for a class, they will get charged full price.
5.3.3 Discounted Payment
If the student has already paid for a class in the current term, they will be prompted to pay a discounted rate for the class.
5.4 Payment not processed
If a user does not pay for the class that requires payment, they will not join. The class will not show up as requiring payment the next time they log into MobLab. They will be able to add the class using either of the original two options (email link, class key). There is no record of the class on their account.
5.5 Join Class
Once a user pays for their class (or the class is determined not to need payment), they will officially
join the class.
Appendix B
Technical Abstract
While the benefits of learning by doing has been long-established in education, experiments have not gained traction in social science classrooms, largely due to lack of accessible, scalable, and robust platforms, both hardware and software, for such real time interactions. This is particularly alarming because immersive, experiential learning is still largely missing in Economics, Psychology, and Political Science courses even as these school subjects are becoming increasingly popular across the globe. Since fall 201 1, we have been developing a one-stop system with all the necessary technical and pedagogical components that would improve the accessibility of classroom experiments. Through our system, we:
• Shorten experiment setup time while making configuration more flexible.
• Cope with unpredictable student participation.
• Leverage 3G/4G networks for interactive experiments using mobile smart devices. · Design game interfaces that best engage students and relate to their real world experiences.
The system guides instructors to adopt this experimental approach to teaching, to engage students in active learning, and to efficiently develop experiments across client platforms. Commercial Potential of the Product
This project has significant commercial potential, as it is aiming to be the first attempt to introduce large-scale, interactive experiments to social science classrooms through mobile platforms. Students, institutions and educational publishers can all be potential buyers. Social scientists may find the solution attractive, because of its mobility and flexibility, particularly for field experiments. It can improve increasingly popular online courses, which are often being criticized for lack of interactivity. Finally, as the solution becomes more polished and generalized, consulting agencies and even the public at large may find value in it for training and honing strategic thinking skills.
I. Technical Content
1. Significance
a. Problem
The fundamental problem we have tried to solve is the lack of adoption and integration of experiments and games into social science curricula, despite clear evidence that they enhance teaching and engage students. 1 We have identified the following key factors that contribute to the problem.
o Lack of Suitable Technology
1 Mark Dickie found that classroom experiments increased learning in introductory microeconomics courses. Dickie, Mark. "Do Classroom Experiments Increase Learning in Introductory Microeconomics?" Journal of Economic Education 37.3 (2006) : 267-288. • Software. Paper-and-pencil experiments are time and labor intensive and they lack immediate feedback about the experiment results. 2 Desktop applications or web-based experiments are more recent developments, but instructors are still constrained by technological limitations such as the size of computer labs or operating system on the client computers. Additionally, existing solutions are often developed as a research tool first and an education tool second, as a result it often lacks the necessary scalability to support large classroom experiments.
• Network. By solely relying on wired or Wi-Fi wireless networks, the current solution limits the number of students that can participate in the classroom experiment. Network congestion becomes a sever bottleneck for running experiments in classes larger than a couple of hundred students.
• Usability. Configuring an experiment to suit lecture needs can be a time-consuming and frustrating task if the system is not designed intuitively and flexibly. Furthermore, unlike controlled laboratory experiments, student behavior in classrooms can be unpredictable and this in turn demands the system to be robust in handling the number of participants. Lastly, all currently available solutions require pre-class setup that makes it nearly impossible for instructors to adjust based on the actual progress of the lecture.
• Real-time feedback. Current technologies pay little attention to what happens after a classroom experiment is run, yet one of the benefits that classroom experiments can offer is the immediate feedback and spirited discussions of the results while the topic is fresh.
o Lack of Support
• Technical support. Lack of professional and 24/7 technical support from existing experimental software makes it difficult for instructors to reliably run experiments in classrooms, especially when lecture time is scarce.
• Operational support. Running interactive experiments with hundreds of students, sometimes many more when it comes to online courses, is largely unprecedented. The lack of knowledge and systematic studies of how to best organize such activities has limited the adoption of experiments in classrooms, especially for large introductory classes.
• Content support. Instructors who find value in integrated classroom experiments, but lack proper training, have a steep learning curve with the currently available products, which are not intuitive when paired with little instruction, and not user friendly (both on the educator and student side). 3
Given these challenges and the benefits of classroom experiments, it is clear that investing in a comprehensive solution is worthwhile. However, before such a solution can be created, research on product feasibility and accessibility is crucial to ensure the product addresses the problems above.
b. The Product, its Implementation and Intended Outcomes*
The Product
We have developed a mobile educational gaming technology, combined with detailed supplementary materials, to bring interactive experiments into social science classrooms, both
2 Miller, T. B. (1999). Experiments with Economic Principles: Microeconomics, 2nd Edition. Irwin McGraw-Hill.
3 La Martina, David. "Looking Forward: The N MC's Predictions for 2015" Edcetera. Oct. 16, 2012. face-to-face and online. We plan to bring this product primarily to undergraduate classes, but it would also be available to high school and post-graduate classes. The product would empower instructors to conduct experiments under unpredictable classroom conditions with minimal effort in setup and with only a few students to thousands of students. Furthermore, dedicated computer laboratories are no longer a requirement as students can participate using their mobile devices from anywhere at any time. Finally, it provides students with real-time feedback and results immediately after the experiment so they can discuss and digest the results without delay.
There are four main components in the MobLab product:
• Instructor console. The instructor console is a web application that allows instructors to
Figure 1: Instructor Console. Here the instructor can add students to his/her class, create an experiment using drag-n-drop modules from the MobLab game template library, run and monitor the process in real-time, and display the summary results immediately after the experiment.
• Multi-platform client-side game module. In addition to all major web browsers, the and
Figure 2: Game Interfaces on iPhone and Android. On the left is a screenshot of an alternating round bargaining game on the iPhone, where students will be able to negotiate over how to divide a stack of coins. On the right is a screenshot of an English auction on an Android smartphone, where students will be able to outbid one another for a chance at owning the Mona Lisa.
• A client neutral, cloud-ready server. In addition to its scalability and support for different client endpoints, the server's flexible game engine allows various game flows and makes adding new games straightforward.
• A detailed and easy to follow experimental manual. This content component includes standardized game templates, parameter descriptions, and best practices.
The Implementation This product would be integrated into an instructor's in-class time at the instructor's discretion, given the topics being covered and the appropriateness of the experiment for that day in class. It would alter the instructional approach to give students the opportunity for immersive learning and self-discovery rather than passive listening or material memorization.
Figure 3: How An Experiment Works. This flow chart illustrates the steps taken by an instructor and his/her students on how to conduct and participate in an experiment using the MobLab system. The instructor's steps are shown along the top thread and the students' steps are shown along the bottom thread. In the end, both the instructor and the students will review and analyze the experiment results.
Technical requirements for using the MobLab system in classrooms are straightforward. Besides having access to either a Wi-Fi or cellular network, instructors need a computer or tablet to use the web-based console, while students can use their choice of mobile computing device, whether that is a laptop, iPad, iPhone or Android smartphone.
We expect minimal changes to an instructor's expected level of resources. Our instructor console can be accessed using any of the major browsers. Additionally, most universities are moving towards blanket coverage of Wi-Fi networks on campus. College students often have more than one way of getting on the Internet using various personal mobile computing devices. Monetarily, our product will not add an additional resource burden to instructors, as it will be offered to them for free. Students will gain access to MobLab classroom games through either an in-app purchase or an institution-wide licensing plan.
The Intended Outcomes
The intended outcomes from using this product are a deeper understanding of the subject being studied and greater student engagement. Students will engage by participating in the games, discussing the results with their peers after the game, analyzing the data they generated themselves, and tying insights they gathered from the games back to theories. Instructors will save time and effort because they can quickly configure games before or during a class using either our default parameters or providing their own parameters. Figure 4 compares the traditional lecture with experiment-based active learning using the prototype for the Market experiment.
For context, in the Market experiment, students become buyers or sellers of a good. Sellers post prices they are willing to sell their good for, given a cost constraint and buyers post prices they are willing to buy a good for, given a value function. By participating in the market experiment, students internalize concepts such as supply, demand, price discovery and negotiation.
Figure 4: How MobLab Changes Teaching via the Market Experiment. This diagram illustrates the fundamental changes between using MobLab and pencil-and-paper to teach a class using a market experiment. In such a class, the topics covered may include, supply, demand, and equilibrium pricing. By using the more effective, efficient and immersive MobLab solution, instructors and students can really focus on exploring these topics first hand and in-depth.
c. Theory of Change, and Theoretical and Empirical Support*
First, we improve student and educator classroom experiences and skills. Second, we anticipate our product will benefit the research community and education administrations. Finally, we built a product that can be used by the general public and businesses to better understand the social sciences. Our desired outcomes are feasible given past research on interactive learning, digital technology in the classroom and how mobile technology has improved the toolset of researchers. Figure 5 uses a logic model to illustrate our theory of change.
Figure 5: MobLab Logic Model. The Logic Model shows how we will use our Inputs and Outputs to change the way the education community as a whole is teaching the social sciences. Our Outcomes are divided into short, medium and long-term impacts for students, educators and the research community.
There is rich empirical evidence that backs our belief in the importance and effectiveness of interactive learning. Published research shows that students who participated in experiments throughout an introductory microeconomics course learned more material than students who participated in a lecture-only class. 4 More broadly, Nobel laureate Carl Wieman and two coauthors published a study in Science that compared education outcomes between a typical lecture class with a class using the "deliberate practice" model. 5 The deliberate practice structure had students using the scientific method and solving problems during class time. The results showed that not only did the students in the deliberate practice model perform twice as well on a 12-question multiple-choice test of the course material, but attendance rose by 20%. A post-study survey indicated that a majority of students would prefer an interactive experience in class. The benefits of an interactive education are clear and our product will finally make it easier to deliver such an education in the social sciences.
Our aim to enrich educators' abilities and curriculum by integrating mobile gaming technology into social science classrooms is also backed by evidence of previous successes. Abilene Christian University has created an innovative program where every student has been given an iPhone or iPod Touch since 2009. A hurdle that Abilene has had to overcome is training educators who had little experience with mobile technology. To address this problem, they provided mobile training and support to their instructors. 6 Abilene has seen positive results with this five-year research program and has been developing apps to extend learning beyond the classroom. Adding previously unknown technologies into lectures and classrooms can be a daunting task for unprepared faculty members. Our product will bring the "chalk-and-talk" lecture to the 21 st century without compromising on accessibility and ease for educators new to the technology.
Finally, although our product is an education tool first, it will be able to facilitate research. Such a tool would be useful to experimenters because it allows a common platform for cross- cultural and multi-generational studies. Brian Dillion described the use of mobile phones to conduct research in developing countries. 7 He details a study where researchers were able to collect economic data from rural Tanzanian households for nearly a year using mobile phones to interview subjects. The scattered location of the participants and the frequency of data points would not allow for in-person interviews or mail-in surveys.
d. Similar Products or Typical Practices
As previously mentioned, classroom experiments and the technology used to run them are not new. Currently, classroom experiments are typically conducted one of three ways: by paper and pencil, through desktop applications or through web applications.
Paper and pencil classroom experiments have been around for decades. Typically, an instructor consults a textbook with pre-designed experiments and has to create the response
Dickie, Mark. "Do Classroom Experiments Increase Learning in Introductory Microeconomics?" Journal of Economic Education 37.3 (2006): 267-288.
5 Deslauriers, Louis, Ellen Schelew and Carl Weiman. "Improved Learning in a Large- Enrollment Physics Class" Science 332.6031 (2011): 862-864.
6 Abilene Christian University Mobile Learning website. Accessed November 29, 2012.
7 Dillon, Brian. "Using Mobile Phones to Conduct Research in Developing Countries" Cornell University February 2010. worksheets, instructions and manage the data collection methods themselves. 8 This is a time intensive process for the instructor and does not always provide students with immediate feedback regarding the experiment results. Thus, only the most dedicated or experienced instructors would regularly run experiments throughout the course while the majority might only do one or two experiments for the course if time permitted.
With the advent of personal computing, desktop applications have become another way of conducting classroom experiments. Educators will often use software that is either already written or program their own experiments. 9 Such software allows educators to code an endless number of unique experiments, but all experiments have to be run in a laboratory setting. The personal cost for an educator to learn to program is high. Additionally, the costs of building and maintaining computer labs that can host these classroom and research experiments are typically too high to justify for many universities.
Finally, using web applications to run classroom experiments is becoming increasingly popular for educators with prior experience in experimental fields. 10 Web applications are useful because they eliminate the need for expensive laboratory facilities. However, instructors are often limited in their resources to continually improve their games, instructor materials, and software. Some web applications only provide economic simulations, providing no interactivity with other students.
Given these similar products, MobLab is in a unique position with regards to the benefits it can provide to classrooms around the world. First, MobLab's mobile technology will ensure a computer laboratory will never be a necessity for running a classroom experiment. This also means our software is easy to integrate into online and face-to-face courses. Second, the instructor console allows instructors to quickly and easily configure experiments given uncertain classroom conditions. Instructors will never have to print worksheets, program a new experiment or fiddle with unintuitive web applications to run a classroom experiment. Third, MobLab's software can be used in conjunction with any textbook and the supplemental materials we provide will be game-specific with suggestions for curriculum integration.
1. Tool for research experiments. MobLab's software can be used in field-based and laboratory research experiments. Since the 1980's, the experimental economics field has seen explosive growth and there are currently over 170 experimental economics laboratories worldwide. 11 The software's features can facilitate field experiments because it allows participants to be mobile and the easy-to-use interface could be a selling point for researchers wanting to run experiments with atypical subject populations.
2. Technical Objectives/solutions
Textbook examples include Markets, Games and Strategic Behavior by Charlie Holt or Experiments with Economic Principles: Microeconomics by Theodore Bergstrom.
9 Such programs include Ztree and Multistage.
10 Providers of such web applications include Veconlab, EconPort and MyEconLab. Veconlab and EconPort are university-run initiatives; MyEconLab is a commercial venture through Pearson.
11 Bardsley, Nicholas, Robin Cubitt, Graham Loomes, Peter Moffatt, Christ Starmer & Robert Sugden. Experimental Economics: Rethinking the Rules. Princeton University Press (2009). Compilation of experimental economic laboratories from the Montpellier Laboratory of Theoretical and Applied Economics at the University of Montepellier. Objective: Minimize experiment preparation time, allow on-the-fly modification of experiment configuration, and provide real-time feedback and data analysis.
Solution: An HTML and JavaScript based instructor console. A classroom experiment is easy to setup using our modularized game system. Each game comes with a set of fully functional and easily customizable parameters. To configure an experiment, an instructor simply drags-n-drops the desired game into his or her game queue. Furthermore, instructors can switch game order, skip, add, or repeat any particular game during the class to accommodate in-class progress. Finally, instructors can monitor experiment progress in real time and display summary statistics immediately after a game is finished.
Objective: Remove dependence on computer labs and wired networks and let students participate using their preferred mobile device anywhere and at anytime. Solution: Web- based and native client game modules. By allowing games to run from all major browsers, Android smartphones, iPhones and iPads, students will have more than one hardware option for participation. The computer lab is no longer needed for this method of teaching. Wireless smart devices can also automatically hop from one network band to another or even to a cellular network in case of congestion.
Objective: Cope with unpredictable environmental factors such as student behavior and different class sizes.
Solution: A message-driven server with a flexible game engine. Unlike in research experiments, student attendance for class can be rather unpredictable— if they do attend, they may come late or leave early. Our server maximizes the participation by allowing students to join late while ensuring game progression even in the case of students dropping out of the game early. A lightweight, message-driven server implementation simplifies and optimizes information processing. This offers the capacity to support a large number of concurrent experiments and different class sizes. With a well-defined API and the application of programming patterns, the game engine subcomponent makes both game customization and new game incorporation a straightforward process.
Objective: Provide sufficient and easy to follow supplementary materials to instructors with little or no prior experience with running classroom experiments.
Solution: A step-by-step experimental manual. Useful content will play a critical role in lowering the barrier to entry especially for instructors with little or no prior experience. In addition to the simple and easy-to-follow guide, we will provide formal descriptions of the game parameters, detailed discussions on the game data and summary, and finally, suggestions on the best practices for student engagement.
Appendix C
Part i: Identification and Significance of the Innovation
Our mission for MobLab is to bridge the gap between traditional "chalk and talk" teaching in the social sciences and real-world social and economic interactions through fun, engaging, and interactive classroom experiments. The core innovation of MobLab is the delivery of a scalable, interactive software system capable of handling large-scale experiments simultaneously in environments where client hardware and behavior may be completely unpredictable. In the absence of any reliable public Wi-Fi network, our technological breakthrough allows dynamic discovery of hotspots on smart mobile devices and transparent formation of ad-hoc private networks, and therefore supports decentralized experiment execution and data synchronization. The creativity of MobLab is also reflected in its product design and application. Our team has been designing simple, intuitive and engaging user interfaces. Furthermore, we plan to develop experiment protocols and best practices based on classroom observations, surveys, and crowdsourced discussions. Eventually, we hope to design complex scenarios where individual games can be tethered to form a storyline, which runs in parallel with the corresponding curriculum.
Research in experimental economics on topics including markets, auctions, bargaining, and public goods has blossomed since the pioneering work of Vernon Smith (2002 Nobel Laureate) and many others decades ago. Dickie (2007) found that classroom experiments increased learning in introductory microeconomics courses. Instructors in high schools, universities, and business schools want motivated students who actively learn the principles of economics and other social science disciplines through hands-on experience. However, with the exception of some college courses, especially those taught by experimental economists, most students still don't have the opportunity to learn by playing these games in class due to technological constraints. Running paper and pencil experiments with the students is time- and labor- intensive with no immediate feedback about the results (Miller, 1999). Desktop applications are tied to labs, a luxury for most schools, and not easily scalable in terms of the number of student participants or the number of concurrent experiments.
Currendy, instructors usually run one or two simple experiments at most throughout the course to illustrate concepts but our innovation allows them to seamlessly integrate many experiments into the curriculum. MobLab gives instructors the flexibility to tailor the game setup to their course needs and smoothly run experiments under unpredictable classroom conditions. Never before could experiments be easily run in classes with hundreds of students and never before would students get real-time feedback during and immediately after the experiment so that they can digest the results immediately. Our innovations are also not purely technical as we plan to provide instructors with a fully supported integrated system that drastically reduces the work required to get experiments up and running in the classroom compared to previous solutions. The suite of games will be easily customizable but our default instructions, parameters, and protocols often plenty of guidance for instructors with no previous experience with experiments. The barrier to adoption is kept as low as possible for new users (instructors and students) because it will be just another familiar and engaging app interface for them rather than the existing sparse and academic interfaces that are geared toward the research lab rather than the classroom.
In addition to enriching existing classes, MobLab can shape how new economics classes, especially in high school, are taught in the future. According to the latest Council for Economics Education survey in 2009, "21 states now require students to take an Economics course as a high school graduation requirement (up from 17 in 2007 and 13 in 1998). These 21 states make up nearly 65% of the entire U.S. population." In addition, 49 states plus the District of Columbia contain Economics in their curriculum standards and 40 of those states require those standards to be implemented. Thus we anticipate that more and more high schools will be offering Economics courses or modules and MobLab can provide them with a comprehensive suite of connected, scenario-based games that correspond to many of the economic principles they will be required to teach. The currently available software supplement for high school economics classes involve simulations, quizzes, and stories but very little interaction. The situation is quite similar in business schools where there is a strong demand for the latest technology. Instructors and students in high schools, community colleges, and business schools are mostly potential new users because many have not even considered the possibility of running interactive markets or bargaining games in the classroom. Once they see how easy it is and what benefits can be reaped, we believe they will also be some of the most receptive.
*Part 2: Background and Technical Objectives
Overview We have developed and deployed a functional working application that allows us to systematically assess the feasibility of conducting interactive experiments in classrooms and subsequently collect feedback from both instructors and students. Through this process, we built incremental releases that let us address both design and implementation concerns in key areas of the system in separated and integrated ways, and to evaluate the effects on learning and establish best practices based on these preliminary results. Details of the technical objectives and how they meet the needs of our potential customers are described as follows.
Intuitive, Simple and Engaging User Interfaces for Mobile Platforms
Technical Objective Even with the recent exponential advances in Internet and mobile technologies, developing interactive applications across mobile platforms still poses a significant challenge largely due to the heterogeneity in both vendor-specific hardware (various screen sizes and hardware components) and underlying software platforms (web, iOS, Android, etc.). Early prototypes allowed us to accomplish the following objectives.
• Collect and incorporate user feedback early and iteratively even before a working application
• Create a set of fun, aesthetic and engaging UI designs
• Standardize the way users may interact with the interfaces and the result screens
• Converge on consistent look and feel across different mobile platforms
• Evaluate the effectiveness of various client-side technologies, e.g. Java, Object C, and HTML5/JavaScript, on rendering the desired UI designs
Customer Needs Our team knows from years of research experience as well as informal surveys with colleagues who run experiments across the social science disciplines what visual displays work for students. Just as importandy, we know what to avoid putting on the screens that might confuse the students as they process information and make decisions. Experimental economists and psychologists have learned over the decades the importance of consistent interfaces and attention to details. MobLab will hew closely to the consensus in the field regarding visual displays whenever such a consensus has been honed from years of student feedback and will actively poll knowledgeable colleagues to uncover the best practice otherwise. We will also draw on the knowledge of game designers to assemble a set of self-explanatory and addictive interfaces so that students will have a sense of familiarity and control as they interact, facilitating the absorption of abstract concepts.
A Scalable, Event-Driven Server Program
Technical Objective Existing experimental software is typically designed to cope with one experiment at a time and limited number of stable client connections. However, these assumptions are no longer valid for MobLab's targeted environments where the number of concurrent experiment sessions, the number of participations per session, participant connectivity to the server during a session, and network availability can be unpredictable. A functional server-side application stack allows us to address critical system requirements early and with reduced complexity. More specifically, we have
• Developed automated functional and performance testing frameworks and suites
• Built multiple fail-safe measures to cope with unpredictable student participation patterns during an experimental session
• Explored possible optimizations for event-driven client-server communications, in- memory data caching, and asynchronous storage input/output
• Designed minimally-coupled and easily-extendable API for future incorporation of new games and integration with other enterprise applications
Customer Needs Introductory Economics courses at universities such as UCLA or FSU usually have hundreds of students enrolled. Many universities still do not have a dedicated experimental social sciences laboratory and out of those that do, the largest one, CASSEL based at UCLA, has a 70-workstation capacity. Even generic computer labs in higher education do not have the capacity to accommodate these large introductory classes. Thus instructors cannot use any of the available desktop applications for running classroom experiments once their classes reach a certain size. The current web-based applications for running classroom experiments were also not designed with scalability or concurrency in mind. With MobLab, instructors in different parts of the U.S. can confidently run experiments with hundreds of students at the same time.
Deliver interactive Games
'Technical Objective The system allows us to obtain an integrated view of the system from both user's and engineer's perspectives and to achieve the following objectives.
• Identify potential bottlenecks and establish best practices for efficient cross-platform game development
• Develop common client side libraries to reduce platform specific code
· Evaluate experiment execution with a mixed types of client mobile platforms
• Estimate engineering cost of developing a new game
• Assess extensibility of the system with incorporation of new games
• Observe user behaviors, from both the organizers and participants, in classrooms Customer Needs The games we developed for the prototype are two of the most popular and representative games in experimental social sciences. The continuous double-auction market experiment, pioneered by Smith (1962), clearly demonstrates the principles of supply and demand and competitive equilibrium. Our brief case study illustrates the pedagogical power of this game. Furthermore, this game can also be easily modified in MobLab with simple parameter changes to illustrate the impact of price floors and ceiling, taxes, etc. on the market. The second game, alternating offers bargaining (Rubinstein, 1982), two parties take turns making offers on splitting a "shrinking pie" until an agreement is reached. This type of bargaining is at the heart of many political, business, and everyday interactions. Furthermore, the one-offer only case is the ultimatum game (Giith et al., 1982) and a modified version of the two-offer case is the trust game (Berg et al., 1995), two extremely popular games used in lab and field experiments to understand social preferences and norms. We will also design an extremely flexible survey module that can be deployed as a standalone session or be attached to an experiment, either before or after it. The module can be a survey, a quiz, or a tutorial where participants get hints when they give the wrong answer to a question; there will a large menu of types of questions (multiple choice, free form, true/false, rating, etc.) and ways to submit answers (text box, radio buttons, slider, etc.). The survey module has many uses, not limited to: making sure the participants understand the experiment, screening or grouping participants based on survey answers, gathering background or experiment-relevant (e.g. strategies used) information, debriefing after the experiment, making the lectures more interactive, and so on. Test Experiment Execution in Unpredictable Network Environments Technical Objective Availability of stable and sufficient public wireless network for classrooms largely depends campus IT infrastructure, location of the classroom, size of the class, and student wireless devices. To better assess how network quality and bandwidth affect the performance and delivery of MobLab, we focus on the following tasks.
• Evaluate the feasibility of clients using different wireless networks, bands, and channels participating in an experiment session transparently
• Assess the tradeoffs among different types of wireless networks in terms of capacity for number of concurrent connections, traffic congestion, and bandwidth availability · Develop easy-to-follow procedures for creating ad-hoc private networks by leveraging hotspots offered by smart devices when no public wireless network is available
Customer Needs Instructors need to know that they can run experiments smoothly under any classroom conditions so as to not waste valuable class time. For example, they may want to know if allowing different client devices has any effect on participation behavior. In addition, students would know that they have redundant options for participation, which minimizes the probability of any student being excluded. Students can switch devices in the middle of an experiment if one is out of power or borrow a phone from his/her classmate to continue if the network gets too congested and maintain stability for the experiment.
Evaluate Deployment On Cloud
Choosing the right cloud hosting service plays a critical role in maintaining scalability and availability, staying vendor neutral, and keeping the cost low for MobLab. MobLab has accomplished the following key deployment objectives.
• Assess the feasibility of deploying MobLab on cloud computing platform
• Identify vendor and platform specific requirements, if any, for deployment
· Evaluate the efficiency of dynamically allocating server resources based on real-time demand
• Compare setup, maintenance, monitor, and backup costs among different vendors Customer Needs If using MobLab is to become a routine classroom activity, instructors need to have the flexibility of arranging experiments anytime, anywhere, and anyway they want. The recent advancements in cloud computing has made this scalability, agility and reliability a reality at affordable prices.
*Part 3: Research Plan
Technical Research Plan
Development Guidelines The development of MobLab must be agile, iterative, and test-driven. One of the critical strategic focuses for MobLab is to offer fun, engaging and interactive games. Adopting the agile practice advocates more people-centric viewpoints by encouraging the technical team to routinely publish feature-oriented releases and to constantly communicate with and solicit feedback from the research team. Although optimization typically comes at later stages in software development life cycle, we plan to exercise it early and often as the performance and scalability are of paramount importance for MobLab given the potentially large number of participants and concurrent sessions it may have to cope with regularly. Small, iterative cycles allow us to uncover these unforeseen technical hurdles and design issues early and to refine design goals proactively. Finally, we strongly believe in the test-driven philosophy in delivering quality and robust code as well as lowering long-term system maintenance cost. Unit tests offer us measurements on the correctness of the system functionalities as well as their design; stress tests let us establish benchmarks on performance and scalability; lastly, integrated tests allow us to evaluate the system as a whole from a user's perspective. MobLab was developed simultaneously on multiple client platforms, including web, smartphones and tablets. Besides budgeting additional financial and human resources, we plan our engineering roadmap with the following guidelines in order to help us better cope with project risks and uncertainties.
• Increment complexity gradually— start with simple survey application that allows us quickly assess the technical learning curves on various client platforms and difficulties of organizing large, real-time classroom activities.
• Prioritize platform— focus on iPhone and web platforms initially before porting to
Android based smartphones and tablets.
• Routine peer review— encourage shared ownership on code and programming practices.
Data Security All data communications among clients and between clients and servers are through encrypted SSL channels. Except the binary client side program on the mobile devices, the amount of personal experimental data stored locally is minimized largely through stateless and robust HTTP request and response round trips. Furthermore, access to data through MobLab app on client devices is always password protected.
Design Visual Prototypes on Mobile Platforms By working closely together, our UI designer and client-side engineers to constructed visual prototypes for various presentation endpoints, including web, tablet, mobile phones, and smartphone such as iPhone, Android, and RIM phones. During the process, we will construct detailed comparisons on the pros and cons of developing games and log the best practices on each of the underlying platforms— HTML, JAVA, Object C, and JavaScript. With recently published open-source work on developing native applications for one smartphone platform then cross compiling for other platforms (Puder and Yoon, 2010), we plan to experiment with this framework for implementing games more efficiently and with less code duplication.
In addition, the other major part of the visual prototyping was to thoroughly evaluate various built-in UI widgets, which are commonly used in games such as label, text field, button, table, slider, spinner and graph. The outcomes from this research are at least twofold: 1) let us identify the widget set that are common across various platforms; 2) gain in-depth understanding of how events can be registered and processed for each widget.
Develop A Server-Side Prototype The design and implementation of server-side of MobLab meet the requirements of being flexible, robust, scalable, extensible, and testable. The MobLab server-side addresses each of the requirements specifically.
• Flexibility— Server-side presentation layer is designed to be agnostic to any specific client-side technology. A subscriber-and-publisher messaging pattern is applied to ensure the decoupling.
• Robustness— In the context of MobLab, the server has to be robust enough to cope with unpredictable participation behaviors such as joining an experiment session at different times, leaving early, and reconnecting in the middle of the session. Thus it demands careful caching and efficient retrieval of experimental states. Furthermore, simple yet testable paths are iteratively developed to cover both normal and unexpected behaviors.
• Scalability— Throughputs on the server are measured in terms of number of messages it can process, number of participants it can accommodate, and number of experiments it can host simultaneously. The server stack is designed to be able to spawn across multiple application servers transparently and to rely on data storage in a multi-tier deployment.
• Extensibility— Whether it can incorporate new games quickly and efficiently and integrate seamlessly with other enterprise applications, especially those in the educational space, plays an important role in MobLab's adoptability. Public programming interface for each of its component and layer on the application stack is iteratively refined through formal analysis, design, and implementation cycles.
• Testability— It not only serves as a good benchmark on the quality of the system design but also lowers the costs of incorporating new features and long-term code maintenance. Test-driven practice is applied to develop automated, full-coverage functional tests at design instead of implementation stage to gauge code understandability and isolate- ability.
The following diagram summarizes MobLab server-side architecture.
Deliver interactive Prototype Games Two games, alternating offers bargaining and markets, are chosen as end-to-end prototypes for this phase of research for both their relevance in various economics classes and their representation of distinct classes of games. Structurally, bargaining is an alternate move game while markets are asynchronous. Graphically, bargaining can be intuitively implemented using 2-D graphs whereas markets demand a sophisticated composite interface.
Alternating Offers Bargaining. Two players decide on how to share the total endowment (the 'pie') using the following process. Suppose the 'pie' size is 1. Player 1 makes a proposal of the following split: x for Player 1 and 1-x for Player 2. If the game ends there and this split is implemented, then it would be the Dictator Game. If not, then Player 2 now has to decide whether to accept or reject the proposal. If Player 2 accepts the proposal, then the split is implemented. In the renowned Ultimatum Game, if Player 2 rejects, then both players receive 0 payoff and the game ends. Otherwise, the payoffs are now discounted because one period of the bargaining game has passed and no agreement has been reached. If both players have the same discount rate, then the 'pie' shrinks by this common rate S. Otherwise the delay could be more cosdy for one player than the other. Player 2 now makes a proposal for splitting the pie and Player 1 can decide to accept or reject. This process continues until some fixed number of periods has elapsed or until the 'pie' is gone. A salient example is the bargaining between a firm and a labor union. The longer the process drags on, the more cosdy it is for both sides, i.e. the more shrinkage of the 'pie'.
• Bargaining Game User Interfaces
Description:
Round (top left label): to indicate the current round of the bargaining.
Total (top right label): to show the current total left in this round.
Blue portion of the pie denotes the portion the proposer decides to keep in round, while the orange portion is offered to the receiver.
Make Offer button: submit the offer with the given split to the receiver
Accept Offer button: accepts the offer and the game ends
Reject Offer button: rejects the offer and a new round of bargaining starts
History button: shows the history of the bargaining rounds so far
Continuous Markets. Goods Market: Each trader is assigned a role, either Buyer or Seller, and a private value for the good. Sellers are endowed with a unit of the good. In the continuous market, buyers can make bids to buy and sellers can make offers to sell at a certain price and all bids and offers are placed in the open order book in real-time. A transaction occurs when the current best offer or bid is accepted. In the call market, bids and asks are submitted and a market clearing rule determines the price and number of transactions.
Screen Description:
■ Market Open (top label): number of seconds until market closes.
■ Price Chart: displays transaction price-time series in real time.
■ Account Table: reports user account information in real time.
■ Action buttons on the bottom: allow users to buy, sell, cancel orders and access other menu items such as view order and transaction histories.
Test Experiment Execution in Unpredictable Network Environments Classroom pilots may be arranged to assess the effects of different types of wireless network on experiment operation once a functional prototype becomes available. Specifically, test plans are executed in the following environments.
• Wi-Fi network
• Mobile cellular networks
• Mixed Wi-Fi and cellular networks
• Ad-hoc Wi-Fi network using personal hotspots on smartphones
These field tests offer unique opportunities for us to collect user experience feedback for UI comparisons and improvement, and to identify potential network bottlenecks and workarounds.
Deploy MobLab on Cloud As the number of cloud computing service provider increases rapidly in recent years, careful considerations must be taken to choose the right solution that matches MobLab's deployment requirements. MobLab was prototyped on Amazon Elastic Computing Cloud, in order to quickly test various simulated load conditions and collect data on the following metrics, which would help us identify the most suitable solution down the road.
• Resource Availability— Confirm that under various load conditions a vendor solution can dynamically allocate sufficient, but not excess, CPU, memory, and bandwidth in order to maintain reasonable response time. Under the same load condition, compare resource usages and server throughput among the 3 vendor platforms.
• Vendor Specific Deployment Requirement— Gain in-depth understanding of these requirements and cost for conforming and switching.
• Cost— Compare the costs of under same load condition and UP time among the vendors.
Education Market Analysis The potential market for MobLab in education is large, stable, and ever expanding. There are over 5000 institutions of higher education and over 40,000 high schools, not to mention more than 2000 MBA programs in the US alone. Economics, in particular, is growing in popularity as more than 40% of high school students take an Economics course and it has become a top major in undergraduate studies. The following graph
demonstrates the annual enrollment at High School (HS) and Higher Education levels (Institute of Education Sciences, U.S. High School Annual Enrollment Statistics, 2010) (Institute of Education Sciences, Projections of Higher Education Statistics to 2017, 2010). The online learning market is also rapidly growing and MobLab can be seamlessly integrated with online modules. According to the Sloan Consortium (Allen and Seaman, 2010), more than 5.6 million students, nearly one-third of all higher education students took at least one online course in the Fall 2009 term. This represents a 21% increase over the previous year.
The following table listed some of the target fields and classes for which MobLab can be applicable.
Mobile Market Analysis The mobile device market worldwide has enjoyed double, sometimes even triple, digit annual growth in the past decade. This meteoric rise is even evident in emerging markets. The forms of mobile devices are becoming ever versatile as well, from laptops and tablets to smartphones. Surveys have shown that over 80% teens and nearly 100% of young adults in 2010 carry mobile phones. Many campuses now enjoy full wireless network coverage. We are also at the beginning of a new wireless era where smartphones with 3G or 4G access become the standard device that customers use to connect with friends, colleagues, the Internet and the world at large.
Product Delivery and Market Penetration We recognize that best product delivery is the result of optimizing internal engineering, management practices and continuous communications with our customers. Our strategy centers on delivering early and frequendy, implementing feature- orient short iterations, and working closely with instructors ('buyers').
Next Patent: GLUCOSE RATE INCREASE DETECTOR: A MEAL DETECTION MODULE FOR THE HEALTH MONITORING SYSTEM