TECHNICAL FIELD

The subject matter described relates generally to user interfaces and, in particular, to a user interface for users to define and implement set of sweeps between entities within a graphical user interface.

BACKGROUND

A large organization often possesses assets that are divided among entities of the organization. One example of an entity may be a banking account holding cash. A restaurant management company may have a large number of accounts with financial institutions holding cash (and sometimes other assets) for various purposes. Asset transfers, such as sweeps, enable the company's cash to be added or removed from an account at a specified time to ensure (or at least attempt to ensure) that the assets in the account meets specified criteria (e.g., a target balance). Existing approaches to setting up sweeps typically require an account holder to speak with a person at the financial institution or institutions with which they hold accounts who then sets them up manually. This is inefficient and it may take a significant amount of time (e.g., several days) for a sweep to be setup. Furthermore, even with a relatively modest number of accounts and sweeps, it can quickly become hard to track what assets will be moved to which accounts, leading to unexpected and possibility detrimental results.

SUMMARY

A sweep management system generates and updates a graphical user interface (GUI) for defining and simulating asset transfers between entities of an organization. By generating the GUI for an user at an organization, the sweep management system allows the user to build and visualize simple to complex asset transfer relationships (e.g., sweeps) without relying upon a third party institution to perform these operations for them. In one example, this self-service automation of sweeps can quickly serve a restaurant management corporation, whose operations may require assets to be transferred among restaurants across the globe, in determining when, where, and how much assets should be transferred among its restaurants' banking accounts.

For an intuitive and informative user interface for setting up sweeps, various collections of display routines (e.g., JavaScript® libraries) may be used to render different portions of the interface. Each collection may serve a different function in enabling a sweep to be set up. For example, one collection may render an interactive graphic of accounts in an existing sweep and another may render an interactive table listing accounts that can be added to the existing sweep. The variety in collections for generating the interface may increase how informative the interface is by allowing more information to be displayed in organized ways. However, rendering an intuitive user interface is difficult when a portion rendered using one collection relies upon information from another portion using another collection to maintain the information. That is, there may be an absence of or limitation in communication between the various collections that render the same interface. This may prevent users from making intuitive interactions that start at a portion of the interface managed by one collection and end at a portion of the interface managed by another collection.

In various embodiments, the GUI allows for intuitive user interactions between different portions of the interface. In particular, the sweep management system updates the GUI based on user interactions that may involve, within each interaction, collections of display routines used to manage different portions of the interface. The sweep management system increases the communication between these collections that are used together to generate the GUI. By leveraging a shared reference in a representation of the GUI that can be manipulated using various collections, the sweep management system can pass information or instructions between the collections and enable not only more user interactions, but more intuitive user interactions within the GUI.

In one embodiment for communicating between collections of display routines to update a GUI, the sweep management system generates, for display at a webpage on a client device, a list of entities using a first collection of display routines. Each entry in the list, or “list entry,” may represent a respective entity. The sweep management system generates a shared webpage element and callback functions, which are generated using the first collection and accessible using a second collection of display routines. A graphical representation of one or more of the entities may be generated, for display at the webpage on the client device, using the second collection and the shared webpage element. The one or more entities may be organized within the graphical representation according to a hierarchy. A user may perform a first user interaction with a list entry in the displayed list (e.g., dragging the list entry from the list), where the list entry is representative of a selected entity. In response to determining, using a first callback function of the generated callback functions, that the first user interaction has occurred, the sweep management system may record a data value of the selected entity at the time that the first user interaction occurred. A user may perform a second user interaction with the displayed graphical representation (e.g., dropping the dragged list entry into the graphical representation). Further in response to determining the first user interaction occurred, the sweep management system may update the GUI in response to determining that the second user interaction occurred using a second callback function of the generated callback functions. In particular, the system may generate, for display at the webpage on the client device, an updated graphical representation of the one or more entities using the second collection. This updated graphical representation may include the recorded data value of the selected entity.

In one example, a first user interaction includes a drag of the list entry from a first location on the webpage and the second user interaction includes a drop of the list entry at a second location on the webpage. The callback functions can include event listeners for detecting user interactions with the webpage. The event listeners may include a drag-enter listener, a drag-over listener, and a drop listener. In some embodiments, the list of entities is divided into sections, where each section is associated with a respective entity and a respective drag-enter listener. The first callback function may include a drag-enter listener, and determining that the user has interacted with the list entry may involve determining, using the drag-enter listener, that the user has clicked the list entry.

In some embodiments, the graphical representation includes graphical nodes each associated with a respective entity and a respective webpage location eligible for a drop event. In response to determining that the first user interaction with the list entry has occurred, the sweep management system may further determine, using a drag-over listener, a nearest graphical node of the graphical representation. This nearest graphical node may represent a target entity of the entities (e.g., the target entity with which the user wants to establish a sweep). To determine the nearest graphical node, the sweep management system may determine a current webpage location of the list entry with which the user has interacted and determine that the current webpage location is within a boundary of the nearest graphical node. A drag-over listener may be used to determine the current webpage location of the list entry (e.g., a location in the graphical representation over which the user is hovering the list entry). Each of the graphical nodes may be associated with respective boundaries between other graphical nodes within the graphical representation. For example, the graphical representation is divided into sections by boundaries, where each section includes a node surrounded by some boundaries.

The second callback function may be a drop listener, and determining that the second user interaction with the graphical representation may involve using the drop listener to determine that the user has released the list entry at a webpage location of the graphical representation (e.g., somewhere within the graphical representation on the webpage). The updated graphical representation may be generated by, in response to verifying the webpage location is a valid location to release the list entry, determining an identifier of a nearest graphical node in the graphical representation to which the list entry is released and verifying a relationship exists between the selected entity of the list entry and a target entity of the nearest graphical node. The identifier of the nearest graphical node may be determined using the webpage location at which the list entry is released. The relationship may be verified using an identifier of the nearest graphical node.

The callback functions may include a zoom callback function. In some embodiments, the sweep management system receives a third user interaction with the graphical representation. The third user interaction may be indicative of a request to adjust a size of a graphical node of the graphical representation. The callback functions may include an animate callback function, which may be used to generate an animation of content transferred between two graphical nodes within the graphical representation. The callback functions may include a node-click callback function. In some embodiments, a third user interaction is received which includes a click of a given graphical node. The system may distinguish, using the node-click callback function, a given list entry within the list from other list entries, where the given list entry and the given graphical node are representative of the same entity.

The callback functions may include a move-node callback function. The sweep management system may receive a third user interaction with the graphical representation, where the third user interaction is representative of a request to move a given graphical node to a webpage location associated with a target graphical node of the graphical representation. The given graphical node is representative of a given entity and the target graphical node is representative of a target entity. A relationship between the given and target entities may be verified using the move-node callback function. In response to the relationship being unverified (e.g., the relationship could not be verified or was an invalid relationship), the system may display the given graphical node at the first webpage location to indicate that the requested move has been rejected. In response to the relationship being verified, the system may display the given graphical node at the second webpage location to indicate that the requested move has been accepted.

Examples of entities may include one or more of a financial account for a bank, a profile of an individual in an organization, or a process in a manufacturing facility. The first and second collection of display routines may be two of many collections used to generate the webpage, where each collection is configured to manage webpage elements within a representation of the webpage. The representation of the webpage may be a document object model (DOM). The first collection and second collection may be different JavaScript® libraries. The shared webpage element may be a scalable vector graphic (SVG) object.

