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

Abstract

This invention provides an information processing system, a control method for the information processing system, and a program to improve usability in tutorials. [Solution] The information processing system includes a display control means that, in one of the multiple steps included in the tutorial, indicates an input item into which the user should input information, and controls the display of a copy item in the guide area that accepts instructions to copy the information to be entered into the input item, and a control means that copies the copy item in response to the operation of the copy item, and inputs the copy item into the input item in response to a paste operation on the input item.

Description

Technical Field

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

Background Art

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

[0003] Tutorials for acquiring the functions of application software are also known. In Patent Document 2, it is proposed to execute a tutorial selected from a plurality of tutorials and display the progress status of the tutorial.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] Some tutorials allow users to actually perform the software's functions by following the tutorial instructions. However, in tutorials that demonstrate the actual functionality of the software, even if the operations are within the tutorial, the software will not function correctly if the correct input is not made. For example, in a tutorial on creating a REST function, the URL to which the request is sent must be entered correctly for the REST function created in the tutorial to work properly. However, manually entering strings in the operations within a tutorial is time-consuming and increases the possibility of errors. Also, among the multiple steps (procedures) included in a tutorial, there are many parts that the user has already learned or understood, although they may not have fully mastered or understood them, and they would like to quickly complete these with a simple check. Even so, having to manually enter the correct information in the operations within a tutorial is time-consuming. Furthermore, if the user cannot proceed with the tutorial without entering the correct information, they may not know how to enter the correct information or what the correct information is, which could make it difficult to progress through the tutorial.

[0006] Therefore, in view of the above problems, the present invention aims to provide a mechanism that further improves the usability in tutorials. [Means for solving the problem]

[0007] The information processing system of the present invention is A display control means that, among the multiple steps included in the tutorial, indicates the input items in which the user should enter information in step 1, and controls the display of a copy item in the guide area that accepts instructions to copy the information to be entered into the input items, The copy target is copied in response to the operation of the copy item. A control means that controls the input of the copied item to the input item in response to a paste operation being performed on the input item, It is characterized by having the following features. [Effects of the Invention]

[0008] According to the present invention, usability in tutorials can be further improved. [Brief explanation of the drawing]

[0009] [Figure 1] This is a system configuration diagram of an information processing system. [Figure 2] This is a hardware block diagram of developer terminal 100, app user terminal 200, and app user terminal 201. [Figure 3] This is a flowchart of the login process. [Figure 4] This is a flowchart of the UI editor's processing. [Figure 5] This is an example of how login and UI editor processes are displayed. [Figure 6] This is an example of how tab components and the AppBar are displayed in a UI editor. [Figure 7] This is a flowchart of the context menu processing. [Figure 8] This is a flowchart of the action board processing. [Figure 9] This is an example display to explain the action board process. [Figure 10] This is an example of how the action board is displayed during processing. [Figure 11] This is an example of source code generated by development environment 300. [Figure 12] This is a flowchart of the screen switching process. [Figure 13] This is a flowchart of the tutorial process. [Figure 14] This is an example of the display during the tutorial process. [Figure 15] This is an example of the display during the tutorial process. [Figure 16] This is an example of the display during the tutorial process. [Modes for carrying out the invention]

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

[0011] Among the various feature items shown in the embodiments described below, they can be combined with each other. Note that, hereinafter, both "application" and "app" shall mean application software.

[0012] <System Configuration> FIG. 1 shows a system configuration diagram of an information processing system as an embodiment of the present invention. FIG. 1 shows a system for software development and a system for using the developed software.

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

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

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

[0016] The execution engine 302 is at least one hardware resource for executing processes to be run in the development environment 300, and includes a processor 303 and memory 304. The processor 303 consists of at least one processor, which may be a single processor on the cloud or a group of processors combined together. The memory 304 is at least one recording medium that stores the program to be executed by the processor 303. Among the various flowcharts described later, those described as being executed by the development environment 300 are executed by the execution engine 302. That is, this is achieved by the processor 303 loading the program stored in memory 304 into the work memory area of ​​the development environment 300 and executing it.

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

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

[0019] The developer accesses the development environment 300 by accessing a URL for the development environment 300 from the browser software on the developer terminal 100, and logs into the development environment. Upon logging into the development environment, the developer receives the client program 322 and the application definition (UI definition information), which is the content of the development work previously performed and saved, from the development environment. Then, the developer performs an operation to design a new application or an operation to design an update for an existing (work-in-progress) application, and sends the resulting application definition information (application definition, UI definition information) to the development environment 300. The development environment 300 saves the received application definition in its developer area. Thus, 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 applications. Therefore, as long as there is a terminal that can connect to the internet, developers can develop applications regardless of location.

[0020] The execution environment 400 is an environment built on a network (on the cloud, on the internet) using at least one hardware resource. The 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). The execution environment 400 is built by combining multiple web services (cloud services). The execution environment 400 is the environment where definition information (app definition) for applications developed using the developer terminal 100 and development environment 300 is deployed. App user terminals 200 and 201, used by users of the application, access the execution environment 400 by accessing a URL for application execution. The execution environment 400 then executes various actions in response to operations performed on the app user terminals 200 and 201, thereby running the developed application and providing the application's functionality to the app user. Applications built on the execution environment 400, which is located on the network, are so-called web applications.

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

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

[0023] The execution engine 412 is at least one hardware resource for executing processes to be run in the multi-tenant execution environment 410, and includes a processor 413 and memory 414. The processor 413 consists of at least one processor, which may be a single processor on the cloud or a group of processors combined together. The memory 414 is at least one recording medium that stores the program to be executed by the processor 413. Among the various flowcharts described later, those described as being executed by the multi-tenant execution environment 410 are executed by the execution engine 412. That is, this is achieved by the processor 413 loading the program stored in memory 414 into the work memory area of ​​the multi-tenant execution environment 410 and executing it. The program executed here includes a program that performs application actions.

[0024] The distribution engine 415 sends client programs 422 (such as HTML source code or JavaScript source code) to be executed on application user terminals 200 and 201 that have accessed the multi-tenant execution environment 410. The client programs 422 are pre-recorded in the storage 420 included in the execution environment 410.

[0025] 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, a predetermined area of ​​storage 420 (a predetermined folder, a predetermined bucket, a predetermined hierarchy) records access destination information 421 for accessing the execution environment (multitenant execution environment 410). It also has developer areas, which are storage areas for each developer account. For example, this includes developer A area 423 for developer A, developer B area 424 for developer B, and developer C area 425 for developer C. Each developer area stores definition information of applications developed by each developer and deployed from the development environment 300. For example, application definition 423a is recorded in developer A area 423.

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

[0027] Single-tenant execution environments 1(450), 2(460), and 3(470) are each dedicated execution environments for one developer (one developer account), and applications developed using development environment 300 by the owner developer are deployed to them. In this embodiment, for 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 way, 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, 471, execution engines 452, 462, 472, distribution engines 455, 465, 475, storage 456, 466, 476, and DB sets 457, 467, 477, respectively. These functions are similar to 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, except that they are dedicated to a single developer; therefore, a detailed explanation will be omitted. It is possible to build many more single-tenant execution environments than the three shown in the diagram.

[0028] Using the system shown in Figure 1, for example, the operator could provide the multi-tenant execution environment 410 to developers free of charge and the single-tenant execution environment for a fee. Both the multi-tenant execution environment 410 and each single-tenant execution environment require the system operator to pay maintenance costs to the resource and service providers (cloud service providers). By bearing the maintenance costs of the multi-tenant execution environment 410 and providing it free of charge to multiple developers, developers do not need to bear any costs for trial use of the system, making it more accessible to many developers and promoting its widespread adoption. The operator recovers costs by charging developers for the single-tenant execution environments.

[0029] There is a limit to the number of processing requests that can be handled per unit of time in a single execution environment. If many applications are built in a multi-tenant execution environment and many app users access it simultaneously, the requests may not be processed properly, potentially leading to slow application performance. In addition, there are some limitations on deploying and running many applications developed by many developers in a multi-tenant execution environment, and these limitations may prevent applications from achieving sufficient performance. Developers can avoid (or mitigate) these problems caused by the limitations of multi-tenant execution environments by owning a dedicated, single-tenant execution environment for a fee. In other words, by building applications in a single-tenant execution environment, it is possible to build applications that can achieve sufficient performance.

[0030] Taking into account the characteristics of both the multi-tenant single environment and the single-tenant execution environment, developers can utilize this system in the following ways. For example, when using this system for the first time, developers can build an application developed using this system in the multi-tenant execution environment 410 and test it. After determining that the system is beneficial to their software development, they can then purchase the single-tenant execution environment. Alternatively, when a developer is developing a specific application X, they can build an alpha version of application X in the multi-tenant execution environment 410 for a limited number of test users to try before releasing it to general users. There, they can test application X, make corrections, and continue development. After development is complete to a level where it can be released to general users without problems, they can build the production version of application X in the single-tenant execution environment and release it to general users. By using it in this way, developers can reduce development costs during the development period and operate applications that can be used by a large number of general users without problems.

[0031] 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 a developer terminal 100, an application user terminal 200, and an application user terminal 201. In Figure 2, the 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 the internal bus 150. Each part connected to the internal bus 150 is configured to exchange data with each other via the internal bus 150.

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

[0033] The image processing unit 104 performs various image processing operations 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, and captured images, based on the control of the CPU 101. The image processing operations performed by the image processing unit 104 include A / D conversion, D / A conversion, image data encoding, compression, decoding, resizing, noise reduction, and color conversion. The image processing unit 104 may be composed of dedicated circuit blocks for performing specific image processing operations. 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.

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

[0035] The operation unit 106 is an input device for receiving user input, including a keyboard and other text information input devices, a mouse and a touch panel, buttons, dials, joysticks, touch sensors, and a touchpad. The touch panel is a flat input device superimposed on the display 105, and outputs coordinate information corresponding to the position of contact.

[0036] The recording medium interface (I / F) 107 is capable of receiving recording media 108 such as memory cards, CDs, and DVDs, and, based on the control of the CPU 101, reads data from the received recording media 108 and writes data to the recording media 108. The external interface (I / F) 109 is an interface for connecting to external devices via wired or wireless cables and for inputting and outputting video and audio signals. The communication interface (I / F) 110 is an interface for communicating with external devices and the internet (I / F) 111 to send and receive various data such as files and commands. The developer terminal (I / F) 100 can communicate with the development environment (I / F) 300 on the internet (I / F) 111 using the communication interface (I / F) 110. The application user terminals (I / F) 200 and 201 can communicate with the execution environment (I / F) 400 on the internet (I / F) 111 using the communication interface (I / F) 110.

[0037] <Login process> Figures 3(a) and 3(b) show the flowchart of the login process. This process involves logging into the development environment 300 from the developer terminal 100 and displaying the UI editor. When the developer terminal 100 receives an instruction to launch the internet browser software and access the development system (application development platform) of this embodiment by specifying its URL, the process shown in Figure 3(a) begins. The process in Figure 3(a) is realized by the CPU 101 of the developer terminal 100 expanding the program recorded in the non-volatile memory 103 for executing the internet browser software and the client program 322 received from the development environment 300 into memory 102 and executing them. Hereafter, anything simply described as a process executed by the developer terminal 100 will be understood as the process by which the CPU 101 of the developer terminal 100 expands the program recorded in the non-volatile memory 103 for executing the internet browser software and the client program 322 received from the development environment 300 into memory 102 and executes them.

[0038] When a developer launches an internet browser on the developer terminal 100 and accesses the URL of the development system (application development platform) of this embodiment, the distribution engine 305 of the development environment 300 detects the access and sends the client program 322 to the developer terminal 100 that accessed it.

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

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

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

[0042] In S304, the developer terminal 100 accepts input operations for the developer ID and password input fields on the login screen. User 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 (username) is assumed to be an email address. The password used as the PIN is assumed to be an arbitrary string of characters, but other PIN information such as biometric authentication information (fingerprint authentication is information used for facial authentication) or pattern authentication information (information of a trajectory pattern entered on the screen) may also be used.

[0043] In S305, the developer terminal 100 determines whether an operation (e.g., a click) has been performed to instruct the new registration button on the login screen. Hereafter, operations that instruct a display item (a display object or item such as a button or icon) by clicking with the mouse included in the operation unit 106 or touching the touch panel will simply be referred to as "press". If the new registration button is pressed, proceed to S306; otherwise, proceed to S307.

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

[0045] 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; otherwise, it returns to S304.

[0046] In S308, the developer terminal 100 sends the information entered into the developer ID and password fields on the login screen (the entered developer ID and password) to the development environment 300 as login information. After transmission, the development environment 300 performs an authentication process, and the terminal waits for the result.

[0047] In S309, the developer terminal 100 determines whether or not 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 login information input again; otherwise, it proceeds to S310.

[0048] In S310, the developer terminal 100 determines whether or not it has received the execution environment list from the development environment 300. The development environment 300 sends the execution environment list to the developer terminal 100 if login authentication is successful, 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; otherwise, return to S309.

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

[0050] Figure 5(a) shows an example of the display of execution environment options in S311. In the example in Figure 5(a), two options are displayed as execution environments accessible to the logged-in developer: option 551, which corresponds to the multi-tenant execution environment 410, and option 552, which corresponds to the single-tenant execution environment. The developer user can select one of these options by clicking on it and confirm the selection by clicking the SAVE button 553. The option selected here is where the application updated in the following steps will be deployed during this login. Access to the execution environment is not performed at this point. The execution environment selected here can be changed through the operations described later.

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

[0052] 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 also sends it to the development environment 300. In response to receiving the information identifying the selected execution environment (selected environment), the development environment 300 sends information identifying all applications owned by the logged-in developer (applications that were previously created and recorded in storage 320) (such as the application ID and application name) as application information.

[0053] In S314, the developer terminal 100 determines whether or not it has received application information from the development environment 300. If it has received application information, it proceeds to S315; otherwise, it waits in S314 for the application information to be received.

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

[0055] 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; otherwise, it proceeds to S320.

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

[0057] In S318, the developer terminal 100 determines whether or not it has received definition information (UI definition information) for the selected application from the development environment 300. If it has received the definition information for the selected application, it records the received definition information in memory 102 and proceeds to S319; otherwise, it waits in S318 for the definition information to be received. In this embodiment, this definition information is assumed to be a JSON file in which various definitions related to the application are described in JSON format. Subsequently, when displaying information about the selected application on the display 105, the display is based on the definition information recorded in memory 102. When an operation to update the selected application is performed (for example, changing the arrangement of UI components) in the UI editor process described later, the definition information in memory 102 is updated to define the updated content. Then, when a save command is given, the latest definition information recorded in memory 102 is sent to the development environment 300 and saved in the logged-in developer area of ​​storage 320. In this way, the frequency of communication with the development environment 300 is suppressed, and the response time is prevented from decreasing due to communication, enabling comfortable update work.

[0058] In S319, the developer terminal 100 displays the UI editor screen on the display 105 and also displays information based on the received definition information. For example, it displays a canvas (UI screen editing area) with a shape that corresponds to whether the selected application is for desktop or not (i.e., a shape that corresponds to the type of device on which the application is used). For desktop applications, it displays a 16:9 rectangular canvas, and for mobile applications, it displays a vertically elongated canvas that mimics a smartphone. The submenu area (described later) displays a list of UI screens that the selected application has (belong to the selected application) (this process is strictly performed in S401 in Figure 4, described later). The canvas also displays components (UI parts placed on the UI screen) that are placed on the UI screen that is selected by default (the initial UI or the UI screen that was edited when it was last saved). Note that it is also possible not to select a UI screen to be edited by default and to not display anything on the canvas at this point. The login process ends in the S319 process and then proceeds to S401 in Figure 4.

[0059] Meanwhile, in S320, the developer terminal 100 determines whether the icon for creating a new application (the app creation button 1402 in Figure 14(a)) displayed on the screen showing the list of applications has been pressed, and whether the creation of a new application has been instructed. If it is determined that the creation of a new application has been instructed, the process proceeds to S321; otherwise, it proceeds to S350.

[0060] 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; otherwise, it proceeds to S316.

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

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

[0063] In S322, the developer terminal 100 displays a screen to accept input of basic application information (at least the application name and application ID) for the application to be newly created, and accepts input operations to set the application information. Upon receiving the application information, it sends the information received in S321 (whether it is for desktop (PC) or mobile) and the application information received in S322 to the development environment 300. In this way, the definition information for the newly created application is created in the storage 320 of the development environment 300, and the information of whether it is for desktop (PC) or mobile, the application name, and the application ID are recorded. The definition information for previously created applications also has the information of whether it is for desktop (PC) or mobile, the application name, and the application ID recorded in this manner.

[0064] In S323, the developer terminal 100 displays the UI editor screen as the 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, as selected in S321. The canvas is also displayed as blank information with no components placed on it. The login process ends in S323, and then the process proceeds to S401 in Figure 4.

[0065] Figure 3(b) shows the login process on the development environment 300 side, which works in conjunction with the login process on the developer terminal 100 side in Figure 3(a). The process in Figure 3(b) is realized when the processor 303 of the development environment 300 loads the program recorded in memory 304 into the work memory area of ​​the development environment 300 and executes it. Hereafter, processes that are simply described as being executed by the development environment 300 will be considered as being executed by the execution engine 302 of the development environment 300, or more specifically, by the processor 303.

[0066] In S331, the development environment 300 determines whether or not it has received the login information sent from the developer terminal 100 in S308. If the login information is received, it proceeds to S332; otherwise, it waits for the login information to be received.

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

[0068] In S333, the development environment 300 determines whether the login was successful (authentication was successful, authenticated, authentication OK) based on the authentication process in S332. If the login is OK, it proceeds to S335; otherwise, it proceeds to S334 and sends information indicating a login error to the developer terminal 100.

[0069] In S335, the development environment 300 sends a list of execution environments for logged-in developers (logged-in developers), which is included in the developer information 301, to the developer terminal 100. The developer information 301 records, for each developer, their email address (username, developer ID), password, and accessible execution environment IDs. Each execution environment ID is an account ID in the cloud service (web service), and in this embodiment, it is a 12-digit ID. For developers who can access multiple execution environments, the 12-digit execution environment IDs are recorded separated by commas. In S335, this accessible execution environment ID (one or more comma-separated execution environment IDs) for the logged-in developer is sent to the developer terminal 100. In other words, in S335, by referring to the developer information 301, the execution environments that the logged-in developer can access are identified. Thus, the execution environments that each developer can access (execution environments that each developer can use) are recorded in the developer information 301 recorded in the development environment 300. And these log-in execution environments can only be obtained by developers who have been successfully logged in. Furthermore, only the execution environments accessible to the developer who has been successfully logged in can be retrieved. This eliminates the need for developers to manage information for accessing their own accessible execution environments separately from the information for logging into development environment 300. It also helps deter other users from accessing the execution environment illegally.

[0070] 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; otherwise, it waits for the information identifying the selected execution environment to be received.

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

[0072] In S338, the development environment 300 retrieves app information from the logged-in developer's area of ​​storage 320, showing all applications owned (created) by the logged-in developer, and sends it to the developer terminal 100. The app information sent here includes 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 or information indicating actions described later).

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

[0074] In S340, the development environment 300 creates and records new application definition information in the area of ​​the storage 320 designated for the logged-in developer, based on the information about the new application received in S339. The definition information recorded here includes whether it is for desktop (PC) or mobile, the application name, and the application ID. In the development environment 300, to distinguish the application from other users' applications in the multi-tenant execution environment 410, the application ID is recorded with an 8-digit developer code uniquely corresponding to the developer ID of the developer who owns the application, prepended to the ID entered by the developer in S322. Then, the login process ends. Subsequently, when performing internal processing or displaying in a programming language on the action board, the application ID is used with the logged-in developer's developer code appended. When displaying the application ID in the UI editor, only the ID portion entered by the developer in S322 is displayed, excluding the developer code.

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

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

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

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

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

[0080] The Selected Execution Environment box 501 displays the Selected Execution Environment ID as information indicating the selected execution environment. By clicking the arrow icon on the far right of the Selected Execution Environment box 501, a list of execution environments accessible to the logged-in developer obtained from S310 is displayed as a pull-down menu, and the selected execution environment can be changed by selecting an arbitrary execution environment from the list. Even if the selected execution environment is changed, the selected application is not changed, and the contents displayed in the main menu area 510, submenu area 520, and canvas 530 remain unchanged. 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.

[0081] The selected app box 502 displays the name of the selected app as information indicating the selected app. By clicking the arrow icon on the far right 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.

[0082] The selected UI screen box 503 displays the name of the UI screen being edited on canvas 530, representing the UI screen currently being edited. 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 obtained in S318. By selecting any UI screen from the list, it is possible to change the UI screen to be edited and displayed on canvas 530.

[0083] The main menu area 510 displays the following selection icons as menu items for the main menu: App List button 511, UI Screen button 512, Workflow button 513, Settings button 514, Environment List button 515, Database button 516, File Manager button 517, User Management button 518, and Snapshot button 519. The processing that occurs when these selections are pressed will be described later in the screen switching process shown in Figure 12.

[0084] The submenu area 520 displays submenus corresponding to the item selected in the main menu. In the example in Figure 5(b), the UI component list (UI parts list) is displayed as a sub-hierarchical menu of the UI screen button 512.

[0085] Canvas 530 is the layout editing area for the selected UI screen of the selected application (the UI screen whose name is displayed in the selected UI screen box 503). The canvas 530 in Figure 5(b) is an example of how the canvas of a desktop application is displayed, and is shown in a desktop format. Users can select any UI component from the list of UI components displayed in the submenu area 520 and place it in the canvas area 530 by dragging and dropping. UI components placed in the canvas area 530 can be selected to adjust their size and position. Furthermore, by selecting a UI component placed in the canvas area 530 and right-clicking, more detailed settings such as color scheme can be made by selecting a property from the right-click menu (context menu) that appears. In addition, by selecting an action from the same context menu, an action board is displayed, and the action to be executed when that UI component is manipulated can be set. By right-clicking with the cursor in a blank area of ​​canvas 530, the canvas context menu can be displayed, and by selecting an action from there, the action to be executed when the UI screen of that canvas is loaded in the constructed application (executed when that UI screen is displayed) can be set.

[0086] Figure 5(b) shows an example of an application named "UI1" with a canvas 530 named "ui1" containing UI components: a pie chart 531, a button 532, text fields 533 and 534, an output field 535, and a tab component 536. The operation path 531a is a selection frame that indicates the selected UI component and is an operation path (operation handle) that accepts resizing instructions, indicating that the pie chart 531 is selected.

[0087] 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.

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

[0089] In S402, the developer terminal 100 determines whether or not an operation was performed to select any of the UI screens from the list of UI screens displayed in S401. If any UI screen is selected, proceed to S404; otherwise, proceed to S403.

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

[0091] In S404, the developer terminal 100 displays the UI screen selected in S402 on the canvas 530 based on the definition information of the selected application stored in memory 102. If the UI screen already has UI components placed on it, the UI components that were previously placed according to the definition information are displayed on the canvas 530. In other words, if a UI screen has been partially created in the past, development can continue from where it left off. If the UI screen selected in S402 is a newly created UI screen, the canvas 530 is displayed as a blank canvas with no UI components placed on it. If the UI screen selected in S402 is a pre-prepared UI screen (template screen), even if the user has not previously placed UI components on that UI screen, a template component with predefined actions is displayed in a predetermined position on the canvas 530.

[0092] In S405, the developer terminal 100 displays a list of UI components in the submenu area 520. That is, it switches from the UI screen list of the selected application to the display of the UI component list. UI components that can be placed on the canvas 530 include INPUT, Button, Display (information display component), Navigation, Layout, and Chart, with multiple UI components classified within each category. In the UI component list, first, a list of UI component types is displayed as shown in Figure 5(c), and when an operation is made to select one of the displayed types, the UI components classified under the selected type are expanded and displayed. Figure 5(b) above is an example where the option 522 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 UI components of the expanded type or options of other types) can be displayed by scrolling. As shown in Figure 5(b), when the expanded type selection 522 is manipulated, the expanded list of UI components of that type is collapsed, and the list of UI component types is displayed.

[0093] 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 a drag operation has been performed on the UI component displayed in the submenu area 520. If a UI component displayed in the submenu area 520 has been selected, the process proceeds to S407; otherwise, it proceeds to S411.

[0094] In S407, the developer terminal 100 determines whether or not an operation to specify a position on the canvas 530 has occurred. More specifically, it determines whether or not an operation to drop a dragged UI component onto the canvas 530 has occurred. If an operation to specify a position on the canvas 530 has occurred, the process proceeds to S408; otherwise, S407 waits for a position to be specified on the canvas 530. In this embodiment, a drag-and-drop example is described, but 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.

[0095] In S408, the developer terminal 100 determines whether the position on the canvas specified in S407 is included in the area of ​​an already placed tab component (a type of UI component). If it is not included in the tab component's area, the process proceeds to S409; if it is included in the tab component's area, the process proceeds to S410. The tab component is, for example, the tab component 536 shown in Figure 5(b). The tab component has multiple tabs (in the example in Figure 5(b), there are three tabs labeled ITEM1, ITEM2, and ITEM3), and depending on which tab is selected, the display content shown by the tab component is switched to the element screen corresponding to the selected tab.

[0096] The tab component will be explained using Figures 6(a) and 6(b). Figure 6(a) is an example of how the tab component 601 is displayed on the display 105 when it is placed on a canvas 530 displaying a different UI screen than 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 from the tab component's property settings. Tab property settings are performed in S706 of the context menu processing described later in Figure 7, where there is an operation to open the tab's property box from the tab's context menu, and the settings are performed on the tab's property box (settings screen) that is displayed accordingly. The element screen area 602, indicated by a dashed line (illustrated for illustrative purposes only and not displayed), is an area whose displayed content changes depending on the selected tab. The displayed content corresponding to each tab shown in the element screen area 602 is called the element screen corresponding to each tab. Different UI components can be placed in each element screen corresponding to each tab. The example in Figure 6(a) shows an example where tab 610 is selected and the element screen corresponding to tab 610 is displayed. In the illustrated example, UI components 611 and 612 are placed in the element screen corresponding to tab 610. The example in Figure 6(b) shows an example of the display when tab 620 is clicked from the state in Figure 6(a), and the selected tab changes from tab 610 to tab 620. In Figure 6(b), the element screen area 602 displays the element screen corresponding to the selected tab 620. In the illustrated example, UI component 621 is placed in the element screen corresponding to tab 620. In the examples shown in Figures 6(a) and 6(b), the definition information records at least the UI component ID (UI component identification information) of the tab component 601 and the position of the tab component 601 within the UI screen, associated with the ID (UI screen identification information) of the UI screen being edited on the canvas 530.Furthermore, the IDs of UI components 611 and 612, and their respective positions within the element screen of tab 610 are recorded, associated with the ID (element screen identification information) of tab 610 of tab component 601. Also, the ID of UI component 621 and its position within the element screen of tab 620 are recorded, associated with the ID of tab 620 of tab component 601. Return to the explanation of Figure 4.

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

[0098] In S410, the developer terminal 100 places the UI component selected in S406 from the submenu area 520 onto the element screen (currently displayed element screen) corresponding to the selected tab among the tab components at a specified position on the canvas 530, using the default size, and records the information defining this in the definition information stored in memory 102. Specifically, the definition information records the ID of the destination UI screen (the UI screen being edited), the type of UI component placed in S410, the ID of the tab component as the UI component ID, the ID of the tab that was selected in that tab component, the placement coordinates in the element screen corresponding to the selected tab, and the placement size, associating them with the ID of the destination UI screen (the UI screen being edited). In this way, in this embodiment, it is possible to place and lay out different UI components on each element screen corresponding to each tab of the tab component. Furthermore, at this time, it is not necessary to perform complex operations to define the tab of the element screen to which the UI component is placed; it is simply necessary to select and display the destination element screen when placing the UI component by dragging and dropping.

[0099] In S411, the developer terminal 100 determines whether a UI component placed on the canvas 530 has been selected by clicking or other means. If the placed UI component has been clicked (selected), the process proceeds to S412; otherwise, it proceeds to S415.

[0100] In S412, the developer terminal 100 displays the operation path for the UI component clicked in S411. Examples of operation path displays are the aforementioned operation path 531a and operation path 601a.

[0101] In S413, the developer terminal 100 determines whether the location specified by the click 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 an instruction area that instructs switching to the corresponding element screen.

[0102] In S414, the developer terminal 100 switches the display of the element screen area of ​​the tab component to the element screen corresponding to the tab at the position specified by the click in S411. For example, if one of the three tabs displayed as ITEM1, ITEM2, or ITEM3 of the tab component 536 is clicked in S411, S412 displays an operation path for the tab component 536 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 was as shown in Figure 6(a), the display switches to Figure 6(b) when tab 620 is specified. That is, UI components 611 and 612 that were placed on the element screen displayed before the click are hidden, and instead, UI component 621, which is placed on the element screen corresponding to the clicked tab 620, is displayed. This control is implemented to simplify the operation of defining the desired tab element screen when a developer wants to place other UI components on the element screen of a desired tab of the tab component. If a developer wants to place other UI components on the element screen of a desired tab of a tab component, they can simply click on the desired tab to display the desired element screen before dragging and dropping the UI components to be placed.

[0103] In this embodiment, for the sake of simplicity, the processes in S409, S410, S413, and S414 were explained using a tab component as an example, but this is not the only example. Even for UI components other than tab components, if a certain type of UI component has its display content switched in response to an operation on that UI component after the application has been built, the processes in S409, S410, S413, and S414 can be applied in the same way as for tab components.

[0104] On the other hand, in the case of UI components other than those of a predetermined type, such as tab components, the display content within the UI component is not switched in response to the selection of the UI component on the canvas 530. The only action performed in response to the selection of a UI component is the display of the operation path; no other actions are performed. For example, if button 532 is selected on canvas 530 in Figure 5(b), only the operation path is displayed, and the action of button 532 (the process executed when button 532 is pressed in the constructed application) is not performed. Similarly, if text field 533 is selected on canvas 530, only the operation path is displayed, and no processing such as displaying a text input cursor within text field 533 is performed.

[0105] Using Figures 6(c), 6(d), and 6(e), we will explain the AppBar as an example of a type of UI component to which the processing of S409, S410, S413, and S414 can be applied, similar to the tab component. Figure 6(c) shows an example where the UI components AppBar650, TextField661, and Button662 are placed on canvas 530. AppBar650 is a single UI component and contains element icons 651 and 652. Element icon 651 is a display item that accepts instructions to display a drawer menu in the constructed application. Element icon 652 is a display item that accepts instructions to display a popup menu in the constructed application. When the positions of element icons 651 and 652 of the placed AppBar650 on canvas 530 are clicked, the same control is applied as to the tab portion of the tab component. More details are provided below.

[0106] If the position of element icon 651 in the already placed AppBar 650 is clicked (Yes in S411), the operation path for AppBar 650 is displayed (S412), and if it is determined to be Yes in S413, the drawer menu as an element screen is displayed (S414). This transitions from the display state in Figure 6(c) to the display state in Figure 6(d). In Figure 6(d), the operation path 650a for AppBar 650 is displayed, and the drawer menu 651a, which is the element screen corresponding to element icon 651, is displayed. The drawer menu 651a is an area that is displayed by pulling it out 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 on 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 process described in S408 and S410 using a tab component as an example.

[0107] If the position of element icon 652 on the already placed AppBar 650 is clicked (Yes in S411), the operation path for AppBar 650 is displayed (S412), and if it is determined to be Yes in S413, a popup menu as an element screen is displayed (S414). This transitions from the display state in Figure 6(c) to the display state in Figure 6(e). In Figure 6(e), the operation path 650a for AppBar 650 is displayed, and the popup menu 652a, which is an element screen corresponding to element icon 652, is displayed. The popup menu 652a is an area displayed near element icon 652, and displays one or more menu items (options). With the popup menu 652a displayed, other UI components can be placed on the popup menu 652a by dragging other UI components from the submenu area 520 and dropping them onto the popup menu 652a, similar to the process described in S408 and S410 using a tab component as an example. Return to the explanation of Figure 4.

[0108] In S415, the developer terminal 100 determines whether or not an operation has occurred to drag a UI component already placed on the canvas 530. If an operation has occurred to drag a placed UI component, the process proceeds to S416; otherwise, it proceeds to S417. In S416, the developer terminal 100 changes the position where the dragged UI component (selected component) is placed in response to the drag operation. Specifically, it places it at the drop location. When the placement is changed, the definition information stored in memory 102 is also updated to reflect the changed position.

[0109] In S417, the developer terminal 100 determines whether or not 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; otherwise, it proceeds to S419. In S418, the developer terminal 100 changes the size of the UI component (selected component) to which the operation path was attached, according to the operation on the operation path. When the size is changed, the definition information stored in memory 102 is also updated to reflect the changed size.

[0110] In S419, the developer terminal 100 determines whether an instruction operation (a right-click of the mouse in this embodiment) has been performed to display a context menu in any area of ​​the canvas 530. If a right-click has been performed, the process proceeds to S420; otherwise, it proceeds to S421. In S420, a context menu (right-click menu) is displayed according to the position of the mouse cursor when a right-click occurred, 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 Figure 5(b), a context menu 540 related to button 532 (specified UI component) as shown in Figure 5(d) is displayed. The context menu 540 displays property 541, action 542, and erase 543 as selectable menu items. If property 541 is selected, a property box (detailed settings dialog) related to button 532 is displayed, allowing detailed settings such as the button name (label) to be displayed on button 532, the color of button 532, and the size specified by a numerical value. If action 542 is selected, an action board related to button 532 is displayed, and actions in the programming language JavaScript can be entered on the action board. The action entered here is the process that should be executed when button 532 (specified UI component) is pressed in the constructed application. If erase 543 is selected, button 532 will be erased (deleted) from canvas 530. Details of the context menu process will be described later using Figure 7.

[0111] 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; otherwise, it proceeds to S423. In S422, the developer terminal 100 sends 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 operation.

[0112] 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, it proceeds to S424; otherwise, it proceeds to S425. In S424, the developer terminal 100 performs a preview. In the preview process, the canvas 530 is hidden, and based on the definition information stored in memory 102 or the development environment 300, a preview is displayed of the UI screen being edited on the canvas 530 that looks the same as when the UI screen is viewed in the constructed application. In the preview, the operation paths for manipulating UI components are not displayed. In addition, some operations that are not performed on the UI editor screen (not performed when operating on the canvas 530) are performed in the preview. For example, when a UI component for screen transitions or a link is manipulated, the screen transition or transition to the link destination is performed. Operations such as moving the selection frame for an item using the keyboard's tab key are also performed. However, actions such as actions entered by the developer on the action board or database referencing are not performed. Consequently, the preview process can display the results faster than actually deploying and checking the application.

[0113] In S425, the developer terminal 100 determines whether the deploy button 506 has been pressed. If the deploy button 506 has been pressed, the process proceeds to S426; otherwise, it proceeds to S427. In S426, the developer terminal 100 sends a deployment request to the development environment 300 to instruct it to execute the deployment process. When the deploy button 506 is pressed and the deployment process is performed, the developer does not need to select the execution environment to which the application will be deployed. The deployment is performed to the pre-selected execution environment, which is displayed in the selected execution environment box 501. Developers often work by updating content to be deployed to a specific execution environment all at once. Therefore, in this system, the developer is prompted to select the execution environment to which the application will be deployed before selecting the application to be updated (S311 in Figure 3), and the developer is not prompted to select the execution environment each time an application is deployed. Thus, operational errors such as accidentally deploying to an unintended execution environment are suppressed, and the work can be made more efficient. Furthermore, although authentication is performed when logging into the development environment 300, there is no need to perform a separate account authentication operation for the execution environment to be deployed. Therefore, it is possible to prevent an increase in workload and work efficiently. In other words, the developer terminal 100 does not obtain authentication information regarding the target execution environment from the developer user.

[0114] In S427, the developer terminal 100 determines whether or not an operation to change the selected execution environment has occurred. Specifically, it determines whether or not an operation to change the selected execution environment has occurred in the selected execution environment box 501. If an operation to change the selected execution environment has occurred, the process proceeds to S428; otherwise, it proceeds to S429. In S428, the developer terminal 100 records information identifying the selected execution environment (such as the execution environment ID) as "Selected Execution Environment" in memory 102 and sends it to the development environment 300. It also updates the display content of the selected execution environment box 501 to reflect the changed selected execution environment. When the development environment 300 receives the information identifying the selected execution environment, it records the selected execution environment in a settings management file stored in the login developer area of ​​storage 320 based on that information.

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

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

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

[0118] <Context menu processing> Figure 7 shows a flowchart of the context menu processing. This process is a detailed flowchart of S420 in Figure 5.

[0119] 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, in S419, it determines whether the UI component specified by the mouse (specified UI component) when a right-click is received is a button. If it is a button, proceed to S710; otherwise, proceed to S702.

[0120] In S702, the developer terminal 100 determines whether the context menu to be displayed relates to the canvas. More specifically, in S419, it determines whether the position specified by the mouse when the right-click was received was an empty area of ​​the canvas 530 where no UI components were placed. If it was an empty area (i.e., the context menu to be displayed relates to the canvas), the terminal proceeds to S703; otherwise, it proceeds to S704.

[0121] In S703, the developer terminal 100 handles the context menu processing for the canvas.

[0122] 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, in S419, it determines whether the type of UI component (specified UI component) that was selected with the mouse when a right-click was received is a data grid. If it is a data grid, proceed to S705; otherwise, proceed to S706.

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

[0124] In S706, the developer terminal 100, as part of its other processing, displays a context menu related to the specified target corresponding to the specified location and performs processing according to the operation. Details are omitted.

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

[0126] In S711, the developer terminal 100 overlays the context menu for the button shown in Figure 5(d) near the specified position (mouse cursor position) as a context menu for the specified UI component.

[0127] In S712, the developer terminal 100 determines whether a property (property 541 in Figure 5(d)) has been selected from the options included in the context menu. If a property is selected, the process proceeds to S713; otherwise, it proceeds to S714.

[0128] In S713, the developer terminal 100 displays a property box for a 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, for example, detailed settings such as the button name (label) to be displayed on the specified UI component, the button color, and the size specified by a numerical value can be made. After making the settings and performing the apply operation, the specified UI component is displayed on the canvas 530 in a display format that reflects the settings.

[0129] In S714, the developer terminal 100 determines whether an action (property 542 in Figure 5(d)) has been selected from the options included in the context menu. If an action is selected, the process proceeds to S715; otherwise, it proceeds to S716.

[0130] In S715, the developer terminal 100 performs action board processing related to the designated UI component, which is a button. Action board processing will be described later using Figure 8.

[0131] In S716, the developer terminal 100 determines whether "erase" (erasure 543 in Figure 5(d)) has been selected from the options included in the context menu. If "erase" is selected, the process proceeds to S717; otherwise, it proceeds to S718.

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

[0133] In S718, the developer terminal 100 determines whether another option has been selected from the options included in the context menu. If another option is selected, the process proceeds to S719, where it performs the processing corresponding to the selected option. Otherwise, the process proceeds to S720.

[0134] In S720, the developer terminal 100 determines whether an operation to close the context menu has occurred (for example, clicking outside the area where the context menu is displayed). If an operation to close the context menu has occurred, the context menu is hidden and the process shown in Figure 7 is terminated. If no closing operation has occurred, the process returns to S712.

[0135] On the other hand, in S721, the developer terminal 100 overlays a context menu for the specified UI component, specifically for the template screen and for buttons, near the specified position (mouse cursor position). Unlike the context menu for the regular UI screen (the context menu 540 shown in Figure 5(d)), the context menu for the template screen does not display actions or delete options; only properties are displayed. In other words, for UI components placed on the template screen, the developer is prevented from setting the actions that occur when that UI component is manipulated.

[0136] In S722, the developer terminal 100 determines whether a property has been selected from the options included in the context menu. If a property is selected, the process proceeds to S723; otherwise, it proceeds to S724. The processing in S723 is the same as in S713.

[0137] In S724, the developer terminal 100 determines whether an operation to close the context menu has occurred (for example, clicking outside the area where the context menu is displayed). If an operation to close the context menu has occurred, the context menu is hidden and the process shown in Figure 7 is terminated. If no closing operation has occurred, the process returns to S722.

[0138] <Action Board Processing> This section explains the processing related to the action board. When you select an action from the context menu after specifying a UI component placed on the canvas, an action board is displayed for setting the action for the specified UI component. For example, consider the case where you are editing a UI screen as shown in Figure 9(a). Figure 9(a) is a diagram showing a part of the UI editor screen on display 105. In Figure 9(a), 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. The canvas 900 contains a UI component 901 which is a button, and other UI components. When UI component 901 is specified and an action option is selected from the context menu, an action board as shown in Figure 9(b) is displayed.

[0139] Figure 9(b) shows an example of the display of the action board for UI component 901. The action board 910 is displayed in the area where the canvas 900 was previously displayed, replacing the canvas. Unless it is a template component pre-placed on the template screen, and unless the developer has previously set an action for the specified UI component, the action board 910 will be displayed blank as shown in Figure 9(b). Note that the "1" displayed on the action board 910 is a guide indicating the row number and does not represent the content of the action. Developers can set any action on this action board 910 by operating the keyboard included in the operation unit 106 and entering any string in the programming language JavaScript. The trigger for executing the content set on the action board is predetermined: the specified UI component is operated. Therefore, developers do not need to set what the trigger for executing the action is (they do not need to write it in JavaScript). For example, if the specified UI component is a button, the trigger is when that button is pressed in the built application, and the action set on the button's action board is executed in response to the trigger.

[0140] In addition, along with the action board 910, the submenu area displays a list of functions 920 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 that instructs the display of the action board 910, and function options that instruct the display of each function. Functions created (added) by the developer (user) by pressing the function add button 921, described later, rather than pre-prepared functions, are referred to as custom functions (created functions, added functions, user-created functions). If there are no automatically created functions or pre-prepared functions, and the developer has not previously created a custom function for a specified UI component, the function list 920 will not display function options, as shown in Figure 9(b), and will only display the option 922 and the function add button 921.

[0141] When the Add Function button 921 is pressed, a dialog box for adding a custom function (referred to as the Add dialog 930) is displayed. Figure 9(c) shows an example of the Add dialog 930. The Add dialog 930 displays a Function Type selection field 931 for selecting the Function Type, a Function Name input field 932 for entering the Function Name, and a SAVE button 933. After input is made in the Add dialog and the SAVE button 933 is pressed, the function settings screen corresponding to the function type selected in the Function 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.

[0142] Figure 9(d) shows an example of the REST function settings screen displayed when REST is selected in the type selection field 931. Instead of the action board 910, the REST function settings screen 940 is displayed to accept various settings necessary to create a function using REST (REpresentational State Transfer) (REST function). In addition, the function list 920 displays 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 settings are not set on the function settings screen (if there is insufficient information to set), an incomplete mark 929 is displayed to indicate that the function is incomplete, and the corresponding function 923 is displayed in an incomplete state.

[0143] The REST function settings screen 940 in Figure 9(d) displays setting fields 941 to 944. Setting field 941 is the function name setting screen. Initially, the function name entered in the function name input field 932 is displayed, but it can be changed according to the developer's input. Setting field 942 is the setting field for setting the variable name for arguments. In this embodiment, "param" is set by default and cannot be changed. It is displayed in gray to indicate that it cannot be changed. Setting field 943 is the setting field for setting the type of REST function. By operating the triangular icon on the far right of this area, GET, POST, PUT, and DELETE will be displayed as options in the pull-down menu, and you can select one of these options to set it. The type set here is the type of request that this function makes. Setting field 944 is the setting field for the URL to which the request made by this function will be sent. Thus, when creating a REST function on the REST function settings screen 940, the developer does not need to write source code strings in a programming language.

[0144] Figures 10(a) to (d) further show examples of the settings screen for the creation function and the display of the action board. In Figure 10, the same reference numerals as in Figure 9 are used, and their explanations are omitted.

[0145] Figure 10(a) shows an example of the SQL function settings screen displayed when SQL is selected in the type selection field 931. Instead of the action board 910, the SQL function settings screen 950 is displayed to accept various settings necessary to create a function using SQL (Structured Query Language) (SQL function). In addition, the function list 920 displays 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 settings field 951 is the function name setting screen, and in the initial state, the function name entered in the function name input field 932 is displayed, but it can be changed according to the developer's input. The settings field 952 is a setting field for setting the variable name for setting arguments. In this embodiment, "param" is set by default and cannot be changed. It is displayed grayed out to indicate that it cannot be changed. The setting field 953 is an input field for entering a string of characters (SQL statement) that instructs the database using SQL, a type of computer language (a database language, not a programming language). Developers can enter any SQL statement into the setting field 953 using the keyboard included in the operation unit 106. In this way, when creating an SQL function on the SQL function setting screen 950, developers do not need to write source code strings in a programming language.

[0146] Figure 10(b) shows an example of the display after the developer has created custom functions 923-925, and has entered some JavaScript code (strings) into the action board 910, and then entered "sq". In this embodiment, when a developer user enters a string, if the entered string has a prefix match with the function name (identification information) of a previously created custom function, the function name that has a prefix match is displayed as an option in the code assist field 911. In the example shown, the entered "sq" has a prefix match with the function name "sql01" of the previously created custom function 924, so "sql01" is displayed as an option. When the user selects "sql01" displayed in the code assist field 911, "sql01" is entered into the action board 910 as shown in Figure 10(c), without the user having to enter "l01". This code assist function allows developers (users) to input the function name (identification information) of a custom function without having to type the entire name on the keyboard, thus reducing the number of steps required. Furthermore, if the entered function name matches a function name of an existing custom function, the full name will be displayed in the code assist field 911. If there is no match (i.e., if no function starts with that string), the code assist field 911 will not be displayed. Therefore, developers can confirm that they are entering the correct function name of an existing custom function, preventing input errors. If there are multiple custom functions that match the entered name, multiple options will be displayed in the code assist field 911. In addition, the function names of custom functions displayed in the code assist field 911 are those created for the specified UI component targeted by the action board 910 (UI component 901 in the illustrated example), and custom functions created for other UI components are not displayed. Therefore, it is possible to prevent the mistake of writing the function name of a custom function created for another UI component that does not exist as a custom function for the specified UI component on the action board 910.

[0147] Furthermore, as shown in Figure 10(c), along with the action board 910, the function list 920 displays the function type (icon before the string) and the function name for each of the custom functions 923 to 925 created by the developer. Therefore, the developer user can check what types and names of custom functions have been created while entering (writing) the action code (a string in JavaScript) into the action board 910. This reduces the effort required to check and manage valid custom functions that can be written on the action board 910 (for example, the effort of making a note of it or opening another screen to check). It also helps prevent input errors in function names. The functions displayed in the function list 920 are those created for the specified UI component targeted by the action board 910 (UI component 901 in the example shown), and custom functions created for other UI components are not displayed. Therefore, it is possible to prevent the mistake of writing the function name of a custom function created for another UI component that does not exist as a custom function for the specified UI component into the action board 910. Furthermore, custom functions are only effective when defining actions for a specified UI component and do not affect the definition of actions for other UI components. Therefore, if the function name of a custom function created for a specified UI component is the same as the function name of a custom function created for another UI component, even if that function name is written in 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 component will not be reflected. Therefore, even if the same function name as a custom function already created for another UI component is used, no error will occur. Thus, users can decide on a function name for a custom function and enter it in the action board 910 without worrying about duplication with custom functions already created for other UI components. In other words, although many custom functions will be created throughout the development of the application, they are automatically managed and organized in association with the specified UI component and displayed in the code assist field 911 and the function list 920, making it very easy for developers to manage many custom functions. Therefore, the effort and time required to check function names can be reduced.Furthermore, it helps to reduce input errors in function names. As a result, debugging work (debugging) required when input errors in function names are made can also be reduced. This reduces the workload and man-hours required for software development (application development), enabling more efficient software development (application development).

[0148] Figure 10(d) shows an example of how the action code will appear on the action board 910 after it has been entered in a programming language. In the example shown, the custom function "rest01" (function 923 in the function list 920) is used in the section indicated by the dotted line 960 on the third line. In the code string shown on the action board 910 in Figure 10(d), the details of the custom function rest01 are not defined. Also, when the developer sets up rest01 on the REST function setting screen 940, the details of rest01 are not defined in the programming language. When definition information including the definition of an action in this state is uploaded and saved to the development environment 300, the development environment 300, in the saving process, creates source code in a programming language, including the definition of the function in a programming language, from the uploaded definition information, based on the function settings and the string written on the action board 910, as a program for the execution environment. Thus, when the development environment 300 obtains a string containing the identification information (function name) of a custom function written in a programming language, it controls the system to enable the execution of the function (action) indicated by the string containing the function of the custom function (the action listed on the action board), based on the information set on the function settings screen.

[0149] Figure 11 shows an example of source code in a programming language generated by the development environment 300 based on the string written on the action board 910 in Figure 10(d) and the settings for rest01 configured on the REST function settings screen 940. Note that the numbers 1-75 on the left edge of the example are for line numbering purposes only and are not part of the source code. The example in Figure 11 is 75 lines of source code, including a detailed definition of rest01 in a programming language. However, the developer does not need to input 75 lines. By configuring the settings on the REST function settings screen 940 and writing the string of the amount shown (7 lines) on the action board 910 in Figure 10(d), the content of the source code shown in Figure 11 can be defined. In other words, efficient development can be performed using low-code.

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

[0151] In S801, the developer terminal 100 displays an action board on the display 105. If no action is defined for the specified UI component, it displays a screen containing a blank action board 910 as described in Figure 9(b). If an action is already defined for the specified UI component, it displays a screen containing an action board 910 with the action string entered, as described in Figure 10(d).

[0152] In S802, the developer terminal 100 determines whether or not 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 on the keyboard included in the operation unit 106 while the action board 910 is selected, or by touching the soft keyboard displayed on the touch panel. If an operation to describe an action has been performed, the process proceeds to S803; otherwise, it proceeds to S810.

[0153] In the S803, the developer terminal 100 accepts action input operations through actions that describe actions, and displays the entered characters on the action board 910.

[0154] In S804, the developer terminal 100 determines whether the string formed by the characters entered in S803 and the characters entered before it matches the function name of the created function (i.e., partially matches). If there is a match, proceed to S805; otherwise, proceed to S808.

[0155] In S805, the developer terminal 100 displays the function name of the custom function determined to match in S804 as an option in the code assist field. This displays the code assist field 911 as explained in Figure 10(b). Note that the code assist field 911 may also display function names that are commonly used in programming languages, in addition to custom functions, if they match the input string.

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

[0157] In S808, the developer terminal 100 determines whether the operation to describe the action has been performed again. If the operation to describe the action has been performed again, the process proceeds to S803; otherwise, it proceeds to S802.

[0158] In S810, the developer terminal 100 determines whether an operation to instruct the addition of a function has been performed. Specifically, it determines whether the function addition button 921 has been pressed. If the function addition button 921 has been pressed, the process proceeds to S811; otherwise, it proceeds to S820.

[0159] In S811, the developer terminal 100 displays an add dialog 930 for adding a custom function and accepts input for the add dialog 930. The content of the input accepted in the add dialog is as described above using Figure 9(c). Once input is made into the add dialog and the SAVE button 933 is pressed, the process proceeds to S812.

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

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

[0162] In S815, the developer terminal 100 determines whether the type selected in the type selection field 931 of the add dialog is SQL. If it is SQL, it proceeds to S816; otherwise (i.e., if the type selected in the type selection field 931 of the add dialog is REST), it proceeds to S817. In S816, the developer terminal 100 displays the SQL function settings screen and accepts setting operations from the developer user. The settings accepted on the SQL function settings screen are as described above using Figure 10(a).

[0163] In S817, the developer terminal 100 displays the REST function settings screen and accepts setting operations from the developer user. The settings accepted on the REST function settings screen are as described above using Figure 9(d).

[0164] In S818, the developer terminal 100 determines whether the input of the predetermined required setting items has been completed (whether the settings have been completed) on the function setting screen for each type. If the input of the required items has been completed, it proceeds to S819; otherwise, it proceeds to S802.

[0165] In S819, the developer terminal 100 hides the incomplete mark that was displayed in the function list 920 for the custom function being configured, as it corresponds to the function name. This allows the user (developer) to recognize that the custom function being configured is in a valid configuration state and can be used on the action board 910.

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

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

[0168] In S822, the developer terminal 100 records the contents of the action board processing performed so far in the definition information stored in memory 102, and also sends it to the development environment 300.

[0169] In S823, the developer terminal 100 determines whether option 922, which instructs the display of the action board 910 displayed in the function list 920, has been pressed. If option 922 is 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, the display switches to the action board. If option 922 is not pressed, the process proceeds to S824.

[0170] In S824, the developer terminal 100 determines whether or not an action board closing operation (an operation to terminate the action board processing) has occurred. If there is no action board closing operation, the process proceeds to S802 and is repeated. If an action board closing operation has occurred, the action board is hidden, the display switches to the canvas of the selected UI screen, and the process returns to the UI editor.

[0171] <Screen switching process> Figure 12 shows a flowchart of the screen switching process. This process corresponds to the selection of an option displayed in the main menu area 510 as described in the display example in Figure 5(b).

[0172] 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; otherwise, it proceeds to S1202.

[0173] 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; otherwise, it proceeds to S1204. In S1203, the UI editor processing shown in Figure 4 is performed.

[0174] 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; otherwise, it proceeds to S1206.

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

[0176] 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; otherwise, it proceeds to S1209.

[0177] In S1207, the developer terminal 100 displays the app settings screen. The app settings screen 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 stored in memory 102 based on the settings. Settings that can be accepted in S1208 include, for example, the display language setting and the setting of whether or not to build an app that can be used as a PWA (Progressive Web App). There is also a setting to determine which of the multiple UI screens belonging to the app will be the initial UI. The initial UI is the screen that is first displayed when accessing a built app deployed to the execution environment, or the screen that is first displayed after authentication is successful on the app's authentication screen after accessing a built app.

[0178] 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; otherwise, it proceeds to S1210.

[0179] 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; otherwise, it proceeds to S1215. Pressing the database button 516 is a request to connect to the database.

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

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

[0182] In S1213, the developer terminal 100 refers to the DB instance name recorded in the developer information of the logged-in developer (information registered for the logged-in developer from the developer information 301). Then, from the DB set 430 included in the multi-tenant execution environment 410, which is the execution environment selected by the development environment 300, it retrieves the contents recorded in the database of the DB instance indicated by the DB instance name obtained by referring to the developer information of the logged-in developer. Then, the development environment 300 sends the database information obtained from the selected execution environment to the developer terminal 100. The developer terminal 100 does not access the multi-tenant execution environment 410 without going through the development environment 300.

[0183] In S1214, the developer terminal 100 displays the database management screen and shows the database information obtained in S1212 or S1213. It then accepts DB management operations, such as various settings for the database of the selected execution environment and instructions to update its contents.

[0184] 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; otherwise, it proceeds to S1218.

[0185] In S1216, the developer terminal 100 displays a file management screen for managing files to be saved in the selected execution environment, and in S1217, it accepts operations for managing files to be saved in the selected execution environment. For example, image files to be displayed on the screen of the application being built can be uploaded and saved to the developer area of ​​the selected execution environment. When a file to be saved to the selected execution environment is selected from the local storage area (such as the storage medium 108) of the developer terminal 100 and a save command is issued, the developer terminal 100 sends the selected file to the development environment 300. Upon receiving the selected file, the development environment 300 sends it to the developer area of ​​the selected execution environment, thereby saving it to the selected execution environment. Various execution environments only accept access from the development environment 300. Therefore, for file management, the developer terminal 100 accesses various execution environments via the development environment 300. The developer terminal 100 does not access the multi-tenant execution environment 410 without going through the development environment 300. As explained in the login process above, developers need to authenticate and log in to development environment 300. Therefore, by restricting access to various execution environments to only through development environment 300, other users who cannot log in to development environment 300 cannot illegally access the execution environment, thereby improving security.

[0186] Furthermore, developer users only need to perform the authentication process required to log in to development environment 300, and do not need to perform the authentication process for each execution environment. This helps to reduce the number of operations required.

[0187] In S1218, the developer terminal 100 determines whether or not 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; otherwise, it proceeds to S1220.

[0188] In S1219, the developer terminal 100 performs user information display processing. User information display processing is the process of displaying user information (such as user information 411, 451, 461, 471 in each execution environment shown in Figure 1), which is information about application users (information managed separately from the developer) who can log in to the application built in the selected execution environment, and accepting management operations from the developer.

[0189] 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 the snapshot process; otherwise, the process proceeds to S1222.

[0190] In S1222, the developer terminal 100 determines whether or not a termination operation has been performed. If no termination operation has been performed, the process proceeds to S1201 and is repeated. If a termination operation has been performed, the screen switching process is terminated. <Tutorial Process> Figure 13 shows a flowchart of the tutorial process executed by the developer terminal 100. This process is a detailed description of the process at S351 in Figure 3. Figure 14(a) shows an example of the application list (app list) displayed on the display 105 by the process at S315. The app list displays two options, options 1403 and 1404, as app choices. The header menu area displays the tutorial button 1401 and the app creation button 1402. When the tutorial button 1401 is pressed, the tutorial process shown in Figure 13 begins. Note that the display destination for the various display processes in the tutorial process in Figure 13 is the display 105 of the developer terminal 100. Also, the various display examples are examples of only a part of the display 105, not the entire display.

[0191] In S1301, the developer terminal 100 displays a list of lessons. Figure 14(b) shows an example of the lesson list 1410 display. The tutorial contains multiple lessons. Each lesson contains multiple chapters, and each chapter contains multiple steps (procedures). In the example in Figure 14(b), five lessons, Lesson 1 to 5, are displayed in the lesson list 1410. When the downward arrow to the right of any of the displayed lessons is clicked, the multiple chapters included in the corresponding lesson are expanded and displayed. Figure 14(c) shows an example of the display when the multiple chapters included in Lesson 1 are expanded. 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 and chapters that have not yet been started are displayed in different colors so that they can be easily recognized. When the start button 1412 is pressed with any lesson selected, the tutorial for the selected lesson begins.

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

[0193] In S1303, the developer terminal 100 determines whether or not an operation to hide the lesson list 1410 (an operation to terminate the tutorial process) has occurred. If there is no termination operation, the process proceeds to S1302; if there is a termination operation, the tutorial process shown in Figure 13 is terminated.

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

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

[0196] In S1306, the developer terminal 100 initializes the variable S, which is a step number indicating the step (procedure) to be processed in the tutorial and is stored in memory 102, to 1.

[0197] In S1307, the developer terminal 100 determines whether the content of the tutorial to be displayed in the currently processed step, as indicated by the variables L, C, and S, includes the string "copy". The content of the tutorial to be displayed in each step of each tutorial for 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 referring to the client program 322 (client information) recorded in memory 102. If the processed step is a step that includes the string "copy", proceed to S1320; otherwise, proceed to S1308. Alternatively, if the step (procedure) requires a string to be entered in the input field to be more than a predetermined number of characters, proceed to S1330, and if the step (procedure) does not require a string to be entered in the input field to be less than a predetermined number of characters, proceed to S1308.

[0198] In S1308, the developer terminal 100 displays a guide in the tutorial for the step being processed. Figure 14(d) shows an example of the guide display in the tutorial. Figure 14(d) is an example of the guide display for Step 1 of Chapter 1 of Lesson 1. The app creation button 1402, which is the item to be operated on, is highlighted by graying out the other parts, and a callout 1420 (guide display area) that indicates (points to, identifies) the item to be operated on in the target step of the tutorial is superimposed. The callout 1420 displays the chapter guide 1421 indicating the current chapter, the guide message 1422 for the current step, and the exit button 1423. In the example in Figure 14(d), the guide message 1422 is displayed as "[Click the [Create App] button.]". Note that the item to be operated on varies depending on the step, and may be a button or an input item (such as a text box).

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

[0200] Figure 15(a) shows an example of how the guide display in the tutorial is shown when the item being operated on is an input item. Figure 15(a) is an example of the guide display for a step included in Chapter 1 of Lesson 1. The other parts are grayed out to highlight the input item 1501, and a callout 1520 (guide display area) pointing to the input item is superimposed. The input item 1501 is a text box for receiving the ID setting (input of a string that will be the ID) from the developer (user). The callout 1520 displays the guide message 1522 for the current step, the finish button 1523, and the next button 1524. In the example in Figure 15(a), the guide message 1522 is displayed as "[Enter the ID]. After entering, click the [Next] button." In other words, it displays guidance on what should be entered in the input item 1501. In Figure 15(a), the copy button is not displayed.

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

[0202] In S1312, the developer terminal 100 determines whether the "Next" button has been pressed or whether an operation on the target item has been performed. If the "Next" button has been pressed or an operation on the target item has been performed, the process proceeds to S1340; otherwise, it proceeds to S1313. For example, in the state shown in Figure 14(d), the process proceeds to S1340 if the app creation button 140 is pressed. Also, for example, in the state shown in Figure 15(a) or Figure 15(b), the process proceeds to S1340 if the "Next" button 1524 is pressed.

[0203] In S1313, the developer terminal 100 determines whether a skip button (for example, the skip button 1610 in Figure 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 is pressed, the process proceeds to S1314; otherwise, it proceeds to S1316. The skip button is displayed in a fixed position (a predetermined position on the surface, the same position) that does not change on the screen even as the steps progress, regardless of the display position of the item being operated on (i.e., regardless of the position of the callout displaying the guide). In this way, once the mouse hovers over the skip button, the mouse position remains fixed, and operations on the item being operated on in multiple steps included in the tutorial can be skipped consecutively. Therefore, when you want to quickly and easily review the content of multiple steps in the tutorial rather than going through the tutorial thoroughly, you can efficiently review the content of multiple steps in the tutorial.

[0204] In S1314, the developer terminal 100 inputs predetermined values ​​(various predetermined information) into the input fields. These 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 step of the tutorial without errors. For example, if the skip button is pressed in the state shown in Figure 15(a), an appropriate value (for example, the string "app_tutorial") as the ID of the newly created application is automatically entered into the input field. In other words, even if no input corresponding to user operation is provided in the input fields in S1310 and S1311, the appropriate information (value) is automatically entered when the skip button (skip item) is operated. If the operation target field is not an input field, S1314 automatically operates the operation target field (presses it if it's a button) and proceeds to S1340 without going through S1315.

[0205] In S1315, the developer terminal 100 displays the predetermined value automatically entered into the input field and determines whether a predetermined time (e.g., 2 seconds) has elapsed. If the predetermined time has elapsed, the process proceeds to S1340; otherwise, it waits for the predetermined time to elapse in S1315. In this way, the appropriate value automatically entered into the input field is displayed for a predetermined time. Therefore, even a developer user who pressed the skip button because they did not know what value to enter into the input field can confirm what value would have been appropriate. In this way, the developer user can learn how to use and operate this system more effectively.

[0206] In S1316, the developer terminal 100 determines whether an operation to terminate the tutorial has occurred (for example, pressing the exit button 1423). If an operation to terminate has occurred, the process in Figure 13 is terminated; otherwise, the process proceeds to S1310 and is repeated.

[0207] In S1340, the developer terminal 100 determines whether an error has occurred. If an error has occurred, it proceeds to S1941; otherwise, it proceeds to S1342.

[0208] In S1321, the developer terminal 100 returns to the step where the error occurred and displays a warning. For example, if, in the state shown in Figure 15(a), the input item 1501 is left blank and the Next button 1524 is pressed, and then in a later step in the tutorial, the confirmation button for creating the app, which is the target item, is pressed, an error occurs because there is no ID for the app to be created. In this case, the process returns to the step that displays Figure 15(a) (the variable S is set to the return step number), the input item 1501 that caused the error is highlighted (for example, displayed with a red frame), and the process proceeds to S1307 to repeat the step that displays Figure 15(a).

[0209] 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, proceed to S1324; otherwise, proceed to S1323.

[0210] 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 to process the next step in the tutorial. For example, in S1308, if the app creation button 1402, which is the target item, is pressed while the guide for step 1 of chapter 1 of lesson 1 as shown in Figure 14(d) is displayed, S1302 determines Yes, and it proceeds to S1320No, S1322No, and in S1323 it sets it to the next step in the same chapter 1, and then proceeds to S1307No, S1308. In S1308, the guide for step 2 of chapter 1 is displayed as shown in Figure 14(e).

[0211] 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 is terminated. Figure 15(c) shows an example of the tutorial guide display for the last step of the last chapter of Lesson 1. If the deploy button, which is the item to be operated on, is pressed in this state, S1324 is determined to be Yes, and the process in Figure 13 is terminated.

[0212] Furthermore, the actual development of the application is controlled based on the operations performed in the tutorial. In other words, pressing the deploy button in Figure 15(c) is equivalent to pressing the deploy button included in the confirmation screen that appears after pressing the deploy button in S425 of Figure 4, as mentioned above. Therefore, when the deploy button is pressed in Figure 15(c), the process in S426 is performed, and a deployment request is sent to the development environment 300 instructing it to deploy to the selected execution environment. In response, the development environment 300 actually deploys to the selected execution environment and builds the application. The definition information of the application newly created according to the tutorial is also saved in the development environment 300, and when the application list screen is displayed after completing Lesson 1, the application option 1530 created in the tutorial is added and displayed, as shown in Figure 15(d).

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

[0214] Meanwhile, in 1330, the developer terminal 100 displays a guide with a copy button in the tutorial for the step to be processed. Figure 16(a) shows an example of the guide display with a copy button in the tutorial. Other parts are grayed out to highlight the input target item 1601, and a callout 1620 (guide display area) that identifies (points to, indicates) the input target item 1601 is superimposed. The callout 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, and a copy button 1624 (copy item), which is an operation icon (display item) that instructs copying the string to be copied, is displayed. The string to be copied displayed in box 1626 is the same as a predetermined value that is automatically entered into the input target item 1601 when the skip button 1610 is pressed. In other words, these are values ​​(information) recorded step by step in the client program 322 (client information) stored in memory 102, and are correct values ​​(information) that allow the user to proceed to the next step of the tutorial without errors.

[0215] 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; otherwise, it proceeds to S1333.

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

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

[0218] In S1334, the developer terminal 100 inputs (pastes) the string copied to the clipboard into the input field 1601. As a result, if the copy button 1624 is pressed immediately afterward, the copied string (the string displayed in box 1626) is entered into the input field 1601.

[0219] The processing in S1340-S1346 is the same as that in S1310-S1316, so the explanation is omitted. Note that in S1341, it is also possible to enter an invalid value for the input field that is different from the string to be copied (for example, an incorrect URL). By intentionally accepting invalid values, it is possible to provide the user with the lesson that an error will occur in subsequent processing if they enter invalid information.

[0220] Figure 16(b) shows an example of how the text is displayed when the copy button 1624 is pressed and then pasted into the input field 1601, starting from the state in Figure 16(a), resulting in the copied text (the text displayed in box 1626) being entered into the input field 1601. In this way, the text to be entered in the tutorial can be easily entered. Even long texts can be easily entered without errors, ensuring that the correct text (the text copied when the copy button 1624 is pressed) is entered correctly.

[0221] Figures 16(a) and 16(b) are tutorials for the REST function settings screen described in Figure 9(d). This embodiment controls the execution of the application development software's functions based on the content entered in the input fields. Specifically, input field 1601 is the setting field 944 in Figure 9(d), which is the setting field for the URL to which the request made by this function will be sent. By entering a string indicating an appropriate URL as the destination for the request in input field 1601, a REST function that actually functions correctly can be created through the tutorial. If a string indicating an inappropriate URL (for example, a non-existent URL) is entered in input field 1601, the REST function generated in the tutorial will not function correctly and will cause an error. Manually entering a URL string without copying it is prone to typos and may result in an inappropriate string. In contrast, as in this embodiment, a copy button 1624 is displayed during the tutorial, allowing for easy copying of the appropriate string to send the request to, enabling simple, error-free, and reliable input.

[0222] Furthermore, a copy button that allows for easy copying of target text is also very effective in the aforementioned tutorial on action boards. Action boards allow users to enter text representing actions in JavaScript (a programming language). To guide developers through this in a tutorial and have them actually operate it, the input field would be the action board, and the developers would be asked to actually enter text representing actions in JavaScript into the action board. JavaScript text representing actions is long, making it time-consuming to input and prone to typos. Also, it's not easy for developers to immediately think of what kind of action to write, and having them consider what kind of action to write from the beginning would be too time-consuming for a tutorial. Therefore, if a pre-prepared JavaScript text representing an appropriate action could be copied using a copy button and pasted into the action board, it would greatly reduce the effort and errors while also serving the purpose of a tutorial that helps developers understand what an action board is. The same effect can be achieved by having the same text as the target text automatically entered and displayed in the action board when the skip button is pressed.

[0223] In this embodiment, an example showing both a skip button and a copy button is explained in the tutorial, but it is also possible to display only one of them. That is, either the process of automatically inputting a predetermined value into the input field by pressing the skip button, or the process of copying an appropriate string to be entered into the input field by pressing the copy button, may be performed.

[0224] Alternatively, even without displaying a copy button, it would suffice to simply display the appropriate string to be copied in the tutorial's guide area in a selectable and copyable format, as this is the intended input value (information) for the input field. Controlling the system so that the copied string is copied when the user selects the string displayed in the guide area and instructs the user to copy it, and then pasting the copied string into the input field, would also improve the usability of the tutorial.

[0225] Thus, in this embodiment, the usability of the tutorial can be further improved.

[0226] Furthermore, the various controls described in the flowcharts above may be performed by a single piece of hardware, or multiple pieces of hardware (for example, multiple processors or circuits) may share the processing to control the entire device. 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 that do not depart from the spirit of the invention are also included in the present invention. Moreover, each of the embodiments described above is merely one embodiment of the present invention, and it is also possible to combine each embodiment as appropriate.

[0227] (Other embodiments) The present invention can also be realized by performing the following process: supplying software (programs) that realize the functions of the embodiments described above to a system or device via a network or various storage media, and having the computer (or CPU, MPU, etc.) of that system or device read and execute the program code. In this case, the program and the storage medium storing the program constitute the present invention. [Explanation of symbols]

[0228] 100: Developer terminal, 200: App user terminal, 201: App user terminal 201, 300: Development environment, 400: Execution environment

Claims

1. A display control means that controls the display of items to skip steps in multiple steps included in the tutorial, showing the content of specific operations to be performed by the user, and In the above procedure, if the user performs a predetermined action, the system will proceed to the next step in the tutorial. In the above procedure, if the item is operated, a control means controls the process to proceed to the next step of the tutorial even without the user performing the predetermined operation, An information processing system characterized by having the following features.

2. The predetermined operation is an operation on a predetermined target item, The control means controls the procedure such that, if the item is operated, the tutorial proceeds to the next step, even if the user does not perform the predetermined operation, in the same way as if an operation had been performed on the target item. The information processing system according to claim 1, characterized by the above

3. The predetermined operation is an operation on a predetermined input target item, The control means controls the procedure such that, if the item is operated, the tutorial proceeds to the next step, even if the user does not perform the predetermined operation, in the same manner as if a predetermined input operation had been performed on the input target item. The information processing system according to claim 1, characterized by the above

4. The display control means controls the display of guidance in the guide area regarding the content to be entered into the input target item as part of the content of the specific operation. The information processing system according to claim 3, characterized by the following:

5. The display control means controls the display of the item to a position independent of the position of the guide area. The information processing system according to claim 4, characterized by the following:

6. The control means, when the item is operated, displays a state in which predetermined content has been entered into the input target item, and then controls the system to proceed to the next step of the tutorial. The information processing system according to claim 3, characterized by the following:

7. The control means, when the item is operated, controls the system to display for a predetermined time that a predetermined content has been entered into the input target item, and then proceed to the next step of the tutorial. The information processing system according to claim 3, characterized by the following:

8. The display control means controls the display of the items in the same position in multiple steps included in the tutorial. The information processing system according to claim 1, characterized by the following:

9. The display control means controls the display of the item to be shown in a position independent of the position of the input target item. The information processing system according to claim 3, characterized by the following:

10. The display control means controls the display of the item to be shown in a position independent of the position of the item to be operated on. The information processing system according to claim 2, characterized by the following:

11. The display control means further controls to show input target items in which the user should input information in a predetermined procedure among a plurality of procedures included in the tutorial, and to display copy items that accept instructions to copy the information to be entered into the input target items, The control means further controls the copying of the copy target in response to the operation of the copy item, and, when a paste operation is performed on the input target item, to input the copy target into the input target item. The information processing system according to claim 3, characterized by the following:

12. The display control means controls the display of the copy item during the predetermined procedure of the tutorial, and controls the display of guidance on what should be entered into the input target item during the second procedure of the tutorial that is not the predetermined procedure, without displaying the copy item. The information processing system according to claim 11, characterized by the following:

13. The aforementioned predetermined procedure is a procedure in the tutorial that satisfies the condition based on the number of characters in the string to be entered as information to be entered in the input target item. The information processing system according to claim 11, characterized by the following:

14. The control means can also control the input target item to input information different from the copy target item, in response to user operation. The information processing system according to claim 11, characterized by the following:

15. The control means controls the execution of the actual functions of the software targeted by the tutorial based on the predetermined operation. The information processing system according to claim 1, characterized by the following:

16. The predetermined operation is the same as or different from the specific operation. The information processing system according to claim 1, characterized by the following:

17. A display control step that controls the display of items to skip steps in multiple steps included in the tutorial, showing the content of specific actions to be performed by the user, and In the above procedure, if the user performs a predetermined action, the system will proceed to the next step in the tutorial. In the above procedure, if the item is operated, a control step is provided to control the process so that it proceeds to the next step of the tutorial even without the user performing the predetermined operation. A control method for an information processing system, characterized by having the following features.

18. A program for causing at least one computer to function as one of the means of an information processing system described in any one of claims 1 to 16.

Images