WO2007066057A1

WO2007066057A1 - Display of information on the display screen of a computing device

Info

Publication number: WO2007066057A1
Application number: PCT/GB2005/003869
Authority: WO
Inventors: Matthias Reik
Original assignee: Uiq Technology Ab
Priority date: 2004-10-05
Filing date: 2005-10-05
Publication date: 2007-06-14
Also published as: GB0520270D0; GB2419074A; EP1825359A1; JP2008516359A; GB0422088D0; CN101044453A

Abstract

The text that an application places on the screen of a computing device is decided upon at the point of display by the operating system (OS) controlling the device rather than when the application is built or installed. The application passes a string ID to the operating system, to which a number of possibles a candidate strings, is attached. The (OS) then decides at the point of execution which of the possible candidates should be displayed, taking into account a number of possible display variables, such as the language in use, the available space on the screen, the device configuration and so on.

Description

Display of Information on the Display Screen of a

Computing Device

This invention relates to a method for displaying information on a display screen of a computing device, and in particular to the method used by an interactive computing devices to place appropriate textual messages in specific areas on the display screen.

The term 'interactive computing device' should be construed to include any device which includes both a screen or other method for displaying information and also a keyboard, keypad, button array, touchscreen or some other method for input such as selecting information; today this includes personal devices such as desktop computer, laptop computers, PDAs, Mobile Telephones, Smartphones, Digital Camera, Digital Music Players as well as many other industrial and domestic devices ranging from ATMs to domestic electrical apparatus (such as washing machines and televisions) to transport mechanisms including such devices, such as motor vehicles (of all forms), trains, boats and planes.

The development of inexpensive Visual Display Units (VDU) in the 1970s enabled the growth of true interactive computing, whereby a single unit incorporated a keyboard and screen providing real-time input and output functionality. Interactive computing requires a user interface by means of which a computing device displays information and prompts the user for input, which is validated and acted upon. While modern screens capable of handling high-resolution graphics have increased the use of visual images (such as icons), it is still the case that much information is displayed in textual form.

However, the inclusion of textual prompts has always presented particular problems for programmers who write code for user interfaces. One main reason for this has always been that text is location and therefore language dependent: internationalizing a programme, in order that it can be used by people in different countries, generally requires changes to the text included with the user interface but not to the program itself.

The traditional means by which programmers have sought to cope with the problem of location dependence has been by removing location dependent information, including the text strings which define the textual prompts, from the main body of the code and keeping it instead in a separate module (most commonly in a resource file), from which it can be retrieved as needed via some type of indexed look-up mechanism.

One of the earliest documented implementations is to be found in the Digital Research GEM Operating System. The 1985 GEM Programmer's Guide states:

"The purpose of a resource file is to isolate an application's device-, user-, and country-specific data from its code. This isolation provides the following advantages:

* e machine-code portability

To port the application across different environments, the programmer need only change the resource file data.

* customization of appearance

A non-programmer can change the application's menu structure, the layout of dialog boxes, and error message text. In most cases the programmer need not be involved.

* internationalization of text messages

To change text messages from one language to another, one need only change the text in the resource file.

* device-independent raster graphics Because they are stored as resources, GEM AES's icons and other bitmapped images can be tailored to the resolution characteristics of various displays. In all these instances the application's code is unchanged."

To summarize, the advantage of the above method of handling text strings is that internationalization of the software for different languages requires no change to the program or application itself; a suitably customized resource file would be all that is required. Most operating systems are able to adjust screen controls (such as dialogue boxes and menus) at run time to take account of differing text string lengths. However, the standard solutions described above for localization and display customization prove less than satisfactory when applied to resource constrained computing devices with small screens, such as mobile telephones.

The fundamental problem with such devices is that the area of the screen is too small to allow sufficient flexibility in the size of dialogue boxes and menus which can be displayed. Text strings that fit in one dialog box on the screen will not fit in another dialog box without being truncated.

Ul designers have in the past attempted to ensure that each text string fits perfectly in the required locations of the user interface by defining a separate text string for each place where the text string might be used.

However, this 'static' technique relies on the assumption that the designer is fully aware of all the possible screen parameters. For advanced devices running operating systems which are not only agnostic about screen size but which also allow for dynamic alteration and reconfiguration of the screen by the user, such a static approach is impractical. It is not economic, as it would make localization too expensive, and it would waste too much memory on these resource constrained devices in catering for configurations that might never or at best only occasionally be used. The GEM art quoted above also hints at another reason (shared with icons and other graphical information) as to why the inclusion of textual information in a user interface may give rise to problems. This is because of differences in display characteristics: the precise form of the text used depends not merely on what needs to be conveyed to the user, but also depends on items such as screen size and display resolution. Such differences in displays most commonly exist only between devices. Where problems do arise, they have generally been accommodated either by configuring the software at software build time or upon software installation. However, it should be noted that many modern desktop computing devices find it unnecessary to make special provisions in this area, because they can assume standard screen resolutions such as 640x480 or 1024x768 pixels, which are relatively large and permit the use of run-time techniques (such as scroll bars) where text does not fit into an appropriate space. Clearly, such methods are inappropriate for devices with small screen displays such as mobile phones.

Therefore, it is an object of the present invention to provide an improved way of displaying information on the display screen of a computing device.

According to a first aspect of the present invention there is provided According to a second aspect of the present invention there is provided According to a third aspect of the present invention there is provided

Embodiments of the present invention will now be described, by way of further example only.

The perception underlying this invention is that instead of configuring different strings for each possible device at build time, the differentiation is made in runtime. In this invention, the same unique text string identifier (or string ID) is used each time it is required to offer the same respective message to a user of the device, but without consideration of the usable size of the display. Each of these string IDs has one or more text strings attached to it, and these text strings are arranged such they take account of most, and preferably all possible screen sizes and usage instances envisaged for the device. These text strings may, for example, be stored in a database within a memory of the device. This is relatively easy to achieve because, as stated above, the text strings, which define the textual prompts, are maintained separate from the main bodies of programme code and are kept instead in a separate module (most commonly in a resource file), from which they can be retrieved as needed via some type of indexed look-up mechanism.

The real estate of the display of the device is usually controlled by a part of the operating system known as the windows manager, which knows the size of all the screen boxes in which the text strings are to fit. So, for example, if the display changes from a portrait format to a landscape format between one programme and another, the windows manager knows that a particular user message in the portrait format which was accommodated in two lines of wraparound text in a dialog box having a size and format able to accommodate wraparound text must now be accommodated in a dialog box which is only able to accommodate a single line of text. Hence, with the present invention, when the string ID for the particular message is selected, the text strings associated with that string ID become available to the windows manager, and the manager is able to select that text string which is able to fit as a single line of text in the box real estate available. Hence, at run-time, the string that is actually displayed on the screen is the one that fits best on the screen, taking into account the screen size, font, font size, style, available space and so on, and the portion of the operating system that controls the screen is arranged to select the best fit from among all the strings attached to the string ID. It can be seen, therefore, that the present invention provides several advantages over the known art

• Developers do not have to worry about ensuring that software is configured appropriately because the effort involved in development and the investment in maintenance time that would otherwise be needed to support flexible configurations, such as variable screen sizes and resolutions, different zoom levels, screen format, are reduced to an absolute minimum. Even devices with two screens (such as some mobile phones) require no extra development effort.

• Users of devices with small screens such as mobile phones do not need to worry about buying the correct version of the software, and also do not need to fear that they may be installing it incorrectly.

Hence, this invention provides a method by which the text which an application places on the screen of a computing device is decided on at the point of display by the operating system controlling the device rather than by the application designer at the point at which the application is built or by the owner at the point at which the application is installed. The mechanism by which this is achieved is that the application passes a string ID to the operating system, to which a number of possible candidate strings are attached. The OS then decides at the point of execution which of the possible candidates should be displayed, taking into account a number of possible display variables, such as the language in use, the available space on the screen, the device configuration and so on.

Although the present invention has been described with reference to particular embodiments, it will be appreciated that modifications may be effected whilst remaining within the scope of the present invention as defined by the appended claims.

Claims

Claims:

1. An interactive computing device in which a decision as to what text string is to be shown on a screen or other display device during the execution of an application is made at the point of display and not at application build time and is made by a component of the operating system and not by a component of the application.

2. A device according to claim 1 in which an application wishing to display text is operable to pass a string ID to the operating system component, which selects the most appropriate text string to display from amongst a plurality of text string candidates provided by the application.

3. A device according to claim 2 in which the selection as to the most appropriate text string to display is made according to any one or more of a. the language in use at the time the application is run

b. the size of the space on the screen into which the string must fit c. the device on which the application is running

d. the input methods available on the device at the time the application is run

e. the resolution of the screen at the time the application is run f. the zoom level of the screen at the time the application is run g. the aspect ratio of the screen at the time the application is run h. any other elements of the configuration of the device at the time the application is run

i. the zoom level of the screen

j. the devices or networks to which the device may be attached.

4. A device according to claim 2 or 3 in which the application is arranged to provide the candidate strings to be attached to each string in a separate file.

5. A method of operating an interactive computing device in which the decision as to what text string is to be shown on a screen or other display device during the execution of an application is made at the point of display and not at application build time and is made by a component of the operating system and not by a component of the application.

6. A method according to claim 5 in which an application wishing to display text passes a string ID to the operating system component, which then selects the most appropriate text string to display from amongst a plurality of candidates provided by the application.

7. A method according to claim 6 in which the selection as to the most

appropriate text string to display is made according to at least one of

a. the language in use at the time the application is run

d. the input methods available on the device at the time the application is run

i. the font, pitch and style of the text to be displayed

j. the devices or networks to which the device may be attached.

8. A method according to claim 6 in which the application provides the

candidate strings to be attached to each string in a separate file.

9. An operating system for causing a computing device to operate in

accordance with a method as claimed in any one of claims 5 to 8.