MXPA06009489A - Display of menu items in a user interface - Google Patents

Abstract

A user interface for a device is provided, wherein the user interface generates a list of elements that is too large to be displayed within a region of the UI. The number of list elements to be displayed is determined and an appropriate subset of list elements are then chosen from the generated list of elements.

Description

"MENU ELEMENT SCREEN IN A USER INTERFACE" FIELD OF THE INVENTION The present invention relates to a method for deploying menu items in a user interface and in particular to such a method for use with a device for use with a mobile communication network.

BACKGROUND OF THE INVENTION One of the limitations that is common in most mobile devices is that the display screen is quite small and when a menu is displayed it is not always possible to display all the menu items on the screen at the same time. Conventional approaches tend to load all menu items into memory, along with associated icons or graphs, and then view them appropriately as the user moves up or down the menu. This approach is not an efficient technique for devices that have limited resources, such as mobile phones, and for devices that use a markup language to supply the device screen and / or to provide operating software for the device.

BRIEF DESCRIPTION OF THE INVENTION According to a first aspect of the present invention, there is provided a method for displaying one or more menu items in a user interface, the method comprising the steps for: (i) determining the number of items of menu that can be displayed in the user interface; (ii) determining a set of menu items, from which one or more menu items may be selected for display in the user's inferred; (iii) selecting a number of menu items for display, the number of menu items being selected according to the number determined in step (I) and selecting the menu items from among the set of menu items selected in step (ii); and (iv) displaying the number of menu items selected in step (iii) within the user interface. According to a second aspect of the present invention, a data carrier comprising computer executable code is provided for executing any of the above methods.

According to a third aspect of the present invention, there are provided 12. A device comprising a screen and a user interface that configures the device, in use, to (i) determine the number of menu items that can be displayed in the user interface; (ii) determining a set of menu items, from which one or more menu items can be selected for display at the user interface; (iii) selecting a number of menu items for display, selecting the number of menu items according to the number determined in step (i) and selecting the menu items from the set of menu items selected in step (ii); and (iv) display the number of menu items selected in step (iii) in the user interface. According to a fourth aspect of the present invention, there is provided a device comprising processing means, storage means, a screen, user input means, wireless communication means and a user interface, where the device is configured to execute the method of any of the methods described above.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows a schematic representation of a system embodying the present invention; Figure 2 graphically represents in more detail the structure and operation of the server; Figure 3 shows a schematic representation of software for mobile devices; and Figure 4 shows a schematic representation of a device comprising a user interface according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION The invention will now be described only by way of illustration and with respect to the accompanying drawings, in which Figure 1 shows a schematic representation of a system embodying the present invention. The system comprises the server 100, set of content instruments 200, mobile devices 300, operational support systems 700 (OSSs - operational support systems), content feeds 500 and user interface sources 600 (Ul-user interface). During use, the server 100 communicates the content data and data of Ul to the mobile devices 300, 301, ..., each of which comprises the software package 400. The server 100 performs the interfaces with the OSSs 700, conventionally using the OSSs to operate mobile networks, for example, billing, account management, and so on. In addition, the server 100 performs the interfaces with the set of content instruments 200: the set of content instruments receives the data from the sources of Ul 600, 601, ..., and packages the Ul data in such a way that the server can transmit the packaged Ul data to the software packages 400 comprised within the mobile devices 300. The server receives the data from a plurality of content feeds, and this data is processed and packaged so that it can be sent to the software packages 400 or so that the mobile devices 300 can access the data using the software package 400. The system can be divided into three separate domains: the operator domain 50 comprises the systems and equipment operated by the mobile network operator (MNO); the user domain 60 comprises a plurality of mobile devices and the third domain 70 comprises the content feeds and feeds of Ul which can be controlled or operated by a number of different entities. Figure 2 graphically depicts in more detail the structure and operation of the server 100. The server 100 comprises the publishing component 110 and the content server component 150. The publishing component comprises the database 111, the import queue 112, the interface 113 of the set of content instruments, the user interface 114 and the catalog 115. During its operation, the publishing component receives content from the set of content instruments in the interface of the set of content instruments. The content is presented in the form of a look 210a, 210b, ..., (see below) comprising 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 extend or alter a trig. If a plot comprises more than one trig then one of the trigs can be a master trig from which the other trigs are derived.

Figure 3 shows a software schematic representation 400 for mobile devices 300, which comprises a dial-language interpreter 410, update manager 420, network communications agent 425, resource manager 430, virtual file system 435, administrator 440 of actors, a plurality of actors 445a, 445, ..., interpreter 450 of native Ul, administrator 460 of support, administrator 465 of trigs, and analyzer 470 of marking language. It is preferred that the software operate using TrigML, which is an XML application and that the markup language interpreter 410 interprets the TrigXML code for the screen on the mobile device 300. The markup language interpreter also uses the Tag Analyzer. TrigML to analyze the resources of TrigML, visualize the content in the device screen and control the replacement and visualization of the content in the portable telephone. The interpreter of the native Ul is used to visualize the components of Ul that can be visualized without the use of TrigML, and to visualize error messages. Software 400 is provided and installed specifically to the device. For example, for a Nokia Series 60 device, the software is installed using an SIS file, while for a MS Smartphone device the software is installed using a CAB file. Similarly, software updates are handled specifically to the device and updates can be provided by air. The software can be provided in a more limited format, for example, as a standalone application that interprets its content formation only, that its additional trigs can not be added later to the trig that is supplied with the application. Trigger administrator 465 presents an interface with resource manager 430 and markup language interpreter. He is responsible for the administration of trigs in general. This includes: persisting knowledge of the trig in use, changing the current trig, selecting a trig start, selecting an additional trig as a backslash for a corrupt trig, keeping the set of trigs installed, identifying when a particular trig is installed in the resource manager and read the updates channel definitions of a trig and configure the update manager appropriately. The resource manager provides an abstraction of the persistent storage on the device, that is, store the files of how real files, or as records in a database. The resource manager presents a file system interface to the markup interpreter and the update manager. It is responsible for managing a file path logic, distinguishing between real resource files and actor attributes, mapping trajectories relative to trig in absolute trajectories, interfacing with the trig manager and providing a modification interface to the administrator. updates The Resource Manager is also responsible for ensuring the integrity of the resources stored in persistent storage, especially in the case of unpredictable interruptions such as a loss of device power. The Resource Manager has no knowledge of the trig currently used. Its interface is free of threads (since it is used by both the Update Manager and the Analyzer) from different threads. The Update Manager manages the reception and application of trigs and triglets. The Update Manager presents an interface with the Interpreter and Trigs Administrator and is responsible for: initiating manual updates when instructed by the Interpreter; control and implement the automatic updates channel when configured by the trig administrator; indicate the progress of a manual update and retrieve an Update after the unexpected loss of nek connection and / or device power. The format of the update package can be defined as a binary serialization of an XML schema. The Support Manager provides an interface for other components in order to report the occurrence of an event or error. Depending on the severity of the error, the Support Manager will log the event and / or display a drop-down error message. The Actor Manager 440 then searches for the 445 set of actors present in the software. It is used by: the interpreter when the content is sending events to an actor; the actors that wish to notify that an attribute value has changed and the actors that wish to broadcast an event (see below).

The software can comprise a multiple thread application that executes a minimum of two threads, very possibly depending on how many and what kind of actors are included. The software runs mainly on a thread, referred to as the main thread. The main thread is used to execute the interpreter which communicates synchronously with other components. The actors always have a synchronic interface with the Interpreter. If an actor requires additional threads for its functionality, then it is the responsibility of the actor to manage the inter-wire communication. A lightweight message structure is preferred to avoid unnecessary duplication of code where many actors require inter-thread communication. In addition to the main thread, the update manager runs a network thread. The network thread is used to download update packages and is separated from the main thread in order to allow the interpreter to continue without changes until the package has arrived. The Update Manager is responsible for handling the inter-thread messages in such a way that the Update Manager communicates synchronously with the Interpreter and the Resource Manager when the changes defined in an Update Package are applied. The memory allocation strategy of the software is specific to the platform. On MIDP platforms, the software simply uses the reserved area of the system and the garbage collector for all its memory requirements. Garbage collection is applied at any time that a content replacement event occurs in an attempt to keep the garbage collection predictable and not suffer unexpected breaks during the operation. It is assumed that any memory allocation could fail, in which case the software will remove all its references to objects, garbage collection, and restart assuming that the software has already successfully started and will interpret the first page. On platforms based on C ++, a mix of pre-assignments and assignments will be made on demand from the reserved area of the system. All the memory required for the start is assigned on demand during the start, with any faults causing the output (if possible with message) of the software. After a successful start, the memory required to interpret the content document model is pre-assigned. The content provided has the authorization to use less than a defined limit, the interpretation is guaranteed. Additional RAM is used for various memories associated with the necessary for a quick operation of the software. When memory conditions are low, these associated memories will be released resulting in low performance of interpretation from the software. The Interpreter receives information regarding the oppression of keys. If there is no configured behavior in the training time for a key, it is sent as a TrigML content event to the current focus element. Then, the content event is handled as defined by the normal logic of the TrigML event processing. For example, if a key is pressed, an event "keypress" is sent to the Interpreter with a parameter configured with the relevant key. When it is due to the key, a keypress event is sent to the Interpreter. If you keep pressing a key for an extended period of time, an event? Longkeypress' is sent to the Interpreter. In the release, both an M longkeypress 'event and a?! Keypress' are sent to the Interpreter. At any time you start the software, perform the following actions: Verify, and continue with, the interrupted processing of Updates; Verify, and process, the Updates that reside in the file system (whether pre-provided, or installed in the file system by some other means); If known, start the current trig (which may be the last running trig); • If a current trig is not established, a trig that has been labeled efault can be started. The presence of a trig default fails, the first valid trig in alphabetical order of names will be selected. A trig starts when loading the name of the defined resource, start / default. The TrigML defined in the start / default is analyzed as the new content for the content root node. The first time a trig is executed by the software after its installation, the trig is started by loading the name of the start / first time resource. The software can register whether or not it has been executed in a file located in the highest level folder for that trig. Depending on the platform used by the mobile device, the automatic start of the software can be established as a training time configuration option. In addition, placing the software in the background after an automatic start can also be a training time configuration option. An initiator can appear to the user as an application icon and select whether to start the software with a trig specified by that initiator (this trig can be indicated by an icon and / or initiator name). When an initiator is used to start a trig, it is possible to specify a "point of entry" parameter. The parameter is a resource name of a file found in the "start" folder. This file is not used if the trig has never been executed before, in which case the file called? Firsttime '(? Firsttime') is used instead. The software uses content resource files stored in a virtual file system on the device. The file system is described as virtual since it can not be implemented as a classic file system, however, all references to resources are file paths as if they were stored in a hierarchical folder and file system. In addition, the software stores some or all of the following information: usage statistics; active user accounts; TrigManager status; TrigML fragments and update channel definition (serialized as binary XML); PNG images; flat text, encoded as UTF-8 OTA and then stored in a specific encoding to the platform; Other resources specific to the platform, for example, tone files, wallpaper images, etc. Files in the file system can be changed, either when the attribute value of the actor changes, or when a file is placed by a triglet. When the files in the / attrs directory change, the Interpreter is immediately notified and the relevant branches of the content tree are refreshed and refreshed. When the images and text resources change, the Interpreter behaves as if the affected resources are refreshed immediately (either the entire content tree or only the affected branches can be refreshed). When the TrigML fragments change, the Interpreter behaves as if it has not been notified and continues to visualize its current content, possibly expired. This is to prevent the software from needing to persist < includes > (< include >) elements and history of < load > (< load >) of the current content. Software 400 is provided to mobile devices in a method specific to the device. One or more trigs may be provided as part of the installation, for example, stored as an uncompressed update package. At the beginning, the package can be expanded and installed in the file system. Actors 445 are components that publish attribute values and handle and issue events. The Actors communicate with the interpreter synchronously. If an actor needs asynchronous behavior, then it is the responsibility of the actor to manage and communicate with a thread external to the main thread of the Interpreter. One of the common limitations in many mobile devices is that the display screen is quite small and when a menu is displayed it is not always possible to display all the menu items on the screen at the same time. Conventional approaches tend to load all menu items into memory, along with associated icons or graphs, and then displayed appropriately as the user scrolls up or down the menu. This approach is not an efficient technique for devices that have limited resources, such as mobile phones, and for devices that use a markup language to interpret the device screen and / or to provide operating software for the device. This problem is addressed by providing an efficient technique that allows a limited number of menu items to be loaded into the memory, such that these menu items can be displayed simultaneously by the device. When the user scrolls up or down the menu, the item (s) that are no longer on the screen is (are) discarded and the item (s) is (n) now on the screen is (are) loaded (s) in memory. Preferably, this can be implemented using a <element; griddata > in TrigML to define a list view of some data, where the data is stored in a folder in the file system, and the appearance of the list has the same structure for each element. The < griddata > It includes a "repeat-over" attribute that specifies the folder in which the data can be located. The only child elements of < griddata > It is a template for the appearance of each item in the list. The template can use a special symbol, for example $$ 'to refer to the iterator. This is the variable template that changes every time the template is instantiated: for example < griddata repeatover = "news / headlines" > < text res = "news / headlines / $$ / title. txt" / > < / griddata > where the folder news / headlines / contains: 0 / title.txt 1 / title.txt 2 / title.txt 3 / title. txt This would display a list of 4 elements, each one described by a simple element < text > which points to the resource? title. txt 'in the folder? newws / headlines / $$'. When the source data has more elements in them than the space for the display that has the < griddata > , the < griddata > visualize only those elements that can be visualized. When the user scrolls through the list, the < griddata > change the ata-window '(entana-data') accordingly. The advantage of this technique is that only the resources required by the current screen are actually loaded into memory, which reduces memory utilization and reduces the amount of time it takes to interpret the list of elements. A similar scheme can be used to define the order in which a list is displayed. If the purpose of the repeat-over attribute is a file instead of a folder, then it can be assumed that the file contains a list of resource names to be used in the iteration. For example, < griddata repeatover = "football / league" > < text res = "footbal / teams / $$ / name.txt" / > < / griddata > where the football / league file contains: Manchester Arsenal Chelsea the football / teams / folder contains: Manchester / name. txt Arsenal / ame. txt Chelsea / name. txt and each yam. txt is a text file that stores the name of the computer. The result of this is that the text files associated with the equipment would be displayed in the defined order and within the defined area of the device screen. Below is an additional example of this, with the template generating a list of surname data, name to be displayed, the list comprising three entries. < gridlist id = "myList" repeatover = "path / to / list" rows = "3" > < group > < text res =? $$ / surname "/ > < text res =" $$ / firstname'V > < / group > < / gridlist > This approach can be extended to allow lists to be nested within other lists. After the above approach, if there are a number of different lists, then there is ambiguity about which list the operator $$ 'refers to. This problem is addressed by replacing $$ r with an expression that uniquely identifies the list to which it is referring, such as:. { / elem / myList / index} In addition to being able to refer only to a list, this approach allows the elements to reference the list but not currently on the list. For example, the title bar of a window could contain text referring to the selected item in a list and the text in the title bar could change as the list scrolls. When the data is accessed by means other than the file system, for example, it is stored in a database, or is generated on the fly by another software component, this scheme can still be used if a virtual file system 435 is used, which can map a file system interface to the underlying provider of the data. This means that the content can still be configured as described above, but the data can be provided in a method that allows an efficient storage and retrieval of data. Updates that sent OTA can be resumed using HTTP-GET requests initiated by the software. The GET request is addressed in the URL associated with the Update. The body of the HTTP response is a binary file that carries data in an Update Pack format. The reception of data that they handled in a thread separated from the Interpreter thread. For background updates (started automatically) this allows the user to continue navigating the Ul. For foreground updates (manually initiated) this allows the Interpreter thread to display a progress bar and hear a cancellation instruction. The algorithm used to unpack and install an update is specific to the device. However, it is important that the algorithm is safe against unwanted interruptions (for example, loss of power), in such a way that the state of non-corruption or unrecoverable in the file system is reached. This can be achieved by using two threads (a network thread and an interpreter thread) with the goal of having as much of the update processing as possible achieved by the network thread in order to interrupt the interpreter thread a certain amount of time. as short as possible. There are other failure modes to consider: if an HTTP-GET can not be started, or if an HTTP error response code is met, then this attempt is abandoned in an Update and the retry strategy is used to start a new one attempt to update at a later date.

When an HTTP response is interrupted by the loss of the network signal, any temporary files are deleted and the retry strategy is used to restart the Update attempt at a later date. If an 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 it already receives the Update on the device then the data file is deleted from the device. header and the Update attempt and any subsequent retries are canceled. The TrigML fragments are files that contain TrigML and the resource references within these arguments are virtual file paths. The mapping of these virtual file paths to the actual file paths is defined by a TrigDefnition file. This file also defines other trig properties. When used to compile a triglet, this file also defines how the TrigML / PNG / Input Text resources are mapped in the virtual file system modifications of a trig. In order to successfully interpret the user interface of a mobile device, the markup language must have the following qualities: concise page definitions, consistent presentation rules, that can be implemented in a compact interpreter, provides multiple layers and arbitrary overlay content , model of events, require the repainting of only the areas of the screen that have to change between the pages of the Ul, include hooks to the platform to read the property values that receive events and that send events, extensible, and be graphically flexible TrigML provides these features and a summary of the elements and attributes that provide the desired functionality can be found in our co-pending application GB0403709.9, submitted on February 19, 2004. It is desirable that the cost of requalifying the UIs and producing a red continuous updates is minimal. This is possible by providing an efficient flow of information from the creative process to the transmission of data to users. A container, referred to as a plot, is used for UIs, Ul updates, and templates for third party participation. The plots contain all the information necessary for a third party to produce, test and send UIs and qualified updates. Many different UIs can be derived from a common base. Typically, the common base would increase most of the same interface, and the three derived from it would increase small variations in it, such as rating. A Triglet can be derived from a Trig, and can control any of the resources from the parent Trig it selects (optionally you can enter your own resources). Notice that the "resources" here also refer to TrigML, so that the behavior of the presentation of a Trig can be modified by a Triglet as obvious as replacing its a simple image or a piece of text. A plot can comprise one or more base trigs (that is, a Trig that is not derived from some other trig), one or more multiple trigs derived from a Trig base, a plurality of triglets derived from any of the trigs and a plurality of triglets derived from other triglets. The parcel format is an opaque binary format that stores all this information as serialized objects. The plot can include a certain amount of resources, such as images, text, URLs, update channels, tone files, background images, native applications, and so on. Each resource contains permission information on how to view, edit, or delete the resource. Plots can be used to develop trigs and / or triglets for mobile devices that have different capabilities such as scrsize, RAM capacity. To simplify this, a number of hierarchies can be defined and the data resource or TrigML elements can be classified within the hierarchies. When a trig or triglet is compiled from a parcel, the most appropriate resources or elements of TrigML can be selected and compiled for a particular device. Figure 4 shows a schematic representation of a device 800 comprising a user interface according to an embodiment of the intervention. The device comprises a scr810 displaying the user interface 815 and the user interface means 820, which allow the user to interact with the user interface 815. A processor 830 executes the software that is stored in one or more storage means 840 and one or more wireless communication interfaces 850 may be provided to allow communication with other devices and / or communication networks. One or more batteries 860 may be served to power the device, which may also comprise interfaces to receive electrical power and / or communication cables. The nature of these components and interfaces will depend on the nature of the device. It will be understood that such a user interface can be implemented in a mobile phone or cells, but is also applicable to other portable devices such as digital cameras, personal digital organizers, digital music players, GPS navigators, portable gaming consoles, and so on. In addition, it is also applicable to other devices that comprise a user interface, such as a personal computer or desktop computers. The user interface means may comprise the plurality of buttons, such as a numeric or alphanumeric keypad, or a touch scror the like. One or more storage devices may comprise a form of non-volatile memory, such as a delay card, so that the stored data is not lost if the power goes out. Storage media in ROM can be provided to store data that does not need updating or changes. Some RAM may be provided for temporary storage since faster response times support the placement in associated memory of the accessed data more frequently. The device can also accept removable memory cards by the user and optionally the hard disks can be handled as a storage medium. The storage medium used will be determined by balancing the different requirements of the device size, power consumption, the storage volume required, etc. Such a device can be implemented virtually in conjunction with any wireless communications network, for example, second generation digital mobile telephone networks (i.e., GSM, D-AMPS), so-called 2.5G networks (i.e., GPRS, HSCSD, EDGE) , third-generation WCDMA or CDMA-2000 networks and improvements to and derivatives of these networks and similar networks. Other technologies such as Bluetooth, IrDA or wireless LANs (whether based on radio systems or optical systems) can also be used within buildings or on university campuses. USB and / or FireWire connectivity can also be provided for data synchronization with other devices and / or for battery charging. Computer software to implement the methods and / or to configure a device as described above may be provided in data carriers such as floppy disks, CD-ROMs, DVDs, non-volatile memory cards, etc. This application claims the benefit of the Patent Application of the RU 0403709.9, filed on February 19, 2004, the content of which is incorporated herein by reference.

Claims (23)

NOVELTY OF THE INVENTION Having described the invention as antecedent, the content of the following claims is claimed as property:
1. CLAIMS 1. A method for displaying one or more menu items in a user interface, characterized in that the method comprises the steps for: (i) determining the number of menu items that can be displayed in the user interface; (ii) determining a set of menu items, from which one or more menu items may be selected for display at the user interface; (iii) selecting a certain number of elements for visualization, selecting the number of menu items according to the number determined in step (I) and selecting the • menu items from the set of menu items selected in step (ii); and (iv) display the number of menu items selected in step (iii) in the user interface.
2. 2. A method according to claim 1, characterized in that: step (iii) is repeated to update the number of menu items selected for display in response to a user input; and step (iv) is repeated later to display the updated number of menu items in the user interface.
3. 3. A method according to claim 2, characterized in that the user input comprises activating a user input means and the selection and display of an additional subset of elements of Ul causes scrolling through a list or menu. A method according to any of claims 1 to 3, characterized in that the menu items are stored in a single location and a marking language component is provided that defines the location of the menu items. A method according to claim 4, characterized in that the marking language component further defines the display of the selected menu items in a list. 6. A method according to claim 5, characterized in that a template is associated with the marking language component, the template determining the appearance of the selected menu items displayed in the list. A method according to any of claims 1 to 3 characterized in that the menu items are stored in a single file, a marking language component is provided that defines the location of the file and the file comprises one or more data resources for visualization in the user interface. A method according to claim 7, characterized in that the marking language component further defines the display of the selected menu items in a list. 9. A method according to claim 8, characterized in that a template is associated with the marking language component, the template determining the appearance of the selected menu items displayed in the list. A method according to any of claims 3 to 9, characterized in that the list of the selected menu items comprises one or more additional lists, each of the one or more additional lists being identified by a single expression. 11. A data carrier comprising computer executable code for executing the method according to any of claims 1 to 10. 12. A device comprising a screen and a user interface, the device being configured, in use, for (i) determine the number of menu items that can be displayed in the user interface; (ii) determining a set of menu items, from which one or more menu items may be selected for display at the user interface; (iii) selecting a certain number of elements for viewing, the number of menu items being selected according to the number determined in step (i) and selecting the menu items from the set of menu items selected in step ( ii); and (iv) display the number of menu items selected in step (iii) in the user infer. 13. A device according to the claim 12, characterized the device because it also comprises user input means and is configured, in use, to respond to a user input in order to: repeat step (iii) to update the number of menu items selected for display in response to a user input; and then repeat step (iv) to display the updated number of menu items in the user interface. A device according to claim 12 or claim 13, characterized in that the device responds to the activation of the user input means in such a way that the selection and display of additional menu items causes the displacement by a list or menu 15. A device according to any of claims 12 to 14 characterized the device because it further comprises storage means and the menu items are stored in a single location and a marking language component is provided that defines the location of the menu items. 16. A device according to claim 15, characterized in the marking language component because it additionally defines the display of the menu items in a list. 17. A device according to claim 16, characterized in that a template is associated with the marking language component, the template determining the appearance of the selected menu items displayed in the list. A device according to any of claims 12 to 14 characterized the device because it further comprises storage means and the menu items are stored in a single file where a marking language component is provided that defines the location of the file and the file it comprises one or more data resources for visualization in the user interface. 19. A device according to claim 18, characterized in that the marking language component further defines the screen of the selected menu items in a list. 20. A device according to claim 19, characterized in that a template is associated with the marking language component, determining the appearance template of the selected menu items displayed in the list. 21. A device according to any of claims 15 to 20, characterized in that the list of the selected menu items comprises one or more additional lists, each of the one or more additional lists being identified by a single expression. 22. A device according to any of claims 11 to 21, characterized in that the device comprises wireless communication means. 23. A device comprising processing means, storage means, a screen, user input means, wireless communication means and a user interface, characterized in the device because it is configured to execute the method according to any of claims 1 to 10.