This is the Actors section of the document. See the DeviceDescriptionEcosystem overview.

Actors in the Device Description market

Editorial note
This list is neither final nor exhaustive. It also contains descriptions of the current situation of each actor at the time of writing. This information is provided at this point in the draft to establish context. It is expected that this information will ultimately be presented in this Note's companion "Landscape" document.

In this section we summarise the actors that currently play a role in the device description market, and those who are likely to play a role in the future. Each of these have different motivations for participating in the device description ecosystem. These are highlighted in each case.

Device Manufacturers

The manufacturers provide the key physical capabilities of the mobile device. Their manufacturing processes determine the size of the screen, the amount of memory, the speed of the processor, the networking features and more.

Motivation

By providing accurate descriptions of their devices, manufacturers can ensure that the features of their devices will be known to * service providers, application developers, content authors and adaptation solutions, so that these features can be exploited. This should produce improved user experiences, raising the approval ratings of their devices, and thus leading to enhanced sales.

Question: what is the current motivation for manufacturers to create device descriptions, such as instances of UAProf?

Unique Selling Point

* One of the reasons for introducing new features/capabilities to a product is to make it more competitive. Encouraging the use of such features may lead to increased demand for the products. Publication of device features is a means of encouraging their use.

Seamless content delivery DELETED

Current situation

Device manufacturers are not required to provide device descriptions. For mobile devices, such descriptions would normally be represented using the OMA's User Agent Profile technology, which is based on the W3C's CC/PP. If these profiles are created by a manufacturer, there is no requirement to store them in any particular place for public access, or even to advertise that they have been created. In some cases, the stored profiles have been found to be invalid according to the specifications of UAProf, or have contained inaccurate data, possibly because the device characteristics were altered during the design/manufacturing process without updating the profile before publication. Errors are not always corrected. Some useful device information has been contained within the profiles in the form of comments, which are inaccessible to automated processes.

The OMA is making efforts to provide better access to validation tools, and to provide a repository of validated profiles. This will provide manufacturers with a common management framework in which to facilitate their device descriptions. Facilities for augmenting or correcting the OMA repository are not provided, though the public access to the repository means that such facilities could be provided through third parties.

Absence of regulatory imperative to produce profiles

Manufacturers are not required to provide profiles of their devices. There is therefore no penalty for those who do not provide profiles. The availability of profiles therefore depends on other factors.

A regulatory imperative to provide profiles would guarantee their availability, but such regulations could only be imposed if their necessity could be clearly demonstrated. There is also the issue of identifying the appropriate regulatory body to enforce the regulations.

Absence of a standards imperative to produce profiles

There are no standards, necessary for the manufacture of devices, that demand the provision of device profiles. In fact, the only popular standard used by Web enabled devices that demands some communication of device capabilities is HTTP itself, in the form of the "accept" header. It is unfortunate that very few Web servers actually make use of the accept header. With this poor track record, it is not surprising to find that there is skepticism about the future of device description technology.

Commercial regulation

Agreements between operator and manufacturer so that devices must come with descriptions in order to be supported by the operator. Only works between big operators and big manufacturers.

Component manufacturers

The characteristics of a device depends on the characteristics of the components of which it is composed. Component suppliers do not contribute to the creation of device profiles. The principal manufacturer (or assembler) takes this responsibility.

Browser Vendors

Browser vendors provide content presentation software that may be installed at the time of manufacture, or at a later stage by the end- user via an installation process. The browser determines the presentation capabilities, including the type of markup, the type of image, sound or other media formats, and the modes of interaction.

Obviously, interaction may be limited by the capabilities of the device.

Motivation

Like device manufacturers, browser vendors are motivated by economic factors. By making the characteristics of their browsers known to the authors and adaptation solution providers they ensure that content can be presented to maximum effect. Good user experience should encourage more manufacturers or operators to adopt the browsers, and end users to install them.

There are also providers of browsers who are not motivated by economics, the open source community being a particular example. For these the motivation is typically a desire to demonstrate quality and professionalism while contributing something useful to their user community. Providing descriptions of their products is a simple way to advertise the features they are providing, and of ensuring that these features are used.

Current situation

Browser vendors are not required to provide descriptions of their browsers. Unlike manufacturers, there is no common technology with which they can provide descriptions. The UAProf vocabulary does not extend to include the specific features associated with the browser, although some vital information is supported. Only the content adaptors maintain descriptions related to browsers, and with the exception of the open source solutions, these descriptions are treated as commercial property. This is because of the effort involved in gathering and verifying information about the browsers, particularly as their characteristics can be affected by the device into which they are installed.

Device Validators

The handset validation sector is both a provider and a customer of device descriptions: they are gatekeepers of new handsets coming into the network. Although a lot of their knowledge of handsets is at lower radio levels, there is increasing service/application/content-level expertise.

Motivation

As both consumers and producers of device descriptions, the business of the device validator is dependent on device descriptions.

Current situation

We need expert opinion here.

Accessibility Groups

The focus of the accessibility and usability groups is typically on software and services, rather than on the characteristics of the device. Nevertheless, there are certain device features that can be described by these groups, including:

• Font-magnifier
• Text-to-speech
• Color schemes
• Navigation layout
• Keyboard usability
• Special navigation keys
• Navigation layout
• Access keys

To illustrate how an accessibility/usability group might augment the descriptions provided by the manufacturer, consider the first item on the list: "font-magnifier". An accessibility group may determine that the built-in magnifier works best with sans serif fonts, which is information that might not be indicated by the manufacturer. This assessment would be made by specialists available to the accessibility group that would not necessarily be available to the manufacturer.

Motivation

Current situation

Content Adaptors

Because of the wide diversity of Web-enabled devices, a single representation of a resource will not be suitable for all devices in all delivery contexts. This has been well documented by the DIWG. Content adaptation solution providers use device descriptions as part of their content adaptation processes. Better device descriptions lead to better adaptations.

Motivation

Content adaptors are typically motivated by economic factors to maintain large and detailed repositories of device descriptions. The quality of their adaptations is directly influenced by the quality of the information in their repositories. Adaptation quality is a key selling factor.

Current situation

Content adaptors maintain large and complex repositories of device descriptions. They do this by gathering information from a number of sources, including:

• Manufacturer specifications
• UAProf data on manufacturer Web sites
• Open source descriptions
• Reports from new users
• Direct assessment in their evaluation laboratories

Direct assessment is the primary source for some content adaptation providers, as it is the most reliable. This requires that their evaluation laboratories have physical access to new devices. In many cases, descriptions of new devices appear some time after the devices are released to the market, so there can be a lag between new devices appearing and optimum content being available.

Content Annotators

An annotator adds content to existing content, possibly via a metadata-based technology. This might be for translation, for summaries, for interpretation. Not sure if there is an actual company or organization I can use as an illustration, nor if such people would be interested in using or creating device descriptions. Needs more thought...

Examples: adding keywords, adding company references to cause tickers to appear etc.

Motivation

Current situation

Web Content Ratings

People who provide information to enable you to decide what is suitable (to your device, to your age, to your interests, etc.) We might find in the future that these people will provide a service for rating if a site is MobileOK, MobileBetter or MobilePerfect. Needs more thought.

* The W3C Mobile Web Best Practices Working Group has endeavored to provide guidance on the creation of content suitable for mobile devices. Among the general principals cited by the group are the exploitation of device capabilities to provide an enhanced user experience and the taking of reasonable steps to work around deficient implementations. To achieve this, the authors or content delivery systems need to be aware of the capabilities and deficiencies. Validators are proposed (and some implemented) by the BPWG to assess if the content on mobile sites are adhering to the suggested practices. Third-party services are also in place to provide similar assessment of content. The results of such assessments are typically ratings that can be advertised to potential content consumers.

Motivation

* The providers of content rating services do so in order to encourage more and higher quality content in their aspect of the Web. For example, the BPWG provides content ratings to increase the amount of content that can be accessed via mobile devices. Other rating providers may do so to encourage higher quality content and/or to make revenue from the issuance of trust marks. Content authors make use of content rating services in order to improve the quality of their content, to make it accessible to a wider audience and to advertize this availability via trust marks or other certification mechanisms that indicate the ratings achieved.

Current situation

* The BPWG has published a document entitled “mobileOK Basic Tests 1.0”, which can be applied to content to determine if it conforms with the “mobileOK Basic” requirements. It is expected that future tests will include cases where particular device capabilities can be used to their best advantage, which assumes that such capabilities can be determined. Third-parties are also providing similar content rating services to their respective communities.

Content Authors

Content author use device information to determine the amount, type and variations of content to provide. For example, it is common for branding purposes that a corporate logo will be available in a number of different formats and sizes. The variation in these images results from knowing the variation in device characteristics. * The information may be used at the actual time of authoring, or may be used at delivery time in a manner previously indicated by the author.

Motivation

Authors are concerned that the content they create is properly represented to the user. * The fidelity of brand representation is significantly important to many commercial organizations. For example, it is common for branding purposes that a corporate logo will be available in a number of different formats and sizes. The variation in these images results from knowing the variation in device characteristics. For many, there is a compelling need to guarantee the accuracy of their content, especially when representing in complex layouts (e.g. timetables). The growing popularity of well-designed Web sites is further evidence of the attention that authors are giving to making optimal use of device capabilities, whether these be with respect to rendering, scripting, interaction or otherwise.

Current situation

* Crude "browser sniffing" techniques provide many authors with the means of determining some of the general capabilities of the client into which the content is delivered. Many of these techniques are now being packaged into libraries for ease of use. Component-based authoring approaches also offer some degree of device capability awareness, where each component alters its representation according to the delivery context. Solutions that are aware of a large number of contextual parameters are generally only available commercially, though some free/open solutions are available that offer basic access to the delivery context. In general, the representations of context, and the interfaces to the data, are not interoperable across the various solutions.

Application Developers

* Applications rely upon their operating environment to execute and interact with their users. The environment includes both the operating system and the hardware. With ever increasing varieties of environments, mainly due to hardware diversity, applications either have to be tailored to the individual environments or be capable of adapting when deployed into any environment. The latter is extremely challenging, so generally, applications are tailored in advance for the environments in which they are expected to operate. This applies equally to applications that run natively on the device and those that run within a browser. Application tailoring makes use of device descriptions.

Motivation

* Access to device descriptions enables developers to create applications that are compatible with the broadest variety of environments. Developers either expect their development tools to be aware of device diversity, or be adaptable based on information they provide. For example, development tools that produce code compatible with PDA devices will typically be aware of the screen dimensions and orientation, or be capable of producing code that can adapt the screen layout based on screen properties discovered at the time of execution. With new devices appear regularly and developers are keen to see that these new devices are also supported because this represents new market opportunities for their applications.

Current situation

* While many development tools are aware of certain kinds of device diversity, any significant change in capabilities introduced by new devices will usually require a significant upgrade to the tools. Modular development environments are easier to upgrade in this manner, since only those modules that are affected by the changes in device characteristics need be upgraded. Virtual Machine (VM) approaches are often used to overcome some device diversity (Java being a popular example) though often this involves gaining greater device compatibility at the expense of being unable to access new device features. The use of scripting in browsers is also extremely popular, especially with the growing use of the AJAX design pattern, though once again device diversity can present challenges. This is particularly challenging with the wide variety of interaction modes, which either requires increasingly complex scripts to be delivered to the browser, or some pre-adaptation to be performed by the server.

Operators

Network operators provide the means for conveying content to devices, and in many cases also provide the content. Mobile Network Operators are an example of content adaptors.

Motivation

Operators aim to provide a functional user experience to their subscribers. They may also enforce content ratings policies. Device descriptions also assist in certification testing, and hence accelerate the release of the device to market.

Current situation

Multiple proprietary and commercial implementations * are in use, with some having basis in standards such as UAProf and WURFL. Often the device descriptions include some operator-specific information, such as whether the device is part of a specific promotional range * being promoted by the operator.

End-Users

End users * are consumers of device descriptions, and they can * also influence device descriptions. They can enable or disable features, and in some cases can combine multiple devices into a composite (e.g. by adding a camera to a cellphone). End users are a source of preference information, which is another influencing factor in content selection or adaptation. This is why capabilities and preferences are handled by the same representation within CC/PP. End-user preferences, choices and combinations of features should complement the device description technologies.

Motivation

* Users are particularly motivated by new features, whether it be because of the benefits that these features offer, or because of the enjoyment that many people get from something new. Users are therefore eager to learn of new features that are offered by new devices, and will often make comparisons between brands and models on the basis of competing features, as part of their purchasing decisions. Additionally, the ability of applications to make use of features may also influence their selection of devices and applications. Users are also being empowered to affect their devices by being able to alter the installed software, or augment the hardware. In this way, users have made device descriptions an increasingly dynamic issue. It is no longer possible to rely on the manufacturers’ descriptions of their devices once they have been delivered to the end users. While some properties may be fixed (e.g. built-in keypad, screen, processor etc), many are user-configurable (e.g. browsers, memory, media players etc.). To adapt to such environments it is necessary to be able to determine the actual description of the device in real-time.

Current situation

* Users tend to discover the properties of their devices through marketing material, rather than through an automated mechanism. Comparison shopping sites on the Web offer a break-down of features across brands and models. The need for easy comparison has led to the selection of units that are easy to comprehend, such as the number of different colors that can be displayed, rather than the number of bits per pixel, types of palette or any other measure of color capability. Access to dynamic properties (e.g. screen orientation) is being provided through various APIs for non-browser applications, though these may also be exposed to scripts in browsers. This is the goal of the W3C UWA WG’s DCCI specification. Meanwhile, other organizations such as the OMA are working on similar problems [DPE].

Repository Providers

A repository provider offers a set of descriptions for sale, or license * or free unrestricted use. Need to say something about who consumes this data. This is a very new type of business. * This information can be used for marketing purposes (e.g. comparison shopping), to augment the sales process of related products (e.g. games for mobile devices), to adapt content or applications according to the needs of the end user, to support emulators for use in test environments, to facilitate prototyping and many other uses.

Motivation

* Given the many possible uses of device descriptions, repository providers will be interested in a common device description technology so that they can reach the largest possible customer base. For example, if a device description repository provider and the vendor of a device prototyping tool are to work together, it is essential that the interface between the two is compatible. Similarly, if the data representing the current description of a device (based on client-side analysis) is to be used on the server side, then they need to agree on a common vocabulary. Obviously there would be problems if the repository represented the usable screen width in millimeters while the client-side script determined this value in pixels. Compatibility and interoperability are therefore strong motivations for repository providers.

Current situation

* In general, repository providers use proprietary formats and interfaces, and rely upon other developers to bridge any differences. Some providers employ UAProf in their repositories, though this limits the expressivity to the UAProf vocabulary. The DDWG participants include commercial and open source providers of device repository technologies and data who support the goal of a common interface and vocabulary.

Standards Organization

Standards organizations determine the interoperable means by which their participant members achieve mutually beneficial goals. The goals (e.g. efficiency) are generally perceived by the user community as positive objectives.

Motivation

The attainment of standards by the organization's membership can establish a defensible perception of quality that is attractive to consumers and acceptable to regulatory authorities (where appropriate). This enables products (that verifiably meet such standards) to operate in a consumer market and with a reasonable expectation that adherence to standards will attract customers.

Standards organizations capitalise on their members desires to benefit from standardization, and their members desires (pre-standardization) to ensure that the results of a standardization process will be in line with their current/planned products and services.

Since device descriptions are to be shared and used by many actors, interoperability becomes a key requirement, for which a standards organisation is the natural facilitator.

Current situation

Although several standards already exist that have a significant bearing on device descriptions (e.g. RDF, CC/PP, etc.), the benefits to the participants in the standardisation process have not been made obvious. Consequently it has been a struggle to achieve any standards, with barely enough done to demonstrate interoperability. The quality one normally associates with the use of standards is not evident in the case of device descriptions, and this is probably because of two reasons:

• There is no regulatory body demanding quality of device descriptions in accordance with any particular standard.
• The end users are unaware of any benefit to them that might derive from the availability of standardized device descriptions, and thus their buying patterns are unaffected.

Content Providers

* Content providers are sources of content that is distributed to end users directly, through syndication or through partnerships. It is increasingly important that the content is accessible to end users regardless of the device they use to access the content and therefore some degree of selection or adaptation is required. This is done on the basis of known device characteristics. Where the content provider is not aware of the final delivery context, the authored content may be provided in a variety of forms to suit a variety of possible contexts. For example, the images accompanying a news article may be provided in various sizes at various resolutions.

Motivation

* As content providers either have to react to delivery contexts in real time, or anticipate future delivery contexts, it is in their interest to determine the parameters of such contexts that may affect the way content is delivered.

Current Situation

* Content providers frequently use formats that are independent of the delivery contexts (e.g. RSS news feeds), and rely upon client software, or context-aware server software to adapt accordingly. In some cases, alternate content is provided (e.g. thumbnails of images, and short summaries of articles) to support a minimal degree of selection. As content providers increase the amount of content delivered to non-desktop environments, the need for context awareness is increasing.