How We Test Expandability

ANALYZING THE CURRENT NOMINAL TASKS of a person using a trading tool is one way to decide what such a tool should do. Such a limited approach, satisfies the base needs of the user and gets the trading tool out to the door to the end user. However, this approach leaves unanswered the question: "What will a user want to do with the system once he gets it installed and has become comfortable with the base features?" Our testers carefully consider this last question when evaluating a trading tool and rate rate it accordingly. Why? Products which elegantly anticipate user's future needs are more popular and can sell better because they satisfy better.

We believe there are 16 typical ways a user may want to expand any feature of a product. These ways group into three major categories:

1. expanding the number of objects to which a feature is applied
2. integrating with other system or environment facilities
3. modifying the way the product carries out instructions

Below are the categories with their respective subparts. Illustrative examples, using the notion of a command sequence (often called a "macro") are also given.

1) Expanding the number of objects

• using more than one instance of a feature - e.g. using one indicator in more than one program at a time alternating back and forth between them all, using an indicator in more than one screen, instrument or time frame at a time
• reusing a facility - e.g. being able to cut and paste a section/snippet of indicator parameter lists into a new instance of an indicator
• inclusion in a larger goal - e.g. using the tool on a weeks collection of trades rather than just the trades of one instrument

2.) Integrating with other system facilities

• interleaving with other goals - e.g. the indicators which are highlighted change as appropriate to whichever window has focus
• taking advantage of other goals - e.g. an indicator which determines that optional facilities are currently available because a prior indicator has been loaded by a previous context
• ability to stop or postpone - e.g. stop input to the trading screen from an external source (data feed, historical data base) that is clearly going awry or postpone/suspend completion of such input in order to switch to another task
• get result - e.g. get a result from one indicator in order to determine the next activity to be done, i.e. ability to use the indicator's internal values without plotting the indicator
• external activation - e.g. allow another separate program or product to activate the capabilities of the product under use in order to get the product under use output for its own use

3. Modifying the way the product carries out instructions

• progress monitoring - e.g. user may wish to know or change whether the product is treating the current keyboard input as a command, a shortcut, text, noise, or is idling and if the product changes its mind about that evaluation
• result detection - e.g. the user may wish to optionally know whether the last series of rapidly entered commands were actually received as intended
• rolling back to a previous state - e.g. the user may wish to undo the window context switch implied by a keystroke or shortcut or other input (to any depth)
• recording and retrieving - e.g. the user may wish to retrieve the last few commands for use as a self contained sequence for use in a new context thus also implying some recording mechanism for those commands and a companion searching mechanism for those selected commands
• modifying outcomes - e.g. a user might wish to modify an otherwise successful series of previous input commands in order to get a new result
• modifying for multiple similar outcomes - e.g. a way to target multiple contexts with the same command sequence each context being differentiated by one or more additional keystrokes or phrases which select the next context; also a companion enumeration facility to display various instances of the more general sequence - i.e. do the same thing on tbonds that the trader just did on e-minis.

The examples above given for each of the general expandability principles are not contained in entirety in any current product although some are features contained in some products. They are in no way whatsoever the full range of reasonable expandability possibilities. Nor should the examples above be taken as our complete prescription for the perfect trading tool. They are examples given to illustrate how a tester (or designer, for that matter) may use the principles to anticipate user attempts to search for increased productivity.

It's crucial to distinguish between simply adding product features and our goal. Casual adding of new product features often results in bloatware. Our expandability analysis is designed to increase the utility within the work environment of existing product features by careful polishing of those features in limited ways which align with the above principles.

If you have applications under development and wish to have an analysis performed along these lines please contact us.

More on bug testing...
More on usability...

Reference: Goal Composition by Jakob Nielsen