LAUNCHPAD FOR MULTI APPLICATION USER INTERFACE

In one general aspect, a method and system are described for generating a customizable web interface for launching a plurality of applications on a client computing device. The system and method may include obtaining access to a plurality of services for configuring the plurality of applications on the customizable web interface. At least one of the plurality of services determines a role for a user accessing the client computing device. The system and method may also include registering a namespace for each application, generating a plurality of graphical targets leading to selectable access of a portion of the plurality of applications, embedding, in the customizable web interface, the plurality of graphical targets corresponding to the portion, and accessing at least one service to generate and display, on a display device of the client computing device, the customizable web interface with the plurality of graphical targets for the portion.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to and the benefit of U.S. Provisional Application No. 62/335,888, filed May 13, 2016, U.S. Provisional Application No. 62/335,892, filed May 13, 2016, U.S. Provisional Application No. 62/335,895, filed May 13, 2016, U.S. Provisional Application No. 62/335,897, filed May 13, 2016, U.S. Provisional Application No. 62/335,899, filed May 13, 2016, U.S. Provisional Application No. 62/335,873, filed May 13, 2016, U.S. Provisional Application No. 62/335,875, filed May 13, 2016, U.S. Provisional Application No. 62/335,879, filed May 13, 2016, U.S. Provisional Application No. 62/335,883, filed May 13, 2016, U.S. Provisional Application No. 62/335,886, filed May 13, 2016, and U.S. Provisional Application No. 62/335,887, filed May 13, 2016, each of which provisional application is incorporated by reference in its entirety.

TECHNICAL FIELD

This description generally relates to user interfaces and user experiences. The description, in particular, relates to systems and techniques for providing a user experience for accessing and viewing data and information related to multiple software applications on a computing device.

BACKGROUND

Users may utilize or interact with multiple software applications at the same time. The multiple applications may be hosted on the same or different types of computer platforms or systems and accessed from the users' client devices. In example implementations, the different types of computer platforms or systems may include, for example, SAP HANA, SAP ABAP, or other enterprise-type computer platforms or systems.

In example implementations, the suite of the multiple applications which an enterprise may deploy (and which users may need to use for their work) may be large. A sample of the large number of applications that may be deployed by an enterprise for its operations may, for example, include applications in the areas or domains of Finance, R&D, Engineering, Human Resources, Manufacturing, etc. Different subsets of these applications may be used in the work of enterprise personnel, who, for example, may have a variety of different roles. Each user may have a need to use a different respective subset of the multiple applications, based, for example, on the user's role in the enterprise.

Consideration is now given to a launchpad for entry into multiple applications and facilitating a user's use of a different respective subset of the multiple applications.

SUMMARY

A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a computer-implemented method for generating a customizable web interface for launching a plurality of applications on a client computing device.

The method may include obtaining access to a plurality of services for configuring the plurality of applications on the customizable web interface. At least one of the plurality of services may determine a role for a user accessing the client computing device. The method may also include registering a namespace for each application in the plurality of applications and generating a plurality of graphical targets leading to selectable access of a portion of the plurality of applications. The plurality of graphical targets may be configured for display in the customizable web interface. The portion may be selected based on the role of the user. The method may also include embedding, in the customizable web interface, the plurality of graphical targets corresponding to the portion of the plurality of applications and accessing at least one of the plurality of services to generate and display, on a display device of the client computing device, the customizable web interface with the plurality of graphical targets for the portion. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations may include one or more of the following features. The method further including selecting a different portion of the plurality of applications and display a different plurality of graphical targets for the different portion in the customizable web interface, in response to detecting that a role of the user is modified. The method further including using a runtime configuration to populate the customizable web interface with configuration settings for the plurality of applications according to the role. The method where the configuration settings for each of the plurality of applications include static configuration settings, initial configuration data, and query parameters for embedding each application in the customizable web interface, where the query parameters pertain to a URL associated with the customizable web interface. The method where the customizable web interface is a webpage and embedding a plurality of graphical targets for accessing the plurality of applications uses inline frames on the webpage. The method where the customizable web interface is a self-contained graphical component with access to a document object model to display the portion of the plurality of graphical targets. The method where the customizable web interface is adapted to provide a user with an application-to-application navigation function, a personalization function, a role-based application assignment function, a search function, and an incident creation function. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

The details of one or more implementations are set forth in the accompanying drawings and the description below. Further features of the disclosed subject matter, its nature and various advantages will be more apparent from the accompanying drawings, the following detailed description, and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a screen shot of an example personalized user interface (UI) display, in accordance with the principles of the present disclosure.

FIG. 1B is an illustration showing an example login screen displayed in a shell main container.

FIG. 1C is an illustration showing an example launchpad displayed in a shell main container.

FIG. 1D is an illustration showing an example active application screen (an overview page) displayed in a shell main container.

FIG. 1E is an illustration showing an example object page displayed in a shell main container.

FIG. 1F is an illustration showing an example footer toolbar.

FIG. 1G is an illustration showing an example me area that can be displayed in a left container.

FIG. 1H is an illustration showing an example notification area that can be displayed in a right container.

FIG. 1I is an illustration showing an example copilot user interface.

FIG. 1J is an illustration of a timeline user interface that can display timeline entries.

FIG. 2 is a diagram of an example system that can implement the user interfaces and user experiences described herein.

FIG. 3 is a diagram of an example system that can implement the launchpad for the user interfaces and user experiences described herein.

FIG. 4 is an example screenshot depicting examples of the launchpad carrying out navigation and discovery tasks.

FIGS. 5A-5B illustrate screenshots of example launchpad user interfaces.

FIG. 6 shows an example page of the Tiles Catalog, which visually depicts a tile for selection (e.g., for inclusion in the personalized tile groups or tile arrays on the home page of web interface).

FIG. 7 is an illustration of an example tile/container structure, in accordance with the principles of the present disclosure.

FIG. 8 is an illustration of an example tile setting mode dialog, in accordance with the principles of the present disclosure.

FIGS. 9A-9B is an illustration of an example user home page, which includes customized groups of array of tiles and a list of links, which represent different applications that the user may have a need or want to navigate to or use, in accordance with the principles of the present disclosure.

FIG. 10 is a schematic diagram which illustrates example relationships between component floorplans of a web interface that may be included or supported by an UI infrastructure, in accordance with the principles of the present disclosure.

FIG. 1I is an example content model for a launchpad, in accordance with the principles of the present disclosure.

FIG. 12 is an example flow describing authorization handling, in accordance with the principles of the present disclosure.

FIG. 13 is an example architecture for user assignment and authorizations of content, in accordance with the principles of the present disclosure.

FIG. 14 is an illustration of an example method that includes generating a customizable web interface for launching a plurality of applications on a client computing device in accordance with the principles of the present disclosure.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

A client computer device structure or framework provides a launchpad for a web interface for access to, or interaction with, a suite of multiple and diverse applications (or data sources), in accordance with the principles of the present disclosure. The launchpad can be used for the multiple and diverse applications and may, for example, provide services to a user for application-to-application navigation, personalization, search, and incident creation. The launchpad may be designed to provide a common, same, or unified user experience (UX) to the user when launching, accessing, or interacting with one or more of the multiple applications. In an example implementation, a backend or gateway computer system (which may be connected to multiple applications or hosts) may generate the launchpad. The launchpad may be delivered or presented as a web page on the client computer device and serve as a single web-based entry point for multiple applications and analytics across platforms and devices.

The launchpad, which is customized or personalized for a user, may also be referred to as the “personalized UI”, “personalized web interface”, “home page,” or “home screen” herein. The launchpad may be the first page that a user sees after the user has logged in. The launchpad may be a shell that hosts UI applications (e.g., apps) and provides the UI apps with services such as navigation, personalization, embedded support, and application configuration. The launchpad may represent an entire client containing ross-functionality (e.g., search, notifications, navigation, etc.) and an interface for hosting and managing all content (e.g., apps, catalogs, etc.).

The content of the personalized UI may be organized in one or more containers (e.g., main or center “shell” container, left container, right container) for display on a display screen of a client computer device. The main container may contain the launchpad (e.g., home page), which may act as the starting or focal location for initiating application-to-application navigation, personalization, search, and incident creation, just to name a few examples.

Each of the multiple applications may be represented by, or delivered via, content (e.g., a graphical user element (GUI), link, tile, factsheet, or other object) on the launchpad. Further, the content of the launchpad may be customized or personalized to a user (e.g., based on user role, authorization level, user interests or needs, etc.) for access to, or interaction with, a selected subset of the multiple applications (or data sources). Each of the selected subset of multiple applications may be represented a specific object (e.g., a tile or link) on the launchpad. The specific object (e.g., tile or link) may be identified or labelled by a name, title, or icon indicating the specific application which the specific object represents. The tile or link (e.g., by a single click) may be used as an application launcher on the launchpad (e.g., web interface) to launch the application that the tile or link represents.

The tiles corresponding to the specific applications represented on the launchpad may be organized as a group or array of tiles in a “tiles area” of the UI hosting the launchpad. Similarly, links corresponding to specific applications represented on the launchpad may be organized as a list of links in a “links area.” A Design Time Tool (e.g., available, for example, in a menu or via a tile or link on the launchpad) may allow users or administrators to define which applications should be displayed as links or tiles on the launchpad. Users/Administrators may personalize the tiles area and the link list area to a user.

One or more containers of the personalized UI may have adjustable amounts of displayed content (e.g., number of tiles) (and correspondingly adjustable display size or display area) so that the same personalized UI can be adapted for display on different-sized display screens of different client device types (e.g., smartphone, smart watches, laptops, work station, tablet, desktop computer, etc.), and across all possible deployment options (e.g., on premise, cloud, as-a-service, etc.). Which ones of the one or more containers are displayed on the display screen at given moment may depend, for example, the status of tasks or activities of the user navigating the launchpad, and also, for example, on the size of the display screen of the client computer device available for display.

In example implementations, a container (e.g., center container, launchpad) may be used to display main or core content for a user (e.g., application/tiles relevant to a user's work or role). Launchpad serves as the shell container to access all content. Other containers may include different panels with different floorplans for different content corresponding user interests or activities (e.g. a “ME” panel displaying information or personal data about a user, a “notifications center” displaying notifications (e.g., e-mail, text messages, alerts, etc.) for the user, a panel displaying discussion threads or boards, an Overview Page, an Object Page (e.g., a floorplan to view, edit and create objects), a panel displaying context and ad-hoc workflows, a panel displaying dynamic sidebar information, a dynamic side content panel, etc. The dynamic side content is a layout control that allows additional content such as timeline, chat, additional information to be displayed in a way that flexibly adapts to different screen sizes. In some implementation, if no notifications are available, the launchpad may overtake space typically set aside for notifications.

In some implementation, the launchpad may be placed with a visual effect, including sliding in from a top of a UI and bouncing into place in the UI. In another example, the launchpad can be scaled up (e.g., maximized into view) and faded out of view upon detecting a user has exited the launchpad UI.

In some implementations, the launchpad can be executed on multiple devices, use responsive web design, and be deployable on multiple platforms. In some implementations, the launchpad is the entry point apps on mobile or desktop devices. The launchpad displays various tiles. In general, the tiles are square or rectangular objects that provide access to applications. Which tiles are displayed on a user's entry page depends on the user's role. Depending on the role, the user can choose from a wide array of ready-to-use tiles from the tile catalog as part of the launchpad personalization.

In some implementations, the launchpad may be delivered to a user through for example a Main Content area of a Viewport. A user may employ a launchpad as something of a customizable view (e.g., multiple levels of view) through the use of comprehensive filtering mechanisms, tiles. The sizing, placement, location, and arrangement of artifacts (such as for example Tiles) on or within a FLP are among other things responsive, flexible, alterable, and dynamically configurable.

A user may optionally create, alter, remove groupings of one or more tiles. Tiles may be grouped together in any number of ways using for example any number of organizational paradigms including inter alia nested, stacked, hierarchical, etc. A user may browse, traverse, etc. a collection (e.g., grouping) of tiles in any number of ways. The placement, location, sizing, arrangement, etc. of tiles (or tile grouping) is responsive, flexible, extensible, and dynamically configurable.

In some implementations, the launchpad may offer one or more comprehensive resource locators, finders, etc. such as for example AppFinder. While the launchpad may improve and/or augment aspects of an app environment, the launchpad may also operate and/or function in any number of other environments.

In some implementations, the launchpad may reside (and operate). within a user interface on any target device including, for example, any combination of one or more of a desktop, a notebook, a tablet, a smart phone, a smart watch, etc. and may among other things dynamically adjust or adapt aspects of itself to account for any particulars (e.g., display real estate, input mechanism(s), etc.) of a target device.

FIG. 1A shows an example display of a personalized web interface with a launchpad 100, in accordance with the principles of the present disclosure. Launchpad 100 may be included in a center container 120 (e.g., “Work”) with content relevant to the user's work, domain, or role in the enterprise. A left side container 110 (e.g., “ME”) with content personal to the user may pertain to content in the launchpad 100 or may be independent of content in the launchpad 100. A right side container 130 (e.g., “Notifications”) may include notifications directed to the user that pertain to content in the launchpad or other content. In some implementations, these containers 110, 120, and 130 may be referred to collectively herein as “Viewports.” In accordance with the principles of the present disclosure, the personalized web interface may be presented as a uniquely integrated, multifaceted user interface which may, in effect, transform a single-screen view on the client computer device into three multifunctional screen areas (e.g., Left/Center/Right “Viewports”).

As shown in FIG. 1A, located in the center is the “Work” Viewport 120 which may, for example, display either the launchpad 100 or an active application screen that was previously selected or opened from the launchpad tile array. The left “Me” Viewport 110 may, for example, provide various generalized functionalities related to the user and their operation and personalization. The right “Notifications” Viewport 130 may, for example, display one or more of a broad array of notification types (System Alerts, messages, reminders, tasks alerts, etc.) in a customizable listing format.

The launchpad or home screen in the Viewport, which may available at all times and in any application, may provide a clear screen orientation for accessing corresponding application information as well as generalized functionalities and navigations without ever disrupting a user's context of their current task. On a client computer device (e.g., a mobile device), which has a limited display screen area, a personalized UI display may be adapted to present fewer of the three multifunctional screen areas or Viewports on the device's limited display screen area. For example, only the Center, Left/Center or Center/Right screen areas or Viewports may be presented on a mobile device's display screen.

For convenience in description, the terms “Work Viewport”, “center Viewport”, “launchpad”, “home screen” and “home page” may be used interchangeably herein because each may persist as a user-configured starting point in which to access content.

In example implementations, the applications (which, for example, may be a set of applications implemented on HTML5/CSS/JS technology using SAPUI5 framework) delivered via launchpad 100 may adhere to a consistent, responsive design that allows users to seamlessly experience the applications across interaction channels—desktop, tablet, mobile, etc. Further, the applications delivered via the launchpad may include legacy applications implemented on traditional platforms using legacy UI technologies (e.g., FPM/WDA, SAPGUI for HTML, SAPGUI for Windows, etc.). Access to legacy applications may, for example, be provided via corresponding links in a links area of the personalized UI display.

In an example implementation of the personalized UI display, a start screen (e.g., main container, “launchpad” or home page) may present assigned applications as so-called “tiles” (e.g., tile 150, tile 151, tile 152, etc.). Tiles (which are user-activable UI elements) may only be used as application launchers for launching applications and presenting the applications on the launchpad. An App Descriptor defines Navigation Intent (=Semantic Object+Action) to launch the transaction, Title, Subtitle and Icon for the Application Launcher, i.e. the text of the tile; and Parameters, e.g. order number.

A user may use these tiles (e.g., tile 150, tile 151, tile 152, etc.) to launch or navigate to specific applications. Incorporated into the launchpad may be a launchpad Designer tool, which allows assignment of tiles to users and user groups for customization or personalization (e.g., based on user role) of launchpad 100. As a general rule, each of the multiple applications (for which launchpad 100 serves as an interface) may correspond to at least one tile. An exception to the general rule may be for factsheet applications, which need not be represented by tiles. However, factsheets may optionally still be saved as and represented by tiles on launchpad 100 if desired.

Users may (e.g., using the launchpad Designer tool) personalize their home page on launchpad 100 by selecting the tiles/applications to be shown on the home page from a tile catalog (which may be maintained, for example, by the backend computer system generating launchpad 100). The tiles available to a user in the tile catalog may depend on the user's role. The tile catalog may show all the available tiles, which may be organized into catalog groups. Pre-defined catalog groups may be assigned to different user-roles. A group selection and a search field help may assist users to find and select the right tile or tiles for their needs. The home page can be personalized and tiles can be added, removed, individually or bundled in groups.

A user may add frequently used or accessed tiles to their home page on launchpad 100. However, seldom used tiles may be accessed directly from the tile catalog, without adding them to the home page. The tiles added to the home page may be part of a group or groups of tiles (i.e. a predefined set of tiles) the user sees on his or her home page on launchpad 100. The number of visible tiles on the launchpad home page may depend on the display screen resolution of the client computer device on which launchpad 100 is displayed. If the tiles in a group do not fit in one row on the display screen, they may be wrapped to the next row. Further, the size of the displayed tiles may be responsive to the size of the display screen. For example, smaller sized tiles may be displayed on a smart phone display screen that on a desktop computer screen.

A traditional tile, apart from serving as a UI element or button for launching an application, includes only an application identifier (e.g., name, title or representative icon or logo) of the application that the tile represents. In some instances, a tile as serving an UI element or button for launching an application may be shown as an icon (e.g., icon 111)

In accordance with the principles of the present disclosure, a tile that represents an application (e.g., on launchpad 100 or any other UI), apart from serving as a UI element or button for launching the application and displaying the application identifier, may be a container that displays different types of additional information or content. The additional information may include, for example, informative text, numbers, and charts. The displayed tile content may be static or dynamic. The displayed tile content may be dynamically updated and may include, for example, data (e.g., trends or key performance indicators (KPIs), and application status, etc.) supplied by the backend systems or applications to which the tile is represents.

The multiple applications described herein may be hosted on the same or different types of computer platforms or systems (possibly including some applications hosted on the client device itself). In example implementations, the different types of computer platforms or systems may include, for example, SAP HANA, SAP ABAP, or other enterprise-type computer platforms or systems.

In example implementations, the suite of the multiple applications which an enterprise may deploy for its operations (e.g., in the areas or domains of Finance, R&D, Engineering, Human Resources, Manufacturing, etc.) may be large. Different subsets of these applications may be used in the work of enterprise personnel who may have a variety of different roles. Each user may have a need to use a different respective subset of the multiple applications, based, for example, on the user's role in the enterprise.

In general, viewports (e.g., viewports 110, 120, and 130) may each represent a partial view of a larger surface. By opening up this surface beyond the borders of a window (i.e., beyond the borders of the actual screen) a user may prepare to use the architecture described herein to extend to larger screens and collaborative wall displays. For example, if a screen or window is too small, the user will only see the viewport that fits to the screen or window. On the other hand, if the virtual screen is wider (e.g., multi-screen displays), the systems and methods described herein can provide an advantage of allowing a widening of the viewport to offer a panoramic view of the surface. While maintaining the promise to responsively support small devices, the systems and methods described herein offer the possibility to also target larger displays.

The viewport also provides the advantage of a natural user experience compared to the classical off-canvas designs that are common in mobile applications. As shown in FIG. 1A, two off-screen areas are shown, the Me area (e.g., viewport 110) with user-specific information and a Notifications area (e.g., viewport 130) on the right. Each off-screen area is populated using system-driven information. Users can access these areas through actions in a shell bar on the top left and top right corners. The transition that is shown upon accessing such content depicts a smoothly animated lateral move that mimics the user's head turning to the left and to the right in a panoramic view. User interaction with the content can be mapped to mimic natural user (e.g., human) gestures or input controls. The surface generated by the view therefore removes any screen limitations. Such a surface offers additional space for user-specific and system-driven data.

The Me Area can be found to the left of an off-screen area. Because this area is located off-screen, it is not permanently visible to the user. In order for the Me Area to slide into view, the user can click on the profile image located on the top left corner of the screen—an action that mimics the user turning his or her head to the left. This action will also trigger the viewport to move to the left and the main content area to zoom out. As the Me Area slides into view, the user will be able access information relevant to both the user and his or her usage environment. This includes, for example, the user's profile picture and access to online state, settings and preferences, a catalog of available apps (App Finder), tools to personalize the current content in the main area, and objects and apps recently visited by the user.

The Me Area may be available from each screen in the main content area. On the background surface, the different areas co-exist and influence one another. While most actions in the Me Area are available independently of the current context, some of the actions will be directly tied to the content shown in the main content area. For example, settings will display the settings page for the specific app in the main content area (not yet available). Additionally, personalization options might only be available if the respective screen is visible in the main area. In some implementations, an option to allow users to view a list of their most recently visited items is provided. This is especially useful for those users who are used to working with a limited set of apps or objects as it significantly simplifies their navigation.

The right off-screen area is dedicated to providing system-driven information. This may include system-generated notifications of events to which a user has subscribed. The system may provide more live insights and actions, making a real-time push channel increasingly important.

A notification center can provide system-generated notifications from various sources such as the workflow inbox or chat notifications. Notifications can be prioritized and grouped into groups of similar items. Through these configurations, the user will be able to access more information about a notification and take immediate action.

Similar to the Me Area, the notification area is accessible from every app that is shown in the main content area. Here, too, the user can bring the notification area into focus through a virtual turn of the head—that is, by clicking on the notification icon on the top right corner of the screen.

The notification area exists independently of the application in the main content area. The big difference between this area and the notifications on the home page of the launchpad is that the launchpad home area displays notifications within the launch tiles. By separating the notifications from the tiles, our rationale is to guide the user and make him aware of critical and actionable issues immediately. Other types of information may be suitable for display in the notification area, such as progress indicators for long-running tasks (for example, for a build or deployment process).

With the design of the viewport, the systems and methods described herein can concurrently manage different screen areas without sacrificing simplicity and responsiveness. The viewport offers a partial view of a potentially infinite surface on which content and functionality can be placed either in a fixed layout with the three main areas, or in a more flexible layout of multiple areas.

In one example, the Me Area slides into view from the left to offer users access to various user-related information including personalization, profile, settings and interaction history. Similarly, the notification area slides into view from the right to offer users access to system-driven information that helps them to become aware of critical, real-time information. The notification area may also offer other system-driven content.

FIG. 1B is an illustration showing an example login screen 110 displayed in the shell main container 104. The login screen 110 provides a UI that allows a user to enter credentials in order to log into and begin a personalized and customized UX. In the example shown in FIG. 1B, the login screen 110 appears to drop into the shell main container 104 from a virtual extension area located along a top of a display area. In some implementations, the virtual extension area can be placed along the bottom of the display area. In some implementations, the virtual extension area can be placed to the left and/or the right of the display area.

FIG. 1C is an illustration showing an example launchpad 100 displayed in the shell main container 104. The launchpad 100 can be a web-based entry point (or homepage) for enterprise applications that can execute (run) across multiple platforms and computing devices. In the example shown in FIG. 1C, the launchpad 100 appears to drop into the shell main container 104 from the top of a display area. In some implementations, the virtual extension area can be placed along the bottom of the display area. In some implementations, the virtual extension area can be placed to the left and/or the right of the display area.

The launchpad 100 can serve as a bracket around (or a base for) a set (or group) of enterprise applications, providing a single point of entry for the set of enterprise applications. In the example shown in FIG. 1C, the launchpad 100 presents (displays on a screen of a computing device of a user) each application represented by a tile. A tile can be a container that represents the application. Each tile can display different types of content. A user can interact with each tile to navigate to the specific enterprise application associated with the tile. In addition, when designing a tile to represent a specific application, a programmer can assign a tile to a specific user or group of users. The launchpad 100 can provide one or more services. The one or more services can include, but are not limited to, application-to-application navigation, personalization, role-based application assignments, search, and incident creation.

The launchpad 100 can be a role based, personalized, real-time and contextual aggregation point for business applications and analytics. The launchpad 100 can run (execute) on multiple computing devices including, but not limited to, desktop computers and mobile computing devices such as laptop computers, tablet computers, notebook computers, personal digital assistants (PDAs), smartphones, mobile phones, smart watches, etc.). In addition, the launchpad 100 can be deployed on multiple platforms (e.g., Linux, Windows, Windows Phone, MAC®, iOS®, OS X®, Android®, etc.).

The launchpad 100 includes tiles 114a-h. Each tile can display different types of content. For example, tile 114a can be a news and feeds tile that can enhance collaboration by providing a user with information about the enterprise. The tiles 114a-h can be individually color-coded. A color can represent a particular role (e.g., finance, human resources, supply chain management (SCM), customer relationship management (CRM), etc.). The tiles 114a-h can be associated with a group 116. Tile 114f can be a key performance indicator (KPI) tile. Tile 114b can be a basic launch tile. Tile 114d can be a monitoring tile. Tile 114g can display a comparison chart for specific content.

The launchpad 100 includes a link list area 118 that includes links 119a-f. The link list area 118 is an area on the launchpad 100 that can provide links to enterprise applications represented by the tiles 114a-h. For example, a user can select and drag a tile from the tile area on the launchpad 100 into the link list area 118 to create a link to the application associated with (represented by) the tile. In some implementations, the launchpad 100 can include a footer toolbar (e.g., footer toolbar 132 as shown in FIG. 1F). In some implementations, the footer toolbar can appear to float over the content displayed in the launchpad 100.

In some implementations, the shell toolbar 108 can display a search icon 111 and a copilot launch icon 113. A user can select (click on) the copilot launch icon 113 to launch a copilot UI. A copilot UI will be described in more detail with reference to FIG. 1I.

FIG. 1D is an illustration showing an example active application screen (overview page 120) displayed in the shell main container 104. The enterprise applications that can be accessed by a user by way of the launchpad 100 and then subsequently displayed in an active application screen (e.g., the overview page 120) can include, but are not limited to, transactional applications, analytical applications, and fact sheet applications (contextual navigation applications). Transactional applications can allow a user to create, change and/or approve processes with guided navigation. Analytical applications can provide a user with a visual overview of a dedicated topic for monitoring and tracking purposes to allow for further key performance indicator (KPI) related analysis. Fact sheet applications can allow a user to view essential information about an object and to allow navigation between related objects.

The overview page 120 can visualize all of the information a user may need for a specific business context (business domain) on a single page or screen. The information can be displayed in one or more variable content packages (VCPs) or cards 122a-i. Each card can be a container of content for organizing large amounts of information on an equal plane within the overview page 120. In some implementations, a user can rearrange the position of the cards 122a-i on the overview page 120. In some implementations, a user defines, adds, or deletes cards included in the overview page 120.

An overview page (e.g., the overview page 120) can be a selectable application (e.g., from the launchpad 100) providing an integrated gateway into enterprise applications and application content included in the launchpad 100. The UI of the overview page (e.g., the overview page 120) can provide a user with a visual summary of data, links, actions, and content that are relevant to a business domain of expertise of a user and relevant to a selected role of the user within the domain. The visual summary can be presented in one or more cards (e.g., the cards 122a-i) that display live content to a user at-a-glance without the user having to open multiple applications and perform multiple drill downs through application content to find and present the content.

In some implementations, the overview page 120 can include a footer toolbar (e.g., footer toolbar 132 as shown in FIG. 1F). In some implementations, the footer toolbar can appear to float over the content displayed in the overview page 120.

In some implementations, an enterprise system can determine content displayed on an overview page (e.g., the overview page 120). In addition or in the alternative, a selection of one or more business domains and one or more roles of a user in the business or enterprise can determine content displayed on an overview page (e.g., the overview page 120). In some implementations, a user can make the selection using a settings UI included in a launchpad (e.g., the launchpad 100). In some implementations, a user can select one or more business domains and/or one or more roles of the user in the enterprise by way of an overview page (e.g., the overview page 120). Selecting one or more business domains and/or one or more roles of the user in the enterprise by way of the overview page can maintain absolute relevance to the individual user and the way in which the user works.

In some implementations, the user can personalize the layout and placement of one or more cards (e.g., the cards 122a-i) included in a UI of an overview page (e.g., the overview page 120) and the display of content included in each card. The personalization can enhance the workplace productivity of the user.

FIG. 1E is an illustration showing an example object page (object page 124) displayed in the shell main container 104. An object page can be a floor-plan used to represent objects in a UI. An object page can be used to display, create, or edit an object. An object can represent a business entity (e.g., a customer, a sales order, a product, an account, etc.). Enterprise applications that reflect a specific scenario (e.g., a sales order, am account status) can be bundled using an object. The object page can include a header area 126, a navigation area 128, a content area 130, and, in some implementations, a footer toolbar (e.g., footer toolbar 132 as shown in FIG. 1F). In some implementations, the footer toolbar can appear to float over the content displayed in the object page 124. For example, referring to FIG. 1C, a user can select the tile 114f and an object page can be displayed to the user.

FIG. 1F is an illustration showing an example a footer toolbar (e.g., footer toolbar 132). In some implementations, referring to FIG. 1A, the footer toolbar 132 can appear at the bottom of a screen displayed in the shell main container 104, the left container 102, and/or the right container 106. For example, as described herein with reference to FIGS. 1C-E, a footer toolbar (e.g., the footer toolbar 132) can be displayed at the bottom of the launchpad 100, the overview page 120, and the object page 124. The footer toolbar (e.g., the footer toolbar 132) can continue to appear at the bottom of the screen of the display area of the display device even as the displayed screen is scrolled. The footer toolbar (e.g., the footer toolbar 132) can appear to hover over or float over the content being displayed on the screen. The footer toolbar 132 can include buttons or controls 134a-k. The controls 134a-k can be selected by a user in order to perform one or more actions that can affect content included on the page being displayed on the screen. The controls 134a-k are examples of controls that can be included in a footer toolbar. In some implementations, the controls can be different, fewer than, or more than the controls 134a-k. The type and number of controls included in a footer toolbar can be based on the type of page being displayed and/or the content being displayed in the page.

FIG. 1G is an illustration showing an example me area (e.g., me area 136) that can be displayed in the left container 102. In some implementations, the me area 136 can be displayed in the right container 106. The me area 136 includes an upper section 138 and a lower section 140. The upper section 138 includes a user icon 142. Selecting (clicking on) the user icon 142 can provide a user profile. A dropdown indicator button 144 displays a status of the user and, if selected, a user can logout of an application. The upper section 138 includes navigation targets 146a-e. Selection of (clicking on) a navigation target by a user triggers a corresponding functionality (e.g., an application) associated with a navigation target. The me area 136 can provide various generalized functionalities as they are related to a user.

The upper section 138 can include sort selections 146a-b. A user can select (click on) a sort selection (e.g., one of the sort selections 146a-b) to determine how the listing of the recent activities included in the lower section 140 will be sorted and displayed.

The lower section 140 of the me area 136 includes a list of recent activities 148a-c. The recent activities 148a-c can include links 156a-c, respectively, that when selected (clicked on) by a user can navigate the user to back to the shell main container 104, opening an application (or function) that corresponds to the link in the shell main container 104. Recent activity items can include, but are not limited to, enterprise applications, triggered searches, co-pilot collections, and co-pilot drafts.

FIG. 1H is an illustration showing an example notification area (e.g., notification area 150) that can be displayed in the right container 106. In some implementations, the notification area 150 can be displayed in the left container 102. The notification area 150 includes notifications 152a-c. A user interacting with the UI in the notification area 150 can take immediate action on a notification. A notification item (e.g., notifications 152a-c) can have an indicator (e.g., notification indicators 154a-c) that can indicate the status of the notification. For example, a notification indicator can be color coded to indicate a particular status of the notification.

A user can reject a notification by selecting (clicking on) a reject selection (e.g., a reject selection 156a-b). For example, a user can reject the notification 152a by selecting (clicking on) the reject selection 156a. The rejection of the notification 152a (the notification status) can be indicated by content included in (e.g., a color of) a notification indicator 154a. A user can acknowledge a notification by selecting (clicking on) an acknowledge selection (e.g., a acknowledge selection 158a-b). For example, a user can acknowledge the notification 152b by selecting (clicking on) the acknowledge selection 158b. The acknowledgement of the notification 152b (the notification status) can be indicated by content included in (e.g., a color of) a notification indicator 154b.

A user can drill down into a relevant application by selecting (clicking on) a more info selection (e.g., a more info selection 160a-b). In some cases, a user may contact someone directly in response to a notification.

FIG. 1I is an illustration showing an example copilot UI (e.g., copilot UI 162). For example, referring to FIG. 1C, a copilot application can be launched from the launchpad 100 when a user selects (clicks on) the copilot launch icon 113. The copilot application can provide (generate and display) the copilot UI 162. In some cases, the copilot UI 162 can float over the UI included in the launchpad 100. As a floating UI control, the copilot UI 162 can be visually unobtrusive and flexible in its cross-functional omnipresent implementation across any device or application screen.

The example copilot UI 162 is an example copilot start page or start screen. The start screen (the copilot UI 162) can be an entry point for copilot functionality for an enterprise system.

The copilot UI 162 can provide shortcuts to different copilot features. For example, as shown in FIG. 1I, a collection can be represented by an entry in a collection list 164 that includes collection list entries 164a-d. A copilot collection can be a cluster of items in relation to a specific topic. For example, an item can be a note, a screenshot, a chat message, a copilot message, an object, or a quick create. In some implementations, the items included in the collection can be homogeneous (e.g., all of the items are of the same type). In some implementations, the items included in a collection can be non-homogeneous (e.g., the items can be of different types). Each collection list entry 164a-d can provide a representation of a collection that can include a title, a timestamp (e.g., last changed), a visual content summary, and a textual content preview. In some implementations, the collection list 164 can be searched and/or filtered.

For example, the selection of a copilot shortcut 166a-d can allow a user to create and navigate to a new collection with a specified intention. The selection of a copilot create icon 168 located in a copilot footer toolbar 170 can create and navigate to a new plain collection. The selection of a copilot settings icon 172 located in the copilot footer toolbar 170 can allow a user access to copilot settings (e.g., display a copilot settings UI, open a copilot settings application, etc.).

Copilot entries can be living, gradually growing artifacts and software entities that can accompany a user from the identification of an issue to a solution for the issue, while providing support in the form of relevant context and actions. Copilot entries can serve as memory aides while the copilot entries can incrementally evolve into valuable transactional tasks and collaborations as they mature in meaningful ways that bridge a gap between predefined application functionality and processes based on personal ways of working for a user. Though the example shown in FIG. 1I describes launching the copilot application from the launchpad 100, referring to FIG. 1A, the copilot application can be launched from other screens displayed in (included in) the shell main container 104, the left container 102, and/or the right container 106.

Copilot entries can be made ready for users to use when communicating, collaborating, and creating actionable transactions in desktop or mobile scenarios. For example, copilot text entries can be analyzed for recognizing and identifying relevant text related objects. Copilot text entries can emphasize displayed text, and a copilot application can recommend contextual entities for use in a current task. The copilot application can understand user context and can intelligently propose selections, auto-entries, and user options.

A smart template can provide a framework for generating user interfaces at runtime for an enterprise application. For example, a smart template can be used to generate the UI for the overview page 120 as shown in FIG. 1D. In another example, a smart template can be used to generate the UI for the object page 124, as shown in FIG. 1E. A smart template can provide a framework for generating the user interfaces based on metadata annotations and predefined templates for the most used application patterns. The use of smart templates can ensure design consistency by providing centralized high quality code by using predefined templates and controllers. The use of smart templates can keep applications up to date with evolving design guidelines. The use of smart templates can reduce an amount of front-end code used in building enterprise applications. The term “smart” can refer to annotations that add semantics and structures to provided data. The term “smart” can also refer to the way in which the templates understand the semantics.

FIG. 1J is an illustration of a timeline UI (e.g., the timeline 174). A timeline UI (e.g., the timeline 174) can display timeline entries 176a-e. For example, the entries can be events, objects, and/or posts listed and displayed in a chronological order. The timeline 174 includes nodes 178a-d that correspond to respective timeline entries 176a-d.

The timeline 174 can be used for collaborative communications. The timeline 174 can be configured in multiple different ways depending on use case implementations. For example, the timeline 174 can provide information about changes of an object or about events related to an object. The timeline 174 can provide information about generated entries (e.g., value XY changed from A to B) or about manual entries (e.g., comments from an individual). In some implementations, the latest entry is at the top of a list displayed by a timeline. In some implementations, the timeline 174 can be displayed along with a business object. In some cases, the timeline 174 can be displayed to the right of the business object.

Two example versions of a timeline can include a basic timeline and a social timeline. A basic timeline can be a read-only timeline. A social timeline can allow for interaction and collaboration among users.

FIG. 2 is a diagram of an example system 200 that can implement the user interfaces and user experiences described herein. The system 200 includes an enterprise computing system 202, a network 204, and client computing devices 206a-e.

For example, computing device 206a can be a mobile phone, a smartphone, a personal digital assistant, or other type of mobile computing device. The computing device 206a includes a display device 220. For example, computing device 206b can be a laptop or notebook computer. The computing device 206b includes a display device 222. For example, computing device 206c can be a tablet computer. The computing device 206c includes a display device 224. For example, the computing device 206d can be a wearable device such as a smartwatch. The computing device 206d includes a display device 226. For example, the computing device 206e can be a desktop computer. The computing device 206e can include a display device 228. A user of the computing devices 206a-e can use/interface with the display devices 220, 222, 224, 226, and 228, respectively, when interacting with the enterprise computing system 202. The computing devices 206a-e can display on the display devices 220, 222, 224, 226, and 228 any of the screens and UIs described herein.

The enterprise computing system 202 can include one or more computing devices such as a web management server 214, a frontend server 230, a backend server 208, and a mobile device management server 210. The enterprise computing system 202 can also include a database management computing system 212 that includes a database management server 212a and a database 212b. Though not specifically shown in FIG. 2, each server (the web management server 214, the frontend server 230, the backend server 208, the mobile device management server 210, and the database management server 212a) can include one or more processors and one or more memory devices. Each server can run (execute) a server operating system.

In some first implementations, the client computing devices 206a-d (e.g., the mobile computing devices) can communicate with the enterprise computing system 202 (and the enterprise computing system 202 can communicate with the client computing devices 206a-d) by way of the mobile device management server 210. The mobile device management server 210 includes one or more mobile device platform application(s) 216. By using the mobile device platform application(s) 216, the enterprise computing system 202 can deliver cross-platform, secure, and scalable applications to the computing devices 202a-d, independent of the mobile computing device-type (e.g., laptop, notebook, smartwatch, mobile phone, PDA, etc.) and independent of the operating system running on the computing device 206a-d. In these implementations, the mobile device management server 210 can then communicate with the web management server 214.

In some second implementations, the client computing devices 206a-e (both the mobile computing devices (computing devices 206a-d) and the desktop computing device 206e) can communicate with the enterprise computing system 202 (and specifically with the web management server 214), and the enterprise computing system 202 (and specifically with the web management server 214) can communicate with each of the client computing devices 202a-e) using the network 204. The web management server 214 includes a web dispatcher application 218. In both the first implementations and the second implementations, the web dispatcher application 218 can act as a “software web switch” accepting or rejecting connections to the enterprise computing system 202.

In some implementations, the network 204 can be a public communications network (e.g., the Internet, cellular data network, dialup modems over a telephone network) or a private communications network (e.g., private LAN, leased lines). In some implementations, the computing devices 206a-e can communicate with the network 204 using one or more high-speed wired and/or wireless communications protocols (e.g., 802.11 variations, WiFi, Bluetooth, Transmission Control Protocol/Internet Protocol (TCP/IP), Ethernet, IEEE 802.3, etc.).

The frontend server 230 can include product specific UI Add-On Applications 232 and a UI infrastructure 234. The UI infrastructure 234 can include a design portion and a runtime portion. The frontend server 230 can decouple a lifecycle of a UI (e.g., design and runtime deployment) from the backend server 208. The decoupling can allow UI applications to interface with a plurality of different databases. The decoupling provides a single point of UI design, access, and maintenance allowing for theming, branding, configuring, and personalizing a UI without a need for development privileges to the backend server 208 (e.g., no need to have backend administrative rights). The decoupling can result in a more secure enterprise computing system. The decoupling can provide for rule-based dispatching of requests in a multi-system landscape (e.g., for approvals including aggregation).

The frontend server 230 includes a gateway 236. The gateway 236 can provide a way to connect devices, environments, and platforms to enterprise software based on market standards. The gateway 236 can enable the development of UIs for use in different environments (e.g., social and collaboration environments). The gateway 236 can enable the development of UIs for use on different types of client computing devices (e.g., client computing devices 206a-e). The gateway 236 can enable the development of UIs for use in internet-based applications.

The backend server 208 can include a bundle (a set) of business applications (e.g., business suite 238). The business applications can be transactional applications. analytical applications, and fact sheet and contextual navigation applications. Transactional applications can allow task-based access to tasks that can include create and change. In addition or in the alternative, transactional applications can allow access to entire processes with guided navigation. Analytical applications can provide a user with a visual overview of complex tasks for monitoring and tracking purposes. Fact sheet applications and contextual navigation applications involve search and explore activities. Fact sheet applications and contextual navigation can allow a user to view essential information about an object and can allow contextual navigation between related objects.

The database management computing system 212 includes a database management server 212a that can run (execute) applications that can manage a database 212b. For example, the database 212b can be an in-memory, column-oriented, relational database (e.g., SAP HANA®). The database management computing system 212 can include extended application services 240 that can embed a full featured application server, web server, and development environment within the database management computing system 212. The extended application services 240 can include application content 242 and reuse content 244 for use by the enterprise computing system 202 when providing a personalized, responsive, and simple UX across different types of computing devices and deployment options.

FIG. 3 is a diagram of an example system 300 that can implement the launchpad for the user interfaces and user experiences described herein. The launchpad acts as runtime shell environment for the apps described herein in which the personalized home page is one feature among many other services. The launchpad is based on a unified shell architecture. The guiding principle of the unified shell is to have a single, platform-independent, client-side runtime environment which can be hosted on different server platforms (e.g., SAP NetWeaver AS ABAP, SAP HANA XS, SAP HANA CloudPlatform).

In general, the framework described herein may support for modularizing comprehensive JavaScript applications. That means, instead of defining and loading one large bundle of JavaScript code, an application can be split into smaller parts which then can be loaded at runtime at the time when they are requested. These smaller individual files are called modules.

A module is a JavaScript file that can be loaded and executed in a browser. The module may include a name, a description, a dependency, and a declaration location. There are no rules or definitions what code belongs to a module, and what code does not. The content bundled in a module is up to the developer, but typically the content has a common topic, such as forming a JavaScript class or namespace or the contained functions address a specific topic, for example client to server communication or mathematical functions.

Modules have no predefined syntax or structure, but module developers can use the name, declaration, description, or dependency to identify such modules. The name identifies the module and is used with jQuery.sap.require to load the module. As human readers associate a module with the main JavaScript object declared in it, the module names by convention are a hierarchical sequence of dot-separated identifiers like sap.ui.core.Core. A developer can use all but the last identifier to group modules in a logical and/or organizational order, similar to packages in Java, and can use the last identifier to give the module a semantical name.

Modules can declare themselves and their location of content by calling the static jQuery.sap.declare function with their name. This helps SAPUI5 to check at runtime whether a loaded module contains the expected content by comparing the used name against the declared name. As a side effect, jQuery.sap.declare ensures that the parent namespace of the module name exists in the current global namespace (window). For modules without declaration, the framework assumes that the module has the expected content and declares it with the name that was used for loading. In some cases a module declaration is mandatory.

The description of a module is any JavaScript comment preceding the module's declaration statement and is intended to help to decide whether a module is useful for the intended purpose. The configuration UI displays the description next to the module name.

Modules can use the jQuery.sap.require method to load other modules they depend on. While jQuery.sap.require internally has the effect of a loadModule call, it can also be regarded as a dependency declaration. The dependency declarations can be evaluated at runtime, but can also be analyzed at built time or at runtime on the server.

In one example, the unified shell offers unified services with platform-independent interfaces (APIs) (e.g., services 301) to the hosted apps and shell components. The implementations of these services can utilize different service adapters for the respective platform to carry out platform-specific behavior. The unified shell can be enabled using a shell container 302, shell services 304, and a shell renderer 306. In some implementations, the shell container may be independent of shell services 304 by utilizing the shell renderer 306.

Applications (e.g., apps) 308 may be embedded in an application container 310. As this is an independent re-use component, the embedding aspect is decoupled from the renderer 306. The application container 310 can, for example, host SAPUI5 components, Web Dynpro ABAP applications and SAP GUI for HTML transactions.

The shell services 304 and renderers 306 are managed by the central shell container 302. The shell container 302 utilizes a runtime configuration 312, which defines the concrete implementations for services 314, adapters 316, and shell renderer 306, as well as global settings like theme, language, system and user data. The runtime configuration 312 is fed by a number of settings, including, but not limited to static configuration settings in the hosting HTML page, dynamic configuration data read from the front-end server during startup, and/or dynamic settings passed as query parameters in the URL

In some implementations, the JavaScript components shown in FIG. 300 are embedded into a single HTML page. The launchpad implementation of the SAP NetWeaver ABAP front-end server may contain a standard page called, for example, Fiorilaunchpad.html 318, or other URL 320 directed to a launchpad page. Users may create custom start pages which utilize the shell with different static configurations.

The web browser can use http data and OData to access application back-end systems 322 and UI front-end server 324 (e.g., service implementations 326 and UI contact 328) via web dispatcher 330.

Users can embed apps into the Launchpad. When embedding applications into the launchpad, the system 300 differentiates between applications based on SAP GUI for HTML or Web Dynpro ABAP can be embedded using an iFrame (i.e., inline frame). The system 300 differentiates between applications based on SAPUI5. As these have been implemented using the same UI technology, these can be embedded directly into the Launchpad using DOM injection. This approach also allows smooth, animated UI transitions and the reuse of shared components at runtime. Therefore, applications have to be implemented as self-contained SAPUI5 components, as described below.

In a specific example, users can embed SAPUI5 Applications into the launchpad using the application container 310 configured with the following parameters: the URL (root path) of the application and the name of the SAPUI5 component. The root path is a path where the component controller for the SAPUI5 app (e.g., the Component.js file) is located. The application container 310 registers the component namespace as module path for the application URL.

The SAPUI5 component is defined with a file structure having a file named Component.js, which should be located in the root folder of the application being embedded. The definition of an SAPUI5 component includes the component metadata. The component metadata includes a config object containing additional information. The launchpad-specific configuration is defined in this config object.

The launchpad evaluates the following properties of the component configuration:

ResourceBundle—Path to the resource bundle that holds the translated app title. Example: i18n/i18n.properties.

TitleResource—Key of the app title text in the resource bundle. The title is typically displayed in the browser tab.

FavIcon—Path to the “favicon” (*.ico) file for the app, which is typically displayed in the address bar or next to the window title or tab title.

HomeScreenIconPhone, homeScreenIconPhone@2, homeScreenIcon Tablet, and/or homeScreenIconTablet@2-Paths to icons with different resolutions that are used when users add the (launchpad page containing the) app to their mobile devices' home screens. The properties with an @2 suffix enable referral to special icons for high-resolution devices.

The architecture 300 can provide path resolution to a developer embedding an app. For all properties that reference files, there are several ways to define them: absolute reference, typically starting with “/”, so it is an absolute path on the same host, relative reference, pointing to a location outside of the app, starting with “../”, relative reference, pointing to a location within the app, starting with any file or folder name below the root folder of the app. The launchpad ensures that relative references are relative to the location of the Componentjs file (not relative to the location of the HTML file displayed by the web browser). This is consistent with the behavior for other references in component metadata, for example the includes property.

One example of how the component.js file in an SAPUI5 app may appear, is shown in the snippet below:

sap.ui.core.UIComponent.extend(“mycompany.abc.Component”, { metadata : { name: “Sample Component”, library : “ mycompany.abc”, includes : [ “css/style.css” ], dependencies : { }, config : { “resourceBundle” : “i18n/i18n.properties”, “titleResource” : “shellTitle”, // The following properties reference dedicated image files. Note // that relative links are always relative to the location of the // Component.js of the app, NOT to the location of the HTML file that // is displayed in the web browser (typically: Fiorilaunchpad.html). “favIcon” : “img/favicon.ico”, “homeScreenIconPhone” : “img/57_iPhone_Desktop_Launch.png”, “homeScreenIconPhone@2” : “img/114_iPhone-Retina_Web_Clip.png”, “homeScreenIconTablet” : “img/72_iPad_Desktop_Launch.png”, “homeScreenIconTablet@2” : “img/ 144_iPad_Retina_Web_Clip.png”}},(...)});

Apps in the launchpad are effectively SAPUI5 components and can be built as self-contained components. The launchpad instantiates applications by loading the Component.js file. Use an app-specific index.html file for standalone apps only. The application.js and index.html files are not loaded by the unified shell. Declare configuration information, like the location of icons, and library dependencies in the component.js configuration file. Do not use any global variables. Do not use the global event bus (sap.ui.getCore( )getEventBus( )). Register models on the root component or on single views of your apps. Do not use sap.ui.getCore( ) to register models. Let SAPUI5 generate IDs for global elements. Do not set explicit IDs for global elements in your code, as this may prevent you from running an app several times in the launchpad. Do not rely on sap.ui.getCore( ).byId( ) for global location of elements. Always use local names getView( ).byId( ) and let SAPUI5 generate the IDs of views and components. Use only the SAPUI5 APIs to manipulate the location hash. Do not read or write directly to window.location.hash or window.location.

The launchpad uses URL hashes for its own navigation. Direct manipulation of the location hash would interfere with the launchpad navigation. For cross-app navigation, use the Cross-Application Navigation service. For inner-app navigation, use the SAPUI5 routing API. Ensure that all controls created by your component are destroyed when the component is destroyed. Avoid using sap.ui.localResources inside your Component.js file. sap.ui.localResources registers a path relative to the main page (Fiorilaunchpad.html).

FIG. 4 is an example screenshot 400 depicting examples of the launchpad carrying out navigation and discovery tasks. The launchpad is the environment in which all applications run. The Launchpad provides the integration functionality (e.g., navigation, search, and notifications) for creating, for a user, a coherent experience across the apps hosted by the architecture described herein. One main function of the launchpad is to provide access to all the applications that a user may wish to use to accomplish their job functions.

In operation of the architecture described herein, a user may access applications to navigate (e.g., navigation 402) to an app that she wishes to use or the user may wish to complete a task and is searching to discover (e.g., discovery 404) a suitable app to carry out the task. In an enterprise environment, there are generally clear rules about which users/roles are allowed to use which applications. An administrator will typically assign the user specific roles with the assumption that the user's tasks have already been well defined. Navigation functionality for the launchpad may enable a curated catalog or repository of apps from which the user could select.

Both navigation-based searching (e.g., navigation 402) and discovery-based searching (discovery 404) are provided for a user to define favorites 406, find featured or related apps 408, find content based on role 410, and to review all apps available 412.

As shown in FIG. 5A, an example screenshot of a launchpad depicts a home page 502. The primary place where a user will look for applications is the home page 502. This is the heart of the launchpad and the starting place for the user. The home page is similar to the corresponding concepts on mobile platforms or common operating systems. It is a place where the user can create shortcuts to the apps the user uses most frequently. This also means that the home page may be considered a place where the user can organize and generate a custom home page for accessing content. By combining launching and dashboard functionalities, the home page provides the advantage of a flexible desktop or device home without increasing the level of complexity for the user.

Launch tiles 504-530 are used to represent the individual apps (or variants of these, using the apps Save as Tile function), similar to the app icons shown on a desktop. In addition to their pure launching function, tiles also offer enough space to display information from the corresponding apps, such as a counter, KPI, or even data visualization. The user can define what tiles should be visible on the home page and the user can use this functionality to create an individualized dashboard.

A link area allows for an alternative visualization of apps on the home page as simple textual links. This possibility is useful when a user wishes to have direct access to a group of apps that may not necessarily offer content worth visualizing on launch tiles.

Tile groups (e.g., tiles 532 and 534) allow the user to structure the home page according to particular needs of the user. Related apps can be grouped together. The groups also serve as anchors for the navigation bar on top of the page (not shown), allowing the user to scroll directly to a specific group. Within each group, either launch tiles or textual links can be used. This allows the user to control content density and the kind of information displayed on the home page.

In the launchpad home page, tiles are usually clustered in groups. These groups are listed in an anchor bar or in a tab bar at the top of the page. The anchor bar is the default setting. Optionally, users can choose the tab bar instead. Note: Both types are only shown when users have more than one group. If a user wishes to modify groups and tiles, the user can select Edit Home Page from the Me Area.

By default, all groups may be displayed in the launchpad home page. These groups are listed in the anchor bar at the top of the page. When users select a group name, the page scrolls down to the selected group. Launchpad home page with anchor bar—all groups at a glance.

When the tab bar is selected, the groups are separated into tabs. Only one group is typically displayed at a time. While this functionality reduces the overview of all groups, it allows the user to focus on a selection of tiles and improves the performance for users with a large number groups.

Users may interact with tiles to edit content in the tiles or launchpad. For example, when an Edit Home Page link is activated and the user clicks or taps a tile, an action sheet appears showing a list of generic actions, such as Settings or Move. Tile designers can also add additional generic actions. A Settings link opens a dialog in which the user can change the information that is displayed on a tile, such as the title or description. If the user wishes to move the tile to a different group, a Move operation/link opens a dialog in which the user can move the selected tile to a different group.

In one example, the user can remove tiles by clicking or tapping the Remove icon on the top right corner of a tile. The user can also add tiles by clicking or tapping an Add icon ( ) on an empty group in edit mode, or select App Finder from the Me Area. The user can rearrange tiles by dragging them to a new location in the same group, or by dragging them to a different group. The user can open tiles by clicking or tapping a tile to open an underlying app or content item.

Users can customize groups to their needs using the Edit Home Page. For example, users can add a new group by clicking or tapping the + Add Group button. The user will be prompted to enter a new group name. If the user doesn't immediately enter a name, the placeholder text. “Enter a group name” will appear as the default name. Once the group is created, it will appear below + Add Group on the launchpad home page. The user can rearrange a group by dragging it to a new location in the group panel.

The user can rename groups by clicking or tapping a group name. A text box appears in which the user can enter the new name, which is then saved automatically. To discard a change while the text box is visible, the user must press Escape. The user can delete groups that the user has created (including all the tiles they contain) by pressing Delete. Note that predefined groups, such as My Home, or locked groups (as defined by customers) cannot be deleted. By clicking or tapping Reset, a user can reset a predefined group to its initial state as defined by an administrator. The user can temporarily hide one or more groups on the launchpad home page. Note: The My Home group and locked groups cannot be hidden. To hide a group, users go to Edit Home Page and select Hide on the top right corner of each group. To unhide a group, users select Show.

An edit mode offers additional functionality to control the visibility and placement of apps and groups on the home page. To add new applications to the home page, the user can access the catalog. The catalog contains all the apps that are available to the user. In some implementations, the catalog may be represented as an app store. Notifications 536 provide information to the user, as described in detail above.

In one example, apps can be launched from any or all of tiles 504-530. In effect, the apps can appear to be launched from the central home page 500. In addition to launching from a central home page, the architecture described herein can enable additional navigation menus that offer hierarchy navigation, related apps navigation, and all apps navigation. For example, in hierarchy navigation, for every app, each screen forms part of a screen flow, which may have been defined during an initial design phase. No matter which screen the user chooses to access, the hierarchical navigation of the launchpad 500 will offer the user the option to navigate to the parent screen of the corresponding app. For example, if a user receives an email notification for a work item, the user can access this work item by clicking the link in the email. If the user now wanted to access the related worklist, this would not be possible using a historical back navigation. Instead, the worklist would be derived from the application structure and exposed in the hierarchy navigation.

The related apps navigation can take advantage of the fact that many apps form part of a bundle of apps that support similar tasks or different aspects of a domain. Such apps can be offered as a recommendation to the user depending on the current context and based on different heuristics. An example would be the My Opportunities app for field sales representatives (in CRM). This app forms a natural bundle with other CRM apps such as My Contacts, which could easily be accessed through a list of related apps.

The all apps navigation can provide an option for moving between apps for the user if the hierarchy navigation and the related apps navigation are insufficient. The all apps navigation provides the user a full navigation menu with structured access to all apps in the catalog. Compared to the traditional approaches of using a fix masthead or top level navigation, this menu may be temporarily visible on the screen and can also be used on a mobile device.

The launchpad also provides an additional way for the user to navigate through the software apps and architecture described herein using a frequently used apps option in. This provides an advantage to the user to access commonly used applications without having to resend search requests to find the apps. In addition, the launchpad may provide separate access to both an app history and a used objects history.

If a user is searching for particular functionality or for a particular application, but is unsure whether this is available, the user will benefit from an intuitive way to browse and explore the available apps using the launchpad discovery option of App Finder—an “app store”-like interface that will list all the apps that a user might potentially use.

Apps in the App Finder may be sorted by frontend server catalog, user menu, or system menu. The frontend server catalog organizes all apps that an administrator has added to the catalog in the frontend server. These are the apps that would typically appear in the user's catalog of the launchpad.

Apps in the App Finder may be sorted by user menu (e.g., at SAP Logon) and may include all apps that have been assigned to a user in a specific system. These are the apps that a user would find in the user menu at login when logged on to a specific system.

Apps in the App Finder may be sorted by system menu (e.g., at SAP Logon) and may include all apps in a system, no matter if they were assigned to the user, or if the user has access to it. These are the apps that a user would find in a main menu in login when logged in to a specific system.

Other common functionalities such as application descriptions, screenshots, and community content should accompany these apps so that the user can get a better idea of whether an app might be useful. From the App Finder, the user will be able to directly open an app or add it to the home page as part of the user's favorites. If the user does not have access rights for a specific app, the user should be able to directly request the rights through a GRC process.

A Top Apps feature specific apps along certain recommendation criteria, the For You and All Apps perspectives offer a hierarchically structured view of different system-specific catalogs. Here the user can search or browse the entire catalog for suitable apps.

FIG. 5B is another screenshot of an example launchpad 538. The launchpad 538, similar to launchpad 500 may be customized or personalized by a user to include, among other things, specific tiles, different groupings of tiles, links or other references, etc.

The items on the launchpad 538 were selected based at least in part on a role associated with a user that is accessing the launchpad. That is, the content placed in the launchpad 538 is role-based content 540. In general, the role corresponds to the work that a person does within a company or the position held, for example, a sales person or someone working in support. Therefore, the launchpad is role based, personalized, real-time, and contextual aggregation point for business applications and analytics. A user may have assigned to them, or take on, any number of roles. Such associations may lead to different catalogs (of tiles) and different groups 542 (of tiles).

In transaction PFCG, roles are defined matching the real life roles that people play within a work situation. More specifically, a role within transaction PFCG is a set of transactions that persons within specific roles would need for their daily work. In this example, a sales person could have a role that uses transactions to add new customers, display customer details, or to enter a new lead.

Given the existence of roles within transaction PFCG that describe the typical work persona, a transaction SU01 can be used to assign these roles to specific users. A user in the system can have any number of roles assigned, which reflects the real work that the person does within the company.

The launchpad 538 can be used by a user to access and launch applications in SAPUI5, Web Dynpro ABAP, SAP GUI for HTML and URL-based environments. The launchpad 538 can include any number of news and feeds 544 to enhance collaboration. Users can search across and within apps to retrieve immediate answers and content using a search function 546.

In some implementations, the launchpad 538 may be color coded to provide indications to the user to perform actions. For example, an alert that is overdue may be color coded on a tile 548 to ensure that the indication draws the user's eye to the tile 548. The launchpad 538 can also provide dynamic charts, real-time overviews, and edit mode for personalization of groups and tiles.

The components of the launchpad 538 may include a catalog, a user menu, and an apps finder, just to name a few options. Content may be organized into catalog groups. A search field and a group selection option help users to locate specific tiles. The content is organized into hierarchical menu folders. The app finder contains all the tiles that the user is allowed to see. In addition, the user menu provides access to the complete set of functions offered by a particular back-end system, which is role-independent and therefore displays the same content for all users. The interaction for adding apps from the app finder to the home page differs for apps depending on the content sources (Catalog, User Menu, etc.).

On a launchpad 538, a user can find a number of services including, but not limited to a settings menu, a save as tile option, a user preferences menu, a help menu, and a navigation option. The settings menu provides app specific settings to the launchpad.

The Save as tile option offers a user to save a certain state of an app as a tile on the launchpad. In this case, an entry in the footer bar's share menu opens the Save as Tile popup adding the new tile to the launchpad. User preferences menu provides details about the user that is logged in. In addition, it offers theme selection and also a switch to activate the accessibility mode.

The launchpad may offer an area to log in and log out. All aspects of log in and log out are handled by the launchpad. If single-sign-on (SSO) is used, the user does not have to care about passwords. If no SSO is used, the launchpad log in screen is provided. The user can log out using the log out entry in the settings menu which opens the logout confirmation dialog.

Navigation between apps is done via the launchpad. In the catalog, smaller tiles appear on smaller screens so that at least two tiles can be shown side by side. The easy access menu (User Menu and SAP Menu) is not available on smartphones and tablets.

FIG. 6 shows an example page 600 of the Tiles Catalog, which visually depicts a tile 610 for selection (e.g., for inclusion in the personalized tile groups or tile arrays on the home page of launchpad 100). Page 600 of the Tiles Catalog may provide a user-activable UI element (e.g., button 612 at the bottom of the visual depiction of tile 610) which may be used to select or add tile 610 to the personalized tile array on the home page of launchpad 100. As described previously, the size of a displayed tile may depend on the size of the display screen of the client device on which launchpad 100 is displayed. Page 600 may also include design drawings (e.g., drawings 614 and 616) showing of the dimensions of different-sized versions of tile 610 for use, for example, on different size display screens (e.g., of a desktop and a mobile device, respectively).

The tiles representing applications made available for inclusion on launchpad 100 may be of different types (i.e. display different types of content). The different tile types may, for example, include “KPI”, “Comparison Chart”, “Bullet Chart”, “Trend Chart”, “Bar Chart”, “Launch”, and “Monitoring” tile types. FIG. 8 shows examples of tile types that may be available (e.g., in the tile catalog) for inclusion on launchpad 100.

Similarly, the links (e.g. URL links) made available for inclusion in launchpad 100 may have different types or display formats: Standard Link test titles, Link with subtitles, Links with counters, etc.

FIG. 7 shows an example tile/container structure 700, in accordance with the principles of the present disclosure. In example implementations, the tile/container may include both mandatory and optional display blocks and areas. For displaying various content Tile/container structure 700 may include different display blocks or areas (e.g. a Header Area 710, a Subtitle Area 770, a Content Area 730 and a Status Area 740). The Header Area and the Content Area may be mandatory display blocks or areas, while the Subtitle Area and the Status Area may be optional display blocks or areas. The mandatory header area (and the optional subtitle area) may display information identifying the application which the tile represents.

In example implementations, mandatory Content Area 730 of tile/container structure 700 may be used to display content defined or generated by the applications. This content may, for example, include any of KPIs, charts, texts, numbers or icons (or any combinations thereof). Optional Status Area 740 may be a text-only area for status messages, which may, for example, relate to the status of the underlying application or the displayed tile content. Example status messages may include “Current Quarter”, “Being refreshed”, “Unable to load,” “New notification,” etc.

In a variation of tile/container structure 700, which may be used for feed tiles (e.g., for an RSS data feed tile), the Header Area may be optional with only the Content Area being the only mandatory display blocks or area.

The content displayed by all the tiles on the home page may be refreshed by pulling in refreshed content at login or when the web browser or web page on the client computer device is refreshed.

In another example implementation, the tile/container structure may include additional or alternate UI elements. For example, FIG. 8 shows an example tile/container structure 800 with additional or alternate UI elements, in accordance with the principles of the present disclosure. Tile/container structure 800 may include a user-activate-able button 810 (e.g., in a clickable footer region), which can be activated by a user on a displayed tile to refresh the content displayed by the individual tile. In yet another example implementation, tile/container structure 800 may include a clickable footer/timestamp region, which may be used to display a time stamp (e.g. 2 hours ago, 5 hours ago, current, etc.) for the content displayed by the tile. The clickable footer region may include a user-activable “refresh” button, which the user can click to initiate pulling refreshed content displayed by the individual tile. In one version, clicking anywhere in the footer region may initiate refresh. In another version, clicking on the timestamp itself may initiate refresh.

In some implementations, the time stamp and clickable “refresh” button may be provided for a group of tiles on a launchpad 500. The user can click the group level “refresh” button to initiate pulling refreshed content for all tiles in the group.

For an example implementation of launchpad 500, a push model may be deployed for refreshing the content of all tiles displayed on launchpad 500. The backend systems/applications supporting launchpad 500 may continually push content delta to the tiles on launchpad 500 for display. In a version of the push model implementation, a user may access a tile setting mode (e.g., using the launchpad Designer tool or a tile catalog personalization tool) to preset times intervals when the tile content should or should not be pushed to an individual tile.

As shown in FIG. 8, a tiles setting dialog 820 can be used to configure a tile. Tile setting mode dialog 820 may be presented, for example, by a tile settings tool. In tile setting mode dialog 820, a user can select times (e.g., 1 minute, 5 minutes, hourly, daily) when refreshed content should be pushed to the individual tile displayed on launchpad 500, for example.

An application which is hosted in the launchpad 500 can be started or launched in one of two ways. If the application is associated directly with a tile on the launchpad, a user can launch the application by clicking on the respective tile. A second option is by cross application navigation. In such a case, a user may be working in a first application and this application may provide a navigational link to a second application, or to a navigation intent (i.e. a so-called semantic object and semantic action). Rather than linking a specific instance of the second application, the navigation intent (semantic object and semantic action) may be linked.

When a user clicks on a tile on launchpad 500 to navigate to an application, the application (“navigation target”) represented by the tile is opened. However, in some implementations, a tile included in a launchpad may represent multiple applications (i.e., have multiple navigation targets). For example, a generic “Application Launcher” tile may be able to launch one or more applications. A generic “Track Supplier Invoices” tile may be capable of tracking supplier invoices for more than one supplier types, categories or contexts (e.g., foreign or domestic supply). For such tile instances, a launchpad may be configured to show a target selection dialog by which the user can pre select which of the multiple targets is the intended navigation target. User selection of a navigation target may open the corresponding application.

FIG. 9 shows an example user home page (e.g., launchpad) 900, which includes a customized groups of array of tiles (e.g., in tiles area 910 and in tiles area 920) and a list of links (e.g., in links area 930), which represent different applications that the user may have a need or want to navigate to or use, in accordance with the principles of the present disclosure. Launchpad 900, in addition to the tiles that allow users to launch applications, may show additional information (e.g., menus or links to design or editing tools).

The tiles (which may have been selected from the Tiles Catalog) displayed on the launchpad 900 may be arranged, for example, in rows in a tiles area (e.g., in tiles area 910 and in tiles area 920) of the launchpad 900. The tiles may display dynamic content supplied by the underlying applications. The arrangement of tiles and the list of links on the launchpad 900 may, at a glance, provide the user an overview of resources (e.g., applications) available for work and the status of work-in-progress.

Applications which do not offer dynamic content on tiles (e.g., legacy applications or transactional applications) may be represented as links in the links list area on the launchpad 900. In customizing or personalizing the display of resources (e.g., applications) on the launchpad 900, the user may be able to drag and drop a tile from the tile area into the link list area to have the underlying application represented as a link on the launchpad 900. Conversely, a user may drag and drop a link from the links area into the tile area to have the linked application represented by a tile in the tile area of the launchpad 900.

In general, the launchpad 900 may have a normal mode and an edit mode. In the edit mode, the launchpad 900 may be personalized and tiles (and links) may be added, removed, or bundled in groups (using, for example, a launchpad Design tool).

The tiles included on the launchpad 900 may take any number of forms including, for example simple, complex, etc. A user/administrator may optionally edit, customize, etc. aspects of a tile (using, for example, a tile settings tool). Further, the user/administrator may optionally create, alter, remove, reposition, etc. groupings of one or more tiles. The tiles on the launchpad 900 may be organized in groups based on any of a number of organizational paradigms (e.g., nested, stacked, and hierarchical, etc.) The placement, location, sizing, arrangement, etc. of tiles on the home page (e.g., launchpad 900) may be responsive, flexible, extensible, and dynamically configurable.

In example implementations, a tile may among other things dynamically adjust or adapt aspects of itself (e.g., size or contents) to account for any particulars (e.g., display real estate, input mechanism(s), etc.) of the client computer device on which the tile is hosted device.

Launchpad 900 may offer one or more locator or finder mechanisms to the user to find resources or applications that may be available on the system. In an example implementation, launchpad 100 may include an “app finder” application that a user can utilize to locate or find other applications (e.g., in an application store) that may be available to the user. The app finder application itself may be represented by a tile on launchpad 100. With reference to FIGS. 1 and 9A, an example app finder application may be represented, for example, by tile 151 in Work Viewport 120 and launchpad 900, and by icon 111 in Me Viewport 110 of launchpad 100. By activating tile 151, for example, in launchpad 900 (or icon 111 in Me Viewport 110, FIG. 1), the user may launch the app finder application. The user may also be able to access the app finder application directly via an edit mode of launchpad 900 or Me Viewport 110. The user may launch or access the app finder application, for example, to add new applications (tiles) to the launchpad 900.

An example app finder application may be an “app store”-like interface (web page) that will list all the apps that a user might potentially use. FIG. 9B shows an example app finder interface 950A that may be displayed on launchpad 100 after the user activates app finder tile 151, in accordance with the principles of the present disclosure. Applications shown in app finder interface 950A may be organized under tab 951 (catalog), tab 952 (user menu), and tab 953 (system menu).

In example implementations, the applications that may be displayed under tab 951 (catalog) may include, for example, all applications that an administrator may have added to an application catalog (e.g., tile catalog) available on system servers. These applications may be the same applications that typically appear in a user catalog on the user's launchpad 900. The applications content may be organized into catalog groups. A search field (e.g., field 954) and a group selection option (e.g., option 955) may help users to locate specific tiles.

The client computer device-user interface (UI) structure or framework described herein, in addition to launchpad 900, may provide one or more Overview Page UIs (or simply “OVP”) to enhance UX while interacting with or navigating through the suite of multiple applications. Each OVP may be domain-specific and user-specific.

As described above, the launchpad may serve as an entry point to applications on mobile or desktop devices. The launchpad may display various tiles and links with each tile or link representing an application (e.g., transactions, analyses, fact sheets, smart business etc.). Clicking on a tile on the launchpad may launch the represented application. An OVP may be one such application opened from the launchpad (e.g., by clicking on an “OVP” tile or web browser link).

The OVP may provide the user with an overall view of a subject matter, with updated data (e.g. statuses, KPIs, recent transactions, etc., retrieved from the backend system/applications) presented in an easy-to-read format and may include calls to action. The updated data may be presented on one or more cards in the OVP. The cards may be displayed in the form of a list, table, chart, etc. A card may allow the user to take immediate actions (e.g. approving a purchase order) without launching an additional application. A card may include user-activable “actions” UI elements that allow the user to initiate actions related to the card content.

An overview page (OVP), which may be domain-specific and user-specific (e.g., user role specific), may be a selectable application or a run time web page (selectable, for example, from the launchpad as an OVP tile or a web browser link). The OVP may collect, combine and provide a visual summary of data, links, actions, and content, which is relevant, for example, to a user's domain expertise and his or her selected roles within the domain. There may be multiple OVPs. Each OVP may display user-pertinent live content to the user for a respective domain of interest. The user may be able to view at-a-glance, in one place, all the information needed or relevant to the user's work in a domain or role. With the OVP, the user may not have a need to open individual applications and perform numerous drill downs through individual applications and application content to hunt-down the information needed or relevant to the user's work in the domain.

The OVP may present views of both analytical and business-process related data through the lens of cards (small containers of actionable content). The OVP allows users to take actions immediately on some entries, without having to drill down to the underlying apps. It also guides users to the apps relevant for addressing an issue or getting the needed work done.

In some implementations, the OVP may differ from the launchpad. For example, framework for the launchpad may include be configured to provide a single point of entry for a user to access all applications of all roles the user is assigned to. There is no need to provide specific business contexts or filters and no need to take into account business specific actions (e.g., approve purchase order) for a tile (e.g., hosting an app). Launchpad may provide limited context information when available (e.g., number of new workflow items). There generally exists one launchpad per user.

As for the OVP, it provides an application area having insight and context information for one specific business context based on the user. The OVP has the ability to filter across all cards (e.g. Plant, Purchase Order . . . ). Micro-Actions are possible on cards to perform tasks quickly (e.g. approve or reject purchase order) directly on the OVP. The OVP includes more information for the specific context available (e.g. more details for the first workflow items) than does the launchpad. Multiple OVPs can exist per user (e.g., depending on role assignment or use cases). The OVP is an optional configuration and application specific card types can be implemented. Third party content can be embedded in the OVP.

A card used in the overview page may be an atomic unit of content which can be consumed across multiple devices (e.g., desktop through wearable technologies). The cards used in an OVP may be of different types than those used in the launchpad. For example, a Grouped Object card may be container for a related set of objects (or links) providing quick navigation to details and/or actions. A Single Object card may represent a single object or data point and may be informational (read-only) or actionable. A Stack may be a collection of Single-Object Cards based on a topic or action, which can be opened to browse Single Card objects.

The system may provide users the ability to add or delete cards, and to add/select cards from a catalog and add them to the OVP. Users or administrators may be able to add or edit filters for a specific card to filter displayed content, resize cards, and create their own personalized OVP (e.g., using a GUI tool that allows stakeholders to create their own OVP's and cards). A card on the OVP display may have a fixed height, or a flexible height (e.g., to adjust to variable content amount). Further, the flexible height card may, for example, have vertical scrolling enabled in the content area displayed (e.g., iframe) to allow a user to scroll content and visualize different portions of content which does not fit in one view of the card.

Any single-entity card on the OVP can have actions displayed. Cards may have simple actions (e.g., approve), or additional complex actions. For Function-Import actions with parameters, the card behavior may include that when an action is taken (e.g., user clicks on an action), the card transforms into a modal dialog (this is responsive for all call form factors) to allow the action to be taken. The modal dialog may have only two possible choices, for example, the action prescribed in the card footer action area, and a Cancel action.

A card may behave differently based on the type of action the application specifies. However, the behavior may not be controlled by the OVP, but may be set by the card's parent application which controls the logic of the card actions. For example, navigation actions may be set as multiple-click. Function-Import action may be set as 1 click or multiple-click depending on the use case. Multiple-click action menu items may be clicked over and over again. Once a 1-click action is taken the card in no longer needed and may disappear from the OVP.

As shown in the FIG. 10, launchpad 1000 may include a launchpad 1000, in which multiple applications are represented by tiles and can be launched by activating the tiles (e.g., tile 1002). An application launched by activating a tile (e.g. tile 1002) may open an application page (e.g., application pages 1040) on the launchpad or web interface (e.g., on an application page, a side panel, split screen (e.g., split screen 1042, etc.)). Application information and data for the multiple applications may be received for example, using content management services 1030 (e.g., WebGUI, Hybris, WebDynpro, etc.). In some instances, overview page 1010 may provide a user with an at-a-glance view of a set of the multiple applications (which may be relevant, for example, to the user's domain or role). The application information and data may be presented on cards (e.g., card 1012) in the overview page 1010. Each card 1012 may be bound only to a single application and may display application information and data for the single application retrieved, for example, using content management services 1030.

Object page 1020 may provide a flexible, extensible, and dynamically configurable overview facility through which a user may among other things create, edit, and view the objects (e.g., launchpad 1000, tile 1002, overview page 1010, card 1012, application pages 1040, split screen 1042, etc.), with the specific characteristics and particulars (e.g., as shown in floorplans) of the objects driving or directing behaviors (e.g., data retrieval, data processing, display artifact rendering) of the objects.

FIG. 1I is an example content model 1100 for a launchpad, in accordance with the principles of the present disclosure. The content model 1100 is operated upon by a transaction (code) PFCG 1102 and a launchpad designer 1104. The transaction code PFCG 1102 is a role maintenance administration to manage roles and authorization data. The tool for role maintenance, the Profile Generator automatically creates authorization data based on selected menu functions. These are then presented for fine-tuning. The systems described herein use the role maintenance functions and the profile generator (transaction code PFCG) to maintain the roles, authorizations, and profiles. The roles, which are based on the organizational plan of each specific organization (e.g., company) form the structure for the Profile Generator. These roles are the connection between the user and the corresponding authorizations. The actual authorizations and profiles may be stored in a particular central SAP system as objects. With the roles, users can be assigned to any user menu that is displayed upon logon to the SAP System. Roles also contain the authorizations with which users can access the transactions, reports, web-based applications, and so on that are contained in the menu.

In general, users 1106 can be assigned to PFCG roles 1108. PFCG roles 1108 can be assigned to groups 1110 and catalogs 1112. Roles 1108 are the means to assign catalogs 1112 and their apps to users. Content can be configured system wide (configuration) or client specific (customizing). The launchpad designer (FLPD) 1104 can perform target mapping 1116 to map navigation intent to concrete (logical application/target 1118. The launchpad designer (FLPD) 1104 can map groups 1110 to tiles 1114. The tile 1114 may be used to launch an application from the homepage. The catalog 1112 may represent a set of applications a user can use and add to her homepage. The group may represent a predefined set of tiles 1114 that a user sees on her homepage.

FIG. 12 is an example architecture for user assignment and authorizations of content, in accordance with the principles of the present disclosure. As shown, business system functionality 1202 works in conjunction with authorizations and roles 1204 to provide services and apps (via the launchpad) to users 1206. The business and system functionality 1202 includes or has access to apps 1208, analytical reports 1210, KPIs 1212, and WebDynpro HMTL GUIs 1214. The business and system functionality 1202 can bundle the role-based apps 1208 in targeted catalogs 1216 across application domains. The catalogs 1216 assigned to a user are the basis for deriving the authorizations. For example, a specific business user 1218 may be assigned or associated with a business role 1220 and the catalog 1216 can be provided based on the business role 1220.

Restrictions 1224 may be placed on the catalog based on data structures 1226 and rules 1228. The authorization module 1230 may authorize/restrict particular content from being provided in the catalog 1216 for a specific user 1218, for example. In general, apps are developed to include authorization checks (via authorization module 1230). The authorization and roles module 1204 can invoke instance based authorization 1232 and may begin 1234 such authorization in response to a request by the user 1206. In response, the authorizations and roles module 1204 can bundle apps 1208 in catalogs 1216, insert catalogs 1216 into roles 1220 and derive authorizations 1230, an finalize roles 1220 by adding authorization object values.

FIG. 13 is an example flow 1300 describing authorization handling, in accordance with the principles of the present disclosure. The flow 1300 may begin before or as a user accesses a launchpad user interface 1302. The launchpad UI 1302 may display a catalog 1304 and one or more groups 1306. Each catalog and group may contain particular tiles (e.g., application launchers) 1308 and target mappings 1310. The tiles 1308 can resolve any target mapping 1310 based on the user accessing the launchpad UI 1302.

The target mappings 1310 can start particular apps 1320. The apps 1320 can use app-specific OData services 1322, which can use trusted RFCs 1324 to access data providers 1326. The OData services 1322 can have access to model providers 1328 and data providers 1326. The data providers 1326 may be accessed from a back-end system, which also provides access to business logic 1330. To access data provider 1326 and business logic 1330, a PFCG role 1332 (on the front-end server) is identified (or newly granted) for the user. Once the role 1332 is identified (or granted) for the user, a PFCG role 1334 for the back-end server can be generated and the an authorization profile 1336 for the user can be requested. The PFCG role 1334 can refer to any authorization defaults 1338 for the user. The authorization defaults 1338 can refer to data providers 1326, which may use authorization objects 1340 and business authorization objects 1342 (and business logic 1330) to determine and establish an authorization profile 1336.

The launchpad UI 1302 may use OData services 1312 which uses data providers 1316 that can call launchpad logic 1318 to resolve which tiles 1308 should be displayed for a particular user. The OData services 1312 may have access to model providers 1314 and data providers 1316.

In the front-end server, the model provider 1328 can enable a start authorization object 1344 to determine an authorization profile 1346 for the user. The authorization profile 1346 can be provided to the back end server. The model provider 1328 can also request or receive authorization defaults 1348 from the PFCG role 1332.

FIG. 14 is an illustration of an example method that includes generating a customizable web interface for launching a plurality of applications on a client computing device in accordance with the principles of the present disclosure. The customizable web interface (e.g., launchpad) includes a set of UI elements (e.g., graphical targets, navigation links, icons, graphs, pictorial data, etc.) leading to a respective set of the multiple applications for a user. The launchpad may include any or all architecture including, but not limited to a shell container, an application container, a renderer, services (e.g., shell services), a runtime configuration, web browser functionality, etc. The launchpad may have access to frontend servers and backend servers (e.g., server 324 and server 322).

In method 1400, generating a customizable web interface for launching a plurality of applications on a client computing device can include, at block 1402, having a shell container that can execute in a web browser and provide a plurality of services for configuring applications on a customizable web interface. The plurality of services may determine a role for a user accessing the client computing device. The role may be used to populate (or determine not to populate) particular applications and UI features of the launchpad. In some implementations, the shell container uses a runtime configuration to populate the customizable web interface with configuration settings for the plurality of applications according to the role. In some implementations, the configuration settings for each of the plurality of applications include static configuration settings, initial configuration data, and query parameters for embedding each application in the customizable web interface. In some implementations, the query parameters pertain to a URL associated with the customizable web interface.

At block 1404, the method 1400 may include accessing an application container, executing in the web browser, to register a namespace (e.g., name) for each application in the plurality of applications. The namespace may indicate a location to obtain content to load and execute in the web browser for enabling use of each respective application. The name identifies the module and may be used with jQuery.sap.require to load the module. As human readers associate a module with the main JavaScript object declared in it, the module names by convention are a hierarchical sequence of dot-separated identifiers like sap.ui.core.Core.

At block 1406, the method 1400 may include generating a plurality of graphical targets leading to selectable access of a portion of the plurality of applications. The plurality of graphical targets may be configured for display in the customizable web interface and the portion may be selected based on the role of the user. For example, if the user is a finance employee, the portion of applications may be applications used to carry out finance tasks. Other modules or applications may not be displayed to simplify the UI and/or to ensure that the user is not provided with content she does not wish to use or view.

At block 1408, the method 1400 may include embedding, in the customizable web interface. The plurality of graphical targets may correspond to the portion of the plurality of applications. Graphical targets may be icons, tiles, blocks, data, content, links, or any other graphical content displayable on the customizable web interface. The embedding ensures that each instance a user may open of the customizable web interface is populated with user-specific and role-specific content across many formats and/or devices. In some implementations, embedding a plurality of graphical targets for accessing the plurality of applications uses inline frames on the webpage.

At block 1410, the method 1400 may include accessing at least one of the plurality of services to generate and display, on a display device of the client computing device, the customizable web interface with the plurality of graphical targets for the portion and according to the determined role. In some implementations, the customizable web interface is a webpage hosted by a backend server. In some implementations, the customizable web interface is a webpage hosted by a frontend (e.g., client) server.

In some implementations, the customizable web interface is a self-contained graphical component with access to a document object model to display the portion of the plurality of graphical targets. In some implementations, the customizable web interface is adapted to provide a user with an application-to-application navigation function, a personalization function, a role-based application assignment function, a search function, and an incident creation function.

In some implementations, the application container is further capable of selecting a different portion of the plurality of applications and displaying a different plurality of graphical targets for the different portion in the customizable web interface, in response to detecting that a role of the user is modified.

The various systems and techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The various techniques may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine readable non-transitory storage device, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magnetooptical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of nonvolatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magnetooptical disks; and CDROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in special purpose logic circuitry.

Implementations may be implemented in a computing system that includes a backend component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a frontend component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such backend, middleware, or frontend components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

Claims

1. A computer-implemented method for generating a customizable web interface for launching a plurality of applications on a client computing device, the method comprising:

obtaining access to a plurality of services for configuring the plurality of applications on the customizable web interface, wherein at least one of the plurality of services determines a role for a user accessing the client computing device;
registering a namespace for each application in the plurality of applications;
generating a plurality of graphical targets leading to selectable access of a portion of the plurality of applications, the plurality of graphical targets configured for display in the customizable web interface, the portion selected based on the role of the user;
embedding, in the customizable web interface, the plurality of graphical targets corresponding to the portion of the plurality of applications; and
accessing at least one of the plurality of services to generate and display, on a display device of the client computing device, the customizable web interface with the plurality of graphical targets for the portion.

2. The method of claim 1, further comprising selecting a different portion of the plurality of applications and display a different plurality of graphical targets for the different portion in the customizable web interface, in response to detecting that a role of the user is modified.

3. The method of claim 1, further comprising using a runtime configuration to populate the customizable web interface with configuration settings for the plurality of applications according to the role.

4. The method of claim 3, wherein the configuration settings for each of the plurality of applications include static configuration settings, initial configuration data, and query parameters for embedding each application in the customizable web interface, wherein the query parameters pertain to a URL associated with the customizable web interface.

5. The method of claim 1, wherein the customizable web interface is a webpage and embedding a plurality of graphical targets for accessing the plurality of applications uses inline frames on the webpage.

6. The method of claim 1, wherein the customizable web interface is a self-contained graphical component with access to a document object model to display the portion of the plurality of graphical targets.

7. The method of claim 1, wherein the customizable web interface is adapted to provide a user with an application-to-application navigation function, a personalization function, a role-based application assignment function, a search function, and an incident creation function.

8. A system for generating a customizable web interface for launching a plurality of applications on a client computing device, the system comprising:

a shell container, executing in a web browser and providing a plurality of services for configuring the plurality of applications on the customizable web interface, wherein at least one of the plurality of services determines a role for a user accessing the client computing device;
an application container, executing in the web browser, the application container, registering a namespace for each application in the plurality of applications, the namespace indicating a location to obtain content to load and execute in the web browser for enabling use of each respective application, generating a plurality of graphical targets leading to selectable access of a portion of the plurality of applications, the plurality of graphical targets configured for display in the customizable web interface, the portion selected based on the role of the user, embedding, in the customizable web interface, the plurality of graphical targets corresponding to the portion of the plurality of applications, and accessing at least one of the plurality of services to generate and display, on a display device of the client computing device, the customizable web interface with the plurality of graphical targets for the portion and according to the determined role.

9. The system of claim 8, wherein the application container is further capable of selecting a different portion of the plurality of applications and displaying a different plurality of graphical targets for the different portion in the customizable web interface, in response to detecting that a role of the user is modified.

10. The system of claim 8, wherein the shell container uses a runtime configuration to populate the customizable web interface with configuration settings for the plurality of applications according to the role.

11. The system of claim 10, wherein the configuration settings for each of the plurality of applications include static configuration settings, initial configuration data, and query parameters for embedding each application in the customizable web interface, wherein the query parameters pertain to a URL associated with the customizable web interface.

12. The system of claim 8, wherein the customizable web interface is a webpage and wherein embedding a plurality of graphical targets for accessing the plurality of applications uses inline frames on the webpage.

13. The system of claim 8, wherein the customizable web interface is a self-contained graphical component with access to a document object model to display the portion of the plurality of graphical targets.

14. The system of claim 8, wherein the customizable web interface is adapted to provide a user with an application-to-application navigation function, a personalization function, a role-based application assignment function, a search function, and an incident creation function.

15. A computer program product for generating a customizable web interface for launching a plurality of applications on a client computing device, the computer program product being tangibly embodied on a non-transitory computer-readable storage medium and comprising instructions that, when executed by at least one computing device, are configured to cause the at least one computing device to:

obtain access to a plurality of services for configuring the plurality of applications on the customizable web interface, wherein at least one of the plurality of services determines a role for a user accessing the client computing device;
register a namespace for each application in the plurality of applications;
generate a plurality of graphical targets leading to selectable access of a portion of the plurality of applications, the plurality of graphical targets configured for display in the customizable web interface, the portion selected based on the role of the user;
embed, in the customizable web interface, the plurality of graphical targets corresponding to the portion of the plurality of applications; and
access at least one of the plurality of services to generate and display, on a display device of the client computing device, the customizable web interface with the plurality of graphical targets for the portion.

16. The computer program product of claim 15, further comprising selecting a different portion of the plurality of applications and displaying a different plurality of graphical targets for the different portion in the customizable web interface, in response to detecting that a role of the user is modified.

17. The computer program product of claim 15, further comprising using a runtime configuration to populate the customizable web interface with configuration settings for the plurality of applications according to the role.

18. The computer program product of claim 17, wherein the configuration settings for each of the plurality of applications include static configuration settings, initial configuration data, and query parameters for embedding each application in the customizable web interface, wherein the query parameters pertain to a URL associated with the customizable web interface.

19. The computer program product of claim 15, wherein the customizable web interface is a self-contained graphical component with access to a document object model to display the portion of the plurality of graphical targets.

20. The computer program product of claim 15, wherein the customizable web interface is adapted to provide a user with an application-to-application navigation function, a personalization function, a role-based application assignment function, a search function, and an incident creation function.

Patent History
Publication number: 20170344218
Type: Application
Filed: May 10, 2017
Publication Date: Nov 30, 2017
Inventors: Florian Jann (Heidelberg), Michael Krenkler (Wiesloch), Emil Voutta (Heidelberg), Marc Arno Ziegler (Mauer), Jamila Schon (Heidelberg), Kai Richter (Muehltal), Jeong Sook Lee (Walldorf), Tina Rauschenbach (Mannheim), Janos Varadi (Ludwigshafen), Carolin Seel (Heidelberg)
Application Number: 15/591,999
Classifications
International Classification: G06F 3/0481 (20130101); G06F 17/30 (20060101);