[portland] Meeting, Tomorrow! (Tues, Oct 9th, 7pm, CubeSpace)
freyley at gmail.com
Mon Oct 8 20:43:06 CEST 2007
On 10/8/07, Rich Shepard <rshepard at appl-ecosys.com> wrote:
> On Mon, 8 Oct 2007, kirby urner wrote:
> > Operators won't get bogus data past this gatekeeper, if everything's coded
> > "air tightly".
> Unfortunately, they will.
> Perhaps a valid analogy is that of statistical software. There is knowing
> how to operate the software, and there is knowing what statistical tests are
> appropriate for use in any given situation. Using the wrong tests will work,
> but give invalid answers. I've seen this done when, for example, consultants
> use multiple t-tests rather than ANOVA (Analysis of Variance). Our
> application is like that. If you put in inappropriate data you'll generate
> an answer, but it won't be the correct answer.
It's always seemed to be that, in cases like this, there are two
1) The Disclaimer
2) The Flowchart
The second one is an attempt I've occasionally seen to capture the
information you're talking about, the "which part of this app should I
use?" information in the app itself in the form of a flowchart.
Sometimes called a wizard, sometimes horribly awful, this kind of
thing can be incredibly useful if some of the ways of using the app
can be clearly described and then tests can be built, human tests
asked of the user, that parachute the user into the part of the app
that makes sense for what they're doing.
I'll happily make a ReportLab piece of paper. You might consider
asking for an MVC+wxPython group at some point.
More information about the Portland