Task-Centered User Interface Design
A Practical Introduction |
by
Clayton Lewis
and
John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book. |
Contents | | Foreword | | ProcessUsers&Tasks | | Design | | Inspections | | User-testing | | Tools | | Documentation | |
3.2 Making Use of Existing Applications
The next copying you ought to do is to find good existing applications that already provide some of the functionality you need and plan to incorporate those applications into your system. Do users need some database capabilities, and some ability to do calculations of the data they are dealing with in your application? They almost always do. You will not be able to develop your own Dbase, or your own Excel, that will be nearly as good, or as powerful, as existing products that have been shaped by intense and extended competition in the commercial market. Even if you could you and your users are still behind: many of them already know how to use Excel, and they gain nothing by having to learn about your version of a spreadsheet instead.
Suppose you want to do financial projections, such as you might do with a spreadsheet, but you need to represent uncertainty in the numbers you use: next year's sales should be somewhere around $1.5M, but they could be as low as about $1M or as high as $2M. Costs should be around $1.2M, but they could be as high as $1.4M or as low as $1M. So what's the gross profit picture for next year? You could use a regular spreadsheet by running various what-if's with different numbers, but if you have a few more parameters that gets tedious and error-prone. And suppose you think that sales and costs are probably correlated? Monte Carlo simulation is a modelling technique that lets you specify statistical distributions for parameters, and correlations between them, and estimates the distribution for resulting quantities by sampling from the distributions you provide.
Suppose you wanted to sell a Monte Carlo tool to the business world. You could try to build your own system from the ground up, but you'd be wrong. The right thing to do, as Crystal Ball and @Risk have done, is to build and sell a spreadsheet add-on. Modern spreadsheets, and the systems in which they run, permit fairly easy communication between the spreadsheet and your code. This is a huge win, for the following reasons: - The spreadsheet provides for you many functions which you would otherwise have to implement yourself, including data entry and specification of computations in the model. - It provides these functions in a form many users already understand. In fact the same add-on can be made to work with more than one of the popular spreadsheets, so users can choose whichever spreadsheet they already know most about. - The spreadsheet provides many functions that aren't part of what you HAVE TO do in your application but are significant enhancements that you get for nothing. For example, modern spreadsheets offer a wide range of graphical presentations of data. - Chances are users will want to transfer data between your package and their spreadsheet anyway. That'll be much easier with the add-on than if you build a separate package. - The spreadsheet can handle most if not all of the various environmental dependencies for you, such as drivers for various kinds of displays and printers. There is no way that you could afford to put as much coverage of environment options into your package as the spreadsheet developers, with their huge market, can afford to put in theirs.
Copyright © 1993,1994 Lewis & Rieman |
Contents | | Foreword | | ProcessUsers&Tasks | | Design | | Inspections | | User-testing | | Tools | | Documentation | |