Unified desktop and mobile graphical user interface

Abstract

To standardize GUI displays for different types of devices.SOLUTION: A standardization system 110 in a computing environment 100 converts different GUI views appearing in a desktop device 150 into GUI views on a mobile device 140. Both devices may access the same application and / or may access an application by using a cloud computing platform. The standardization system 110 can support regeneration of a GUI modification executed on one user device in the other user device. The standardization system 110 can maintain a consistent look and feel for a user for different computing device types.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] As users become more dependent on computers and software, their dependency and interactions with the user interface (UI) or graphical user interface (GUI) also increase. These interactions may involve manipulating buttons or icons on the GUI to execute software commands or navigate to different views. Users are also beginning to expect that their full-featured desktop GUI experience will be mirrored in their mobile GUI experience, despite limitations in mobile form factors. While developers have attempted to provide this mirroring functionality, applications developed and supported typically have a fixed GUI configuration. For example, many application GUIs include fixed buttons or icons. This fixed nature can lead to navigation inefficiencies as users navigate within and access various GUI components on desktop and / or mobile computing devices. Furthermore, modifications made on a desktop computing device may not be replicated on a mobile computing device, and vice versa.

[0002] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of U.S. Provisional Application No. 62 / 735,496, filed September 24, 2018, which is incorporated herein by reference in its entirety.

[0003] This application is further related to U.S. patent application Ser. No. 16 / 221,090 (Atty. Dkt. No. 3462.1730002), filed on December 14, 2018, and entitled "Application Builder," U.S. patent application Ser. No. 16 / 221,093 (Atty. Dkt. No. 3462.1730003), filed on December 14, 2018, and entitled "Graphical User Interface Object Matching," U.S. patent application Ser. No. 16 / 221,097 (Atty. Dkt. No. 3462.1730004), filed on December 14, 2018, and entitled "Graphical User Interface Divided Navigation," and U.S. patent application Ser. No. 16 / 221,102 (Atty. Dkt. No. 3462.1730002), filed on December 14, 2018, and entitled "Graphical User Interface Management for Different Applications." No. 3462.1730005), all of which are incorporated herein by reference in their entireties. [Brief explanation of the drawings]

[0004] The accompanying drawings are incorporated into and constitute a part of this specification. [Figure 1] 1 illustrates a block diagram of a computing environment according to some embodiments. [Figure 2A] 1 illustrates a block diagram of a graphical user interface (GUI) displaying an application selection page, according to some embodiments. [Figure 2B] 1 illustrates a block diagram of a GUI displaying an application home page, according to some embodiments. [Figure 2C] 1 illustrates a block diagram of a GUI displaying an object homepage according to some embodiments. [Figure 2D] 1 illustrates a block diagram of a GUI displaying a record page, according to some embodiments. [Figure 3A]1 illustrates a block diagram of a GUI displaying a mobile application menu page, according to some embodiments. [Figure 3B] 1 illustrates a block diagram of a GUI displaying a mobile object homepage, according to some embodiments. [Figure 3C] 1 illustrates a block diagram of a GUI displaying a mobile record page, according to some embodiments. [Figure 3D] 1 illustrates a block diagram of a GUI displaying a scrolled mobile record page, according to some embodiments. [Figure 4] 1 shows a flowchart illustrating a method for sequentially generating a second GUI corresponding to a first GUI, according to some embodiments. [Figure 5] 1 illustrates a block diagram of a GUI displaying an application builder, according to some embodiments. [Figure 6] 1 illustrates a block diagram of a GUI displaying a mobile application builder, according to some embodiments. [Figure 7] 1 illustrates a block diagram of a GUI that displays an editor prompt, according to some embodiments. [Figure 8] 1 shows a flowchart illustrating a method for building a unified application, according to some embodiments. [Figure 9] 1 illustrates a block diagram of a GUI displaying navigation buttons according to some embodiments. [Figure 10] 1 illustrates a block diagram of a GUI displaying a navigation menu, according to some embodiments. [Figure 11] FIG. 10 shows a block diagram of a GUI displaying updated navigation buttons corresponding to a selected object, according to some embodiments. [Figure 12A] 1 illustrates a block diagram of a GUI displaying a page containing tab objects, according to some embodiments. [Figure 12B] 1 illustrates a block diagram of a GUI displaying tab object movement according to some embodiments. [Figure 12C] 1 illustrates a block diagram of a GUI displaying mobile object movement according to some embodiments. [Figure 12D] 1 illustrates a block diagram of a GUI displaying a page including an extended tab object, according to some embodiments. [Figure 12E] 1 shows a block diagram of a GUI displaying a page with added tab objects according to some embodiments. [Figure 12F] 10 illustrates a block diagram of a GUI displaying added mobile objects according to some embodiments. [Figure 13] 1 shows a flowchart illustrating a method for modifying a navigation menu, according to some embodiments. [Figure 14A] 1 illustrates a block diagram of a GUI displaying a mobile page including cursor buttons, according to some embodiments. [Figure 14B] 1 illustrates a block diagram of a GUI displaying a mobile page with a visible cursor, according to some embodiments. [Figure 14C] 1 illustrates a block diagram of a GUI displaying a mobile page including cursor movement, according to some embodiments. [Figure 15] 1 shows a flowchart illustrating a method for generating a cursor, according to some embodiments. [Figure 16A] 1 illustrates a block diagram of a GUI displaying a mobile application menu page, according to some embodiments. [Figure 16B] 1 illustrates a block diagram of a GUI displaying a mobile application selection page, according to some embodiments. [Figure 16C] 1 illustrates a block diagram of a GUI displaying an updated mobile application menu page, according to some embodiments. [Figure 17] 1 shows a flowchart illustrating a method for replacing a list of objects corresponding to an application, according to some embodiments. [Figure 18]1 illustrates an exemplary computer system useful for implementing various embodiments.

[0005] In the drawings, like reference numbers generally indicate the same or similar elements. Further, the leftmost digit(s) of a reference number generally identifies the drawing in which the reference number first appears. DETAILED DESCRIPTION OF THE INVENTION

[0006] Provided herein are embodiments of systems, apparatus, devices, methods, and / or computer program products, and / or combinations and subcombinations thereof, for unifying graphical user interface (GUI) views, components, usage, and control across different computing devices.

[0007] Unification of GUI views may refer to configuring the GUI that appears on a mobile computing device to correspond to the GUI that appears on a desktop computing device. The following description may describe this type of computing environment, although the described embodiments may extend to computing devices of any configuration.

[0008] In one embodiment, the unification system can support unification of GUI views. This unification can refer to generating a GUI on a mobile device that corresponds to a GUI on a desktop device. However, unification can also extend to other computing device configurations. When a user creates and / or manipulates a GUI displayed on a desktop device, a central system can control the GUI display on the mobile device to similarly reflect the manipulation. The central system can be a unification system, as described below.

[0009] The unified system not only controls the content of applications operated by computing devices, but can also modify GUI objects to generate a mobile GUI that corresponds to a desktop GUI. In one embodiment, the unified system can tag different GUI data portions using a sequential component tagging process. The sequential tagging process can enable GUI components arranged horizontally and / or in a combination of vertical and horizontal positions on the desktop GUI to be rearranged into a vertical order for the mobile GUI. This configuration can result in a more comfortable browsing experience for users using mobile devices to view the content of the underlying application with a corresponding desktop view. While the desktop view may include a more horizontally organized layout due to the use of a computer screen, the mobile view can organize the same components in a vertically organized layout. A user may be able to scroll through GUI components and interact with the same application more intuitively via the mobile layout.

[0010] In this way, a user can access the same application using either a desktop GUI or a mobile GUI. The unification system can instantiate a specific GUI based on the device from which the application is accessed. Furthermore, manipulation of the GUI on one device can be replicated on the other device. In addition to modifying the underlying application content (such as data and / or records), a user can edit GUI objects in a particular GUI view on the desktop GUI. For example, a user can move or add a tab to the list of tabs on the desktop GUI. The unification system can generate this modification in the mobile GUI. In this way, when a user views the mobile GUI, the unification system can instantiate a mobile version that includes the modification. Based on this configuration, a user can personalize the desktop GUI, and the unification system can adjust the mobile GUI to include the personalization.

[0011] The unification system may also include controls for an administrator to manage access to applications and / or configure GUI views. For example, the unification system may provide an application builder GUI that an administrator (or an authorized user) can use to manipulate GUI objects. The application builder may include compatible desktop and mobile views and allow an administrator to add and / or remove GUI components. For example, an administrator may add GUI components to a desktop or mobile GUI using a gallery of components with drag-and-drop gestures. The unification system may then arrange the GUI components for the corresponding GUI in the other. In this manner, an administrator may use the unification system to quickly generate multiple GUIs that can be applied to different devices.

[0012] The application builder can also allow an administrator to control various aspects of each GUI component. For example, an administrator can modify GUI objects within a GUI component. Additionally, an administrator can differentiate GUI component views between desktop and mobile GUIs. For example, an administrator can use visibility filters to identify specific GUI components as visible on the desktop GUI but invisible on mobile applications. This customization can still unify the desktop and mobile GUIs while still maintaining the desired independence in visualization. Using either the desktop or mobile GUI can still enable operation of the same underlying application as seen by the GUI.

[0013] In addition to translating the desktop GUI to a mobile GUI, the unified system can also provide mobile GUI controls that can support accessibility of the mobile version of the desktop GUI. For example, the unified system can provide a framework for switching between applications, navigation menus, and / or cursor control.

[0014] In mobile applications, similar to desktop applications, users can interact with the GUI to switch between different applications. When the unification system detects this command, it can replace the GUI components of the currently displayed application with the GUI components of the selected application. In one embodiment, the unification system can maintain the same framework being used, thereby allowing the user to maintain familiarity with the location of GUI objects. While specific content, commands, and / or navigation options may change according to the selected application, the unification system can maintain a common framework between the selected applications. In this way, the unification system can support user access to multiple applications and customization of GUI views within applications and across different devices.

[0015] When navigating within an application, the application may contain different objects or categories. These objects may be tabs in the desktop view and / or may be represented by GUI buttons. Interacting with these objects may allow the user to navigate to different elements of the application. When navigating within these objects using the desktop, the desktop GUI may display the objects due to the large amount of GUI space available relative to the mobile GUI. However, this same view may not be available in the mobile version due to screen size limitations.

[0016] Depending on the difference in screen size, the unified system can generate a navigation menu with corresponding navigation buttons. The navigation menu can correspond to objects of the application that are visible in the desktop GUI view. In one embodiment, these objects may remain hidden to save space on the mobile view. Using the navigation buttons, the user can navigate to the corresponding GUI object. Using a menu gesture (e.g., a long press) on the navigation button can display the navigation menu. The user can then select an object from the navigation menu to navigate to a particular object. This selection may update the navigation button to reflect the selected object. In this way, the navigation button may reflect the most recently selected object, allowing the user to quickly return to the selected object.

[0017] The use of navigation buttons and navigation menus can allow users to navigate within an application using the mobile GUI in a manner similar to navigation in the desktop GUI. By instantiating the mobile GUI to contain the same objects as the desktop GUI, the unification system can unify these views and allow users to perform the same actions in either GUI. Furthermore, by allowing users to customize objects on the desktop GUI and reproducing those customizations on the mobile GUI, users can maintain their desired configuration and navigate the application in a unified manner. When a user moves an object from a first location in the desktop GUI to a second location, the unification system can also adjust the navigation menu to reflect the change in object location.

[0018] In addition to modifying desktop objects, the unified system may also provide controls on the mobile GUI for navigating within components of the mobile GUI. For example, the mobile GUI may include an interface for gesture control. The gesture control may enable split navigation. A user may use a portion of the GUI in a particular way to select a different portion of the GUI. For example, a user may perform a gesture (e.g., a long press) on the bottom half of the mobile GUI. This bottom half may be more comfortable when a user is holding the mobile device with one hand and may also aid accessibility. After performing the gesture, the GUI may display a cursor in another portion of the GUI (e.g., the top half). The user may then move the cursor using gestures on the bottom half of the mobile GUI. In this manner, a user may use a first portion of the GUI to control a second portion of the GUI.

[0019] Through implementation of these embodiments, the unified system can generate various GUIs for accessing one or more applications. These applications may reside on, for example, a cloud computing platform. In one embodiment, the cloud computing platform may be a multi-tenant system. Users can then access, customize, and / or manipulate these GUIs from different computing devices, while the unified system can send instructions to the computing devices to maintain a unified appearance. These instructions can instruct the computing devices to render the GUI in a particular manner. As this disclosure explains below, the unified system can provide centralized management of applications and GUI generation to maintain continuity between computing devices, such as desktops, and mobile devices. Users who make changes on one device can expect to see those changes on other devices based on management by the unified system. In this way, users can more efficiently interact with applications across different platforms and with personalizations that are preserved across different platform GUIs.

[0020] These features of the exemplary embodiments will now be discussed in more detail with respect to the corresponding figures.

[0021] 1 illustrates a block diagram of a computing environment 100 according to some embodiments. The computing environment 100 may represent a computing network that allows user devices to communicate and interact with programs and / or applications. In one embodiment, the computing environment 100 may facilitate cloud computing operations for user devices. The user devices may access cloud-hosted applications and / or data using an internet browser and / or installed programs.

[0022] The computing environment 100 may include a unification system 110. The unification system 110 may be implemented using one or more processors, memory, databases, servers, routers, modems, antennas, and / or hardware or software that may be configured to generate one or more GUIs and / or receive GUI interaction information from mobile devices 140 and / or desktop devices 150. The unification system 110 may be implemented using a computer system 1800 described with reference to FIG. 18. The unification system 110 may be implemented within a computing network, such as, for example, a cloud computing platform and / or a software-as-a-service platform. In one embodiment, the unification system 110 may provide GUI instantiation elements to a cloud computing platform that hosts Internet applications and / or records. In some embodiments, the unification system 110 may also host elements of Internet applications and / or records. In either configuration, the unification system 110 may support multiple users and / or multiple user devices corresponding to each of the multiple users.

[0023] The unified system 110 may communicate with mobile devices 140, desktop devices 150, and / or administrator devices 120. Collectively, these devices may be referred to as user devices. User devices may be, for example, desktop computers, laptop computers, tablets, phones, smartphones, and / or other computing devices. Mobile devices 140 may refer to tablets, phones, and / or smartphones, while desktop devices 150 may refer to desktop computers or laptop computers. However, these user device configurations are not limited to these particular embodiments.

[0024] A user device can access an application over the Internet using a locally installed program and / or an Internet browser. When a user device accesses an application, the unification system 110 can act as an intermediary and instantiate a GUI view to allow the user to display the GUI on the user device and manipulate the GUI objects. The user device can then send commands to the unification system 110 for processing to control the hosted application. In one embodiment, the mobile device 140, the desktop device 150, and / or the administrator device 120 can communicate with the unification system 110 using the network 130.

[0025] The network 130 may be a network capable of transmitting information either wired or wirelessly, such as the Internet, a local area network, or a wide area network. The network 130 may utilize a network protocol such as Hypertext Transfer Protocol (HTTP), TCP / IP protocol, Ethernet, or asynchronous transfer mode. In one embodiment, the network 130 facilitates communication between a user device and the unification system 110. The unification system 110 may instantiate a GUI that may be displayed on the user device. The instantiation may include sending and / or issuing GUI commands to the user device to cause the user device to generate a GUI specified by the unification system 110. The instantiation process may include sending and / or issuing commands to manipulate program code and / or data stored locally on the user device. The GUI commands may cause the user device to generate and / or display a GUI according to instructions provided in the GUI commands. Through instantiation, a user may view the generated GUI and send commands to the unification system 110 via the network 130.

[0026] The unification system 110 may also communicate with an administrator device 120. The administrator device 120 may be a user device configured to provide administrative control over content, applications, and / or GUI functions accessible by users using the mobile device 140 and / or the desktop device 150. Using the administrator device 120, an administrator may configure the applications and / or records accessible to users. The administrator may also manage multiple users via commands sent to the unification system 110. The administrator device 120 may be implemented within a cloud computing platform running the unification system 110. In one embodiment, the administrator device 120 may communicate with the unification system 110 via the network 130.

[0027] Based on these interactions, the unifying system 110 can instantiate GUIs and / or maintain GUI information to assist in generating GUIs on user devices. To instantiate GUIs, the unifying system 110 can include a layout system 112, a user database 114, and / or a content database 116. The layout system 112 can be one or more processors, servers, routers, modems, antennas, and / or other hardware or software that can be configured to generate one or more GUIs and / or receive GUI interaction information from mobile devices 140 and / or desktop devices 150. The layout system 112 can receive requests from user devices and can formulate commands based on programmed rules to generate the requested GUI.

[0028] The layout system 112 can instantiate a GUI using information stored in the user database 114 and / or the content database 116 in conjunction with request data received from the mobile device 140 and / or the desktop device 150. The user database 114 can be a memory containing information related to user preferences. The user database 114 can also include administrator configuration for specific applications and / or permissions assigned by an administrator. The content database 116 can include page and / or record data related to applications. In one embodiment, the content database 116 can be located within the unification system 110 and / or within a cloud computing platform running cloud applications. The content database 116 can include records and / or data associated with underlying applications that a user can interact with using the instantiated GUI.

[0029] In one embodiment, the unifying system 110 can define an application's data page using a single metadata definition. Rather than having two separate data versions of the application for execution on the mobile device 140 and the desktop device 150, the unifying system 110 can store a single record or page definition representing the application page in the content database 116. In one embodiment, this single page definition may represent the application configuration for a particular user and may be used regardless of whether the user is accessing the application on a mobile device 140 or a desktop device 150. When the unifying system 110 receives an access request from a user device, the layout system 112 can determine the device type being accessed. The unifying system 110 can make this determination independent of whether the access comes from a natively installed application or an internet browser.

[0030] For example, the layout system 112 can receive an access request from a mobile device 140 for a particular application. Based on the device type, the layout system 112 can retrieve a single application page definition from the content database 116. The single application page definition can include specific user GUI customization or personalization parameters set by the user. This customization and / or personalization metadata can be stored within the page definition. In response to the request, the layout system 112 can then instantiate a GUI using the metadata. In one embodiment, the layout system 112 can use the portion of the metadata that corresponds to the requesting device type. In one embodiment, the layout system 112 can provide transformation commands based on the stored metadata to instantiate the GUI. In this manner, GUI generation for the mobile device 140 and / or the desktop device 150 can be completed using a single stored data definition along with transformations of the data definition, depending on the device type of the access request.

[0031] As further described below with reference to figures depicting GUI embodiments, the unified system 110 can generate different desktop and mobile GUIs that may share a common page definition. By accessing this common page definition, the unified system 110 can generate GUIs on different devices and replicate modifications made to the GUI from one device to another.

[0032] In one embodiment, the stored data definition can include metadata including component sequencing. Component sequencing can indicate the positional arrangement of GUI components that can be shared between desktop and mobile GUIs. This process can be used to enable the placement of GUI components. When creating or designing an application page, the unification system 110 can automatically generate the sequencing information and store the sequencing information in the page definition. In this way, when the unification system 110 receives a request from a particular device, it can access the page definition and instantiate the corresponding GUI using the sequencing metadata. One embodiment of this sequencing is further described with reference to FIG. 4.

[0033] To briefly illustrate a non-limiting example of this ordering, a developer or administrator can first design a page having several GUI components. For example, the developer can use a desktop to design a page having components similar to the embodiment shown in FIG. 2D . The unification system 110 can then assign sequential numbering to the components of the GUI. If the GUI includes horizontal positions, the unification system 110 may assign numbers in a left-to-right manner, for example. Using this sequential numbering, the unification system 110 can generate a mobile GUI that includes elements from the desktop GUI. The unification system 110 can vertically order the GUI components that correspond to the sequential numbering. In this way, the unification system 110 can store specific records and efficiently invoke elements to instantiate a mobile GUI that corresponds to the desktop GUI and maintains a similar look and feel. The unification system 110 can convert the horizontally arranged GUI components into a vertical format, which may result in a more comfortable viewing experience on the mobile device 140.

[0034] Similarly, if a user reorders components using the mobile device 140, the unification system 110 can receive a reordering command from the mobile device 140. The unification system 110 can then update the stored definition with the updated sequential ordering. The unification system 110 can reallocate the set of assigned values. When the unification system 110 receives a request from the desktop device 150, the unification system 110 can use the updated or reallocated ordering when instantiating the desktop GUI. In this manner, the unification system 110 can unify GUI views across different devices and different device types. In one embodiment, the unification system 110 can also preserve differences between views. For example, the unification system 110 may store a particular ordering for the mobile view while storing a different ordering for the desktop view. An administrator or user can specify this difference using a command sent to the unification system 110.

[0035] In addition to instantiating GUIs for user use across different devices, the unified system 110 can also provide administrator control. The administrator device 120 can specify application permissions and / or corresponding GUI permissions for a user. The unified system 110 can store this information in the content database 116 and in definitions corresponding to pages and block and / or allow user access depending on the permissions.

[0036] As described further below with respect to FIGS. 5-8, the unification system 110 can also instantiate an application builder. The application builder can enable a user and / or administrator to develop specific GUIs and / or page views for an application. These GUIs and / or page views may be default views that may also be editable by the user. The application builder can include compatible desktop and mobile views and allow an administrator to add and / or remove GUI components. For example, an administrator can add GUI components to a desktop or mobile GUI using a gallery of components with drag-and-drop gestures. The unification system 110 can then arrange the GUI components for the corresponding GUI in the other. In this manner, an administrator can use the unification system 110 to quickly generate multiple GUIs that can be applied to different devices.

[0037] As described further below with respect to Figures 9-13, the unification system 110 can also instantiate a mobile GUI that includes navigation buttons and / or navigation menus. The navigation menus can include objects that correspond to desktop objects. The mobile device 140 can display the navigation buttons and / or navigation menus to enable a user to quickly navigate to different parts of an application using the GUI objects. The user can also modify the placement of the GUI objects. The unification system 110 can modify the placement of the mobile GUI objects in response to changes in the placement of the desktop GUI objects.

[0038] As described further below with respect to Figures 14A-15, the unifying system 110 can also generate a cursor on the GUI display. This cursor can allow a user to manipulate a portion of the GUI without directly interacting with that portion. For example, if the GUI is displayed on a mobile device 140, the user can press on the bottom half of the GUI to cause a cursor to appear in the top portion. In this manner, the unifying system 110 can instantiate a mobile GUI that includes accessibility elements and allows a user to access the top portion of the GUI while controlling the bottom portion of the GUI.

[0039] 16A-17, the unification system 110 can also facilitate switching between different applications and providing an updated GUI depending on the selected application. In this manner, the unification system 110 can provide a framework for implementing different applications and application types while maintaining uniformity of the GUI instantiated on the mobile device 140 and the desktop device 150. The unification system can also load different applications developed by different parties and maintain a consistent layout for each application.

[0040] The operation of the unified system 110 will now be described with respect to GUI displays instantiated by the unified system 110 and corresponding flowcharts illustrating the corresponding processes.

[0041] [Sequential deployment of desktop and mobile GUIs]

[0042] FIG. 2A shows a block diagram of a graphical user interface (GUI) 200A displaying an application selection page, according to some embodiments. The GUI 200A may be instantiated by the unification system 110. In one embodiment, the unification system 110 can instantiate the GUI 200A for display on the desktop device 150. The unification system 110 can instantiate the GUI 200A in response to receiving a request from the desktop device 150. The request may include user information, such as login credentials or a session token. The request may also include data indicating the device type that initiated the request and / or whether the request was made from a locally installed application or an internet browser. Using the request, the unification system 110 can instantiate the GUI 200A and / or send a command to the desktop device 150 to display the GUI 200A. The request and / or command may be exchanged via APIs used by the unification system 110 and the desktop device 150.

[0043] In one embodiment, the unified system 110 can instantiate a GUI 200A that is displayed in response to a log-on or power-on request. The GUI 200A can be a home page of a cloud computing platform that allows a user to select an application. Different applications can be supported by the cloud computing platform. These applications can be pre-programmed into the cloud computing platform, created by an administrator using the cloud computing platform, and / or retrieved from an application exchange or marketplace. These applications are further described with reference to FIGS. 16A-17.

[0044] The GUI 200A can display application buttons 215 that allow a user to select an application. The displayed application buttons 215 may correspond to applications that are permitted according to user account information. For example, an administrator can select the specific applications that a user can access. This user permission information may be stored in the user database 114. When the unification system 110 receives a request from a user device, the layout system 112 can consult this permission information to determine the applications available to the user and which application buttons 215 to display in the GUI 200A. The permission information may also indicate the specific GUI components available to the user. The unification system 110 can display the applications selected by the administrator and / or the user.

[0045] A user can make a gesture to select an application button 215. For example, if GUI 200A is displayed on a desktop monitor or display screen, the user can use a cursor in conjunction with a hardware input peripheral to make a selection. If the display screen includes touchscreen functionality, the user can select a particular application button 215 by touching the screen. Desktop device 150 can process the selection locally to determine subsequent actions or GUI screens and / or send the selection to unified system 110.

[0046] GUI 200A may also include a search bar 210. Search bar 210 may allow a user to search for a particular application. In one embodiment, search bar 210 may also allow a user to search for items within a particular application. Using application button 215 and / or search bar 210, a user can select an application and search for elements of the selected application.

[0047] 2B shows a block diagram of GUI 200B displaying an application homepage, according to some embodiments. Desktop device 150 can display GUI 200B in response to selection of application button 215. Desktop device 150 can generate GUI 200B based on locally stored rules or commands. In one embodiment, unification system 110 may instantiate GUI 200B after receiving selection data from desktop device 150.

[0048] GUI 200B may display an application home page. The application home page may allow a user to interact with a selected application. The application home page may include one or more GUI components that may contain different commands and / or data. For example, GUI 200B may include a search bar 210, an object 220, and / or an application component 230.

[0049] The search bar 210 from GUI 200B may be similar and / or the same as the search bar 210 displayed on GUI 200A. A user may use the search bar 210 to navigate between applications and / or to retrieve items within a selected application. The search bar 210 may persist on the display screen as the user navigates within different page views and / or components of the application, thereby allowing the user to navigate throughout the application.

[0050] In addition to the search bar 210, the GUI 200B may include objects 220. The objects 220 may represent different page views of the application. The objects 220 may also persist on the display screen as the user interacts with the objects 220 and / or navigates within the application. In one embodiment, the objects 220 may be represented as tabs on the GUI 200B, but may also be represented by other GUI buttons. The objects 220 may also include collapsed or grouped options. Grouped objects 220 may be expanded to reveal hidden buttons. As further described below with reference to FIGS. 12A-12F, the objects 220 may be edited and / or customized by the user.

[0051] Interacting with objects 220 can access different page views of an application. Objects 220 may depend on the functionality provided by the application. An application may contain different data record portions and / or executable program code. Selecting objects 220 can display these data records and / or executable program code for user interaction and / or manipulation. GUI 200B may also include these data records and / or executable program code as application components 230.

[0052] Application components 230 may include different portions of GUI 200B that display data records and / or executable program code. GUI 200B may display these application components and / or allow a user to interact with application components 230 to interact with the underlying application. In one embodiment, the application may be a data management application and may include a posting component 230A. Posting component 230A may allow a user to submit text and / or files to the application. GUI 200B may also include other components that allow a user to view records, update or modify records, generate files such as documents, spreadsheets, or presentations, issue approval commands, and / or connect to external programs or other programs managed by the cloud computing platform. When viewing GUI 200B, a user can interact with available application components 230 and / or use objects 220 to navigate to other elements of the application. For example, a user may select object 220C by using cursor commands or gestures. In response to receiving this command, desktop device 150 and / or unification system 110 may instantiate GUI 200C, as shown in FIG. 2C.

[0053] 2C shows a block diagram of a GUI 200C displaying an object home page, according to some embodiments. The GUI 200C may include an object 220 and / or a search bar 210, which may persist after selection of the object 220. The object home page may correspond to the selected object 220. In one embodiment, the object home page may display grouped and / or collapsed objects 240. The object home page may be, for example, an intermediary application page that allows a user to navigate among the grouped and / or collapsed objects 240. If a user selects one of the grouped and / or collapsed objects 240 as shown in GUI 200C, the user may access a record page, as shown in GUI 200D and FIG. 2D.

[0054] In one embodiment, a user can access a record page from GUI 200B and / or GUI 200C. For example, if a user selects an ungrouped object 220 from GUI 200B, the unification system 110 can instantiate GUI 200D to display a record page corresponding to the selected object. In contrast, if a user selects an object 220 with multiple object options, such as object 220C, the unification system 110 can generate an object home page shown in GUI 200C. The object home page can include grouped and / or collapsed objects 240. A user can select a grouped and / or collapsed object 240 to access the corresponding record page.

[0055] Additionally, grouped and / or collapsed objects 240 may be accessed from GUI 200B. For example, when accessing object 220C from GUI 200B, GUI 200B may display a menu that includes grouped and / or collapsed objects 240. The user can then select grouped and / or collapsed objects 240 from this menu to access a record page.

[0056] FIG. 2D shows a block diagram of a GUI 200D displaying a record page, according to some embodiments. A record page may be a particular application page having components similar to application component 230. For example, a record page may be a particular account, such as “The Grocery Company,” which specifies an instance of “Account” under the “Accounts” object. Components in GUI 200D may include data records and / or executable program code. For example, header component 250 may include data record information and / or GUI buttons that allow a user to interact with header component 250. Similarly, information component 260 may include record data and / or allow a user to view and / or navigate within a data record. Information component 260 may include components such as tab component 262. Tab component 262 can allow a user to navigate within different data records grouped by different tab components 262.

[0057] Record pages may also include a messaging component 270. The messaging component 270 can retrieve data records linked to communications. For example, the administrator device 120 can provide news and / or other communications related to a particular record page, user, and / or organization.

[0058] A record page may also include a program component 280. The program component 270 may include one or more program tabs 282. The program tabs 282 may allow selection of different portions of executable program code. For example, the program tab 282A may include an activity monitor. The activity monitor may track user tasks and / or tasks associated with a particular record page.

[0059] The program component 280 may also include a program tab 282B that allows a user to post information. For example, a user may post information related to a record page. The unification system 110 may accept data received from the desktop device 150 and correlate the posted data with the record page. In one embodiment, the unification system 110 may pass this information to a cloud computing program that runs an application and processes the application data.

[0060] The program component 280 may also include a program tab 282C that allows a user to create a file. The file may be stored on a cloud computing platform and / or program code may be executed to create the file. The file may be, for example, a word processing file, a spreadsheet file, a presentation, an image, an audio file, a video file, and / or other data file. Creating a file using the GUI 200D may allow a user to correlate the file with a displayed record page. The unifying system 110 may facilitate this correlation with the underlying application. In this manner, a user may utilize the program component 280 and / or the GUI 200D to interact with a record page of an application.

[0061] In one embodiment, Figures 2A-2D may correspond to example GUIs displayed on desktop device 150. Unification system 110 can instantiate these example GUIs and allow users to access the applications. Unification system 110 can also instantiate corresponding GUIs on mobile device 140. These mobile GUIs are described in embodiments discussed below with respect to Figures 3A-3D.

[0062] FIG. 3A shows a block diagram of a GUI 300A displaying a mobile application menu page, according to some embodiments. The GUI 300A can be instantiated by the unification system 110. In one embodiment, the unification system 110 can instantiate the GUI 300A to be displayed on the mobile device 140. The unification system 110 can instantiate the GUI 300A in response to receiving a request from the mobile device 140. The request can include user information, such as login credentials or a session token. The request can also include data indicating the device type that initiated the request and / or whether the request was made from a locally installed application or an internet browser. Using the request, the unification system 110 can instantiate the GUI 300A and / or send a command to the mobile device 140 to display the GUI 300A. The request and / or command can be exchanged via APIs used by the unification system 110 and the mobile device 140.

[0063] GUI 300A may show a mobile application menu page. The mobile application menu page may correspond to GUI 200B shown in FIG. 2B. GUI 300A may represent a selected application displayed on mobile device 140. GUI 300A may include an application menu button 315 for selecting another application. Selecting application menu button 315 may cause mobile device 140 to display GUI 1600B and a mobile application selection page 1605, as shown in FIG. 16B.

[0064] GUI 300A may also include object 320. Object 320 may correspond to object 220 from the desktop GUI. Selecting object 320 may allow a user to navigate through different pages of an application. Accessing these objects may provide access to a single definition of the page managed by unified system 110 and / or the cloud computing platform. Similar to accessing object 220, when a user selects object 320, mobile device 140 may display GUI 300B or GUI 300C, depending on whether the selected object 320 includes a grouped object.

[0065] For example, if the selected object 320 includes a grouped object, the unified system 110 can instantiate GUI 300B. Figure 3B shows a block diagram of GUI 300B displaying a mobile object homepage, according to some embodiments. From GUI 300B, a user can select a grouped and / or collapsed object 340 to access a record page. In this manner, GUI 300B can be similar to GUI 200C for desktop viewing.

[0066] If mobile device 140 is displaying GUI 300A and the user selects object 320 that does not include grouped or collapsed objects, unified system 110 can directly instantiate GUI 300C to display the record page corresponding to object 320. In this manner, interaction with object 320 and / or grouped and / or collapsed objects 340 can enable the user to reach the record page displayed in GUI 300C.

[0067] In addition to object navigation, GUI 300A may include various mobile buttons 310-318 that enable navigation through the GUI displayed on mobile device 140. Mobile buttons 310-318 may persist and appear as a user navigates to different pages of an application displayed on mobile device 140. Mobile buttons 310-318 may include navigation button 310, favorites button 312, search button 314, notifications button 316, and / or menu button 318. Navigation button 310 may enable quick navigation to different objects in the application and may reveal a navigation menu containing one or more objects 320. Navigation buttons 310 are described in further detail with reference to FIGS. 9-13.

[0068] Favorites button 312 can show record pages and / or objects 320 that have been marked as favorites. Selecting favorites button 312 can generate a GUI that displays the marked favorites.

[0069] The search button 314 may enable a search for objects and / or records associated with the underlying application. Selecting the search button 314 may reveal a search GUI that includes an interface that may enable a user to enter search terms. The search button 314 may also be used to generate cursor control, as further described with reference to Figures 14A-15.

[0070] The notification button 316 can allow a user to see updates related to the user. For example, if the user is mentioned in a post or if an alert is generated for a record linked to the user, the user can use the notification button 316 to see the update.

[0071] Menu button 318 can allow a user to display GUI 300A. For example, as a user navigates and / or interacts with different objects and / or data records, the user may wish to return to GUI 300A. For example, the user may wish to select a different object 320 and / or a different application using application menu button 315. Selecting menu button 318 can reveal GUI 300A and allow the user to perform a desired action.

[0072] After a user selects object 320 and / or grouped and / or collapsed object 340, unification system 110 can instantiate a mobile record page. FIG. 3C shows a block diagram of GUI 300C displaying a mobile record page, according to some embodiments. FIG. 3D shows a block diagram of GUI 300D displaying a scrolled mobile record page, according to some embodiments. The mobile record page may correspond to GUI 200D and the record page illustrated in FIG. 2D. Unification system 110 can store a definition for this record page and can instantiate GUI 200D or GUIs 300C-300D depending on the device type accessing the record page.

[0073] GUIs 300C-300D may also display the same components as GUI 200D displayed on desktop device 150. For example, GUIs 300C-300D may include a header component 350 corresponding to header component 250, an information component 360 corresponding to information component 260, a messaging component 370 corresponding to messaging component 270, and a program component 380 corresponding to program component 280.

[0074] These mobile components can include similar functionality to desktop components. For example, information component 360 may include tab component 362, similar to tab component 262. Selecting tab component 364 can allow a user to view related information and / or "drill down" to different data records. This GUI configuration can allow for a look and feel similar to a desktop version of the GUI with familiar tabs, but can also preserve display screen space in the mobile version so that more information is visible and / or accessible.

[0075] Similarly, as displayed in GUI 300D, program component 380 may include program tab 382, ​​which may be similar to program tab 282. A user may use a scroll gesture to move through the mobile record page and view program component 380. Similar to program tab 282, a user may interact with program tab 382 to execute specific program code corresponding to an application.

[0076] The components between the desktop and mobile GUI versions of a page may be similar and / or may include similar components, but the ordering and / or placement of the components may differ. The unifying system 110 can control this ordering so that the mobile GUI version maintains a similar look and feel to the desktop version but still maintains efficient accessibility based on smaller screen sizes.

[0077] To manage these components, the unified system 110 can characterize the components using a sequential allocation process, one embodiment of which is further described with reference to FIG.

[0078] The sequential assignment process can include analyzing the desktop GUI to identify specific GUI components of a record page. The unification system 110 can then sequentially assign values ​​to each GUI component, even if the GUI components are in different positions on the GUI. For example, the GUI components may be located in different rows and / or columns and / or may have relative horizontal placement. However, these horizontal positions may be undesirable when the record page is displayed on the mobile device 140 due to the vertical screen structure. In this case, the unification system 110 can utilize the sequentially assigned values ​​to instantiate a vertical organization for the mobile device 140 in response to receiving a request to view the record page on the mobile device 140. The vertical screen structure can allow a user to scroll the record page vertically without having to scroll horizontally. This structure can aid user accessibility and allow a user to navigate to different portions of the record more quickly. Because a user can focus on one-dimensional vertical scrolling, the user can avoid scrolling in a second dimension in an attempt to locate a desired GUI object.

[0079] Additionally, GUIs 300C-300D may include action buttons 390. Action buttons 390 may persist while a user scrolls and / or navigates through record pages and may allow the user to perform actions related to the displayed record page. For example, edit button 390A may allow a user to edit data within a record page. Post button 390B may allow a user to post a comment to a record page. The comment may be a user message or note and may differ from the data corresponding to the record page. For example, the data may be an organization name, while the comment may be a user message to another user who has access to the record page. Similarly, log button 390C may include a special type of post directed to logging information, such as a phone call. In one embodiment, log button 390C may create a special data record for tracking information.

[0080] The action buttons 390 may also include other actions depending on the record page and / or application. The displayed action buttons 390 may also include more and / or fewer than the number of action buttons 390 displayed in FIG. 3C. The expand button 390D may further reveal other possible actions. For example, the other possible actions may include creating or attaching a file, creating a link, creating a new user group, adding a new note, creating a poll, posting a question, adding a thank you note, adding a video, sending an email, and / or other actions.

[0081] To select an action, the user can click and / or press the action. In one embodiment, the user can use a scrub gesture in conjunction with the search button 314. The search button 314 may also be used to generate cursor control, as further described with reference to FIGS. 14A-15. The user can scroll with the cursor using a long press. When the cursor selects an action button 390, releasing the long press can designate selection of the particular action button 390 selected by the cursor.

[0082] Using GUIs 300C-300D, a user can navigate record pages using mobile device 140. As described further below, personalization configurations created by a user on desktop device 150 can also appear in the mobile GUI version. Unification system 110 can store these configurations and retrieve them in response to a request. Unification system 110 can apply personalization selections when generating the mobile GUI. In addition to these selections, unification system 110 can generate the mobile GUI using a sequential component allocation process.

[0083] 4 shows a flowchart illustrating a method 400 for sequentially generating a second GUI corresponding to a first GUI, according to some embodiments. Method 400 is described with reference to FIG. 1. However, method 400 is not limited to that exemplary embodiment.

[0084] In one embodiment, unifying system 110 can utilize method 400 to generate a second GUI corresponding to a first GUI. The foregoing description describes one embodiment of the implementation of method 400 with respect to GUI 200D and GUIs 300C-300D, but may be applicable to any mapping GUI. Although method 400 is described with reference to unifying system 110, method 400 may be performed on any computing device, such as, for example, a computer system described with reference to FIG. 18 , and / or processing logic, which may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof.

[0085] It should be appreciated that not all steps may be required to practice the disclosure provided herein. Moreover, as will be appreciated by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that shown in FIG.

[0086] In one embodiment, at 410, the unification system 110 can instantiate a first graphical user interface (GUI) corresponding to a first device, where the first GUI includes multiple GUI components of an application. The unification system 110 can instantiate the first GUI on the desktop device 150. For example, a user, an administrator, or both can build the first GUI corresponding to an application. The application may be hosted by a cloud computing program and / or a networked computing system. The administrator and / or user can develop one or more GUI views corresponding to the application. The first GUI may correspond to, for example, a record page. In one embodiment, the administrator and / or user can generate the record page using an application builder. One embodiment of the application builder is described with reference to FIGS. 5-8.

[0087] The record page may be displayed using a first GUI. The first GUI may represent a record page displayed on desktop device 150. The first GUI may include multiple GUI components representing different access portions to the application. One example embodiment of GUI components is described with reference to FIG. 2D and GUI 200D. An administrator and / or user may place components in desired positions in the first GUI. These positions may be within rows and / or columns and / or may be arbitrary. At 410, the user or administrator may modify the positions of the components, and unification system 110 may track the modified positions. The unification system 110 may know that the creation and / or modification of the first GUI is complete, for example, using elapsed time and / or from receiving a command to save the first GUI. In one embodiment, the unification system 110 may save the configuration of the first GUI in a continuous and / or monitored manner without a direct command from the user. At 410, instantiating may include instructing desktop device 150 to display the first GUI and / or may include saving the configuration of the first GUI.

[0088] At 420, the unified system 110 can sequentially assign values ​​to each of the plurality of GUI components of the first GUI to generate a set of assigned values. Referring to FIG. 2D and GUI 200D, the first GUI can include components 250-280. These components 250-280 can be arranged in any manner and / or into rows and columns. For example, the header component 250 can be arranged above the information component 260, the messaging component 270, and the program component 280. The information component 260 can be located to the left of the messaging component 270 and the program component 280. The messaging component 270 can be located above the program component 280.

[0089] The unification system 110 can store metadata associated with these locations. The metadata can correspond to a shared definition of a record page. This shared definition can be used to instantiate the first GUI and / or the second GUI. When storing this metadata, the unification system 110 can sequentially assign values ​​to each component of the first GUI. For example, the unification system 110 can assign a corresponding numeric or binary code to the component based on its placement on the first GUI. The unification system 110 can use a left-to-right and top-to-bottom process for assigning values. For example, the header component 250 can be first, followed by the information component 260, the messaging component 270, and the program component 280. Each GUI component can be assigned a sequential value. This sequential value can assist in recreating the first GUI as a second GUI displayed on a different device. The second device can, for example, utilize a vertical display screen, and reordering the components can facilitate a more accessible GUI relative to the horizontal GUI 200D displayed in FIG. 2D .

[0090] At 430, the unification system 110 can store the set of assigned values ​​in memory. As previously discussed, the assigned values ​​may be stored in memory as metadata. The unification system 110 can store this metadata in the content database 116 and / or store the metadata externally. For example, if a cloud computing system is using the unification system 110 to manage GUI construction of application views, the set of assigned values ​​may be passed to the cloud computing system for storage.

[0091] In one embodiment, a set of assigned values ​​may be stored corresponding to a record page displayed by a first GUI. The record page may use a single definition that can be modified to include the set of assigned values. This single definition may be a data structure or record facilitated by an application. The unification system 110 can use this single definition to recreate different GUI views of the record page. For example, the unification system 110 may use this single definition to generate the first GUI and / or the second GUI.

[0092] At 440, the unification system 110 may receive a request to view the application on a second device. The second device may be different from the first device and / or may be a different device type. For example, the first device may be a desktop device 150, while the second device may be a mobile device 140. The request from the second device may be a message including login credentials, a session token, device information, and / or other information identifying the second device. When the unification system 110 receives the request, the unification system 110 may analyze this data to determine the device type. For example, at 440, the unification system 110 may determine that the second device is a mobile device 140. In one embodiment, the unification system 110 may utilize rules and / or logic to determine that the GUI instantiation of the mobile device 140 is different from the GUI instantiation of the desktop device 150.

[0093] At 450, in response to receiving the request, the unification system 110 may retrieve a set of assigned values ​​from memory. After determining the device type by checking the data or metadata of the request, the unification system 110 may retrieve the set of assigned values ​​to determine the placement of the GUI components. If the request was received from desktop device 150, the unification system 110 may place the GUI components in a manner similar to GUI 200D. However, because the request is received from a second device, the unification system may utilize the set of assigned values ​​to create a different GUI.

[0094] At 460, the unifying system 110 can instantiate a second GUI by arranging the GUI components according to the set of assigned values. For example, after determining that the second device is a mobile device 140, the unifying system 110 can use programmatic rules or logic to instantiate the second GUI in a manner compatible with the mobile device. For example, the unifying system 110 can recognize that GUI components should be arranged vertically for the mobile device and mobile device 140 due to the vertical nature of the display screen.

[0095] In this manner, the unification system 110 can instantiate the GUIs 300C-300D to be displayed on the mobile device 140. The particular order of the components can correspond to a set of assigned values. This order can enable the unification system 110 to create a similar look and feel for the mobile device 140 and the desktop device 150.

[0096] In this manner, using method 400, the unification system 110 can enable the unification system 110 to recreate different GUI component arrangements for different devices. The unification system 110 can store a single page definition that can be retrieved upon receiving a request from a particular device. The unification system 110 can then determine the device type and instantiate a corresponding GUI based on the device type. In this manner, devices can share a single page definition managed by the unification system 110. The single page definition may be modified. For example, a user may modify the position of a particular component using a first device. As described further below, the user may also modify object positions. The unification system 110 can update the single page definition to include these modifications. The unification system 110 can then consult the single page definition when instantiating a new GUI view of a record page. In this manner, the unification system 110 can enable user personalization of GUI components, and modifications or personalization selections can be replicated across different devices. The unified system 110 can also manage modified application content, but enables and tracks modifications to GUI components, allowing users to have more flexibility and navigation access across different devices.

[0097] [Application Builder]

[0098] Although the unification system 110 may instantiate various GUI views of an application or record page depending on the device type, the unification system 110 may also provide an application builder. The unification system 110 may instantiate various GUI views of an application builder that allow users and / or administrators to configure and / or create record pages for an application. While the following description may refer to the administrator device 120 accessing the application builder GUI, users may also access and / or operate the application builder GUI using the desktop device 150. This functionality may depend on whether the user has been granted access by an administrator.

[0099] FIG. 5 shows a block diagram of a GUI 500 displaying an application builder, according to some embodiments. The application builder may be managed by the unification system 110 and may allow an administrator to modify an application's record page. These modifications may include GUI modifications, including specific components available to a user when accessing the record page. In one embodiment, the unification system 110 may instantiate the GUI 500 on the administrator device 120. The administrator device 120 may accept commands and / or interactions with the GUI 500. The administrator device 120 may then send these commands and / or interactions to the unification system 110. The unification system 110 may then store these commands and / or update the record page according to the commands. In one embodiment, the unification system 110 may update a single definition data structure corresponding to the record page. The unification system 110 may use this single definition data structure when instantiating GUI views of the application and / or record page for the mobile device 140 and / or desktop device 150.

[0100] GUI 500 may include different elements that allow an administrator or user to view, create, and / or modify a GUI view of a record page. For example, GUI 500 may include a device button 510, a save button 520, a GUI viewer 530, a component panel 540, a page panel 550, a visibility icon 560, and / or a page button 570.

[0101] The device button 510 can allow the administrator to toggle GUI views of the record. The device button 510 can be a drop-down menu and / or icon for selecting a specific device. The device button 510 can indicate a device type, such as "desktop" or "mobile." The device button 510 can allow different categorization based on device type, such as "desktop," "laptop," "tablet," or "phone." In one embodiment, the device button 510 can allow a user to specify a specific device, such as "User's Tablet ID #123." Based on the selection of the device button 510, the unified system 110 can modify the content of the GUI viewer 530.

[0102] GUI viewer 530 may include a preview of the GUI being created and / or modified by the application builder. GUI viewer 530 may display, for example, the GUI or record page to be displayed on desktop device 150. For example, GUI viewer 530 may display components from GUI 200D. An administrator may interact with GUI viewer 530 to modify the components of the GUI.

[0103] An administrator can provide commands to the unification system 110 using the administrator device 120. In response to the commands, the unification system 110 can modify the GUI displayed in the GUI viewer 530. For example, the unification system 110 can modify the position of a particular component. When interacting with the GUI 500, the administrator can provide drag-and-drop commands or gestures. In response to these commands, the unification system 110 can move the component to the indicated position. Additionally, the unification system 110 can provide different layouts in terms of rows or columns or component placement. In this manner, the administrator can customize the GUI components of the record page. As described below with reference to FIG. 7, the administrator can also use the GUI viewer 530 to further configure elements within the GUI components.

[0104] In addition to modifying component locations, an administrator can also add and / or remove GUI components from the GUI. To remove a GUI component, an administrator can provide a remove command from the administrator device 120 to the unified system 110. This remove command may refer to removing the GUI component, but may not delete the underlying record data and / or modify the application data or executable programs. Removing a GUI component may reflect a design decision or may indicate to the unified system 110 that a particular component will not be loaded. A user may or may not still access the component or the underlying application elements using other operations.

[0105] In one embodiment, an administrator can specify specific GUI views for specific users. The administrator can decide to block a user from using specific application elements and / or GUI components. Thus, the unification system 110 may be configured to receive a command indicating that a specific GUI component is blocked and may not load the specific GUI component for the user to prevent the user from accessing the application element.

[0106] In addition to removing and / or blocking GUI components from the GUI, an administrator can add components. The administrator can access components using the component panel 540. The unification system 110 can retrieve these components depending on the installed components in the cloud computing platform. Using the component panel 540, a user can add listed components to the GUI by dragging and dropping them into the GUI viewer 530. The user can then move the added GUI components to the desired location. While the GUI viewer 530 shows four components in FIG. 5, more or fewer components may be added. Components may also be resized by unification based on commands provided by the administrator. Additionally, added components may overflow "off-screen." In this case, the unification system 110 can provide a scrolling element within the GUI viewer 530 to allow the user to scroll and view the components.

[0107] The component panel 540 may include pre-loaded components from a cloud computing platform, but the component panel 540 may also include a button to retrieve additional components. This button may reveal an application marketplace or exchange for installing additional components. The user may also use a search bar in the component panel 540 to filter and / or retrieve specific components.

[0108] The components discussed herein may correspond to GUI views and / or commands that may be utilized in an application. For example, a record may include account information that may be listed in a header component. An information component may organize record data in a tab-like manner, allowing a user to browse stored information. An action component may allow a user to edit record data and / or interact with record data based on functionality provided by the underlying application. In this manner, an administrator may define components to make up a GUI, and users may use these components to interact with the underlying application and application record data.

[0109] In addition to editing GUI components, an administrator can also use the page panel 550 to edit metadata associated with a record. The page panel 550 may include administrator metadata, which may not be available for viewing by users. For example, the page panel 550 may allow an administrator to add a GUI view label, developer name, page type, object description, select a template, and / or add a description. This metadata editing may be useful for categorizing records. For example, metadata may specify that a particular record page is an "account" object. The page panel 550 may then display the object information.

[0110] The page panel 550 can also allow a user to select a particular template of components to quickly build a GUI view. The template may include preselected components and / or component locations. Changing the template can also cause the unification system 110 to modify the GUI to match the template.

[0111] As discussed further with respect to FIG. 7 , GUI 500 may also include visibility icons 560. Visibility icons 560 can represent GUI components with different properties depending on device type. For example, in one embodiment, when unification system 110 instantiates a GUI on desktop device 150, desktop device 150 may display components with visibility icons 560. However, when unification system 110 instantiates a GUI on mobile device 140, mobile device 140 may not display the components in this embodiment. Unification system 110 can store this visibility information in a single definition for the record page. Unification system 110 can maintain these visibility elements and allow an administrator to hide and / or show certain components depending on device type. An administrator may, for example, want to provide components on desktop device 150 due to larger screen sizes, but hide the components on mobile device 140. In this manner, the GUI display of the record page for mobile device 140 may be more aesthetically appealing, depending on the administrator's selection.

[0112] The GUI 500 may also include page buttons 570. The page buttons 570 may allow quick access between record pages and allow editing of GUI components. The administrator can use the page buttons 570 to reveal a drop-down menu and select a particular page. The unified system 110 can then instantiate that page in the GUI viewer 530 and allow the administrator to manipulate the page.

[0113] GUI 500 may also include a save button 520. In response to receiving an interaction on save button 520, unification system 110 can save the GUI component configuration to a single page definition corresponding to the page. This single page definition may apply to a single user and / or more than one user, depending on configuration information provided by an administrator. For example, an administrator can configure a GUI for user A to include a certain component and a GUI for user B to not include the component. Unification system 110 can maintain this configuration information. However, in one embodiment, if a component is available to user A, unification system 110 can manage a single page definition for user A and enable user A to access the component using desktop device 150 and / or mobile device 140. Modifications to GUI components and / or application content may be saved in the single page definition for user A, so that they can be reproduced for each user device corresponding to user A.

[0114] 6 shows a block diagram of a GUI 600 displaying a mobile application builder, according to some embodiments. The GUI 600 may show a mobile view of a GUI edited in the GUI viewer 530 as described with reference to FIG. 5. The unification system 110 may instantiate the GUI 600 in response to receiving an interaction with the device button 510. The interaction may be, for example, a click or tap that switches the view to a mobile view.

[0115] GUI 600 may include similar elements and may operate in a similar manner as GUI 500. For example, GUI 600 may include a device button 610, a save button 620, a GUI viewer 630, a component panel 640, a page panel 650, a visibility icon 660, and / or a page button 670. Device button 610 may be used to allow a user to toggle between a mobile view, as shown in GUI viewer 630, and a desktop view, as shown in GUI viewer 530.

[0116] The unification system 110 can instantiate GUI components in the GUI viewer 630 using a single page definition. In this manner, the GUI components in the GUI viewer 630 can correspond to the GUI components in the GUI viewer 530. The unification system 110 can arrange these components in a sequential manner, as described with reference to FIG. 4 . In one embodiment, an administrator can arrange the GUI components in a particular desktop layout. The unification system can then automatically generate a default mobile layout with the corresponding arrangement of the GUI components. In one embodiment, an administrator or user can distinguish between the ordering of the desktop layout and the mobile layout. For example, an administrator or user can modify the modified layout separately from the desktop labels. The unification system 110 can then store the different arrangements and use the specified arrangement when instantiating the GUI on the desktop device 150 and / or the mobile device 140, respectively.

[0117] Using GUI viewer 630, an administrator can modify the mobile GUI view of a record page. Similar to GUI 500, an administrator can use component panel 640 and GUI viewer 630 to add, remove, modify, and / or alter components of the mobile GUI displayed in GUI viewer 630. An administrator can also modify metadata using page panel 650. These modifications on the mobile GUI view may be saved and automatically replicated on the desktop view shown in GUI viewer 530. In this manner, the application builder can allow a user to edit both the desktop and mobile views of a record page. The unification system 110 can then save the changes and automatically update the GUI views, so that the edits are visible in both GUIs. Using the application builder, an administrator can quickly generate a desktop GUI and / or corresponding mobile GUI that allow users to access applications and / or data records. Similarly, an administrator can create a mobile GUI, and the unification system 110 can automatically generate a desktop version of the mobile GUI.

[0118] While the unification system 110 can automatically organize and / or replicate GUI components for desktop and mobile views, the unification system 110 can also allow an administrator to designate certain components to be visible only on certain views. For example, a user can select a component to be visible on the desktop view but not on the mobile view. This component may be marked with a visibility icon 660. Although the component may be invisible to an end user of the created GUI, an administrator can still see the component in the GUI viewer 630 and modify the component and / or accept hidden aspects of the component.

[0119] In this way, the application builder can allow an administrator to customize GUI component views. If the administrator grants the user permission, the user may also be able to customize the GUI component views. The unifying system 110 can persist these configurations across different devices and device types and instantiate the created GUI views. The unifying system 110 can manage these configurations using a single definition file that is accessed regardless of the device type issuing the request.

[0120] 7 shows a block diagram of a GUI 700 displaying an editor prompt 770, according to some embodiments. While displayed through the mobile view, the editor prompt 770 may also appear through the desktop view. The editor prompt 770 can allow an administrator to edit the configuration of a particular component. For example, the editor prompt 770 can allow editing of specific fields of the component. A component may include several tabs. The editor prompt 770 can be used to allow an administrator to modify the tabs that are visible.

[0121] Similarly, editor prompt 770 can allow an administrator to select visibility parameters for a component. As described above, an administrator may want a component to be visible in a first GUI (e.g., for desktop device 150), but may want the component to be hidden in a second GUI (e.g., for mobile device 140). Using editor prompt 770, the administrator can make this selection. Components with adjusted visibility parameters may include a visibility icon 760.

[0122] Using editor prompt 770, an administrator can define several visibility rules. For example, an administrator can create multiple device categories, such as desktop, tablet, and phone. The administrator can then define visibility parameters for each of the categories. For example, a component may be visible on a phone but not on a desktop or tablet. Using editor prompt 770, the administrator can specify and / or customize these visibility parameters. The unified system 110 can then store these parameters for the application when a particular GUI is instantiated.

[0123] In one embodiment, editor prompt 770 may include a drop-down menu that allows an administrator to specify the type of device on which a particular GUI component should be shown. For example, the drop-down menu may include a “small” option, a “large” option, and / or a blank option. In one embodiment, selecting the “small” option may indicate that the GUI component should be shown only on mobile devices 140. Similarly, the “large” option may indicate that the GUI component should be shown only on desktop devices 150. The blank option may indicate that the GUI component should be displayed on all devices. The drop-down menu may further include a “medium” option, which may correspond to tablet devices. In one embodiment, editor prompt 770 may also allow an administrator to specify a negative condition and / or select devices on which the GUI component should be hidden. Using these visibility options, an administrator can customize different GUI views across different user devices.

[0124] 8 shows a flowchart illustrating a method 800 for building a unified application according to some embodiments. Method 800 is described with reference to FIG. 1. However, method 800 is not limited to that example embodiment.

[0125] In one embodiment, unifying system 110 may utilize method 800 to manage different GUI views of an application builder. The foregoing description describes one embodiment of the implementation of method 800 with respect to GUI 500 and GUI 600, but may be applicable to any application builder GUI. Although method 800 is described with reference to unifying system 110, method 800 may be performed on any computing device, such as, for example, a computer system as described with reference to FIG. 18 , and / or processing logic, which may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof.

[0126] It should be appreciated that not all steps may be required to practice the disclosure provided herein. Moreover, as will be appreciated by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that shown in FIG.

[0127] In one embodiment, at 810, the unifying system 110 may instantiate an editor GUI that includes a first view displaying a first GUI corresponding to a first device and a second view displaying a second GUI corresponding to a second device. The first view may be GUI 500 and / or may include GUI viewer 530. The corresponding device may be desktop device 150. The unifying system 110 may identify the GUI of the particular device being edited and store modifications to the GUI components in memory for the particular device.

[0128] The second view may be GUI 600 and / or may include GUI viewer 630. The corresponding device may be a mobile device 140. The unification system 110 may allow a user or administrator to toggle between these two views to see the GUI as it appears when instantiated on the user device. Additionally, the unification system 110 may instantiate the first view and the second view using a single page definition of an application or record.

[0129] At 820, the unification system 110 can receive an edit interaction with the first view that modifies a GUI component of the first GUI. The edit interaction can include adding a component to the first GUI, removing a component from the first GUI, changing a position of a component on the first GUI, adjusting a component parameter, adjusting a visibility parameter of a component, and / or other edits. The administrator device 120 can provide the edit interaction to the unification system 110. The unification system 110 can save the configuration to a single page definition for the application or record and / or update the first view to include the modified GUI component.

[0130] At 830, the unification system 110 can, in response to receiving, modify GUI components of the second GUI that correspond to GUI components of the first GUI. In one embodiment, the unification system 110 can perform this modification using a single page definition. For example, when the administrator toggles to view the second GUI, the second GUI may be updated based on the modification performed on the first GUI. The unification system 110 can automatically replicate this modification using the shared single page definition. The administrator can continue to modify elements on the second GUI, and the unification system 110 can replicate these further modifications on the first GUI. In this manner, the unification system 110 can enable component modification across different GUI views and can enable the administrator to quickly see how potential modifications on the first GUI (e.g., displayed on the desktop device 150) may affect the second GUI (e.g., displayed on the mobile device 140).

[0131] [Navigation buttons and navigation menu]

[0132] The unification system 110 can instantiate navigation buttons and / or navigation menus. These navigation GUI elements can assist a user in navigating within different page views of an application. These GUI elements can also provide faster navigation due to their location and accessibility on the mobile device 140. A user can select different application objects using the navigation buttons and / or navigation menus. The unification system 110 can also modify objects within the navigation buttons and / or navigation menus. In one embodiment, the unification system 110 can identify the addition, deletion, and / or movement of objects on the desktop GUI view. The unification system 110 can receive these commands from the desktop device 150. The unification system 110 can then modify the navigation buttons and / or navigation menus to maintain the same personalization. Figures 9-13 illustrate navigation buttons and navigation menus.

[0133] 9 shows a block diagram of a GUI 900 displaying a navigation button 910, according to some embodiments. The navigation button 910 may operate in a manner similar to the navigation button 310 described with respect to FIG. 3A. The unified system 110 may instantiate the GUI 900 on the mobile device 140. A user viewing the GUI 900 may interact with a display screen and / or other touchscreen interface of the mobile device 140 to submit a user interaction with the navigation button 910. The user interaction may be, for example, a click or tap on the navigation button 910. The mobile device 140 may transmit this interaction to the unified system 110 and / or process the interaction locally.

[0134] In response to receiving an interaction with the navigation button 910, the mobile device 140 may display a navigation screen 920. The navigation screen 920 may be instantiated by the unified system 110 and / or may be determined internally by the mobile device 140. The navigation screen 920 may correspond to the object displayed on the navigation button 910. For example, if the navigation button 910 represents an “Accounts” object in an underlying application, selecting the navigation button 910 may display the “Accounts” home page on the navigation screen 920. In this manner, if the navigation button 910 changes to represent a different object, when the user selects the navigation button 910, the navigation screen 920 changes to represent the page of that object. This changing navigation button 910 is further described with reference to FIG. 11 .

[0135] FIG. 10 shows a block diagram of a GUI 1000 displaying a navigation menu 1030, according to some embodiments. To display the navigation menu 1030, a user can interact with a navigation button 1010. In contrast to the interaction described with respect to FIG. 9, the interaction with the navigation button 1010 may be different to reveal the navigation menu 1030. For example, a user can use a long press on the navigation button 1010 to reveal the navigation menu 1030. A long press indicates contact with the navigation button 1010 for longer than a predetermined amount of time or may be a gesture or selection that exceeds a predetermined time threshold. The mobile device 140 can measure the elapsed time corresponding to the user contact to determine whether a long press interaction is detected. In one embodiment, an operating system running on the mobile device 140 can detect long presses, short presses, and / or other gestures. In this case, a software program running on the mobile device 140 and communicating with the unified system 110 can perform a function when invoked by the operating system in response to detecting a particular gesture.

[0136] A short press may be an interaction with the navigation button 1010 that lasts for less than a predetermined amount of time. If a short press is detected on the navigation button 1010, similar to the process described in Figure 9, the mobile device 140 may alter the navigation screen 1020 to display a home page that corresponds to the object currently displayed on the navigation button 1010. In this manner, two different gestures may be applied to the navigation button 1010 to reveal the navigation menu 1030 and / or navigate to a highlighted object.

[0137] The navigation menu 1030 may include a list of objects 1035 corresponding to the application. These objects 1035 may be similar to the objects 220 described with reference to FIG. 2B. When the navigation menu 1030 is shown, the user may select an object 1035 to navigate to the selected object page. In a non-limiting example, the user may select object 1035F to navigate to the "Opportunities" object. FIG. 11 shows one embodiment of the results of this selection.

[0138] 11 shows a block diagram of a GUI 1100 displaying an updated navigation button 1110 corresponding to a selected object, according to some embodiments. When a user selects a particular object 1035 from a navigation menu 1030, the unified system 110 and / or the mobile device 140 can update the navigation button 1010 to become the navigation button 1110 and / or update the navigation screen 1020 to become the navigation screen 1120.

[0139] For example, if a user selects object 1035F to navigate to the "Opportunities" object, navigation button 1110 may be updated to display the "Opportunities" icon. Similarly, navigation screen 1120 may display the "Opportunities" home page or the object home page. In this manner, a user may be able to use navigation menu 1030 to navigate to different objects in the application.

[0140] The updated navigation button 1110 allows the user to return to the navigation screen 1120 using a short press gesture. If the user navigates to a different application page, selecting the navigation button 1110 can reveal the navigation screen. In this manner, the navigation button 1110 may be updated to reflect the “most recent” selection from the navigation menu 1030. The unification system 110 and / or the mobile device 140 can store this selection in memory, allowing the user to quickly navigate back to a previously selected object. Additionally, the user can update the navigation button 1110 by invoking the navigation menu 1030 and selecting a different object.

[0141] 12A-12F, the mobile objects 1035 listed in the navigation menu 1030 may correspond to tab objects 1245 found in the desktop version of the application GUI. In this manner, manipulation of the tab objects 1245 on the desktop device 150 may result in changes to the objects in the navigation menu 1030, and vice versa. The unified system 110 can facilitate these changes based on a single definition used for both the GUI displayed on the mobile device 140 and the GUI displayed on the desktop device 150.

[0142] 12A shows a block diagram of a GUI 1200A displaying a page including a tab object 1245, according to some embodiments. The tab object 1245 may be similar to the object 220 described with reference to FIG. 2B. The unification system 110 may instantiate the GUI 1200A for display on the desktop device 150.

[0143] 12B shows a block diagram of GUI 1200B displaying the movement of tab object 1245, according to some embodiments. Unification system 110 can instantiate GUI 1200B in response to detecting a tab object 1245 movement interaction. For example, from GUI 1200A, a user can move tab object 1245D from between tab objects 1245C and 1245E to between tab objects 1245A and 1245B. The user may have provided this gesture on desktop device 150. Desktop device 150 may have sent this modification to unification system 110. Unification system 110 can store this modification and update the ordering of tab objects 1245. Unification system 110 can store this modification as an update to a single page definition representing the page. Furthermore, because the unifying system 110 can correlate tab objects using a single page definition, the unifying system 110 can apply this modification when the page is accessed on the mobile device 140.

[0144] 12C shows a block diagram of a GUI 1200C displaying the movement of a mobile object 1235, according to some embodiments. In contrast to FIG. 10, the navigation menu 1230 includes a different ordering of objects relative to the navigation menu 1030. For example, an "Opportunities" object 1235D may be next to a "Home" object 1235A. This change may correspond to the arrangement of the tab objects 1245 shown in FIG. 12B. The navigation menu 1230 may be invoked with a gesture using the navigation button 1210.

[0145] 12A through 12C can illustrate the unification system 110's ability to track object movement in a desktop device 150 environment and translate this movement into a navigation menu 1230. This movement can preserve a specific desired ordering by the user and can be reflected on the user device being used by the user. In this manner, the unification system 110 can interactively preserve GUI object modifications, enabling faster user navigation in both the desktop device 150 environment and the mobile device 140 environment. In addition to modifying application content, the unification system 110 also enables specific modifications of GUI components in a customizable manner.

[0146] Similar to the flow described with reference to FIGS. 12A to 12C, FIGS. 12D-12F may represent a flow for adding an object to a list of objects.

[0147] FIG. 12D shows a block diagram of a GUI 1200D displaying a page including an expanded tab object 1250, according to some embodiments. Similar to the grouped and / or collapsed objects 240 described with reference to FIG. 2C, the GUI 1200D can include the expanded tab object 1250 among tab objects 1245. The expanded tab object 1250 can represent grouped objects that are currently visible due to the expansion of a particular tab object 1245. In one embodiment, a user may wish to remove the expanded tab object 1250 from the group and use the expanded tab object 1250 as a standalone object similar to the tab object 1245. In this manner, a user can drag and drop the expanded tab object 1250 into the list of tab objects 1245.

[0148] 12E shows a block diagram of a GUI 1200E displaying a page including an added tab object 1250, according to some embodiments. In response to the drag-and-drop interaction, the unification system 110 can identify the added tab object 1250 as currently being added to the list of tab objects 1245. The unification system 110 can adjust and / or resize the GUI portion representing the object to provide spacing on the GUI 1200E. In the new position, the user can interact with the added tab object 1250 to reach the corresponding object home page. Similarly, the unification system 110 can save this configuration in a single page definition to reproduce this ordering on a mobile GUI.

[0149] 12F shows a block diagram of a GUI 1200F displaying an added mobile object 1255, according to some embodiments. As seen in GUI 1200F, the added mobile object 1255 can appear in a navigation menu 1230. The ordering of the navigation menu 1230 can also correspond to the ordering of tab objects 1245 with the added tab object 1250 on the desktop GUI. In this manner, the unification system 110 can recreate a modified GUI view when modifications to the object are detected from the desktop device 150. The unification system 110 can modify the GUI displayed on the mobile device 140 to include these GUI modifications.

[0150] Although these descriptions describe the initial modification on desktop device 150, in one embodiment, the modification may be performed on mobile device 140. Unification system 110 can translate this modification into the GUI of desktop device 150.

[0151] Additionally, the unification system 110 can also apply a similar approach when an object is removed from a list. Deleting an object may not erase the underlying application data, but may remove the object from a particular GUI view. For example, if an object is deleted from a list on the desktop device 150, the unification system 110 can remove it from the list on the mobile device 140, and vice versa.

[0152] Further aspects of this GUI modification include a combination of administrator and user customization versus personalization. An administrator using the administrator device 120 can identify specific applications that users can access. In one embodiment, the administrator can also specify the GUI components that users can access, for example, using an application builder. Layered within the administrator's customization control, users can personalize their own views of the desktop or mobile GUI. As previously discussed, user control can include moving, adding, and / or deleting objects. Furthermore, users can personalize different elements within a GUI component. In this way, the unified system 110 can simultaneously support both administrator and user customization. Using a single page definition, these configurations can be stored and / or retrieved to instantiate one or more GUIs for users when the application is accessed on the mobile device 140 and / or desktop device 150.

[0153] 13 shows a flowchart illustrating a method 1300 for modifying a navigation menu, according to some embodiments. The method 1300 is described with reference to FIG. 1. However, the method 1300 is not limited to that example embodiment.

[0154] In one embodiment, unifying system 110 can utilize method 1300 to modify a navigation menu, such as navigation menu 1230. The foregoing description describes one embodiment of the execution of method 1300 with respect to GUIs 1200A-1200F, but may be applicable to any GUI, including a navigation menu. Although method 1300 is described with reference to unifying system 110, method 1300 may be performed on any computing device, such as, for example, a computer system as described with reference to FIG. 18 , and / or processing logic, which may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof.

[0155] It should be appreciated that not all steps may be required to practice the disclosure provided herein. Moreover, as will be appreciated by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that shown in FIG.

[0156] In one embodiment, at 1310, unified system 110 may instantiate a first GUI menu configured to display on a first device, the first GUI menu including a list of objects. The first GUI menu may be, for example, navigation menu 1230. Navigation menu 1230 may be displayed on a first device, such as mobile device 140. The list of objects may be objects 1235. Using the objects, a user can navigate to different object homepages.

[0157] At 1320, the unified system 110 can instantiate a second GUI menu configured to display on the second device, the second GUI menu including a list of objects. The second GUI menu may be, for example, a list of tab objects 1245. The list of tab objects 1245 may be displayed on the second device, such as the desktop device 150. Similar to the mobile scenario, the user can navigate to different object homes using the tab objects 1245.

[0158] At 1330, unification system 110 may receive a modification interaction at the second GUI that modifies an object in the list of objects on the second GUI menu. For example, a user at desktop device 150 may modify the list of tab objects 145. The user may change the ordering, add objects, and / or remove objects. In this case, unification system 110 may receive the modification interaction from desktop device 150. Unification system 110 may store the modification as an update to a single record representing the page.

[0159] At 1340, in response to receiving, the unification system 110 can modify the list of objects on the first GUI menu according to the modification interaction. The unification system 110 can access the records and send commands to the mobile device 140 to modify the navigation menu 1230 according to the changes detected from the desktop device 150. For example, the unification system 110 can change the ordering of the objects 1235, remove objects 1235, and / or add objects 1235. In this case, the unification system 110 can modify the list of objects, so that the customization selections are preserved between different GUIs. The unification system 110 can automatically perform method 1300 in response to detecting the modifications on the mobile device 140 and / or the desktop device 150.

[0160] Although the first device has been described as a mobile device 140 and the second device as a desktop device 150, these may be reversed. In one embodiment, the devices may also be other devices and / or software applications, such as a tablet or an internet browser. For example, a user may access an application using two windows on a computer. Modifying the list of objects in the first window may result in modifying the list of objects in the second window.

[0161] [Cursor Gesture Control]

[0162] As described further below with respect to FIGS. 14A-15, the unifying system 110 can further generate a cursor on the GUI display. This cursor can allow a user to manipulate portions of the GUI without directly interacting with those portions. For example, when the GUI is displayed on the mobile device 140, the user can press on the bottom half of the GUI to cause a cursor to appear in the top portion. In this manner, the unifying system 110 can instantiate a mobile GUI that includes accessibility elements and allows a user to access the top portion of the GUI while controlling the bottom portion of the GUI. GUI content and / or program elements may be sourced from the unifying system 110. The mobile device 140 can then execute these program elements to display the corresponding GUI and / or cursor control. In this manner, the cursor control described herein may apply to any program that runs on a computing device and displays a GUI.

[0163] 14A shows a block diagram of a GUI 1400A displaying a mobile page including a cursor button 1410, according to some embodiments. The cursor button 1410 occupies space on the GUI 1400A and allows a user to create a cursor in a distinct portion of the GUI 1400A. In one embodiment, the cursor button 1410 may occupy the same space as another button. For example, the cursor button 1410 may occupy the same space as the search button 314. Although the cursor button 1410 may occupy the same space as the search button 314, accessing the cursor button 1410 involves using a different gesture than accessing the search button 314.

[0164] In one embodiment, using the search button 314 may include a short press, while using the cursor button 1410 may include a long press. When the GUI 1400A is displayed on the mobile device 140, the mobile device 140 may determine the type of interaction detected based on the timing of the press. Additionally, although the cursor button 1410 may be shown as occupying the space of the search button 314, the cursor button 1410 may occupy other space on the GUI 1400A, and resulting in a particular interaction (e.g., a long press) may initiate a cursor button 1410 command.

[0165] In addition to cursor buttons 1410, GUI 1400A can include action buttons 1420. Action buttons 1420 can be similar to action buttons 390 described with reference to FIG. 3C. As described below, cursor buttons 1410 can be used to allow a user to select action buttons 1420 from a display screen. A user interacting with cursor buttons 1410 can generate a cursor that can be scrubbed across the screen to select the desired action button 1420.

[0166] 14B shows a block diagram of a GUI 1400B displaying a mobile page including a visible cursor 1440, according to some embodiments. To reveal the cursor 1440, a user can invoke the cursor button 1410 using an interaction 1430. For example, the interaction 1430 may be a long press, a double tap, a drawing of a shape, and / or other interaction on the cursor button 1410. In response to detecting the long press, the mobile device 140 can display the cursor 1440. The unified system 110 can generate the mobile GUI but can enable the mobile device 140 to manage processing for the cursor button interaction.

[0167] After displaying cursor 1440, the user can scrub along the bottom of the screen to move cursor 1440. For example, this movement can be seen in FIG. 14C. FIG. 14C shows a block diagram of GUI 1400C displaying a mobile page including movement of cursor 1440, according to some embodiments. As seen when moving from GUI 1400B to GUI 1400C, when the user moves interaction 1430 to the right, cursor 1440 can also move to the right. Cursor 1440 can move from selecting action button 1420A to selecting action button 1420B. The user can also move interaction 1430 left to move cursor 1440 left.

[0168] In one embodiment, this movement can correspond to a long press. That is, the user can continuously tap or hold on the display screen to generate the interaction 1430. As the user moves the interaction 1430, the user can continue to press the display screen. The user can move the interaction 1430 left or right to move the cursor 1440 left or right, respectively. Additionally, this interaction can reveal other action buttons 1420, such as action buttons hidden beneath action button 1420D. This scrolling movement for the cursor 1440 can enable increased accessibility. A user holding the mobile device 140 can interact with the lower portion of the screen while controlling actions at the top of the screen. This split aspect of GUI operation can allow the user to navigate the GUI using, for example, one hand. This navigation can increase navigation comfort.

[0169] After generating cursor 1440, the user can release interaction 1430 and / or stop interaction 1430 to select an application button. For example, if interaction 1430 is a long press, releasing the press can indicate selection of the action button 1420 currently highlighted by cursor 1440. Mobile device 140 can then generate a GUI corresponding to the selection and / or send a request to unified system 110 to instantiate the requested GUI. This selection can execute the action or action button 1420 corresponding to cursor 1440.

[0170] As previously discussed, interaction 1430 can appear in different portions of GUI 1400B. For example, rather than pressing search button 314, cursor button 1410 may be represented by a portion of the screen or GUI. For example, cursor button 1410 may be defined as the bottom half or bottom third of the screen. When mobile device 140 detects interaction 1430 that invokes cursor button 1410, mobile device 140 can display cursor 1440.

[0171] Similarly, cursor 1440 may be an object that moves in response to movement of interaction 1430. In one embodiment, this movement may be unidirectional. For example, as interaction 1430 moves left or right, cursor 1440 may also move left or right. Cursor 1440 may move along a designated track and / or may attach to an icon displayed on GUI 1400B or GUI 1400C. In one embodiment, cursor 1440 may not follow a designated track and may be movable to any position.

[0172] In some embodiments, cursor 1440 may be moved to a two-dimensional position. This movement may be similar to mouse cursor movement. Interaction 1430 may instruct cursor 1440 to move to different parts of the GUI and / or interact with different GUI elements. This movement may also provide useful accessibility options for users to navigate the GUI.

[0173] 15 shows a flowchart illustrating a method 1500 for generating a cursor 1440 according to some embodiments. The method 1500 is described with reference to FIG. 1. However, the method 1500 is not limited to that exemplary embodiment.

[0174] In one embodiment, unified system 110 and / or mobile device 140 can utilize method 1500 to generate GUI cursor 1440. The foregoing description describes one embodiment of the execution of method 1500 with respect to GUIs 1400A-1400C, but may be applicable to any GUI that includes a cursor. Although method 1500 is described with reference to unified system 110 and / or mobile device 140, method 1500 may be performed on any computing device, such as, for example, a computer system as described with reference to FIG. 18 , and / or processing logic, which may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof.

[0175] It should be appreciated that not all steps may be required to practice the disclosure provided herein. Moreover, as will be appreciated by those skilled in the art, some of the steps may be performed simultaneously or in a different order than that shown in FIG.

[0176] In one embodiment, at 1510, the unifying system 110 and / or the mobile device 140 can instantiate a GUI having a first GUI portion and a second GUI portion. The unifying system 110 can provide a command to the mobile device 140 to instantiate a particular GUI. The mobile device 140 can then display the instantiated GUI on a display screen. The mobile device 140 may, for example, display GUI 1400A. GUI 1400A may include a first GUI portion representing an action button 1420 and / or a second GUI portion representing a cursor button 1410.

[0177] At 1520, the mobile device 140 can receive a selection interaction 1430 in the first GUI portion. At 1530, the mobile device 140 can identify the selection interaction in the first GUI portion as a cursor 1440 gesture. The selection interaction 1430 can be a specific interaction that invokes the cursor button 1410. For example, the interaction 1430 can be a long press, or a double tap, or a specific drawn shape. The mobile device 140 can determine the selection interaction based on programmed logic provided by the unified system 110 and / or stored locally on the mobile device 140.

[0178] At 1540, in response to identifying the selection interaction 1430, the mobile device 140 may generate a GUI cursor 1440 over the second GUI portion. As described above, this GUI cursor 1440 may enable a user to interact with the first GUI portion to provide control over the second GUI portion. The user may move the cursor using a scrubbing or scrolling motion to select a different GUI button, such as the action button 1420. Releasing the interaction 1430 may indicate a user selection of the action button 1420 or an element of the second GUI portion. Based on the selection, the mobile device 140 may send the selection to the unified system 110 for processing and / or may handle the processing locally.

[0179] [Application Framework and Application Selection]

[0180] 16A-17, the unification system 110 can also further facilitate switching between different applications and providing an updated GUI depending on the selected application. In this manner, the unification system 110 can provide a framework for realizing different applications and application types while maintaining uniformity of the GUI instantiated on the mobile device 140 and the desktop device 150. The unification system can also load different applications developed by different parties and maintain a consistent layout for each application.

[0181] 16A shows a block diagram of a GUI 1600A displaying a mobile application menu page, according to some embodiments. The GUI 1600A may be similar to the GUI 300A shown in FIG. 3A. The GUI 1600A may be instantiated by the unified system 110 and / or displayed on the mobile device 140.

[0182] GUI 1600A can present a menu page displaying objects 1620 of a particular application. A user can access the menu page by, for example, selecting menu button 318 as described with reference to FIG. 3A . GUI 1600A can include an application menu button 1610, which can be similar to application menu button 315. Interacting with application menu button 1610 can allow a user to select a different application. Interacting with an object 1620 can allow a user to view a page corresponding to the object 1620. GUI 1600A can present objects 1620 as a list 1630 for ease of navigation. As described above with respect to FIG. 10 , the GUI can include a navigation button that can reveal a navigation menu 1030 corresponding to the enumerated objects 1620. In one embodiment, navigation menu 1030 can be an abbreviated version of the list 1630 seen on the menu page.

[0183] The list 1630 and the object 1620 may correspond to the currently selected application. As described with respect to Figure 16B and previously described with respect to Figure 2A, the user may select a different application. This selection may alter the list 1630, the object 1620, and / or the navigation menu 1630.

[0184] FIG. 16B shows a block diagram of a GUI 1600B displaying a mobile application selection page 1605, according to some embodiments. The unified system 110 can instantiate the GUI 1600B to be displayed on the mobile device 140 in response to receiving a selection on an application menu button 1610. Listed on the application selection page 1605 may be application buttons 1615. The application buttons 1615 may be similar to the application buttons 215 described with reference to FIG. 2A. Selecting a particular application button 1615 can allow a user to select among different available applications. In one embodiment, the GUI 1600A may correspond to application button 1615A. However, selecting a different application button, such as application button 1615B, can result in a different menu page and / or a different corresponding object.

[0185] As can be seen from these selection objects, the unification system 110 can support multiple applications for a user to select and / or use. The unification system 110 can provide a framework that supports a GUI view for the cloud computing platform and / or enabled applications. In one embodiment, the cloud computing platform can utilize standard-supplied applications that can be pre-programmed. The cloud computing platform can also allow users or administrators to create their own applications. In one embodiment, users may be able to download applications from third parties and / or use an application marketplace or application exchange. Users can install these applications for use with the cloud computing platform.

[0186] In this manner, the unified system 110 can support different types of applications and create a cohesive GUI experience across desktop device 150 and mobile device 140 environments. Creating this cohesive look and feel across different applications, application types, and / or different application sources can enable greater scalability and customization for administrators and / or users. In this manner, the unified system 110 can act as or be included within a framework or container for managing different applications.

[0187] Returning to GUI 1600B, the user may decide to select application button 1615B. The application corresponding to application button 1615B may differ in type and / or source from the previously viewed application corresponding to application button 1615A. In response to the selection, mobile device 140 may send an indication of the selection to unification system 110. Unification system 110 may then instantiate a corresponding GUI, such as GUI 1600C.

[0188] 16C shows a block diagram of a GUI 1600C displaying an updated mobile application menu page, according to some embodiments. This selection can change the available objects and navigation menus based on the application's correspondence.

[0189] GUI 1600C may include an application menu button 1610 similar to GUI 1600A. Interacting with application menu button 1610 may instantiate GUI 1600B and allow the user to select another application button 1615.

[0190] Because the user selected another application, the unified system 110 may instantiate the other application and provide updated objects 1640, updated lists 1650, updated navigation menus 1680, updated navigation buttons 1660, and / or updated navigation objects 1670. These updated components may be similar in function to the previous objects and navigation elements; however, the updated versions may correspond to the newly selected application and application button 1615.

[0191] For example, list 1650 and object 1640 may represent objects of the newly selected application. In response to the selection, mobile device 140 may now support the newly selected application and allow the user to interact with the corresponding object 1640.

[0192] Similarly, navigation menu 1680 has been updated to include navigation object 1670 corresponding to object 1640. Navigation menu 1680 may be updated even if it is collapsible. In this manner, when a user interacts with navigation button 1660 to reveal navigation menu 1680, the user can select from navigation object 1670 to navigate to different portions of the newly selected application. The newly selected application corresponding to application button 1615B may include its own data records and / or executable program set, which may differ from the application corresponding to application button 1615A. However, unification system 110 may be able to allow a user to switch between these applications on mobile device 140 and / or desktop device 150. In this manner, unification system 110 can act as a framework or container, supporting different applications while maintaining a look and feel that may be similar across the different applications.

[0193] 17 shows a flowchart illustrating a method 1700 for replacing a list of objects corresponding to an application, according to some embodiments. Method 1700 is described with reference to FIG. 1. However, method 1700 is not limited to that example embodiment.

[0194] In one embodiment, unifying system 110 can utilize method 1700 to update and / or replace a list of objects based on a selected application. The foregoing description describes one embodiment of the execution of method 1700 with respect to GUIs 1600A-1600C, but may be applicable to any GUI that supports multiple applications. Although method 1700 is described with reference to unifying system 110, method 1700 may be performed on any computing device, such as, for example, the computer system described with reference to FIG. 18 , and / or processing logic, which may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof.

[0195] It should be appreciated that not all steps may be required to practice the disclosure provided herein. Moreover, as will be understood by one of ordinary skill in the art, some of the steps may be performed simultaneously or in a different order than that shown in FIG.

[0196] In one embodiment, at 1710, the unification system 110 can instantiate a GUI corresponding to a first application, the GUI including a first list of objects corresponding to the first application. For example, the unification system 110 can generate GUI 1600A having a list 1630 of objects 1620. The objects 1620 can correspond to a particular application. While an application is selected, a user can interact with the application through various objects and / or GUI components. These interactions can manipulate records, programs, and / or commands corresponding to the application.

[0197] At 1720, the unification system 110 may receive a selection interaction in the GUI selecting a second application. For example, the mobile device 140 may display GUI 1600A and / or applications menu button 1610. The user may select applications menu button 1610. The mobile device 140 may transmit this selection to the unification system 110. In response, the unification system 110 may transmit a list of available applications and / or instantiate available applications button 1615 to be displayed in GUI 1600B. The user may then select applications button 1615 from selection page 1605. The mobile device 140 may process this selection and may transmit an indication of this selection to the unification system 110.

[0198] At 1730, in response to receiving the selection interaction, the unification system 110 can replace the first list of objects with a second list of objects corresponding to the second application. The unification system 110 can instantiate GUI 1600C, for example. The unification system 110 can replace list 1630 with list 1650. Similarly, the unification system 110 can replace object 1620 with object 1640. The unification system 110 can also modify navigation menu 1680 to include updated navigation menu 1680 with updated navigation object 1670 and navigation button 1660. Using this GUI, a user can navigate and / or interact with different applications as provided by the framework managed by the unification system 110.

[0199] 16A-17 illustrate different application options for mobile device 140, unification system 110 can also maintain these different applications for desktop device 150. As discussed above, modifications performed on desktop device 150 can be replicated on mobile device 140 by unification system 110. In this manner, unification system 110 can manage different administrator customization parameters, different application customization parameters, and / or different user personalization parameters, so that a particular look and feel can be replicated across different user devices. In this manner, unification system 110 can help organize specific GUI layouts for users for different user devices. Users may be able to more quickly navigate within different application object and record pages across multiple types of user devices using the framework and GUIs instantiated by unification system 110.

[0200] Exemplary Computer System

[0201] Various embodiments can be implemented using one or more well-known computer systems, such as, for example, computer system 1800 shown in Figure 18. One or more computer systems 1800 can be used, for example, to implement any of the embodiments discussed herein, as well as combinations and subcombinations thereof.

[0202] Computer system 1800 may include one or more processors (also referred to as central processing units or CPUs), such as processor 1804. Processor 1804 may be connected to a communication infrastructure or bus 1806.

[0203] The computer system 1800 may further include user input / output devices 1803 , such as a monitor, keyboard, pointing device, etc., that may communicate with a communications infrastructure 1806 through a user input / output interface 1802 .

[0204] One or more of the processors 1804 may be a graphics processing unit (GPU). In one embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. A GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common in computer graphics applications, images, video, etc.

[0205] The computer system 1800 may further include a main or primary memory 1808, such as random access memory (RAM). The main memory 1808 may include one or more levels of cache. The main memory 1808 may store control logic (i.e., computer software) and / or data therein.

[0206] Computer system 1800 may further include one or more secondary storage devices or memories 1810. Secondary memory 1810 may include, for example, a hard disk drive 1812 and / or a removable storage device or drive 1814. Removable storage drive 1814 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, a tape backup device, and / or any other storage device / drive.

[0207] The removable storage drive 1814 can interact with a removable storage unit 1818. The removable storage unit 1818 may include a computer-usable or readable storage device having stored thereon computer software (control logic) and / or data. The removable storage unit 1818 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and / or any other computer data storage device. The removable storage drive 1814 can read from and / or write to the removable storage unit 1818.

[0208] Secondary memory 1810 may also include other means, devices, components, intermediaries, or other approaches that allow computer programs and / or other instructions and / or data to be accessed by computer system 1800. Such means, devices, components, intermediaries, or other approaches may include, for example, removable storage unit 1822 and interface 1820. Examples of removable storage unit 1822 and interface 1820 may include a program cartridge and cartridge interface (such as those found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and / or any other removable storage unit and associated interface.

[0209] Computer system 1800 may further include a communications or network interface 1824. Communications interface 1824 may enable computer system 1800 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referred to by reference numeral 1828). For example, communications interface 1824 may enable computer system 1800 to communicate with external or remote devices 1828 over communications path 1826, which may be wired and / or wireless (or a combination thereof), and which may include any combination of a LAN, a WAN, the Internet, etc. Control logic and / or data may be transmitted to and from computer system 1800 via communications path 1826.

[0210] Computer system 1800 may also be a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet, a smartphone, a smartwatch or other wearable, an appliance, part of the Internet of Things, and / or an embedded system, or any combination thereof, to name a few non-limiting examples.

[0211] The computer system 1800 may be used in a variety of cloud computing solutions, including, but not limited to, remote or distributed cloud computing solutions, local or on-premise software ("on-premise" cloud-based solutions), "as a service" models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBS), and the like). The application may be a client or server accessing or hosting any application and / or data through any delivery paradigm, including infrastructure as a service (MBaaS), infrastructure as a service (IaaS), etc., and / or hybrid models including any combination of the foregoing examples or other service or delivery paradigms.

[0212] Any applicable data structures, file formats, and schemas in computer system 1800 may be derived from standards, including, but not limited to, JavaScript® Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations, alone or in combination. Alternatively, proprietary data structures, formats, or schemas may be used exclusively or in combination with known or open standards.

[0213] In some embodiments, a tangible, non-transitory device or article of manufacture comprising a tangible, non-transitory computer-usable or readable medium having control logic (software) stored thereon may further be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 1800, main memory 1808, secondary memory 1810, and removable storage units 1818 and 1822, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (e.g., computer system 1800, etc.), can cause the data processing devices to operate as described herein.

[0214] Based on the teachings contained herein, it will be apparent to one skilled in the art how to make and use embodiments of the present disclosure using data processing devices, computer systems, and / or computer architectures other than those shown in Figure 18. In particular, embodiments may operate with software, hardware, and / or operating system implementations other than those described herein.

[0215] It is to be appreciated that the Detailed Description section, and not the other sections, is intended to be used to interpret the claims, which may describe one or more example embodiments, but not all, contemplated by the inventors, and are therefore not intended to limit the scope of this disclosure or the appended claims in any way.

[0216] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible and are within the scope and spirit of the present disclosure. For example, without limiting the generality of this paragraph, the embodiments are not limited to the software, hardware, firmware, and / or entities illustrated in the drawings and / or described herein. Moreover, the embodiments (whether or not explicitly described herein) have significant utility for fields and applications beyond the examples described herein.

[0217] Embodiments have been described herein using functional building blocks that illustrate implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for ease of description. Alternative boundaries may be defined so long as the specified functions and relationships (or their equivalents) are appropriately performed. Furthermore, alternative embodiments may implement functional blocks, steps, operations, methods, etc. using an ordering different from that described herein.

[0218] References herein to “one embodiment,” “one embodiment,” “one exemplary embodiment,” or similar phrases indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments necessarily include that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with one embodiment, it is within the knowledge of one of ordinary skill in the art to incorporate such feature, structure, or characteristic into other embodiments, whether or not explicitly mentioned or described herein. Furthermore, some embodiments may be described using the terms “coupled” and “connected,” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms “connected” and / or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term “coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0219] The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. 1. A computer-implemented method comprising: identifying a first graphical user interface (GUI) corresponding to a first device, the first GUI including a plurality of GUI components of an application in a first configuration, the plurality of GUI components including a first component, a second component, and a third component; sequentially assigning a value to each GUI component of the plurality of GUI components based on the position of the plurality of GUI components in the first arrangement to generate a set of assigned values, the set of assigned values ​​defining an order of the plurality of GUI components, the value assigned to the second component being greater than the value assigned to the first component, and the value assigned to the third component being greater than the value assigned to the second component; storing the set of assigned values ​​in a memory; receiving a request to view the application on a second device; retrieving the set of assigned values ​​from the memory in response to said receiving; sending a GUI command to the second device to cause the second device to generate a second GUI, the second GUI including the plurality of GUI components in a second arrangement based on the order defined by the set of assigned values ​​retrieved from the memory; the computer-implemented method comprising: receiving a reordering from the second device in response to a user modifying a position of a GUI component of the plurality of GUI components within the second GUI; updating the set of assigned values ​​stored in the memory to incorporate the modification of the position of the GUI component, the set of assigned values ​​defining an updated order; sending a GUI command to the first device to cause the first device to generate a third GUI, the third GUI including the plurality of GUI components arranged according to the updated order defined by the updated set of assignment values; further comprising The computer-implemented method, wherein the second GUI and the third GUI are different sizes.

2. The computer-implemented method of claim 1 , wherein the second arrangement includes the plurality of GUI components in a vertical column according to an order defined by the set of assigned values.

3. 2. The computer-implemented method of claim 1, wherein the plurality of GUI components are arranged horizontally in the first arrangement on the first GUI, and the plurality of GUI components are arranged vertically in the second arrangement on the second GUI.

4. The computer-implemented method of claim 1 , wherein the first device is a desktop computing device and the second device is a mobile computing device.

5. determining that a user has been granted permission to access the plurality of GUI components of the application; In response to the determination, sending a GUI command to the first device to cause the first device to generate the first GUI; The computer-implemented method of claim 1 further comprising:

6. The computer-implemented method of claim 1 , wherein the memory is a cloud computing database.

7. Memory and coupled to the memory; identifying a first graphical user interface (GUI) corresponding to a first device, the first GUI including a plurality of GUI components of an application in a first configuration, the plurality of GUI components including a first component, a second component, and a third component; sequentially assigning values ​​to each GUI component of the plurality of GUI components based on the positions of the plurality of GUI components in the first arrangement to generate a set of assigned values, the set of assigned values ​​defining an order of the plurality of GUI components, the value assigned to the second component being greater than the value assigned to the first component, and the value assigned to the third component being greater than the value assigned to the second component; storing the set of assigned values ​​in a memory; receiving a request to view the application on a second device; retrieving the set of assigned values ​​from the memory in response to said receiving; Sending a GUI command to the second device to cause the second device to generate a second GUI, the second GUI including the plurality of GUI components in a second arrangement based on the order defined by the set of assigned values ​​retrieved from the memory. at least one processor configured to Including, The at least one processor receiving a reordering from the second device in response to a user modifying a position of a GUI component of the plurality of GUI components within the second GUI; updating the set of assigned values ​​stored in the memory to incorporate the modification of the position of the GUI component, the set of assigned values ​​defining an updated order; Sending a GUI command to the first device to cause the first device to generate a third GUI, the third GUI including the plurality of GUI components arranged according to the updated order defined by the updated set of assignment values. It is further structured as follows: The system, wherein the second GUI and the third GUI are different sizes.

8. The system of claim 7 , wherein the second arrangement includes the plurality of GUI components in a vertical column according to an order defined by the set of assigned values.

9. 8. The system of claim 7, wherein the plurality of GUI components are arranged horizontally in the first arrangement on the first GUI, and the plurality of GUI components are arranged vertically in the second arrangement on the second GUI.

10. The system of claim 7 , wherein the first device is a desktop computing device and the second device is a mobile computing device.

11. The at least one processor determining that a user has been granted permission to access the plurality of GUI components of the application; In response to the determination, sending a GUI command to the first device to cause the first device to generate the first GUI. The system of claim 7 further configured to:

12. The system of claim 7 , wherein the memory is a cloud computing database.

13. A non-transitory computer-readable medium having stored thereon instructions that, when executed by at least one computing device, cause the at least one computing device to: identifying a first graphical user interface (GUI) corresponding to a first device, the first GUI including a plurality of GUI components of an application in a first configuration, the plurality of GUI components including a first component, a second component, and a third component; sequentially assigning a value to each GUI component of the plurality of GUI components based on a position of the plurality of GUI components in the first arrangement to generate a set of assigned values, the set of assigned values ​​defining an order of the plurality of GUI components, the value assigned to the second component being greater than the value assigned to the first component, and the value assigned to the third component being greater than the value assigned to the second component; storing the set of assigned values ​​in a memory; receiving a request to view the application on a second device; retrieving the set of assigned values ​​from the memory in response to said receiving; sending a GUI command to the second device to cause the second device to generate a second GUI, the second GUI including the plurality of GUI components in a second arrangement based on the order defined by the set of assigned values ​​retrieved from the memory; and and performing operations including: receiving a reordering from the second device in response to a user modifying a position of a GUI component of the plurality of GUI components within the second GUI; updating the set of assigned values ​​stored in the memory to incorporate the modification of the position of the GUI component, the set of assigned values ​​defining an updated order; sending a GUI command to the first device to cause the first device to generate a third GUI, the third GUI including the plurality of GUI components arranged according to the updated order defined by the updated set of assignment values; further comprising The non-transitory computer-readable medium, wherein the second GUI and the third GUI are different sizes.

14. The non-transitory computer-readable medium of claim 13 , wherein the second arrangement includes the plurality of GUI components in a vertical column according to an order defined by the set of assigned values.

15. 14. The non-transitory computer-readable medium of claim 13, wherein the plurality of GUI components are arranged horizontally in the first arrangement on the first GUI, and the plurality of GUI components are arranged vertically in the second arrangement on the second GUI.

16. 14. The non-transitory computer-readable medium of claim 13, wherein the first device is a desktop computing device and the second device is a mobile computing device.

17. The operation is determining that a user has been granted permission to access the plurality of GUI components of the application; In response to the determination, sending a GUI command to the first device to cause the first device to generate the first GUI; 14. The non-transitory computer-readable medium of claim 13, further comprising:

Images