1. Field of the Invention
The present invention relates to the field of out of box experiences modules and more particularly to an architecture for simplifying development of out of box experience modules.
2. Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Under known out of box experience structures, such as the OOBE structure defined by Microsoft, developing an OOBE module for a particular type of information handling system can be very time consuming. This issue is especially prevalent when frequent changes are desirable such as for systems that are fabricated in a build to order manufacturing environment. An advantage of a build to order manufacturing environment is that an information handling system design can be easily changed in response to changes in the market. This advantage is limited if the time that it takes to modify an information handling system's OOBE module is relatively longer than the time that it takes to modify the design of the information handling system.
It is desirable to provide customized out of box experiences for certain types of transactional customers. A customized out of box experience provides a better customer experience and maximizes the value of the manufacturer that can provide such an experience. However, the known out of box experience structure presents a number of challenges.
For example, OOBE development using a known OOBE architecture can require three to five days to complete. Every change (whether a large change or a small change) requires a new OOBE module. Additionally OOBE development validation can present a challenge that is time consuming in a factory download environment. Additionally, the known OOBE structure does not conform to an install shield specification nor a “Windows” MSI specification. The known OOBE structure is difficult to implement and install within a build to order factory install script. The known OOBE structure does not conform to known factory install tools.
For example,
In one embodiment, the invention relates to a method for providing an out of box experience (OOBE) which includes providing an OOBE module and an OOBE variables file, providing OOBE options to the OOBE module via the OOBE variables file, customizing the out of box experience via the OOBE options in the OOBE variables file, and presenting the out of box experience via the OOBE module.
In another embodiment, the invention relates to a method for developing an out of box experience (OOBE) which includes providing an OOBE module and an OOBE variables file, standardizing the OOBE module, customizing the out of box experience with OOBE options via variables in the OOBE variables file, providing the variables in the OOBE variables file to the OOBE module, and presenting the out of box experience via the OOBE module.
In another embodiment, the invention relates to a method for installing an out of box experience (OOBE) module onto an information handling system which includes executing an OOBE initialization module wherein the OOBE initialization module accesses a component identifier to identify a particular out of box experience, copying an OOBE module onto the information handling system, and copying variables from the OOBE variables file based upon the component identifier wherein the variables cause the OOBE module to execute in accordance with OOBE options and the OOBE options define the particular out of box experience.
The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference number throughout the several figures designates a like or similar element.
Referring to
When an OOBE module is launched (e.g., OOBE.EXE), values are loaded 312 from the OOBE variables file 305. For example, if the OOBE module were setting forth an internet service provider (ISP) registration configuration, any changes to the configuration would only require changes to the OOBE variables relating to ISP registration configuration.
Any flow control or variable definition changes 314 (via, e.g., MSOBSHEL.HTM) are addressed by changes to the OOBE variables within the OOBE variables file 305. Hard code changes and additional branch processing are not needed.
For any OOBE module driven pages (such as e.g., ISP registration customized pages), any changes only occur within the OOBE configuration file 305, the HTML files reads the variables to the configuration file 305 to dynamically generate content and to handle any errors. Thus, option changes and page edits do not require hard code changes to add related statements in each .HTM file of the OOBE module.
Referring to
If a narrow band offer is being presented, then the process obtains narrow band options from the variables within the OOBE variables file 305. If a broadband offer is being presented, then the process obtains broadband options from the variables within the OOBE variables file 305. If no offer is presented, then the process proceeds to a user account creation step 430 where a user account creation information is presented via a hypertext markup language (HTML) type file (usemame.htm). Next a finish page is presented via a HTML file (fini.htm) at step 432.
After either the narrow band options or the broadband options are obtained, then the process accesses the offer property variable at step 440. If the offer property variable is set to offer, then only one of the narrow band or broadband offers are presented and the process proceeds to check the filename suffix at step 442. The check filename suffix determines the specific action to take after the choice of each ISP offer.
If the filename suffix is set to dial up, then the process presents dial process information via a drdyisp.htm file at step 444. The process then proceeds to creating a user account at step 430.
If the filename suffix is set to logo icon (via an ISPICON.HTM file), then the process presents a series of preset ISP vendor's logo information at step 446. The logo information may be presented via JPG, GIF or BMP type files. The process then proceeds to creating a user account (via a username.HTM file) at step 430.
If the offer property variable is set to cross as determined at step 450, then both narrow band and broadband offers are to be presented via the OOBE module, and the process returns to obtain the additional options information from the OOBE variables file 305.
If the offer property variable is set to byoa as determined at step 452, then the user's ISP is to be used and the broadband options from the variables within the OOBE variables file 305 are presented via a BYOA.HTM file at 454.
If the offer property variable was not set to offer, cross or BYOA, then the process proceeds to the user account creation step 430 where a user account creation information is presented via the username.htm file.
Referring to
Referring
An OOBE initialization module (OOBEINIT.exe) is written to a predetermined OOBE directory (e.g., c:\dell\$(PN)) within the information handling system to which the OOBE module is being installed at step 620. Next, the OBBE initialization module is automatically executed at step 622. Next, the process searches the SDR of the particular information handling system for an INFO part that matches the INFO part information that is stored within the OOBE initialization module at step 630. If the OOBE module corresponding to the component identifier is not present, as determined by step 632, then the one step factory installation process 600 exits at step 634.
If the component identifier corresponds to a normal (i.e., non-customized) OOBE module, then an appropriate section of the OOBE initialization module is copied to the OOBE variables file at step 640. If the component identifier corresponds to a preconfigured (i.e., a customized) OOBE module, then a customized OOBE indication (OEMCUST) within the OOBE variables file is set at step 650. After the customized OOBE indication is set, then the appropriate section of the OOBE initialization module is copied to the OOBE variables file at step 640. After the information is coped to the OOBE variables file, then the files corresponding to the variables within the OOBE variables file (e.g., .htm files that are identified within the OOBE variables file) are copied to the information handling system at step 660.
Referring to
The information handling system 700 includes an out of box experience module 730 stored within the memory 706.
For purposes of this invention, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.
The present invention is well adapted to attain the advantages mentioned as well as others inherent therein. While the present invention has been depicted, described, and is defined by reference to particular embodiments of the invention, such references do not imply a limitation on the invention, and no such limitation is to be inferred. The invention is capable of considerable modification, alteration, and equivalents in form and function, as will occur to those ordinarily skilled in the pertinent arts. The depicted and described embodiments are examples only, and are not exhaustive of the scope of the invention.
Also for example, the above-discussed embodiments include software modules that perform certain tasks. The software modules discussed herein may include script, batch, or other executable files. The software modules may be stored on a machine-readable or computer-readable storage medium such as a disk drive. Storage devices used for storing software modules in accordance with an embodiment of the invention may be magnetic floppy disks, hard disks, or optical discs such as CD-ROMs or CD-Rs, for example. A storage device used for storing firmware or hardware modules in accordance with an embodiment of the invention may also include a semiconductor-based memory, which may be permanently, removably or remotely coupled to a microprocessor/memory system. Thus, the modules may be stored within a computer system memory to configure the computer system to perform the functions of the module. Other new and various types of computer-readable storage media may be used to store the modules discussed herein. Additionally, those skilled in the art will recognize that the separation of functionality into modules is for illustrative purposes. Alternative embodiments may merge the functionality of multiple modules into a single module or may impose an alternate decomposition of functionality of modules. For example, a software module for calling sub-modules may be decomposed so that each sub-module performs its function and passes control directly to another sub-module.
Consequently, the invention is intended to be limited only by the spirit and scope of the appended claims, giving full cognizance to equivalents in all respects.