Information processing system, method for controlling information processing system, and program

Abstract

To improve operability in a tutorial.SOLUTION: An information processing system has: display control means that performs control to show an input target item to which a user should input information in one procedure of a plurality of procedures included in a tutorial, and display, in a guide area, a copy item for receiving an instruction to copy a copy target being the information to be input to the input target item; and control means that performs control to copy the copy target according to the fact that the copy item has been operated, and input the copy target to the input target item according to the fact that a paste operation has been performed for the input target item.SELECTED DRAWING: Figure 13

Description

[Technical field]

[0001] The present invention relates to an information processing system, a control method for an information processing system, and a program, and in particular to a technique suitable for use in constructing application software. [Background technology]

[0002] Conventionally, there are application construction tools that construct application software (hereinafter referred to as application) according to definitions as no-code development tools / low-code development tools that do not require or require little coding in a programming language. Patent Document 1 proposes that screen components such as buttons, text boxes, etc. can be placed by drag and drop on a layout editor screen for editing the screen of a Web application to be constructed, and the placed screen components are stored in an input / output definition table.

[0003] Tutorials for learning the functions of application software are also known. Patent Document 2 proposes executing a tutorial selected from a plurality of tutorials and displaying the progress of the tutorial. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2019-49858 A [Patent Document 2] JP 2001-356858 A Summary of the Invention [Problem to be solved by the invention]

[0005] There are some tutorials that allow users to actually execute the functions of software by following the software tutorial. In tutorials that execute the actual functions of software, if the input is not correct, the software will not work properly. For example, in a tutorial on creating a REST function, if the URL to which the request is sent is not input correctly, the REST function created in the tutorial will not work properly. However, actually inputting strings in the operations in the tutorial is time-consuming and increases the possibility of mistakes. In addition, although users may not have completely mastered or understood the multiple steps (procedures) included in the tutorial, they would like to be able to quickly complete the content that they have already mastered or understood with a simple confirmation. Nevertheless, it is time-consuming to have to manually input the correct information in the operations in the tutorial. In addition, if the correct information is not input, users cannot proceed further in the tutorial, but they may have difficulty proceeding further in the tutorial because they do not know how to input the correct information or what the correct information is.

[0006] In view of the above problems, an object of the present invention is to provide a mechanism for further improving operability in tutorials. [Means for solving the problem]

[0007] The information processing system of the present invention comprises: a display control means for controlling to display an input target item in which a user should input information in one step among a plurality of steps included in a tutorial, and to display a copy item in a guide area for receiving an instruction to copy a copy target, which is information to be input into the input target item; copying the copy target in response to the operation of the copy item; a control means for controlling the input of the copy target into the input target item in response to a paste operation being performed on the input target item; The present invention is characterized by having the following. Effect of the Invention

[0008] According to the present invention, it is possible to further improve operability in a tutorial. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a system configuration diagram of an information processing system. [Diagram 2] FIG. 2 is a hardware block diagram of a developer terminal 100, an application user terminal 200, and an application user terminal 201. [Diagram 3] 13 is a flowchart of a login process. [Figure 4] 13 is a flowchart of a UI editor process. [Diagram 5] This is a display example during login processing and UI editor processing. [Figure 6] This is an example of how tab components and AppBars are displayed in the UI editor. [Figure 7] 13 is a flowchart of a context menu process. [Figure 8] 13 is a flowchart of an action board process. [Figure 9] 13 is a display example for explaining an action board process. [Figure 10] 13 is a display example in action board processing. [Figure 11] 2 is an example of source code generated by the development environment 300. [Figure 12] 13 is a flowchart of a screen switching process. [Figure 13] 13 is a flowchart of a tutorial process. [Figure 14] 13 is a display example relating to the tutorial process. [Figure 15] 13 is a display example relating to the tutorial process. [Figure 16] 13 is a display example relating to the tutorial process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the invention according to the claims, and not all combinations of features described in the embodiments are essential to the invention. Two or more features among the multiple features described in the embodiments may be arbitrarily combined. In addition, the same reference numbers are used for the same or similar configurations, and duplicated descriptions are omitted.

[0011] Various features shown in the following embodiments can be combined with each other. In the following, "application" and "app" both mean application software.

[0012] <System configuration> A system configuration diagram of an information processing system according to an embodiment of the present invention is shown in Fig. 1. Fig. 1 shows a system for developing software and a system for using the developed software.

[0013] The developer terminal 100 is an information processing device (information processing terminal) that can be configured with a personal computer (hereinafter, PC), a smartphone, or the like and is operated by a developer user. In other words, it is a user terminal of the developer user. The developer terminal 100 accepts design operations for an application to be developed from the developer, and transmits various definition information of the application, which is the designed content, to the development environment 300.

[0014] The development environment 300 is an environment that uses at least one hardware resource built on a network (on the cloud, on the Internet). The development environment 300 is a multi-tenant environment, and multiple developer users can log in to the environment. The development environment 300 includes developer information 301, an execution engine 302, and storage 320. The development environment 300 is built by combining multiple Web services (cloud services).

[0015] The developer information 301 is information that records the developer's account that can log in to the development environment 300, such as an email address (user ID) that serves as the developer's account ID, and a password. The developer information 301 is recorded in at least one recording medium included in the development environment 300.

[0016] The execution engine 302 is at least one hardware resource for executing a process to be executed in the development environment 300, and includes a processor 303 and a memory 304. The processor 303 is composed of at least one processor, and may be one processor on a cloud, or may be a processor group combining a plurality of processors. The memory 304 is at least one recording medium on which a program to be executed by the processor 303 is recorded. Among the various flowcharts described below, those described as being executed by the development environment 300 are executed by the execution engine 302. In other words, the program recorded in the memory 304 is realized by the processor 303 expanding it into an area of ​​the development environment 300 that serves as a work memory and executing it.

[0017] The distribution engine 305 transmits, to the developer terminal 100 that has accessed the development environment 300, a client program 322 (such as HTML source code or JavaScript source code) to be executed on the developer terminal 100. The client program 322 is pre-recorded in the storage 320 included in the development environment 300.

[0018] Storage 320 is a storage area of ​​at least one recording medium, and stores at least client program 322 that is common to each developer. It also has a developer area, which is a storage area for each developer account. For example, if there are developer A, developer B, and developer C as developers who can log in, it includes developer A area 323, which is an area for developer A, developer B area 324, which is an area for developer B, and developer C area 325, which is an area for developer C. Each developer area stores definition information of an app developed by each developer. For example, developer A area 323 stores app definition 323a (including UI definition information of the app and a program for the execution environment of the app).

[0019] The developer accesses the development environment 300 by accessing a URL for accessing the development environment 300 from the browser software of the developer terminal 100, and logs in to the development environment. When the developer logs in to the development environment, the developer receives the client program 322 and the application definition (UI definition information) that is the content of the past development work and saved from the development environment. Then, the developer performs an operation to design a new application or an operation to update and design an existing (in-progress) application, and transmits the resultant application definition information (application definition, UI definition information) to the development environment 300. The development environment 300 saves the received application definition in its developer area. In this way, in this embodiment, any terminal that can access the development environment 300 on the cloud can be used as the developer terminal 100 to design an application. Therefore, as long as there is a terminal that can connect to the Internet, the developer can develop an application regardless of location.

[0020] The execution environment 400 is an environment using at least one hardware resource built on a network (on a cloud or on the Internet). The execution environment 400 includes a multi-tenant execution environment 410 and multiple single-tenant execution environments (for example, single-tenant execution environments 450, 460, 470). The execution environment 400 is built by combining multiple Web services (cloud services). The execution environment 400 is an environment for deploying definition information (application definition) of an application developed using the developer terminal 100 and the development environment 300. The application user terminals 200 and 201 used by users who use the application access the execution environment 400 by accessing a URL for executing the application. The execution environment 400 executes various actions according to operations performed on the application user terminals 200 and 201, thereby executing the developed application and providing the application user with the functions of the application. The application built in the execution environment 400 on the network is a so-called WEB application.

[0021] The multitenant execution environment 410 is an execution environment of a multitenant environment shared by multiple developers, and applications developed by multiple developers are deployed in the multitenant execution environment 410. In other words, the multitenant execution environment 410 is an environment shared by multiple developers, and is an environment in which multiple applications by multiple developers can be built. The multitenant execution environment 410 includes user information 411, an execution engine 412, a delivery engine 415, a storage 420, and a DB set 433.

[0022] The user information 411 is information that records the account of an application user who can log in to the application, such as an email address (user name) that serves as a user account ID for the deployed application (constructed application), a password, etc. The user information 411 is recorded in at least one recording medium included in the multi-tenant execution environment 410.

[0023] The execution engine 412 is at least one hardware resource for executing a process to be executed in the multitenant execution environment 410, and includes a processor 413 and a memory 414. The processor 413 is composed of at least one processor, and may be one processor on a cloud, or may be a processor group combining a plurality of processors. The memory 414 is at least one recording medium in which a program to be executed by the processor 413 is recorded. Among various flowcharts described later, those described as being executed by the multitenant execution environment 410 are executed by the execution engine 412. That is, the processor 413 expands and executes the program recorded in the memory 414 in an area serving as a work memory in the multitenant execution environment 410. The program executed here includes a program that executes an action of an application.

[0024] The distribution engine 415 transmits a client program 422 (such as HTML source code or JavaScript source code) to be executed on the application user terminal 200, 201 to the application user terminal 200, 201 that has accessed the multi-tenant execution environment 410. The client program 422 is pre-recorded in a storage 420 included in the execution environment 410.

[0025] The storage 420 is a storage area of ​​at least one recording medium, and stores at least a client program 422 that is common to a plurality of applications. In addition, in a predetermined area (a predetermined folder, a predetermined bucket, a predetermined level) of the storage 420, access destination information 421 for accessing the execution environment (multi-tenant execution environment 410) is recorded. In addition, there is a developer area which is a storage area for each developer account. For example, it includes a developer A area 423 which is an area for developer A, a developer B area 424 which is an area for developer B, and a developer C area 425 which is an area for developer C. In each developer area, definition information of an application developed by each developer and deployed from the development environment 300 is stored. For example, an application definition 423a is recorded in the developer A area 423.

[0026] The DB set 430 is a group of information related to databases used by applications deployed in the execution environment 410. The DB set 430 is stored in a storage area of ​​at least one recording medium.

[0027] Each of the single tenant execution environments 1 (450), 2 (460), and 3 (470) is an execution environment dedicated to one developer (one developer account), and an application developed by the developer who is the owner using the development environment 300 is deployed therein. In this embodiment, as an example, the owner of the single tenant execution environment 1 (450) is Developer A, the owner of the single tenant execution environment 2 (460) is also Developer A, and the owner of the single tenant execution environment 3 (470) is Developer B. In this manner, one developer can own multiple single tenant execution environments. The single tenant execution environments 1 (450), 2 (460), and 3 (470) include user information 451, 461, and 471, execution engines 452, 462, and 472, delivery engines 455, 465, and 475, storages 456, 466, and 476, and DB sets 457, 467, and 477, respectively. Except for the fact that these are dedicated to one developer, they have the same functions as the user information 411, execution engine 412, delivery engine 415, storage 420, and DB set 433 of the multi-tenant execution environment 410 described above, so detailed explanations will be omitted. It is possible to build many more single-tenant execution environments in addition to the three shown in the figure.

[0028] Using the system of FIG. 1, for example, an operator may provide the multi-tenant execution environment 410 to a developer free of charge, and provide the single-tenant execution environment for a fee. The operator of this system must pay maintenance costs to the resource and service provider (cloud service operator) for both the multi-tenant execution environment 410 and each single-tenant execution environment. By having the operator bear the maintenance costs of the multi-tenant execution environment 410 and provide it free of charge to multiple developers, the developers do not need to bear the costs for trial use of this system, making it easy for many developers to use and promoting the spread of this system. The operator recovers costs by charging developers for the single-tenant execution environments.

[0029] There is an upper limit to the number of processing requests that can be processed per unit time in one execution environment, and when many applications are built in a multi-tenant execution environment and many app users access the environment simultaneously, the requests cannot be processed, which may result in the applications running slowly. In addition, there are some limitations on the number of applications developed by many developers that can be deployed and executed in a multi-tenant execution environment, and these limitations may prevent the applications from performing satisfactorily. If a developer pays to own a dedicated single-tenant execution environment, the problems caused by the limitations of such a multi-tenant execution environment can be avoided (or reduced). In other words, by building an application in a single-tenant execution environment, it is possible to build an application that performs satisfactorily.

[0030] Considering the characteristics of both the multi-tenant single environment and the single-tenant execution environment, the developer can use the system as follows. For example, when using the system for the first time, the developer can build an application developed using the system in the multi-tenant execution environment 410 and test it, and then, if the developer determines that the system is useful for the developer's software development, introduce the single-tenant execution environment for a fee. When developing a specific application X, the developer builds an alpha version of the application X in the multi-tenant execution environment 410 for a limited number of test users to test before releasing it to general users. The developer tests the application X, modifies the application X, and further develops it. After the development is completed to a level where it can be released to general users, the developer builds a production version of the application X in the single-tenant execution environment and releases it to general users. By using the system in this way, the developer can reduce development costs during the development period and operate an application without problems even when used by a large number of general users.

[0031] Fig. 2 shows a hardware block diagram of an information processing device as an example of a device (electronic device) applicable as developer terminal 100, application user terminal 200, and application user terminal 201. In Fig. 2, CPU 101, memory 102, non-volatile memory 103, image processing unit 104, display 105, operation unit 106, recording medium I / F 107, external I / F 109, and communication I / F 110 are connected to internal bus 150. The respective units connected to internal bus 150 are configured to be able to exchange data with each other via internal bus 150.

[0032] The memory 102 is, for example, a RAM (a volatile memory using a semiconductor element, etc.). The CPU 101 uses the memory 102 as a work memory to control each part of the information processing device according to a program stored in, for example, the non-volatile memory 103. The non-volatile memory 103 stores image data, audio data, other data, various programs for the operation of the CPU 101, etc. The non-volatile memory 103 is, for example, a hard disk (HD), a ROM, etc.

[0033] The image processing unit 104 performs various image processing on image data stored in the non-volatile memory 103 or the recording medium 108, video signals acquired via the external I / F 109, image data acquired via the communication I / F 110, captured images, etc., under the control of the CPU 101. The image processing performed by the image processing unit 104 includes A / D conversion processing, D / A conversion processing, image data encoding processing, compression processing, decoding processing, enlargement / reduction processing (resizing), noise reduction processing, color conversion processing, etc. The image processing unit 104 may be configured with a circuit block dedicated to performing a specific image processing. Depending on the type of image processing, the CPU 101 can also perform image processing according to a program without using the image processing unit 104.

[0034] Display 105 displays images, GUI screens constituting a GUI (Graphical User Interface), and the like under the control of CPU 101. CPU 101 generates a display control signal according to a program, and controls each part of the information processing device to generate a video signal for display on display 105 and output it to display 105. Display 105 displays an image based on the output video signal. Note that the configuration of the information processing device itself is limited to an interface for outputting a video signal for display on display 105, and display 105 may be configured as an external monitor (such as a television). Hereinafter, unless otherwise specified, the display destination in processes executed by developer terminal 100, application user terminal 200, and application user terminal 201 is assumed to be display 105 of each operator.

[0035] The operation unit 106 is an input device for receiving user operations, including a character information input device such as a keyboard, a pointing device such as a mouse or a touch panel, a button, a dial, a joystick, a touch sensor, a touch pad, etc. The touch panel is an input device that is configured as a plane overlaid on the display 105 and outputs coordinate information according to the touched position.

[0036] The recording medium I / F 107 is capable of receiving a recording medium 108 such as a memory card, CD, or DVD, and reads data from the received recording medium 108 and writes data to the recording medium 108 under the control of the CPU 101. The external I / F 109 is an interface for connecting to an external device via a wired cable or wirelessly, and inputting and outputting video and audio signals. The communication I / F 110 is an interface for communicating with an external device, the Internet 111, and the like, and transmitting and receiving various data such as files and commands. The developer terminal 100 is capable of communicating with a development environment 300 on the Internet 111 (capable of transmitting and receiving information) using the communication I / F 110. The application user terminals 200 and 201 are capable of communicating with an execution environment 400 on the Internet 111 (capable of transmitting and receiving information) using the communication I / F 110.

[0037] <Login process> 3(a) and (b) show a flowchart of the login process. This process is a process from logging in to the development environment 300 from the developer terminal 100 to displaying a UI editor. When the developer terminal 100 starts the Internet browser software and receives an instruction to specify the URL of the development system (application development platform) of this embodiment and access it, the process of FIG. 3(a) is started. The process of FIG. 3(a) is realized by the CPU 101 of the developer terminal 100 expanding a program recorded in the non-volatile memory 103 for executing the Internet browser software and a client program 322 received from the development environment 300 in the memory 102 and executing them. Hereinafter, what is simply described as a process executed by the developer terminal 100 is assumed to be a process in which the CPU 101 of the developer terminal 100 expands a program recorded in the non-volatile memory 103 for executing the Internet browser software and a client program 322 received from the development environment 300 in the memory 102 and executes them.

[0038] When an internet browser software is launched on the developer terminal 100 and the URL of the development system (application development platform) of this embodiment is specified and accessed, the distribution engine 305 of the development environment 300 detects the access and transmits a client program 322 to the developer terminal 100 that originated the access.

[0039] In S301, the developer terminal 100 determines whether or not it has received the client program 322 (client information) sent from the development environment 300. If it has not been received, it waits for reception in S301, and proceeds to S302 when it has been received.

[0040] In S302, the developer terminal 100 records the client program 322 (client information) received from the development environment 300 in the memory 102.

[0041] In S303, the developer terminal 100 displays a login screen on the display 105 in accordance with the client program 322. The login screen displays a message indicating that this is a login screen for the development system of this embodiment, as well as input fields for the developer ID and password, a new registration button (icon), and a login button (icon).

[0042] In S304, the developer terminal 100 accepts input operations into the input fields of the login screen for the developer ID and password. The user's input operations are performed using the operation unit 106. The developer ID is user identification information for identifying (specifying) the developer user. In this embodiment, the developer ID (user name) is an email address. Furthermore, the password used as the secret information is an arbitrary character string, but it may be other secret information such as biometric authentication information (fingerprint authentication is information used for face authentication) or pattern authentication information (information of a trajectory pattern entered on the screen).

[0043] In S305, the developer terminal 100 determines whether an operation has been performed (e.g., a click) to instruct the New Registration button on the login screen. Note that hereinafter, an operation to instruct a display item (a display object or display item such as a button or icon) by clicking with the mouse included in the operation unit 106 or by touching the touch panel will be referred to simply as "pressing." If the New Registration button has been pressed, the process proceeds to S306, and if not, the process proceeds to S307.

[0044] In S306, the developer terminal 100 performs developer account registration processing.

[0045] In S307, the developer terminal 100 determines whether or not the login button on the login screen has been pressed. If the login button has been pressed, the process proceeds to S308, and if not, the process returns to S304.

[0046] In S308, the developer terminal 100 transmits, as login information, the information entered in the developer ID and password input fields on the login screen (the entered developer ID and password) to the development environment 300. After transmission, authentication processing is performed in the development environment 300, so the developer terminal 100 waits for the result.

[0047] In S309, the developer terminal 100 determines whether or not it has received information about a login error from the development environment 300. If it has received information about a login error, it returns to S304 and accepts input of login information again, and if not, it proceeds to S310.

[0048] In S310, the developer terminal 100 determines whether or not it has received an execution environment list from the development environment 300. Since the development environment 300 transmits the execution environment list to the developer terminal 100 if the login authentication is successful, receiving the execution environment list means that the login authentication was successful (login was successful). If the execution environment list has been received, the process proceeds to S311, and if not, the process returns to S309.

[0049] In S311, the developer terminal 100 records the execution environment list received in S310 in memory 102 as a development screen for the application after login, and displays execution environment options based on the received execution environment list on the display 105. The execution environment list indicates the execution environments that the logged-in developer can access. Note that screens displayed on the developer terminal 100 after S311 that are different from the screen of the constructed application are collectively referred to as development screens.

[0050] FIG. 5(a) shows an example of the display of execution environment options in S311. In the display example of FIG. 5(a), two options are displayed as execution environments that the logged-in developer can access: option 551 corresponding to the multi-tenant execution environment 410, and option 552 corresponding to the single-tenant execution environment. The developer user can select one of these options by pressing it, and can confirm the selection by pressing the SAVE button 553. What is selected here is the destination to which the application updated in the subsequent work during this login will be deployed. The execution environment is not accessed at this point. The execution environment selected here can be changed by the operation described later.

[0051] In S312, the developer terminal 100 determines whether or not an execution environment has been selected. If one of the execution environment options is pressed and the SAVE button 553 is pressed, the process proceeds to S313, and if not, the process waits for the selection of the execution environment in S312.

[0052] In S313, the developer terminal 100 records information (such as an execution environment ID) that identifies the execution environment selected in S312 in memory 102 as the "selected execution environment" and transmits it to the development environment 300. In response to receiving the information that identifies the selected execution environment (selected environment), the development environment 300 transmits, as application information, information (such as application IDs and application names) that identifies all applications owned by the logged-in developer (applications that have been generated in the past and recorded in storage 320).

[0053] In S314, the developer terminal 100 determines whether or not application information has been received from the development environment 300. If application information has been received, the process proceeds to S315, and if not, the developer terminal 100 waits for reception of application information in S314.

[0054] In S315, the developer terminal 100 records the received application information in memory 102, and displays on the display 105 a list of applications (application list) owned (under development) by the logged-in user based on the application information.

[0055] In S316, the developer terminal 100 determines whether or not any application has been selected from the list of applications displayed in the application list. If any application has been selected, the process proceeds to S317, and if not, the process proceeds to S320.

[0056] In S317, the developer terminal 100 records the application selected from the application list as the “selected application” in memory 102 and transmits information identifying the selected application (such as the application ID or application name) to the development environment 300. When the development environment 300 receives the information identifying the selected application, it obtains definition information (application definition) of the selected application from the area of ​​the logged-in developer in storage 320 and transmits it to the developer terminal 100.

[0057] In S318, the developer terminal 100 judges whether or not it has received definition information (UI definition information) of the selected application from the development environment 300. If it has received the definition information of the selected application, it records the received definition information of the selected application in the memory 102 and proceeds to S319, otherwise, it waits for the reception of the definition information in S318. In this embodiment, it is assumed that this definition information is a Json file in which various definitions related to the application are described in Json format. Thereafter, when the selected application is displayed on the display 105, the display is performed based on the definition information recorded in the memory 102. When an operation for updating the selected application (for example, changing the arrangement of UI parts) is performed in the UI editor process described later, the definition information in the memory 102 is updated to define the updated content. Then, when a save instruction is given, the latest definition information recorded in the memory 102 is transmitted to the development environment 300 and saved in the area of ​​the login developer in the storage 320. In this way, an increase in the frequency of communication with the development environment 300 is suppressed, and a decrease in response due to communication is suppressed, thereby making it possible to perform a comfortable update operation.

[0058] In S319, the developer terminal 100 displays a UI editor screen on the display 105 and performs display based on the received definition information. For example, a canvas (editing area of ​​a UI screen) with a shape according to whether the selected application is for desktop or mobile (i.e., a shape according to the type of device using the application) is displayed. If it is for desktop, a rectangular canvas with a ratio of 16:9 is used, and if it is for mobile, a canvas with a vertical aspect ratio imitating a smartphone is used. A list of UI screens that the selected application has (belongs to the selected application) is displayed in the submenu area (described later) (strictly speaking, this process is performed in S401 in FIG. 4 described later). In addition, the canvas displays components (UI parts to be placed on a UI screen) that are to be placed on a UI screen selected by default (initial UI or UI screen that was edited when last saved). Note that the UI screen to be edited may not be selected by default, and nothing may be displayed on the canvas at this point. The login process is terminated in the process of S319, and the process proceeds to S401 in FIG. 4.

[0059] Meanwhile, in S320, the developer terminal 100 determines whether an icon for creating a new application (Create Application button 1402 in FIG. 14(a)) displayed on the screen displaying the list of applications has been pressed, and whether an instruction to create a new application has been issued. If it is determined that an instruction to create a new application has been issued, the process proceeds to S321, and if not, the process proceeds to S350.

[0060] In S350, the developer terminal 100 determines whether or not the tutorial button 1401 (FIG. 14(a)) has been pressed. If the tutorial button 1401 has been pressed, the process proceeds to S351, and if not, the process proceeds to S316.

[0061] In S351, the developer terminal 100 performs tutorial button processing. The tutorial processing will be described later with reference to FIG.

[0062] In S321, the developer terminal 100 displays a selection screen for whether the newly created application is for desktop use (for PC) or for mobile use, and accepts an operation to select one of them. A desktop application is an application that is intended to be accessed and operated from an application user terminal 200 such as a desktop PC or a notebook PC. A mobile application is an application that is intended to be accessed and operated from an application user terminal 201 such as a smartphone.

[0063] In S322, the developer terminal 100 displays a screen for accepting input of basic application information (at least an application name and an application ID) for the application to be newly created, and accepts an input operation for setting the application information. When the input of the application information is accepted, the information on whether the application is for desktop (PC) or mobile, accepted in S321, and the application information accepted in S322 are transmitted to the development environment 300. In this way, definition information of the new application is created in the storage 320 of the development environment 300 as definition information of the newly created application, and the information on whether the application is for desktop (PC) or mobile, the application name, and the application ID are recorded in this way in the definition information of applications that have already been created in the past.

[0064] In S323, the developer terminal 100 displays a UI editor screen as an editing screen for the newly created application. In this case, the canvas is displayed in a shape according to whether it is for desktop or mobile, selected in S321. Also, the canvas is displayed as blank information with no components placed on it. The login process ends in the process of S323, and then the process proceeds to S401 in FIG. 4.

[0065] Figure 3(b) shows the login process on the development environment 300 side which cooperates with the login process on the developer terminal 100 side in Figure 3(a). The process in Figure 3(b) is realized by processor 303 of development environment 300 expanding a program recorded in memory 304 into an area of ​​development environment 300 that serves as a work memory, and executing the program. Hereinafter, what is simply described as a process executed by development environment 300 is assumed to be a process executed by execution engine 302 of development environment 300, or more specifically, by processor 303.

[0066] In S331, the development environment 300 determines whether or not the login information transmitted in S308 from the developer terminal 100 has been received. If the login information has been received, the process proceeds to S332, and if not, the process waits for reception of the login information.

[0067] In S332, the development environment 300 compares the received login information with the developer information 301 and performs login authentication (user authentication). More specifically, it is determined whether the developer information 301 (user information) contains information that matches the developer ID and password pair contained in the received login information. If so, authentication is successful.

[0068] In S333, the development environment 300 determines whether the result of the authentication process in S332 is that login is OK (authentication was successful, was authenticated, authentication is OK) or not. If login is OK, the process proceeds to S335, and if login is not OK, the process proceeds to S334, where information indicating a login error is sent to the developer terminal 100.

[0069] In S335, the development environment 300 transmits to the developer terminal 100 a list of execution environments of developers (login developers) whose login has been approved and is included in the developer information 301. In addition to an email address (username, developer ID) and password, the developer information 301 records an accessible execution environment ID for each developer. Each execution environment ID is an account ID in a cloud service (web service), and is a 12-digit ID in this embodiment. In the case of a developer who can access multiple execution environments, the 12-digit execution environment ID is recorded separated by a comma. In S335, the accessible execution environment ID (one or more execution environment IDs separated by a comma) for the login developer is transmitted to the developer terminal 100. That is, in S335, the execution environment that the login developer can access is specified by referring to the developer information 301. In this way, the accessible execution environment of each developer (the execution environment that each developer can use) is recorded in the developer information 301 recorded in the development environment 300. This execution environment that can be logged in can only be obtained by a developer whose login has been approved. In addition, only the accessible execution environment of the developer that has been granted login permission can be obtained. This eliminates the need for the developer to manage information for accessing the accessible execution environment separately from information for logging in to the development environment 300. It is also possible to prevent other users from illegally accessing the execution environment.

[0070] In S336, the development environment 300 determines whether or not it has received information (environment identification information) identifying the selected execution environment transmitted in S313 from the developer terminal 100. If it has received information identifying the selected execution environment, it proceeds to S337, and if not, it waits for reception of information identifying the selected execution environment.

[0071] In S337, the development environment 300 records the selected execution environment in a settings management file stored in the logged-in developer area of ​​the storage 320 based on the information identifying the selected execution environment received in S336.

[0072] In S338, the development environment 300 obtains application information indicating all applications owned by the logged-in developer (created by the logged-in developer) from the logged-in developer's area in storage 320, and transmits this information to the developer terminal 100. The application information transmitted here is only the application definition information necessary to display the application list described above in S315, and does not include detailed definition information regarding each application (such as component placement and information indicating actions described below).

[0073] In S339, the development environment 300 determines whether or not information about the new application (information about whether it is for desktop (PC) or mobile, and information including the application name and application ID) has been received from the developer terminal 100 in S322. If information about the new application has been received, the process proceeds to S340, and if not, the process proceeds to S341.

[0074] In S340, the development environment 300 creates and records definition information of a new application in the area of ​​the login developer in the storage 320 based on the information on the new application received in S339. The definition information recorded here includes information on whether the application is for desktop (PC) or mobile, the application name, and the application ID. In the development environment 300, in order to distinguish the application from applications of other users in the multitenant execution environment 410, an eight-digit developer code that uniquely corresponds to the developer ID of the developer who owns the application is added immediately before the ID input by the developer in S322 as the application ID and recorded. Then, the login process ends. After that, when performing internal processing or when displaying in a programming language on the action board, if an application ID is used, the process is performed with the ID to which the developer code of the login developer is added. In addition, when displaying as an application ID in a UI editor, etc., only the ID part input by the developer in S322, excluding the developer code, is displayed.

[0075] In S341, the development environment 300 determines whether it has received information identifying the selected app transmitted from the developer terminal 100 in S317. If it has received the information identifying the selected app, it proceeds to S342; otherwise, it returns to S339.

[0076] In S342, based on the information identifying the selected app received in S341, the development environment 300 acquires the definition information (app definition) of the selected app from the area of the logged-in developer in the storage 320 and transmits it to the developer terminal 100. The definition information transmitted here includes detailed definition information regarding the selected app (such as the arrangement of components and information indicating actions described later). Then, the login process ends.

[0077] <UI Editor Processing> The UI editor processing will be described with reference to FIGS. 4 and 5(b). The UI editor processing is a process of performing various definitions (definitions of UI components, action definitions) of the application to be constructed in response to operations from the developer (user) on the UI editor screen (application development screen).

[0078] FIG. 5(b) shows an example display of the layout editing screen displayed in the UI editor processing on the display 105. The screen in FIG. 5(b) includes a header menu area 500, a main menu area 510, a sub-menu area 520, and a canvas 530 (the editing reception area for the UI screen).

[0079] In the header menu area 500, a selected execution environment box 501, a selected app box 502, a selected UI screen box 503, a save button 504, a preview button 505, and a deploy button 506 are displayed.

[0080] The selected execution environment box 501 displays the selected execution environment ID as information representing the selected execution environment. By pressing the arrow icon on the right end of the selected execution environment box 501, a list of execution environments accessible to the logged-in developer acquired in S310 is displayed as a pull-down menu, and the selected execution environment can be changed by selecting any execution environment from the list. Even if the selected execution environment is changed, the selected app is not changed, and the contents displayed in the main menu area 510, the submenu area 520, and the canvas 530 are not changed. In this way, by changing the selected execution environment to which the same application is to be deployed, it is possible to deploy the same application to any multiple execution environments.

[0081] The selected app box 502 displays the name of the selected app as information representing the selected app. Pressing the arrow icon on the right end of the selected app box 502 displays a pull-down menu containing a list of apps owned by the logged-in developer acquired in S314, and the selected app can be changed by selecting any app from the list. When the selected app is changed, the content to be displayed in the submenu area 520 and the canvas 530 changes.

[0082] In selected UI screen box 503, the name of the UI screen being edited is displayed as information representing the UI screen being edited in canvas 530. By pressing the arrow icon in selected UI screen box 503, a list of UI screens belonging to the selected application based on the definition information of the selected application acquired in S318 is displayed as a pull-down menu, and it is possible to change the UI screen to be edited and displayed in canvas 530 by selecting an arbitrary UI screen from the list.

[0083] In the main menu area 510, an application list button 511, a UI screen button 512, a workflow button 513, a settings button 514, an environment list button 515, a database button 516, a file manager button 517, a user management button 518, and a snapshot button 519 are displayed as selection icons for menu items of the main menu. Processing in response to pressing of these selections will be described later in the screen switching processing of FIG.

[0084] A submenu corresponding to an item selected in the main menu is displayed in the submenu area 520. In the example of Fig. 5(b), a UI component list (UI widget list) is displayed as a lower-level menu of the UI screen button 512.

[0085] The canvas 530 is a layout editing area for the selected UI screen of the selected application (the UI screen of the UI screen name displayed in the selected UI screen box 503). The canvas 530 in FIG. 5(b) is an example of a canvas display for a desktop application, and is displayed in a shape for a desktop. The user can select any UI widget (UI component) from the UI widget list displayed in the submenu area 520 and place it in the canvas area 530 by dragging and dropping it. The size and position of the UI widget can be adjusted by selecting the UI widget placed in the canvas area 530. In addition, by selecting a UI widget placed in the canvas area 530 and right-clicking to display a right-click menu (context menu), more detailed settings such as color scheme can be performed. Furthermore, by selecting an action also included in the context menu, an action board is displayed, and an action to be executed when the UI widget is operated can be set. The canvas context menu can be displayed by right-clicking with the cursor in a blank area of ​​the canvas 530, and an action to be executed (executed when the UI screen is displayed) when the UI screen of the canvas is loaded in the constructed application can be set by selecting an action included in the context menu.

[0086] 5(b) shows an example in which a pie chart 531, a button 532, text fields 533 and 534, an output field 535, and a tab component 536 are arranged as UI components on a canvas 530 with a UI screen name "ui1" of an application with an application name "UI1". Operation path 531a is a selection frame indicating the selected UI component and an operation path (operation handle) that accepts zooming instructions, and indicates that pie chart 531 is selected.

[0087] A flowchart of the UI editor process is shown in Fig. 4. This process is executed by the developer terminal 100, and is performed following S319 or S323 in Fig. 3.

[0088] In S401, developer terminal 100 displays a list of UI screens of the selected application as options in submenu area 520 based on the definition information of the selected application. Each screen displayed in this UI screen list is a screen designed as a screen to be displayed when the selected application is deployed and constructed in an execution environment, and is accessed from application user terminal 200, 201 and executed. This UI screen list can also accept operations to add a new UI screen and operations to delete a UI screen.

[0089] In S402, the developer terminal 100 determines whether or not an operation has been performed to select any of the UI screens from the list of UI screens displayed in S401. If any of the UI screens has been selected, the process proceeds to S404, and if not, the process proceeds to S403.

[0090] In S403, it is determined whether or not an operation has been performed to select any of the options displayed in the main menu area 510. If an option displayed in the main menu area 510 has been selected, the UI editor process ends and the process proceeds to screen switching process, which will be described later with reference to Fig. 12. If not, the process returns to S402.

[0091] In S404, the developer terminal 100 displays the UI screen selected in S402 on the canvas 530 based on the definition information of the selected application recorded in the memory 102. If the UI screen has UI widgets previously arranged, the UI widgets previously arranged according to the definition information are displayed on the canvas 530. In other words, if a UI screen was created partway through in the past, it can be developed from the beginning. If the UI screen selected in S402 is a newly created UI screen, the canvas 530 is displayed blank with no UI widgets arranged. If the UI screen selected in S402 is a UI screen (template screen) prepared in advance as a template, a template component with a predetermined action defined is displayed at a predetermined position on the canvas 530 even if the user has not previously arranged UI widgets on the UI screen.

[0092] In S405, the developer terminal 100 displays a list of UI widgets in the submenu area 520. That is, the display is switched from the UI screen list of the selected application to the UI widget list. UI widgets that can be arranged on the canvas 530 include types INPUT, Button, Display (information displaying widget), Navigation, Layout, and Chart, and a plurality of UI widgets are classified into each type. In the UI widget list, a list of UI widget types is first displayed as shown in FIG. 5(c), and in response to an operation to select one of the displayed types, UI widgets classified into the selected type are expanded and displayed. The above-mentioned FIG. 5(b) is an example in which the option 522 of the type corresponding to INPUT is selected and a list of UI widgets classified into INPUT is displayed. UI widgets classified into INPUT include, for example, a text field 523 and a text area 524. The submenu area 520 is scrollable, and options that cannot be displayed (options of the UI widget of the expanded type and options of other types) can be scrolled to display them. When an expanded type option 522 is operated as in FIG. 5B, the expanded UI widget list for that type is collapsed, and a list of UI widget types is displayed.

[0093] In S406, developer terminal 100 determines whether or not a UI widget displayed in submenu area 520 has been selected. More specifically, it determines whether or not an operation has been performed to drag a UI widget displayed in submenu area 520. If a UI widget displayed in submenu area 520 has been selected, the process proceeds to S407, and if not, the process proceeds to S411.

[0094] In S407, developer terminal 100 determines whether or not an operation to specify a position on canvas 530 has been performed. More specifically, it determines whether or not an operation to drop a dragged UI component onto canvas 530 has been performed. If an operation to specify canvas 530 has been performed, the process proceeds to S408, and if not, the process waits for specification of a position on canvas 530 in S407. Note that, although an example of drag and drop will be described in this embodiment, the method of operation is not limited to this as long as it is an operation to select a UI component from submenu area 520 and place it at a specified position on canvas 530.

[0095] In S408, the developer terminal 100 determines whether or not the position on the canvas specified in S407 is included in the area of ​​a tab part (a type of UI part) that has already been placed. If it is not included in the area of ​​the tab part, the process proceeds to S409, and if it is included in the area of ​​the tab part, the process proceeds to S410. An example of the tab part is the tab part 536 shown in Fig. 5(b). The tab part has multiple tabs (in the example of Fig. 5(b), there are three tabs displayed as ITEM1, ITEM2, and ITEM3), and when any one of the tabs is selected, the display content displayed by the tab part is switched to the element screen corresponding to the selected tab.

[0096] The tab part will be described with reference to Figs. 6(a) and (b). Fig. 6(a) is a display example on the display 105 when a tab part 601 is arranged on a canvas 530 displaying a UI screen different from that shown in Fig. 5(b). The range indicated by the operation bus 601a of the tab part 601 is the occupied area of ​​the tab part 601. By operating the operation bus 601a, the overall display position and overall display size of the tab part 601 including the element screen can be changed. The tab part 601 has three tabs, namely, tabs 610, 620, and 630. Labels that can be set by a developer in the property settings of the tab part are displayed as tab names on each tab. In the illustrated example, Tab0, Tab1, and Tab2 are displayed, respectively. The number and order of tabs can be changed from the property settings of the tab part. Tab property settings are performed by an operation to open a tab property box from the tab context menu in S706 of the context menu processing described later in Fig. 7, and a setting operation for the tab property box (setting screen) displayed in response to the operation. The element screen area 602 indicated by the dashed line (illustrated for explanation, not displayed) is an area in which the display contents change depending on the selected tab. The display contents corresponding to each tab displayed in the element screen area 602 are called the element screen corresponding to each tab. Different UI widgets can be arranged in the element screen corresponding to each tab. The example of FIG. 6(a) is an example in which the tab 610 is selected and the element screen corresponding to the tab 610 is displayed. In the illustrated example, the UI widget 611 and the UI widget 612 are arranged in the element screen corresponding to the tab 610. The example of FIG. 6(b) is an example of a display in which the tab 620 is clicked from the state of FIG. 6(a) and the selected tab is changed from the tab 610 to the tab 620. In FIG. 6(b), the element screen area 602 displays the element screen corresponding to the selected tab 620. In the illustrated example, the UI widget 621 is arranged in the element screen corresponding to the tab 620. In the examples of Figures 6(a) and 6(b), the definition information records at least the UI component ID (identification information of the UI component) of the tab component 601 and the position of the tab component 601 in the UI screen, in association with the ID (identification information of the UI screen) of the UI screen being edited on the canvas 530.Also, the IDs of UI widget 611 and UI widget 612 and the respective positions of UI widget 611 and UI widget 612 in the component screen of tab 610 are recorded in association with the ID of tab 610 of tab component 601 (identification information of the component screen). Also, the ID of UI widget 621 and the position of UI widget 621 in the component screen of tab 620 are recorded in association with the ID of tab 620 of tab component 601. Returning to the description of FIG. 4.

[0097] In S409, developer terminal 100 places the UI widget selected in S406 from submenu area 520 at a specified position on canvas 530 at a default size, and records information defining this in the definition information recorded in memory 102. That is, in the definition information, the type of UI widget placed in S410, UI widget ID, placement coordinates, placement size, etc. are recorded in association with the ID of the UI screen of the placement destination (the UI screen being edited).

[0098] In S410, the developer terminal 100 places the UI widget selected in S406 from the submenu area 520 in a default size on the element screen (currently displayed element screen) corresponding to the selected tab among the tab widgets at the specified position on the canvas 530, and records information defining this in the definition information recorded in the memory 102. That is, in the definition information, the type of the UI widget placed in S410, the ID of the tab widget as a UI widget ID, the ID of the tab selected in the tab widget, the placement coordinates in the element screen corresponding to the selected tab, the placement size, and the like are associated with the ID of the placement destination UI screen (UI screen being edited) and recorded. In this way, in this embodiment, it is possible to place and layout different UI widgets on each element screen corresponding to each tab of the tab widget. In addition, at this time, there is no need to perform complicated operations to define the tab of the element screen on which the UI widget is to be placed, and it is sufficient to simply select and display the placement destination element screen when placing the UI widget to be placed by dragging and dropping it.

[0099] In S411, the developer terminal 100 determines whether or not a UI widget already placed on the canvas 530 has been selected by clicking, etc. If a UI widget already placed has been clicked (selected), the process proceeds to S412, and if not, the process proceeds to S415.

[0100] In S412, the developer terminal 100 displays an operation path for the UI widget clicked in S411. Examples of the operation path display are the above-mentioned operation path 531a and operation path 601a.

[0101] In S413, the developer terminal 100 judges whether the position specified by clicking in S411 is within the area of ​​the tab part of the tab part. If it is not the tab part, the process proceeds to S431, and if it is the tab part, the process proceeds to S414. The tab part is a designation area that instructs switching to the corresponding element screen.

[0102] In S414, the developer terminal 100 switches the display of the element screen area of ​​the tab component to the element screen corresponding to the tab at the position specified by clicking in S411. For example, in response to clicking on any of the three tabs displayed as ITEM1, ITEM2, and ITEM3 in the tab component 536 in S411, the developer terminal 100 displays an operation path for the tab component 536 in S412 and switches the display content of the element screen area 436a to that of the element screen corresponding to the clicked tab. Also, in the case where the display is as shown in FIG. 6(a), for example, the display is switched to that of FIG. 6(b) in response to the designation of the tab 620. That is, the UI components 611 and 612 arranged on the element screen displayed before the click are hidden, and instead, the UI component 621 arranged on the element screen corresponding to the clicked tab 620 is displayed. Such control is performed in order to simplify the operation of defining the element screen of the desired tab to be placed when the developer wants to place another UI component on the element screen of the desired tab of the tab component. If a developer wants to place another UI widget on the component screen of a desired tab of a tab component, the developer can simply click on the desired tab to display the desired component screen before dragging and dropping the UI widget.

[0103] In this embodiment, for the sake of simplicity, the processes of S409, S410, S413, and S414 have been described using a tab part as an example, but the present invention is not limited to this. The processes of S409, S410, S413, and S414 can be applied to a UI part other than a tab part as long as the UI part is a predetermined type in which part of the display content in the UI part is switched in response to an operation on the UI part after an application is constructed.

[0104] On the other hand, in the case of other UI widgets that are not of a predetermined type, such as a tab widget, the display content of the UI widget is not changed in response to the selection of the UI widget on the canvas 530. The only processing performed in response to the selection of a UI widget is processing related to the display of an operation path, and no other actions are performed. For example, when button 532 is selected on the canvas 530 in FIG. 5(b), only an operation path is displayed, and the action of button 532 (processing executed when button 532 is pressed in the constructed application) is not executed. Also, when text field 533 is selected on the canvas 530, only an operation path is displayed, and processing such as displaying a character input cursor in text field 533 is not performed.

[0105] An example of an AppBar will be described with reference to Figs. 6(c), 6(d), and 6(e) as an example of a type of UI widget to which the processes of S409, S410, S413, and S414 can be applied in the same way as with the tab widget. Fig. 6(c) shows an example in which an AppBar650, a TextField661, and a Button662, which are UI widgets, are arranged on a canvas 530. The AppBar650 is one UI widget, and an element icon 651 and an element icon 652 are included in the AppBar650. In the constructed application, the element icon 651 is a display item that receives an instruction to display a drawer menu. In the constructed application, the element icon 652 is a display item that receives an instruction to display a pop-up menu. In the canvas 530, when the positions of the element icon 651 and the element icon 652 in the arranged AppBar650 are clicked, they are controlled in the same way as the tab part of the tab widget. More specifically, they are controlled as follows.

[0106] When the position of the element icon 651 in the arranged AppBar 650 is clicked (Yes in S411), an operation path for the AppBar 650 is displayed (S412), and the result of the determination in S413 is Yes, and a drawer menu is displayed as an element screen (S414). This causes a transition from the display state of FIG. 6(c) to the display state of FIG. 6(d). In FIG. 6(d), an operation path 650a for the AppBar 650 is displayed, and a drawer menu 651a, which is an element screen corresponding to the element icon 651, is displayed. The drawer menu 651a is an area displayed by pulling it out from the left end of the screen to the right, and displays one or more menu items. In a state where the drawer menu 651a is displayed, other UI components can be arranged in the drawer menu 651a by dragging another UI component from the submenu area 520 and dropping it on the drawer menu 651a, similar to the processing described in S408 and S410 using the tab component as an example.

[0107] When the position of the element icon 652 in the arranged AppBar 650 is clicked (Yes in S411), an operation path for the AppBar 650 is displayed (S412), and the result of the determination in S413 is Yes, and a pop-up menu is displayed as an element screen (S414). This causes a transition from the display state of FIG. 6(c) to the display state of FIG. 6(e). In FIG. 6(e), an operation path 650a for the AppBar 650 is displayed, and a pop-up menu 652a, which is an element screen corresponding to the element icon 652, is displayed. The pop-up menu 652a is an area displayed near the element icon 652, and displays one or more menu items (options). In a state where the pop-up menu 652a is displayed, other UI components can be arranged in the pop-up menu 652a by dragging another UI component from the submenu area 520 and dropping it on the pop-up menu 652a, similar to the processing described in S408 and S410 using the tab component as an example. Return to the description of FIG. 4.

[0108] In S415, the developer terminal 100 determines whether or not an operation to drag an already-placed UI widget on the canvas 530 has been performed. If an operation to drag an already-placed UI widget has been performed, the process proceeds to S416, and if not, the process proceeds to S417. In S416, the developer terminal 100 changes the position at which the dragged UI widget (selected component) is placed in response to the drag operation. Specifically, the UI widget is placed at the position where it was dropped. When the placement is changed, the definition information recorded in memory 102 is also updated to indicate the new position.

[0109] In S417, developer terminal 100 determines whether or not an operation has been performed on the operation path of a UI widget already placed on canvas 530. If an operation has been performed on the operation path, the process proceeds to S418, and if not, the process proceeds to S419. In S418, developer terminal 100 changes the size of the UI widget (selected widget) to which the operation path has been assigned in response to the operation on the operation path. When the size is changed, the definition information recorded in memory 102 is also updated to indicate the changed size.

[0110] In S419, the developer terminal 100 judges whether or not an instruction operation (in this embodiment, right-clicking of the mouse) for displaying a context menu has been performed in any area of ​​the canvas 530. If a right-click has been performed, the process proceeds to S420, and if not, the process proceeds to S421. In S420, a context menu (right-click menu) is displayed according to the position of the mouse cursor when the right-click has been performed, and a context menu process is performed to perform a process according to the operation on the context menu. For example, if a right-click is performed with the mouse cursor on the button 532 in FIG. 5(b), a context menu 540 related to the button 532 (designated UI part) as shown in FIG. 5(d) is displayed. In the context menu 540, property 541, action 542, and delete 543 are displayed as menu items to be selected. When property 541 is selected, a property box (detailed setting dialog) related to the button 532 is displayed, and detailed settings such as the button name (label) to be displayed on the button 532, the color of the button 532, and the size by specifying a numerical value can be performed. When action 542 is selected, an action board related to the button 532 is displayed, and an action can be input to the action board in JavaScript, which is a programming language. The action entered here is the process to be executed when the button 532 (designated UI widget) is pressed in the constructed application. When Delete 543 is selected, the button 532 is deleted (deleted) from the canvas 530. Details of the context menu process will be described later with reference to FIG. 7.

[0111] In S421, the developer terminal 100 determines whether or not the save button 504 has been pressed. If the save button 504 has been pressed, the process proceeds to S422, and if not, the process proceeds to S423. In S422, the developer terminal 100 transmits definition information of the application being edited that is recorded in memory 102 to the development environment 300. Upon receiving the definition information, the development environment 300 performs a save process.

[0112] In S423, the developer terminal 100 judges whether the preview button 505 has been pressed. If it is judged that the preview button 505 has been pressed, the process proceeds to S424, and if not, the process proceeds to S425. In S424, the developer terminal 100 performs a preview process. In the preview process, the canvas 530 is hidden, and a preview is displayed of the UI screen being edited on the canvas 530, based on the definition information recorded in the memory 102 or the definition information recorded in the development environment 300, so that the UI screen will look the same as if the UI screen were viewed in the constructed application. In the preview, the operation path for operating the UI widget is not displayed. In addition, some operations that are not executed on the UI editor screen (not executed by operations on the canvas 530) are executed in the preview. For example, when a UI widget for screen transition or a link portion is operated, a screen transition or transition to a link destination is executed. In addition, an operation such as moving a selection frame for an item by operating the tab key on the keyboard is also executed. Note that operations such as actions entered by the developer in the action board and reference to a database are not executed. As a result, the preview process can be displayed faster than if you were to actually deploy and check the results.

[0113] In S425, the developer terminal 100 judges whether the deploy button 506 has been pressed. If the deploy button 506 has been pressed, the process proceeds to S426. If not, the process proceeds to S427. In S426, the developer terminal 100 transmits a deploy request to the development environment 300 to instruct execution of the deploy process. When the deploy button 506 is pressed to perform the deploy process, the developer does not need to select the execution environment to which the application is to be deployed, and the deployment is performed to the selected execution environment that has been selected in advance and is displayed in the selected execution environment box 501. In many cases, the developer works to update the contents to be deployed to one specific execution environment at once. Therefore, in this system, the execution environment to which the application is to be deployed is selected before the selection of the application to be updated (S311 in FIG. 3), and the execution environment is not selected each time the application is deployed. This prevents operational errors such as accidentally deploying to an unintended execution environment, and makes the work more efficient. Furthermore, although an operation for authentication processing is performed when logging in to the development environment 300, there is no need to perform a separate operation for account authentication processing for the execution environment to be deployed to. This makes it possible to prevent an increase in the amount of work required and to work efficiently. In other words, the developer terminal 100 does not obtain authentication information related to the execution environment to which the user is to be deployed from the developer user.

[0114] In S427, the developer terminal 100 determines whether or not an operation to change the selected execution environment has been performed. Specifically, it determines whether or not an operation to change the selected execution environment has been performed on the selected execution environment box 501. If an operation to change the selected execution environment has been performed, the process proceeds to S428, and if not, the process proceeds to S429. In S428, the developer terminal 100 records information (such as an execution environment ID) that identifies the selected execution environment in the memory 102 as the "selected execution environment" and transmits the information to the development environment 300. In addition, the display content of the selected execution environment box 501 is updated to indicate the changed selected execution environment. When the development environment 300 receives the information that identifies the selected execution environment, the development environment 300 records the selected execution environment in a file for setting management that is saved in an area for the logged-in developer in the storage 320, based on the information.

[0115] In S429, the developer terminal 100 determines whether or not an operation to change the application to be edited has been performed. Specifically, it determines whether or not an operation to change the selected application has been performed on the selected application box 502. If an operation to change the selected application has been performed, the process proceeds to S317 in FIG. 3, and the process from S317 onward is executed based on the changed selected application. That is, the display contents of the submenu area 520 and the canvas 530 are updated. If an operation to change the selected application has not been performed, the process proceeds to S430.

[0116] In S430, the developer terminal 100 determines whether or not an operation to change the UI screen to be edited has been performed. Specifically, it determines whether or not an operation to change the selected UI screen has been performed on the selected UI screen box 503. If an operation to change the selected UI screen has been performed, the process proceeds to S404, and processing is performed based on the changed selected UI screen. That is, the display content of the canvas 530 is updated (switched) to the content of the changed selected UI screen. If no operation to change the selected UI screen has been performed, the process proceeds to S431.

[0117] In S431, the developer terminal 100 determines whether or not an operation has been performed to select any of the options displayed in the main menu area 510. If an option displayed in the main menu area 510 has been selected, the UI editor process ends and proceeds to the screen switching process described later with reference to Fig. 12. If not, the process returns to S406.

[0118] <Context menu processing> 7 shows a flowchart of the context menu process, which is a detailed flowchart of S420 in FIG.

[0119] In S701, the developer terminal 100 determines whether the context menu to be displayed is related to a UI widget of type Button. More specifically, it determines whether the type of the UI widget (designated UI widget) designated with the mouse when the right click was accepted in S419 is a button. If it is a button, the process proceeds to S710, and if not, the process proceeds to S702.

[0120] In S702, the developer terminal 100 determines whether the context menu to be displayed is related to the canvas. More specifically, it determines whether the position designated by the mouse when the right-click was accepted in S419 was a blank area of ​​the canvas 530 where no UI widget was placed. If it is a blank area (if the context menu to be displayed is related to the canvas), the process proceeds to S703, and if not, the process proceeds to S704.

[0121] In S703, the developer terminal 100 performs a context menu process for the canvas.

[0122] In S704, the developer terminal 100 determines whether the context menu to be displayed is related to a UI widget of type data grid (table). More specifically, it determines whether the type of the UI widget (specified UI widget) designated with the mouse when the right-click was accepted in S419 is a data grid. If it is a data grid, the process proceeds to S705, and if not, the process proceeds to S706.

[0123] In S705, the developer terminal 100 processes the context menu of the data grid.

[0124] In S706, the developer terminal 100 displays a context menu related to the specified target corresponding to the specified position as other processing, and performs processing according to the operation. Details will be omitted.

[0125] In S710, the developer terminal 100 determines whether or not the UI screen to be edited (selected UI screen) is a template screen. If it is a template screen, the process proceeds to S721, and if not, the process proceeds to S711.

[0126] In S711, the developer terminal 100 displays the button context menu shown in FIG. 5(d) as a context menu related to the specified UI widget, superimposed near the specified position (mouse cursor position).

[0127] In S712, the developer terminal 100 determines whether or not the property (the property 541 in FIG. 5(d)) is selected from among the options included in the context menu. If the property is selected, the process proceeds to S713, and if not, the process proceeds to S714.

[0128] In S713, the developer terminal 100 displays a property box for the button superimposed on the canvas 530 as a property box (detailed setting dialog) for the specified UI widget. Then, various setting operations for the property box are accepted. Here, for example, detailed settings can be made such as the button name (label) to be displayed for the button that is the specified UI widget, the button color, and a size specified by a numerical value. When the settings are made and an operation is performed to reflect them, the specified UI widget is displayed on the canvas 530 in a display form that reflects the settings.

[0129] In S714, the developer terminal 100 determines whether or not an action (property 542 in FIG. 5(d)) is selected from among the options included in the context menu. If an action is selected, the process proceeds to S715, and if not, the process proceeds to S716.

[0130] In S715, the developer terminal 100 performs action board processing for the button, which is the specified UI widget. The action board processing will be described later with reference to FIG.

[0131] In S716, the developer terminal 100 determines whether or not "Delete" (Delete 543 in FIG. 5(d)) has been selected from among the options included in the context menu. If "Delete" has been selected, the process proceeds to S717, and if not, the process proceeds to S718.

[0132] In S717, the developer terminal 100 erases the specified UI widget, and erases information about the specified UI widget (definitions such as position and size, properties and actions, etc.) from the definition information recorded in the memory 102. As a result, the specified UI widget is erased (deleted) and hidden from the canvas 530.

[0133] In S718, the developer terminal 100 determines whether or not another option has been selected from among the options included in the context menu. If another option has been selected, the process proceeds to S719, where processing according to the selected option is performed. If not, the process proceeds to S720.

[0134] In S720, the developer terminal 100 determines whether or not an operation to close the context menu has been performed (for example, an operation of clicking outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden and the process of Fig. 7 ends. If no operation to close the context menu has been performed, the process returns to S712.

[0135] On the other hand, in S721, the developer terminal 100 displays a context menu for the template screen and for the button as a context menu for the specified UI widget, superimposed near the specified position (mouse cursor position). Unlike the context menu for a normal UI screen (context menu 540 shown in FIG. 5(d)), the context menu for the template screen does not display options such as action or delete, but only properties. In other words, for UI widgets placed on the template screen among the UI screens, the developer is not allowed to set the action to be taken when the UI widget is operated.

[0136] In S722, the developer terminal 100 determines whether or not the property has been selected from among the options included in the context menu. If the property has been selected, the process proceeds to S723, and if not, the process proceeds to S724. The process of S723 is the same as that of S713.

[0137] In S724, the developer terminal 100 determines whether or not an operation to close the context menu has been performed (for example, an operation of clicking outside the area where the context menu is displayed). If an operation to close the context menu has been performed, the context menu is hidden and the processing of Fig. 7 ends. If no operation to close the context menu has been performed, the process returns to S722.

[0138] <Action Board Processing> The process related to the action board will be described. When a UI widget arranged on the canvas is specified and an action is selected from the context menu, an action board for setting an action related to the specified UI widget is displayed. For example, consider a case where a UI screen as shown in FIG. 9(a) is being edited. FIG. 9(a) is a diagram showing a part of the UI editor screen on the display 105. In FIG. 9(a), a list of UI widgets is displayed in the submenu area 520, and the UI screen to be edited is displayed on the canvas 900. On the canvas 900, a UI widget 901 which is a button and other UI widgets are arranged. When the UI widget 901 is specified and an action option is selected from the context menu, an action board as shown in FIG. 9(b) is displayed.

[0139] FIG. 9B is an example of the display of an action board related to a UI widget 901. The action board 910 is displayed in place of the canvas in the area where the canvas 900 was displayed. If the designated UI widget is not a template widget (template component) arranged in advance on the template screen, and if the developer has not set an action for the designated UI widget in the past, the action board 910 is displayed blank as shown in FIG. 9B. Note that the "1" displayed on the action board 910 is a guide display indicating the number of lines, and is not the content of the action. The developer can set any action on this action board 910 by operating the keyboard included in the operation unit 106 and inputting any character string in JavaScript, which is a programming language. The trigger for executing the content set on the action board is predetermined, and is the operation of the designated UI widget. Therefore, the developer does not need to set what the trigger for executing the action is (it is not necessary to write it in JavaScript). For example, if the designated UI widget is a button, the trigger is the pressing of the button in the constructed application, and the action set on the action board of the button is executed in response to the occurrence of the trigger.

[0140] In addition to the action board 910, a function list 920 is displayed in the submenu area instead of the UI widget list or UI screen list as shown in FIG. 9(a) displayed on the UI editor screen. The function list 920 displays an option 922 for instructing the display of the action board 910 and function options for instructing the display of each function. Note that a function that is not a pre-prepared function but is created (added) by a developer (user) by pressing a function add button 921 (described later) is referred to as a created function (created function, added function, self-created function). If there is no automatically created function or pre-prepared function and the developer has not created a created function for the specified UI widget in the past, the function list 920 does not display function options, but displays only the option 922 and the function add button 921, as shown in FIG. 9(b).

[0141] When the Add Function button 921 is pressed, a dialog box for adding a created function (referred to as the Add dialog 930) is displayed. An example of the display of the Add dialog 930 is shown in Fig. 9(c). The Add dialog 930 displays a type selection field 931 for receiving a selection of a function type (Function Type), a function name input field 932 for receiving an input of a function name (Function Name), and a SAVE button 933. When input is made to the Add dialog and the SAVE button 933 is pressed, a setting screen for a function according to the type selected in the type selection field 931 is displayed, and the function name entered in the function name input field 932 is additionally displayed in the function list 920.

[0142] FIG. 9(d) is a display example of a REST function setting screen that is displayed when REST is selected in the type selection field 931. Instead of the action board 910, a REST function setting screen 940 for receiving various settings required to create a function (REST function) using REST (REpresentational State Transfer) is displayed. In addition, in the function list 920, a function 923 with the function name "rest01" input in the function name input field 932 is displayed as a function option. Note that the icon displayed in front of "rest01" indicates that the type of the function 923 is a REST function. If all the required setting items are not set on the function setting screen (if information to be set is insufficient), an incomplete mark 929 indicating that the function is incomplete is displayed, and the corresponding function 923 is displayed in an identifiable incomplete state.

[0143] The REST function setting screen 940 in FIG. 9(d) displays setting fields 941 to 944. The setting field 941 is a setting screen for setting the function name, and in the initial state, the function name entered in the function name input field 932 is displayed, but can be changed according to an input operation by the developer. The setting field 942 is a setting field for setting a variable name for setting arguments. In this embodiment, param is set by default and cannot be changed. It is displayed grayed out to indicate that it cannot be changed. The setting field 943 is a setting field for setting the type of the REST function. By operating the triangular icon on the right end of this area, GET, POST, PUT, and DELETE are displayed as options in a pull-down menu, and one of the options can be selected and set. The type set here is the type of request made by this function. The setting field 944 is a setting field for the URL to which the request made by this function is sent. In this way, when creating a REST function on the REST function setting screen 940, the developer does not need to write a character string of the source code in a programming language.

[0144] 10(a) to (d) further show examples of the creation function setting screen and the action board display. In Fig. 10, the same reference numerals as in Fig. 9 are used for the same elements, and the description thereof will be omitted.

[0145] FIG. 10(a) is a display example of an SQL function setting screen that is displayed when SQL is selected in the type selection field 931. Instead of the action board 910, an SQL function setting screen 950 is displayed for accepting various settings required to create a function (SQL function) using SQL (Structured Query Language). In addition, in the function list 920, a function 924 with a function name "sql01" input in the function name input field 932 is displayed together with an incomplete mark 929 as a function option. Note that an icon displayed in front of "sql01" indicates that the type of the function 924 is an SQL function. The setting field 951 is a setting screen for setting the function name, and in the initial state, the function name input in the function name input field 932 is displayed, but it can be changed according to an input operation by the developer. The setting field 952 is a setting field for setting a variable name for setting arguments. In this embodiment, param is set by default and cannot be changed. It is displayed in gray to indicate that it cannot be changed. The setting field 953 is an input field for inputting a character string (SQL sentence, SQL statement) for issuing an instruction to a database in SQL (a database language, not a programming language), which is a type of computer language. A developer can input any SQL STATEMENT into the setting field 953 using a keyboard or the like included in the operation unit 106. In this way, when creating an SQL function on the SQL function setting screen 950, the developer does not need to write a character string of source code in a programming language.

[0146] FIG. 10B shows an example of a display at the stage where the developer has created functions 923 to 925, input (describe) a certain amount of code (character string) in JavaScript into the action board 910, and then inputs "sq". In this embodiment, when the developer user inputs a character string, if the input character string matches the function name (identification information) of an already created created function, the code assist field 911 displays the function name that matches the character string as an input candidate option. In the illustrated example, the input "sq" matches the function name "sql01" of the function 924, which is an already created created function, so "sql01" is displayed as an option. When the user performs an operation to select "sql01" displayed in the code assist field 911, "sql01" is input into the action board 910 as shown in FIG. 10C, even if the user does not perform an operation to input "l01". This code assist function allows a developer (user) to input the function name (identification information) of a created function without typing all the characters of the function name of the created function on the keyboard, which contributes to reducing the number of operations. If the function name matches the beginning of the function name of a created function that has already been created, the full name is displayed in the code assist field 911, and if there is no match (i.e., if there is no function starting with that character string), the code assist field 911 is not displayed. Therefore, the developer can input the function name of the created function that he or she has already created after confirming that it is correct, and can prevent inputting a mistake in the function name. Note that if there are multiple created functions that match the beginning of the function name, multiple options are displayed in the code assist field 911. Furthermore, the function names of the created functions displayed in the code assist field 911 are functions created for the specified UI widget (UI widget 901 in the illustrated example) that is the target of the action board 910, and created functions created for other UI widgets are not displayed. Therefore, it is possible to prevent a mistake of writing a function name of a created function created for another UI widget, which does not exist as a created function for the specified UI widget, in the action board 910.

[0147] As shown in FIG. 10C, the function list 920 displays the type of function (icon before the character string) and the name of the function for each of the functions 923 to 925 of the created functions created by the developer together with the action board 910. Therefore, the developer user can check what type and name of the created function has been created while inputting (writing) the action code (character string in JavaScript) in the action board 910. This can reduce the effort of checking and managing valid created functions that can be written in the action board 910 (e.g., the effort of making a note of it at hand, opening another screen to check, etc.). This also contributes to preventing input errors in function names. The functions displayed in the function list 920 are functions created for the specified UI widget (UI widget 901 in the illustrated example) that is the target of the action board 910, and created functions created for other UI widgets are not displayed. Therefore, it can prevent the mistake of writing in the action board 910 the function name of a created function created for another UI widget but not existing as a created function for the specified UI widget. In addition, the creation function is effective only when the action of the specified UI widget is defined, and does not affect the definition of the action of other UI widgets. Therefore, if the function name of the creation function created for the specified UI widget is the same as the creation function created for other UI widgets, even if the function name is described in the action board 910, only the function setting set for the specified UI widget is reflected, and the function setting set for the other UI widget is not reflected. Therefore, even if the same function name as the function name of the creation function already created for the other UI widget is used, an error does not occur. Therefore, the user can decide the function name of the creation function and input it to the action board 910 without worrying about the duplication of the function name with the creation function already created for the other UI widget. That is, although a large number of creation functions are created in the entire development of an application, they are automatically managed and organized in association with the specified UI widget and displayed in the code assist field 911 and the function list 920, so that it is very easy for the developer to manage a large number of creation functions. Therefore, the effort and time required for checking the function name can be reduced.It also reduces input errors in function names. This reduces the amount of debugging work (debug removal work) required when a function name is input incorrectly. This reduces the workload and man-hours required for software (application) development, allowing for more efficient software (application) development.

[0148] FIG. 10(d) is a display example when the action code has been input in a programming language into the action board 910. In the illustrated example, the created function "rest01" (function 923 in the function list 920) is used in the portion indicated by the dotted line 960 on the third line. The details of the created function rest01 are not defined in the character string of the code illustrated in the action board 910 of FIG. 10(d). Also, when the developer sets rest01 on the REST function setting screen 940, the details of rest01 are not defined in the programming language. When definition information including the action definition in this state is uploaded and saved in the development environment 300, the development environment 300 creates source code in the programming language including the function definition in the programming language from the uploaded definition information as a program for the execution environment in the save process, based on the function setting contents and the character string described in the action board 910. In this way, when the development environment 300 acquires a string containing identification information (function name) of a created function written in a programming language, it performs control to enable the execution of the function (action) indicated by the string containing the function of the created function (action written on the action board) based on the information set on the function setting screen.

[0149] FIG. 11 shows an example of source code in a programming language generated by the development environment 300 based on the character string written on the action board 910 in FIG. 10(d) and the setting contents of rest01 set on the REST function setting screen 940. In the illustrated example, the numbers 1 to 75 written on the left side are illustrated to indicate the number of lines and are not part of the source code. The example in FIG. 11 is a 75-line source code including a detailed definition of rest01 in a programming language. However, the developer himself does not need to enter 75 lines. By setting on the REST function setting screen 940 and writing the character string of the amount (7 lines) shown in the action board 910 in FIG. 10(d), the contents of the source code shown in FIG. 11 can be defined. In other words, efficient development can be performed with low code.

[0150] Fig. 8 shows a flowchart of the action board process. This process is a detailed flowchart of the action board process described above in S715 of Fig. 7, and is a process for controlling the operation to be performed as explained using the display examples in Figs. 9(b)-(d) and 10(a)-(d).

[0151] In S801, the developer terminal 100 displays an action board on the display 105. If no action has been defined for the specified UI widget, a screen including a blank action board 910 as described in Fig. 9(b) is displayed. If an action has already been defined for the specified UI widget, a screen including an action board 910 with a character string for the action entered as described in Fig. 10(d) is displayed.

[0152] In S802, the developer terminal 100 determines whether or not an operation (writing operation) for writing an action has been performed on the action board 910. The operation for writing an action is, for example, a text input operation performed by operating a keyboard included in the operation unit 106 with the action board 910 selected, or by touching a soft keyboard displayed on a touch panel. If an operation for writing an action has been performed, the process proceeds to S803, and if not, the process proceeds to S810.

[0153] In S803, the developer terminal 100 accepts an action input operation by an operation for describing the action, and displays the input characters on the action board 910.

[0154] In S804, the developer terminal 100 determines whether the character string consisting of the characters entered in S803 and the characters entered up to that point matches (i.e., partially matches) the function name of the created function. If they match, the process proceeds to S805, and if not, the process proceeds to S808.

[0155] In S805, the developer terminal 100 displays the function names of the created functions determined to match in S804 as options in the code assist field. This causes the code assist field 911 to be displayed as described in Fig. 10(b). Note that the code assist field 911 may display not only created functions, but also function names that are generally available in programming languages ​​and the like that match the input character string in the beginning.

[0156] In S806, the developer terminal 100 determines whether any of the options displayed in the code assist field has been selected. If any of the options has been selected, the process proceeds to S807, where the function name of the selected option is displayed in the code assist field 911. For example, in response to the selection of an option in the code assist field 911 from the state of FIG. 10(b), "sql01" is entered and displayed, as shown in the fifth line of the action board 910. If none of the options has been selected, the process proceeds to S808.

[0157] In S808, the developer terminal 100 determines whether or not the operation of describing the action is being continued. If the operation of describing the action is being continued, the process proceeds to S803, and if not, the process proceeds to S802.

[0158] In S810, the developer terminal 100 determines whether or not an operation has been performed to instruct adding a function. Specifically, it determines whether or not the Add Function button 921 has been pressed. If the Add Function button 921 has been pressed, the process proceeds to S811, and if not, the process proceeds to S820.

[0159] In S811, the developer terminal 100 displays the addition dialog 930 for adding a created function, and accepts input to the addition dialog 930. The contents of the input accepted in the addition dialog are as described above with reference to Fig. 9(c). When the input is made to the addition dialog and the SAVE button 933 is pressed, the process proceeds to S812.

[0160] In S812, the developer terminal 100 displays the function name entered in the function name input field 932 of the addition dialog in the function list 920 in the submenu area, with an incomplete mark 929 added.

[0161] In S813, the developer terminal 100 determines whether or not the type selected in the type selection field 931 of the addition dialog is a script. If it is a script, the process proceeds to S814, and if not, the process proceeds to S815. In S814, the developer terminal 100 displays a script function setting screen (not shown) and accepts setting operations from the developer user.

[0162] In S815, the developer terminal 100 determines whether or not the type selected in the type selection field 931 of the addition dialog is SQL. If it is SQL, the process proceeds to S816, and if it is not (i.e., the type selected in the type selection field 931 of the addition dialog is REST), the process proceeds to S817. In S816, the developer terminal 100 displays an SQL function setting screen and accepts setting operations from the developer user. The setting contents accepted on the SQL function setting screen are as described above with reference to FIG. 10(a).

[0163] In S817, the developer terminal 100 displays a REST function setting screen and accepts setting operations from the developer user. The setting contents accepted on the REST function setting screen are as described above with reference to FIG. 9(d).

[0164] In S818, the developer terminal 100 determines whether input to the setting items that are predetermined as required items has been completed (whether the setting has been completed) on the function setting screen of each type. If input to the required items has been completed, the process proceeds to S819, and if not, the process proceeds to S802.

[0165] In S819, the developer terminal 100 hides the incomplete mark that was displayed in association with the function name displayed in the function list 920 for the created function being set. This allows the user (developer) to recognize that the created function being set is in a valid setting state that can be used on the action board 910.

[0166] In S820, the developer terminal 100 determines whether or not any of the created functions displayed in the function list 920 has been selected (pressed). If a created function has been selected in the function list 920, the process proceeds to S813, and in S814, S816, or S817, a setting screen according to the type of the selected created function is displayed, reflecting the contents that have already been set. The user (developer) can change the settings on the setting screen or add additional settings (i.e., edit the created function).

[0167] In S821, the developer terminal 100 determines whether or not a save instruction operation has been performed (for example, pressing the Save button 915). If a save instruction operation has been performed, the process proceeds to S822, and if not, the process proceeds to S823.

[0168] In S 822 , the developer terminal 100 records the contents performed in the action board processing up to now in the definition information held in the memory 102 , and transmits this to the development environment 300 .

[0169] In S823, the developer terminal 100 determines whether or not option 922, which is displayed in the function list 920 and instructs the display of the action board 910, has been pressed. If option 922 has been pressed, the process proceeds to S801, and the action board of the specified UI widget is displayed. As a result, if the function setting screen was displayed, it switches to displaying the action board. If option 922 has not been pressed, the process proceeds to S824.

[0170] In S824, the developer terminal 100 determines whether or not an operation to close the action board (an operation to end the action board processing) has been performed. If an operation to close the action board has not been performed, the process proceeds to S802 and the process is repeated. If an operation to close the action board has been performed, the action board is hidden, the display is switched to the canvas of the selected UI screen, and the process returns to the UI editor processing.

[0171] <Screen switching process> A flowchart of the screen switching process is shown in Fig. 12. This process corresponds to the selection of an option displayed in the main menu area 510 described above in the display example of Fig. 5(b).

[0172] In S1201, the developer terminal 100 determines whether or not the application list button 511 has been pressed. If the application list button 511 has been pressed, the process proceeds to S315 in Fig. 3, and if not, the process proceeds to S1202.

[0173] In S1202, the developer terminal 100 determines whether or not the UI screen button 512 has been pressed. If the UI screen button 512 has been pressed, the process proceeds to S1203, and if not, the process proceeds to S1204. In S1203, the UI editor process of FIG. 4 is performed.

[0174] In S1204, the developer terminal 100 determines whether or not the workflow button 513 has been pressed. If it is determined that the workflow button 513 has been pressed, the process proceeds to S1205, and if not, the process proceeds to S1206.

[0175] In S1205, the developer terminal 100 performs a workflow creation process.

[0176] In S1206, the developer terminal 100 determines whether or not the setting button 514 has been pressed. If the setting button 514 has been pressed, the process proceeds to S1207, and if not, the process proceeds to S1209.

[0177] In S1207, the developer terminal 100 displays an application setting screen. The application setting screen is a screen that accepts a setting operation related to a selected application. In S1208, the developer terminal 100 accepts a setting operation on the application setting screen, and updates the definition information recorded in the memory 102 based on the setting. Settings that can be accepted in S1208 include, for example, a display language setting and a setting of whether to build an application that can be used as a PWA (Progressive Web Apps). In addition, there is a setting of which UI screen among multiple UI screens belonging to the application is to be the initial UI. The initial UI is a screen that is displayed first when an already-built application deployed in the execution environment is accessed, or a screen that is displayed first after authentication is OK on the authentication screen of the application after accessing the already-built application.

[0178] In S1209, the developer terminal 100 determines whether or not the Environment List button 515 has been pressed. If the Environment List button 515 has been pressed, the process proceeds to S311 in Fig. 3, and if not, the process proceeds to S1210.

[0179] In S1210, the developer terminal 100 determines whether or not the Database button 516 has been pressed. If the Database button 516 has been pressed, the process proceeds to S1211, and if not, the process proceeds to S1215. Pressing the Database button 516 is a request to connect to the database.

[0180] In S1211, the developer terminal 100 determines whether or not the selected execution environment is the multi-tenant execution environment 410. If it is the multi-tenant execution environment 410, the process proceeds to S1213, and if it is not (if it is the single-tenant execution environment), the process proceeds to S1212.

[0181] In S1212, the developer terminal 100 acquires database information acquired by the development environment 300 from the selected execution environment. More specifically, the development environment 300 determines whether the selected execution environment is a multi-tenant execution environment or a single-tenant execution environment, and if it is a single-tenant execution environment, the development environment 300 accesses the DB set (any of DB sets 457, 467, 477, etc.) of the single-tenant execution environment that is the selected execution environment, and acquires the contents recorded in the database. Then, the development environment 300 transmits the database information acquired from the selected execution environment to the developer terminal 100. The developer terminal 100 does not access the single-tenant execution environment without going through the development environment 300.

[0182] In S1213, the developer terminal 100 references the DB instance name recorded in the developer information of the logged-in developer (information registered for the logged-in developer out of the developer information 301). Then, the development environment 300 acquires the contents recorded in the database of the DB instance indicated by the DB instance name obtained by referencing the developer information of the logged-in developer from among the DB sets 430 included in the multitenant execution environment 410, which is the currently selected execution environment. Then, the development environment 300 transmits the database information acquired from the currently selected execution environment to the developer terminal 100. The developer terminal 100 will not access the multitenant execution environment 410 without going through the development environment 300.

[0183] In S1214, the developer terminal 100 displays a database management screen, and displays the database information acquired in S1212 or S1213. Then, various settings related to the database of the selected execution environment and DB management operations for instructing content updates are accepted.

[0184] In S1215, the developer terminal 100 determines whether or not the file manager button 517 has been pressed. If the file manager button 517 has been pressed, the process proceeds to S1216, and if not, the process proceeds to S1218.

[0185] In S1216, the developer terminal 100 displays a file management screen for managing files to be saved in the selected execution environment, and in S1217, accepts an operation for managing files to be saved in the selected execution environment. For example, an image file to be displayed on the screen of the application to be constructed can be uploaded and saved in the developer area of ​​the selected execution environment. When a file to be saved in the selected execution environment is selected from the local storage area (such as the recording medium 108) of the developer terminal 100 and an instruction to save is given, the developer terminal 100 transmits the selected file to the development environment 300. When the development environment 300 receives the selected file, it transmits it to the developer area of ​​the selected execution environment to save it in the selected execution environment. The various execution environments only accept access from the development environment 300. Therefore, for file management, the developer terminal 100 accesses the various execution environments via the development environment 300. The developer terminal 100 does not access the multi-tenant execution environment 410 without going through the development environment 300. As explained in the login process above, a developer must be authenticated before logging in to the development environment 300. Therefore, by restricting access to various execution environments except via the development environment 300, other users who cannot log in to the development environment 300 cannot illegally access the execution environment, thereby improving security.

[0186] Furthermore, the developer user only needs to perform operations related to authentication to log in to the development environment 300, and does not need to perform operations related to authentication to log in to each execution environment. This makes it possible to prevent an increase in the number of operations.

[0187] In S1218, the developer terminal 100 determines whether or not the user management button 518 has been pressed. If it is determined that the user management button 518 has been pressed, the process proceeds to S1219, and if not, the process proceeds to S1220.

[0188] In S1219, the developer terminal 100 performs a user information display process. The user information display process is a process for displaying user information (such as user information 411, 451, 461, 471 in each execution environment shown in FIG. 1) that is information on application users (information managed separately from the developer) who can log in to an application built in the selected execution environment, and accepting management operations from the developer.

[0189] In S1220, the developer terminal 100 determines whether or not the snapshot button 519 has been pressed. If the snapshot button 519 has been pressed, the process proceeds to S1221 where snap processing is performed, and if not, the process proceeds to S1222.

[0190] In S1222, the developer terminal 100 determines whether or not an end operation has been performed. If an end operation has not been performed, the process proceeds to S1201 and the process is repeated, and if an end operation has been performed, the screen switching process ends. <Tutorial Processing> FIG. 13 shows a flowchart of the tutorial process executed by the developer terminal 100. This process is a detailed view of the process of S351 in FIG. 3. FIG. 14(a) shows an example of a list of applications (app list) displayed on the display 105 by the process of S315. In the app list, two options 1403 and 1404 are displayed as app options. In the header menu area, a tutorial button 1401 and an app creation button 1402 are displayed. When the tutorial button 1401 is pressed, the tutorial process in FIG. 13 is started. Note that the display destination of the various display processes in the tutorial process in FIG. 13 is the display 105 of the developer terminal 100. Also, the various display examples are examples of a portion of the display 105, not the entirety of the display 105.

[0191] In S1301, the developer terminal 100 displays a lesson list. FIG. 14(b) shows an example of the display of the lesson list 1410. The tutorial includes multiple lessons. Each lesson includes multiple chapters, and each chapter includes multiple steps (procedures). In the example of FIG. 14(b), five lessons, Lessons 1 to 5, are displayed in the lesson list 1410. When the down arrow on the right side of any of the displayed lessons is displayed, the multiple chapters included in the corresponding lesson are expanded and displayed. FIG. 14(c) shows an example of the display when the multiple chapters included in Lesson 1 are expanded and displayed. In this state, Lesson 1 is selected, and the four chapters included in Lesson 1 are displayed in an area 1411. The chapters that the developer has already done and the chapters that the developer has not started are displayed in different colors so that they can be distinguished. When the start button 1412 is pressed with any of the lessons selected, the tutorial for the selected Lesson is started.

[0192] In S1302, the developer terminal 100 determines whether or not any lesson has been selected from the lesson list 1410 and a command to start has been issued (start button 1412 has been pressed). If a lesson has been selected and a command to start has been issued, the process proceeds to S1304, and if not, the process proceeds to S1303.

[0193] In S1303, the developer terminal 100 determines whether or not an operation to hide the lesson list 1410 (an operation to end the tutorial process) has been performed. If there has been no operation to end the tutorial process, the process proceeds to S1302, and if there has been an operation to end the tutorial process in FIG.

[0194] In S1304, the developer terminal 100 sets the lesson number variable L, which indicates the lesson to be processed of the tutorial held in the memory 102, to the number corresponding to the selected lesson.

[0195] In S1305, the developer terminal 100 initializes a variable C, which is a chapter number indicating the chapter to be processed in the tutorial stored in memory 102, to 1. Note that it may be possible to select a specific chapter from a list of chapters such as that shown in area 1411 in Fig. 14(c) and start the tutorial from that chapter. In that case, in S1305, the variable C is set to the number corresponding to the selected chapter.

[0196] In S1306, the developer terminal 100 initializes to 1 a variable S which is a step number indicating a step (procedure) of the tutorial held in the memory 102 that is the processing target.

[0197] In S1307, the developer terminal 100 judges whether the contents of the tutorial to be displayed in the currently processed step indicated by the variables L, C, and S include a character string to be copied. The contents of the tutorial to be displayed in each step for each tutorial for each lesson are indicated by the client program 322 (client information) received from the development environment 300 in S302 and recorded in the memory 102. That is, the judgment in S1306 is made by referring to the client program 322 (client information) recorded in the memory 102. If the step to be processed is a step that includes a character string to be copied, the process proceeds to S1320, and if not, the process proceeds to S1308. If the character string to be input, which is information to be input in the input target item, is a step (step) that requires more than a predetermined number of characters, the process proceeds to S1330, and if the character string to be input, which is information to be input in the input target item, is a step (step) that requires less than a predetermined number of characters, the process proceeds to S1308.

[0198] In S1308, the developer terminal 100 displays a guide in the tutorial for the step to be processed. FIG. 14(d) shows an example of the guide display in the tutorial. FIG. 14(d) is an example of the guide display for step 1 of chapter 1 of lesson 1. In order to emphasize the application creation button 1402, which is the operation target item, other parts are grayed out, and a speech bubble 1420 (guide display area) indicating (pointing, identifying) the operation target item in the target step of the tutorial is displayed in a superimposed manner. In the speech bubble 1420, a chapter guide 1421 indicating the current chapter, a guide message 1422 for the current step, and an end button 1423 are displayed. In the example of FIG. 14(d), "Click the [Application Creation] button" is displayed as the guide message 1422. Note that the operation target item differs depending on the step, and may be a button or an input item (an input target item such as a text box).

[0199] In S1310, the developer terminal 100 determines whether the operation target item is an input item and whether an input operation has been performed on that input item (input target item). Note that an input item that is an operation target item in a processing target step in the tutorial is referred to as an input target item. If the operation target item is other than an input item such as a button, or if the operation target item is an input item but no input operation has been performed, the process proceeds to S1312. If the operation target item is an input item and an input operation has been performed on that input item (input target item) (for example, a character input operation of operating a keyboard included in the operation unit 106 with the input item selected), the process proceeds to S1311.

[0200] FIG. 15(a) shows an example of a guide display in a tutorial when the operation target item is an input item. FIG. 15(a) is an example of a guide display for a step included in chapter 1 of lesson 1. To emphasize an input target item 1501, other parts are grayed out, and a balloon 1520 (guide display area) pointing to the input target item is superimposed. The input target item 1501 is a text box for receiving the setting of the ID of a newly created application (input of a character string to be the ID) from a developer (user). The balloon 1520 displays a guide message 1522 for the current step, an end button 1523, and a next button 1524. In the example of FIG. 15(a), the guide message 1522 reads, "Enter [ID]. After entering, click the [Next] button." In other words, guidance on the content to be entered in the input target item 1501 is displayed. In FIG. 15(a), a copy button is not displayed.

[0201] In S1311, the developer terminal 100 inputs a character string in accordance with the input operation from the user received in S1310 into the input target item. As a result, for example, as shown in Fig. 15(b), the character string "app01" is displayed in the input target item 1501. Fig. 15(b) is the same display example as Fig. 15(a) except that a character string has been input into the input target item 1501.

[0202] In S1312, the developer terminal 100 determines whether or not the Next button has been pressed or an operation has been performed on an item to be operated. If the Next button has been pressed or an operation has been performed on an item to be operated, the process proceeds to S1340, and if not, the process proceeds to S1313. For example, in the state of FIG. 14(d), if the application creation button 140 has been pressed, the process proceeds to S1340. Also, for example, in the state of FIG. 15(a) or FIG. 15(b), if the Next button 1524 has been pressed, the process proceeds to S1340.

[0203] In S1313, the developer terminal 100 judges whether or not a skip button (for example, skip button 1610 in FIG. 16) has been pressed. The skip button is a display item (operation icon) and is also referred to as a skip item. If the skip button has been pressed, the process proceeds to S1314, and if not, the process proceeds to S1316. The skip button is displayed at a fixed position (a predetermined position on the screen, the same position) that does not change on the screen even if the step proceeds, regardless of the display position of the operation target item (i.e., a position that does not relate to the position of the speech bubble that displays the guide). In this way, after hovering the mouse over the skip button once, it is possible to continuously skip operations on operation target items in multiple steps included in the tutorial while keeping the mouse position fixed. Therefore, when you do not want to go through the tutorial carefully but want to check it quickly and easily, you can efficiently check the contents of multiple steps of the tutorial.

[0204] In S1314, the developer terminal 100 inputs a predetermined value (various predetermined information) to the input target item. The predetermined value is a value (information) recorded for each step in the client program 322 (client information) recorded in the memory 102, and is a value (information) that allows the user to proceed to the next or subsequent step of the tutorial without error. For example, if the skip button is pressed in the state of FIG. 15(a), a value appropriate as the ID of the newly created application (for example, the character string "app_tutorial") is automatically input to the input target item. That is, even if no input is made to the input target item according to the user's operation in S1310 and S1311, appropriate information (value) is automatically input when the skip button (skip item) is operated. Note that if the operation target item is not an input item, the operation target item is automatically operated (pressed if it is a button) in S1314, and the process proceeds to S1340 without passing through S1315.

[0205] In S1315, the developer terminal 100 judges whether a predetermined time (e.g., 2 seconds) has elapsed while displaying the predetermined value automatically input into the input target item. If the predetermined time has elapsed, the process proceeds to S1340, and if not, the process waits for the predetermined time to elapse in S1315. In this way, the appropriate value automatically input into the input target item is displayed for a predetermined time. Therefore, even if a developer user presses the skip button because he or she does not know what value to input into the input target item, he or she can confirm what value was appropriate to input. In this way, the developer user can more conveniently learn how to use and operate the system.

[0206] In S1316, the developer terminal 100 determines whether or not an operation to instruct the end of the tutorial has been performed (for example, pressing the End button 1423). If an operation to instruct the end has been performed, the process of FIG. 13 ends, and if not, the process proceeds to S1310 and is repeated.

[0207] In S1340, the developer terminal 100 determines whether or not an error has occurred. If an error has occurred, the process proceeds to S1341, and if not, the process proceeds to S1342.

[0208] In S1321, the developer terminal 100 returns to the step where the error occurred and displays a warning. For example, if the Next button 1524 is pressed while the input target item 1501 is left blank in the state shown in FIG. 15(a), and then the Confirm App Creation button, which is the operation target item, is pressed in a subsequent step of the tutorial, the ID of the newly created app will no longer exist, and this is determined to be an error. In this case, the process returns to the step where the display in FIG. 15(a) is performed (the variable S is set to the return destination step number), the input target item 1501 that caused the error is highlighted (for example, displayed in a red frame), and the process proceeds to S1307 to perform the process of the step where the display in FIG. 15(a) is performed again.

[0209] In S1322, the developer terminal 100 determines whether the variable S is Smax (the number of the last step of the chapter to be processed). If the variable S is Smax, the process proceeds to S1324, and if not, the process proceeds to S1323.

[0210] In S1323, the developer terminal 100 increments the value of the variable S by one. That is, it sets it to the number of the next step. Then, the process proceeds to S1307, and processing related to the next step in the tutorial is performed. For example, in S1308, in a state where a guide display of step 1 of chapter 1 of lesson 1 in FIG. 14(d) is displayed, if the application creation button 1402, which is the operation target item, is pressed, S1302 is determined as Yes, and the process proceeds to S1320 No and S1322 No, and the process sets the next step of the same chapter 1 in S1323, and then proceeds to S1307 No and S1308. In S1308, a guide display of step 2 of chapter 1 is performed as shown in FIG. 14(e).

[0211] In S1324, it is determined whether the variable C is Cmax (the number of the last chapter of the lesson being processed). If the variable C is not Cmax, the process proceeds to S1325. If the variable C is Cmax, the tutorial for that lesson is complete, and the process in FIG. 13 ends. FIG. 15(c) shows an example of a guide display for the tutorial for the last step of the last chapter of Lesson 1. In this state, if the Deploy button, which is the item to be operated, is pressed, S1324 determines Yes, and the process in FIG. 13 ends.

[0212] Control is performed to actually develop an application based on the operations in the tutorial. That is, pressing the Deploy button in FIG. 15(c) is synonymous with pressing the Deploy button included in the confirmation screen displayed after pressing the Deploy button in S425 in FIG. 4 described above. Therefore, when the Deploy button is pressed in FIG. 15(c), the process of S426 is performed, and a deploy request instructing the development environment 300 to deploy to the selected execution environment is sent to the development environment 300. In response to this, the development environment 300 actually deploys to the selected execution environment and builds the application. The definition information of a new application created according to the tutorial is also saved in the development environment 300, and when the application list screen is displayed after completing lesson 1, an option 1530 for the application created in the tutorial is added and displayed as shown in FIG. 15(d).

[0213] In S1325, the developer terminal 100 increments the value of the variable C by 1. That is, it sets it to the number of the next chapter. Then, the process proceeds to S1328, where the variable S is set to 1. That is, it is set to the number of the first step of the next chapter. Then, the process proceeds to S1307, where processing relating to the first step of the next chapter in the tutorial is performed.

[0214] On the other hand, in 1330, the developer terminal 100 displays a guide with a copy button in the tutorial of the step to be processed. FIG. 16(a) shows an example of a guide display with a copy button in the tutorial. To emphasize an input target item 1601, other parts are grayed out, and a speech bubble 1620 (guide display area) that identifies (points to, indicates) the input target item 1601 is superimposed. In the speech bubble 1620, a chapter guide 1621 indicating the current chapter, a guide message 1622 for the current step, an end button 1623, and a next button 1624 are displayed. In addition, a character string to be copied is displayed in a box 1626, and a copy button 1624 (copy item) that is an operation icon (display item) that instructs copying the character string to be copied is displayed. The character string to be copied displayed in the box 1626 is the same as a predetermined value that is automatically input to the input target item 1601 when the skip button 1610 is pressed. In other words, it is a value (information) recorded for each step in the client program 322 (client information) recorded in memory 102, and is an appropriate value (information) that allows the user to proceed to the next or subsequent step of the tutorial without error.

[0215] In S1331, the developer terminal 100 determines whether or not the copy button 1624 has been pressed. If the copy button 1624 has been pressed, the process proceeds to S1332, and if not, the process proceeds to S1333.

[0216] In S1332, the developer terminal 100 copies the character string to be copied (the character string displayed in box 1626) to the clipboard.

[0217] In S1333, the developer terminal 100 determines whether or not a paste operation has been performed on the input target item 1601. If a paste operation has been performed on the input target item 1601, the process proceeds to S1334, and if not, the process proceeds to S1340.

[0218] In S1334, the developer terminal 100 inputs (pastes) the character string copied to the clipboard into the input target item 1601. As a result, if the time is immediately after pressing the copy button 1624, the character string to be copied (the character string displayed in the box 1626) is input into the input target item 1601.

[0219] The processing of S1340 to S1346 is similar to the processing of S1310 to S1316, respectively, and therefore a description thereof will be omitted. Note that in S1341, it is also possible to input an inappropriate value for the input target item (e.g., an incorrect URL) that is different from the character string to be copied. By deliberately accepting the input of an inappropriate value, it is possible to provide the user with the lesson that an error will occur in subsequent processing if an inappropriate input is made.

[0220] Fig. 16(b) shows an example of a display when, from the state of Fig. 16(a), a copy button 1624 is pressed and then an operation of pasting into the input target item 1601 is performed, so that the character string to be copied (the character string displayed in the box 1626) is input into the input target item 1601. In this way, the character string to be input in the tutorial can be easily input. Even if the character string is long, an appropriate character string (the character string to be copied by pressing the copy button 1624) that does not cause an error can be easily input.

[0221] FIG. 16(a) and FIG. 16(b) are tutorials of the setting screen of the REST function described in FIG. 9(d). In this embodiment, the function of the application development software is actually executed based on the contents entered in the input target field. That is, the input target field 1601 is the setting field 944 in FIG. 9(d), which is a setting field for the URL to which the request made by this function is to be sent. If a character string indicating an appropriate URL as a destination to which a request is to be sent is entered in this input target field 1601, a REST function that actually functions correctly can be created through the tutorial. If a character string indicating an inappropriate URL (e.g., a non-existent URL) as a destination to which a request is to be sent is entered in the input target field 1601, the REST function generated in the tutorial will not function correctly, which will cause an error. If the URL character string is manually entered without copying, typing errors are likely to occur, and the character string may become inappropriate. In contrast, as in this embodiment, by displaying a copy button 1624 during the tutorial that allows easy copying of the copy target character string, which is an appropriate character string to which a request is to be sent, simple and reliable input without errors can be performed.

[0222] The copy button, which allows easy copying of the target string, is also very effective in the tutorial on the action board mentioned above. The action board can be used to enter a string representing an action in JavaScript (a programming language). In order to guide the developer user through this in a tutorial and have the developer user actually operate it, the input target item is the action board, and the developer user is required to actually enter the string representing the action in JavaScript into the action board. The string representing the action in JavaScript is long, which is troublesome to enter, and is prone to typos. In addition, it is not easy for the developer user to immediately think of what kind of action to write, and considering what kind of action to write first is too much work for a tutorial. Therefore, if a string representing a suitable action prepared in advance in JavaScript can be copied as the target string with the copy button and pasted into the action board, it is possible to achieve the effect of a tutorial that allows the developer user to understand what the action board is, while greatly reducing the effort and mistakes. The same effect can be obtained by automatically entering and displaying the same string as the target string in the action board by pressing the skip button.

[0223] In this embodiment, an example in which both the skip button and the copy button are displayed in the tutorial has been described, but only one of them may be displayed. In other words, either one of the process of automatically inputting a predetermined value into an input target item by pressing the skip button, or the process of copying an appropriate copy target character string as a value to be input into an input target item by pressing the copy button may be performed.

[0224] Also, even if the copy button is not displayed, it is possible to simply display a character string to be copied that is appropriate as a value (information) to be input to an input target item in a form that can be selected and copied in the guide area of ​​the tutorial. The effect of improving operability in the tutorial can be achieved even if the character string to be copied is copied in response to an operation of selecting the character string to be copied displayed in the guide area and instructing copying, and the copied character string to be copied is input to the input target item in response to a paste operation to the input target item.

[0225] In this manner, in this embodiment, the operability in the tutorial can be further improved.

[0226] The various controls described in each of the above flowcharts may be performed by a single piece of hardware, or the entire device may be controlled by multiple pieces of hardware (e.g., multiple processors or circuits) sharing the processing. In addition, although the present invention has been described in detail based on the preferred embodiments, the present invention is not limited to these specific embodiments, and various forms within the scope of the gist of the present invention are also included in the present invention. Furthermore, each of the above-mentioned embodiments merely shows one embodiment of the present invention, and each embodiment can be appropriately combined.

[0227] (Other embodiments) The present invention can also be realized by executing the following process. That is, software (programs) that realize the functions of the above-mentioned embodiments are supplied to a system or device via a network or various storage media, and the computer (or CPU, MPU, etc.) of the system or device reads and executes the program code. In this case, the program and the storage medium storing the program constitute the present invention. [Explanation of symbols]

[0228] 100: developer terminal, 200: application user terminal, 201: application user terminal 201, 300: development environment, 400: execution environment

Claims

1. Display control means for controlling to display a copy item that indicates an input target item for which a user should input information in a predetermined procedure among a plurality of procedures included in a tutorial, and receives an instruction to copy a copy target, which is information to be input to the input target item; copying the copy target in response to the copy item being operated; control means for controlling to input the copy target to the input target item in response to a paste operation being performed on the input target item; An information processing system characterized by comprising:

2. The display control means controls to display the copy item in the predetermined procedure of the tutorial, and controls to display guidance on the content to be input to the input target item without displaying the copy item in a second procedure that is not the predetermined procedure of the tutorial. The information processing system according to claim 1, characterized in that.

3. The predetermined procedure is a procedure that satisfies a condition based on the number of characters of a character string to be input as information to be input to the input target item in the tutorial. The information processing system according to claim 2, characterized in that.

4. The control means can also control to input information different from the copy target to the input target item in response to a user operation. The information processing system according to claim 1, characterized in that.

5. The control means controls to execute the actual function of the software targeted by the tutorial based on the information input to the input target item. The information processing system according to claim 1, characterized in that.

6. Display control means for indicating an input target item for which a user should input information in a predetermined procedure among a plurality of procedures included in a tutorial, and controlling to display a copy target, which is information to be input to the input target item, in a guide area; copying the copy target in response to an operation of selecting and instructing to copy the copy target; control means for controlling to input the copy target to the input target item in response to a paste operation being performed on the input target item; An information processing system characterized by comprising:

7. Among a plurality of procedures included in the tutorial, display control means for indicating an input target item for which a user should input information in a predetermined procedure, displaying a skip item, and controlling to display guidance on the content to be input to the input target item in a guide area; When there is an input operation from the user for the input target item, controlling to input the content input from the user to the input target item and proceed to the next step in the tutorial; Control means for controlling to input predetermined content to the input target item and proceed to the next step in the tutorial even when there is no input operation from the user for the input target item when the skip item is operated; An information processing system characterized by comprising the above.

8. The control means controls to proceed to the next step after displaying a state in which the predetermined content is input to the input target item when the skip item is operated. The information processing system according to claim 7, characterized by the above.

9. The control means controls to proceed to the next step after displaying a state in which the predetermined content is input to the input target item for a predetermined time when the skip item is operated. The information processing system according to claim 7, characterized by the above.

10. The display control means controls to display the skip item at the same position in a plurality of procedures included in the tutorial. The information processing system according to claim 7, characterized by the above.

11. The display control means controls to display the skip item at a position regardless of the position of the input target item. The information processing system according to claim 7, characterized by the above.

12. The display control means controls to display the skip item at a position regardless of the position of the guide area. The information processing system according to claim 7, characterized by the above.

13. The control means can also control to input information different from the predetermined content to the input target item according to a user operation. The information processing system according to claim 7, characterized by the above.

14. The control means controls to execute the actual function of the software targeted by the tutorial based on the information input to the input target item. The information processing system according to claim 7, characterized by

15. A display control step of controlling to display a copy item that indicates an input target item for which a user should input information in a predetermined procedure among a plurality of procedures included in a tutorial, and receives an instruction to copy a copy target that is information to be input to the input target item; copying the copy target in response to the copy item being operated; A control step of controlling to input the copy target to the input target item in response to a paste operation being performed on the input target item; A control method for an information processing system, characterized by comprising

16. A display control step of controlling to display, among a plurality of procedures included in a tutorial, an input target item for which a user should input information in a predetermined procedure, and to display a copy target that is information to be input to the input target item in a guide area; copying the copy target in response to an operation of selecting the copy target and instructing a copy; A control step of controlling to input the copy target to the input target item in response to a paste operation being performed on the input target item; A control method for an information processing system, characterized by comprising

17. A display control step of controlling to display, among a plurality of procedures included in a tutorial, an input target item for which a user should input information in a predetermined procedure, display a skip item, and display guidance on the content to be input to the input target item in a guide area; when there is an input operation from the user for the input target item, controlling to input the content input by the user to the input target item and proceed to the next step in the tutorial; A control step of controlling to input predetermined content to the input target item and proceed to the next step in the tutorial even when there is no input operation from the user for the input target item when the skip item is operated; A control method for an information processing system, characterized by comprising

18. A program for causing at least one computer to function as each means of the information processing system according to any one of claims 1 to 14.

Images