A design philosophy question

How would you design a complex multi-panel display?

Let's take, for example, an order entry display.  There's a screen for the
ship-to information, a screen for notes, a screen for order header
information, a screen for order detail, a screen for shipment detail.

It seems to me there are a number of possibilities:

1. One really big display file handles by one really big program
2. Separate programs, each with its own display file, run by a driver
program
3. Separate modules, each with its own display file, called using bound
calls from a driver program
4. Separate modules, each with its own display file, in a service program,
called from a driver program

Option one is bad, for all the reasons we've come to know and hate over the
years - maintenance, modularity, and so on.  So that leaves the other
options.  What are the opros and cons of having a display file in a module?
And what are the tradeoffs between having such a module bound or in a
service program?

I'm not looking for a definitive "right" answer here; my guess is that "it
depends".  But I'd like to have a little discussion on the matter.  I guess
that's becase I'm at option two today, and very comfortable with it, but I
know that I'd get at least one benefit from a bound approach: fewer objects
to manage, especially in the production environment.  That goes away a
little if I move to a service program approach, but then maintenance is a
bit easier.

So, please, I'd be interested to hear what you think.  Any comments about AG
usage in this scenario would be appreciated as well.

Joe