Patent Application
20180083841
Operating systems, applications, or other software products can provide many settings, options, selections, or other configuration parameters for users to specify. Some of these configuration parameters are designed to suite particular environments or preferences of users. For example, an operating system on a smartphone can provide options for users to specify a power profile on the smartphone. The power profile can include how long before the smartphone turns off a screen when idle. Other configuration parameters, however, can affect functioning of a software product. For example, an email application on a smartphone may not operate correctly if a user incorrectly specifies network configuration parameters on the smartphone.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Software developers or vendors often collect anonymous telemetry information of software products or services for understanding configuration, usage, operating health, performance, or other attributes. For example, a software application installed on a smartphone can transmit, with user consent, installation parameters, operating conditions, data/network usage, or other suitable data to a software vendor via the Internet. The software vendor can then analyze the received user data to extract insights on how the software application is installed or used, in what configuration(s) the software application performs properly, and/or other suitable information that can help improve features and/or performance of the software application.
While software developers or vendors can use such telemetry information for improving software products, little or none of such telemetry information is available to end users of the software products. For example, when a user is prompted to choose a setting during installation, the user has no information regarding values for the same setting selected by other users. Some of these settings may be designed to suite particular preferences of users. As such, selection of a particular value for the setting may not affect overall operations of a software product. Other settings, however, can potentially render a software product functioning poorly or even non-functional. For example, an email client may fail to retrieve/send emails if values for network configuration parameters (e.g., port, authentication settings, etc.) are specified incorrectly.
Several embodiments of the disclosed technology can make telemetry insights available or visible to end users so that the end users can make data driven decisions in order to reduce or even avoid configuration errors. In certain implementations, upon user consent, a telemetry server can collect telemetry information anonymously from multiple users via the Internet or other suitable computer networks. The telemetry information can be related to profiles of computing environments (e.g., operation system, application version/build, etc.), configuration/settings of software products operating in the computing environments, or other suitable information. The telemetry server can then process and store the collected telemetry information in a data store.
During installation and/or configuration of a software product in a computing device, the telemetry server can provide a user with information regarding values or selections that have been used by other users for a configuration parameter. For example, with user consent, the telemetry server can receive a profile of a computing environment on the computing device. Based on the received profile of the computing environment, the telemetry server can determine a list of values or selections related to the setting of the software product based on overall usage, usage trend, or other suitable criteria. For example, the telemetry server can generate a list of power thresholds (e.g., 10%, 20%, etc.) at which a computing device goes into a sleep mode. The telemetry server can also include adoption rates of the individual power thresholds. For instance, 10% is most commonly used while 20% is second mostly commonly used by other users. The telemetry server can then transmit the determined list of values to the computing device which in turn outputs the values to the user along with respectively adoption rates. In certain embodiments, based on the displayed options, the user can select one of the values from the displayed list as a value for the setting. In other embodiments, the mostly commonly used value can be pre-filled into a dropdown menu, a radio button, or other suitable types of input field associated with the setting on the computing device.
Several embodiments of the disclosed technology can thus help users to reduce or even avoid errors when configuring software products. For example, by providing users with what or how other users are or have been using the same or similar software product, the telemetry server can help users to gauge where a potential choice/value stands in a spectrum of choices/values. As such, a user who is new to a software product can have confidence in that certain setting options are relative “safe,” whereas others may cause potential errors. As a result, configuration errors in software products can be reduced, and user experience of software products can be improved when compared to certain techniques.
Certain embodiments of computing systems, devices, components, modules, routines, and processes for facilitating operations between a public cloud and a private cloud are described below. In the following description, specific details of components are included to provide a thorough understanding of certain embodiments of the disclosed technology. A person skilled in the relevant art can also understand that the disclosed technology may have additional embodiments or may be practiced without several of the details of the embodiments described below with reference to
As used herein, the term “software product” refers to a software application, a feature of a software application, a feature of an operating system, or other suitable types of standalone or integrated software program designed to perform one or more functions, tasks, or activities for benefit of users. For example, a software product can include an email client, a word processor, a spreadsheet application, or other suitable types of standalone application. In another example, a software product can also include a power management tool as a component of an operating system for managing power configurations of a computer, smartphone, or other computing devices.
An “operating environment” generally refers to an environment in which users can run various application software. Example operating environments can be associated with particular user interfaces as well application programming interfaces (“APIs”), internal memory (e.g., RAM) configuration/status, CPU speeds, operating systems installed, versions of various software applications, country and language of operations, or other suitable operating conditions. In certain examples, an operating environment can include an operating system. In other examples, an operating environment may not include a full operating system but can be a form of middleware that rests between the operating system and applications executing on top of the operation system. For instance, the middleware can include a graphic user interface laid over a command-line based operating system.
Also used herein, a “configuration parameter” or “setting parameter” generally refers to adjustable parameters or variable related to certain aspects of functioning of a software product. For example, a configuration parameter of an operating system can include a language setting, a date/time setting, a daylight savings time setting, or other suitable settings. A configuration parameter can be associated with multiple values or states. For example, a language setting for an operating system can include values such as English, Chinese, Swahili, or other languages. In another example, a daylight saving time setting can include either “on” or “off.”
In addition, as used herein, “telemetry information” generally refers to data representing usage, configuration, performance, or other suitable information related to a software product or a software environment by multiple users. Telemetry information can be generated by receiving data from individual users and aggregate the received data to derive the data representing usage, configuration, performance, or other suitable information. In certain embodiments, telemetry information can include one or more values for a configuration parameter of the software product or software environment. The one or more values have been adopted by the multiple users. In other embodiments, telemetry information can also be processed to derive one or more adoption rate associated with the one or more values. For instance, a most commonly adopted value (e.g., “English” for a language setting) can have an adoption rate of 95% in the United States. In further embodiments, telemetry information can also be processed to derive a ranking, a trend, or other suitable information related to the values of the configuration parameters.
In certain embodiments, telemetry information can be collected anonymously or non-anonymously with user consent. For example, during installation, a software product can prompt a user for participating or opt out the telemetry information collection process. While consenting for telemetry collection, users can choose to send the information anonymously or non-anonymously. Upon user consent, the software product can then transmit telemetry information to a telemetry server via the Internet or other suitable network. When the collected telemetry information is not anonymous, the telemetry information can be anonymized at the software product or at the telemetry server to remove all personal identification information to safeguard personal privacy of the users. In other embodiments, telemetry information can be collected from beta testing, survey results, or data generated from related internal or external researches, internal deployments, theoretical survey results, previous versions of same or related products, or other suitable sources.
As used herein, the term “adoption rate” generally refers to a rate at which users adopt certain values or selections related to a configuration parameter. For example, when six out of ten users adopt a single value for a configuration parameter, the adoption rate of the signal value is 60%. As such, a most commonly used value would have the highest adoption rate, and vice versa. In other examples, adoption rates can also be represented as decimals, fractions, or other suitable notations.
In certain computing systems, little or no telemetry information related to software products is available to end users. When a user is prompted to choose a setting during installation, the user has no information regarding values selected by other users for the same setting. As such, the user may select a value that potentially renders the software product non-functional. For example, an email client may fail to retrieve/send emails if values for network configuration parameters (e.g., port, authentication settings, etc.) are specified incorrectly.
Several embodiments of the disclosed technology can make telemetry insights available or visible to end users so that the end users can make data driven decisions in order to reduce or even avoid configuration errors. During installation and/or configuration of a software product in a computing device, a telemetry server can provide a user with information regarding values or selections that have been adopted by other users for a configuration parameter. Based on the displayed values, the user can select one of the values from the displayed list as a value for the setting, or the mostly commonly used value can be applied by default. As such, the user who is new to a software product can have confidence in that certain setting options are relative “safe,” whereas others may cause potential errors. As a result, configuration errors in software products can be reduced, and user experience of software products can be improved, as described in more detail below with reference to
Even though particular components and associated arrangements of the computing system 100 are shown in
The client devices 102 can individually include a computing device that facilitates access by the users 101 to the telemetry server 108 and/or the product servers 106 via the computer network 104. For example, in the illustrative embodiment, the client devices 102 individually include a desktop computer. In other embodiments, the client devices 102 can also include laptop computers, tablet computers, smartphones, or other suitable computing or communications devices. Even though three users 101 are shown in
The product servers 106 can be configured to provide copies of software products to the users 101 via the computer network 104. In certain embodiments, the product servers 106 can include web servers configured to allow downloading of software applications, software updates/upgrades, or other suitable software programs. In other embodiments, the product servers 106 can include content distribution network servers configured to distribute copies of suitable software programs. Though two product servers 106 are shown in
The telemetry server 108 can be configured to anonymously collect telemetry information related to installation, use, performance, or other suitable characteristics of software products installed and/or executing on the client devices 102. For example, the telemetry server 108 can collect telemetry information from the first and second client devices 102a and 102b values of configuration parameters, performance levels, error logs, operating environments, or other suitable information regarding an installed software product on the first and second client devices. In certain embodiments, the telemetry server 108 can only collect telemetry information from successful operations for generating recommendations. In other embodiments, the telemetry server 108 can also collect telemetry information from failed operations for generating warning or other suitable notifications. The telemetry server 108 can then store the collected telemetry information in a data store. In certain embodiments, the stored telemetry information can be updated with additional telemetry information periodically, for instance, every twelve hours. In other embodiments, the stored telemetry information can be updated every twenty-four hours, forty-eight hours, or other suitable periods of time.
The telemetry server 108 can also provide the collected telemetry information to the users 101 during installation or operation of the software product on the client devices 102. For example, in the illustrated embodiment, the third user 101c can download another copy of the software product from one of the product servers 106 and install the downloaded copy on the third client device 102c. During installation, with user consent, the third client device 102c can indicate to the telemetry server 108 that the third client device 102c has entered a configuration mode for the software product, for example, when a configuration wizard is initiated. In response, the telemetry server 108 can provide suitable telemetry information regarding values of configuration parameters related to the software product to the third client device 102c. The provided telemetry information can include, for instance, various values or selections the first and second users 101a and 101b have adopted for various configuration parameters of the software product. The third client device 102c can then output the received telemetry information to the third user 101c on, for example, a user interface (e.g., a display) of the third client device 102c. As such, even though the third user 101c may be new to the installed software product, the third user 101c can expect that certain values or selections for the configuration parameters are less likely to cause configuration errors than others, as described in more detail below with reference to
In addition, in
Components within a system can take different forms. As one example, a system comprising a first component, a second component and a third component can, without limitation, encompass a system that has the first component being a property in source code, the second component being a binary compiled library, and the third component being a thread created at runtime. The computer program, procedure, or process may be compiled into object, intermediate, or machine code and presented for execution by one or more processors of a personal computer, a network server, a laptop computer, a smartphone, and/or other suitable computing devices. Equally, components may include hardware circuitry.
A person of ordinary skill in the art would recognize that hardware may be considered fossilized software, and software may be considered liquefied hardware. As just one example, software instructions in a component may be burned to a Programmable Logic Array circuit, or may be designed as a hardware circuit with appropriate integrated circuits. Equally, hardware may be emulated by software. Various implementations of source, intermediate, and/or object code and associated data may be stored in a computer memory that includes read-only memory, random-access memory, magnetic disk storage media, optical storage media, flash memory devices, and/or other suitable computer readable storage media excluding propagated signals.
The telemetry server 108 can include a computing device having a processor 111 and a memory 116 containing instructions executable by the processor 111 to provide various software components. The processor 111 can include a microprocessor, a field-programmable gate array, and/or other suitable logic devices. The memory 116 can include volatile and/or nonvolatile media (e.g., ROM; RAM, magnetic disk storage media; optical storage media; flash memory devices, and/or other suitable storage media) and/or other types of computer-readable storage media configured to store data received from, as well as instructions for, the processor 111 (e.g., instructions for performing the methods discussed below with reference to
The processor 111 can execute instructions to provide a plurality of software components 115 configured to facilitate telemetry driven configuration of software products. As shown in
The input component 110 can be configured to receive, from the client devices 102 (
The profile of operating environment 136 can include identifications of a type, version, or build of an operating system or another software product/component currently executed or installed on the client devices 102. For example, the profile of operating environment 136 can indicate that the first client device 102a (
In certain embodiments, the input component 110 can periodically query the client devices 102 for the telemetry data 132 and/or the profile of operating environment 136. In other embodiments, the client devices 102 can transmit the foregoing data to the telemetry server 108 on a periodic basis, upon change, upon installation, upon configuration, or on other suitable basis. Upon receiving the foregoing data, the input component 110 can store/update the telemetry data 132 with corresponding profile of operating environment 136 in the memory 116. Even though
The software components 115 can also include an analysis component 112 and an output component 114 configured to facilitate telemetry driven configuration of software products, as described in more detail below with reference to
Upon receiving the configuration indication 135, the analysis component 112 can be configured to determine a list of telemetry information 138 for the configuration parameters of the software product 118 based on the stored telemetry data 132. In the example shown in
The analysis component 112 can then provide the retrieved records to the output component 114 to transmit as telemetry information 138 to the third client device 102c. For instance, the telemetry information 138 can indicate that the most commonly used value for “Options” 120 is “1” while the most commonly used value for “Selection” 122 is “On.” In other embodiments, the analysis component 112 can also provide adoption rates, trends, or other suitable information related to the telemetry information 138, as described below with reference to
In certain embodiments, the analysis component 112 can also be configured to determine whether sufficient amount of telemetry data 132 is available to provide the telemetry information 138. In response to determining that insufficient amount of telemetry data 132 is available, the analysis component 112 can provide a default list of telemetry information 138, provide no telemetry information 138, or perform other suitable operations.
Upon receiving the telemetry information 138, the software product 118 (or a component of an operating system on the client device 102) can be configured to display the telemetry information 138 to the user 101. For example, as shown in
As shown in
In further embodiments, the telemetry information 138 can also contain trending data related to each of the values. For instance, as shown in
As shown in
As such, upon receiving an indication that a user 102 (
The process 200 can then include transmitting the determined values to the client device at stage 206. The transmitted values can be recommended values for use by the user when configuring the software product in the configuration mode. As such, with such knowledge, the user can reduce a risk of configuration error of the software product executed on the client device.
Depending on the desired configuration, the processor 304 can be of any type including but not limited to a microprocessor (μP), a microcontroller (μC), a digital signal processor (DSP), or any combination thereof. The processor 304 can include one more levels of caching, such as a level-one cache 310 and a level-two cache 312, a processor core 314, and registers 316. An example processor core 314 can include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP Core), or any combination thereof. An example memory controller 318 can also be used with processor 304, or in some implementations, memory controller 318 can be an internal part of processor 304.
Depending on the desired configuration, the system memory 306 can be of any type including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.) or any combination thereof. The system memory 306 can include an operating system 320, one or more applications 322, and program data 324. This described basic configuration 302 is illustrated in
The computing device 300 can have additional features or functionality, and additional interfaces to facilitate communications between basic configuration 302 and any other devices and interfaces. For example, a bus/interface controller 330 can be used to facilitate communications between the basic configuration 302 and one or more data storage devices 332 via a storage interface bus 334. The data storage devices 332 can be removable storage devices 336, non-removable storage devices 338, or a combination thereof. Examples of removable storage and non-removable storage devices include magnetic disk devices such as flexible disk drives and hard-disk drives (HDD), optical disk drives such as compact disk (CD) drives or digital versatile disk (DVD) drives, solid state drives (SSD), and tape drives to name a few. Example computer storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The term “computer readable storage media” or “computer readable storage device” excludes propagated signals and communication media.
The system memory 306, removable storage devices 336, and non-removable storage devices 338 are examples of computer readable storage media. Computer readable storage media include, but not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media which can be used to store the desired information and which can be accessed by computing device 300. Any such computer readable storage media can be a part of computing device 300. The term “computer readable storage medium” excludes propagated signals and communication media.
The computing device 300 can also include an interface bus 340 for facilitating communication from various interface devices (e.g., output devices 342, peripheral interfaces 344, and communication devices 346) to the basic configuration 302 via bus/interface controller 330. Example output devices 342 include a graphics processing unit 348 and an audio processing unit 350, which can be configured to communicate to various external devices such as a display or speakers via one or more A/V ports 352. Example peripheral interfaces 344 include a serial interface controller 354 or a parallel interface controller 356, which can be configured to communicate with external devices such as input devices (e.g., keyboard, mouse, pen, voice input device, touch input device, etc.) or other peripheral devices (e.g., printer, scanner, etc.) via one or more I/O ports 358. An example communication device 346 includes a network controller 360, which can be arranged to facilitate communications with one or more other computing devices 362 over a network communication link via one or more communication ports 364.
The network communication link can be one example of a communication media. Communication media can typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and can include any information delivery media. A “modulated data signal” can be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), microwave, infrared (IR) and other wireless media. The term computer readable media as used herein can include both storage media and communication media.
The computing device 300 can be implemented as a portion of a small-form factor portable (or mobile) electronic device such as a cell phone, a personal data assistant (PDA), a personal media player device, a wireless web-watch device, a personal headset device, an application specific device, or a hybrid device that include any of the above functions. The computing device 300 can also be implemented as a personal computer including both laptop computer and non-laptop computer configurations.
From the foregoing, it will be appreciated that specific embodiments of the disclosure have been described herein for purposes of illustration, but that various modifications may be made without deviating from the disclosure. In addition, many of the elements of one embodiment may be combined with other embodiments in addition to or in lieu of the elements of the other embodiments. Accordingly, the technology is not limited except as by the appended claims.
