JP7807668B2 - Information processing system, control method for information processing system, and program - Google Patents

Description

This article relates to information processing systems, control methods for information processing systems, and programs, and in particular to technologies suitable for use in building application software.

Conventionally, application construction tools exist as no-code/low-code development tools that require little or no coding in a programming language and build application software (hereinafter referred to as "applications") according to definitions. Patent Document 1 proposes that screen components such as buttons and text boxes can be placed by drag and drop on a layout editor screen for editing the screen of the web application to be built, and that the placed screen components are stored in an input/output definition table.

Tutorials for learning the functions of application software are also known. Patent Document 2 proposes executing a tutorial selected from multiple tutorials and displaying the progress of the tutorial.

Japanese Patent Application Laid-Open No. 2019-49858 Japanese Patent Application Laid-Open No. 2001-356858

Some software tutorials allow users to actually perform software functions by following the instructions. However, even in tutorials that involve performing actual software functions, if the input is not correct, the software will not function properly. For example, in a tutorial on creating a REST function, if the URL to which the request is sent is not entered correctly, the REST function created in the tutorial will not function properly. However, actually entering strings of characters during tutorial operations is tedious and increases the likelihood of error. Furthermore, while users may not fully master or understand many of the multiple steps (procedures) included in the tutorial, they may want to quickly complete the majority of the content they have already mastered or understood with a simple confirmation. Nevertheless, manually entering correct information during tutorial operations is tedious. Furthermore, users cannot proceed further in the tutorial unless they enter the correct information, and they may struggle to progress if they do not know how to enter the correct information or what the correct information is.

In view of the above issues, the present invention aims to provide a mechanism that further improves operability during tutorials.

The information processing system of the present invention comprises:
a display control means for controlling the display of an input target item into which a user should input information in one of a plurality of steps included in the tutorial, and for displaying a copy item in the 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.

This invention can further improve operability during tutorials.

FIG. 1 is a system configuration diagram of an information processing system. FIG. 2 is a hardware block diagram of a developer terminal 100, an application user terminal 200, and an application user terminal 201. 10 is a flowchart of a login process. 10 is a flowchart of a UI editor process. 10 shows display examples in login processing and UI editor processing. 10 is a display example of tab components and an AppBar in a UI editor process. 10 is a flowchart of a context menu process. 10 is a flowchart of an action board process. 10 is a display example for explaining an action board process. 10 is a display example in action board processing. 10 is an example of source code generated by the development environment 300. 10 is a flowchart of a screen switching process. 10 is a flowchart of a tutorial process. 10 is a display example relating to the tutorial process. 10 is a display example relating to the tutorial process. 10 is a display example relating to the tutorial process.

The following embodiments are described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the claimed invention, and not all combinations of features described in the embodiments are necessarily essential to the invention. Two or more of the features described in the embodiments may be combined in any desired manner. Furthermore, identical or similar components are designated by the same reference numerals, and redundant descriptions will be omitted.

The various features shown in the following embodiments can be combined with each other. Note that, below, "application" and "app" both refer to application software.

<System Configuration>
Fig. 1 shows a system configuration diagram of an information processing system according to an embodiment of the present invention, which includes a system for developing software and a system for using the developed software.

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

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 it. 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).

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

Execution engine 302 is at least one hardware resource for executing processing to be executed in development environment 300, and includes processor 303 and memory 304. Processor 303 consists of at least one processor, and may be a single processor on the cloud, or a processor group combining multiple processors. Memory 304 is at least one recording medium on which programs to be executed by processor 303 are recorded. Of the various flowcharts described below, those described as being executed by development environment 300 are executed by execution engine 302. In other words, the programs recorded in memory 304 are implemented by processor 303 by expanding them into an area of development environment 300 that serves as work memory and executing them.

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

Storage 320 is a storage area of at least one recording medium, and stores at least a 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 developers A, B, and C are able to log in, it includes a developer A area 323 for developer A, a developer B area 324 for developer B, and a developer C area 325 for developer C. Each developer area stores definition information for the apps developed by each developer. For example, developer A area 323 stores app definition 323a (including UI definition information for the app and programs for the app's execution environment).

The developer accesses the development environment 300 by accessing the URL for accessing the development environment 300 from the browser software on the developer terminal 100, and logs in to the development environment. Once logged in to the development environment, the developer receives from the development environment the client program 322 and the app definition (UI definition information) that is the content of previous development work that was saved. The developer then performs an operation to design a new application or an operation to update the design of an existing (in-progress) application, and sends the resulting app definition information (app definition, UI definition information) to the development environment 300. The development environment 300 stores the received app 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 a terminal that can connect to the Internet is available, developers can develop applications regardless of location.

Execution environment 400 is an environment using at least one hardware resource built on a network (on the cloud or the Internet). Execution environment 400 includes a multi-tenant execution environment 410 and multiple single-tenant execution environments (e.g., single-tenant execution environments 450, 460, 470). Execution environment 400 is built by combining multiple web services (cloud services). Execution environment 400 is an environment for deploying application definition information (app definition) developed using developer terminal 100 and development environment 300. Application user terminals 200 and 201 used by users who use the application access execution environment 400 by accessing a URL for executing the application. The execution environment 400 then executes various actions in response to operations performed on application user terminals 200 and 201, thereby executing the developed application and providing the application's functions to the app user. Applications built in execution environment 400 on a network are so-called web applications.

The multi-tenant execution environment 410 is a multi-tenant execution environment shared by multiple developers, and applications developed by multiple developers are deployed to it. In other words, it is an environment shared by multiple developers, and is an environment in which multiple apps by multiple developers can be built. The multi-tenant execution environment 410 includes user information 411, an execution engine 412, a distribution engine 415, storage 420, and a DB set 433.

User information 411 is information that records the account of an app user who can log in to the application, such as an email address (username) that serves as the user account ID for the deployed application (built application), and a password. User information 411 is recorded on at least one recording medium included in the multi-tenant execution environment 410.

The execution engine 412 is at least one hardware resource for executing processing to be executed in the multi-tenant execution environment 410, and includes a processor 413 and memory 414. The processor 413 consists of at least one processor, and may be a single processor on the cloud, or a processor group combining multiple processors. The memory 414 is at least one recording medium on which programs to be executed by the processor 413 are recorded. Of the various flowcharts described below, those described as being executed by the multi-tenant execution environment 410 are executed by the execution engine 412. In other words, this is realized when the processor 413 deploys and executes the programs recorded in the memory 414 in an area of the multi-tenant execution environment 410 that serves as work memory. The programs executed here include programs that execute application actions.

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 the storage 420 included in the execution environment 410.

Storage 420 is a storage area of at least one recording medium, and stores at least a client program 422 that is common to multiple applications. In addition, access destination information 421 for accessing the execution environment (multi-tenant execution environment 410) is recorded in a specified area of storage 420 (specified folder, specified bucket, specified level). It also has developer areas, which are storage areas for each developer account. For example, it includes developer A area 423, which is an area for developer A, developer B area 424, which is an area for developer B, and developer C area 425, which is an area for developer C. Each developer area stores definition information for apps developed by each developer and deployed from development environment 300. For example, developer A area 423 stores app definition 423a.

DB set 430 is a group of information about databases used by applications deployed in execution environment 410. DB set 430 is stored in the storage area of at least one recording medium.

Single-tenant execution environments 1 (450), 2 (460), and 3 (470) are each execution environments dedicated to one developer (one developer account), and applications developed by the owner developer using development environment 300 are deployed therein. In this embodiment, as an example, the owner of single-tenant execution environment 1 (450) is Developer A, the owner of single-tenant execution environment 2 (460) is also Developer A, and the owner of single-tenant execution environment 3 (470) is Developer B. In this manner, one developer can own multiple single-tenant execution environments. Single-tenant execution environments 1 (450), 2 (460), and 3 (470) each include user information 451, 461, and 471, execution engines 452, 462, and 472, distribution engines 455, 465, and 475, storage 456, 466, and 476, and DB sets 457, 467, and 477. Apart from the fact that these are dedicated to a single developer, they have the same functions as the user information 411, execution engine 412, distribution 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 than the three shown in the figure.

Using the system in Figure 1, for example, an operator could provide the multi-tenant execution environment 410 to developers free of charge and the single-tenant execution environments for a fee. The operator of this system would need to pay maintenance costs to the resource and service provider (cloud service provider) for both the multi-tenant execution environment 410 and each single-tenant execution environment. By having the operator cover the maintenance costs of the multi-tenant execution environment 410 and provide it free of charge to multiple developers, developers would not need to incur costs for trial use of the system, making it easier for many developers to use and promoting the spread of the system. The operator would recover costs by charging developers for the single-tenant execution environments.

There is a limit to the number of processing requests that can be processed per unit time in a single execution environment. If many applications are built in a multi-tenant execution environment and many app users access them simultaneously, the requests may not be able to be processed, which could result in the applications running slowly. There are also 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 applications from achieving their full performance. Developers can avoid (or mitigate) these problems caused by the limitations of a multi-tenant execution environment by paying to own a dedicated single-tenant execution environment. In other words, by building applications in a single-tenant execution environment, it is possible to build applications that demonstrate sufficient performance.

Taking into account the characteristics of both the multi-tenant single environment and the single-tenant execution environment, developers can use the system as follows. For example, when using the system for the first time, a developer can build an application developed using the system in the multi-tenant execution environment 410 and test it. After determining that the system is beneficial to the developer's software development, the developer can purchase a single-tenant execution environment. Furthermore, when developing a specific application X, a developer can build an alpha version of application X in the multi-tenant execution environment 410 for a limited number of test users to try out before releasing it to general users. Application X is then tested, modifications are made, and further development is carried out. Then, once development is complete to a level where it can be released to general users, a production version of application X is built in the single-tenant execution environment and released to general users. Using the system in this way, developers can reduce development costs during the development period and operate applications without any problems, even when used by a large number of general users.

Figure 2 shows a hardware block diagram of an information processing device as an example of a device (electronic device) that can be used as developer terminal 100, application user terminal 200, and application user terminal 201. In Figure 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. Each unit connected to internal bus 150 is capable of exchanging data with each other via internal bus 150.

Memory 102 is, for example, RAM (volatile memory using semiconductor elements, etc.). CPU 101 controls each part of the information processing device using memory 102 as work memory in accordance with programs stored in, for example, non-volatile memory 103. Non-volatile memory 103 stores image data, audio data, other data, and various programs for CPU 101 to operate. Non-volatile memory 103 is, for example, composed of a hard disk (HD) or ROM.

Under the control of the CPU 101, the image processing unit 104 performs various image processing on image data stored in the non-volatile memory 103 or recording medium 108, video signals acquired via the external I/F 109, image data acquired via the communication I/F 110, captured images, etc. 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 specific image processing. Furthermore, depending on the type of image processing, the CPU 101 may perform image processing according to a program without using the image processing unit 104.

Under the control of CPU 101, display 105 displays images and GUI screens that constitute a GUI (Graphical User Interface). CPU 101 generates display control signals according to a program and controls each part of the information processing device to generate video signals for display on display 105 and output them to display 105. Display 105 displays images based on the output video signals. Note that the information processing device itself may only have an interface for outputting video signals 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 for processes executed by developer terminal 100, application user terminal 200, and application user terminal 201 will be assumed to be the display 105 of each operator.

The operation unit 106 is an input device for accepting user operations, and includes a character information input device such as a keyboard, a pointing device such as a mouse or touch panel, a button, a dial, a joystick, a touch sensor, a touchpad, etc. The touch panel is an input device that is configured as a planar surface overlaid on the display 105 and outputs coordinate information according to the position of contact.

The recording medium I/F 107 allows a recording medium 108 such as a memory card, CD, or DVD to be attached, and reads and writes data from and to the attached recording medium 108 under the control of the CPU 101. The external I/F 109 is an interface that connects to an external device via a wired cable or wirelessly, and is used to input and output video and audio signals. The communication I/F 110 is an interface that communicates with external devices and the Internet 111, sending and receiving various data such as files and commands. The developer terminal 100 can communicate with (send and receive information from) the development environment 300 on the Internet 111 using the communication I/F 110. The application user terminals 200 and 201 can communicate with (send and receive information from) the execution environment 400 on the Internet 111 using the communication I/F 110.

<Login process>
3A and 3B show flowcharts of the login process. This process covers the process from logging in to the development environment 300 from the developer terminal 100 to displaying the UI editor. When the developer terminal 100 launches the internet browser software and receives an instruction to access the development system (application development platform) of this embodiment by specifying the URL, the process shown in FIG. 3A begins. The process shown in FIG. 3A is realized by the CPU 101 of the developer terminal 100 loading into memory 102 a program stored in nonvolatile memory 103 for executing the internet browser software and a client program 322 received from the development environment 300. Hereinafter, the process simply described as the process executed by the developer terminal 100 refers to the process in which the CPU 101 of the developer terminal 100 loads into memory 102 a program stored in nonvolatile memory 103 for executing the internet browser software and a client program 322 received from the development environment 300 and executes them.

When the developer terminal 100 launches the internet browser software and accesses the development system (application development platform) of this embodiment by specifying its URL, the distribution engine 305 of the development environment 300 detects the access and sends the client program 322 to the developer terminal 100 that is the source of the access.

In S301, the developer terminal 100 determines whether 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 if it has been received, it proceeds to S302.

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

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 the login screen for the development system of this embodiment, as well as fields for entering a developer ID and password, a new registration button (icon), and a login button (icon).

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

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 hereafter, an operation to instruct a display item (a display object such as a button or icon, or a display item) by clicking with the mouse included in the operation unit 106 or touching the touch panel will be referred to simply as "pressing." If the new registration button has been pressed, proceed to S306; if not, proceed to S307.

At S306, the developer terminal 100 performs developer account registration processing.

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

In S308, the developer terminal 100 sends 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 as login information. After sending, authentication processing is performed in the development environment 300, so the developer terminal 100 waits for the results.

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

In S310, the developer terminal 100 determines whether it has received an execution environment list from the development environment 300. If login authentication is successful, the development environment 300 sends the execution environment list to the developer terminal 100, so receiving the execution environment list means that login authentication was successful (login was successful). If the execution environment list has been received, proceed to S311; if not, return to S309.

In S311, the developer terminal 100 records the execution environment list received in S310 in memory 102 as the development screen for the app after login, and displays execution environment options on the display 105 based on the received execution environment list. 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 differ from the screen of the built app are collectively referred to as development screens.

Figure 5(a) shows an example of the execution environment options displayed in S311. In the display example of Figure 5(a), two options are displayed as execution environments accessible to the logged-in developer: 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 confirm the selection by pressing the SAVE button 553. The selection made here is the destination to which the application updated in 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 using the operations described below.

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

In S313, the developer terminal 100 records information identifying the execution environment selected in S312 (such as the execution environment ID) in memory 102 as the "selected execution environment" and transmits it to the development environment 300. In response to receiving the information identifying the selected execution environment (selected environment), the development environment 300 transmits, as app information, information identifying all applications owned by the logged-in developer (applications previously generated and recorded in storage 320) (such as the app ID and app name).

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

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

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

In S317, the developer terminal 100 records the application selected from the app list as the "selected app" in memory 102, and also transmits information identifying the selected app (such as the app ID and app name) to the development environment 300. Upon receiving the information identifying the selected app, the development environment 300 obtains definition information (app definition) for the selected app from the area of storage 320 for the logged-in developer, and transmits it to the developer terminal 100.

In S318, the developer terminal 100 determines whether it has received definition information (UI definition information) for the selected app from the development environment 300. If it has received definition information for the selected app, it records the received definition information for the selected app in memory 102 and proceeds to S319. If not, it waits for the reception of definition information in S318. In this embodiment, this definition information is a Json file in Json format that describes various definitions related to the application. Thereafter, when the selected app is displayed on the display 105, it is displayed based on the definition information recorded in memory 102. When an operation to update the selected app (e.g., changing the layout of UI components) is performed using the UI editor process described below, the definition information in memory 102 is updated to define the updated content. Then, when a save command is received, the latest definition information recorded in memory 102 is sent to the development environment 300 and saved in the logged-in developer's area of storage 320. This reduces the frequency of communication with the development environment 300 and prevents a decrease in response time due to communication, allowing for smooth update operations.

In S319, the developer terminal 100 displays a UI editor screen on the display 105 and displays the screen based on the received definition information. For example, a canvas (editing area of the UI screen) with a shape corresponding to whether the selected app is for desktop or mobile use (i.e., a shape corresponding to the type of device on which the app will be used) is displayed. For desktop use, a rectangular canvas with a 16:9 aspect ratio is used, and for mobile use, a canvas with a vertical aspect ratio similar to that of a smartphone is used. A list of UI screens owned by (belonging to) the selected app is displayed in the submenu area (described below). (Strictly speaking, this process is performed in S401 of Figure 4, described below.) The canvas also displays components (UI parts to be placed on the UI screen) that will be placed on the UI screen selected by default (the initial UI or the UI screen edited at the time of the last save). 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 ends in S319, and the process proceeds to S401 of Figure 4.

On the other hand, in S320, the developer terminal 100 determines whether an icon for creating a new application (Create App button 1402 in FIG. 14(a)) displayed on the screen displaying the list of applications has been pressed, instructing the creation of a new application. If it determines that an instruction to create a new application has been issued, the process proceeds to S321; otherwise, the process proceeds to S350.

In S350, the developer terminal 100 determines whether the tutorial button 1401 (Figure 14(a)) has been pressed. If the tutorial button 1401 has been pressed, the process proceeds to S351; if not, the process proceeds to S316.

In S351, the developer terminal 100 performs tutorial button processing. The tutorial processing will be described later using Figure 13.

In S321, the developer terminal 100 displays a selection screen asking whether the newly created application should be for desktop use (for PCs) or for mobile use, and accepts an operation to select one of the options. 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 laptop 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.

In S322, the developer terminal 100 displays a screen for accepting input of basic app information (at least the app name and app ID) for the newly created application, and accepts input operations to set the app information. Upon accepting the input of the app information, the information on whether the application is for desktop (PC) or mobile use accepted in S321 and the app information accepted in S322 are sent to the development environment 300. In this way, definition information for the new application is created in storage 320 of the development environment 300 as definition information for the newly created application, and the information on whether the application is for desktop (PC) or mobile use, the app name, and the app ID are recorded. In this way, the information on whether the application is for desktop (PC) or mobile use, the app name, and the app ID are also recorded in the definition information for applications that have already been created in the past.

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 that corresponds to whether it is for desktop or mobile use, selected in S321. The canvas is also displayed as blank information with no components placed on it. The login process ends in S323, and the program then proceeds to S401 in Figure 4.

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 the processor 303 of the development environment 300 expanding and executing a program recorded in memory 304 into an area of the development environment 300 that serves as work memory. Hereinafter, any description of a process simply executed by the development environment 300 will be taken to mean a process executed by the execution engine 302 of the development environment 300, or more specifically, by the processor 303.

In S331, the development environment 300 determines whether the login information sent from the developer terminal 100 in S308 has been received. If the login information has been received, the process proceeds to S332; if not, the process waits for the login information to be received.

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 determines whether the developer information 301 (user information) contains information that matches the developer ID and password combination contained in the received login information. If so, authentication is successful.

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

In S335, the development environment 300 sends to the developer terminal 100 a list of execution environments for developers (logged-in 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 accessible execution environment IDs for each developer. Each execution environment ID is an account ID for a cloud service (web service) and is assumed to be a 12-digit ID in this embodiment. For developers who can access multiple execution environments, the 12-digit execution environment IDs are recorded, separated by commas. In S335, the accessible execution environment IDs (one or more execution environment IDs separated by commas) for the logged-in developer are sent to the developer terminal 100. That is, in S335, the developer information 301 is referenced to identify the execution environments accessible by the logged-in developer. In this way, the accessible execution environments for each developer (the execution environments available to each developer) are recorded in the developer information 301 recorded in the development environment 300. This login-enabled execution environment can only be obtained by the developer who has been granted permission to log in. Furthermore, only the developer who has been granted permission to log in can obtain the execution environment that they themselves have access to. This eliminates the need for developers to manage information for accessing their own accessible execution environment separately from the information used to log in to the development environment 300. It also prevents other users from accessing the execution environment illegally.

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

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

In S338, the development environment 300 obtains app information indicating all applications owned by (created by) the logged-in developer from the logged-in developer's area in storage 320, and sends this information to the developer terminal 100. The app information sent here is only the app definition information necessary to display the app list mentioned above in S315, and does not include detailed definition information about each app (such as component placement and information indicating actions, which will be described later).

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

In S340, the development environment 300 creates and records definition information for a new application in the logged-in developer's area of storage 320 based on the information about the new app received in S339. The definition information recorded here includes information about whether the app is for desktop (PC) or mobile use, the app name, and the app ID. To distinguish the app from other users' apps in the multi-tenant execution environment 410, the development environment 300 records the app ID by appending an eight-digit developer code that uniquely corresponds to the developer ID of the developer who owns the app immediately before the ID entered by the developer in S322. The login process then ends. Thereafter, when performing internal processing or displaying the app ID in a programming language on the action board, the ID appended with the developer code of the logged-in developer is used. Furthermore, when displaying the app ID in a UI editor, etc., only the ID portion entered by the developer in S322 is displayed, excluding the developer code.

In S341, the development environment 300 determines whether or not it has received information identifying the selected app sent from the developer terminal 100 in S317. If it has received information identifying the selected app, it proceeds to S342; if not, it returns to S339.

In S342, the development environment 300 retrieves definition information (app definition) for the selected app from the logged-in developer's area in storage 320 based on the information identifying the selected app received in S341, and transmits this information to the developer device 100. The definition information transmitted here includes detailed definition information about the selected app (such as component placement and information indicating actions, which will be described later). The login process then ends.

<UI Editor Processing>
The UI editor process will be described with reference to Figures 4 and 5B. The UI editor process is a process for defining various aspects of the application to be constructed (UI component definitions, action definitions) in response to operations by a developer (user) on the UI editor screen (application development screen).

Figure 5(b) shows an example of a layout editing screen displayed by the UI editor process on the display 105. The screen in Figure 5(b) includes a header menu area 500, a main menu area 510, a submenu area 520, and a canvas 530 (the editing reception area of the UI screen).

The header menu area 500 displays 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.

The selected execution environment box 501 displays the selected execution environment ID as information indicating 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 obtained 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 does not change, and the content displayed in the main menu area 510, submenu area 520, and canvas 530 does not change. In this way, by changing the selected execution environment to which the same application is deployed, it is possible to deploy the same application to any number of execution environments.

The selected app box 502 displays the name of the selected app as information representing the selected app. By pressing the arrow icon on the right end of the selected app box 502, a list of apps owned by the logged-in developer obtained in S314 is displayed as a pull-down menu, 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 canvas 530 changes.

The selected UI screen box 503 displays the name of the UI screen being edited as information representing the UI screen being edited on the canvas 530. By pressing the arrow icon in the selected UI screen box 503, a list of UI screens belonging to the selected app is displayed as a pull-down menu based on the definition information of the selected app acquired in S318. By selecting any UI screen from the list, it is possible to change the UI screen being edited and displayed on the canvas 530.

The main menu area 510 displays the following selection icons for the main menu items: an app 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. The processing performed in response to pressing these selections will be described later in the screen switching processing of Figure 12.

The submenu area 520 displays a submenu corresponding to the item selected in the main menu. In the example of Figure 5(b), a UI component list (UI part list) is displayed as a lower-level menu of the UI screen button 512.

The canvas 530 is the layout editing area for the selected UI screen of the selected app (the UI screen whose UI screen name is displayed in the selected UI screen box 503). The canvas 530 in Figure 5(b) is an example of a canvas display for a desktop application, displayed in a desktop format. The user can select any UI component (UI part) from the list of UI components displayed in the submenu area 520 and place it in the canvas area 530 by dragging and dropping it. The size and position of a UI component can be adjusted by selecting it in the canvas area 530. Furthermore, by selecting a UI component in the canvas area 530, right-clicking, and selecting properties from the right-click menu (context menu), more detailed settings such as color scheme can be made. Furthermore, by selecting an action from the context menu, an action board is displayed, allowing the user to set the action to be executed when the UI component is operated. By right-clicking while the cursor is in a blank area of the canvas 530, the canvas's context menu can be displayed. By selecting an action from the menu, you can set the action to be executed when the UI screen of that canvas is loaded in the built application (to be executed when the UI screen is displayed).

Figure 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" for an app with an app name "UI1." Operation path 531a is a selection frame indicating the selected UI component and an operation path (operation handle) that accepts zoom instructions, indicating that pie chart 531 is selected.

Figure 4 shows a flowchart of the UI editor process. This process is executed by the developer terminal 100 and follows S319 or S323 in Figure 3.

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

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

In S403, it is determined whether an operation to select one of the options displayed in the main menu area 510 has been performed. If an option displayed in the main menu area 510 has been selected, the UI editor processing ends and the process proceeds to the screen switching processing described later in FIG. 12. If not, the process returns to S402.

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 app recorded in memory 102. If the UI screen has previously had UI components placed on it, the UI components placed on it according to the definition information are displayed on the canvas 530. In other words, if the UI screen was previously created but only partially, development can continue from that point. If the UI screen selected in S402 is a newly created UI screen, the canvas 530 is displayed blank with no UI components placed on it. If the UI screen selected in S402 is a UI screen (template screen) that has been prepared in advance as a template, a template component with a predetermined action defined is displayed in a predetermined position on the canvas 530, even if the user has not previously placed UI components on that UI screen.

At S405, the developer terminal 100 displays a list of UI components in the submenu area 520. That is, the display switches from the UI screen list of the selected app to a UI component list. UI components that can be placed on the canvas 530 include types: INPUT, Button, Display (information display component), Navigation, Layout, and Chart, each of which has multiple UI components categorized under that type. In the UI component list, a list of UI component types is first displayed, as shown in FIG. 5(c). When an operation to select one of the displayed types is performed, the UI components classified under the selected type are expanded and displayed. The aforementioned FIG. 5(b) shows an example in which the option 522 for the type corresponding to INPUT is selected, and a list of UI components classified under INPUT is displayed. UI components classified under 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 for the UI component of the expanded type and options for other types) can be scrolled to display them. When an option 522 for an expanded type is operated, as shown in Figure 5(b), the list of UI components for the expanded type is collapsed, and a list of UI component types is displayed.

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

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

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

Tab components will be explained using Figures 6(a) and (b). Figure 6(a) is an example of a display on the display 105 when a tab component 601 is placed on a canvas 530 displaying a UI screen different from that shown in Figure 5(b). The area indicated by the operation bus 601a of the tab component 601 is the area occupied by the tab component 601. By operating the operation bus 601a, the overall display position and overall display size of the tab component 601, including the element screen, can be changed. The tab component 601 has three tabs: tab 610, tab 620, and tab 630. Each tab displays a label as the tab name, which can be set by the developer in the tab component's property settings. In the example shown, they are displayed as Tab0, Tab1, and Tab2, respectively. The number and order of tabs can be changed in the tab component's property settings. Tab properties are set by opening a tab property box from the tab's context menu in S706 of the context menu processing described later in FIG. 7 , and then performing setting operations on the tab property box (setting screen) that is displayed accordingly. The element screen area 602 indicated by the dashed-dotted line (illustrated for illustrative purposes only and not actually displayed) is an area in which the display content changes depending on the selected tab. The display content corresponding to each tab displayed in the element screen area 602 is referred to as the element screen corresponding to each tab. Different UI components can be arranged on the element screen corresponding to each tab. The example in FIG. 6A shows an example in which tab 610 is selected and the element screen corresponding to tab 610 is displayed. In the illustrated example, UI components 611 and 612 are arranged on the element screen corresponding to tab 610. The example in FIG. 6B shows an example of a display in which tab 620 is clicked from the state in FIG. 6A , changing the selected tab from tab 610 to tab 620. In FIG. 6B , the element screen area 602 displays the element screen corresponding to the selected tab 620. In the illustrated example, a UI component 621 is placed on the component screen corresponding to tab 620. In the examples of FIGS. 6(a) and 6(b), the definition information at least records the UI component ID (UI component identification information) of tab component 601 and the position of tab component 601 in the UI screen in association with the ID (UI screen identification information) of the UI screen being edited on canvas 530. Also, the IDs of UI components 611 and 612 and their respective positions in the component screen of tab 610 are recorded in association with the ID of tab 610 of tab component 601. Also, the ID of UI component 621 and the position of UI component 621 in the component screen of tab 620 are recorded in association with the ID of tab 620 of tab component 601. Return to the description of FIG. 4.

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

In S410, the developer terminal 100 places the UI component selected in S406 from the submenu area 520 at a default size on the element screen (the currently displayed element screen) corresponding to the selected tab among the tab components at the specified position on the canvas 530, and records the information defining this in the definition information stored in memory 102. That is, the definition information associates the ID of the destination UI screen (the UI screen being edited) with the type of UI component placed in S410, the tab component ID as the UI component ID, the ID of the selected tab for that tab component, the placement coordinates in the element screen corresponding to the selected tab, the placement size, and other information. In this way, in this embodiment, it is possible to place and layout different UI components on each element screen corresponding to each tab of the tab component. Furthermore, at this time, there is no need for complex operations to define the tab of the element screen on which the UI component will be placed; simply select and display the destination element screen when placing the desired UI component by dragging and dropping it.

In S411, the developer terminal 100 determines whether a UI component already placed on the canvas 530 has been selected by clicking or the like. If a placed UI component has been clicked (selected), the process proceeds to S412; if not, the process proceeds to S415.

In S412, the developer terminal 100 displays an operation path for the UI component clicked in S411. Examples of displayed operation paths are the operation path 531a and operation path 601a described above.

In S413, the developer terminal 100 determines whether the position specified by clicking in S411 is within the area of the tab portion of the tab component. If it is not within the tab portion, the process proceeds to S431; if it is within the tab portion, the process proceeds to S414. The tab portion is a designation area that instructs switching to the corresponding element screen.

In S414, the developer terminal 100 switches the display of the tab component's element screen area to the element screen corresponding to the tab at the position specified by the click in S411. For example, if one of the three tabs displayed as ITEM1, ITEM2, or ITEM3 on the tab component 536 is clicked 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, for example, if the display is as shown in FIG. 6(a), the display switches to that shown in FIG. 6(b) when tab 620 is specified. That is, the UI components 611 and 612 located on the element screen displayed before the click are hidden, and instead, the UI component 621 located on the element screen corresponding to the clicked tab 620 is displayed. This control is performed to simplify the operation of defining the element screen of the desired tab when a developer wants to place another UI component on the element screen of a desired tab of the tab component. If a developer wants to place another UI component on the component screen of a desired tab of a tab component, they can simply click the desired tab to display the desired component screen before dragging and dropping the desired UI component.

In this embodiment, for the sake of simplicity, the processing of S409, S410, S413, and S414 has been described using a tab component as an example, but this is not limited to this. The processing of S409, S410, S413, and S414 can be applied to a specific type of UI component other than a tab component, as long as the display content of the UI component changes in response to an operation on the UI component after the application is built.

On the other hand, in the case of UI components that are not of a specific type, such as tab components, the display content within the UI component is not changed in response to the selection of the UI component on canvas 530. The only processing performed in response to the selection of the UI component is processing related to the display of the operation path, and no other actions are performed. For example, when button 532 is selected on canvas 530 in Figure 5(b), only the operation path is displayed, and the action of button 532 (the processing that is executed when button 532 is pressed in the constructed app) is not executed. Furthermore, when text field 533 is selected on canvas 530, only the operation path is displayed, and processing such as displaying a character input cursor within text field 533 is not performed.

Using Figures 6(c), 6(d), and 6(e), we will explain an example of an AppBar as an example of a type of UI component to which the processes of S409, S410, S413, and S414 can be applied, similar to tab components. Figure 6(c) shows an example in which UI components AppBar 650, TextField 661, and Button 662 are placed on canvas 530. AppBar 650 is a single UI component, and contains element icons 651 and 652. In a constructed application, element icon 651 is a display item that accepts instructions for displaying a drawer menu. In a constructed application, element icon 652 is a display item that accepts instructions for displaying a pop-up menu. When the positions of element icons 651 and 652 of placed AppBar 650 on canvas 530 are clicked, they are controlled in the same way as the tab portion of a tab component. More specifically, it is controlled as follows:

When the position of the element icon 651 in the placed AppBar 650 is clicked (Yes in S411), the operation path for the AppBar 650 is displayed (S412), and if a Yes determination is made in S413, a drawer menu is displayed as an element screen (S414). This transitions the display state from FIG. 6(c) to FIG. 6(d). In FIG. 6(d), the operation path 650a for the AppBar 650 is displayed, and the drawer menu 651a, which is the element screen corresponding to the element icon 651, is also displayed. The drawer menu 651a is an area that is displayed by sliding from the left edge of the screen to the right, and displays one or more menu items. With the drawer menu 651a displayed, other UI components can be placed in the drawer menu 651a by dragging other UI components from the submenu area 520 and dropping them onto the drawer menu 651a, similar to the processing described in S408 and S410 using the tab component as an example.

When the position of the element icon 652 in the placed App Bar 650 is clicked (Yes in S411), the operation path for the App Bar 650 is displayed (S412). Furthermore, if a Yes determination is made in S413, a pop-up menu is displayed as an element screen (S414). This transitions the display state from FIG. 6(c) to FIG. 6(e). In FIG. 6(e), the operation path 650a for the App Bar 650 is displayed, and a pop-up menu 652a, which is an element screen corresponding to the element icon 652, is also displayed. The pop-up menu 652a is an area displayed near the element icon 652 and displays one or more menu items (options). With the pop-up menu 652a displayed, other UI components can be placed in the pop-up menu 652a by dragging another UI component from the submenu area 520 and dropping it onto the pop-up menu 652a, similar to the process described in S408 and S410 using the tab component as an example. Return to the description of FIG. 4.

In S415, the developer terminal 100 determines whether an operation to drag a placed UI component on the canvas 530 has been performed. If an operation to drag a placed UI component has been performed, the process proceeds to S416; if not, the process proceeds to S417. In S416, the developer terminal 100 changes the position of the dragged UI component (selected component) in response to the drag operation. Specifically, it places the component at the dropped position. When the position is changed, the definition information recorded in memory 102 is also updated to indicate the new position.

In S417, the developer terminal 100 determines whether an operation has been performed on the operation path of a UI component already placed on the canvas 530. If an operation has been performed on the operation path, the process proceeds to S418; if not, the process proceeds to S419. In S418, the developer terminal 100 changes the size of the UI component (selected component) to which the operation path has been assigned in accordance with the operation on the operation path. When the size is changed, the definition information recorded in memory 102 is also updated to reflect the changed size.

In S419, the developer terminal 100 determines whether a command to display a context menu (in this embodiment, a right-click of the mouse) has been performed in any area of the canvas 530. If a right-click has been performed, the process proceeds to S420; otherwise, the process proceeds to S421. In S420, a context menu (right-click menu) is displayed according to the position of the mouse cursor at the time of the right-click, and context menu processing is performed to perform processing according to the operation on the context menu. For example, if a right-click is performed while the mouse cursor is over button 532 in FIG. 5(b), a context menu 540 related to button 532 (specified UI component) as shown in FIG. 5(d) is displayed. The context menu 540 displays properties 541, actions 542, and delete 543 as menu options. When properties 541 is selected, a properties box (detailed settings dialog) related to button 532 is displayed, allowing detailed settings to be made, such as the button name (label) to be displayed on button 532, the color of button 532, and the size specified numerically. When action 542 is selected, an action board related to button 532 is displayed, and an action can be entered into the action board in JavaScript, a programming language. The action entered here is the process to be executed when button 532 (specified UI component) is pressed in the constructed application. When delete 543 is selected, button 532 is deleted (removed) from canvas 530. Details of context menu processing will be described later using Figure 7.

In S421, the developer terminal 100 determines whether the Save button 504 has been pressed. If the Save button 504 has been pressed, the process proceeds to S422; if not, the process proceeds to S423. In S422, the developer terminal 100 transmits the definition information of the application being edited, which is stored in memory 102, to the development environment 300. Upon receiving the definition information, the development environment 300 performs a save process.

In S423, the developer terminal 100 determines whether the preview button 505 has been pressed. If it determines that the preview button 505 has been pressed, the process proceeds to S424; otherwise, the process proceeds to S425. In S424, the developer terminal 100 performs preview processing. In the preview processing, the canvas 530 is hidden, and a preview of the UI screen being edited on the canvas 530 is displayed based on the definition information stored in memory 102 or the definition information stored in the development environment 300, so that the UI screen will look the same as when viewed in the built application. The preview does not display the operation paths for operating UI components. In addition, some operations that are not performed on the UI editor screen (i.e., not performed by operations on the canvas 530) are performed in the preview. For example, when a UI component for screen transitions or a link is operated, a screen transition or transition to the link destination is performed. In addition, operations such as moving the selection frame for an item by operating the tab key on the keyboard are also performed. Please note that actions entered by the developer on the action board and database references will not be performed. As a result, the preview process can be displayed more quickly than if you were to actually deploy and check the results.

In S425, the developer terminal 100 determines whether the Deploy button 506 was pressed. If the Deploy button 506 was pressed, the process proceeds to S426; otherwise, the process proceeds to S427. In S426, the developer terminal 100 sends a deploy request to the development environment 300 to instruct the deployment process. Note that when the Deploy button 506 is pressed to perform the deployment process, the developer does not need to select the destination execution environment; the deployment occurs to the pre-selected execution environment displayed in the Selected Execution Environment box 501. Developers often work to update all the content to be deployed to a specific execution environment at once. For this reason, the system requires the developer to select the destination execution environment before selecting the application to be updated (S311 in Figure 3), eliminating the need to select the execution environment each time an application is deployed. This prevents operational errors such as accidentally deploying to an unintended execution environment and improves work efficiency. Furthermore, although authentication processing is performed when logging in to the development environment 300, there is no need to perform separate account authentication processing for the execution environment to be deployed to. This prevents an increase in the amount of work required and allows for efficient work. In other words, the developer terminal 100 does not obtain authentication information related to the execution environment to which the developer is deploying from the developer user.

In S427, the developer terminal 100 determines whether an operation to change the selected execution environment has been performed. Specifically, it determines whether 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; if not, the process proceeds to S429. In S428, the developer terminal 100 records information identifying the selected execution environment (such as an execution environment ID) in memory 102 as the "selected execution environment" and sends it to the development environment 300. The developer terminal 100 also updates the display content of the selected execution environment box 501 to represent the changed selected execution environment. Upon receiving the information identifying the selected execution environment, the development environment 300 records the selected execution environment in a settings management file stored in the logged-in developer area of storage 320 based on that information.

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

In S430, the developer terminal 100 determines whether an operation to change the UI screen to be edited has been performed. Specifically, it determines whether 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. In other words, the display content of the canvas 530 is updated (switched) to the changed content of the selected UI screen. If no operation to change the selected UI screen has been performed, the process proceeds to S431.

In S431, the developer terminal 100 determines whether an operation to select one of the options displayed in the main menu area 510 has been performed. If an option displayed in the main menu area 510 has been selected, the UI editor processing ends and the process proceeds to the screen switching processing described later in FIG. 12. If not, the process returns to S406.

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

In S701, the developer terminal 100 determines whether the context menu to be displayed relates to a UI component of the button type. More specifically, it determines whether the type of UI component designated with the mouse when the right-click was accepted in S419 (designated UI component) is a button. If it is a button, the process proceeds to S710; if not, the process proceeds to S702.

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 with the mouse when the right-click was accepted in S419 was a blank area of the canvas 530 where no UI components were placed. If it is a blank area (if the context menu to be displayed is related to the canvas), the process proceeds to S703; otherwise, the process proceeds to S704.

In S703, the developer terminal 100 performs canvas context menu processing.

In S704, the developer terminal 100 determines whether the context menu to be displayed relates to a UI component of the data grid (table) type. More specifically, it determines whether the type of the UI component (specified UI component) 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; if not, the process proceeds to S706.

In S705, the developer terminal 100 performs context menu processing for the data grid.

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

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

In S711, the developer terminal 100 superimposes and displays the button context menu shown in FIG. 5(d) near the specified position (mouse cursor position) as a context menu for the specified UI component.

In S712, the developer terminal 100 determines whether or not Properties (Properties 541 in FIG. 5(d)) has been selected from the options included in the context menu. If Properties has been selected, the process proceeds to S713; if not, the process proceeds to S714.

In S713, the developer terminal 100 displays a property box for the button superimposed on the canvas 530 as a property box (detailed settings dialog) for the specified UI component. It then accepts various setting operations for the property box. Here, detailed settings can be made, such as the button name (label) to be displayed on the button (the specified UI component), the button color, and the size (specified numerically). After making the settings and performing an operation to reflect them, the specified UI component is displayed on the canvas 530 in a display format that reflects the settings.

In S714, the developer terminal 100 determines whether an action (property 542 in FIG. 5(d)) has been selected from the options included in the context menu. If an action has been selected, the process proceeds to S715; if not, the process proceeds to S716.

In S715, the developer terminal 100 performs action board processing for the button, which is the specified UI component. Action board processing will be described later using Figure 8.

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

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

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

In S720, the developer terminal 100 determines whether an operation to close the context menu has been performed (for example, an operation to click 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 in Figure 7 ends. If no operation to close the context menu has been performed, the process returns to S712.

Meanwhile, in S721, the developer terminal 100 superimposes a button context menu for the template screen near the specified position (mouse cursor position) as a context menu for the specified UI component. Unlike the context menu for a normal UI screen (context menu 540 shown in FIG. 5(d)), the template screen context menu does not display options such as Action or Delete, but only Properties. In other words, for UI components placed on the template screen, the developer cannot set the action to be taken when the UI component is operated.

In S722, the developer terminal 100 determines whether or not Properties has been selected from the options included in the context menu. If Properties has been selected, the process proceeds to S723; if not, the process proceeds to S724. The processing of S723 is the same as S713.

In S724, the developer terminal 100 determines whether an operation to close the context menu has been performed (for example, an operation to click 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 in Figure 7 ends. If no operation to close the context menu has been performed, the process returns to S722.

<Action Board Processing>
The processing related to the action board will now be described. When a UI component placed on the canvas is designated and an action is selected from the context menu, an action board for setting an action related to the designated UI component is displayed. For example, consider the case where a UI screen such as that shown in FIG. 9A is being edited. FIG. 9A is a diagram showing a portion of the UI editor screen on the display 105. In FIG. 9A, a list of UI components is displayed in the submenu area 520, and the UI screen to be edited is displayed on the canvas 900. A UI component 901, which is a button, and other UI components are arranged on the canvas 900. When the UI component 901 is designated and an action option is selected from the context menu, an action board such as that shown in FIG. 9B is displayed.

Figure 9(b) is an example of an action board display for UI component 901. Action board 910 is displayed in place of canvas 900 in the area where canvas 900 was displayed. Unless the specified UI component is a template component pre-placed on the template screen, and unless the developer has previously set an action for the specified UI component, action board 910 will be displayed blank, as shown in Figure 9(b). Note that the "1" displayed on action board 910 is a guide indicating the number of lines, and does not represent the action itself. Developers can set any action on this action board 910 by operating the keyboard included in operation unit 106 and entering any string in JavaScript, a programming language. The trigger for executing the content set on the action board is predetermined and occurs when the specified UI component is operated. Therefore, developers do not need to set the trigger for executing the action (there is no need to write it in JavaScript). For example, if the specified UI component is a button, pressing that button in the constructed app will be the trigger, and when the trigger occurs, the action set in the action board for that button will be executed.

In addition to the action board 910, a function list 920 is displayed in the submenu area instead of the UI component list or UI screen list shown in Figure 9(a) that was 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 the developer (user) by pressing the Add Function button 921 (described below) is referred to as an "original function" (created function, added function, self-made function). If there are no automatically created functions or pre-prepared functions and the developer has not previously created an original function for the specified UI component, the function list 920 will not display function options, and only the option 922 and the Add Function button 921 will be displayed, as shown in Figure 9(b).

When the Add Function button 921 is pressed, a dialog box (referred to as the Add dialog 930) for adding an original function is displayed. Figure 9(c) shows an example of the Add dialog 930. The Add dialog 930 displays a type selection field 931 that accepts the selection of the function type, a function name input field 932 that accepts the input of the function name, and a SAVE button 933. When input is made to the Add dialog and the SAVE button 933 is pressed, a function settings screen corresponding 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 added to the function list 920.

Figure 9 (d) is an example of a REST function setting screen that is displayed when REST is selected in the type selection field 931. In place of the action board 910, a REST function setting screen 940 is displayed to accept various settings required to create a function (REST function) using REST (REpresentational State Transfer). The function list 920 also displays a function 923 with the function name "rest01" entered in the function name input field 932 as a function option. The icon displayed before "rest01" indicates that the type of function 923 is a REST function. If all required setting items are not set on the function setting screen (if information that should be set is missing), an incomplete mark 929 indicating that the function is incomplete is displayed, clearly indicating that the corresponding function 923 is in an incomplete state.

The REST function setting screen 940 in Figure 9(d) displays setting fields 941 to 944. Setting field 941 is a setting screen for the function name. By default, it displays the function name entered in the function name input field 932, but this can be changed based on input from the developer. Setting field 942 is a setting field for setting the variable name for the 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. Setting field 943 is a setting field for setting the type of REST function. By operating the triangle icon on the right side of this area, a pull-down menu appears with options: GET, POST, PUT, and DELETE, and one of these options can be selected and set. The type set here indicates the type of request made by this function. 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, developers do not need to write source code strings in a programming language.

Figures 10(a) to (d) show further examples of the creation function setting screen and action board display. In Figure 10, the same elements as in Figure 9 are given the same reference numerals as in Figure 10, and their explanations will be omitted.

Figure 10(a) shows an example of the SQL function setting screen that appears when SQL is selected in the type selection field 931. Instead of the action board 910, an SQL function setting screen 950 is displayed to accept various settings required to create a function (SQL function) using SQL (Structured Query Language). The function list 920 also displays the function 924 with the function name "sql01" entered in the function name input field 932, along with an incomplete mark 929, as a function option. The icon displayed before "sql01" indicates that the type of function 924 is an SQL function. The setting field 951 is a function name setting screen. Initially, the function name entered in the function name input field 932 is displayed, but this can be changed based on input operations by the developer. The setting field 952 is a setting field for setting variable names for setting arguments. In this embodiment, param is set by default and cannot be changed. It is displayed as grayed out to indicate that it cannot be changed. The setting field 953 is an input field for entering a string of characters (SQL sentence, SQL statement) that issues instructions to a database in SQL, a type of computer language (a database language, not a programming language). The developer can enter any SQL STATEMENT into the setting field 953 using a keyboard included in the operation unit 106, for example. In this way, when creating an SQL function on the SQL function setting screen 950, the developer does not need to write the source code string in a programming language.

Figure 10(b) shows an example display of the stage when a developer has created functions 923-925, entered (written) some code (character strings) in JavaScript into the action board 910, and then entered "sq." In this embodiment, when a developer user enters a character string, if the entered character string matches the prefix of the function name (identification information) of a previously created created function, the code assist field 911 displays the matching function name as an input candidate option. In the illustrated example, the entered "sq" matches the prefix of the function name "sql01" of function 924, a previously 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 entered into the action board 910, as shown in Figure 10(c), without performing an operation to enter "sql01." This code assist function allows developers (users) to enter the function name (identification information) of a created function without typing all the characters of the function name on the keyboard, thereby reducing the number of steps required. Furthermore, if the function name matches the prefix of a previously created created function, the full name is displayed in the code assist field 911. If there is no match (i.e., if no function begins with that character string), the code assist field 911 is not displayed. This allows developers to confirm that the function name they are entering is correct for a previously created created function, preventing input errors in the function name. If there are multiple previously created functions that match the prefix, multiple options are displayed in the code assist field 911. Furthermore, the function names of created functions displayed in the code assist field 911 are functions created for the specified UI component (UI component 901 in the illustrated example) targeted by the action board 910; created functions created for other UI components are not displayed. This prevents the mistake of accidentally entering the name of a created function created for another UI component on the action board 910, even if that function does not exist as a created function for the specified UI component.

As shown in Figure 10(c), the function list 920, along with the action board 910, displays the function type (icon before the string) and function name for each of the developer-created functions 923-925. Therefore, while entering (writing) the action code (JavaScript string) into the action board 910, the developer user can check the types and names of the created functions they have created. This reduces the effort required to check and manage valid created functions that can be written into the action board 910 (e.g., the effort required to make a note of them or open another screen to check). It also helps prevent input errors in function names. The functions displayed in the function list 920 are functions created for the specified UI component (UI component 901 in the illustrated example) targeted by the action board 910; created functions created for other UI components are not displayed. This prevents the mistake of accidentally entering a function name of a creation function created for another UI component that does not exist as a creation function for the specified UI component on the action board 910. Furthermore, creation functions are only valid when defining the action of the specified UI component and do not affect the action definitions of other UI components. Therefore, if the function name of a creation function created for a specified UI component is the same as the function name of a creation function created for another UI component, even if that function name is entered on the action board 910, only the function settings set for the specified UI component will be reflected, and the function settings set for the other UI components will not be reflected. Therefore, no error will occur even if the same function name as the function name of a creation function already created for another UI component is used. Therefore, the user can decide on the function name of the creation function and enter it on the action board 910 without worrying about duplicate function names with creation functions already created for other UI components. In other words, many original functions will be created throughout the entire development of an application, but these are automatically managed and organized in association with specified UI components and displayed in the code assist field 911 and function list 920, making it extremely easy for developers to manage a large number of original functions. This reduces the effort and time required to check function names. It also reduces input errors in function names. This also reduces the amount of debugging work (debug fixes) required when inputting a function name. This reduces the workload and man-hours required for software development (application development), enabling more efficient software (application development).

Figure 10(d) is an example of the display after action code has been entered in a programming language into the action board 910. In the illustrated example, the portion indicated by the dotted line 960 on the third line uses the original function "rest01" (function 923 in the function list 920). The code string shown on the action board 910 in Figure 10(d) does not define the details of the original function rest01. Furthermore, when the developer configured rest01 on the REST function setting screen 940, the details of rest01 were not defined in the programming language. If definition information including the action definition in this state is uploaded and saved to the development environment 300, the development environment 300, during the save process, creates source code in the programming language including the function definition in the programming language from the uploaded definition information as an execution environment program based on the function settings and the string written on 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.

Figure 11 shows an example of source code in a programming language generated by the development environment 300 based on the string entered on the action board 910 in Figure 10(d) and the settings for rest01 configured on the REST function setting screen 940. Note that in the illustrated example, the numbers 1 to 75 written on the left side are used to indicate the line numbers and are not part of the source code. The example in Figure 11 shows 75 lines of source code including a detailed definition of rest01 in a programming language. However, developers do not need to enter all 75 lines themselves. By configuring the REST function setting screen 940 and entering the amount of string (7 lines) shown on the action board 910 in Figure 10(d), the source code content shown in Figure 11 can be defined. In other words, efficient development can be achieved using low code.

Figure 8 shows a flowchart of the action board processing. This processing is a detailed flowchart of the action board processing described above in S715 of Figure 7, and is a process that controls the operations described using the display examples in Figures 9(b) to (d) and 10(a) to (d).

In S801, the developer terminal 100 displays an action board on the display 105. If no action has been defined for the specified UI component, 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 component, a screen including an action board 910 with the action string entered as described in FIG. 10(d) is displayed.

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

In S803, the developer terminal 100 accepts the action input operation by the action description operation and displays the input characters on the action board 910.

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 there is a prefix match, proceed to S805; if not, proceed to S808.

In S805, the developer terminal 100 displays the function names of the created functions determined to be a 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 that prefix-match the input string.

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 shown in FIG. 10(b), "sql01" is entered and displayed, as shown on the fifth line of the action board 910. If none of the options has been selected, the process proceeds to S808.

In S808, the developer terminal 100 determines whether the operation to describe the action is being performed continuously. If the operation to describe the action is being performed continuously, the process proceeds to S803; if not, the process proceeds to S802.

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

In S811, the developer terminal 100 displays the addition dialog 930 for adding a creation function and accepts input into the addition dialog 930. The content of the input accepted in the addition dialog is as described above with reference to FIG. 9(c). Once input into the addition dialog has been made and the SAVE button 933 has been pressed, the process proceeds to S812.

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.

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

In S815, the developer terminal 100 determines whether the type selected in the type selection field 931 of the addition dialog is SQL. If it is SQL, the process proceeds to S816; if not (i.e., if 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 using Figure 10(a).

In S817, the developer terminal 100 displays the 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 Figure 9 (d).

In S818, the developer terminal 100 determines whether input into the setting items predetermined as required items has been completed (whether the settings have been completed) on the function setting screen for each type. If input into the required items has been completed, the process proceeds to S819; if not, the process proceeds to S802.

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 creative function being set. This allows the user (developer) to recognize that the creative function being set is in a valid setting that can be used on the action board 910.

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

In S821, the developer terminal 100 determines whether a save instruction operation (e.g., pressing the Save button 915) has been performed. If a save instruction operation has been performed, the process proceeds to S822; if not, the process proceeds to S823.

In S822, the developer terminal 100 records the details of the action board processing performed up to this point in the definition information stored in memory 102 and transmits it to the development environment 300.

In S823, the developer terminal 100 determines whether 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 component is displayed. As a result, if the function settings screen was displayed, it switches to displaying the action board. If option 922 has not been pressed, the process proceeds to S824.

In S824, the developer terminal 100 determines whether an operation to close the action board (an operation to end 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 switches to the canvas of the selected UI screen, and the process returns to the UI editor processing.

<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).

In S1201, the developer terminal 100 determines whether the App List button 511 has been pressed. If the App List button 511 has been pressed, the process proceeds to S315 in Figure 3; if not, the process proceeds to S1202.

In S1202, the developer terminal 100 determines whether the UI screen button 512 has been pressed. If the UI screen button 512 has been pressed, the process proceeds to S1203; if not, the process proceeds to S1204. In S1203, the UI editor process of Figure 4 is performed.

In S1204, the developer terminal 100 determines whether the workflow button 513 has been pressed. If it determines that the workflow button 513 has been pressed, the process proceeds to S1205; if not, the process proceeds to S1206.

In S1205, the developer terminal 100 performs workflow creation processing.

In S1206, the developer terminal 100 determines whether the Settings button 514 has been pressed. If the Settings button 514 has been pressed, the process proceeds to S1207; if not, the process proceeds to S1209.

In S1207, the developer terminal 100 displays an app settings screen. The app settings screen is a screen that accepts setting operations related to the selected app. In S1208, the developer terminal 100 accepts setting operations on the app settings screen and updates the definition information recorded in memory 102 based on the settings. Settings that can be accepted in S1208 include, for example, a display language setting and a setting for whether to build an app that can be used as a PWA (Progressive Web App). There is also a setting for which UI screen, out of multiple UI screens belonging to the app, is to be designated as the initial UI. The initial UI is the screen that is displayed first when accessing a built app deployed in the execution environment, or the screen that is displayed first after authentication is successful on the app authentication screen after accessing the built app.

In S1209, the developer terminal 100 determines whether the Environment List button 515 has been pressed. If the Environment List button 515 has been pressed, the process proceeds to S311 in Figure 3; if not, the process proceeds to S1210.

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

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

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, which is the selected execution environment, and acquires the contents recorded in the database. The development environment 300 then transmits the database information acquired from the selected execution environment to the developer terminal 100. The developer terminal 100 will never access the single-tenant execution environment without going through the development environment 300.

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

In S1214, the developer terminal 100 displays the database management screen and displays the database information obtained in S1212 or S1213. It then accepts DB management operations to specify various settings for the database of the selected execution environment and to instruct content updates.

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

At S1216, the developer terminal 100 displays a file management screen for managing files to be saved in the selected execution environment, and at S1217, accepts operations for managing files to be saved in the selected execution environment. For example, an image file to be displayed on the screen of an application being 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 a save instruction is given, the developer terminal 100 sends the selected file to the development environment 300. When the development environment 300 receives the selected file, it sends it to the developer area of the selected execution environment, thereby saving 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 never accesses the multi-tenant execution environment 410 without going through the development environment 300. As explained in the login process above, developers must authenticate themselves before logging in to the development environment 300. Therefore, by restricting access to various execution environments to via the development environment 300, other users who cannot log in to the development environment 300 cannot access the execution environment illegally, thereby improving security.

In addition, the developer user only needs to perform the authentication operations required to log in to the development environment 300, and does not need to perform the authentication operations required to log in to each execution environment. This prevents an increase in the number of operations required.

In S1218, the developer terminal 100 determines whether the User Management button 518 has been pressed. If it determines that the User Management button 518 has been pressed, the process proceeds to S1219; if not, the process proceeds to S1220.

At S1219, the developer terminal 100 performs user information display processing. The user information display processing displays user information (such as user information 411, 451, 461, and 471 for each execution environment shown in FIG. 1) that is information about app users (information managed separately from the developer) who can log in to the application built in the selected execution environment, and accepts management operations from the developer.

In S1220, the developer terminal 100 determines whether the snapshot button 519 has been pressed. If the snapshot button 519 has been pressed, the process proceeds to S1221 to perform snap processing; if not, the process proceeds to S1222.

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 developer terminal 100 proceeds to S1201 and repeats the process, but if an end operation has been performed, the screen switching process ends.
<Tutorial processing>
FIG. 13 shows a flowchart of the tutorial processing executed by the developer terminal 100. This processing is a detailed example of the processing 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 processing of S315. The app list displays two options 1403 and 1404 as app options. A tutorial button 1401 and an app creation button 1402 are displayed in the header menu area. Pressing the tutorial button 1401 starts the tutorial processing of FIG. 13. Note that the display destination of the various display processes in the tutorial processing of FIG. 13 is the display 105 of the developer terminal 100. Furthermore, the various display examples are examples of a portion of the display 105, not the entire display 105.

In S1301, the developer terminal 100 displays a lesson list. Figure 14(b) shows an example of the lesson list 1410. A tutorial includes multiple lessons. Each lesson includes multiple chapters, and each chapter includes multiple steps (procedures). In the example of Figure 14(b), the lesson list 1410 displays five lessons, Lessons 1 to 5. Clicking the downward arrow to the right of any of the displayed lessons expands and displays the multiple chapters included in the corresponding lesson. Figure 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 area 1411. Chapters that the developer has already completed are displayed in different colors so that they can be easily distinguished from chapters that the developer has not yet started. When a lesson is selected and the start button 1412 is pressed, the tutorial for the selected lesson begins.

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

In S1303, the developer terminal 100 determines whether an operation to hide the lesson list 1410 (an operation to end the tutorial process) has been performed. If no operation to end the tutorial process has been performed, the process proceeds to S1302; if an operation to end the tutorial process has been performed, the tutorial process in FIG. 13 is ended.

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

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

In S1306, the developer terminal 100 initializes the step number variable S, which indicates the step (procedure) to be processed in the tutorial stored in memory 102, to 1.

In S1307, the developer terminal 100 determines whether the tutorial content to be displayed in the currently processed step, indicated by variables L, C, and S, contains a copied string. The tutorial content to be displayed in each step for each tutorial in each lesson is indicated by the client program 322 (client information) received from the development environment 300 in S302 and recorded in memory 102. That is, the determination in S1306 is made by referencing the client program 322 (client information) recorded in memory 102. If the step to be processed contains a copied string, proceed to S1320; otherwise, proceed to S1308. If the string to be entered, which is the information to be entered in the input field, is a step (procedure) that requires more than a predetermined number of characters, proceed to S1330; if the string to be entered, which is the information to be entered in the input field, is a step (procedure) that requires less than the predetermined number of characters, proceed to S1308.

In S1308, the developer terminal 100 displays a guide for the tutorial for the step being processed. Figure 14(d) shows an example of a guide display for a tutorial. Figure 14(d) is an example of a guide display for step 1 of chapter 1 of lesson 1. To highlight the Create App button 1402, which is the item to be operated, the other parts are grayed out and a speech bubble 1420 (guide display area) indicating (pointing to, identifying) the item to be operated in the target step of the tutorial is superimposed. The speech bubble 1420 displays a chapter guide 1421 indicating the current chapter, a guide message 1422 for the current step, and an end button 1423. In the example of Figure 14(d), the guide message 1422 reads, "Click the [Create App] button." Note that the item to be operated varies depending on the step and may be a button or an input item (an input item such as a text box).

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 step in a tutorial is referred to as an input target item. If the operation target item is something 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 by operating the keyboard included in the operation unit 106 with the input item selected), the process proceeds to S1311.

Figure 15(a) shows an example of a guide display in a tutorial when the item to be operated is an input item. Figure 15(a) is an example of a guide display for a step included in Chapter 1 of Lesson 1. To highlight the input item 1501, the other parts are grayed out and a speech bubble 1520 (guide display area) pointing to the input item is superimposed. The input item 1501 is a text box that accepts the developer (user)'s setting of the ID of the newly created app (input of a character string that will become the ID). The speech bubble 1520 displays a guide message 1522 for the current step, an end button 1523, and a next button 1524. In the example of Figure 15(a), the guide message 1522 reads, "Enter an [ID]. After entering the ID, click the [Next] button." In other words, guidance on what to enter in the input item 1501 is displayed. In Figure 15(a), the copy button is not displayed.

In S1311, the developer terminal 100 inputs a character string corresponding to the input operation from the user received in S1310 into the input target field. As a result, for example, as shown in FIG. 15(b), the character string "app01" is displayed in input target field 1501. FIG. 15(b) is the same display example as FIG. 15(a), except that a character string has been input into input target field 1501.

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

In S1313, the developer terminal 100 determines whether a skip button (e.g., 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; if not, the process proceeds to S1316. The skip button is displayed in a position that is unrelated to the display position of the item to be operated (i.e., a position that is unrelated to the position of the speech bubble displaying the guide), and in a fixed position (a predetermined position on the screen, the same position) that does not change on the screen even as the steps proceed. By doing this, after hovering the mouse over the skip button once, it is possible to continuously skip operations on items to be operated in multiple steps included in the tutorial while keeping the mouse position fixed. This allows you to efficiently check the contents of multiple steps of the tutorial, for example, if you want to quickly and easily check the contents rather than going through the tutorial in detail.

In S1314, the developer terminal 100 inputs predetermined values (various predetermined information) into the input target field. The predetermined values are values (information) recorded for each step in the client program 322 (client information) stored in memory 102, and are values (information) that allow the user to proceed to the next or subsequent step in the tutorial without error. For example, if the skip button is pressed in the state shown in FIG. 15(a), an appropriate value (e.g., the string "app_tutorial") is automatically entered into the input target field as the ID of the newly created app (e.g., the string "app_tutorial"). In other words, even if no user input is made into the input target field in S1310 or S1311, appropriate information (values) are automatically entered when the skip button (skip item) is operated. Note that if the operation target field is not an input field, the operation target field is automatically operated (pressed if it is a button) in S1314, and the process proceeds to S1340 without passing through S1315.

In S1315, the developer terminal 100 determines whether a predetermined time (e.g., 2 seconds) has elapsed while displaying the predetermined value automatically entered into the input field. If the predetermined time has elapsed, the process proceeds to S1340; otherwise, the process waits for the predetermined time to elapse in S1315. In this way, the appropriate value automatically entered into the input field is displayed for the predetermined time. Therefore, even if a developer user presses the skip button because they are unsure of what value to enter into the input field, they can confirm what value they should have entered. In this way, developer users can more effectively learn how to use and operate the system.

In S1316, the developer terminal 100 determines whether an operation to end the tutorial (e.g., pressing the End button 1423) has been performed. If an operation to end the tutorial has been performed, the process of FIG. 13 ends; if not, the process proceeds to S1310 and is repeated.

In S1340, the developer terminal 100 determines whether an error has occurred. If an error has occurred, proceed to S1941; if not, proceed to S1342.

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 field 1501 is left blank in the state shown in Figure 15(a), and then the Confirm App Creation button, which is the target field for operation, 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 Figure 15(a) is displayed (the variable S is set to the step number to return to), the input target field 1501 that caused the error is highlighted (for example, displayed in a red frame), and the process proceeds to S1307 to repeat the process of the step where Figure 15(a) is displayed.

In S1322, the developer terminal 100 determines whether the variable S is Smax (the number of the last step in the chapter being processed). If the variable S is Smax, the process proceeds to S1324; if not, the process proceeds to S1323.

In S1323, the developer terminal 100 increments the value of variable S by one. That is, it sets it to the number of the next step. Then, it proceeds to S1307 and performs processing related to the next step in the tutorial. For example, if in S1308 the Create App button 1402, which is the item to be operated, is pressed while the guide display for Step 1 of Chapter 1 of Lesson 1 in Figure 14(d) is displayed, S1302 will be determined as Yes, and it will proceed to S1320 No and S1322 No, and it will be set to the next step in the same Chapter 1 in S1323, and then it will proceed to S1307 No and S1308. In S1308, the guide display for Step 2 of Chapter 1 will be displayed, as shown in Figure 14(e).

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

The actual development of the app is controlled based on the operations in the tutorial. In other words, pressing the Deploy button in Figure 15(c) is synonymous with pressing the Deploy button included in the confirmation screen that is displayed after pressing the Deploy button in S425 of Figure 4 described above. Therefore, when the Deploy button is pressed in Figure 15(c), processing of S426 is performed, and a deploy request instructing deployment to the selected execution environment is sent to the development environment 300. In response, the development environment 300 actually deploys to the selected execution environment and builds the app. The definition information for a new app created in accordance with the tutorial is also saved in the development environment 300, and when the app list screen is displayed after completing Lesson 1, an option 1530 for the app created in the tutorial is added and displayed, as shown in Figure 15(d).

In S1325, the developer terminal 100 increments the value of variable C by 1. That is, it sets it to the number of the next chapter. Then, it proceeds to S1328, where it sets variable S to 1. That is, it sets it to the number of the first step of the next chapter. Then, it proceeds to S1307, where it performs processing related to the first step of the next chapter in the tutorial.

Meanwhile, at 1330, the developer terminal 100 displays a guide with a copy button for the tutorial of the step being processed. Figure 16(a) shows an example of a guide with a copy button for a tutorial. To highlight the input target item 1601, the other parts are grayed out, and a speech bubble 1620 (guide display area) identifying (pointing at) the input target item 1601 is superimposed. The speech bubble 1620 displays 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. In addition, the string to be copied is displayed in box 1626, along with a copy button 1624 (copy item), which is an operation icon (display item) that instructs the user to copy the string to be copied. The string to be copied displayed in box 1626 is the same as the predetermined value automatically entered into the input target item 1601 when the skip button 1610 is pressed. In other words, these are values (information) recorded for each step in the client program 322 (client information) stored in memory 102, and are appropriate values (information) that allow you to proceed to the next or subsequent step in the tutorial without error.

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

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

In S1333, the developer terminal 100 determines whether 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; if not, the process proceeds to S1340.

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 copy button 1624 has just been pressed, the character string to be copied (the character string displayed in box 1626) is input into the input target item 1601.

The processing of S1340 to S1346 is similar to the processing of S1310 to S1316, respectively, and therefore will not be explained here. It is also possible to enter an inappropriate value for the input item (for example, an incorrect URL) that is different from the string to be copied in S1341. By intentionally accepting input of an inappropriate value, the user can learn that an error will occur in subsequent processing if an inappropriate input is made.

Figure 16(b) shows an example of the display when, from the state shown in Figure 16(a), the copy button 1624 is pressed and then pasted into the input target item 1601, resulting in the string to be copied (the string displayed in box 1626) being entered into the input target item 1601. This makes it easy to enter the string to be entered in the tutorial. Even if the string is long, it is easy to enter an appropriate string (the string copied by pressing the copy button 1624) that will not cause errors.

Figures 16(a) and 16(b) are tutorials for the REST function settings screen described in Figure 9(d). This embodiment controls the actual execution of application development software functions based on the content entered in the input fields. That is, input field 1601 is the setting field 944 in Figure 9(d) and is the setting field for the URL to which this function sends requests. By entering a string indicating an appropriate URL to which requests will be sent in input field 1601, users can create a REST function that actually functions correctly through the tutorial. If a string indicating an inappropriate URL to which requests will be sent (e.g., a non-existent URL) is entered in input field 1601, the REST function generated in the tutorial will not function correctly and may result in an error. Entering the URL string manually without copying it is prone to typos, which can result in an inappropriate string. In contrast, as in this embodiment, by displaying a copy button 1624 during the tutorial, which allows users to easily copy the string to be copied, which is an appropriate string to which a request is to be sent, users can enter text easily and reliably without making any mistakes.

The copy button, which allows for easy copying of target strings, is also extremely effective in tutorials on the aforementioned action board. The action board allows for the entry of strings representing actions in JavaScript (a programming language). To guide developers through this in a tutorial and have them actually operate the action board, the input field can be set as the action board, and the developer can actually enter the string representing the action in JavaScript into the action board. The string representing an action in JavaScript is long, tedious to enter, and prone to typos. Furthermore, it is not easy for developer users to immediately come up with the right action, and starting from the beginning, deciding what action to write would be too time-consuming for a tutorial. Therefore, if the copy button could be used to copy a pre-prepared JavaScript string representing an appropriate action and paste it into the action board, it would significantly reduce the effort and errors while still providing the effect of a tutorial that helps developer users understand what the action board is. A similar effect can be achieved by automatically entering and displaying the same string as the target string in the action board by pressing the skip button.

In this embodiment, an example was described in which both a skip button and a copy button were displayed in the tutorial, but it is also possible to display only one of them. In other words, it is possible to perform either a process of automatically inputting a specified value into an input target field by pressing the skip button, or a process of copying an appropriate copy target string as a value to be input into an input target field by pressing the copy button.

Also, without displaying a copy button, it is possible to simply display in the tutorial guide area a string to be copied that is appropriate as a value (information) to be entered into an input field in a form that can be selected and copied. The string to be copied is copied in response to an operation to select the string to be copied displayed in the guide area and instruct copying, and the copied string to be copied is entered into the input field in response to an operation to paste into the input field, thereby achieving the effect of improving operability in the tutorial.

In this way, this embodiment can further improve operability during tutorials.

The various controls described in 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.
Furthermore, although the present invention has been described in detail based on its 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-described embodiments merely shows one embodiment of the present invention, and each embodiment can be combined as appropriate.

(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-described 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 media storing the program constitute the present invention.

100: Developer device, 200: App user device, 201: App user device 201, 300: Development environment, 400: Execution environment

Claims (15)

a display control means for controlling the display of input items into which the user should input information in a predetermined procedure among a plurality of procedures included in the tutorial, and a copy item for receiving an instruction to copy a copy item, which is information to be input into the input 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;
An information processing system comprising: The information processing system according to claim 1, wherein the display control means controls the display of the copy item in the predetermined procedure of the tutorial, and controls the display of guidance on what should be entered in the input target field without displaying the copy item in a second procedure of the tutorial that is not the predetermined procedure. 3. The information processing system according to claim 2, wherein the predetermined procedure is a procedure in the tutorial that satisfies a condition based on the number of characters of a string to be input as information to be input into an input target item. 2. The information processing system according to claim 1, wherein the control means is also capable of controlling the input of information different from the information to be copied into the input target item in response to a user operation. 2. The information processing system according to claim 1, wherein the control means controls the execution of actual functions of the software that is the subject of the tutorial based on the information input for the input target items. a display control means for controlling the display of input target items into which the user should input information in a predetermined procedure among a plurality of procedures included in the tutorial, and for controlling the display of copy targets, which are information to be input into the input target items, in the guide area;
copying the copy object in response to an operation of selecting the copy object and instructing copying;
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;
An information processing system comprising: the display control means further controls to display input target items into which the user should input information in a predetermined procedure among a plurality of procedures included in the tutorial, to display skip items, and to display guidance on the content to be input into the input target items in a guide area ;
the control means further controls, when a user inputs an operation for inputting the input item, the control means inputs the content input by the user into the input item and proceeds to the next step in the tutorial;
The information processing system described in claim 1, characterized in that when the skip item is operated, the system controls the input of specified content into the input target item and proceeds to the next step in the tutorial, even if there is no input operation from the user for the input target item . The information processing system according to claim 7, wherein the control means, when the skip item is operated, controls the system to proceed to the next step after displaying a state in which the predetermined content has been input into the input target item. The information processing system according to claim 7, wherein the control means controls the system to proceed to the next step after displaying the state in which the predetermined content has been input into the input target item for a predetermined period of time when the skip item is operated. 8. The information processing system according to claim 7, wherein the display control means controls the display so that the skip items are displayed at the same position in a plurality of steps included in the tutorial. 8. The information processing system according to claim 7, wherein the display control means controls the display of the skip item in a position that is independent of the position of the input target item. The information processing system according to claim 7 , wherein the display control means controls the display of the skip item in a position independent of the position of the guide area. a display control step of controlling to display input target items into which the user should input information in a predetermined procedure among a plurality of procedures included in the tutorial, and a copy item 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 step of controlling the copy target to be input into the input target item in response to a paste operation being performed on the input target item;
1. A method for controlling an information processing system, comprising: a display control step of displaying input target items into which the user should input information in a predetermined procedure among a plurality of procedures included in the tutorial, and controlling the display of copy targets, which are information to be input into the input target items, in the guide area;
copying the copy object in response to an operation of selecting the copy object and instructing copying;
a control step of controlling the copy target to be input into the input target item in response to a paste operation being performed on the input target item;
1. A method for controlling an information processing system, comprising: 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 12 .