Information About the Technical Platform

ThePlatformmodel describes the technical means by which the user consumes content and in- teracts with the website. Again, the UsiXML platform model served as an inspiration. However, this model is slightly more abstract than UsiXML’s – for example, it does not include compat- ibility information such as the operating system version of a device, instead it concentrates on how web pages are rendered. The platform consists of the properties of the hardware device, the software (primarily the rendering engine), and the characteristics of the device’s network ac- cess. As mentioned before, the model should be extended if a particular class of devices, such as mobile devices, is of special interest to a web application, and if special usability tool support requires additional properties to be specified. Similar to the user model, a set of tags is available as a simple basic facility for extensions, with the discussed disadvantage that the semantics of any newly introduced tags must be agreed upon “ad-hoc” by the developer and the tool.

APlatformconsists of aHardwarePlatform, aBrowserPlatformand aNetworkPlatform. It is identified by a string – as with theUserclass, this string can be used by tools to refer to the platform, e.g. in error messages. If several alternatives are available in a context, such as both a mobile phone and a laptop computer, or two different browsers on a single device, this can be modelled by attaching several platforms to the context. The details of the platform model are shown in figure5.6.

HardwarePlatform

This class describes the capabilities of the physical device that is used to access the web applica- tion.

deviceDescription A string describing the primary form factor of the device. Possible values in- cludedesktop,notebook,subnotebook,cellphone,pdaandtv, others can be introduced if needed.

supportedAbility A set of tags with the same meaning as those in the user model’snoAbility,

partialAbilityandfullAbility, which lists the types of abilities which are supported by the device.

inputDevices A list of available input devices. The values are more concrete than support- edAbility above, they include the following: keyboard (includes numeric-keyboard,

handwriting-recognition), selection-buttons, pointing-device (includes mouse, track- ball,touchpad,trackpoint,joystick,touchscreen),scrolling-device.

(For example, a typical mobile phone would be represented by numeric-keyboard, joy- stick,selection-buttonsand possiblyspeech-recognition.)

outputDevices A list of available output devices. Possible values include: screen (graphi- cal display),characters(i.e. non-graphical text display),loudspeaker, braille, vibration,

Platform id : string HardwarePlatform deviceDescription : string supportedAbility : string[0..*] inputDevices : string[0..*] outputDevices : string[0..*] screenWidth : int screenHeight : int screenBpp : int screenDpi : int maxScreenChar : int BrowserPlatform engine : string engineVersion : string outputMedia : string[0..*] supportedTechnology : string[0..*] performance : int NetworkPlatform downloadSpeed : int uploadSpeed : int responseTime : int reliability : float costPerConnection : int costPerSecond : int costPerKByte : int 1..* 1 1..* 1 1..* 1

Figure 5.6: The platform model consists of information about the hardware device, the browser running on it and the type of network access.

screenWidth, screenHeight Screen resolution; number of pixels horizontally and vertically (0 if not applicable, i.e. not pixel-based)

screenBpp Number of colours of the display, in bits per pixel (1 for monochrome displays) screenDpi Resolution of the screen, in pixels per inch (0 if not applicable, i.e. not pixel-based) maxScreenChar Maximum number of characters that can be displayed (0 if not applicable).

For pixel-based displays, this value is the number of characters that can be rendered at the default font setting and line spacing, with an assumed character width which corresponds to the average of the lowercase alphabet characters. The value can vary significantly – for instance, braille displays may only be able to display a single line of text. Thus, tools should take care not to implement overly simplistic algorithms, e.g. “text paragraphs on a web page should be shorter thanmaxScreenChar”.

BrowserPlatform

In this class, properties of the rendering agent are specified. Because the primary focus is web applications, other, non-browser software which may be installed on the device is not described by the model.

engine The name of the rendering engine, such as mozilla,opera,webkitormsie, or the value

allto include all engines which are standards-complaint as well as the ones which are most popular.

engineVersion Version information about the rendering engine

outputMedia The set of CSS media types [W3C-CSS2, section 7] which the rendering engine can create output for – one or more of the following: all, braille, embossed, handheld,

print,projection,screen,speech,tty,tv. Values which are irrelevant in practice should be avoided. For example, the “FireVox” extension of the Firefox web browser allowsspeech

output, and the Opera browser can switch to projection or handheld output, but unless these unusual capabilities are really important for a web development project, they should be omitted to avoid that tools are misled.

supportedTechnology A set of strings identifying different technologies which are implemented in the browser, including these: xhtml,frames,javascript,flash,svg,xml,xslt.

performance A measure of how quickly the software can render HTML pages or execute Java- Script code. It is difficult to devise a unit of speed measurement which takes into account different aspects, such as any tradeoff between speed and memory requirements, JavaScript execution speed, CSS rendering speed, first-time rendering vs. rendering of pages visited before, etc. For this reason, no such attempt is made here. Instead, the values only indicate a ratio of speeds of the differentBrowserPlatforms present in a model. For example, if two platforms have twoperformancevalues of 1 and 4, then the second browser engine will be about 4 times as fast as the first one. The developer can assign values subjectively or base them on performance testing.

NetworkPlatform

This class characterizes the way the device accesses the Internet in general, and the web applica- tion in particular.

downloadSpeed, uploadSpeed Average available bandwidth for receiving and sending content, in bits per second

responseTime Typical time in milliseconds from the sending of an HTTP request until an answer is received. This includes the time to send the request, processing of the URL by the web server software, and receiving the response, but not the time of any server-side HTML generation mechanism, database lookup or similar. In other words, it is the time taken for the simplest imaginable HTTP request, e.g. an XMLHttpRequest which is answered with a zero-length reply.

reliability Probability in the range 0..1 of any single HTTP request to fail due to technical prob- lems, such as bad wireless reception, DSL router re-connect etc. For wired networks, a very low value like 0.001 can usually be assumed, whereas wireless connections are generally more likely to fail.

costPerConnection, costPerSecond, costPerKByte The monetary cost associated with the use of the Internet connection. No particular currency is assumed, so the values in all models for a web development project need to be based on the same currency. costPerConnection

Environment id : string partialAbility : string[0..*] fullAbility : string[0..*] requirement : string[0..*] stressed : int stressedDeviation : float

Figure 5.7: The environment model describes the way the use of the web application is influenced by external factors.

is the cost for one “session” (e.g. in a mobile GPRS network), not the cost for one HTTP or TCP connection.

Rates which cannot be described directly by these properties should be approximated with values which would lead to the same user behaviour. For example, for flatrates a cost of zero could be used, on the grounds that the user will not get more impatient or be deterred by the cost of access, as it is already covered by the general flatrate fee.