Nuptuals for the pvPlayer & Excel

This is a menu of the topics on this page (click on any):

• We need Excel for rapid application development   
• How we'll use Excel   
• What we'll expect of the user
  • The unskilled user   
  • The skilled user   
• Simplifying design constraints   
• old notes (possibly no longer useful)   .

We need Excel for rapid application development

Completing an application is hard work. Reducing system errors as much as possible and providing error control for those that remain or that occur under some fringe condition is very painstaking work. That and providing an effective user interface is likely to be as much work as to achieve the basic functionality in APL. Whatever flaws remain are might be very serious for the user, including the loss of current work whenever an error is encountered and the user faces a unretrievable error message and then the application goes away.

Using Excel as the user interface offers a compelling advantage. When an APL error is encountered, one simply can't complete the desired operation, but no previous work is lost, the screen remains, and it is possible that useful work has been done. This might mean that Excel has an important place in the life cycle of a product for getting started provided that Excel can be used in a way that translates well to the later APL front end. The remainder of this page is to set the stage for discussing how this might be done.

How we'll use Excel

Suppose we were to design an application with the "Plain Vanilla" (Phoenix) approach whereby programming is done by writing specs which compilers then render in whatever environment is desired. This might mean that a general purpose front end might be written using Excel that could be quickly put to work and that might be later replaced with an APL gui.

What we'll expect of the user

The unskilled user

The product appears as an Excel spreadsheet. The unskilled user must be sufficient power and ease in the application so that effective work can be done.

The skilled user

An immense amount of customizing and decorative or documentary work can be done by the user who has Excel skills.

Simplifying design constraints

1. Worksheets are like APL child forms which are like 2 dimensional APL arrays. All start at the upper left corner (providing for buttons or offsets as needed). Complexity shows up as multiple worksheets and multiple inter-related forms. This is precisely the Phoenix approach.
2. Any mapping that is necessary is done under program control, not by a programmer or installer.

old notes (possibly no longer useful)

All report creation takes place in APL with a combination of our 50 or 100 generic report formats plus our not yet designed user operable generalized report utility. APL will render the desired format in Excel just like we are doing it with Phoenix & the APL grid control now. APL will build the links between APL & Excel. The user will have a fully operable form (multiple sheets) in Excel but he cannot change the format in Excel (except he can add/subtract sheets selecting from our 50-100 or his/her own). Changing the Excel format can only be done by changing the specs in APL and regenerating the Excel formats. But he/she can do all the data changing he/she wants in Excel and see model results displayed in Excel.

---

I'm beginning to see daylight on the CDBG project and thinking about what we'll do with it. I has similarities with the imgdb project. It is about that scale and the interactive nature of the form is about that complicated. In other words, the power we'll give the user is fairly limited. But, of course, the power of imgdb was also fairly limited. I thought imgdb was pretty wonderful, but among the several people who tried it some had trouble. (possibly due to bad configurations in their computers) We don't have room for trouble with CDBG customers. So, I'm thinking we sell the data but give the software away. In a sales call, I'll use the software very importantly, but I don't want to count on it for users in the near future. The most important thing the CDBG work will do is give us funding for real estate work. That's where software development is really important. So, I'm thinking we might want to use Excel as our front end for the CDBG product. Please read the attached and let me know what you think.

Comments by Davin 3/27/04 7:45 pm:

Interfacing APL & Excel will be useful when (a) we're not doing much work beyond retrieving data & handing it off to the user, and (b) when the user will want to rearrange & decorate his own output. Error handling/control is more difficult/limited (if anything) in the (combined) Excel environment -- it doesn't really provide much real benefit. Presenting a fancy user interface is more difficult in Excel than APL (assuming you want to present such an interface). Coding to just hand back raw data is about as easy in Excel as with Phoenix grids.

Providing a nice user interface, in *any* language, typically requires between 75% and 95% of the total coding time, the other 5%-25% being base computational functionality and similar tasks. It's also one of the most important things to the user, so it shouldn't be ignored or given only half-hearted attempts if you want your software to be taken seriously. Converting an Excel front-end to an APL front-end isn't significantly easier than just writing the APL front-end in the first place, and is quite a bit more difficult when you add together writing the front-end in Excel first plus converting it to APL afterwards. (And I'm not just talking about re-using generic form specifications -- the little mechanical details to make all this work swamps that amount of effort.)

There are three good ways to interface APL & Excel -- the choice should be determined mostly by how you want it to behave:

1) Excel is the controlling application, and APL is called under the covers as a subroutine to perform data retrieval and complex calculations. (Usually requires an initial spreadsheet with macros to set up the interaction.)

2) APL is the controlling application, and it starts a visible copy of Excel for user interaction but does all its own calculations and interface monitoring (not a particularly trivial task, BTW). (It's also dangerous if there's another copy of Excel already running.)

3) APL is run as a standalone application, with a simple interface to request retrieval of selected data. This data is then written directly to a native Excel file and APL is shut down (or left running for further requests). That file can then be manually brought up and edited by a standalone Excel application at the behest of the user, in the same way they're used to working with any other Excel file. (As a bonus, APL could bring up that first Excel editing session for them, but it would still be an independent Excel application and would not be talking to APL at all.) This is the simplest and most error-free option, though it doesn't give them a fancy (intelligently moderated) interface of any sort.

Davin