SYSTEM AND METHODS FOR A RUN TIME CONFIGURABLE USER INTERFACE CONTROLLER
1. A method for reskinning a user interface of a consumer electronics device, the method comprising:
- intercepting data between at least one of an application, an operating system and an output driver of the consumer electronics device, wherein the output driver includes input and output drivers for at least one of video, audio and tactile interfaces;
determining an indicator is present, wherein the indicator includes at least one of the status of the consumer electronics device and content within the data, and wherein the indicator specifies that the data should be modified; and
modifying the data according to a theme, wherein the theme includes a plurality of limited scripts to generate a customized interface causing at least one of the animations and alterations to move based upon timers, battery levels change and signal strength varies, and outputting the modified data to the original destination.
The present invention relates to interface control systems and methods, for use with consumer electronic devices. User Interfaces, which are normally predefined at the time of manufacture, are entirely specific to the appliance by virtue of the underlying kernel or operating system. The present system includes means for providing information to and receiving information from a user to establish control over the user interface. The means for providing and receiving the information may be controlled, at least in part, by an alterable database that is separate from both the operating system and applications. This allows the database to be changed without making any changes to the underlying operating system or applications. The alterable database may be in a script form, and may be configured by the user at any time during normal operation of the apparatus. The system may invoke or modify the information contained in the alterable database in response to stimuli external to the alterable database. The alterable database may also cause flags to be set. These flags may result in a limit to the operation of the apparatus, a limit to the operation of the applications, or an alteration of information referenced by the alterable database.
- 1. A method for reskinning a user interface of a consumer electronics device, the method comprising:
intercepting data between at least one of an application, an operating system and an output driver of the consumer electronics device, wherein the output driver includes input and output drivers for at least one of video, audio and tactile interfaces; determining an indicator is present, wherein the indicator includes at least one of the status of the consumer electronics device and content within the data, and wherein the indicator specifies that the data should be modified; and modifying the data according to a theme, wherein the theme includes a plurality of limited scripts to generate a customized interface causing at least one of the animations and alterations to move based upon timers, battery levels change and signal strength varies, and outputting the modified data to the original destination.
- View Dependent Claims (2, 3, 4, 5, 6, 7, 8, 9, 10, 11)
- 12. An apparatus for reskinning a user interface of a consumer electronics device, the apparatus comprising:
an application program for intercepting data between at least one of an application, an operating system and an output driver of the consumer electronics device, wherein the output driver includes input and output drivers for at least one of video, audio and tactile interfaces; and a configuration engine for determining an indicator is present, wherein the indicator includes at least one of the status of the consumer electronics device and content within the data, and wherein the indicator specifies that the data should be modified, and modifying the data according to a theme, wherein the theme includes a plurality of limited scripts to generate a customized interface causing at least one of the animations and alterations to move based upon timers, battery levels change and signal strength varies, and outputting the modified data to the original destination.
- View Dependent Claims (13, 14, 15, 16, 17, 18, 19, 20, 21, 22)
This application claims the benefit of and is a Continuation of application Ser. No. 12/561,930, filed Sep. 17, 2009, of the same title, which application is incorporated herein in its entirety by this reference.
The present invention relates to interface control systems and methods for use with consumer electronic devices. More particularly, the present invention relates to systems and methods for controlling a user interface on an appliance to enable enhanced user personalization and run time configurability.
Users of consumer electronic devices are increasingly interested in customization and personalization. This phenomenon has led to the wild popularity of highly personalized social networking websites pages, customizable ringtones for cellular phones, and background themes available for personal computers. Businesses and manufacturers have learned to capitalize on this user driven desire for more options by offering greater selections of product designs and colors.
This invention relates to consumer electronic devices, which include a wide range of devices, including personal computers, gaming systems and portable personal appliances such as media players, PDAs and mobile phones. Many of these consumer electronic devices have fairly similar user interfaces (UI). When looking at portable personal appliances in particular, generally speaking, the UI for such devices is part of the main application software, or code, or results from the application-specific toolkit used to design that interface.
Moreover, it is common for devices from the same manufacturer, or using the same technology base, to share many of the same core design features and so any customization or personalization is often limited. To accommodate the number of variants would require an enlargement of the operating system and consume memory in a way that dissipates the advantage of a shared core. Typically, changes which may be made by a user are relatively simple, focusing on changing backgrounds (wallpaper) or color palettes in use. In many cases alteration of the UI is possible only after changes to the core software with attendant economic penalties.
Normally an appliance may incorporate a user interface that determines how a user will experience the interaction. For example in an address book, a screen may display a symbol that invites a user to enter information and this visual element will depend entirely upon how the UI was conceived by the application programmer. Because users are strongly affected by perceived ease of use, and this is a subjective measure, manufacturers of physical product often perform lengthy studies to aid them in offering the “best” UI experience. Since the UI is often incorporated in the application program, the result is usually a longer development cycle and an unforgiving market reaction if the UI proves unpopular.
A common design pattern in computing science is the Model-View-Controller methodology originally described in reference to the Xerox PARC “Smalltalk” work circa 1979. Successful use of this scheme isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the output appearance or user perception of the application or the underlying application business rules, each without affecting the other. However, a common limitation in handling the UI component of an appliance is that the UI must be specified at compile-time and thereafter only the limited and comparatively trivial changes discussed above are possible.
Commercial customization efforts to “re-skin” the display elements of a mobile phones have been attempted (TriGenix, acquired in October of 2004 and now absorbed into Qualcomm'"'"'s Brew technology, used extended markup language in its ‘skinning’ application) but with mixed success mainly because of the complexity of use. This necessarily forced manufacturers to resort to a graphical approach to the problem with relatively onerous memory requirements.
Given the strong desire by users to personalize their appliance, as well as the risk of unpopular user interfaces which may dramatically damage appliance sales, there is a strong need to provide readily customizable interfaces which are relatively un-complex to use and do not pose onerous memory or processing requirements. Such systems and methods may provide enhanced control over personalization and modification of user interfaces in a wide range of consumer electronic devices at run time. Thus, a user may be able to see the results of changes immediately without the delays and difficulties that attend compilation and embedding processes.
In view of the foregoing, systems and methods for improving efficiency of personalization of an appliance are disclosed. The present invention provides a novel approach to the implementation of User Interfaces with unparalleled flexibility in the design phase, remarkable ease of use and minimal dependence upon an underlying application.
The present invention discloses interface control systems and methods for use with consumer electronic devices. More particularly, the present invention relates to systems and methods for controlling a user interface on an appliance to enable enhanced user personalization and run time configurability.
The interface control system may provide flexibility for a manufacturer, service provider, if any, and of course the end user. By using an interpreter, or some functional equivalent, embedded in a virtual machine, run time operations may be accomplished and a user may be empowered to see the results of changes immediately without the delays and difficulties that attend compilation and embedding processes. A manufacturer may enjoy extensive re-use of an existing OS (operating system) or Kernel and any associated applications and treat the UI design and implementation as a truly separate activity within the context of the appliance.
The system may include an apparatus capable of personalization. The apparatus may have a microprocessor, memory and an operating system. Applications which operate in conjunction with the operating system may exist on the system. These applications may generate and receive interface data.
The apparatus may likewise include a means for providing information to and receiving information from the user over a user interface. The means for providing and receiving the information may be controlled, at least in part, by an alterable database that is separate from both the operating system and applications. This may allow the database to be changed without making any changes to the underlying operating system or applications.
The alterable database may be in a script form and may be configured by the user at any time during normal operation of the apparatus. Further, the alterable database may be read by an interpreter or may be compiled to bytecode. The alterable database may also incorporate both current and prior versions of an information script, and if an error occurs in the current version, the apparatus may revert to the prior version.
In some embodiments, the alterable database references alterable information that describes at least one of format, layout and content of the information. Likewise, the database may reference at least one of scaling, skewing, transformation, animation and alteration of information.
The alterable database may, in some embodiments, be comprised of more than one personality database. These personality databases or themes are independently alterable and selectable, and each comprises a separate complete personality.
The system may invoke or modify the information contained in the alterable database in response to stimuli external to the alterable database. Likewise, each personality database or theme may be invoked or modified in response to stimuli external to the database.
The alterable database may also cause one or more flags to be set. These flags may result in a limit to the operation of the apparatus, a limit to the operation of the applications, or an alteration of information referenced by the alterable database.
Note that the various features of the present invention described above may be practiced alone or in combination. These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
In the drawings, like reference numerals are sometimes used to designate like structural elements. It should also be appreciated that the depictions in the figures are diagrammatic and not to scale.
The present invention will be described in detail with reference to selected preferred embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention. The features and advantages of the present invention may be better understood with reference to the drawings and discussions that follow.
Aspects, features and advantages of exemplary embodiments of the present invention will become better understood with regard to the following description in connection with the accompanying drawing(s). It should be apparent to those skilled in the art that the described embodiments of the present invention provided herein are illustrative only and not limiting, having been presented by way of example only. All features disclosed in this description may be replaced by alternative features serving the same or similar purpose, unless expressly stated otherwise. Therefore, numerous other embodiments of the modifications thereof are contemplated as falling within the scope of the present invention as defined herein and equivalents thereto. Hence, use of absolute and/or sequential terms, such as, for example, “consist”, “will,” “will not,” “shall,” “shall not,” “must,” “must not,” “only,” “first,” “initially,” “next,” “subsequently,” “before,” “after,” “lastly,” and “finally,” are not meant to limit the scope of the present invention as the embodiments disclosed herein are merely exemplary.
The present invention relates generally to systems and methods for controlling a user interface to enable configurable run time customizations. In particular, the present invention is directed to novel methods and systems for user interface personalization which offers flexibility to manufacturers and allows a user to see the results of changes immediately without the delays and difficulties that attend compilation and embedding processes.
Of note is that, in the remainder of this application, particular attention will be placed upon visual displays on a portable personal appliance. It is important to realize that the present invention may apply equally well to all manner of consumer electronic devices including, but not limited to, computers, tablet computer systems, e-reader devices, kitchen appliances, digital music players, media players, digital watches, cameras and virtually any electronic device which includes an interface. In addition, while a visual interface is described in great detail, the present invention is entirely capable of operation with a wide range of interface types, including any combination of a visual display, tactile and audio output and a visual, tactile or acoustic user interface (UI).
The present application for letters patent describes an intermediate Configurable Presenter which interposes between an operating system (OS) of the portable personal device and the user interface. The portable personal device may also be known as simply a device or an appliance.
This provides flexibility for a manufacturer, service provider, if any, and of course the end user. By using an interpreter or some functional equivalent embedded in a virtual machine, run time operation can be accomplished and allows a user to see the results of changes immediately without the delays and difficulties that attend compilation and embedding processes. A manufacturer may enjoy extensive re-use of an existing OS (operating system) or Kernel and any associated applications and treat the UI design and implementation as a truly separate activity within the context of the appliance. Insomuch as the UI itself is concerned, this may be provided through the use of an intermediate Configurable Presenter, 120 in
An application developer need only consider the functionality of the application and UI operation in the context of the appliance or device may be determined later. More specifically, neither the appearance of any output data nor the mechanism of entry of input data need be considered at this point, rather the UI may be developed in comparative isolation. Appliances may thus use a common application code base yet need share no common UI aspects. Although there may be an efficiency penalty in that carefully structured code may be compiled to a very compact memory footprint, this often renders an implementation unique and does not normally account for post-compilation changes beyond a few selectable and pre-defined options.
The Configurable Presenter Subsystem may be used to handle data from the application and present it to the user and may handle input events and provide them to the application. Interaction between the Configurable Presenter 120 and underlying applications or Operating Systems 100 may be achieved using an Application Programming Interface which may provide convenient connectivity between the Configurable Presenter 120 and the rest of the appliance. These interactions may be provided unconstrained by the application, such as a fixed predefined output format being replaced by one more appropriate to the appliance or to anticipated user preferences. The Configurable Presenter 120 may transform or manipulate data using a set of configuration files which files may be simply altered by a user. Such transformation or manipulation may include changing data attributes such as color, size and orientation or it may provide sophisticated, device-context transformations based on time, location or current device status; for example, battery charge level or ringer alert style may cause a change in the way that information is presented to a user. The data handling may be static, quasi-static or dynamic in nature and this nature itself may be alterable dynamically. For example, the data handling may be dynamic based upon services being offered or may be keyed to time considerations, such as changing or moving an icon with every time interval.
Additionally, the Configurable Presenter Subsystem may add new or hidden UI elements to improve the user experience or remove elements that are superfluous depending on the status of the appliance.
In addition to handling the appearance of elements, the positioning and layout of visual UI elements may also be handled by the Configurable Presenter 120. The Configurable Presenter 120 may also handle aspects of acoustic or tactile information. UI elements may be modified by the system, including scaling, positioning or the addition of animation, visual or acoustic or additional components. Elements may be enhanced by effects, such as dynamic addition of shadows, reflections or highlights (which may, themselves, be alterable). Where acoustic components of the UI elements are altered, these may include echoes and reverberations so as to create the acoustic perceptions of depth and breadth. Tactile interaction of the UI may incorporate vibration devices or acceleration sensitive devices as well as physically changing device properties. For example, certain keys on a virtual keyboard may be enlarged if they are preferred, whereas the appearance or resistance to motion of a physical key may be changed by lighting or extinguishing an embedded light emitter or altering spring tension electro-mechanically.
The application may specify attributes that the Configurable Presenter 120 should not change, in order that any regulatory, service or product requirements may be complied with. For example, if a text field is required to have a mandatory background color to signify an urgent condition then the Configurable Presenter 120 may respect the protected attribute and limit the extent of interaction available. This may be achieved either directly by interaction with an application or by tagging certain data within the Configurable Presenter'"'"'s data definitions.
The Configurable Presenter 120 may also adjust the appearance of UI elements based on the properties, existence or lack of other UI elements. For example, a set of checkboxes may modify their position to align themselves with each other, or the colors and images may be modified to improve contrast based on the current background. If battery power is low, then the choice of contrasting color may be altered so as to minimize appliance based lighting. Similarly, ambient lighting may be detected and responded to in a way that improves user perception of displayed data.
The Configurable Presenter 120 may perform its functions in accordance with thematic information that may be held in a separate store. This thematic information may be stored in a memory. In one implementation, by using a script language format, thematic information may be stored as text and may only be limited by the available memory size or allocation. The information stored may be altered or added to at any time and the Configurable Presenter 120 may interpret this stored information which may then govern the actions of the Configurable Presenter 120.
The Configurable Presenter 120 may maintain tables or lists which reference objects stored in the thematic information store. Each time a change is made which adds an object to the thematic information, the Configurable Presenter 120 may supplement its data and may record information relevant to locating this added object along with certain other information. This may enable the Configurable Presenter 120 to locate the object within an information store without having to read the entire store. In this way, a function governed by an object in the store may be exercised without unexpected delay in locating the object.
Below is provided a number of example systems and methods of user interface control. For the sake of clarity, multiple subsections with corresponding headings are provided. These subsections are provided solely in the interest of clarity and are not intended to limit the present invention in any manner.
Applications 110, being a higher level of abstraction than the OS 100, are those programs or elements of an appliance which deal with specific tasks. In the telephony example discussed above, these Applications 110 may include a dialer program or an address book, for example, with which the user interacts directly but through a component referred to as the User Interface or UI. The purpose of the UI, also referred to as the “man-machine interface,” is to bridge the gulf between the way a machine represents data and the way that human users prefer to interact. For example, when a user enters information, there is a desire to see the information being entered simply to produce a level of comfort that the correct information is being acted upon. It also needs to be arranged so that it is familiar to a user and big enough to be easily seen. All of these factors are referred to, in the vernacular, as “usability”.
The applications 110 normally deliver information to and receive information from the components of the UI. This may be from physical pieces of the appliance which are specifically configured to be useful as user interface components, such as a screen, a loudspeaker or earpiece and a keyboard of some description. Other UI interface hardware may include a blue tooth adapter or other signal receiver, touchpad, stylus input, finger scanner, accelerometers, compass, vibrator, or any known, or future known appliance interface mechanism. Broadly, these interface components may be subdivided into Visual Displays 150, Acoustic Components 160 and Tactile Components 170. However, as noted above, additional interfaces are considered which do not readily fit within any of these three illustrated UI components. These additional interface types are omitted from the figures to aid clarity.
Due to of the inherent complexities of these latter physical components, requirements for voltages and currents that differ from the usual logic levels may be found within modern programmable machines, the details of their operation may be handled by some Input/Output Driver 140 which is entirely dedicated to operating these components. In this way, connectivity to the physical world may be a resource that can be shared by many applications and these drivers may be a part of the OS itself or may be separate elements.
As is known by those skilled in the art, since a Driver 140 performs relatively well defined tasks, information transacted with a driver can be data that is placed in and read from a buffer without any further interaction on the part of the application. This information may contain data representative of the actual material to be output along with extra data that may instruct the driver to handle the output material in a specific way. For example, a text string to be displayed may be supplemented with additional information that causes the text to be shown in some particular font and size. In a typical appliance, a user may be limited to one of a small number of presentation options which are pre-programmed into the driver, such as the choice of one of three font sizes.
In some embodiments of the present invention the Connection 201 between the application and the buffers from which the Input Output Drivers 140 take their instruction may be severed and a Configurable Presenter 120 may be interposed in between the Applications 110 and the Drivers 140. This may be clearly seen in
The Configurable Presenter 120 in conjunction with one or more Definition Database(s) 130 form one embodiment of the User Interface Control System 115. The Configurable Presenter 120 may then become a proxy for the UI process. The Configurable Presenter 120 may, in some embodiments, exchange information with the Application 110 and the physical device'"'"'s Input/Output Drivers 140. The Configurable Presenter 120 may be transparent to some information in that it simply relays information without alteration. In other cases, the Configurable Presenter 120 may be opaque to information flow and information may be transformed quite completely. The opacity of the Configurable Presenter may be entirely controllable by stored information. The function of the Configurable Presenter may be defined entirely by thematic information stored in the Definition Database 130 which may store the rules by which the Configurable Presenter 120 governs information flow. Data storage may be in any of a number of forms and, as is well known to those skilled in the art, in one embodiment it may be represented as a text file. Likewise, tabular, matrix and compressed storage may be considered in some embodiments.
In typical appliances, the device Drivers 140 comprise components that may be programmed to cause a Display or touch screen 150, Acoustic Components 160 and/or Tactile Components 170 to provide information to and receive information from a user. Examples of this would be a touch screen (combining both the display and tactile elements) where data is displayed and the position and action of a pointing device such as a stylus or a finger are returned. The conversion of pointing device activity to input data is well known in the art. In another embodiment, acoustic drivers supplement the implementation and audio information may be routed by the Configurable Presenter 120 to this component. Tactile information may be vibration or pulsing that may be used to cue operation where the acoustic environment prevents audio cues from working well. In another implementation, Braille information may be output by the movement of sensor pegs.
As noted above, in some embodiments, the API 310 may contain message protocols that enable the Configuration Engine 320 to interact with data between the Applications 110 and the Drivers 140 to varying degrees. In some embodiments, this level of manipulation may be sub-divided into three interference levels: i) invoke the Configuration Engine 320, ii) permit the Configuration Engine 320 to interact and iii) prevent the Configuration Engine 320 from interacting. In this last instance, in some implementations, the API 310 may appear transparent to the data. In this case, data received by the API 310 may simply be repeated, thus resulting in a slight time delay, but otherwise not altering the data in any way.
As seen in
Then, at step 430, another inquiry may be made to check if any flag condition exists which indicates an application restriction. In addition to any preset restrictions on the data, appliance status or condition may be factored in to the decision process to see if there is some limitation on functionality. For example, power restrictions or time limitations may be included in the decision whether to limit functionality.
Responsive to the functionality test, either a full enabled theme may be fetched from the definition database, at step 450, or a limited theme may be selected, at step 440. In some embodiments, only one of the three possible results can be passed, at 470 or 480 respectively, to the I/O Driver at step 460.
As an example of restriction based upon device condition, in some embodiments the user chooses to display text as white lettering on a blue background under normal circumstances. In low power conditions, however, the color scheme may be transitioned to yellow lettering on a purple background. This high contrast enables screen backlighting to be reduced and lowers overall power consumption. Thus, instead of applying the preferred settings (white on blue), a limited setting may be applied instead (high contrast yellow on purple).
As an example of a time restriction on data manipulation, consider a traveling user who has arrived in a country whose time zone is different than the original location. If the appliance is time aware, then this information may be used to moderate the theme which might be specified. If it is now late at night, the alert tones may be conditioned to operate at reduced volume and the display restricted to partial intensity. By contrast if it is mid day, then the display intensity may be set to full brightness and the ring tone set to a more appropriate level for the circumstances. In one implementation, the acoustic input may be monitored and used to dynamically alter the alert tone for volume and cadence.
Referring back to
In the case of Key Type=Table, where the represented data may be stored as a table, the table entries may be value tuples that may be associated with a key which may then be returned to the application. These value tuples may be used by the Configurable Presenter 120 to establish or modify the parameters of items that may be provided to or received from the Drivers 140 such as Visual, Acoustic or Tactile signals. A table may be used to advantage in examples where the machine value of a key is to be changed. Consider the use of a 9 key numeric keypad for a simple application that requires a cursor to be moved or directed around a screen. In the case of a simple shooting game, the center key (normally the 5 key) might be designated as the fire button and the surrounding keys assigned movement attributes for the sighting mechanism. Here, the literal values are meaningless and a table might be useful to convert the 4 key to a value tuple that causes the sight to be panned to the left. Similarly the keys might represent musical notes in a diatonic scale and in this case the value tuples might represent frequencies that may be programmed into an audio oscillator. These table defined items may then be presented to the user of the appliance as displayed screen items or as audible information or in tactile form. An example of tactile data could be as simple as a vibration, or may be more complex, such as a Braille signal. Tactile input data may be acquired from accelerometers and may allow actions to be governed by finger taps other than on a touch sensitive screen. For example, a finger tap may be used to signal an acknowledgement without regard for position on a screen. In one implementation, a flag may be assigned to determine whether a function or table treatment is intended and a single bit may be used to switch from one to another. For example, if the bit is zero valued, then a table may be intended but if it is a one, then a function may be intended. If other operations are defined, then a four bit structure can define 16 possibilities and is well known in the art.
The following discussions and references to figures are provided to illustrate a set of examples for some embodiments of the present invention. The examples may include particular limitations which are unique to the given example and are not intended to extend to the invention as a whole. Likewise, some examples have been simplified in order to aid in clarity. It is understood that while the foregoing examples aid in explanation and clarification of the present invention, these examples do not limit the scope or function of the present invention.
Returning briefly to
Taking this example of Script M 630 which is simplified for ease of reading:
The first script line causes the Configurable Presenter 120 to create (add) a record of an object named “background.” This record may be stored in any of the means known in the art; for example this may be as a list or, as shown in
Flag data that is recorded may include information about related objects and their status, as well as, information concerning the status of the appliance. It will be appreciated that, although in simple cases it would be possible to associate objects by simply manipulating their location in the table, in more complex cases, it may be necessary to store the location of related objects. Flag data may be unique to the object it concerns and the net effect on the aggregate task may be determined algorithmically once all related objects have been parsed. These kinds of problems and their solutions are known in the art and such methods are described extensively in “The Art of Computer Programming” Knuth, Volume 3, Searching and Sorting. Where frequent associations are found, it may be economic to maintain separate tables each containing only related objects and determine which composite table to use from the context of the activity.
In this way, each script block in the theme may contain a single personalization component. The extent of the script is limited only by available memory and since this may be separate from the memory that the appliance uses to maintain its basic function, may have no adverse impact on the OS or the applications. However, if the script causes the Configurable Presenter 120 to undertake computationally intense actions then this may consume more resource than available at any one time in the same way as any other extensive computational effort.
A more sophisticated theme-element example may now be appropriate. Consider the sequence:
- which selects the image “background.png” and then resizes it to be the size of the screen. It sets the fill process and then makes it visible (the ‘show’ command) to the user. The image is then moved to the origin which in convention is the top left of the screen. The image may then be assigned a “layer value” which determines where it should be placed when there are several other elements on the screen. Higher values are moved to the foreground and lower values lie below them. In the manner known in the art, this causes images to obscure images beneath them and so appear like a paper pile. The function terminates after returning a value of “true” to indicate that a successful outcome was achieved. A theme may be composed of many such elements, especially for the more complicated situations such as setting a required background and imposing an inset background for one or more other features For example:
When the Definition Database 130 contains multiple elements resulting in multiple related objects, a further advantage may be realized by allowing objects to be combined or expanded. For example, in one implementation several objects may be consolidated to result in one single output in some cases and may be shown as separate individual objects in other cases.
As noted above, the present interface control system may be event driven, and events may generate callbacks in application code. Many non-trivial programs make use of callbacks or their equivalent in some way. Callbacks can be generated for a variety of reasons. Some may be synchronous with other events in the application, others may be generated from user events, while yet others may be a result of network or other activity. A Callback is a familiar construct in the C programming language and well known in the art.
Timers and I/O watching file descriptors are usually the most common events generating a response from the User Interface Control System 115. However, here a number of other events may generate activity from the system, including jobs, animators, signals and idlers.
Timers may be one of the most common callbacks in the system. Simple animations, transitions, time-outs, counters and many other effects can be implemented using timers. Repeated events are a frequent requirement in many programs. Generally when used in a repeated manner some sort of state may be stored for each call to keep track of what is happening. Once the objective has been achieved, the timer may delete itself, and its data.
Another extremely common event which may result in the system manipulating the user interface is input or output signals, as discussed above.
Thus, the image is set to “puppy.jpg” which is a recognized image file. At line 2 of the script, the native height and width of the image file is determined. The displayed image is then resized to ‘w’ and ‘h’ which is the same as its native size. The image may then be positioned to an horizontal position of ‘20’ and a vertical position of ‘10’. The last line of the script may then display the image on a visual interface by sending the data to the Driver 140.
An image object has its object width and object height within the graphical interface, while an image from a file also has its image width and image height. If the size of the image object to be displayed on the interface is larger than the image file'"'"'s width and height, the image will be displayed on the screen scaled up. Likewise if the size of the image object is smaller, the image will be displayed scaled down. What has been done in the example above at
Continuing the example,
evas_object_image_fill_set(image1, 0, 0, w, h);
which sets the fill region from (0, 0) of the object, with the width and height of the size of the object. Therefore only one image is displayed within the object. Image 2, on the other hand, may include the line:
evas_object_image_fill_set(image2, 0, 0, w/2, h/2);
which sets the fill region from (0, 0) of the object, with the width and height of half the size of the object. The image is now tiled around that region. As the region is half the size of the object, the image rendered four times within the image object. Lastly, image 3 may be produced utilizing this script line:
evas_object_image_fill_set(image3, 32, 32, w/2, h/2);
which sets the fill region from (32, 32) of the object, with the width and height of half the size of the object. The size of the image being rendered is the same as image 2. However, the fill region rectangle is now at (32, 32). Thus, image 3 is like image 2 but everything is now shifted to the right and to the bottom by 32 pixels.
void evas_object_image_border_set(Evas_Object *image, int I, int r, int t, int b);
The use of border essentially splits the image into nine regions, a central region, four corner regions and four edge regions. This is illustrated in
Additional image manipulations are possible. For example, image rotation may be readily accomplished through scripts such as:
The first parameter (src) is the source image, which may be a standard image object. This is the source image to be rotated. It will not be affected by the rotate itself. The angle determines the angle of rotation; it may be measured in a positive direction (counter-clockwise) from the X-axis in degrees. Negative angles and angles greater than 360 are treated consistently with methods known in the art. The function may be configured to seek out optimization options, so for example, with angles which are multiples of 90 degrees, the appearance of rotation may simply be achieved by copying rather than by calculation, thus improving the performance dramatically.
The created images may be rectangular, and rotated images are thus, in some embodiments, the same size or larger then the source image. Thus, some pixels in the destination may not be represented in the source image. The color and transparency of these “new” pixels may be set using the fill parameter. The fill parameter in the examples of
Similar to rotation, scaling of images is readily possible utilizing the following script:
The example scaling script provides a way to create a new scaled image from a loaded image asynchronously, thus avoiding repeated resource-expensive scaling routines. One implementation provides two algorithms for scaling, a smooth scaling routine for high quality resolution, and a subsample method for maximum speed.
The first parameter of the script is the object to be scaled. The next two parameters determine the parameters for the scaling itself. The first is the scaling routine, and the second is the ratio which determines the amount to scale the image down by. The final two parameters are the callback to be invoked on completion, and a user data pointer. Output of such a scaling routine may be seen in
For example, an image on layer 10, will be drawn beneath text on layer 20.
Additionally layers may be negative, so the image of
void evas_object_layer_set(Evas_Object *obj, int layer);
Because multiple layers can be confusing, in one implementation an object'"'"'s layer ID may be queried using:
int evas_object_layer_get(Evas_Object *obj);
In addition to layers, objects may exist as stacks within the same layer. In general, as objects are added they are placed at the top of the layer. Manipulating stack order of objects may be done in a number of ways well known in the art. For example:
Raising an object moves it to the top of the object stack for that layer, pushing all other objects on the same layer down. Lower moves it to the bottom, pushing the rest up in the stack. For more fine-grained control one may use:
Continuing the example screenshots,
Continuing the example, as evening progresses the sun icon may set and be replaced by a moon icon. The sky color may darken and stars may be illustrated. In some embodiments, when the device is relocated to a different time zone, the interface may likewise register this shift in daylight hours and compensate the interface display accordingly. The time and date may be seen displayed in the top right hand corner of this example.
Additional icons may indicate location, new text messages, voicemails, cellular signal strength and battery status. In addition to visual modifications to the display, the present invention may likewise customize audio and tactile interface components. Thus, animations in a character on the screen may be accompanied with sounds and tactile outputs, such as a vibration.
If the user opens a received message, the device may display the message in a themed display, as is seen at
Like the Demo theme,
Although not illustrated in the present figures, the neon boxes may, in some embodiments, include color defined information. For example, all device status indicators such as time, date, signal strength and battery may be illustrated as green neon signs. Urgent messages, such as missed calls or new texts, may be red. Links may be blue colored, and the screen title may be grey colored. Additionally, some embodiments of this example may include a unique set of tactile and audio interface controls as well.
The purpose of presenting
In addition to the relatively few examples provided, the present invention may be configured to include a wide range of other graphical, acoustic and tactile manipulations. This may include text display, resizing, font changes and color changes; further image effects including transparency, overlays, layouts, movements and clips; sound responses to various alerts and notifications; tactile outputs; media outputs and combinations of outputs. Further, composite outputs are possible, whereby composites are theme-able abstract animated objects. Thus, the sheer range of available outputs makes it impractical to provide an inclusive listing of examples in this application. Furthermore, the benefits gained from adding additional examples are unnecessary at this point for the understanding of the present invention.
In sum, systems and methods for user interface control and personalization on an electronic device is provided. Such a system provides control over user interfaces which are normally predefined and constrained by a manufacturer. Some embodiments of the system enables near run time modification of user interface content in an efficient manner by utilizing an interpretive element embodied in a virtual machine.
While the system and methods have been described in functional terms, embodiments of the present invention may include entirely hardware, entirely software or some combination of the two. Additionally, manual performance of any portion of the methods disclosed is considered by the present invention.
While this invention has been described in terms of several preferred embodiments, there are alterations, permutations, modifications and various substitute equivalents, which fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods and systems of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations, modifications, and various substitute equivalents as fall within the true spirit and scope of the present invention.