The Interpretation of Dreams: John Weinshel and Russ Kohn

When should the computer make a decision and when should the user? The business rules around propagating changes* in a complex system, for instance, can become so subtle as to best be left to humans. But when is that point reached? Or, how we choose between tightly defined validation at the field level, fully locked down dev efforts, and in implementations that, say, allow nearly anything to be entered and then validate at various milestones, and on different types of milestones such as order status promotion vs pre reporting? And how do we reconcile the reality that our system implementations are increasingly deployed multi-platform (FMP client, Web, mobile) with differing technical capabilities.
The common ground here is, how do we approach these issues internally from a technical perspective. More critically, how do we listen to the client and then do our job: finding the right balance between protecting and enabling them? Some developers prefer to tightly lock down the system and then back off, as the client asks for more control, sort of like tuning a stringed instrument down a hair too far and then bringing it back up to the desired pitch.
But what does a lock-down system look like in a iOS, Web and FMP Client deployment? How do we deal with client pushback ("Why can't I just change the invoice amount?"). How do we handle data quality issues? When should we let FileMaker Be FileMaker and when do we impose more control? John and Russ will briefly present a couple of case studies that illustrate these issues, both from a user interface and data architecture perspective, and then turn to the room for ideas.

While the FileMaker development techniques are not terribly complex, the larger issues of data quality, process control and balance between letting FileMaker be FileMaker and locking processes down is subtle. In this discussion we hope to advance our collective understanding in how to think about these issues as developers, and how to discuss them with our customers.

*'Propagating changes' here means 'how do you handle a change made in one place that may affect other things, both upstream, downstream, and sideways?'