Display of menu items in a user interface

Display of menu items in the user interface {DISPLAY OF MENU ITEMS IN A USER INTERFACE}

FIELD OF THE INVENTION The present invention relates to a method for displaying menu items in a user interface, and more particularly to such a method for use in a device for use with a mobile communication network.

One of the limitations, common in many mobile devices, is that the display screen is quite small and it is not always possible to display all menu items on the screen at once when the menu is displayed. Conventional approaches tend to load all menu items into memory, along with associated icons or graphics, and then display them appropriately as the user scrolls up or down the menu. This approach is not an efficient technique for resource-constrained devices, such as mobile phones, and devices that use mark-up languages to render device displays and/or provide operating software for those devices.

Summary of the invention

According to a first aspect of the present invention, there is provided a method for displaying a subset of a plurality of user interface elements in a user interface, the method comprising: (i) determining the size of a subset of a plurality of UI elements that can be displayed in the user interface determining; (ii) determining a plurality of UI elements that may be selected for display within the user interface; (iii) choosing a subset of UI elements from the plurality of UI elements determined in step (ii); and (iv) displaying the subset of UI elements selected in step (iii) in the user interface. Step (iii) may be selected to select an additional subset of UI elements in response to the user input, and may then be repeated to display the additional subset of UI elements within the user interface.

According to a second aspect of the present invention, there is provided a data carrier comprising computer executable code for performing any one of the above methods.

According to a third aspect of the present invention, there is provided an apparatus comprising a display and a user interface, the apparatus comprising, in use, (i) determining a size of a subset of a plurality of UI elements that may be displayed within the user interface; ;

(ii) determine a plurality of UI elements that may be selected for display within the user interface;

(iii) selecting the subset of UI elements from the plurality of UI elements determined in step (ii); In addition

(iv) display in the user interface the subset of UI elements selected in step (iii).

According to a fourth aspect of the present invention there is provided an apparatus comprising processing means, storage means, display, user input means, wireless communication means and user interface, said apparatus being configured to perform any one of the methods described above. do.

Brief description of the drawing

1 is a schematic diagram of a system embodying the present invention;

2 shows the structure and operation of the server in more detail;

3 is a schematic diagram of software for a mobile device; In addition

4 is a schematic diagram of a device including a user interface according to an embodiment of the present invention;

DETAILED DESCRIPTION OF THE INVENTION

The invention will be described by way of example only and with reference to the accompanying drawings, in which Figure 1 shows a schematic diagram of a system embodying the invention. The system includes a server 100 , a content toolset 200 , a mobile device 300 , a motion support system (OSS 700 ), a content feeds 500 and a user interface (UI) source 600 . include During use, server 100 delivers content data and UI data to mobile devices 300 , 301 , ..., each of which includes a software package 400 . Server 100 interfaces with OSS traditionally used to operate mobile networks, for example, for billing, account management, and the like. The server 100 also interfaces with a content toolset 200: the content toolset receives data from UI sources 600, 601, ..., and the server includes a software package 400 contained within the mobile device 300. ) to package the UI data so that the packaged UI data can be transmitted. The server receives data from a plurality of content providers, the data is processed and packaged so that it can be transmitted to the software package 400 or accessed using the mobile device 300 software package 400 . do.

The system is divided into three separate domains: operator domain 50 includes systems and equipment operated by mobile network operators (MNOs); User domain 60 includes a plurality of mobile devices; Third party domain 70 includes content providers and UI providers that may be controlled or operated by a number of other entities.

2 shows the structure and operation of the server 100 in more detail. Server 100 includes a publishing component 110 and a content server component 150 . The publishing components include a database 111 , an import queue 112 , a content toolset interface 113 , a user interface 114 , and a catalog 115 . In operation, the publishing component receives content from the content toolset of the content toolset interface. The content exists in the form of a parcel 210a, 210b, ... (see below) including one or more trigs and one or more triglets. A trig is a user interface for a mobile device such as a mobile phone, and a triglet is a data file that can be used to expand or replace a trig. When a Fossil contains more than one trig, one of the trigs may be a master trig, from which other trigs are derived.

3 shows a schematic diagram of software 400 for a mobile device 300, comprising a mark-up language renderer 410, an update manager 420, a network communication agent 425; Resource manager (430), virtual file system (435), actor manager (440), multiple actors (445a, 445, ...), native UI renderer (450), support manager (support) manager 460 ), a tree manager 465 , and a mark-up language parser 470 .

This software preferably operates using the XML application TrigML, preferably the mark-up language renderer 410 to render the TrigXML code for display on the mobile device 300 . In addition, the mark-up language renderer uses the TrigML parser to analyze the TrigML resource, display the content on the device screen, and control the content replacement and viewing on the handset. The native UI renderer is used to display UI components that can be displayed without using TrigML, and is used to display error messages.

The software 400 is prepared and installed in a device-specific manner. For example, on MS smartphone devices, software is installed using CAB files, whereas on Nokia series 60 devices, software is installed using SIS files. Similarly, software upgrades are handled in a device-specific manner, and upgrades may be provided over the air. Software may be prepared in a more limited form, e.g. as a self-contained application that renders only its embedded content, i.e. in a form that cannot later add additional trigs to the trig supplied to that application. may be

The tree manager 465 exposes an interface to the resource manager 430 and a mark-up language renderer. The trig manager is generally responsible for managing the trig. This includes: maintaining knowledge of the trig in use, modifying the current trig, selecting a trig at startup, selecting additional trigs as a reserve for damaged trigs, maintaining a set of installed trigs, specific identifying where the trig is installed in the resource manager and reading the update channel definition of the trig and configuring the update manager appropriately.

The resource manager provides an abstraction of persistent store on the device, i.e. storing files as real files or as records in a database. The resource manager represents a mark-up language file system and a file system that interfaces with the update manager. It is responsible for handling the file path logic, distinguishing between actual resource files and actor attributes, mapping the tree-relative path to an absolute path, interfacing with the tree manager, and providing a change interface with the update manager.

In addition, the resource manager is responsible for ensuring the integrity of the resources stored in persistent storage, especially when faced with unpredictable disturbances such as loss of device power. The resource manager has no knowledge of the currently used trig. Its interface is thread-safe (since it can be used by both the update manager and the renderer).

The update manager handles the reception and application of trigs and triglets. The update manager presents an interface to the renderer and the trig manager, and initiates manual updates when directed by the renderer; control and implement automatic update channels when so configured by the trig manager; Responsible for displaying the progress of manual updates and restoring updates following unexpected loss of network connectivity and/or device power. The update packet format may be specified as a binary serialization of an XML schema.

The support manager provides an interface to other components to report the occurrence of events or errors. Depending on the severity of the error, the support manager logs the event and/or pops up an error message.

The actor manager 440 manages the set of actors 445 present in the software. It is: by the renderer when sending events to actors; It is used by actors who want to notify whether an attribute value is changed and actors who want to send events (see below).

Software includes multi-threaded applications running two or more threads, and is more likely to depend on how many and what kinds of actors are involved. Software mostly runs on one thread, referred to as the main thread. The main thread is used to run a renderer that communicates synchronously with other components. Actors always have a synchronous interface to the renderer. If an actor requires additional threads for its functionality, it is the actor's responsibility to manage inter-thread communication. When many actors require inter-thread communication, a light messaging framework is used to avoid unnecessary code duplication.

In addition to the main thread, the update manager runs a network thread. A network thread is used to download update packets, and is detached from the main thread, which causes the renderer to remain unchanged until the packet arrives. The update manager is responsible for handling inter-thread messaging, so that the update manager communicates synchronously with the renderer and resource manager as it applies the changes specified in the update packet.

The memory allocation scheme of this software is platform-specific. On the MIDP platform, the software simply uses the system heap and garbage collector for all of its memory needs. In order to keep the collection of obsolete information predictable and prevent unexpected stoppage during operation, the collection of obsolete information is forced whenever a content replacement event occurs. Assuming that the software has already successfully started and rendered the first page, it is assumed that any memory allocation would have failed if the software deletes all its references to the object, stale information, and restart.

On a C++ based platform, a mixture of pre-allocation and on-demand allocation will be built from the system heap. All memory required for start-up, if it causes the software to shut down (with a message if possible), is allocated any failure as soon as there is an order during start-up. Following successful launch, the memory required to render the content document model is pre-allocated. The content provided is guaranteed to be rendered and made to be used less than the prescribed limits. Additional use is made through RAM for various caches required for high-speed operation of the software. When memory conditions are poor, these caches are released from software, causing slow rendering performance.

The renderer receives information related to key presses. If no action is set at build time for a key, it is sent to the current focus element as a TrigML content event. Content events are then handled as defined by TrigML's general event processing logic.

For example, when a key is pressed, a 'keypress' event is sent to the renderer with a set of parameters for the relevant key. When a key is released, a '!keypress' event is sent to the renderer. When a key is held down for an extended period of time, a 'longkeypress' event is sent to the renderer. When released, '!longkeypress' and '!keypress' events are sent to the renderer.

Whenever the software is launched, it performs the following actions:

Check for interrupted update processing, and also proceed with it;

Check for updates in the file system (pre-staged, or installed in the file system by some other means), and process them;

· If known (which could be the latest running trig), start the current trig;

· If the current trigger is not set, a trigger flagged as 'default' can be started.

· If no default trig exists, the first valid tree in alphabetical order by name is chosen.

The trig is initiated by loading the specified resource name, start-up/default . TrigML specified in start/default is parsed as new content for the content root node.

If the trig is first run by the software after installation of the software, the trig is started by loading the resource name startup/firsttime . The software may record whether or not a trig was run in a file located in the top-level folder for that trig. Depending on the platform used by the mobile device, automatic startup of the software may be set as a build time setting option. Also, placing the software in the background following auto-initiation may be a build-time setting option.

A launcher may appear to the user as an application icon, and may choose to launch software with a trigger specified by the launcher, which may be indicated by a launcher icon and/or name. have. When using the launcher to initiate a trigger, it is possible to specify the 'entry point' parameter. This parameter is the resource name of the file found in the 'start-up' folder. If the trig has never been run before, this file is not used, in which case a file named 'firsttime' is used instead.

The software uses content resource files that are stored in a virtual file system on the device. A file system is described as 'virtual' because it cannot be implemented as an old file system, but all references to resources are file paths as if they were stored in a hierarchical system of folders and files. In addition, the software may contain some or all of the following information: usage statistics; active user counts; TrigManager state; TrigML fragment, and update channel specification (serialized as binary XML); PNG image; plain text, encoded in UTF-8 and then stored on the platform in a specific encoding; store other platform-specific resources, for example, cell phone ring tone files, background pictures, and the like.

A file in the file system can change when an actor changes a value or when a file is replaced by a triglet. When files in the /attrs directory change, the renderer recognizes it immediately, and the relevant branch of the content tree is updated and refreshed. When picture and text resources are changed, the renderer behaves as if the related resource is immediately reloaded (the entire content tree or just the related branches may be refreshed). When a TrigML fragment changes, the renderer behaves as if it were not aware of it and continued to display its current, possibly outdated content. This avoids the need for software to persist the <include> element and <load> history of the current content.

The software 400 is prepared on the mobile device in a device-specific manner. One or more triggers may be prepared (eg, stored as uncompressed update packets) as part of the installation process. Upon initiation, the packet is expanded and installed in the file-system.

The actor 445 is a component that issues attribute values and manages and emits events. Actors communicate synchronously with the renderer. When an actor requires asynchronous behavior, it is the actor's responsibility to manage and communicate with a thread outside of the renderer's main thread.

One limitation, common in many mobile devices, is that the display screen is quite small and it is not always possible to display all menu items on the screen at once when the menu is displayed. Conventional approaches tend to load all menu items into memory, depending on the associated icon or graphic, and then display them appropriately as the user scrolls up or down the menu. This approach is not an efficient technique for resource constrained devices, such as mobile phones, and devices that use mark-up languages to render device displays and/or provide operating software for those devices.

This problem is addressed by providing an efficient technique that allows a limited number of menu items to be loaded into memory so that these menu items are displayed simultaneously by the device. When the user scrolls up or down the menu, the item(s) that are no longer on the display are discarded, and the item(s) that are now on the display are loaded into memory.

Preferably, this can be implemented using the <griddata> element of TrigML, which defines a list view of some data, where this data is stored in a folder in the file system and the list appearance has the same structure for each item . The <griddat> element contains a 'repeat-over' attribute, which specifies the folder in which the data can be located. The single child element of <griddata> is a template for the appearance of each item in the list.

This template may use a specific symbol, for example '$$' to refer to an iterator. This is a template value that changes whenever the template is instantiated: for example

<griddata repeatover="news/headlines">

<text res="news/headlines/$$/title.txt"/>

</griddata>

where the folder news/headlines/ is

O/title.txt

1/title.txt

2/title.txt

3/title.txt

includes This displays one list of four items, each described by a single <text> element pointing to the 'title.txt' resource in the 'news/headlines/$$' folder. Where the source data has more items than the <griddata> element has space on the display, the <griddata> element only displays the items that can be displayed. When the user scrolls through the list, the <griddata> element shifts the 'data-window' accordingly. An advantage of this technique is that only the resources currently required by the display are actually loaded into memory, which reduces memory usage and reduces the amount of time it takes to render the items in the list.

A similar approach can be used to specify the order in which the list is displayed. If the target of the 'repeat-over' attribute is a file instead of a folder, it can be assumed that this file contains a resource name that is used repeatedly. E.g,

<griddata repeatover="football/league">

<text res="football/teams/$$/name.txt"/>

</griddata>

where the file football/league is

Manchester

Arsenal

Chelsea

including,

The folder football/teams/ is

Manchester/name.txt

Arsenal/name.txt

Chelsean/name.txt

, and each name.txt is a text file that holds the team name. The result of this is that the test files associated with the teams are displayed in a prescribed order, and are displayed in a prescribed area of the device display.

An additional example of this is given below, with a template having a list containing three entries, resulting in a list of first and last names data to be displayed,

<gridlist id="myList"repeatover="path/to/list" rows="3" >

<group>

<text res="$$/surname"/>

<text res="$$/firstname"/>

</group>

</gridlist>

This approach can be extended to allow this list to be nested within other lists. Following this approach, if there are multiple different lists, it is ambiguous which list the '$$' operator refers to. The problem is that '$$' is an expression that uniquely identifies the list it refers to, for example:

{/elem/myList/index}

is solved by replacing

In addition to being able to refer to a list uniquely, this approach allows an item to refer to the list but not actually exist in the list. For example, the title bar of a window contains text related to a selected item in a list, and the text in the title bar may change as the list is scrolled.

When data is accessed by means other than the file system, eg, it is stored in a database, or created on the fly by another software component, this way, if the virtual file system 435 is used, i.e., If a file system interface can be mapped onto a sub-provider of data, it can still be used. This means that the content can still be arranged, as described above, but the data can be presented in a way that allows for efficient data storage and retrieval.

Updates sent to the OTA can be retrieved using an HTTP-GET request initiated by software. The GET request is directed at the URL associated with the update. The body of the HTTP response is a binary file carrying data in update packet format. Data reception is handled in a separate thread from the renderer thread. For (automatically initiated) background updates, this allows the user to continue browsing the web for the UI. For foreground updates (manually initiated), this causes the renderer thread to display a progress bar and accept a cancel instruction.

The algorithm used to unpack and install updates is device specific. However, it is important that this algorithm is safe from unexpected interruptions (eg, lack of power), so that a corrupted or unrecoverable state does not reach the file system. This may be achieved by using two threads (a network thread and a renderer thread) to interrupt the renderer thread only for as short a time as possible, with the goal of allowing as much of the update processing performed by the network thread as possible.

There are other failed modes to be considered: if HTTP-GET fails to initialize, or if HTTP-GET satisfies the HTTP error response code, at update time, this attempt is abandoned, and a new update attempt is made on a later date. A retry technique is used to initiate When an HTTP resource is interrupted by a loss of network signal, any temporary files are deleted and a retry technique is used to restart the update attempt at a later date. The header data file is deleted if the update header indicates that the update payload size may be too large to fit on the device, if the update requires an incompatible version of the software, or if the update already exists on the device. and the update is attempted, and any subsequent retries are canceled.

A TrigML fragment is a file containing the text TrigML, and resource references within these fragments are virtual file paths. The mapping of these virtual file paths to the actual file paths is defined by the TrigDefinition file. This file also specifies other characteristics of the trig. Also, when used to compile a triglet, this file specifies whether the input TrigML/PNG/Text resource maps onto a variant of the trig's virtual file-system.

In order to successfully render the user interface of a mobile device, the mark-up language must have the following qualities. Concise page rules, consistent layout rules, can be implemented in a compact renderer, provide multiple layering and arbitrary overlapping content, event model, which needs to be changed between pages of UI Requires only the display area to be repainted, includes a hook to the platform that reads the property values of incoming and outgoing events, is extensible, and is graphically flexible. TrigML provides an overview of these properties and elements, and attributes that provide this desired functionality can be found in Applicant's co-pending application GB0403709.9 (filed Feb. 19, 2004).

It is desirable to minimize the cost of re-branding the UI and producing a continuous flow of updates. This can be made possible by providing an efficient flow of information throughout the data transmission from the creative process to the user. A container, referred to as Fossil, is used for templates, UI, and UI updates for third-party associations. Fossil contains all the information needed to be produced by third parties, tests and transmits branded UIs and updates.

A number of different UIs may be derived from a common base. Typically the common base implements most of the interface itself, and a trig derived from the common base implements small changes on it, such as branding. A triglet may be derived from a trig, and it may override any resources from the parent tree it chooses (optionally it may introduce its own resource). It should be noted that "resource" also refers to TrigML, so the behavior or layout of a trig can be changed by a triglet as simply as replacing a single image or a single piece of text.

Fossil comprises one or more elementary treegs (i.e., trigs not derived from any other tree), one or more multiple trigs derived from an elementary treeg, a plurality of triglets derived from any of the treegs, and It may include a plurality of triglets derived from other triglets.

Fossil format is an opaque binary format that stores all such information as serialized objects. Fossil may contain a number of resources, such as images, text, URLs, update channels, cell phone ringtone files, wallpapers, native applications, and the like. Each resource includes permission information on how to read, edit, or delete the resource. Fossil may be used to develop trigs and/or triglets for mobile devices with different capacities, such as display size and RAM capacity. To simplify this, multiple layers may be defined, and data resources or TrigML elements may be classified within the layers. Trigs or triglets are compiled from Fossil, and most suitable resources or TrigML elements can be selected and compiled from a particular device.

4 is a schematic diagram of an apparatus 800 including a user interface in accordance with an embodiment of the present invention. The device comprises a user interface 815 and a display 810 for displaying user interface means 820 , allowing a user to interact with the user interface 815 . One or more wireless communication interfaces 850 may be provided for the processor 830 to execute software stored in one or more storage means 840 and to enable communication with other devices and/or communication networks. One or more batteries 860 may be housed for powering the device, which may also include an interface for connecting electrical power sources and/or communication cables.

These components and interfaces will depend on the nature of the device. Although such a user interface may be implemented within a mobile or cellular telephone handset, it is also appreciated that it is applicable to other portable devices, such as digital cameras, personal digital assistants, digital music players, GPS navigators, handheld game consoles, and the like. It is also applicable to other devices that include a user interface, such as a laptop or desktop computer.

The user interface means may comprise a plurality of buttons, such as a numeric or alpha-numeric keyboard, or a touch screen or the like. One or more storage devices may include a form of non-volatile memory, such as a memory card, so that stored data is not lost even when power is turned off. A ROM storage means may be provided for storing data that does not require updating or changing. Some ROMs may be provided to support faster response times in the caching of frequently accessed data. The device may also accept a user-removable memory card and optionally use a hard disk drive as the storage means. The storage means used is determined by balancing different requirements such as device size, power consumption, required storage, etc.

Such devices can be implemented in virtually any wireless communication network, eg 2nd Generation Digital Mobile Telephone Networks (ie GSM, D-AMPS), so-called 2.5 Generation Networks (ie GPRS, HSCSD, EDGE), 3rd Generation WCDMA or It may be implemented in conjunction with CDMA-2000 networks and developments and derivatives from these and similar networks. Within buildings and campuses, other technologies such as Bluetooth (based on radio or optical systems), IrDa, or wireless LANs may be used. USB and/or firewall connectivity may be provided for data synchronization with other devices and/or battery charging.

Computer software for implementing the method as described above and/or computer software for configuring an apparatus as described above may be provided on a data carrier such as a floppy disk, CD-ROM, DVD, non-volatile memory card, or the like.

This application claims priority to British Patent Application No. 0403709.9, filed on February 19, 2004, the contents of which are incorporated herein by reference.