3.0 Important Considerations¶
3.1 Content and Usability¶
During usability testing of the web.alive user interface we encountered a number of usability issues that were directly related to the content we were using rather than the web.alive user interface itself. It became apparent that content creation can have a positive or negative impact on usability. The following are some key points to keep in mind during content creation:
- Provide Proper Affordances:
For example, a door should be readily recognizable as a door and it should convey the direction in which it opens. Likewise, a button within the environment should readily convey that it can be pushed and its location in the environment should help in determining what the button acts upon. For example, buttons to control a slide presentation should be place in close proximity to the presentation that they control.
- Avoid Improper Affordances:
which in fact do nothing in the environment. For example, a light switch in the environment conveys that an adjacent light can be turned off and on. If the light cannot actually be turned on and off via the light switch then the light switch should not exist in the environment. This is an important point because content developers may have a tendency to introduce such elements in their efforts to make their environments more realistic. However, such improper affordances confuse users and introduce usability problems.
- Always Provide Proper Feedback:
Provide proper feedback to users so that they can evaluate their actions. For example, when a next slide button is pressed in the environment the user should be able to evaluate that their action has been accepted by seeing the associated slide presentation advance to the next slide. That is, they should be able to see the slides being advanced from the position at which they are able to press the button.
- Include Proper Signage
Just as in the real world, people look for signage when they are trying to locate a specific place. Make sure that signage is adequately placed, readable, and provide clear instruction. Also use volumes (see section 5.1) with proper location name values to properly name regions.
3.2 Download Size and Performance¶
Environments can be almost as large and complex as you can dream. However, the more detail you put into an environment, both in terms of polygons and in terms of textures the longer it will take to download the environment and the slower the environment will display. This section provides some guidelines to help you create environments that will download quickly and run smoothly on the widest possible range of PCs. Of course, if your target audience is known to have better than the minimum recommended hardware for web.alive, then you are welcome to exceed these guidelines.
Factor Maximum (in view) Maximum (in level) -------------------------------- ----------------- ------------------ Polygons 20,000 100,000 Textures 5MP 100MP Overdraw 5 - .wae file size - 50MB Total size of web.alive packages - 25MB (does not include insertions) Active WebTextures 10 - (with pure html content) Active WebTextures 2 - (with flash video) Environment Dimensions - 10km x 10km x 10km
Please note that there are several important optimizations that can be used to improve rendering and download performance. These optimizations include the use of image insertions, activation volumes, and anti-portals.
Image insertions allow the actual pixels of the texture to be downloaded only when the user actually looks at the texture (deferred download) – this allows users to enter the environment faster the first time. Image insertions also support .jpg compression which is much more effective than DXT compression supported in web.alive packages – so the total download size is smaller.
Activation volumes allow control over when resource intensive actors are loaded and unloaded. A good example is WebTextures – each WebTexture uses resources equivalent to having that same web content displayed in your web browser (at least 5MB RAM + some CPU for animations/video + some network for streaming audio/video etc). Activation volumes render the web texture (and thus use the resources) only when the user is in a particular volume (or volumes). This allows an environment to have many web textures, but only consume the resources for those textures when the user is nearby.
Anti-portals are simple geometric shapes that the content developer can create. An anti-portal tells the rendering engine that it isn’t necessary to render any actor, static meshes or BSP that is completely concealed behind the anti-portal. Carefully positioned anti-portals can dramatically improve frame rates in complex environments.
For more information concerning the optimization of content please consult the web.alive Content Optimization presentation found Here.
3.3 Audit Logs¶
The web.alive audit logs function to log important events within an environment and are intended for consumption by other computer programs (e.g. analytics). Audit logs are only created on the server and they follow the W3C logging standard. The Audit Log Guide 16 may be consulted for a better description of the audit logs.
Audit logs should be considered during content creation since a number of configurable actors produce audit logs when triggered. In particular, the “UserLabel” field can be set to a value which will be included in the Subject field of any audit logs generated from the associated actor. Setting the “UserLabel” field will result in better Audit logs which are easier to interpret. Finally, some actors provide the ability to enable/disable audit logging on particular events. For example, by default a generic trigger will generate an audit log when triggered but will not generate an audit log when untriggered. However, it is possible to disable the audit logs when triggered and enable them when untriggered by modifying the trigger’s properties. Table 1 lists a number of Actors with properties pertaining to audit log functionality. The configuration of these properties, along with the “UserLabel” property, should be considered during level creation in order to ensure proper audit logging.
Actors with Audit Log Properties
Actor Properties related to Audit Log Functionality
----------------------------- ---------------------------------------------
Trigger enableTriggerAuditLog (default=true)
enableUnTriggerAuditLog (default=false)
LookAndUseTrigger enableAuditLog (default=true)
StareTrigger enableStareAuditLog (default=true)
enableUnStareAuditLog (default=false)
PhysicsVolume enablePawnEnterAuditLog (default=true)
(and all subclasses including enablePawnExitAuditLog (default=false)
OMNIListenerVolume,
OMNISpeakerVolume,
and PrivateRoomVolume)