URC sockets are the base on whicpersonalised user interfaces can be build. Since they are the common base of all possible user interfaces they should be well designed an stable in time. These guidelines help to develop reliable sockets.
For the quality of your User Interface Sockets, consider the following guidelines:
- A Socket is a functional unit of a Target. Split and merge sockets of a Target accordingly.
- Think about functional blocks that are independent of each other.
- For example, a telephone-fax appliance would have two sockets: a telephone socket, and a fax socket.
- Use Dublin Core Metadata Terms to describe a Socket, including the dcterms:modified term.
- The dcterms:modified term facilitates caching at runtime.
- If you use the socket builder tool, dcterms:modified will be included automatically in your socket description.
- A Socket is modality-neutral in general. When designing a socket, think about implementing your user interface in at least two different modalities: visual and auditory.
- Example for a visual user interface: A smartphone with touchscreen.
- Example for an auditory user interface: An automatic voice system for phone access.
- In general, think about the information and interaction items on a small screen rather than on a big screen.
- At least one grouping sheets should be suitable for small screens.
- Use groups with a "normal" and "weak" cohesion level to allow for pagination on small screens, where appropriate.
- For changing the status of the Target, use variables rather than commands.
- With variables, the user always knows (by reading the value of the variable) in what state the Target is. With commands, the state is only available temporarily upon execution (as return value of the command).
- With variables, a controller can choose how to change a value (e.g. by increments and decrements, or by typing a value). For commands, this is already pre-defined.
- Example: Use a boolean variable 'power' to switch the Target on and off.
- Use XML Data Types and publish them external to the Socket for reuse, where appropriate.
- Create special data types to define the semantics of a variable. Restrict the value space accordingly. Example: Define a data type "volume" as an integer in the range of 0 to 100.
- Define your data types in your own target namespace, and make them available on a public web server for re-use by you and other Socket designers.
- Define labels on the data type level rather than the socket variable level, where appropriate.
- When labels are defined on the data type, they apply to all instances of socket elements that use this data type.
- If you post data type definitions publicly, you should also post resource sheets containing labels for the types and their values.
- Use notifications if the user needs to get notified in a modal manner.
- Notifications are designed for this exact purpose. If you misuse a variable for notifying the user, the user interface may not know that it should alert the user to a change of value.
- The notification text has to be specified as an atomic resource.
- Specify dependencies between the socket elements where appropriate.
- Dependencies can be used by intelligent user interfaces to assist the user in operating a system.
- For example, the system can tell the user that they need to switch the power on before they can select a TV channel.
- Split resource sheets based on language and other criteria that help to minimize download size at runtime.
- It is good practice to create a resource sheet for each language.
- One resource sheet may contain resources for a target and its sockets together since both files will be needed by the client at runtime.
Taken from openurc.org. Last update: Gottfried Zimmermann, 2015-04-20