FR3047095B1 - SHORTCUT LINKS IN A GRAPHICAL INTERFACE - Google Patents

Abstract

Methods, systems and computer program products for providing a shortcut link in a graphical interface, GUI, of an electronic device for jumping at least one of multiple GUI screens is provided. This can be based on GUI statistics from a previous GUI visit. The statistics of the GUI concern at least one path including a sequence of GUI screens multiple GUI screens. The multiple GUIs may be displayed by switching from the current GUI screen to a GUI screen following multiple GUI screens in response to a user action, thus allowing a user to navigate through the GUI screens. A recent browsing history can be generated during a current GUI tour, based on the current GUI screen and potentially previous GUI screens displayed during the current GUI tour. At least one candidate path can be identified based on the recent browsing history and GUI statistics, including determining if the recent browsing history matches a subsequence of the at least one candidate path. A target GUI screen may be determined in the at least one candidate path, in which the target GUI screen is a GUI screen after the next GUI screen. The shortcut link may be set to point to the target GUI screen to cause the electronic device to switch to the target target GUI screen in response to a user who activates the shortcut link. The shortcut link can be displayed in the current GUI screen.

Description

SHORTCUT LINKS IN A GRAPHIC INTERFACE BACKGROUND

In general, the invention relates to electronic devices, for example computers, and software and, in particular, methods, systems and computer program products to provide a shortcut link in a graphical interface (a MISTLETOE).

[0002] A GUI viewed by an electronic device may have multiple screens to display to a user in a screen-by-screen manner when the user navigates through the GUI. Most often, the user will not need to access each of the multiple screens. Rather, in some cases, the user may require only a few of the multiple screens. However, the user may be led to browse one or more screen (s) that does not interest him, for the sole reason of finally reaching the desired screen of the GUI.

Improved devices, systems, methods and computer program products are therefore necessary to enable better navigation through a GUI. SUMMARY [0004] In one aspect, a method of providing a shortcut link in a graphical user interface, a GUI, of an electronic device for skipping at least one of the multiple GUI screens based on GUI statistics from a previous visit. GUI is provided. The statistics relate to at least one path (which has been traversed at least once during a previous visit) including a sequence of GUI screens of the multiple GUI screens. The electronic device is configured to display the multiple GUIs by switching from a current GUI screen to a GUI screen following multiple GUIs in response to a user action, allowing a user to navigate through the display screens. the graphical interface. The method includes the generation by the electronic device of a recent browsing history during a current GUI visit, based on the current GUI screen and potentially previous GUI screens displayed during the current visit of the GUI. MISTLETOE. The method further includes identifying, by the electronic device, at least one candidate path based on recent browsing history and GUI statistics. Identifying the at least one candidate path may include determining whether the Recent Navigation History corresponds to a sub-sequence of Tau minus a candidate path. The method further comprises determining, by the electronic device, a target GUI screen in at least one candidate path. The target GUI screen is a GUI screen after the next GUI screen. The method further includes establishing, by the electronic device, the shortcut link to point to the target GUI screen to cause the electronic device to change the GUI to the target GUI screen determined in response to a user who activate the shortcut link. The method further includes displaying, by the electronic device, the shortcut link on the current GUI screen.

In another aspect, a device is provided including a processor and a memory. The memory includes program code which, when executed by the processor, causes the apparatus to provide a shortcut link in a graphical interface, GUI, of the apparatus for skipping at least one of the multiple GUI displays based on statistics. GUI of a previous GUI visit. The statistics relate to at least one path (which has been traversed at least once during a previous visit) including a sequence of GUI screens of the multiple GUI screens. The apparatus is configured to display the multiple GUI screens by switching from the current GUI screen to a GUI screen following multiple GUI screens in response to a user action, thereby allowing the user to navigate the GUI screens. . The device is also required to generate a recent browsing history during a current GUI visit, based on the current GUI screen and potentially previous GUI screens displayed during the current GUI visit. The apparatus is further provided to identify at least one candidate path based on recent browsing history and GUI statistics. Identifying the at least one candidate path may include determining whether the Recent Navigation History corresponds to a sub-sequence of Tau minus a candidate path. The apparatus is further required to determine a target GUI screen in at least one candidate path. The target GUI screen is a GUI screen after the next GUI screen. The apparatus is further provided to establish the shortcut link to point to the target GUI screen to cause the apparatus to change the GUI to the target target GUI screen in response to a user who activates the shortcut link. . The device is also required to display the shortcut link on the current GUI screen.

In yet another aspect, a computer program product is provided that includes a computer-readable non-transitory storage medium including program code. The program code is configured for, when executed by a processor, causing the processor to provide a shortcut link in a graphical interface, GUI, of an electronic device for skipping at least one of the multiple GUI screens, based on statistics. the GUI of a previous GUI visit. The statistics relate to at least one path (which has been navigated at least once during a previous visit) including a sequence of GUI screens of the multiple GUIs. The electronic device is configured to display multiple GUIs by switching from a current GUI screen to a next GUI screen-multiple GUIs in response to user action, allowing a user to browse the screens. of the graphical interface. The processor is also required to generate a recent browsing history during a current GUI visit, based on the current GUI screen and potentially previous GUI screens displayed during the current GUI visit. The processor is further provided to identify at least one candidate path based on the recent browsing history and GUI statistics. Identifying the at least one candidate path may include determining whether the Recent Navigation History corresponds to a sub-sequence of Tau minus a candidate path. The processor is further required to determine a target GUI screen in at least one candidate path. The target GUI screen is a GUI screen after the next GUI screen. The processor is further provided to establish the shortcut link to point to the target GUI screen to cause the processor to change the GUI to the target target GUI screen in response to a user who activates the shortcut link. The processor is further required to display the shortcut link on the current GUI screen.

SUMMARY DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and, together with the general description of the invention given above, and the detailed description of the modes. embodiment below, serve to explain the embodiments of the invention.

[0008] FIG. 1 is a schematic representation of an exemplary computer system configured to perform the methods described herein.

[0009] FIG. 2A is a schematic representation of a stream for performing a reservation task of a hotel.

FIG. 2B is a schematic representation of a path with a start GUI screen, a current GUI screen, a next GUI screen, and a target GUI screen with a shortcut link provided to skip the next GUI screen.

FIG. 3A is a flow chart showing a process that can be executed, for example by the computer system shown in FIG.l, to implement the embodiments.

FIG. B is a flowchart representing a process that can be executed, for example by the computer system shown in FIG. 1, to implement other embodiments.

FIG. 4A is a schematic view of the paths of two flows of a GUI, including the GUIs.

FIG. 4B is a schematic view of two scenarios of a GUI.

FIG. 5 is a graph representing GUIs and paths. DETAILED DESCRIPTION [0016] The following detailed description relates to a method, an electronic device, an apparatus and a computer program product for providing at least one shortcut link in a graphical interface, GUI. Still other embodiments are specified by combinations of two or more of the following embodiments. The embodiments may be implemented by electronic devices, for example by simple electronic devices or by systems including at least one client electronic device and at least one server electronic device.

The graphical interface (GUI) consists of several GUI screens to allow a user to perform at least one task, for example a hotel reservation task. GUI screens can be defined in a GUI definition document (definition of the GUI), which could be maintained in the database of the electronic device or external to the electronic device, for example in a server accessible by via a network connection. The GUI definition can include GUI layout definitions. In addition, the GUI includes navigation definitions specifying for GUI screens the respective respective GUIs to be traversed in response to a respective user action thus defining the navigation behavior of the GUI. For example, navigation definitions can be included in the GUI definition document. Thus, based on a single document, the GUI definition document defines the appearance of the GUI as well as the behavior of the GUI with respect to navigating through the GUIs. Defining both the GUI layout and navigation mechanisms in a single GUI definition document (although it may include different files) reduces the development effort of GUIs and / or more compact and resource-efficient GUI definition The GUI definition may be processed by the electronic device to display GUIs and proceed to appropriate subsequent GUIs in response to respective actions of users.

When displayed, for example by the electronic device, some GUI screens may present information, such as a hotel address, to the user. Some other GUIs may provide input fields, such as buttons, text entry fields, selection fields, or the like, for receiving user input. Some other GUIs can both present information and provide one or more input fields.

For example, the GUI can be web oriented, namely the GUI screens are configured to be searchable by a web browser. For example, the GUI definition document can be formulated including HTML 4.01 code. A shortcut link can be represented by a graphic element displayed in a GUI screen. Graphic elements can be HTML elements that can receive attention, for example a button.

The electronic device can display the multiple GUI screens by switching from the graphical interface of a current GUI screen to a next GUI screen selected from the multiple GUI screens in response to a user action. This allows a user to browse the GUI screen by screen. The terms "navigation through the GUI" and "navigation through GUIs" have the same meaning here and must be understood in the sense that the user visits some or all GUI screens when visiting the interface graphic. The expression "browse a path" means that the user navigates along a (full) path, ie the user navigates screen by screen along the GUI screen sequence of the path. However, using shortcut links to skip some GUI screens from the path must also be understood as "walking a path". The GUI provides at least one navigation path through the GUI unless otherwise noted. A path includes a sequence of GUI screens. In what follows, the expression "a path includes a GUI screen" must be understood in the sense that the GUI screen is included in the sequence of GUI screens of the path.

[0021] Providing a shortcut link in a GUI allows a user to jump at least one GUI screen as he navigates through the GUI. A shortcut link points to a target GUI screen, which means that the shortcut link provides a reference to the target GUI screen, and thus allows the user to skip one or more of the following GUI screens that user by necessity must browse to finally arrive at the desired target GUI screen.

As a result, the shortcut link allows the user to immediately jump to the target GUI screen.

To provide a shortcut link, the context of the current navigation (ie, where is the current GUI screen and how the user has navigated to the current GUI screen during the current visit of the GUI) should be considered. Therefore, a sequence of GUI screens visited so far during the current GUI visit can be collected as a recent browsing history. The current context makes it possible to determine possible candidate GUI screens to which the user is allowed to jump in the context of the current context. Therefore, candidate paths are identified based on the recent browsing history. A candidate path can be considered as a path that is compatible with the recent browsing history. In other words, the candidate paths can be considered as those paths that the user can take in the context of the current context. However, there may be other limitations as described below. Possible target candidate GUI screens should only be found on candidate paths.

In addition, to provide a shortcut link, the habits of the user must be considered. Therefore, the identification of the candidate paths is also based on GUI statistics acquired during previous visits of the GUI (by the current user or, in some examples, by any user). GUI statistics include information about the typical browsing behavior of users. For example, this may reduce the number of candidate paths and / or determine a ranking of preferred candidate paths. GUI statistics relate to paths that have been visited during previous GUI visits; for example, GUI statistics may include information about how often a path has been traveled during previous visits.

In addition, since the shortcut link should provide a "real" shortcut, namely should allow the user to jump (ie bypass directly) at least one subsequent GUI screen, the GUI target screen can be a screen after a next screen of the GUI from the point of view of the current GUI screen. The shortcut link, or in some embodiments of multiple shortcut links, is displayed in the current GUI screen and provides a link to a respective target GUI screen. Enabling the shortcut link causes the GUI, for example by the electronic device, to (directly) switch from the current GUI screen to the target GUI screen and, thus, allows the user to skip at least one next GUI screen.

Some embodiments further include pre-loading at least one target GUI screen, for example to reduce the response time to display a target GUI screen when the user activates a shortcut link. Preload refers to loading a target GUI screen before the user activates a shortcut link that corresponds to the target GUI screen. For example, pre-loading a target GUI screen includes storing the target GUI screen in a cache memory. Pre-loading the target GUI screen may include reading the layout of the GUI target screen from the GUI definition.

Therefore, the methods and devices described herein allow to provide shortcut links according to a current context and GUI statistics. This means that if a new user starts using the GUI for the first time, the user will not receive any proposals based on their own habits; however, in some embodiments described below, the user may benefit from proposals based on the habits of other users (having previously visited the GUI) and / or proposals specific to his role or to a category or group the user is associated with. In some embodiments, the determination of the target GUI screen may include, for example based on a cost function, the balancing of the probability that a user can use the shortcut link to access the GUI screen. target with the number of GUI screens skipped. Indeed, even if it is less likely that a user decides to make a long-range jump by using a shortcut link, a shortcut link that allows you to skip more GUI screens and / or user input. to navigate through the GUI may be of more interest. As a result, the cost function can be based on the number of GUI screens skipped during the activation of the shortcut link and a probability of the target GUI screen having been visited during previous GUI visits as part of the current context. A shortcut link proposal (s) can depend on the context, for example of the current GUI screen, a stream and / or a scenario in which the user is located currently. As described in more detail below, a stream includes at least one path associated with a task and a scenario includes at least two or more streams to allow a user to perform a complex task that includes two or more tasks.

The GUI may allow the user to perform at least one task (for example using the electronic device). Examples of tasks could be the creation of a reservation or the booking of a trip, a hotel, a flight or a car, for example. The GUI can provide different ways and / or different options for performing a task. Therefore, multiple paths through the GUI can be associated with the task. In other words, the graphical interface can provide several paths (ie different sequences of GUI screens to be successively visited by the user) to perform the same task.

For example, the task of booking a hotel may include booking a hotel for one person or otherwise booking the hotel for two people. Therefore, the GUI can include a feed to perform the task of booking a hotel. The stream includes a first path including at least one GUI screen for entering data from a single person and a second path including at least two GUI screens, namely at least one GUI screen for each person.

[0029] Referring now to FIG. 2A, a diagram is shown which illustrates an example of flow 100 to reserve the hotel. Starting from the GUI screen 110, the user can either navigate along a first path to the GUI screen 120 or along a second path on the GUI screen 130. The GUI screen 110 may provide a input field to allow the user to choose whether to book the hotel for one person or two people.

By selecting "single person", the user navigates along a first path to the GUI screen 120, which provides input fields to the user to enter a desired room category. After completing the required data in the input fields of the GUI screen 120, the user accesses the (only possible) next screen GUI 121 to enter the period that the user wants to stay at the hotel. Subsequently, the user can access the (only possible) next screen GUI 150 to make the payment of the reserved hotel.

By selecting "two people" in the GUI screen 110, the user navigates along a second path to the GUI screen 130 which provides input fields to the user to enter a desired room category. for the first person. As with the first path, futiizer can access the next screen GUI 131 to enter the period during which the first person wants to stay at the hotel. Then, the user can access the next GUI screen 132 to enter a desired room category for the second person and then the user can access the next GUI screen 133 to enter the period during which the second person wants to stay. Continuing to navigate along the second path, the second path meets at the first path in the GUI screen 150 to make the payment. However, according to GUI statistics the GUI "knows" from first visits from users that many times two people may want to share a room. Therefore, the GUI provides a shortcut link 140 in the GUI screen 131 to skip the GUI screens 132 and 133. By activating the shortcut link 140, the user can navigate directly to the GUI screen 150 to pay. This allows the user to skip the GUI screens 132 and 131. To sum up, the stream 100 provides two paths to completely complete the task of booking a hotel. Both paths offer alternatives in terms of the number of people staying at the hotel. So much for the FIG. 2A.

Another example of a task could be the configuration of a network router device (router). This task can be performed by a network administrator. For example, the task may include configuring the router for a single subnet, or, alternatively, configuring the router for multiple virtual networks. Therefore, the GUI corresponding to the task of configuring the router can provide a first path including (inter alia) a GUI screen for input, for example a single subnet mask and a single gateway address, and a second one. path, including (inter alia) at least two GUI screens for entering a first subnet mask and a first gateway address in a first GUI screen and a second subnet mask and a second gateway address in a second GUI screen, and / or a third path, including (inter alia) a single GUI screen for entering at least two subnet masks and gateway addresses, for example.

Another example of a task could be the configuration of a printer in an operating system of a computer. This task can be performed by an administrator of the computer or by a user of the same computer, for example. The job may include configuring a single paper cassette of a printer, or, alternatively, configuring multiple paper trays of the printer. Therefore, the GUI corresponding to the printer configuration task can provide a first path, including (inter alia) a GUI screen to enter, for example a paper size and paper orientation of a single cassette of paper, and a second path, including (inter alia) art-less two GUI screens to enter a first paper size and paper orientation in a first GUI screen and a second paper size and paper orientation in a second GUI screen, and / or a third path, including (inter alia) a single GUI screen for entering a first paper size and a first paper orientation and a second paper size and a second paper orientation, for example.

In some embodiments, the GUI to perform a particular task has only one path to perform this task, namely each GUI has exactly one GUI screen. However, even in such an embodiment, the shortcut link may allow one or more GUI screens to be skipped while navigating along the path. Preferably, the GUI has multiple paths, which allows the user to navigate along different (alternative) paths through the GUI. In some embodiments, at least one path, preferably each path includes a subset of all available GUIs, ie the task can be completed by the user without having to visit all GUIs. In some embodiments, at least one path, preferably each path comprises a respective sequence of GUIs that is sufficient to perform a task completely, namely, to perform the task from the beginning of the task to completion. of the task. Thus, each of the at least two paths alone can allow the user to perform completely the same task, for example the booking of a hotel; however, they can provide different options or features to the user.

To accomplish a task, a flow of the GUI can be defined. A feed can include one or more paths associated with the job. In some embodiments, a stream includes all the paths associated with the same task. For example, the multiple paths of the stream may provide other means, namely different GUI screen sequences to accomplish the task. In addition, or alternatively, one or more paths in the stream may provide options for the task.

In some embodiments, each path per se may allow the user to perform a task from the beginning of the task until completion of the task. With respect to the previous example of hotel reservation, a flow to book the hotel may include the first, second and third paths, in which each of these paths per se allows the user to make the reservation in different ways, for example, with different options for booking, payment or delivery. This applies in parallel to the examples of router configuration and printer setup tasks.

In some embodiments, the GUI may include at least one scenario that includes at least two streams. A scenario can be considered as a combination or sequence of flows. The GUI can allow the user to perform a complex task that includes multiple individual tasks based on a respective scenario. For example, a scenario may allow the user to book a trip. In this example, booking a trip is a complex task, for example including individual tasks of booking a flight, booking a hotel and booking a car. As a result, the scenario in this example includes a first feed for booking the flight, a second feed for the hotel reservation and a third feed for the booking of the car. Each of these streams can include one or more paths.

In some embodiments a current stream and / or a current scenario (ie a stream and / or a scenario a user currently visiting the GUI is browsing) is (automatically) identified by the system. For example, if a scenario has been identified, the user's entries may be recorded in a first stream and the registered user's entries may be used to pre-populate input fields of a second stream of that user. scenario, since the first as well as the second stream are associated with the same complex task. For example, a user's home address data may be required for the task of booking the flight as well as for the booking task of the hotel and the car. Thus, in some embodiments the GUI may display information that at least one subsequent GUI screen is pre-filled. This allows the user to skip pre-filled GUI screens by activating a shortcut link if the user does not wish to make changes in the next pre-filled GUI screen (s) .

The GUI can provide more than one possible next GUI screen (directly adjacent) for a current GUI screen. This allows the user to choose on the current GUI screen if he wants to proceed to navigation on a first GUI screen or a second GUI screen next. For paths, a first path may include the current GUI screen and the next GUI screen, and a second path may include the current GUI screen and the second GUI screen. However, the path along which the user navigates depends on the action of the user on the current GUI screen. For a current GUI screen, in response to a first (Futiiizer) action, the GUI will move to the next GUI screen and in response to a second (user) action, the GUI will switch to the second GUI screen different from the first screen MISTLETOE. In some embodiments, multiple different (user) actions may cause the GUI to switch to the same next GUI screen. Therefore, in some embodiments, at least two (different) actions sequences (of the user) may lead to navigation along the same path in the GUI.

Paths can be described explicitly in a definition of the graphical interface. A path may include a set of rules specifying for each GUI screen the path of respective future GUI screens. In addition, the path may further include rules specifying for each pair of current GUI screen and next GUI screen at least one action (of the user) in response to which the GUI must be passed from the respective GUI screen on the respective next GUI screen.

However, in some embodiments, a path may not be (explicitly) included, for example, predefined or pre-encoded, in the GUI definition of a newly created GUI. For example, a definition of the graphical interface may include for each screen information about the actions (of the user) leading to the next respective GUI screens. Thus, the creator of the GUI does not have to consider (and explicitly define) every possible path through the GUI. Paths can be indirectly defined by rules to change between GUI screens, for example in a GUI definition. Therefore, in the present description, any operation with respect to a path may be based on data implicitly and / or explicitly indicating the path in the GUI definition and / or the GUI statistics and / or in the recent browsing history. Data explicitly indicating a path can be obtained by recording a sequence of GUI screens displayed in response to actions of a user navigating through the GUI. Additionally or alternatively, such data can be obtained from records of previous GUI visits. In addition or alternatively, such data can be obtained from rules to change between the GUI screens.

[0042] Preferably, a shortcut link provides a "real" shortcut, which means that by activating the shortcut link at least one subsequent GUI screen after the current screen will be ignored. Therefore, in some embodiments, a path includes at least three GUIs, namely a current GUI screen, a target GUI screen, and a next GUI screen between the current GUI screen and the target GUI screen. Preferably, a path includes at least four GUIs, namely a starting GUI screen, the current GUI screen, a next GUI screen, and a target GUI screen.

As for the omission of GUI screens when browsing through the GUI, a user may not be obliged to visit each GUI screen of a path to complete a task. For example, when booking a hotel, the user may or may not wish to specify a particular room. As a result, the graphical interface can provide at least one shortcut link to jump at least one GUI screen. Regarding the previous example, if the user does not want to specify a particular room, he can jump, by clicking on the shortcut link, the GUI screens providing information about available rooms and / or providing fields enter the user to select one of the available rooms. This reduces the effort and time of the user to perform the task, as well as, for example, the computing resources of the electronic device necessary to process the user's inputs to perform the task. Reducing the number of GUI screens visited to complete the task may also result in a reduction in network traffic in a client / server scenario, for example, if the GUI screens are retrieved from a remote web server.

As mentioned earlier, providing the shortcut link is based on statistics of the GUI of one or more previous GUI visits. For example, if a user has performed a task using a particular path during a previous visit, the user will probably perform this operation in the same way, ie by using the same path during a subsequent GUI visit. This information can be collected in the GUI statistics. For example, the statistics of the GUI can concern GUI paths (previously visited). However, in some embodiments, the GUI statistics do not include (immediately) information about each possible GUI path. For example, before the very first visit of the GUI, the statistics of the GUI can even be empty. When a path of the GUI is navigated for the first time, the respective information representing the path can be added to the statistics of the GUI. In addition to this, information on the frequency with which a path has been traveled during previous visits can be added to the statistics of the GUI. This information can be updated whenever a path is traveled. This allows the GUI to learn the browsing behavior of users. A path for which GUI statistics do not (yet) include information may be assumed to have a zero value for its frequency during previous visits.

One or more GUI screens (additional) may be added to the definition of the GUI and / or one or more screens GUI (existing) can be removed from (s) the definition of the GUI, for example due to further development or improvement of the overall GUI. Also the navigation behavior of the GUI can be changed, ie existing paths can be added, deleted or modified. In order to reuse the information collected until now by the GUI statistics as much as possible, information concerning the paths that are not affected by this adaptation of the GUI definition are kept in the GUI statistics, in certain modes. of realization. Information about an affected path can be flushed from the GUI statistics because the old statistics for the affected path have become obsolete. For example, GUI statistics may include only information about paths affected by the addition / removal of a GUI screen collected after the GUI screen was added or removed from the GUI definition. .

In some embodiments, a path is affected by the addition and / or deletion of a GUI screen if the added / deleted GUI screen is / has been included in the GUI screen sequence of the path. For example, all paths passing through the added / deleted GUI screen are affected paths, ie the information with respect to these paths can be cleared of the GUI statistics.

In some embodiments, a path including a directly predecessor GUI screen of an added / deleted GUI screen is an assigned path. A GUI directly predecessor screen of an added / deleted GUI screen is a GUI screen that is arranged directly before the added / deleted GUI screen along the GUI screen sequence of one or more (possibly further) paths . In other words, in these embodiments, a path may be affected by adding / removing a GUI screen, even if it does not include the added / deleted GUI screen, but includes a GUI screen. which is a predecessor of the added / deleted GUI screen along another path (which includes the added / deleted GUI screen). This allows to consider that a user's navigation behavior may change when navigating around the added / deleted GUI screen; in this example, when navigating through the predecessor GUI screen of an added / deleted GUI screen.

In some embodiments, a path including a second order, a third order or, for example, a higher order GUI screen predecessor of an added / deleted GUI screen is defined as an assigned path. A second-order predecessor GUI screen is a GUI screen with a GUI screen between itself and the added / deleted GUI screen along the GUI screen sequence of a GUI path. As a result, a third-order predecessor GUI screen is a GUI screen with two other GUI screens between itself and the added / deleted GUI screen along the GUI screen sequence of a GUI path.

Maintaining the statistics of the GUI thus for paths that are not particularly affected by a change in the GUI (for example due to an addition or removal of GUI screens) allows a dynamic offer of continuous links of useful shorthand even in situations of a GUI change, while a removal of all GUI statistics would require a collection of new GUI statistics until useful shortcut links can be calculated and displayed again.

To determine appropriate target GUI screens, the knowledge on the behavior of the user contained in the GUI statistics and the current context (navigation) of the user during his current visit are taken into consideration. During the current visit, the user may or may not have already navigated through some of the GUI screens before arriving at a current GUI screen. This information is collected by the recent browsing history, which is generated, for example by the electronic device, for the current visit of the user of the GUI. The recent browsing history may include (at least) the current GUI screen and (optionally) one or more, preferably all GUI screens visited until then during the current GUI visit. In other words, the recent browsing history may include a subsequence or the (complete) sequence of GUIs that the user visited during his current GUI visit. Therefore, the recent browsing history can be considered as a sub-path of the GUI, including at least the current GUI screen and, optionally, including one or more GUI screens before the current GUI screen. The recent browsing history may represent the current context of the user navigating through the GUI. The recent browsing history can be reset (eg emptied) at the beginning of a GUI tour and / or when a start GUI screen becomes the current GUI screen. The recent browsing history can be reset when navigating to a next stream and / or a subsequent scenario.

Not all GUI screens constitute appropriate target GUI screens. Since the shortcut link preferably provides a shortcut over a current path, the target GUI screen must be found on the same path, which also includes the current GUI screen. Therefore, a candidate path can be identified based on the recent browsing history. For example, identifying a candidate path may include determining if a path includes the recent browsing history as a subpath. In other words, the GUI screen sequence of a candidate path may include the GUI screen sequence of the recent browsing history as a subsequence. This means that the user may not leave the path he has taken so far by activating a shortcut link.

As previously described, a shortcut link should provide a "real" shortcut, which means that using the shortcut link at least one next GUI screen after the current GUI screen should be ignored. Therefore, a target GUI screen is a GUI screen after the next GUI screen (s) along a candidate path. This is illustrated in FIG. 2B showing a single path 200 of a GUI. The access path 200 includes a GUI screen sequence: a start GUI screen 210, a current GUI screen 220, a next GUI screen 230, and a target GUI screen 240 in that order. Starting from the departure GUI screen 210, the user can navigate along the path 200 and arrive at the current GUI screen 220. According to the GUI screen sequence of the path 200, in the direction of the trajectory 200, the The following GUI screen 230 is (directly) after the current GUI screen 220. The GUI provides a shortcut link 221 displayed in the current GUI screen 220. The shortcut link points to the target GUI screen 240. This allows the user to directly access the target GUI screen 240 from the current GUI screen 220 and thereby skip the next GUI screen 230. However, the user can also get to the screen GUI target without using the shortcut link 221, namely by navigating along the path 220 screen-by-screen. So much for the example of FIG. 2B.

In some embodiments, a minimum number of subsequent GUI screen (s) to be ignored by the shortcut link is necessary. The term "after" refers to the GUI screen sequence of the candidate path. Therefore, identification of candidate paths may include determining whether the GUI screen sequence of a path includes at least two or at least the minimum number of next GUIs plus a GUI screen behind the current GUI screen. In response to this, the path is considered a (possible) candidate path; otherwise, this path will not be identified as a candidate path.

[0054] A candidate path may have multiple target candidate GUI screens (when the candidate path has more than one GUI screen after the next GUI screen (s).) Also, multiple candidate paths may have been identified by the system.Therefore, the number of candidate GUI target screens may be greater than a maximum number of shortcut links to be displayed in the current GUI screen.Therefore, the determination of the target GUI screen may include the selection of a GUI screen from multiple target GUI candidate screens, This selection may be based on the cost function, the minimum number of next GUI screens to be skipped and / or the GUI statistics. a GUI screen of target candidate GUI screens may be based on the candidate path weight, cumulative weights based on the weights of each candidate path that includes a respective target candidate GUI screen and / or probabilities included in the GUI statistics and associated with respective candidate paths and / or respective target candidate GUI screens.

The determination of a target GUI screen may be based on distances between the current GUI screen and target candidate GUI screens along the candidate path (s). A distance between two GUIs may be the number of possible GUIs between the two GUIs increased by one. For example, the longer the distance between the target candidate GUI screen and the current GUI screen, the better the target GUI screen will be determined as the target GUI screen. This skips a larger number of subsequent GUI screens by enabling the shortcut link.

If a target GUI screen has been determined, the shortcut link can be set to point to the target GUI screen. This means that the shortcut link is configured to cause, for example by the electronic device, to switch to the target GUI screen determined in response to a user activating the shortcut link. In some embodiments, one or more shortcut links may be displayed in the current GUI screen. However, in some GUI screens a shortcut link may be displayed, in some other GUI screens multiple shortcut links may be displayed and in still other GUI screens no shortcut links may be displayed. As a result, a number of shortcut links may vary between different GUI screens being the current GUI screen. The user can choose between multiple target GUI screens and thus immediately jump to different target screens.

The GUI may include GUI screens that can not be skipped. Thus, the determination of the target GUI screen may include determining if a GUI screen that can not be skipped is between the current GUI screen and the target candidate GUI screen along the candidate path. If a GUI screen that can not be skipped is between the current GUI screen and a prospective target candidate GUI screen, the shortcut link is prevented from pointing to this target candidate GUI screen. Alternatively, this prospective target candidate GUI screen may be considered not to be a target candidate GUI screen. As a result, any GUI screen that is behind a GUI screen that can not be skipped along the path can be excluded from being determined as a target GUI screen.

[0058] A shortcut link can be activated by clicking on an icon or a text string representing the shortcut link in the current GUI screen to the target GUI screen associated with the shortcut link. In some embodiments, a shortcut link may be activated by an action (of the user), for example when the user presses a certain button or a combination of buttons on a keyboard. A shortcut link can be activated by different alternative actions of the user, for example one or more actions based on the support of a button (s) and / or mouse clicks and / or a touch screen. This provides the user with alternative ways to activate the shortcut link, namely to jump to the respective target GUI screen.

The GUI statistics may include path weights (integers), where each path may be associated with its own weight. The weight of a path can be based on statistics about how often the path was taken during previous visits. The weight of a path can be based on a probability that the user can navigate along the respective path. For example, the weight of the paths may correspond to the frequency with which the paths were taken during previous visits.

As described above, in some embodiments the paths may not be explicitly defined in a GUI definition. In some embodiments, the GUI statistics include information on paths, preferably on each path taken by a user during a previous GUI visit. The GUI statistics can include the sequence of the GUI screens of the path, for example this sequence can be stored as a data entry associated with the path in a database. GUI statistics can relate to the paths visited by users during previous GUI visits independently of individual users, ie without distinguishing individual users. Alternatively, the GUI statistics may relate to individual user statistics, user role statistics, user category statistics, and / or user group statistics. User roles can be administrators, performers, standard users, and / or anonymous developers or users, for example. Categories of users may be based on income, family status, age and / or sex, for example. At the same time, the GUI statistics can relate to path weights on a single user level, a user role level, a user category level, and / or a user group level. Therefore, all the embodiments described herein relating to "users" correspond to other embodiments that must be understood regarding "individual users" and vice versa The information included in the statistics of the GUI and / or or in the recent browsing history may be associated with a user profile, for example, the GUI may include multiple profiles, which may be associated with individual users, to differentiate between different user habits.

In some embodiments, the graphical interface may include multiple individual statistics. For example, some individual statistics may be associated with respective individual users. A set of individual statistics can be associated with a generic user profile if a user has not been identified. Some individual statistics may be associated with individual roles, categories, and / or user groups. For example, a first set of statistics may be associated with a first user and a second set of statistics may be associated with a second user.

At least two paths, preferably each path of the GUI may include one or multiple mandatory GUI screen (s) in common. Therefore, without considering which of the paths the user takes, the graphical interface will display at least the mandatory GUI screen (s). This may allow the GUI to force users to visit the required GUI screen (s) to complete the task (completely).

In some embodiments, at least two paths, preferably each path of the GUI may include the same initial GUI screens as the first GUI screen of the GUI screen sequences of the paths. As a result, when a user visits the GUI, the user will always see the (same) first GUI screen.

In some embodiments, the GUI paths may be unique. For example, two paths may differ in at least one GUI screen. They may have a different number of GUI screens and / or at least one GUI screen is included in only one of the two paths but is not included in the other. Two different paths may include the same sub-path, ie they may have at least one (sub) sequence of GUI screens in common. At least one, preferably each path may include only one real (sub) set of multiple GUIs. To provide, for example, real alternatives to the user to perform a task, no path (of a flow) can include all GUI screens. In some embodiments, paths are always considered complete paths, ie no path can be included completely (such as a subsequence / subpath) in another path. A path may include at least one GUI screen multiple times, i.e. a GUI screen sequence of a path may contain one or more GUI screens multiple times. This allows the paths to contain loops, ie a GUI screen sequence of a path may contain at least one directly adjacent repeat of the same GUI screen subsequence.

The GUI can enter information about an input of the user when using the GUI. For example, the GUI may include a control program to be executed by a processor to operate the graphical user interface. For example, the control program can be implemented by JavaScript in order to carry out the methods described above. The control program can be included in the GUI definition document, for example as JavaScript included in an HTML document. In some other embodiments, the control program may be kept separate from the GUI definition document, for example as an executable file including machine code to be directly performed by a processor.

When executed by the processor, the control program can enter the information concerning the user input. For better readability, expressions such as "The GUI is ..." should be understood as "The GUI control program includes program code stored on the non-transitory, computer-readable storage medium that, when it is executed by the processor, causes the processor to do ... "For example, the previous expression" The GUI can enter information about an input of the user when using the GUI " should be understood as "The GUI control program includes program code stored on the non-transitory, computer-readable storage medium that, when executed by the processor, causes the processor to enter information". applies in parallel with GUI statistics.

[0067] User inputs relating to navigation through the GUI are also called faction "(of the user) .Thus, the term" actions "refers to user inputs that cause the GUI, for example by the electronic device, to switch from a first GUI screen to a second GUI screen, including switching between streams or scenarios in some embodiments. User actions may include clicking on icons in a GUI screen. example, a "next", "previous", or a home button displayed in the current GUI screen to access the next screen, the previous screen, or the start screen, for example. User actions may also include user inputs in a user input field, for example entering information into a text field and pressing an Enter key or selecting a radio button, if that input the user causes the electronic device to switch to another GUI screen. User actions may also include pressing a key or combination of keys or a series of keys on a user's keyboard.

The GUI can record some or all of the user's input during the visit of a user of the GUI. In some embodiments, the GUI may record a sequence of actions of the user. Preferably, the GUI can record each action of the user during the visit of a user of the GUI. In some embodiments, the statistics of the GUI further relate to user inputs or actions of the user. This provides information about the user's behavior when navigating through the GUI and / or data entered by the user. For example, the statistics of the GUI can consider the frequency with which a user has booked a certain hotel, and / or the probabilities of selecting a certain flight (s) and / or a certain train (s). ) and / or a certain car (s) for trips in general or for a certain trip. As yet another example, the GUI may consider sequences of user actions performed by a user during previous browsing visits along a path. For a respective path, the user interface may include one or more action sequences of the user.

In some embodiments, a path includes at least one sequence of actions of the user. A user action sequence may include user action for each pair of two consecutive (directly adjacent) GUIs. This makes it possible to identify one of the multiple paths, even if the user has not yet taken a full path and if the GUI screens visited by the user so far are included in each of the multiple paths. As previously described, several user actions can be associated with the same GUI screen, ie the user can navigate from the current GUI screen to the next (same) GUI screen by performing a user's first action or a second action of the user. Therefore, a path may comprise more than one sequence of actions of the user.

However, some embodiments consider the history of the user's actions that the user has made so far during the current visit. For example, in response to the same user action, the GUI may switch to either a next GUI screen or a second GUI screen. If the GUI goes to the first or second screen GUI may depend on at least one previous action of the user performed by the user before arriving at the current GUI screen and / or user input entered into the current GUI screen or any previous GUI screen.

As previously described, a scenario includes at least two streams to allow the user to perform at least two tasks using the GUI. Therefore, a scenario may include the GUI screens of all the paths of the scenario flows. In some embodiments, a GUI may include at least two scenarios. Each scenario may comprise a subset of the multiple GUIs, the subsets being disjunctive in some embodiments.

When a user navigates through the GUI, the user can switch between different paths, flows and / or scenarios: The graphical interface can provide at least one link in the current GUI screen, in response to the activation. of one of the at least one links, the GUI will switch to a GUI screen of a different path, another stream and / or a different scenario with respect to the current GUI screen. These links can be considered as new optional links in addition to navigation by user actions described above. Determining the target GUI screen can be based on a probability that the user changes the path, flow, and / or scenario during previous visits for the current context. This probability can be collected by the GUI statistics during previous visits by the user.

As described above, the current context (including the current path, the current flow and the current scenario) of the user navigating through the GUI is reflected by the recent navigation statistics. However, in some situations, for example when the user has just entered the GUI, it may not yet be possible to exactly determine a current stream and / or a current scenario. Therefore, to provide a shortcut link, the GUI can apply the following schema: If neither the current scenario nor the current stream has been identified, the target GUI screen can be selected from the GUI screens of the most common scenario according to GUI statistics. If the current stream but not the current scenario has been identified, the target GUI screen can be selected from the GUI screens of the current stream. If the current stream and the current scenario have been identified by the system, the target GUI screen can be selected from the GUI screens of the current stream of the current scenario.

The user can enter a user input into a GUI screen that can be consistent with different streams of a scenario. For example, in a booking scenario of a trip, a user can book a flight to go in a first stream. Then, in a second stream, the user can book a hotel. Then, in a third stream, the user can book a return flight. Thus, the user performs three tasks using three streams of a GUI scenario. However, each task may require the same user input, such as user name, address, date of birth, and the like. This information can be collected by the GUI statistics, for example by GUI statistics storing user entries from previous GUI visits and / or previous visits of particular feeds. Thus, when the user has completed the first task and accesses the second stream, the GUI statistics are already aware of the user's entries in the first stream. In some embodiments, the GUI may reuse user inputs collected by the GUI statistics to pre-populate GUIs. In some embodiments, the GUI may reset the collected user inputs when a new scenario is detected.

[0075] Referring now to FIG. 1, an electronic device in accordance with one embodiment of the invention may be implemented by computer devices or systems, such as computer 20 by way of example. The computer 20 may include a processor 22, a memory 24, a mass storage memory device 26, an input / output (I / O) interface 28, and a Human Machine Interface (HMI) 30. The computer 20 may also be operatively coupled to one or more external resources 32 via the network 18 or the I / O interface 28. External resources may include but are not limited to computers, servers, databases, mass storage devices, peripheral devices, network services focused on cloud computing or other appropriate computer resource that can be used by the computer 20.

The processor 22 may include one or more devices chosen from microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, programmable gate networks in situ, programmable logic devices, PLCs. , logic circuits, analog circuits, digital circuits, or any other device that manipulates signals (analog or digital) based on operational instructions that are stored in the memory 24. The memory 24 may comprise a single memory device or a plurality of memory devices, including but not limited to ROM, random access memory (RAM), volatile memory, non-volatile memory, static random access memory ( SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or any other device capable of The mass storage device 26 may include data storage devices such as a hard disk, an optical drive, a tape drive, a volatile or nonvolatile solid memory device, or any other device. able to store information.

The processor 22 can operate under the control of an operating system 34 that resides in the memory 24. The operating system 34 can manage computer resources so that program code realized in the form of a or several software applications, such as an application 36 residing in the memory 24, may have instructions executed by the processor 22. In an alternative embodiment, the processor 22 can execute the application 36 directly, in which case the system exploitation 34 can be omitted. One or more data structures 38 may also reside in the memory 24, and may be used by the processor 22, the operating system 34, or the application 36 for storing or storing the data. manipulate data.

The I / O interface 28 can provide a machine interface that couples the processor 22 operationally to other devices and systems, such as the network 18 or the external resource 32. The application 36 can thus work in collaboration with the network 18 or the external resource 32 communicating via the I / O interface 28 to provide the various features, functions, applications, processes or modules comprising embodiments of the invention. The application 36 may also have program code that is executed by one or more external resources 32, or otherwise rely on functions or signals provided by other system or network components of components external to the computer. Since the possible hardware and software configurations are almost infinite, those skilled in the art will understand that embodiments of the invention may include applications that are located outside the computer 20, distributed between several computers or other external resources, or provided by computer resources (hardware and software) that are provided as a service on the network 18, such as a cloud computing service.

The HMI 30 may be operatively coupled to the processor 22 of the computer 20 in a known manner to allow a user to interact directly with the computer 20. The HMI 30 may include video screens or alphanumeric, a touch screen, a speaker, and any other audio and visual indicators adapted to provide data to the user. The HMI 30 may also include peripherals and input devices such as an alphanumeric keyboard, pointing device, keyboards, pushbuttons, control buttons, microphones, etc. capable of taking commands. or data input from the user and transmit it to the processor 22.

A database 40 may reside on the mass storage memory device 26, and may be used to collect and organize data used by the various systems and modules described herein. The database 40 may include data and support data structures that store and organize the data. In particular, the database 40 may be arranged with any database organization or structure, including, but not limited to, a relational database, a hierarchical database, a database network, or combinations thereof. A database management system may be provided by a software application of the computer executing instructions on the processor 22. This database management system may be used to access information or data stored in the database. in response to a request. The request can be dynamically determined and executed by the operating system 34, other applications 36, or one or more modules.

Referring now to FIG. 3A, a flowchart is shown which illustrates a method 50 that can be performed by the computer 20 according to one embodiment of the invention. To perform the process 50, the computer 20 is configured to display GUI screens of the GUI by switching from a current GUI screen to a GUI screen following multiple GUI GUI screens. This switching is performed in response to a user action, namely a user input that triggers switching. This allows a user to navigate the GUI, ie through the GUI screens.

Starting from block 51, in block 52, process 50 can generate a recent browsing history in a current GUI visit. The recent browsing history can be stored in the database 40 and / or the resource 32, for example. Recent browsing history includes information about the current GUI screen and potentially previous GUI screens displayed to the user during the current GUI tour so far. Therefore, the recent browsing history includes information on a sub-path including the sequence of GUI screens already visited by the user during the current GUI visit.

For example, recent browsing history may also be based on the user's entries or (only) actions performed by the user during the current visit. The recent browsing history may include data representing a sequence including each entry or action performed by the user since the beginning of the navigation through the GUI during the current visit so far, namely including the entries of The user in the current GUI screen.

In some examples, as already described above, in response to the addition of a GUI screen or the removal of a GUI screen from the definition of the GUI, or a change of existing paths, Thistory of navigation with respect to any path so affected is removed from the GUI statistics in block 52, while GUI statistics for paths that are not affected by Tajout / removal of a GUI screen or a change path are maintained.

In block 53, process 50 may identify possible candidate paths based on recent browsing history and GUI statistics. Only paths for which the recent navigation history is a subsequence can be identified as candidate paths. In addition, only paths that are considered by the GUI statistics can be identified as candidate paths in some embodiments.

The statistics of the GUI can be maintained in a database, for example stored in the database 40 or in the resource 32, for example. GUI statistics are generated during previous GUI visits and may include statistical information about each path navigated by a previous user or the current user. GUI statistics can include a weight of each path. The weight can be based on the frequency with which the path was navigated during previous visits. More often a path has been taken, more important its weight could be, at least with respect to the weights of the other paths. For example, the sum of all the weights of all the paths considered by the GUI may be normalized to a certain value, for example, 1 or 100. In some embodiments, a path that has never been navigated before is not understood or considered by GUI statistics. In other examples, the GUI statistics consider or include each (possible) GUI path. A weight of a path that has never been navigated can be supported or set to zero. For example, initialization of GUI statistics may include for all GUI paths storing information representing a respective path in a GUI statistics database and also storing a zero value weight associated with the GUI. path in the GUI statistics database. In other examples, the GUI statistics can be generated dynamically in response to GUI visits. Accordingly, each time a user navigates along a path that is not (yet) considered by the statistics of the GUI, the computer 20 can store information representing that path in the statistics database of the GUI and can also store a zero value weight (as an initial value) and associated with the path in the statistics database of the GUI. For example, when a user is navigating along a path that is already considered by the GUI statistics, the weight associated with that path can be increased (relative to the weight of the other paths considered in the GUI statistics). Thus, GUI statistics include information about the browsing behavior of users or the particular current user. GUI statistics can consider the weight of paths at the individual user level, at the user role level, and / or at the user group level. In some embodiments, the computer 20 may provide a respective set of GUI statistics for each respective user, for example a first set of statistics of the GUI associated with a first user and a second set of statistics of the GUI associated with a second user. user and so on. These multiple statistics of the GUI can be stored on the mass memory 20 or the resource 32 as a single database or multiple databases each being associated with a user (particular) and including a set of statistics of the GUI associated with it. user.

In block 54, process 50 may determine a target GUI screen. Determining the target GUI screen can be limited to such GUI screens that are included in the candidate paths. A candidate path can be a path that includes the recent browsing history as a subpath, includes at least one GUI screen after the current GUI screen, and includes at least one target candidate GUI screen after the at least one GUI screen. a next GUI screen. In other words, a candidate path can include at least three GUIs, namely the current GUI screen sequence, the next GUI screen (which can be skipped using the shortcut link), and the GUI screen. target after the next GUI screen.

In block 55, the process 50 can set up the shortcut link to point to the determined target GUI screen. This means that the shortcut link is configured, for example, by the computer 20, in a manner appropriate to cause the computer 20 to switch to the target target GUI screen in response to a user input activating the computer. shortcut link. The shortcut link may include a reference to the determined target GUI screen. Thus, when activating the shortcut link, the computer 20 can read the reference included in the shortcut link and set up the GUI screen thus referenced as a next GUI screen. Thus, when navigating through the GUI, the user can activate, for example by clicking on an icon representing the shortcut link on the current GUI screen, the shortcut link and thus "jump" directly to the screen Target GUI by skipping the next GUI screen (s) between the current GUI screen and the target GUI screen. However, in order to allow the user to easily take the shortcut provided by the shortcut link, in block 56, the process 50 may display the shortcut link on the current GUI screen. The shortcut link can be displayed to the user, for example as an icon. In block 57, the user can activate the shortcut link by a respective action. In response, the GUI displays, in block 59, the target GUI screen and thus jumping at least one subsequent GUI screen. Otherwise, namely in response to not having activated, in block 57, the shortcut link, in block 58, the user can navigate through the at least one screen (s) following GUI (s). Finally, after navigating through the at least one subsequent GUI screen (s), in block 59, the target GUI screen will be displayed, since the user will also arrive at the target GUI screen by taking the long route without activating the shortcut link in block 57. The flow according to FIG. 3A ends in block 60.

[0089] A flowchart shown in FIG. 3B corresponds to that shown in FIG. 3A. However, in addition to the process 50 of FIG. 3A, the process 50b also includes, in the block 56b, the pre-loading of the target GUI screen determined in the block 54 on a memory (such as memory 24) of the computer 20. In this way, the possible activation of the target GUI screen by the user is anticipated with the effect that the display of the target GUI screen in response to its actual activation using the shortcut link is accelerated (compared to loading the target GUI screen only in response to activation of the shortcut link). Since the target GUI screen to be pre-loaded depends on user input into the current GUI screen, at least those portions of the target GUI screen that are static and therefore independent of the input of the GUI screen. the user in the current GUI screen are pre-loaded. The dynamic portions of the target GUI screen that depend on user input in the current GUI screen are then loaded when the shortcut link is activated.

[0090] Referring now to FIG. 4A, the process 50 may also include providing a first stream 61 to the user to perform a first task by switching from one screen to another GUI screen 65 of the first stream 61, and providing a second stream 62 to the user to perform a second task by switching from one screen to another GUI screen 65 of the second stream 62. In this embodiment, the GUI includes at least two streams 61, 62 and, therefore, allows the user to perform at least two tasks, for example the booking of a hotel and the booking of a flight.

As illustrated in FIG. 4A, GUI screens 65 may be represented by nodes of a graph. The paths 64 may be represented by the edges connecting the nodes associated with the path. Each path may include (the same) initial GUI screen represented by the root node of the graph. To perform a task completely, the user must navigate from the root node to a terminal node of the graph (ie, an external node opposite to the root node). Thus, as can be seen in FIG. 4A, flows 61, 62 provide many ways to perform tasks, since each path of a flow can be considered as an individual way to perform the task. The weights of a path can be represented by the thickness of the edges.

[0092] Referring now to FIG. 4B, the process 50 may also include providing a first scenario 70 to the user to perform a first set of tasks and a second scenario 75 to the user to perform a second set of tasks. Each scenario 70, 75 includes at least two streams 71, 72, 76, 77 each including multiple paths.

The GUI including scenarios allows the user to perform a complex task. For example, scenario 70 allows the user to perform a complex task including the task of streams 71 and 72. In some embodiments, scenarios 70, 75 may be isolated in the sense that a user navigating through the GUI can only browse this / these GUI screen (s), which are included in the flows of a particular scenario. However, in response to a user input switching scenario, the GUI can switch between multiple scenarios. The switching between the scenarios may include setting the current GUI screen as the GUI start screen of the GUI of a respective first stream. In some embodiments, when switching between scenarios the recent browsing history is also readjusted, ie the recent browsing history will be set or changed to include a single GUI screen, eg the starting GUI screen . Although FIG. 4B shows similar graphs of streams 71, 72, 76 and 77, each of two streams may vary depending on their number of paths and the paths themselves.

Referring now to FIG. 5, illustrating a graph representing eight GUI screens A - H and a starting GUI screen S of a graphical interface including a total of nine GUI screens. The GUI offers four paths including respective sequences of GUIs indicated by letters and associated with respective weights: (SACDF, 60%), (SBCDF, 10%), (SBCEG, 10%) and (SBCEH, 20%). %). The weights are included in the GÜI statistics and represent the frequency with which the respective path has been navigated during previous GUI visits. The paths correspond to the only allowed sequences of GUI screens a user can browse in the GUI. In other words, a user must not navigate from a first GUI screen to a second GUI screen if the first screen and second GUI screen are not included in the same path.

Note that in some embodiments, the GUI statistics include trail weights rather than individual chart edge weights. Weights (or probabilities) of particular edges of the graph can be obtained from the weights of the paths. For example, 70% of users have sailed on the CD edge, while only 30% of users have sailed on the CE edge. However, assuming the user navigates along SBC to the current GUI screen C, in this situation, 25% of users have visited the following GUI screen D while 75% of users have visited the following GUI screen E during previous visits.

By way of illustration, it can be assumed that C is the current GUI screen. In this case, the user may have accessed the current GUI screen C from the start GUI screen S in the current GUI visit so far. If only the information on the current GUI screen C has been considered to provide a shortcut link, each of the GUI screens F, G and H will be found appropriate. However, a shortcut link may be more adequately defined as follows: [0096] From the graph, the user may have taken either the SAC or SBC subpath so far. This information can be used in that the recent browsing history can either include SAC or SBC as a sequence of GUI screens visited so far during the current visit. Therefore, the recent browsing history allows both to consider the current GUI screen as well as from where the user comes from, ie the sequence of GUI screens that he has already visited during the current visit. In some embodiments, the recent browsing history may also include user inputs or a sequence of actions that the user has made during his or her current visit to date. This makes it possible to distinguish between different possible SAC and SBC histories rather than considering only the current GUI screen C.

When the user comes from node A, for example, if the user has sailed along SAC, he has certainly navigated on the SACDF path so far, because it is the only possible path including the GUI screen A. In this situation, the GUI will prevent the user from navigating to E, G, or H, since E, G, and H are not included in the SCDF path. As a result, the only (possible) next GUI screen is the D screen. This can be explained in more detail: [0098] Regarding the identification of candidate paths: This identification may include determining whether a path includes the recent SAC navigation history as a sub-path. Therefore, the SACDF path is the only possible candidate path in this example. The remaining controls will not change anything in this example: The identification may also include determining if a path is considered by the GUI statistics. In this example, the GUI statistics are for all (allowed) paths of the GUI. As a result, SACDF remains a candidate path. In addition, the identification may include determining whether a path includes at least one GUI screen after a subsequent GUI screen. In this example, the SACDF path includes another GUI screen F behind the D GUI screen, and therefore remains a candidate path. Therefore, only the SACDF path is identified as a candidate path for the current GUI screen C when the user is from A.

As for the determination of a target GUI screen, first of all possible candidate target GUIs can be determined. In this example, the only candidate GUI screen is the F screen, because F is the only GUI screen that is included in a candidate path and, furthermore, is behind the next GUI screen. shortcut link can be established to point to the F target GUI screen and the shortcut link can be displayed in the current GUI screen C. This allows the user to jump directly from the current GUI screen C to the GUI screen of target F and, thus jumping the following GUI screen D.

[00100] When the user comes from B, for example, if the user has sailed along SBC, the GUI will allow the user to navigate to any of the D, E, F, G and / or H GUI screens. identification of candidate paths: As previously, the identification may include determining whether a path includes recent SBC navigation history as a sub-path. Thus, only SBCDF, SBCEG and SBCEH (but not SACDF) remain possible candidate paths in this example. The identification may also include determining if a path is considered by the GUI statistics. As before, in the present example, the statistics of the GUI concern all the paths of the GUI. In addition, the identification may include determining whether a path includes at least one GUI screen after a subsequent GUI screen. In this example, the SBCDF, SBCEG, and SBCEH paths include other GUI screens F, G, H behind the following GUI screens D, E. Therefore, the SBCDF, SBCEG, and SBCEH paths are identified as candidate paths.

As for the determination of a target GUI screen, first of all possible target candidate GUIs can be determined. In this example, the GUI screens F, G, H are target GUI candidate screens because they are included in candidate paths and, furthermore, they are behind subsequent GUI screens D, E. Therefore, to provide a shortcut link, one of the possible candidate GUI target screens can be selected. This selection can be based on the GUI statistics and / or the distance between the possible target GUI screens and the current GUI screen. In the present example, the distance is determined to have the value 2 for each possible GUI screen of target F, G, H. However, on the basis of the statistics of the GUI, it can be seen that, during previous visits, users may have preferred in this situation (having navigated on SBC so far) one of the possible target GUI screens. The weight of each of the SBCDF and SBCEG paths is 10%. However, the weight of the SBCEH path is larger, namely 20%. Thus, during previous visits, in this situation, users have more often navigated to H than to F or G. Therefore, H can be determined as the target GUI screen, and therefore a shortcut link can be set to point to this target H GUI screen. The shortcut link can be displayed in the current GUI screen C. This allows the user to jump directly from the current GUI screen C to the GUI screen of the current GUI screen. H target thus jumping the next GUI screen E.

[00102] It should be noted that in this situation, three possible target GUI screens were determined. In some other embodiments, at least one other shortcut link may be provided, which may point to F or G, for example. For example, if several (possible) target candidate GUI screens were determined, at least a few of these could be scored by respective shortcut links.

In general, the programs executed to implement the embodiments of the invention, whether they are implemented as part of an operating system or a specific application, component, program, object , module or sequence of instructions, or a subset thereof, may be referred to herein as "computer program code", or simply "program code". Program code typically includes computer readable instructions that reside at various times in various memory and storage devices in a computer and, when read and executed by one or more processors in a computer, cause the The computer performs the operations necessary to perform operations and / or elements incorporating the various aspects of the embodiments of the invention. Computer readable program instructions for performing operations of the embodiments of the invention may be, for example, assembly language or either source code or object code written in any combination of one or more programming languages. .

[00104] Various program codes described herein can be identified using the application within which they are implemented in specific embodiments of the invention. However, it must be known that any particular program nomenclature that follows is used only for convenience, so the invention should not be limited to being used only in a specific application identified and / or induced by the nomenclature. Furthermore, given the generally infinite number of ways in which computer programs can be organized into routines, procedures, methods, modules, objects, etc., and the like, as well as the different ways in which program functionality can be divided between different software layers residing in a typical computer (for example operating systems, libraries, APIs, applications, applets, etc.), it should be noted that the embodiments of the invention are not limited to the specific organization and the functionalities of the program described here.

The embedded code in any application or module described herein may be distributed individually or collectively as a program product in a variety of forms. In particular, the code may be distributed using a computer readable storage medium having program instructions for causing a processor to perform aspects of the embodiments of the invention.

[00106] Computer-readable storage media, which are non-transitory in nature, may include volatile and non-volatile, removable and non-removable tangible media used in any method or technology for storing information, such as instructions. computer readable, data structures, program modules or other data. Computer readable storage media may further include RAM, ROM, erasable programmable read only memory (EPROM), electrically erasable read only memory (EEPROM), flash memory, or other memory technologies in the state. solid, read-only compact disc (CD-ROM), or other optical storage, magnetic cassettes, magnetic tapes or other magnetic storage devices, or any other means that may be used to store the desired information and that can be read by computer. A computer-readable storage medium should not be interpreted as transient signals per se (for example, radio waves or other electromagnetic waves propagating, electromagnetic waves propagating through a transmission medium such as a light guide). wave, or electrical signals transmitted by a wire).

Computer readable program instructions may be downloaded to a computer, another type of programmable data processing apparatus, or other device from a computer readable storage medium or to an external computer or external storage device via a network. Computer readable program instructions stored on a computer readable medium can be used to specifically operate a computer, other types of programmable data processing apparatus, or other devices such that the instructions stored in the computer readable product produce an article of manufacture, including instructions that implement the functions, actions and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams. The instructions of the computer program may be provided to one or more processors of a general purpose computer, a specialized computer or other programmable data processing device for producing a machine, such that instructions executed through said one or more processors, cause a series of calculations to implement the functions, actions and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams.

In certain other embodiments, the functions, acts and / or operations specified in the flow charts, sequence diagrams, and / or block diagrams can be controlled, serially processed, and / or processed simultaneously in accordance with the modes of operation. embodiment of the invention. Furthermore, any flow chart, sequence diagram, and / or block diagram may comprise more or fewer blocks than those illustrated in accordance with embodiments of the invention.

The terminology used herein is intended to describe particular embodiments only and is not intended to limit the embodiments of the invention. As used herein, the singular forms "one", "one" and "the" are intended to include plural forms, unless the context clearly indicates otherwise. It will also be understood that the terms "includes" and / or "including", when used in this specification, indicate the presence of declared characteristics, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. Furthermore, to the extent that the terms "includes", "having", "a", "with", "consisting of", or variations thereof are used either in the detailed description or in the claims, these terms are intended to be inclusive in a manner similar to the term "comprising".

While the whole of the invention has been illustrated by a description of various embodiments and that these embodiments have been described in detail, it is not the intention of the Applicant to restrict or limiting the scope of the appended claims to such details. Those skilled in the art will see additional benefits and modifications. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and process, and illustrative examples presented and described. Therefore, deviations can be made from these details without departing from the spirit or scope of the Applicant's general inventive concept.

Claims (14)

1. A method for providing a shortcut link (221) in a graphical interface, GUI, of an electronic device (20) for jumping at least one of multiple GUI screens based on GUI statistics from a previous GUI visit , in which the statistics relate to at least one path comprising a sequence of GUI screens of the multiple GUI screens: wherein the electronic device is configured to display the multiple GUI screens by changing from the current GUI screen (220) to a screen Following GUI (230) multiple GUI screens in response to a FutiHsator action, thereby allowing a user to navigate through the GUIs; the method comprising: ~ generating (52), by the electronic device (20), a recent browsing history during a current GUI visit, based on the current GUI screen (220) and previous GUI screens displayed during the current GUI visit; the identification (53), by the electronic device (20), of at least one candidate path on basis of the recent navigation history and statistics of the GUI, Including the determination if the recent navigation history corresponds to a subscript; sequence of the at least one candidate path; "Determining (54), by the electronic device (20), a target GUI screen in the at least one candidate path, wherein the target GUI screen is a GUI screen after the next GUI screen (230) ; - the establishment (56), by the electronic device (20). a shortcut link (221) for pointing to the target GUI screen for causing the electronic device (20) to switch to the target target GUI screen in response to a user activating the shortcut link (221); - displaying (57), by the electronic device (20), the shortcut link (221) in the current GUI screen (220), and in response to adding a GUI screen to the GUI or deleting the a GUI GUI screen, the deletion of all the GUI paths that are impaet by the addition and the deletion, respectively, and the maintenance of all the GUI statistics on the paths that are not impaet by the addition or deletion, respectively. The method of claim 1 further comprising adding, by the electronic device, a path to the GUI statistics by combining a sequence of displayed GUI screens in response to the user's navigation through the GUI when of the current GUI visit, The method of claim 1, wherein the GUI statistics comprise path weights; wherein the determination of the target GUI screen is based on the weight of the at least one of the candidate paths. 4. The method of claim 3, wherein the weight of one respective path is based on statistical information on the fee rate in which the GUL has been navigated by said path during previous visits. The method of claim 3, wherein the weight of a path is increased each time a user navigates by said path. 6. The method of claim 3, wherein the GUI statistics relate to the weights of the paths at a level of individual users, at the level of the user roles and / or at the level of the user groups. The method of claim 3, wherein the determination of the target GUI screen is based on a distance between the target GUI screen and the current GUI screen (220) along a respective candidate path. 8. The method of claim 1, wherein the GUI statistics comprise sequences of collected user entries associated with the paths. The method of claim 1, wherein a first set of statistics of the GUI is associated with a first user and a second set of statistics of the GUI is associated with a second user. 10, The method of claim J, wherein a first stream comprises a first subset of the multiple GUIs and a second stream comprises a second subset of the multiple GUIs: wherein the method further comprises; providing the first stream to the user to perform a first task by changing the GUI between the GUI screens of the first stream, and supplying the second stream to the user to perform a second task by changing the GUI between the GUI screens of the second stream. . The method of claim 1, wherein a first scenario comprises a first subset of the multiple GUIs and a second scenario comprises a second subset of the multiple GUIs; wherein the method further comprises: providing the first scenario to the user to perform a first task by changing the GUI between the GUIs of the first subset, and supplying the second scenario to the user to perform a second task. stain by changing the GUI between the GUI screens of the first subset. The method of claim 11, further comprising: providing a link configured to pass, by the electronic device, a GUI screen from the first scenario to a GUI screen of the second scenario. 13, A device providing (20) a shortcut link (221) in a graphical interface, GUE to jump at least one of multiple GUI screens based on GUI statistics from a previous GUI visit, in which the statistics relate to least one path comprising a GUI screen sequence of the multiple GUI screens; the apparatus (20) comprising: a processor (22); a screen (30) and a memory (24) including program code which, when executed by the processor (22), causes the apparatus to: - display the multiple GUIs by passing the current GUI ( 220) to a next GUI screen (230) of the multiple GUIs in response to user action, thereby allowing a user to navigate through the GUIs; generating (52) a recent browsing history during a current GUI visit, based on the current GUI screen and previous GUI screens displayed during the current GUI visit; identifying (53) at least one candidate path based on the recent browsing history and GUI statistics, including determining whether the recent navigation is a sub sequence of Pau minus a candidate path; determining (54) a target GUI screen in ie at least one candidate path, wherein the target GUI screen is a GUI screen after the next GUI screen (230); Put (55) in place the shortcut link (221) to point to the target GUI screen letting the device to switch to the target GUI screen determined in response to a user who activates the shortcut Hen ( 221); - display (56) the shortcut link (221) in the current GUI screen (220); and - in response to adding a GUI screen to the GUI or deleting a GUI GUI screen, delete from all GUI paths that are irrapacted by adding and deleting, respectively, and keeping all of them GUI statistics on paths that are not impacted by addition or deletion, respectively 14. A computer program product for providing a shortcut link (221) in a graphical interface, GUI, of an electronic device (20) for jumping at least one of multiple GUI screens based on statistics of the GUI of a previous visit of the GUI, in which the statistics concern at least one path comprising a sequence of GUI screens of the multiple GUI screens. wherein the electronic device (20) is configured to display the multiple GUIs by passing the current GUI screen (220) to a next GLU screen (230) of the multiple GUIs in response to a user action, thereby enabling a user to navigate through the GUI screens; the computer program product comprising; a computer-readable non-transitory storage medium; and. program code stored on the non-transitory, computer-readable storage medium which, when executed by a processor, causes the processor to: - display the multiple GUIs by switching from the current GUI (220) to a GUI following (230) multiple GUI screens in response to a Futiiisateur action, thereby allowing a user to navigate through the GUIs; generating (52) a recent browsing history during a current GUI visit, based on the current GUI screen (220) and previous GUI screens displayed during the current GUO-identifier (53) visit at least one candidate path based on the recent browsing history and GUI statistics, including determining if the recent browsing history matches a Fan subsequence minus a candidate path; determining (54) a target GUI screen in the at least one candidate path, wherein the target GUI screen is a GUI screen after the next GUI screen (230); setting (55) the shortcut link (221) to point to the target GUI screen to cause the apparatus to move to the target target GUI screen in response to a user who activates the shortcut link (221); ); Displaying (56) the shortcut link (221) in the current GUI screen (220); and - in response to adding a GUI screen to the GUI or deleting a GUI GUI screen, deleting all GUI paths that are impacted by the addition and deletion, respectively, and keeping them all GUI statistics on paths that are not impacted by addition or deletion, respectively.