+

WO2003067427A2 - Interface utilisateur graphique - Google Patents

Interface utilisateur graphique Download PDF

Info

Publication number
WO2003067427A2
WO2003067427A2 PCT/GB2003/000518 GB0300518W WO03067427A2 WO 2003067427 A2 WO2003067427 A2 WO 2003067427A2 GB 0300518 W GB0300518 W GB 0300518W WO 03067427 A2 WO03067427 A2 WO 03067427A2
Authority
WO
WIPO (PCT)
Prior art keywords
graphical user
user interface
procedures
gui
received
Prior art date
Application number
PCT/GB2003/000518
Other languages
English (en)
Other versions
WO2003067427A3 (fr
Inventor
Mark Adam Buckland
Krzysztof Zbigniew Dufrene
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by British Telecommunications Public Limited Company filed Critical British Telecommunications Public Limited Company
Publication of WO2003067427A2 publication Critical patent/WO2003067427A2/fr
Publication of WO2003067427A3 publication Critical patent/WO2003067427A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • the present invention relates to graphical user interfaces, and is suitable particularly, but not exclusively, for network-connected devices.
  • JavaTM Java 2 Platform, Micro Edition Solution
  • GUI Graphical User Interface
  • a configuration is comprised of a virtual machine, which, as is known by those skilled in the art, enables JavaTM applications to run on the device (for further details of Java virtual machine, and how it interoperates with a microprocessor running on a device, the reader is referred to "The JavaTM Virtual machine specification", Sun Microsystems Chapter 1 .2, Lindholm, T., Yellin, F. 1999.
  • a configuration is comprised of core libraries, classes and application programming interfaces (APIs). There are currently (January 2002) two configurations: the co-called Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC).
  • CLDC Connected Limited Device Configuration
  • CDC Connected Device Configuration
  • the former configuration type, CLDC is suitable for devices with constrained processing capabilities and memory resources
  • the latter configuration type, CDC is suitable for devices with more resources.
  • a profile is a specification that defines device specific application programming interfaces (APIs), such as device display features.
  • APIs application programming interfaces
  • FIG 1 shows two types of profile types: MIDP 101 and Personal 103.
  • MIDP 101 is a profile type that is suitable for wireless and mobile devices, and links into the CLDC 105 configuration
  • the Personal profile 103, together with the Foundation profile 106 is suitable for devices with more computational power, and co-operates with the CDC 107 configuration.
  • each configuration CLDC 105, CDC 107 interoperates with a Java virtual machine KVM 109, CVM 1 1 1 respectively.
  • JavaTM technology is moving away from the "Write Once, Run Anywhere" paradigm, and developers are once again forced to write different applications for different platforms.
  • apparatus for creating a Graphical User Interface for a device comprising a store arranged to store a plurality of processable procedures, each being associated with one or more device types; receiving means arranged to receive a device independent Graphical User Interface specification and data identifying the device; processing means arranged to process the received Graphical User Interface specification in accordance with the received identifying data, so as to identify, from the store, a plurality of procedures corresponding to the identified device; and combining means arranged to combine the identified procedures into a program for processing by the device, thereby creating the Graphical User Interface.
  • the device-independent graphical user interface specification identifies display requirements of a graphical user interface.
  • Embodiments of the invention identify a device type, and, depending on the device type, interpret the specification in accordance with device-dependent display capabilities. These device- dependent capabilities can be derived from software that has been written for a particular device.
  • At least some of the plurality of procedures are written in accordance with object-oriented programming, so that at least some procedures have, associated therewith, a class, which is associated with a device type.
  • the apparatus further includes means arranged to instantiate an object of the identified device type and to pass the instantiated object to the processing means, the processing means thereby having access to the procedures associated with the instantiated object.
  • the processing means is then arranged to receive a reference to procedures corresponding to items in the received Graphical User Interface specification
  • a reference to procedures corresponding to items in the received Graphical User Interface specification Preferably the GUI specification is written in the Extensible Mark-up Language
  • GUI User Interface Markup Language
  • GUIML User Interface Markup Language
  • GUIML User Interface Markup Language
  • the GUI specification could be written using a proprietary descriptive language having a bespoke standard for the encoding of items such as GUI widgets, symbols and layouts etc.
  • embodiments of the invention have access to a repository of functions for each device type, so that if, for example, the XML specification includes the text ⁇ display > , and the device type is identified as being a wireless device, an object corresponding to a wireless device is created and a function of that object, which has the capability of creating a display on a wireless device, is then invoked.
  • the processable procedures include procedures for processing one or more events in accordance with user input received via the application program.
  • the apparatus includes means to select one or more of the said procedures for processing one or more events on the device in accordance with items in the Graphical User Interface specification.
  • the apparatus can either be run on a server apparatus, in which case the Graphical User Interface, once created, is transmitted to a device for which it is intended. Alternatively the apparatus can be run directly on the device itself.
  • the library functions provided by "Abstract FactoryTM” can be used to invoke display components as a function of device type (described by Gamma, E., Helm, R., Johnson, R., and Vlissides, J. in “Design Patterns: Elements of Reusable Object- Oriented Software", Addison-Wesley, Reading, MA, at pp. 87 - 95).
  • These library functions are written in accordance with the object-oriented programming paradigm, and provide polymorphism of objects.
  • Polymorphism is a concept whereby the functionality of an object is defined by its run-time type. Polymorphism is implemented via an interface comprising one base class that contains all methods common to different behaviours. The common methods are defined, in the base class, as being virtual. The different behaviour is provided by different child classes (derived from the base class, also known as a sub-class), which implement the methods that were defined as virtual in the base class.
  • An array can then be created, whose elements are declared as instances of the base class; at run-time (i.e. when the elements are instantiated), any sub-class of the known base class can replace an element of the array, thereby dynamically defining the behaviour of the object.
  • base class Figure having one or more virtual methods therein, which are declared as "abstract".
  • base class Figure includes virtual method Draw.
  • Abstract methods exist only to provide a gateway to multiple different forms of a method, and are thus designed to be overridden by a child class.
  • the Figure class does not include an implementation of the Draw method (In C + + , the Draw method is called pure virtual member function, in Java the Draw method is simply called an abstract method).
  • child classes Square and
  • Polygon class ( Figure) private a: integer; // Length of the side, end;
  • the Abstract FactoryTM libraries include abstract base classes and child classes that provide polymorphism.
  • an application A e.g. an application called "GUI creation”
  • an interface 201 which is representative of a virtual method within a base class, and which can be passed as a parameter to the Application A.
  • application A is run, the interface 201 is cast to whichever object corresponds to the client type, and sent as a parameter to the application A.
  • GUI creation an application
  • An Open Source product called "Abstract User Interface Toolkit” also makes use of the Abstract Factory design approach.
  • GUI requests are written in an XML specification, and the client translates the specification in order to identify the object to be requested.
  • Display components corresponding to the identified object are passed to the display application via the Interface 201 as described above.
  • This Open Source product has been written for "real" windows (in this case Motif, Macintosh OS X and Win32) that run on a single device (conventional PCs). Each window type relates to a different operating system (Unix, Mac and Windows respectively) and has a separate XML specification corresponding thereto.
  • a single GUI specification is written and this can be used for any device type.
  • the "Abstract User Interface Toolkit” is designed for conventional desktop machines, where the actual windowing functionality is identical, but the means of invoking the functionality is not.
  • embodiments of the invention are concerned with devices where the graphical interface functionality varies considerably between device types: cell phones and pagers, for example, have small screens, limited battery life and low memory resources; whereas entertainment environments offer high speed connectivity to a network and have around 1 6 MB memory.
  • J2METM application environment with which embodiments of the invention interoperate
  • Figure 2 is a schematic representation of "Abstract FactoryTM” design utilised by embodiments of the invention
  • Figure 3 is a schematic representation of the environment in which embodiments of the invention operate;
  • FIG. 4 is a schematic representation of an embodiment of the invention generally referred to as GUI engine
  • Figure 5 is a flow diagram showing steps involved in a first embodiment of the invention.
  • Figure 6 is a schematic representation of an object created by the parsing program forming part of the GUI engine shown in Figure 4;
  • Figure 7 is a schematic representation of the functionality of the interface forming part of the GUI engine of Figure 4;
  • Figure 8 is a flow diagram showing steps involved in processing the object shown in
  • Figures 9a and 9b are illustrations of a GUI created by the GUI engine shown in
  • Figure 10 is a schematic representation of processing of an event listening program.
  • an embodiment of the invention runs on a server computer 301 , which is in communication with a range of devices 303a 303b, 303c via a public land mobile network (PLMN) (e.g. a GSM - compatible digital cellular network) N1 or, if the devices 303a, 303b, 303c are equipped with Wireless Ethernet network (WLAN) technology, via a 802.1 1 -compatible Wireless Ethernet network (WLAN) N2 (or any other short range network).
  • PLMN public land mobile network
  • WLAN Wireless Ethernet network
  • WLAN Wireless Ethernet network
  • the devices 303a, 303b, 303c could communicate with the server 301 via GPRS and/or UMTS, which are mobile networks capable of sending and receiving packet switched data.
  • the PLMN network N1 can be connected via a gateway G1 to a public switched network (PSTN) N3.
  • PSTN public switched network
  • Figure 3 shows 3 device types only, but many more are possible.
  • the PSTN N3 is interconnected with an integrated services digital network (ISDN) N4 via a gateway G2 (e.g. a local or international switching centre), and is connected via an ISDN line L1 to the server computer 301 , and to local area network (LAN) N5.
  • ISDN integrated services digital network
  • LAN local area network
  • One or more database servers 01 are accessible by the server computer 301 via the local area network N5.
  • the ISDN network N4 is connected to the WWW via line L2.
  • Information sources held for example on servers IS1 -IS4, are distributed throughout the networks N1 -N6. Only four servers are shown, however other distributions are envisaged. A user operating a smart phone device 303a may wish to receive information from any or all the information sources in the system.
  • an embodiment of the invention provides a means of specifying the requirements of a GUI in a single specification, which includes generic descriptions of GUI elements and can be interpreted in respect of any type of device.
  • the embodiment has access to device-specific GUI items, so that, once the device type and a generic GUI element has been identified, the device specific GUI item corresponding thereto is readily identifiable.
  • the specification is written as an XML file, which means that it can be stored on a centralised server, and is thus accessible by well-known web server access techniques.
  • the specification is processed, and GUI created, from the server computer 301 , which then sends the created GUI to an appropriate device for display thereon.
  • a particular feature of the invention is that, because a single GUI specification is used, the same information and menu options will be available on all devices used by a user (albeit arranged differently). It is well recognised that humans prefer to use devices with which they feel familiar, because it means that information is delivered and/or accessed to and/or by a user in a manner with which they are accustomed. Thus this conformance of GUI components across devices is thus a significant advantage.
  • the server computer 301 comprises a central processing unit (CPU) 401 , a memory unit 403, an input/output device 405 for connecting the server computer to the devices 303a, 303b, 303c and to the database 01 ; storage 407, and a suite of operating system programs 409, which control and co-ordinate low level operation of the server computer 301 .
  • a GUI engine 400 comprises at least some of programs 41 1 , 413, 41 5, 41 7. These programs, which are described in more detail below, are stored on storage 407 and are processable by the CPU 401 .
  • the GUI engine 400 also includes, or has access to, a database 01 , which stores methods corresponding to device types. It is understood that each of the programs 41 1 , 41 3, 41 5, 41 7 could comprise a suite a computer programs, and is preferably written in an object-oriented programming language, such as JavaTM.
  • the programs include a program 41 1 for detecting a type of device for which the GUI is intended, a program 413 for requesting and/or receiving a specification of the GUI requirements, a program 41 5 for parsing the specification, and a program 417 for processing the parsed specification so as to create a GUI comprising features that are appropriate to the detected device type.
  • a program 41 1 for detecting a type of device for which the GUI is intended a program 413 for requesting and/or receiving a specification of the GUI requirements
  • a program 41 5 for parsing the specification
  • a program 417 for processing the parsed specification so as to create a GUI comprising features that are appropriate to the detected device type.
  • the programs 41 1 , 41 3, 41 5, 41 7 make use of, and extend, library functions supplied by Abstract FactoryTM described above.
  • GUI requirements can be written using the Extensible Mark-up Language (XML).
  • XML Extensible Mark-up Language
  • This specification is device-independent, so that, for a particular GUI format, a single specification applies for all of the devices 303a, 303b, 303c.
  • the processing program 417 processes the specification, the methods and features of the created object are automatically run and retrieved, thereby creating a GUI that has been customised for the detected device type.
  • Figure 5 is a flow diagram showing steps carried out by the GUI engine 400 when creating a GUI for a smart phone 303a
  • Figure 6 is a schematic representation of a device-independent GUI specification
  • Figure 7 is a schematic block diagram showing device-dependent objects and methods thereof that are stored in the database 01 and accessed by the processing program 41 7.
  • the complete lines with arrows indicate process steps, and the dash-dotted lines indicate access relationships.
  • Figure 8 is a flow diagram showing steps carried out by the processing program 41 7.
  • the GUI engine 400 receives 501 a request for a GUI from the smart phone 303a, and sends this request to the detecting program 41 1 , which is activated to identify the type of device that has sent the request.
  • the GUIs are created using JavaTM, they are run on a Java virtual machine running on the device 303a.
  • the type of Java virtual machine will vary from device to device, depending on the configuration 105, 107 running thereon, so identifying the type of Java virtual machine provides a means of detecting the type of device.
  • the detecting program 41 1 sends a request for the type of virtual machine running on the device 303a.
  • RMI Remote Method Invocation
  • J2SE To check if the device is running J2SE the detecting program 41 1 asks if the system property j ava . runtime . name contains the value Java (TM) 2 Runtime Environment. If the string is anything else or null then the platform is not J2SE. Examples of devices that run J2SE are laptops and desktop PCs. e.g. public static final boolean isJ2SE;
  • the detecting program 41 1 asks if the system property os . name contains the value indows CE .
  • the platform will be pJava (pJava devices include the iPAQ (high- spec PDA)) . If the string is anything else or null then the platform is not pJava.
  • the detecting program 41 1 By invoking a series of getProperty O messages the detecting program 41 1 identifies 505 which platform, and thus which type of device, has sent the request message.
  • the detecting program 41 1 then creates 507 an object OD (not shown) of this identified device type (equivalent to square . create in the example given in the introduction section).
  • Each device object has methods and variables corresponding thereto, so that, by creating an object of the detected device type, these associated methods and variables can thereafter be invoked.
  • the GUI engine 400 then activates the receiving program 41 3 to retrieve a specification of the GUI requirements.
  • the specification When the specification is written in XML, it can be accessed from a web server, via a Uniform Resource Locator (URL) submitted with the request sent at step 501 .
  • the request (step 501 ) does not include a URL, or some indication of an access point for the specification, the receiving program 41 3 can access a default GUI specification (or a default URL) from the GUI engine 400. Accordingly, assuming a URL is submitted together with the request at step 501 , the receiving program 413 sends 509 a request for an XML file to a web server at the submitted URL, and receives 51 1 an XML specification therefrom.
  • URL Uniform Resource Locator
  • the parsing program 41 5 is then activated to parse the XML specification.
  • the parsing program 41 5 creates and stores 513 the specification as an XML object 600 comprising a series of nodes, each of which corresponds to a tag in the XML specification, and is readily processable by the processing program 41 7.
  • An overview of XML and tags is given on pages 2 - 5 of McLaughlin, B., Java and XML, O'Rielly, 2000. (ISBN 0-596-0001 6-2), and an overview of parsing of XML is given on page 23, and 46-57.
  • the XML object 600 created at step 513 is then processed, step 51 5, by the processing program 41 7. This involves processing each node of the XML object 600, as described in detail with respect to Figure 8 below.
  • the GUI engine 400 has an interface 701 , which is arranged to receive a device-independent request for some aspect of a GUI from the processing program 41 7, and, depending on the object OD created at step 507, the interface 701 will refer to a device-dependent method relating to the request.
  • These methods can be stored in the database 01 and are automatically accessible by the object when it is created at step 507.
  • Figure 7 illustrates the functionality of the interface 701 for the first node ⁇ display > of the example XML specification given above.
  • the processing program 41 7 sends S 7.1 a request for a "display" to interface 701 .
  • the processing program 41 7 Prior to sending the request at step S 7.1 , the processing program 41 7 has to identify which generic GUI element to request.
  • this can involve accessing a Hashtable data structure, which stores relationships between XML tags and generic GUI elements.
  • a generic GUI element corresponding to an XML tag ⁇ name > can be identified by invoking a method to retrieve a node corresponding to ⁇ name > from the Hashtable, in accordance, for example, with the following psuedo-code:
  • Steps S 7.1 and S 7.2 are repeated for each node in a depth first with back tracking manner (i.e. top to bottom, left to right - that is, the first route through the XML object 600 is the left-most nodes, and when a leaf node is encountered, the route is back tracked until an adjacent right hand node is encountered whereupon the route burrows down this adjacent node until a next leaf node is encountered. This process is repeated for all nodes in the XML object 600). Tree structures (such as is shown in Figure 6) and depth first traversal are described in Budd, T.
  • the processing program 41 7 reads in 801 the first node in the XML object 600 and checks 803 whether the node is of "display" type. If it is (as it is in the current example), the processing program 417 sends S 7.1 a request for a "display" (via the interface method createDisplay ( ) ) to object OD (which sub- classes interface 701 ) created at step 507, and returns S 7.2 the reference back to the processing program 41 7, which stores 805 this as a reference to a new display area.
  • the processing program 41 7 then reads in 807 the left-most node 603 and repeats step 803 in respect thereof, moving onto step 809 because the next node is not a "display" node.
  • the processing program 417 checks whether the node is of "panel" type. As in this example it is, the processing program 417 sends S 7.1 a request for a "panel" (via the interface method createPanel 0 ) to object OD created at step 507, and returns S 7.2 the reference back to the processing program 41 7. This means that, at runtime, the specific implementation of the createPanelO method corresponding to object OD will be invoked.
  • the processing program 417 then adds 81 1 the reference to the panel to the reference stored at step 805.
  • the processing program 41 7 then checks 81 3 whether this panel is the first panel node encountered in the XML object 600, and if it is, it sets 81 5 this panel as the root display element. If this panel is not the first panel node, step 815 is omitted, and the processing program 417 skips to step 817, where the processing program 417 reads in 81 7 the left-most node 605 and repeats steps 803, 809 in respect thereof.
  • this node is neither a "display” nor a "panel” node, so the processing program 41 7 omits steps 803, 809, and extracts 819 whatever information pertains to the node (for node 605 there is no additional information to be extracted). Steps 81 9 - 823 are best illustrated for the case of node 633.
  • the processing program 41 7 When the processing program 41 7 reaches node 633, it sends a request for a "choice group" (via the interface method createChoiceGroup ( ) ) to object OD created at step 507, and returns S 7.2 the reference back to the processing program 41 7.
  • the processing program 41 7 then adds 823 the reference to the panel set as root display element at step 81 5.
  • processing program 41 7 Whenever the processing program 41 7 comes across a terminal branch node (e.g. nodes 605, 607a, 609a) it backtracks 880 through the XML object 600 to identify a next untested node (e.g. having reached node 605, the processing program 41 7 backtracks to node 603).
  • a terminal branch node e.g. nodes 605, 607a, 609a
  • the processing program 41 7 backtracks 880 through the XML object 600 to identify a next untested node (e.g. having reached node 605, the processing program 41 7 backtracks to node 603).
  • the processing program 41 7 can be said to have created a bespoke GUI class, and, at step 51 7, the class is sent to the requesting device (here smart phone 303a) as byte code.
  • the client C which is running on the device 303a and is in operative association with a Java Virtual Machine, then reads in the byte-code and converts it into a class. Thereafter the client C instantiates a new instance of the class - namely a GUI object - essentially displaying 519 the GUI on the device 303a.
  • Figures 9a and 9b each show a GUI that has been created from the same XML specification, for a smart phone and a PDA respectively.
  • the two interfaces show identical information: referring to Figure 9a menu options Xmllnfo 901 , Alert 903, TxtBox 905 TextArea 907 correspond to Xmllnfo 91 1 , Alert 913, TxtBox 91 5 TextBox 91 7 on Figure 9b.
  • one or more server computers 301 receive requests for GUIs from devices.
  • each device 303a, 303b, 303c has a GUI engine 400 running thereon, so that a request for a GUI is processed locally on the device itself.
  • event listening programs listen for inputs (e.g. user input via a keyboard, or via a keypad) and have procedures that respond, with predefined actions, to received inputs.
  • event listening code 1001 typically corresponds to items in the GUI specification; for each GUI specification, the developer only needs to write one version of event-listening code, which can thereafter be sent to any device.
  • the event listening code 1001 can be stored on the server computer 301 (e.g. as a library class).
  • the event listening code 1001 is written in the JavaTM programming language, it is compiled, on the server computer 301 , into byte-code, sent to the device 303a, and received by a program 1003 running on the device 303a.
  • the client C running on the device 303a is in operative association with a Java Virtual Machine, which is arranged to interpret the byte-code of the program 1001 (once translated it into a class file).
  • the client C firstly instantiates an object of the device (it can reuse the device object DO created at step 507). Once the JVM has interpreted the received byte- code into an event listening class, the client C instantiates the said class, thereby realising references to certain event listening methods (in the example above, menuListenerO and getMenuCommandO) via the interface 701 . This essentially involves requesting a reference of a menuListener, or getMenuCommand etc. function of the object DO (i.e. calling "OD. menuListener").
  • the client C can then invoke the method(s) using the reference(s) that is/are received from the interface 701 at run-time.
  • a reference to the method menuListenerO for this device type effectively activates method ActionListener ( ) at run-time .
  • menuListener O is then coupled to components of the GUI, thereby "attaching" the event listeners to the GUI (referring to the code fragment below): // add menulistener to the application's menu try ⁇ factory. setMenuListener (components .get ("Menu”) , menulistener) ; ⁇ catch (Exception e) ⁇ e . printStackTrace ( )
  • an interface 701 essentially provides a means of implementing mappings between generic GUI elements and device specific GUI items (returning to Figure 7, "Display” is a description of a generic GUI element, and "MIDIet display” is a GUI display item specific to the smart phone 303a).
  • the actual implementation of the mappings is via polymorphism, as each type of device is represented by a sub-class, each of which conform to methods corresponding to their base class, interface 701 .
  • the mappings are implemented as a look-up table between generic description and a specific item; this is described in more detail later.
  • each specific GUI item involves one or more classes and methods.
  • identifying GUI items for some generic GUI elements is non-trivial, not least because the GUI architecture for different JavaTM platforms can vary considerably in terms of the relationships between GUI items, the hierarchy of GUI items and the inadequate, and in some instances excessive, equivalencies of GUI objects between platforms.
  • GUI items for MIDP and pJava devices corresponding to generic GUI descriptions. At least some of the items involve bespoke classes and methods (indicated by "bespoke"), while others are provided by the API corresponding to the device (indicated by "API class”). This list is not exhaustive.
  • the hashtable (or series of switch statements) described above requires updating, so that, when the graphical user interface specification is processed, the processing program 41 7 can identify which request to send at step S
  • polymorphism is not used. This means that the classes and methods are explicitly written for each device type, and an object of each type of device has to be explicitly instantiated when creating the GUI (i.e. no instantiation of object at run-time). Accordingly at some point prior to step 801 , the processing program 41 7 receives an identifier representative of the said device type and, when processing the XML object 600, it directly invokes classes and methods relating thereto so as to add a specific component to a specific display that relates to that specific platform of the device type.
  • the following pseudo-java code illustrates how this embodiment could operate:
  • ProcessXMLf orPj ava is defined as: void ProcessXMLforPjava (PjavaDisplayObject pJavaDisplay) ⁇
  • ProcessXMLf orMiDP is defined as: void ProcessXMLforMIDP (MIDPDisplayObject midpDisplay) ⁇
  • a fourth embodiment similarly does not use polymorphism (interface 701 ). Instead, the mapping between generic GUI description and specific GUI item is provided by a simple lookup table of the following form:
  • the processing program 417 then operates as follows: void ProcessXMLforMIDP(MIDPD ⁇ splay ⁇ b 3 ect midpDisplay) ⁇
  • the programs 41 1 - 41 7 are preferably written using JavaTM, which means that the programs only need to be written once, whereupon they will work on any device having a Java Virtual Machine running.
  • the programs could be written using C + + or C# (C-sharp), whereupon they would have to be compiled for each device type (or more specifically, for each operating system type/processor type combination).
  • the programs could be written using an interpreted language like Visual BasicTM, but the GUI created therewith could only be run on devices running MicrosoftTM operating systems, and would have to be compiled specifically for other operating systems. If the programs were written using the C + programming language, the functionality of the interface 701 would be provided by a so-called virtual base class and pure virtual member functions (mentioned in the introduction).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

L'invention concerne les exigences en constante évolution relatives aux interfaces utilisateurs graphiques. L'éventail de dispositifs mobiles et la vitesse à laquelle le contenu informationnel auxquels ils permettent d'accéder ne cessent d'augmenter. Un des inconvénients que présente un si large éventail de dispositifs est qu'il existe un éventail correspondant de configurations et de possibilités et que, de manière générale, chaque dispositif requiert une interface utilisateur graphique (GUI) différente. Les entreprises développant des produits pour un tel éventail de dispositifs peuvent être confrontées à une infrastructure et à des exigences d'interface de programmation extrêmement disparates ainsi qu'à un temps de développement significatif. L'invention a pour objet d'atténuer ces problèmes. A cet effet, un mode de réalisation de l'invention comprend un moyen servant à spécifier les exigences d'une GUI dans une spécification unique comportant des descriptions génériques d'éléments GUI et pouvant être interprétée pour n'importe quel type de dispositif. Ce mode de réalisation comprend un accès à des articles GUI spécifiques aux dispositifs, de façon que, une fois que le type de dispositif et un article GUI générique ont été identifiés, l'article GUI spécifique du dispositif correspondant soit facilement identifiable. De préférence, cette spécification se présente sous la forme d'un fichier XML, ce qui signifie qu'il peut être stocké sur un serveur centralisé et qu'il est accessible au moyen de techniques d'accès à des serveurs Web bien connues. Dans un mode de réalisation, cette spécification est traitée, une GUI est créée, à partir de l'ordinateur serveur (301), qui envoie ensuite la GUI créée vers un dispositif approprié destiné à l'afficher.
PCT/GB2003/000518 2002-02-07 2003-02-04 Interface utilisateur graphique WO2003067427A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP02250817.0 2002-02-07
EP02250817 2002-02-07

Publications (2)

Publication Number Publication Date
WO2003067427A2 true WO2003067427A2 (fr) 2003-08-14
WO2003067427A3 WO2003067427A3 (fr) 2004-08-26

Family

ID=27675742

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2003/000518 WO2003067427A2 (fr) 2002-02-07 2003-02-04 Interface utilisateur graphique

Country Status (1)

Country Link
WO (1) WO2003067427A2 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005081130A1 (fr) * 2004-02-19 2005-09-01 Qualcomm Cambridge Limited Dispositif et procede de fonctionnement
WO2005073847A3 (fr) * 2004-01-30 2005-11-03 Id Business Solutions Ltd Systeme pour creer et afficher des formulaires dans une interface graphique
GB2420477A (en) * 2004-11-23 2006-05-24 Ibm Enhancing the display output of portable devices
WO2007083210A3 (fr) * 2006-01-23 2007-10-18 Nokia Corp Solution de bout en bout pour permettre à un utilisateur final d'obtenir une information dans des interfaces d'utilisateur
WO2007136397A1 (fr) * 2006-05-19 2007-11-29 Nokia Siemens Networks Gmbh & Co.Kg Système et procédé d'auto-adaptation d'une interface utilisateur en fonction de capacités matérielles
EP2000907A3 (fr) * 2007-06-09 2009-08-05 weComm Ltd Fourniture d'applications à des dispositifs mobiles
EP2355486A1 (fr) * 2010-02-02 2011-08-10 Ricoh Company, Ltd. Procédés et systèmes d'impression de réseau avec des paramètres sélectionnables par l'utilisateur
CN102520935A (zh) * 2011-11-29 2012-06-27 曙光信息产业(北京)有限公司 一种用于快速开发用户界面的方法
EP2634695A1 (fr) * 2012-02-29 2013-09-04 Sap Ag Procédé informatique, système informatique et support lisible sur ordinateur
US8856365B2 (en) 2012-02-28 2014-10-07 Sap Ag Computer-implemented method, computer system and computer readable medium
CN106663006A (zh) * 2014-07-03 2017-05-10 阿贝尔环球国际有限公司 控管电子装置的方法以及应用该方法的控制系统
US9977660B2 (en) 2014-07-03 2018-05-22 Able World International Limited Method of controlling and managing electronic device and control system using same
CN115098083A (zh) * 2022-08-26 2022-09-23 广州市保伦电子有限公司 一种图形视图框架的扩展方法、装置、设备及存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6065041A (en) * 1997-09-18 2000-05-16 Electronics For Imaging, Inc. Interface code architecture
US6054983A (en) * 1997-09-30 2000-04-25 The United States Of America As Represented By The Secretary Of The Navy Methods for operating a universal client device permitting interoperation between any two computers
US6778992B1 (en) * 1999-12-21 2004-08-17 Lockstream Corporation Flexible and hierarchical user interfaces defined using a data definition language

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005073847A3 (fr) * 2004-01-30 2005-11-03 Id Business Solutions Ltd Systeme pour creer et afficher des formulaires dans une interface graphique
GB2424094A (en) * 2004-01-30 2006-09-13 Id Business Solutions Ltd System for creating and displaying forms in a graphical user interface
WO2005081130A1 (fr) * 2004-02-19 2005-09-01 Qualcomm Cambridge Limited Dispositif et procede de fonctionnement
WO2005081131A1 (fr) * 2004-02-19 2005-09-01 Qualcomm Cambridge Limited Rendu sur une interface utilisateur
US9454619B2 (en) 2004-02-19 2016-09-27 Qualcomm Incorporated Layered user interface
US8434016B2 (en) 2004-02-19 2013-04-30 Qualcomm Incorporated Virtual file system
US8327289B2 (en) 2004-02-19 2012-12-04 Qualcomm Incorporated Layered user interface
GB2420477B (en) * 2004-11-23 2009-01-07 Ibm Apparatus and method for enhancing the capability of the display output of portable devices
GB2420477A (en) * 2004-11-23 2006-05-24 Ibm Enhancing the display output of portable devices
WO2007083210A3 (fr) * 2006-01-23 2007-10-18 Nokia Corp Solution de bout en bout pour permettre à un utilisateur final d'obtenir une information dans des interfaces d'utilisateur
RU2408923C2 (ru) * 2006-01-23 2011-01-10 Нокиа Корпорейшн Способ и система для конфигурирования интерфейса пользователя
US10146513B2 (en) 2006-01-23 2018-12-04 Nokia Technologies Oy End-to-end solution for an end-user to obtain desired information in user interfaces
WO2007136397A1 (fr) * 2006-05-19 2007-11-29 Nokia Siemens Networks Gmbh & Co.Kg Système et procédé d'auto-adaptation d'une interface utilisateur en fonction de capacités matérielles
US20190173732A1 (en) * 2007-06-09 2019-06-06 Open Text Sa Ulc Supplying applications to mobile devices
US10250432B2 (en) 2007-06-09 2019-04-02 Open Text Sa Ulc Supplying applications to mobile devices
US11252008B2 (en) 2007-06-09 2022-02-15 Open Text Sa Ulc Supplying applications to mobile devices
US8671147B2 (en) 2007-06-09 2014-03-11 Open Text S.A. Supplying applications to mobile devices
US10749730B2 (en) 2007-06-09 2020-08-18 Open Text Sa Ulc Supplying applications to mobile devices
EP2000907A3 (fr) * 2007-06-09 2009-08-05 weComm Ltd Fourniture d'applications à des dispositifs mobiles
GB2449944B (en) * 2007-06-09 2012-08-08 Wecomm Ltd Supplying applications to mobile devices
US8643856B2 (en) 2010-02-02 2014-02-04 Ricoh Company, Ltd. Methods and systems for network printing with user selectable settings
EP2355486A1 (fr) * 2010-02-02 2011-08-10 Ricoh Company, Ltd. Procédés et systèmes d'impression de réseau avec des paramètres sélectionnables par l'utilisateur
CN102520935A (zh) * 2011-11-29 2012-06-27 曙光信息产业(北京)有限公司 一种用于快速开发用户界面的方法
US8856365B2 (en) 2012-02-28 2014-10-07 Sap Ag Computer-implemented method, computer system and computer readable medium
EP2634695A1 (fr) * 2012-02-29 2013-09-04 Sap Ag Procédé informatique, système informatique et support lisible sur ordinateur
US9977660B2 (en) 2014-07-03 2018-05-22 Able World International Limited Method of controlling and managing electronic device and control system using same
CN106663006A (zh) * 2014-07-03 2017-05-10 阿贝尔环球国际有限公司 控管电子装置的方法以及应用该方法的控制系统
CN106663006B (zh) * 2014-07-03 2020-02-28 阿贝尔环球国际有限公司 控管电子装置的方法以及应用该方法的控制系统
EP3164797A4 (fr) * 2014-07-03 2017-07-12 Able World International Limited Procédé de commande et de gestion de dispositif électronique et système de commande utilisant ce dernier
CN115098083A (zh) * 2022-08-26 2022-09-23 广州市保伦电子有限公司 一种图形视图框架的扩展方法、装置、设备及存储介质
CN115098083B (zh) * 2022-08-26 2022-11-22 广州市保伦电子有限公司 一种图形视图框架的扩展方法、装置、设备及存储介质

Also Published As

Publication number Publication date
WO2003067427A3 (fr) 2004-08-26

Similar Documents

Publication Publication Date Title
US7471947B1 (en) Method and system for accessing a universal message handler on a mobile device
US7469140B1 (en) Method and system for push launching applications with context on a mobile device
US7941450B2 (en) Software, devices and methods facilitating execution of server-side applications at mobile devices
US7865528B2 (en) Software, devices and methods facilitating execution of server-side applications at mobile devices
US7636722B2 (en) System and method for describing application extensions in XML
CA2300240C (fr) Ressources de chargement transparent a partir d'une memoire morte pour un programme d'application
US6542908B1 (en) Technique for automatically and transparently transforming software components into software components capable of execution in a client/server computing environment
US8402432B2 (en) System and method of creating and communicating with component based wireless applications
JP4995367B2 (ja) 小フットプリント・デバイス・アプリケーション用の高性能ブックマーク
US20030184584A1 (en) User interface framework for integrating user interface elements of independent software components
WO2002015002A2 (fr) Systeme et procede pour construire des applications qui s'adaptent a des normes multiples de dispositifs et de protocoles
JP2002540536A (ja) コンピュータシステム用分散型オブジェクト
US20050076344A1 (en) System and method for extending capabilities and execution efficiency of script based applications
WO2003067427A2 (fr) Interface utilisateur graphique
US7437149B1 (en) Method and system for exchanging data between portable applications for mobile devices
US20070078925A1 (en) Porting an interface defining document between mobile device platforms
US8438577B2 (en) Method and system for extending scripting languages
US7533114B2 (en) Mobile device having extensible software for presenting server-side applications, software and methods
US20050197157A1 (en) System enabling easy application development on mobile devices
EP1743232B1 (fr) Architecture de commande d'interface utilisateur generique
US7831905B1 (en) Method and system for creating and providing web-based documents to information devices
CA2543910C (fr) Methode et systeme permettant d'augmenter les possibilites des langages de script
US20050256899A1 (en) System and method for representing hierarchical data structures
US20060123026A1 (en) Client server conversion for representing hierarchical data structures
Ławniczek et al. Grid infrastructure monitoring service framework Jiro/JMX based implementation

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CA JP US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载