This invention relates generally to user interfaces, and more particularly, relates to customizable user interfaces.
It is known in the art to access components remote from a computing device as well as to alter user interface elements. Examples of such art include U.S. Pat. No. 6,100,888 to Guordal et al. issued Aug. 8, 2000, U.S. Pat. No. 6,031,532 to Guordal et al. issued Feb. 29, 2000, and U.S. Pat. Pub. No. US 2004/0158811 A1 to Guthrie et al. published Aug. 12, 2004.
The user interface of the typical personal computing device supports a wide range of customizable features. Items like color schemes, visual design of icons, and customized sound events can be personalized by the user. To simplify customization settings some systems support the logical grouping of these settings into themes. Loading a particular theme will automatically change all of the device's settings at once, thus saving the user from having to change the settings individually themselves.
Some advanced personal computing devices support user customization of the look and feel of individual user interface (UI) elements, such as widgets, in addition to themes. For example, with reference to
It is helpful to define several terms used when describing the art. A “skin” is an application level definition that specifies the look and feel of a single application on a device. Changing a skin for one application has no effect on other applications running on the same device. An example known in the art can be seen in skins for WinAmp or Windows Media Player employed on computers running Microsoft Windows™.
A “theme” likewise changes the look and feel of the UI, but is different in several distinct ways from a skin. First, a theme changes the look and feel of elements on a system level. This means that changing the UI theme used on a device affects all applications running on the device. Second, a theme usually allows more than just the look and feel to be changed. Sounds can be associated with particular UI events such as errors or warnings. Lastly, a theme definition usually includes such specifications as which screen saver to use and other system preferences.
Lastly, a “widget” is a system UI control that accepts user input from, or displays information to, the user. In the domain of UNIX™ terminology, such controls are referred to as widgets, while in the Windows domain such controls are typically referred to as “controls”. For the sake of consistency, all such controls are referred to herein as “widgets”. Widgets come in a wide variety of types. Some common types of widgets include, but are not limited to, a “text box”, “radio button”, “drop-down list”, “command button”, “tree view”, “check box”, etc.
As noted, it is common for personal computing devices to allow user customization of the graphical user interface of the device. Simple attributes such as color scheme and text size are the most typical attributes to alter. Some advanced devices support the user customization of the look and feel of the UI widgets in the system, while many systems include support for theme management.
Currently, if the user wants to install a new theme on a device it is necessary to 1) find a location where there is stored the theme package for the particular platform upon which they are operating and the device and software version they are using, 2) download the theme, 3) download any necessary extensions to the system that are required by the theme, and 4) install all of the pieces, often times engaging in the manual copying of files to the correct location. The problem, as viewed by the user, is a vast sea of theme packages for a multitude of platforms and devices. For the novice user this can be quite daunting.
Similar complexities confront a designer of themes. Currently a designer of themes must 1) decide which platform and device to support, 2) create the content for the theme such as widget definitions and related materials, and 3) package all of the material together for that specific platform and device to form a theme package. If the designer wants to create the same theme for a different device, it is necessary to repeat the process again. Such repetition is a time consuming activity. Another problem with the current scheme is that the designer must recreate the theme materials and distribution for every platform that they want to support. Even though most platforms share a common set of widget definitions, the designer must duplicate this effort repeatedly. If the designer wants to create a theme for a new platform, the designer must redesign and include everything from scratch.
Service providers offer theme definitions provided by the various designers to users. Under the current system this can waste storage space. Themes for many different platforms have a number of widget definitions in common. For example, most systems have the concept of a “command button”, “text box”, “check box” and “list”. Under the current scheme, storage space is wasted on the service provider since each theme is packaged for each supported platform and has to include duplicate definitions for the common widgets.
There therefore exists a need for a technique by which theme definitions can be efficiently created, stored and accessed by users desiring to deploy a theme on a device. Such a technique would be of benefit to mobile operators, content designers, and application developers.
In accordance with an exemplary embodiment of the invention a method comprises forming a query to specifically request at least one user interface element not resident upon a device, transmitting the query to a remote repository comprising a plurality of user interface element definitions, dynamically retrieving response data from the remote repository in response to the query, and applying the response data to a user interface of the device.
In accordance with a further exemplary embodiment of the invention a system comprises a means for forming a query to request at least one user interface element not resident upon a device, a means for transmitting the query to a remote repository comprising a plurality of user interface element definitions, a means for dynamically retrieving response data from the remote repository in response to the query, and a means for applying the response data to a user interface of said device.
In accordance with another exemplary embodiment of the invention a program of machine-readable instructions, tangibly embodied on an information bearing medium and executable by a digital data processor, to perform actions directed toward modifying a user interface, the actions comprises forming a query to request at least one user interface element not resident upon a device, transmitting the query to a remote repository comprising a plurality of user interface element definitions, receiving a response from the remote repository comprising at least one user interface element definition, and modifying a user interface of the device in response to the response.
The foregoing and other aspects of these teachings are made more evident in the following Detailed Description, when read in conjunction with the attached Drawing Figures, wherein:
a is an exemplary embodiment of a prior art user interface for selecting a theme.
b is an exemplary embodiment of a prior art user interface for selecting a theme.
a is an exemplary embodiment of a prior art user interface incorporating a theme.
b is an exemplary embodiment of a prior art user interface incorporating a theme.
a is an exemplary embodiment of a user interface comprised,of incongruent icons.
b is an exemplary embodiment of a user interface comprised of congruent icons.
a is an illustration of an exemplary user interface to which is applied a style definition.
b is an illustration of an exemplary user interface to which is applied a style definition.
In an exemplary embodiment of the present invention, there is provided a method for storing device independent, as well as device dependent, UI data, including, but not limited to theme data, style data, icons, and widgets, in a repository for access by users of a UI enabled device. As is described more fully below, the storage of such UI data on a repository capable of being accessed remotely by a user, allows for changes to be made to the UI of a device in a manner which requires a relatively low level of effort on the part of the user and which implements desired changes in an efficient manner.
With reference to
Device 10 is in bi-directional communication with repository 20 via link 17. While illustrated as a wireless link 17, link 17 may be a hardwire connection or any other form of connection that enables device 10 to transmit and receive digital data to and from repository 20.
Repository 20 stores UI data and is capable of responding to requests for UI data stored within repository 20 by retrieving the requested UI data and transmitting the requested UI data to a device 10 via link 17. Repository 20 may store, as non-limiting examples, widget definitions, icon definitions, UI style definitions, and theme definitions, collectively “UI element definitions” 21. With particular reference to widgets and themes, repository 20 may store definitions for widget types corresponding to a multitude of available themes.
In an exemplary embodiment, repository 20 stores UI element definitions 21 in a relational database. As a result, each widget definition may be attributed with the identifiers for themes with which the widget definition is compliant and, if the definition is device dependent, the device identifiers of all devices for which the widget definition is valid. Each widget definition may likewise include an attribute specifying all of the themes for which the widget definition is valid.
With reference to
There is also illustrated an exemplary table entry for a theme having a theme id of “0117” and a theme type of “classic”. While illustrated as a numeric value, the theme id may be referenced, as described below, using a naming convention similar to the manner in which extensible markup language (XML) namespaces are defined. The theme id has, as attributes, one or more widget ids corresponding to widgets which are included in the theme. As noted in the example discussed above, the table entry for widget id “0143” defines the widget as compatible with the theme “classic”. One will note that the theme id “0117” is of a type “classic” and, therefore, lists widget id “0143” as a component widget. The universe of attributes associated with a theme id, including, but not limited to, widget ids and theme types, fully define a theme.
While described with reference to a repository 20 hosting a relational database, the invention is broadly drawn to any form of data repository capable of storing and retrieving UI data as described more fully below.
The general form and function of repository 20 having now been described, it is possible to discuss the interaction of a device 10 and a repository 20 remote from the device 10. With reference to
At step 2, a processor 19 coupled to, or resident within, device 10 and capable of executing instructions such as those defined in software,receives the user's selection of “classic” and formats a request, or query, to the repository 20 to retrieve all of the relevant UI element definitions corresponding to the requested theme. In an exemplary instance, the query may include only the theme id or theme type. In such an instance, the repository would return all widget definition 41 data corresponding to widgets which have “classic” as a theme attribute. Note that the repository retrieves the requested widget definitions 41 and dynamically creates a response to the query. By “dynamically creates” it is meant that the content of the response is created in response to, and is dependent upon, the content of the query and, therefore, does not exist in finished form prior to creation. In another exemplary embodiment, the query may include a theme identifier (id) as well as an explicit listing of the widgets definition 41 data required. In such an instance, the requested user interface elements are specifically identified for retrieval. For example, the communication between the device 10 and the repository 20 can be performed using HyperText Transfer Protocol (HTTP) wherein the request is formatted as follows:
In addition to this example, further information may be embedded in the request. For example, a desired resolution or a device type may be included. By including such additional information, only the widgets comprising a theme which are additionally supported by a particular device need be accessed and transmitted to the device 10. With reference to
Returning to
Such a response is transmitted by the repository 20 to the device 10 at step 4. Upon receiving the response, the device 10, more specifically the processor 19, proceeds to either fetch the widget definitions from the URIs given in step 4, or alternatively, widget definitions 41 are extracted from the <widget_definitiondata> portion of the reply.
Finally, at step 5, the processor 19 changes the appropriate user interface settings in accordance with the newly received widgets and the user interface of the device is thereby changed accordingly.
As is evident, the system described above alleviates the need to store every widget definition 41 forming a given theme in a discreet theme package. A single widget definition 41 can be used by multiple themes. In addition, it is not necessary to send to a device 10 all of the UI data related to a requested theme. As noted above, theme data, that includes all relevant, requested widget definitions 41, can be dynamically formed of only widget definitions 41 compatible with the device from which a query is received, or which were specifically requested by a device 10.
In addition, a user of a device 10 does not have to engage in a complicated procedure to acquire all of the widget definitions 41 comprising a theme package. A user need only browse the available themes in the repository 20 and select one. The user's device 10 need only request the necessary widget definitions 41 and the remote repository 20 assembles the requested theme data on the fly and send it to the device 10.
In an alternative exemplary embodiment, the repository 20 is utilized to store UI data formed of icons. Icons are often application specific. Icons corresponding to particular applications are generally displayed and serve an access means through which an application can be invoked. As a result, loading an application onto a device 10 which is implementing a particular theme may result in a situation where the resident icon for the application does not match the theme. This is particularly possible when utilizing an application and accompanying icon that was developed and loaded onto the device 10 prior to the definition of the theme.
Typically, if a user interface is implementing a theme that lacks a theme compliant icon for an application, a default icon is utilized. Such a substitution often times results in a user interface that has an unattractive mixture of design elements, as is illustrated with reference to
With reference to
In an exemplary embodiment, two pieces of information are used to obtain an icon definition from the remote repository 20. The first is the theme id and the second is the application id. As noted above with reference to theme packages formed of widget definitions 41, the theme id can be created using a method similar to the way in which XML namespaces are defined. Regarding an application id, in the context of an exemplary system like Symbian™, each application is required to register a unique id with the Symbian™ company. Therefore, with systems utilizing a Symbian™ operating system the application id used in the lookup on the repository 20 can be the official id registered with Symbian™. On systems other than Symbian™, the application id could also be determined in a manner similar to the way in which XML namespaces are defined.
With reference to
At step 3, the device 10 queries the repository 20 for the icon definitions corresponding to the undefined applications. A query is sent from the device 10 to the repository 20, via link 17, that is comprised of either a skin id or a theme id and the application ids of the applications for which there are required icon definitions. For example, the query can be executed via HTTP and the query formatted as follows:
At step 4, the repository 20 responds to device 10 with either the icon definitions or the URI where the icon definitions can be obtained. For example, a response that returns the actual icon definition could take a format like the following:
The icon data may be formed of an image or images at different resolutions or may be defined in a scale independent manner, such as in SVG format. At step 5, the device 10 fetches the needed icons from the URIs provided in the response from the repository 20 in step 4 if necessary, or, otherwise, the device 10 utilizes the icon definitions as given by the repository 20 and updates the icons displayed on user interface 15 so as to provide the user interface 15 with a uniform look and feel.
Note that the example query from the device 10 and the subsequent response from the repository 20 demonstrated above show the minimal information required for processing a request. Additional information could also be included with the query to further narrow down the appropriate icon definition. For example, the desired display resolution of the icon could be passed with the request. This would aid in determining the level of detail desired by the device 10. Other relevant pieces of data could also be passed with each query or response.
In an alternative embodiment, there is provided a technique by which a device 10 can query a repository 20 for style information related to a theme. As noted above, loading and executing an application on a device 10 can result in a situation where icon definition data related to the application is not resident on the device 10. In such a situation, the repository 20 can be queried to provide icon definition data. In a more general sense, a device 10 may have resident various applications, icons, and widgets which require rendering in the user interface 15 but which are not compliant with the theme being displayed and which are not defined in the repository 20 for the specified theme. In such instances, it is common to resort to rendering default user interface elements such as default widgets and default icons. The use of default elements can result in an unattractive mixture of visual design elements, specifically user interface elements.
By storing style definitions in the repository 20, it is possible to define and store the general aesthetic constructs which underlie a theme. Once defined, the style definition can be utilized to generate user interface elements, such as icons or widgets, which are not individually defined in the repository 20 but which are generally in accord with a desired theme.
With reference to
With reference to
With reference to
For example, the query may be issued over link 17 in the form of an HTTP formatted request as follows:
At step 3, the repository 20 retrieves the requested style information and formats a reply. For example, a response that returns the style information could take a format like the following:
At step 4, the response is transmitted from the repository 20 to the device 10 and the device 10, at step 5, alters the appropriate user interface settings for the desired user interface elements as specified in the style definition data thus giving the device now has a consistent new look and feel. As a result, any user interface elements that were not defined in the theme can now be rendered with the modifications specified in the style data from the remote repository.
With reference to
As noted above, the invention may be practiced on a mobile station, in particular, a mobile phone. A mobile station (MS) is a handheld portable device that is capable of wirelessly accessing a communication network, such as a mobile telephony network of base stations that are coupled to a publicly switched telephone network. A cellular telephone, a Blackberry® device, and a personal digital assistant(PDA) with internet or other two-way communication capability are examples of a MS. A portable wireless device includes mobile stations as well as additional handheld devices such as walkie talkies and devices that may access only local networks such as a wireless localized area network (WLAN) or a WIFI network.
Computer programs such as drivers for the display 122, algorithms to modulate, encode and decode, data arrays such as look-up tables, and the like are stored in a main memory storage media 134 which may be an electronic, optical, or magnetic memory storage media as is known in the art for storing computer readable instructions and programs and data. In an exemplary embodiment of the invention, the main memory 134 stores a computer program for implementing the invention.
It is understood that the various exemplary embodiments described herein may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor, processor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or some combination thereof.
Alternative exemplary embodiments of the invention may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.
Programs, such as those provided by Synopsys™, Inc. of Mountain View, Calif. and Cadence Design™, of San Jose, Calif. automatically route conductors and locate components on a semiconductor chip using well established rules of design as well as huge libraries of pre-stored design modules. Once the design for a semiconductor circuit has been completed, the resultant design, in a standardized electronic format (e.g., Opus, GDSII, or the like) may be transmitted to a semiconductor fabrication facility or “fab” for fabrication.
While there has been illustrated and described what is at present considered to be preferred embodiments of the invention, it will be appreciated that numerous changes and modifications are likely to occur to those skilled in the art. It is intended in the appended claims to cover all those changes and modifications that fall within the spirit and scope of the claimed invention.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/IB2005/002272 | 8/1/2005 | WO | 00 | 3/2/2010 |