Patent Application
20180004358
A typical computing device, such as a personal computer, laptop computer, or mobile phone, may allow for execution of a significant number of applications, each for accomplishing a particular set of tasks. Many users may frequently switch between a number of these applications, but need to remain aware of what is occurring in other applications. For example, a user may need to monitor the status of an IT system or a stock chart while also checking and responding to incoming emails. A first application displayed in a background area (e.g., an application displaying monitoring metrics such as stock prices, system resource consumption, application performance, order tracking, etc.) may occupy a large portion of a user's screen but be obscured by a second application displayed in a foreground area (e.g., a web browser, movie player, email client, word processor, etc.) in active use by a user. The need of the user to switch back and forth between the first and second applications may interfere with the user's activity in the second application. In such a scenario, the application in the foreground area (e.g., an e-mail client) may be displayed with a degree of transparency to allow the application in the background area (e.g., a monitoring application) to be viewed as well.
In the accompanying drawings, like numerals refer to like components or blocks. The following detailed description references the drawings, wherein:
As described above, an application user interface for monitoring metric data may occupy a large portion of most displays and the need to continuously review incoming data may interfere with a user's ability to perform tasks in other applications. Accordingly, as described in detail below, various example implementations relate to applying transparency in application user interfaces. For example, a user interface for a first application may be displayed in a background area behind a user interface for a second application that has had a degree of transparency applied.
In some implementations, this degree of transparency may help prevent the obscuring of the first application, such as a monitoring application. In this manner, a user may easily check the status of the monitoring application while continuing to perform other actions in the second application. Additional implementations will be apparent to those of skill in the art upon reading and understanding the following description.
In the description that follows, reference is made to the term, “machine-readable storage medium.” As used herein, the term “machine-readable storage medium” refers to any electronic, magnetic, optical, or other physical storage device that stores executable instructions or other data (e.g., a hard disk drive, random access memory, flash memory, etc.).
Referring now to the drawings,
In the example shown in
Device 110 may comprise a display engine 122, a transparency engine 124, and/or a trigger engine 126 to implement the functionality described in detail below. Device 110 may be coupled to display 130 comprising a user interface 140 with a foreground area 142 displayed in front of a background area 144.
Display engine 122, transparency engine 124, and trigger engine 126 may be electronic circuitry for implementing functionality consistent with disclosed examples. For example, engines 122, 124, and 126 may represent combinations of hardware devices and programming to implement functionality consistent with disclosed implementations. For example, the programming for the engines may be executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the engines may include at least one processor to execute those instructions. The instructions may comprise, for example, at least a portion of an operating system (OS) of system 100 or a separate application running on top of the OS to present a user interface. As another example, the executable instructions may be included in a web browser, such that the web browser implements the interface described in detail herein. In some implementations, the executable instructions may be implemented in web-based script interpretable by a web browser, such as JavaScript. Other suitable formats of the executable instructions will be apparent to those of skill in the art.
Display engine 122 may display foreground area 142 and background area 144 in user interface 140. In some implementations, background area 144 may be associated with a first application, such as a monitoring application, and foreground area 142 may be associated with a second application, such as an active user application.
In some implementations, the foreground area 142 may be associated with an active user application, such as an e-mail application, web browser application, productivity applications, media editors and/or players, and any other software that may be executed by system 100. In some implementations, the background area 144 may be associated with a monitoring application that processes and displays updates associated with measurement metrics. For example, a stock ticker application may receive periodic updates on prices for various stocks and display a chart of those prices for a given period and/or a server load application may display updates of resources such as memory, disk space, bandwidth, etc. in use on one and/or more servers.
Such applications may be stored on device 110, a remote server, or on some other storage medium that may be accessed by device 110. In addition, the applications accessible to device 110 may include web pages or web-based applications. As an example, the applications may include web-based social networking applications, web-based email, news or sports websites, blogs, and the like. Regardless of the particular applications accessible to device 110, foreground area 142 and background area 144 may display a number of these applications and allow for user selection of either area.
Transparency engine 124 may apply a degree of transparency to foreground area 142 in an overlap area with background area 144. The application of transparency may aid a user in viewing and interacting with multiple applications. Transparency may allow at least some elements of the background area to be simultaneously visible even when the foreground area 142 occupies an overlapping section of an overall display. For example, background area 144 may comprise a first application window situated behind foreground area 142 that may comprise a second application window. Transparency engine 124 may apply a degree of transparency to foreground area 142 such that background area 144 is visible through foreground area 142.
Transparency in user interface areas may be achieved by several techniques. Transparent pixels may be used by rendering certain pixels in the foreground area transparent such that those pixels are instead used to display the corresponding pixel of the background area. The degree of transparency in this case may thus refer to the percentage of pixels rendered transparent (e.g., a transparency degree of 33% may equate to rendering every third pixel of the foreground area transparently.)
Another technique for applying a degree transparency may include the use of clipping paths around the elements of the foreground area, whereby everything inside the path is visible, and everything outside the path is invisible. A third technique for applying transparency comprises the use of alpha compositing. Alpha compositing is the process of combining an image with a background to create the appearance of partial or full transparency. The foreground and background areas may be rendered in separate passes, and then the resulting images may be combined into a single, final image called the composite. Other techniques for applying transparency to interface areas may be used, such as those provided by graphics rendering hardware and software associated with computers such as user device 110.
Trigger engine 126 may determine whether a trigger event associated with a monitoring application has occurred, and in response to determining that the triggering event associated with the monitoring application has occurred, cause display engine 122 to display the monitoring application in foreground area 142 instead of background area 144. A trigger event may comprise trigger engine 126 determining that a metric received by a monitoring application comprises an abnormal value according to a trigger rule.
In some implementations, the metrics may comprise a series of measurement values associated with a monitored condition, such as computing resources in use, weather conditions, stock prices, etc. The plurality of metrics may be received over time as the measurements are made and/or may be received in batches of sequential and/or sampled measurements. For example, a trigger event may occur when a stock trades at a price greater than a threshold value in a trigger rule and that price is received by the application and analyzed by trigger engine 126.
In some implementations, trigger engine 126 may create a trigger rule. For example, trigger engine 126 may receive a plurality of metric values associated with the monitoring application and analyze the metrics to create a trigger rule. For another example, trigger engine 126 may identify a user selection of the monitoring application in background area 144 and associate at least one of the metrics with the user selection of the monitoring application.
Trigger engine 126 may create the trigger rule based on the metric values establishing thresholds for abnormal values. In some implementations, a default change amount may be used to establish the trigger rule, such as +/−10% of an initial metric value, and the range may be adjusted as more metric values are received and analyzed. For example, if a given metric routinely varies by more than 20%, then the range sleeve may be expanded to encompass a broader range of values that may be considered normal rather than abnormal. In some implementations, user activity may be tracked to aid in identifying abnormal values. For example, if a first application receives and/or displays a new metric value, and user 160 switches from a second application to the first application via input device 155 to retrieve details about the new metric value, the metric analysis may designate the new metric value an abnormal value and create a new trigger rule associated with that value
Once trigger engine 126 has created a trigger rule, trigger engine 126 may receive a second plurality of metrics associated with the monitoring application and determine whether any of the second plurality of metrics comprise an abnormal value according to the trigger rule. In some implementations, determining whether one of the second plurality of metrics comprises an abnormal may comprise determining whether a threshold number of subsequent metrics of the second plurality of metrics comprise abnormal values. For example, a single abnormal value may not be enough to satisfy the trigger rule, but three consecutive abnormal values may. In some implementations, the trigger rule may comprise a range sleeve associated with a range of normal values (e.g., a stock price range of $20-$25 per share).
User 160 may interact with device 110 via an input device 155 such as a mouse, a keyboard, a touchpad, and/or a microphone. It should be apparent, however, that any suitable input device may be used, provided that user 160 may communicate instructions to device 110. Input device 155 may be internal or external to device 110 depending on the configuration of device 110.
In some implementations, trigger engine 126 may comprise instructions for analyzing and correlating data associated with a series of metric values associated with an application executed by user device 100. For example, a stock ticker application may periodically receive a metric value comprising a current price of a particular stock. Over a period of time, the metric analysis may identify a normal range of expected values, such as by identifying an average daily percentage and/or absolute value change. This range of expected values may comprise a range sleeve representing a threshold amount above or below an average value that would comprise an abnormal value. For example, a stock price metric with an average value of $20.00 may comprise a range sleeve of $18.00-$22.00, or +/−10%. Any metric falling outside that range sleeve may comprise an abnormal value.
The metric analysis may create a trigger rule based on the metric values establishing thresholds for abnormal values. In some implementations, a default change amount may be used to establish the trigger rule, such as +1-10% of an initial metric value, and the range may be adjusted as more metric values are received and analyzed. For example, if a given metric routinely varies by more than 20%, then the range sleeve may be expanded to encompass a broader range of values that may be considered normal rather than abnormal. In some implementations, user activity may be tracked to aid in identifying abnormal values. For example, if a first application receives and/or displays a new metric value, and user 160 switches from a second application to the first application via input device 155 to retrieve details about the new metric value, the metric analysis may designate the new metric value an abnormal value and create a new trigger rule associated with that value.
Trigger engine 126 may receive metric values associated with a monitoring application and evaluate those values against the created trigger rules. A metric value that is found to comprise an abnormal value according to the created trigger rules may result in trigger engine 126 causing the display engine 122 to swap a monitoring application being displayed in background area 144 to be displayed in foreground area 142 instead. In some implementations, an application that had been displayed in foreground area 142 may be moved to background area 144 behind the monitoring application. In some implementations, trigger engine 126 may make the monitoring application the active and/or focus window.
Processor 210 of
Machine-readable storage medium 220 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 220 may be, for example, memory, a storage drive, an optical disc, and the like. In some implementations, machine-readable storage medium 220 may be a non-transitory machine-readable (e.g., computer-readable) storage medium, where the term “non-transitory” does not encompass transitory propagating signals. Machine-readable storage medium 220 may be encoded with instructions that, when executed by processor 210, perform operations consistent with disclosed implementations.
Machine-readable storage medium may comprise a memory of user device 200. The memory may comprise both volatile and/or nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. Thus, the memory may comprise, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, and/or other memory components, and/or a combination of any two and/or more of these memory components. In addition, the RAM may comprise, for example, static random access memory (SRAM), dynamic random access memory (DRAM), and/or magnetic random access memory (MRAM) and other such devices. The ROM may comprise, for example, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and/or other like memory device.
For example, machine-readable storage medium 220 may include instructions that perform operations to display a background area associated with a first application, display a foreground area associated with a second application, apply a degree of transparency to the foreground area such that the first application and the second application are both visible, create a trigger rule associated with the monitoring application, determine whether a metric value associated with the monitoring application satisfies the trigger rule, and in response to determining that the metric value associated with the monitoring application satisfies the trigger rule, display the monitoring application in front of the second application. In the example shown in
In some implementations, background area instructions 234 may comprise instructions to update the background area according to a plurality of metric values received by the first application. For example, the first application may comprise a monitoring application that displays a graph of metric values as they are received. Background area instructions 234 may update the graph and refresh the display.
In some implementations, trigger rule determination instructions 244 may comprise instructions to determine whether at least one of the plurality of metric values received by the first application comprises an abnormal value according to the trigger rule. For example, the trigger rule may define an abnormal value as any value that changes from a previous value by more than 10%.
In some implementations, create trigger rule instructions 242 may comprise instructions to analyze the plurality of metric values to identify a range sleeve of normal values. For example, a range sleeve may be established based on a maximum and minimum value of the plurality of metrics. In some implementations, the range sleeve may be expanded by a percentage (e.g., 10% more than the maximum value and 10% less than the minimum value). The percentage expansion may be based on the absolute and/or relative difference between the maximum and minimum values.
In some implementations, foreground area instructions 232 and transparency application instructions 236 may comprise instructions to identify a relevant portion of the background area associated with the first application and apply the degree of transparency to an overlap area of the foreground area corresponding to the relevant portion of the background area. For example, the foreground area may overlap both a graphical representation of the plurality of metric values and a menu bar of the first application. The foreground area instructions 232 may comprise instructions to identify the graphical representation area associated with displaying the plurality of metric values as the relevant portion. Transparency application instructions 236 may apply the transparency to the portion of the foreground area overlapping the graph display and not the portion of the foreground area overlapping the menu bar.
In some implementations, machine-readable storage medium 220 may be encoded with executable instructions for displaying a user interface that enable a user to interact with one or more applications. As with display engine 122, the executable instructions encoded on machine-readable storage medium 220 may be a portion of an OS, a standalone application, a portion of a web browser, web-based script, and other similar formats. Display instructions 230 may display foreground and background areas associated with the first and second applications.
In some implementations, transparency application instructions 236 may apply a configurable degree of transparency to a foreground area associated with a second application, such as an email application, such that a background area associated with the first application, such as a monitoring application, may remain at least partially visible behind the foreground area.
Machine-readable storage medium 220 may also be encoded with executable instructions for analyzing metric values and creating and evaluating trigger rules. As with trigger engine 126, the executable instructions encoded on machine-readable storage medium 220 may be a portion of an OS, a standalone application, a portion of a web browser, web-based script, and other similar formats.
Trigger instructions 240 may determine whether a trigger rule associated with a first application, such as a monitoring application, has been satisfied and cause display instructions 230 to display the user interface associated with a monitoring application in front of the user interface associated with a second application instead of behind the second application. The trigger rule may be satisfied when an analysis of a plurality or metric values associated with a monitoring application has been used to create a the trigger rule and one of the metric values is determined to comprise an abnormal value. Trigger rule creation may comprise the trigger instructions 240 establishing baseline ranges for received metric values, identify abnormal metric values, and evaluate user actions with respect to the received metric values.
In some implementations, display instructions 230 and/or trigger instructions 240 may interact with each other and/or other applications through the use of an Application Programming Interface (API). In particular, an API of an application, whether locally-executed or web-based, may expose a number of functions to other applications. Similarly, an API of an operating system may expose a number of functions used to control the functionality of the OS.
For example, display instructions 230 may apply a degree of transparency to a foreground area associated with a second application via a window control API exposed by the operating system. Further, when foreground area instructions 232 and/or background area instructions 234 are implemented with respect to applications on top of the OS, launching and switching applications in response to user selection of an application control and/or in response to a trigger rule may be implemented using an API of the OS.
User interfaces may be displayed on an output device, similar to that of display 130 described above, comprising a display device, such as a cathode ray tube (CRT) monitor, a liquid crystal display (LCD) screen, or a screen implemented using another display technology. It should be apparent, however, that any suitable display may be used, provided that the user interfaces are displayed to the user. The output device may be internal or external to user interface display device 200 depending on the configuration of user interface display device 200.
Consistent with some implementations, background area 144 of a user interface display, such as user interface 140 of display 130, may comprise a portion of the display where an application window is displayed behind at least one other application window. Foreground area 142 of a user interface display may comprise at least a portion of a window displayed in front of at least one other window. The foreground area may not be limited to that portion of the display occupied by an application window, but may comprise any portion of the display wherein the window is located in front of another window. Similarly, the background area may not be limited to that portion of the display occupied by an application window, but may comprise any portion of the display wherein the window is located behind another window.
In this example, transparency engine 124 may apply a degree of transparency to second application 515 such that the applications 510, 520 remain visible to user 160 in their respective partial overlap areas 525, 535. This allows user 160 to continue to interact with second application 510 while being able to view updates in the applications 510, 520. In this example, the portions of the applications 510, 520 outside the respective partial overlap areas 525, 535 remain at their normal visibility while the portions within the respective partial overlap areas 525, 535 appear dimmer due to the transparency applied to the second application 515.
The degree of transparency applied to the second application 515 may be configurable by user 160 according to their preferences and/or may adjust according to a degree of contrast detected between the second application 515 and the applications 510, 520. For example, a monitoring application with a light colored data display may require a greater degree of transparency to be visible behind the foreground application.
Method 600 may start in block 605 and proceed to block 610 where system 100 may receive a plurality of metrics associated with a monitoring application. The metric may be received by the monitoring application itself and/or may be received from and/or on behalf of the monitoring application by another application and/or the operating system of system 100. In some implementations, the metrics may comprise a series of measurement values associated with a monitored condition, such as computing resources in use, weather conditions, stock prices, etc. The plurality of metrics may be received over time as the measurements are made and/or may be received in batches of sequential and/or sampled measurements.
Method 600 may proceed to block 620, where system 100 may establish a baseline range for the metrics. For example, a range sleeve may be established by trigger engine 126 and/or create trigger rule instructions 242 based on a maximum and minimum value of the metrics. In some implementations, the range sleeve may be expanded by a percentage (e.g., 10% more than the maximum value and 10% less than the minimum value). The percentage expansion may be based on the absolute and/or relative difference between the maximum and minimum values.
Method 600 may proceed to block 630, where system 100 may identify an abnormal value. For example, the range of metrics may comprise a series of values that typically change less than 5% from measurement to measurement or typically differ less than 10% of the mean value of the plurality of metrics. Trigger engine 126 and/or create trigger rule instructions 242 may determine that a metric that comprises a 25% change from the prior metric or from the mean may thus comprise an abnormal value.
Method 600 may proceed to block 640, where system 100 may evaluate a user action with respect to the metric values. For example, while displaying the received metrics in a background monitoring application, user 160 may choose to switch to the monitoring application and bring up more details about a given metric. Such an action may be interpreted, by trigger engine 126 and/or trigger instructions 240, to identify that metric value as one of interest to the user and so may be designated as an abnormal value.
Method 600 may proceed to block 650, where system 100 may create a trigger rule. For example, trigger engine 126 and/or create trigger rule instructions 242 may create a trigger rule comprising the range sleeve established at block 620, the abnormal value identified at block 630, and/or the value of interest identified at block 640. Method 600 may then end at block 655.
Method 700 may start in block 705 and proceed to block 710, where system 100 may display a first application in background area 144. In particular, the first application may comprise a monitoring application including a data display area that may be updated by display engine 122 and/or display instructions 230 as metric values are received such as .that depicted in
Method 700 may then advance to block 715, where system 100 may display a second application in foreground area 142. In particular, the second application may include a plurality of user controls, each corresponding to a particular function. The second application may comprise an application such as a word processor, spreadsheet, web browser, email reader, game, music, movie, and/or other application with which a user may interact. In some implementations, multiple applications may be displayed by display engine 122 and/or display instructions 230 in the foreground area and/or the background area.
Method 700 may then advance to block 720, where system 100 may apply a degree of transparency to the second application in the foreground area. The degree of transparency may be configurable so as to allow the first application displayed behind the second application to still be visible without unduly interfering with the user's interactions with the second application. For example, a transparency degree of 20% may be applied by transparency engine 124 and/or transparency application instructions 236 to an email application with large areas of white space and text while a 40% degree of transparency may be applied to a movie application to allow for better visibility through the movement of the display.
Method 700 may then advance to block 725, where system 100 may receive metrics associated with the first application. For example, a stock monitoring application may receive a metric value comprising an updated stock price while a resource usage monitoring application may receive a metric value comprising an amount of memory or processor power in use by a server. Metrics may be received on a periodic basis (e.g., every five seconds) and/or may be received when an event to be measured occurs (e.g., a stock is traded on the market).
Method 700 may then advance to block 730, where system 100 may update the first application display. In particular, a monitoring application associated with a received metric may have its data display updated by display engine 122 and/or display instructions 230 to reflect the newly received value, such as by adding a data point to the end of a line graph.
Method 700 may then advance to block 735, where system 100 may determine whether the received metric value comprises an abnormal value according to a trigger rule. For example, a trigger rule created at block 650 of method 600 may be used to evaluate, by trigger engine 126 and/or trigger instructions 240, whether the metric falls outside of a range sleeve or comprises a value of interest to the user.
If the metric is determined not to comprise an abnormal value, method 700 may return to stage 725 where system 100 may continue to receive metrics associated with the first application. Otherwise, method 700 may advance to block 740, where system 100 may display the first application instead of the foreground application. For example, the first application may be displayed, by display engine 122 and/or display instructions 230, in front of the second application. In some implementations, the second application may retain the applied transparency with respect to other applications. In some implementations, transparency may be applied by transparency engine 124 and/or transparency application instructions 236 to the now foreground first application to enable the user to continue to view other applications situated behind the first application's window.
In some implementations, activity within the second application may be saved and/or paused until the user returns to that application. For example, a movie's playback may be paused or a word processing document may be saved. Method 700 may then end at block 745.
Although described above as comprising separate blocks, it should be apparent that the display of the particular interface areas need not occur in sequential order. Rather, in some implementations, the interface areas may be processed for display concurrently, such that some portions of a particular interface area are outputted to a display device prior to portions of another interface area.
The disclosed examples may include systems, devices, computer-readable storage media, and methods for progressive buffer generation. For purposes of explanation, certain examples are described with reference to the components illustrated in
Moreover, as used in the specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context indicates otherwise. Additionally, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by this terms. Instead, these terms are only used to distinguish one element from another.
Further, the sequence of operations described in connection with
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2015/015562 | 2/12/2015 | WO | 00 |
