Usability-Improving Mobile Application Development Patterns for Android

(1)

Usability-Improving Mobile Application

Development Patterns for Android

Bettina Biel, Volker Gruhn

University of Duisburg-Essen

paluno, The Ruhr Institute for Software Technology Essen, Germany

[bettina.biel,volker.gruhn]@paluno.uni-due.de

Draft for EuroPLoP2010

Abstract The fast evolution of mobile devices and their complex functionalities require an

improvement of the design process applied: Using patterns allows to document and use up to date and already proven solutions. This paper introduces two usability-improving mobile application development patterns for software designers of mobile applications that run on mobile devices without accessing remote logic or data storage.

1. Introduction

Mobile applications and their design gain more and more importance. Existing mobile devices are enhanced with more computing power, connectivity and interaction capability. The fast evolution of mobile devices and tools and their complex functionalities make it very difficult to design for a short time to market. This requires an improvement of the design process applied for designing new and enhancing existing mobile applications. In order to comply with this evolving requirement we apply the approach of using patterns that hold already proven and up to date solutions for developing and designing mobile applications.

Usability is a quality attribute of the usage of an application. It describes from the users’ point of view, how effectively, efficiently, safe a user can accomplish tasks of a good utility that are easy to learn and to memorize (usability goals), and how pleased one feels about the whole user experience [PRS:2002]. Usability can be improved by skillful design of the user interface, and, as importantly, by careful design of user-system interactions. For these, we propose usability-improving mobile application development patterns to be used by software designers in the area of mobile applications.

There are several pattern collections available that discuss graphical design; our collection shall focus on issues beyond the graphical layout of the user interface. Such usability patterns were coarse-grainedly designed by Bass et al. [BJK:2001]. Another research project, “Mobile Design Patterns and Architectures” [MODPA:2006], lists software development patterns with reported use in the mobile environment. Several well-known patterns [GHJV:1995] and some specific patterns regarding interaction design were found to be useful in the mobile domain. In

(2)

general, the MODEL VIEW CONTROLLER pattern is recommended, and for example, amongst other typical patterns found are the OBSERVER or the ABSTRACT FACTORY. The presented patterns are derived from a review of literature about best practices and online resources for developers in order to support the software design of an Android application by an interdisciplinary team of usability engineers, software architects and programmers.

• CLIENT-SIDE MULTI-SCREEN SUPPORT**

Mobile platforms run on different devices with different screen sizes and resolutions. In order to support all user interfaces, and thus usability, application developers have to write their applications to be displayed on multiple screens. How can developers design their applications for a correct display on many devices?

Therefore, use a small number of predefined media classes and scale them to the need of the specific device.

• UNOBTRUSIVE USABILITY TESTS

Developers should test their application without and with users to collect valuable test data. How can developers test their applications for usability on different devices at run time?

Therefore: Collect and analyze test data at run time while users interact with the application and use this to test the application.

• RANDOM UI-EVENT STRESS TESTS*

Developers can test their application automatically, but they cannot foresee how users will interact with the application. How can developers test their applications for usability on different devices considering unexpected usage?

Therefore, use an application that sends pseudo-random streams of user events to the system as a stress test.

• SPECIFIC TEST APPLICATION*

(3)

Therefore, use an intermediate component with a registration mechanism so that the coupling can be reduced.

Our patterns follow a standard format of patterns, supplemented by a section called “usability consequence”, a category for describing the effects on the usability goals and on user experience. Table 1 shows the pattern format.

Table 1: Pattern format (compulsory elements)

Part Description

Trust factor

Newly identified pattern: no asterisk; Relevant pattern: *; Pattern proven to describe a real approach: **; Regularly used and evaluated pattern: *** [BGG:2008].

Name Short name based on problem or solution.

Categories User- or system-initiated interaction.

Context Technical context regarding communication, distribution of logic and _{data storage.}

Illustration Situations in which the pattern is useful and why.

Problem Problem which the pattern addresses.

Forces Forces with an effect on the solution.

Solution Abstract description of the proposed solution.

Usability

Consequences

Effects on usability goals: Effectiveness, efficiency, safety, utility, learnability, memorability; Effects on user experience goals such as fun, satisfaction, aesthetics [PRS:2002]

Literature References.

Management Author, credits, creation/modification, revision.

This paper presents work-in-progress and introduces five patterns for the development of mobile applications running on mobile devices without accessing remote logic or data storage.

(4)

2. Patterns

as

Name: CLIENT-SIDE MULTI-SCREEN SUPPORT**

Interaction Category/ies: Presentation, device independence Context: A mobile application that runs on a mobile device with

local data storage and logic with no or infrequent access to a server.

Illustration: A user wants to access the system using his own

specific type of device, and he expects the application just downloaded to run on his device. It runs, but the content is not rendered properly. Another user downloads the mobile application

but is does not start at all: the mobile platform on his mobile device filtered out the application because it could not display it correctly – his device’s scrren size is smaller than expected by the application developers.

Problem: Mobile platforms run on different devices with different screen sizes and

resolutions. In order to support all user interfaces, and thus usability, application developers have to write their applications to be displayed on multiple screens. How can developers design their applications for a correct display on many devices?

Forces:

• The heterogeneity of devices and the short innovation cycles in general make designing for all devices a time-consuming task.

• Mobile platforms manage most of adaptation of an application to the current screen, but for a precise control it is necessary to create screen-specific resources.

• It might be possible that targeted mobile platforms are designed to run legacy applications but often the application has to be adapted somehow to make use of such features.

• Some scaling mechanisms for resources as images can be CPU-expensive.

• Application developers have to carefully consider the possibilities of design, content and functionality within the small screen area.

(5)

Scaling mechanisms provided by the platform can display applications properly on most devices, especially when the screen is the same size or larger. But it may need minor adjustments before they display on smaller screens, because of the reduced screen area there may be tradeoffs in design, content, and function.

Low density (120dpi) Medium density (160dpi)

High density (240dpi) Small

screen

QVGA (240x320), 2.6"-3.0" diagonal Normal

screen WQVGA (240x400), 3.2"-3.5" diagonal FWQVGA (240x432), 3.5"-3.8" diagonal

HVGA (320x480),

3.0"-3.5" diagonal WVGA (480x800), 3.3"-4.0" diagonal FWVGA (480x854), 3.5"-4.0" diagona Large screen WVGA (480x800), 4.8"-5.5" diagonal FWVGA (480x854), 5.0"-5.8" diagonal Table 1: range of screens supported by Android [DA2010]

The application should therfore be designed for a standard screen of intermediate size and medium density.

Variant Selection

For the exact control of the application's design, specific resources should be prepared and provided. Using media variants (high, medium, small density classes) also provides a compromise between memory and screen optimization. Instead of using a default directory, directories named according to the density provide specific resources for classes of devices to safe disk space.

Figure 1: The solutions' components

Developers should make use of a scale mechanism that adapts resources to match the display's density.

(6)

If the mobile application creates a resource internally, e.g., a bitmap, and draws something on it, it creates bitmaps at the moment when it is drawn (``draw time''). Scaling at draw time is more CPU-expensive, but it uses less memory.

Related Patterns: The parent pattern is MULTI-CHANNEL ACCESS which also refers to alternative solutions for client/server systems.

Known uses: Android applications best practice [DA:2010] Usability consequences:

[+] Utility: The application will be displayed correctly when screen sizes and density are considered during the design.

[0] User experience: the application must be displayed correctly for a good user experience. As users expect this, there is no additional benefit for them. A correct presentation is a basic usability expectation that must be met. If it is absent, only then users will notice, and they will not like it.

(7)

Name: UNOBTRUSIVE USABILITY TESTS

Interaction Category/ies: System-initiated interaction

Context: A mobile application that runs on a mobile device with local data storage

and logic with no or infrequrent access to a server.

Illustration: Usage data is logged and analyzed by developers to understand how

the system worked.

Problem: Developers should test their application without and with users to collect

valuable test data. How can developers test their applications for usability on different devices at run time?

Forces:

• The heterogeneity of devices in general make designing for all devices a time-consuming task. But it is important to test whether a mobile platform's features affect the user-system interaction.

• Storing (test) data on a mobile device for analysis is useful, but memory capacity is always limited.

Solution: Collect and analyze test data at run time while users interact with the application and use this to test the application.

Components of this solution are a data recorder and the components with data to record. These components (or modules) provide data that is recorded by the data recorder. For the evaluation during usage, a data recorder within the application records data needed of components during usage, for example, record clicks, touches, gestures, or system-level events.

Collected data should be accessed and used by a data analyzer, which evaluates it regarding patterns of errors, user problems or critical incidents.

Module with data to record

Data recorder Data analyzer

Figure 2: Unobtrusive Usability Test – recording and analyzing data

This solution can be enhanced: In order to simulate real usage, a test data streamer provides streams of user events. It generates events for clicks, touches, gestures, or system-level events based on the stored data. But also random streams of interaction should be considered because users can interact with the system in ways unexpected by developers.

(8)

Figure 3 shows how such a system could be designed implementation. DATA INDIRECTION can be used to simulate user interaction within a system.

Figure 3: Example software architecture design

Related patterns: The parent pattern is MULTI-CHANNEL ACCESS which also refers to alternative solutions for client/server systems. The pattern MULTI-SCREEN SUPPORT addresses how to design for multiple screens.

Literature: A basis for the pattern presented is EVALUATING THE SYSTEM in [BJK:2001].

Usability consequences:

[+] Safety: Testing a device helps to find errors, and only known errors can be fixed. Unobstrusive testing is possible that way.

[+] Utility: The application will be displayed and used correctly, if the application is tested and revised.

(9)

Name: RANDOM UI-EVENT STRESS TESTS*

Illustration: Automated usability tests that imitate user input can help developers to

ensure that their mobile application's screen is properly displayed at all targeted devices, and that interactions work.

Problem: Developers can test their application automatically, but they cannot

foresee how users will interact with the application. How can developers test their applications for usability on different devices considering unexpected usage?

Forces:

Solution: Use an application that sends pseudo-random streams of user events to the system as a stress test.

Use emulators

Different emulators should be used as a first test environment: All supported screens (sizes, densities, platform API) should be defined and used for the tests. An emulator for the test should run at a similar physical size of the targeted mobile devices, i.e., the emulator running on a laptop with a density of 96 dpi should scale the emulator display according to the mobile device.

Test on emulators and on devices

Use a test program that sends random UI-events to the application and monitors its behavior. The application should be able to monitor and report application faults, unhandled exceptions and crashes.

Walkthrough

Of course, it is also necessary to conduct a walkthrough by yourself in order to test whether screens are presented correctly.

User Tests

Involve typical users of your application to test it.

Related patterns: SPECIFIC TEST APPLICATION describes a specific test application, while RANDOM UI-STRESS TEST describes the use of a general ui stress test application.

Literature: The UI/Application Exerciser Monkey can be used for stress tests on a

device or on the emulator [DA:2010].

[+] Utility: The application will be displayed and used correctly, if the application is tested and revised.

(10)

Name: SPECIFIC TEST APPLICATION*

Illustration: An application that imitates a user of a particular application.

Problem: Developers should test their application with and without users. How can

developers test their applications’ specific dialogs on different devices automatically?

Forces:

• Storing (test) data on a mobile device for analysis is useful, but memory capacity is always limited.

Solution: Write a specific test application while writing the application itself.

The main idea is write a second application that tests the developed application. This application should test every method, but also provide streams of user events to simulate real usage based on dialog flows.

This application should generate events for clicks, touches, gestures, or system-level events based on the typcical dialogs of the application. But also random streams of interaction should be considered because users can interact with the system in ways unexpected by developers.

Related patterns: The pattern UNOBTRUSIVE USABILITY TESTS shows how test data can be used within the system; and RANDOM UI-STRESS TESTS describes that a general ui-test tool should be used as well.

Literature: A basis for the pattern presented is EVALUATING THE SYSTEM in [BJK:2001].

[+] Utility: The application will be displayed correctly, if the application is tested and revised.

(11)

Name: DATA INDIRECTION**

Interaction Category/ies: Architecture mechanism

Problem: Multiple data producers and data consumers have to be added or deleted

to a system so that neither the data producer or the consumer is affected..

Solution: Use an intermediate component with a registration mechanism so that the coupling can be reduced.

A separate component is used to distribute the data, and both the consumer and the producer of that data register at the component. The registration process can happen at design-, compile-, or run-time. Both producer and consumer of the data have a direct relationship with the distribution component but not with each other. Thus, new components can be added or removed by notifying the distribution component. Coupling is reduced. Data consumer Distribution

component Data producer

Figure 4: Data producer and data consumer are registered at the distribution component

Related patterns: This pattern is used by UNOBTRUSIVE USABILITY TESTS.

Literature: A basis for the pattern presented is DATA INDIRECTION in [BJK:2001].

[+] Utility: The system works as intended.

3. Conclusion

We presented several patterns for usability-improving mobile applications development. Our work-in-progress comprises the identification of more patterns and their combination into a pattern language.

Acknowledgments

The authors would like to thank their shepherd Yishay Mor for his reviews and comments that helped to improve the paper.

(12)

Bibliography

[BG:2006] Biel, B., V. Gruhn: Dialog Flow Manager. Proc. of EuroPLoP 2006

[BG:2007] Biel, B., V. Gruhn: Content Adaptation. Proc. of VikingPLoP 2007

[BGG:2008] Biel, B., T. Grill, V. Gruhn: Patterns of Trust.

Proc. of MoMM2008, 391-396, ISBN 978-1-60558-269-6

[BJK:2001] Bass, L., B.E. John, J. Kates: Achieving Usability Through Software Architecture, Technical Report CMU/SEI-2001-TR-005.

[DA:2010] Andorid Developer Guide, available online, http://developer.android.com/

[GHJV:1995] Gamma, E., R. Helm, R. Johnsson, J. Vlissides: Design Patterns: Elements of Reusable Object Oriented Software, ISBN: 0-201-63361-2

[MODPA:1996] http://www.titu.jyu.fi/modpa/index.htm (now offline, but available via the web archive

http://web.archive.org/web/*/http://www.titu.jyu.fi/modpa/index.htm) [PRS:2002] Preece, J. and Y. Rogers and H. Sharp: Interaction Design: Beyond

Human-Computer Interaction, Wiley 2nd edition, ISBN 978-0470018668.

Pattern Collection Thumbnails

Structure

Usability can be improved by the design of the presentation and the support of user-initiated and system-user-initiated interactions. Accordingly, the pattern collection is structured that following way (Figure 3).

(13)

Presentation

Responsiveness (aka User's Pace) Using applications concurrently Supporting Multiple Activities Model-View-Controller Multi-channel Access Dialog Flow Manager (DFM) Content Adaptation (CA) Server-side Content Adaptation Intermediate Content Adaptation Patterns used by

DFM and CA Device Selector

Small Screen Page Flow Client-side Multi-Screen Support User-initiated Interaction Navigating within a Single View Executing Commands Undo commands Cancelling commands Reusing Information Actions und multiple Objects (Aggregating Data) Supporting comprehensive Searching Retrieving forgotten passwords Aggregating Commands (Macros) Adaption to user preferences (User Profiles) System-initiated Interaction Feedback (Observing system State) Checking for Correctness Predicting Task Duration Context-sensitive Help Context-sensitive Interaction Tests Unobtrusive Usability Tests Specific Test Application Random UI-Event Stress Test Recovering from Failure General Architecture Mechanisms Separation Encapsulate Function Separate Data from Commands Separate Data from the View of that Data Separate Authoring from Execution Replication Replicate Commands Replicate Data

Indirection Data Indirection

Function Indirection Record Data Preemptive Scheduling Models Task Model User Model System Model

(14)

The thumbnails of the following patterns are provided in order of the taxonomy described. Some are work-in-progress-patterns, while others can be found through the list of references. Most of the patterns presented are based on architecture styles presented [BJK:2001]. The tree structure is not sufficient as it does not show all relations between the patterns, but it provides a good overview of the overall structure of the pattern language.

Patterns for Presentation

MODEL VIEW CONTROLLER (first described in [4])

How can data be presented using many different presentation styles?

Therefore: Separate the three components model (data storage), view (different ways of content presentation) and controller (management of application and presentation logic) strictly in order to enable many views of one data model.

MULTICHANNEL ACCESS (work-in-progress)

Mobile devices' capabilities range too widely to manually provide and maintain content for all of them. A web application should be accessible via each channel and present content that is tailor-made. How do you provide interpretable masks and the smaller dialog flow for different devices?

Therefore: Use a profile database to look up device properties, break up the dialog flow into a suitable number of steps and generate the masks afterwards.

MAINTAINING DEVICE INDEPENDENCE [BJK:2001]

Installing a new device may lead to conflicts with already presented devices in the system. How can a new device addes safely and conflicts be prevented?

Therefore: Use a virtual device layer that is used by the applications and accesses the devices by translating the abstracted data for the various physical devices and vice versa.

SUPPORTING INTERNATIONAL USE (aka WORKING IN AN UNFAMILIAR CONTEXT, LEVERAGING HUMAN KNOWLEDGE) [BJK:2001]

Cultures differ in many ways, not just the language, e.g. reading direction, cultural differences, even keyboard layout, encodings. How can a system be configured to

(15)

EMULATION [BJK:2001]

When interacting with new applications on a familiar platform, new versions of applications, a new product in a product line, end-users can easily make mistakes based on their habits. How can the behavior and the design of the earlier version be emulated?

Therefore: Separate the core data from the view of that data to offer multiple interfaces to facilitate the transition from one version of a product to another.

MODIFYING INTERFACES [BJK:2001]

How can user interfaces easily be modified?

Therefore: Encapsulate all user interface functionality from the core of the system, and separate application data from the view of that data.

OPERATING CONSISTENTLY ACROSS VIEWS (aka MAKING VIEWS ACCESSIBLE, SUPPORTING VISUALIZATION) [BJK:2001]

How can a system make commands available based on type and content of a user’s data instead of the current view of the data?

Therefore: Separate the data that is viewed from the view description, as well as the commands that change views.

USING APPLICATIONS CONCURRENTLY (aka VERIFYING RESOURCES) [BJK:2001] Applications can interfere with each other if the same input/output resources are used. How can shared resources used concurrently without conflict? How can an application verify that necessary resources exist before beginning an operation? Therefore: Use a resource manager that is kept separate from other applications to manage system-side resources and adjudicate conflicting requests.

SUPPORTING MULTIPLE ACTIVITIES [BJK:2001]

How can a system support users to quickly switch between applications and tasks? Therefore: Support multiple threads and allow for a robust and fast context switching.

RESPONSIVENESS (WORKING AT THE USER’S PACE [BJK:2001])

The system is designed for the use by humans. How can it present information at the user’s pace?

Therefore: Use a model of the user and the task to determine the correct pace that’s thread is distinct from the main activity thread.

(16)

Server-side solutions

DIALOG FLOW MANAGER (server-side) [BG:2006]

How do you ensure that nested dialogs can be handled in an intuitive way? For predictability, systems should be able to encapsulate complex tasks and remember how far users have come in performing a task.

Therefore: Introduce a central dialog manager that is responsible for managing the dialog flow dynamically.

SERVER-SIDE CONTENT ADAPTATION [BG:2007]

Different mobile devices have different input/output capabilities and thus require datai n different formats. To prepare content only for a few particular devices would exclude many users, and development and maintenance of the different versions would be very time-consuming. How do you adapt dynamic or static content automatically to device properties?

Therefore: Implement dynamic generation of tailored content for mobile devices by using semantic information in raw content, device profiles and according style sheets.

Solutions using Intermediates

INTERMEDIATE CONTENT ADAPTATION [BG:2007]

Different mobile devices have different input/output capabilities and thus require datain different formats. To prepare content only for a few particular devices would exclude many users, and development and maintenance of the different versions would be very time-consuming. How do you adapt dynamic or static content automatically to device properties?

Therefore: Implement a dynamic adaption of content, by using a pipeline that holds all information how content is produced in response to a request.

DEVICE SELECTOR (work-in-progress)

There are multiple mobile device types, each representing a different channel, i.e. with different output formats, interaction schemes and network connectivity. How can a system decide which kind of content it has to provide?

(17)

Therefore: Decide which content is relevant, and which is additional. Define small page flows1_{at design time, i.e. parts of a complete page flow that must or can be} presented together.

Client-side solutions

CLIENT-SIDE MULTI-SCREEN SUPPORT** (presented in this paper)

Mobile platforms run on different devices with different screen sizes and resolutions. In order to support all user interfaces, and thus usability, application developers have to write their applications to be displayed on multiple screens. How can developers design their applications for a correct display on many devices?

Therefore: Use a small number of predefined media classes and scale them to the need of the specific device.

Patterns for User-initiated Interaction

NAVIGATING WITHIN A SINGLE VIEW [BJK:2001] How can caching be supported?

Therefore: Replicate data in a cache and update the data in the cache regularly and the main data store if it is changed by the application.

SUPPORTING MULTI-LEVEL UNDO [BJK:2001]

How can operations and prior operations be undone?

Therefore: A transaction manager uses relevant data viewed as transactions sent by each component that is involved and store state information each time that an “undoable” command is processed.

CANCELLING COMMANDS [BJK:2001]

A component cannot stop itself because it is concerned with the execution of the action that the user invoked. How can it be stopped in a way that the system is in a safe state and quickly?

Therefore: Implement a Cancellation Listener that forwards the request to a Cancellation Controller that exercises a mechanism which is defined by the Activity Component itself to return to the system’s prior state.

(18)

REUSING INFORMATION [BJK:2001]

How can information be transported manually or automatically between different parts of a system?

Therefore: Provide an information reuse repository that separates information producer and information consumer.

ACTIONS ON MULTIPLE OBJECTS (AGGREGATING DATA [BJK:2001])

How can the system support users in grouping objects and applying a command to that group?

Therefore: Iteratively invoke the correct command on each object in the group. Or directly operate a command on the group.

SUPPORTING COMPREHENSIVE SEARCHING [BJK:2001]

How can systems allow users to search data in a comprehensive and consistent manner?

Therefore: Implement a search registry separated from individual applications/files which operates as an intermediary for applications requesting searches.

RETRIEVING FORGOTTEN PASSWORDS [BJK:2001]

If users forget their password, retrieving and/or changing it may be difficult or may cause security problems. How can

Therefore: Encapsulate authentication and store data encrypted.

AGGREGATING COMMANDS (MACROS) [BJK:2001]

Multi-step procedures of several commands are tedious to invoke repeatedly and error-prone. The system can allow scripting or demonstrating the new command. How can the system support users in aggregating commands?

Therefore: Implement an authoring editor that creates and stores the aggregated commands.

(19)

Patterns for System-initiated Interaction

FEEDBACK/OBSERVING SYSTEM STATE [BJK:2001]

While users need unintrusive information about the system state at all times, situations such as system errors demand more obvious system-initated interaction. How can the system decide when to take initative?

Therefore: Collect, process and present data that represents the system state and make it available to the user while monitoring usage and comparing it to a usage model to decide when the system has to take the initiative in presenting data.

CHECKING FOR CORRECTNESS [BJK:2001]

If users make an error that they do not notice, computer-aided correction can be enforced or suggested through prompts. How can the system check for correctness dynamically?

Therefore: Maintain the application data separately from the application accessible to the correctness checker which works concurrently and uses a model of the correct input and manages prompts or automatical correction.

PREDICTING TASK DURATION [BJK:2001]

Task duration depends on many different factors. How can it dynamically be estimated?

Therefore: Use a model of the task and the system to predict each tasks duration.

CONTEXT-SENSITIVE HELP [BJK:2001]

Often users need help in a certain situation. How can the system offer context sensitive help dynamically?

Therefore: Determine the context defined by the current task of the user and the current state of the system and provide the user with prepared help functionality.

UNOBTRUSIVE USABILITY TESTS

Developers should test their application without and with users to collect valuable test data. How can developers test their applications for usability on different devices at run time?

Therefore: Collect and analyze test data at run time while users interact with the application and use this to test the application.

(20)

RANDOM UI EVENT STRESS TESTS*

Developers can test their application automatically, but they cannot foresee how users will interact with the application. How can developers test their applications for usability on different devices considering unexpected usage?

Therefore, use an application that sends pseudo-random streams of user events to the system as a stress test.

SPECIFIC TEST APPLICATION*

Developers should test their application with and without users. How can developers test their applications’ specific dialogs on different devices automatically?

Therefore, write a specific test application while writing the application itself.

RECOVERING FROM FAILURE [BJK:2001]

Sudden failures that stop the system can lead to the loss of the user’s data or safety critical situations. How can a system return to the last stable state quickly?

Therefore: Each component that holds data necessary for the application to execute must record this data when the system is in a consistent state, a Checkpoint Synchronizer ensures that the checking-in of data is performed with consistent data.

Architecture Mechanisms

The following software architecture mechanisms are used within different abstraction levels – within a single application, a set of applications, or a system where these mechanisms are available to several applications.

ENCAPSULATE OF FUNCTION [BJK:2001]

One algorithm or functionality is used by several other parts of the system and should be accessible and easy to modify without changing other parts of a system.

(21)

SEPARATE DATA FROM THE VIEW OF THAT DATA [BJK:2001]

Different users have different preferences or different platforms and thus want different perspectives on a set of data.

Therefore, encapsulate the data itself (Separate Data from Commands) and maintain a description of the view of that data separate too. This description covers items such as language, filters for data items, methods for combined data items, style sheets.

SEPARATE AUTHORING FROM EXCECUTION [BJK:2001]

Authoring allows an end user to specifiy the behavior of a software system within that system, e.g., to choose settings on a menu or by using a scripting language.

Therefore, users should be able to generate new commands issued to a Command Manager that forwards them in sequence to a command processor. The commands can persist across executions of the system or only for the current execution, scheduled after termination of the current execution etc. It has to be considered that authoring takes time and effort.

REPLICATE COMMANDS/DATA [BJK:2001]

Often, performance, realiability, availability have to be improved, and alternatives for achieving a particular result are necessary.

Therfore commands and/or data can be replicated.

For data replication data in the same structure is maintained in different locations within the system, e.g., in a cache on a local storage to improve availability, or to save the system state to quicken restarting a system. The data can also be maintained in different structures, e.g., within an index to accelerate the searching process.

Commands are replicated to provide multiple user interfaces with the same functionality, e.g., remote or local user interfaces, or alternative ways for end users to achieve a functionality.

DATA INDIRECTION [BJK:2001]

Multiple data producers and data consumers have to be added or deleted to a system so that neither the data producer or the consumer is affected.

Therefore, use an intermediate component with a registration mechanism so that the coupling can be reduced: a separate component is used to distribute the data, and both the consumer and the producer of that data register at the component. The registration process can happen at design-, compile, or run-time. Both producer and consumer of the data have a direct relationship with the distribution component but not with each other. Thus, new components can be added or removed. Coupling is reduced.

(22)

FUNCTION INDIRECTION [BJK:2001]

Multiple service requests are directed at a function, and the adding or deletion of service requesting components shoud have no effect on the service provider.

Therefore, put an intermediate function between alternative methods of accomplishing a service, e.g., a virtual device, a virtual tool kit, a strategy pattern or a factory pattern. The service requester uses a single interface to interact with the function indirection component, and coupling is reduced. This component/”manager” specifically translates the received information for the chosen alternative. The binding between the service requester and the service provider can happen at design- or run-time.

RECORD DATA [BJK:2001]

Data such as the state has to be recorded periodically for later use.

Therefore, use a recording component that records data, e.g. interaction events or issued commands. Several issues depend upon a particular application, e.g. the frequency how often the state is recorded, the actual state recorded, how it is used, whether or how persistent it is, whether and how consistency of the data is addressed.

PREEMPTIVE SCHEDULING [BJK:2001]

Activities must appear simultaneous to users.

Therefore, use preemptive scheduling. Resources such as memory, central processing unit, input/output periphal access, queues, are assigned to activities withing a computer system by scheduling. Scheduling strategies are preemptive (resource is used alternatively in certain time slots) and non-preemptive (resource is kept until it is yielded by the resource). Preemptive scheduling allows multiple simultaneous activities. A thread is a logical sequence of activities within a computer system, and can be active or blocked. Preemptive scheduling is allowed by having multiple threads that access a resource alternatively at tiny time scales. For example, a separate thread can be used to monitor user’s actions and to determine the correct moment to present data or update the data currently displayed.