Interactive Header and Input Using - the purist view!

Discussions on the future of databases, computing , the meaning of life ........

Moderators: Phil Winkler, Graham Smith, Pete Tabord

Interactive Header and Input Using - the purist view!

Postby Pete Tabord » Mon Feb 18, 2008 1:41 pm

Hi All

Those of you who have been with me for the long ride will know I have a somewhat ambivalent attitude to these two features.

I will attempt to explain.

Both of them seem to me an entirely wrong-headed approach to somehow make it 'easy' to get parameters into procedures. D-E/Interactive Headers being the worse of the two conceptually, but IU has some problems too.

The confusion seems to me to arise from the mistaken idea that parameters used for running a report are somehow not 'data'. Of course they are, and the very fact that people want to print out the information so entered on reports etc. proves the point. This mistake has led to a design that is driven from the procedure rather than from the data, which is the 'wrong way round' and incompatible with our generally data driven design.

So entering data that was to be used as parameters or even whole record input for a procedure _should_ have been done in the same basic way as entering data anywhere else, e.g. via and into a proper genuine form. The correct design would have been to have a flag on the form (and the aspect, so a form could be used in several ways) which said 'run this procedure using this record and any sub-form records when data is entered to the form' - something like Adrian's use of Open Related.

Of course the record might be a single parameter, or dozens of main and sub-form fields.

The procedure would be able to know who entered the data by examining the 'current' variables.

Other flags and current variables could be added, like current key press and a 'delete this form's record after processing' flag.

If that had been done the whole area of interactive headers, input using, and all the special processing and odd exceptions they involve could have been avoided, and while the effort to implement such a feature might have been considerable surely it would have been far less than all the effort that has been expended on the limited functionality of D-E and IU.

I unfortunately now have relatively limited resources and a design 'legacy' that prevents this clean solution, but this is the way forward that I see when I do have the resources to implement such a thing. In the meantime I'm forced to expend precious effort on things that while necessary at the moment are really limitations rather than opportunities.

You can of course help reach this desirable goal (if of course you think it desirable :) ) by buying more product so I can hire more programmers!

Regards
Peter J. Tabord
Head of Development
Database Software Ltd.
ptabord@ffenics.com
Pete Tabord
 
Posts: 1881
Joined: Fri Sep 07, 2007 12:48 pm
Location: Caernarfon, Gwynedd, UK
Has thanked: 0 time
Been thanked: 3 times
 

Postby John Middleton » Wed Feb 20, 2008 3:44 pm

Pete

I think I read somewhere that Ffenics is written under VS and therefore I wonder, by applying a little lateral thinking (maybe too lateral) how much of job it would be to add either the standard MS Report Viewer or Crystal Reports Runtime to Ffenics?

Both these two products will fish for report parameters that are derived from the Windows System or solely from the current ‘form’. Neither necessarily has to be data connected. Neither requires the .Net framework and would provide the added bonus of alternative exporting.

John
ShopEase
John Middleton
 
Posts: 110
Joined: Mon Sep 10, 2007 3:14 pm
Location: England
Has thanked: 0 time
Been thanked: 1 time
 

Postby Graham Smith » Wed Feb 20, 2008 5:06 pm

Actually, I think that this whole discussion has devolved away from where it should be going. It's stuck on which of several different roads to take when it's not entirely clear what the destination is. I think that we would all be well served if we changed the perspective somewhat.

As an example, one of the most common thing users want is to run a report for a range of dates and to have that date range appear in the header so that anyone looking at the printed report will know what it is based on. It doesn’t really matter how the range of dates is supplied or how it gets into the header as long as it is simple and straightforward.

Pete is absolutely correct when he says that people are trying to use InteractiveHeaders for much more than they ever should have been used for in the first place. But they are a simple way to present the user with a “dialog boxâ€
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 

Postby FfRob » Wed Feb 20, 2008 8:40 pm

People look at the header to answer a fairly obvious question, which is :

What am I looking at?

So that's where you should put D-E parameters, heading, date, etc.
FfRob
 
Posts: 50
Joined: Thu Jan 17, 2008 1:15 am
Has thanked: 0 time
Been thanked: 0 time
 

Postby Graham Smith » Wed Feb 20, 2008 9:08 pm

FfRob wrote:So that's where you should put D-E parameters, heading, date, etc.


Because that's the way you've always done it? That's half the reason why we are having this discussion. Who says that these fields have to go in the header of every page? I've gotten used to doing it that way, but have seen apps where that information only appears at the start of the report that were just as usable. I've seen apps where that was not there at all as the parameters were self evident by looking at the data.

The point I'm trying to make is that if we all assume that the way we have always done something is the ONLY way or the BEST way, then that excludes alternatives that may be even better. For example, I've found a number of cases where no printed report is necessary at all, that there are ways to use Aspects to display the data to the screen that work better for the end user and save paper to boot.
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 

Postby FfRob » Thu Feb 21, 2008 4:41 am

Graham,

How does the end-user benefit by NOT having the parameters in the header?
You may produce a usable report by putting the parameters in the body or the end but it is not a better report. The software should be adapted to user needs and expectations. And it's not unreasonable to see certain things in the header.
FfRob
 
Posts: 50
Joined: Thu Jan 17, 2008 1:15 am
Has thanked: 0 time
Been thanked: 0 time
 

Postby Mark Nicholas » Thu Feb 21, 2008 9:13 am

FfRob wrote:The software should be adapted to user needs and expectations.


The software as shipped _can_ be adapted to user needs and expectations. In my view, 'adapting' it is up to the Developer who creates/maintains Applications.

There are Developers out there with varying levels of experience/expertise. A great number of them will have read articles in Dialogue Magazine (where Adrian Jones' articles are of particular interest), researched FAQ on the web or joined discussion groups, or simply learned on the job via input from colleagues.

All those that have done that should be able to get the Report's Selection Criteria onto the Header of every page.

Whether the methods are 'intuitive' or not is another matter.

Whether it is necessary or not (as Graham so rightly points out) is yet another matter.

But basically it _can_ be done (without the Database City team having to make any changes to the product as shipped).
Mark Nicholas
Mark Nicholas
 
Posts: 120
Joined: Wed Sep 12, 2007 6:56 am
Location: London , UK
Has thanked: 0 time
Been thanked: 1 time
 

Postby Pete Tabord » Thu Feb 21, 2008 9:34 am

Hi all

I didn't mean this thread to be on 'how it is done now', rather 'how it should be done'. 'How it is done now' - well, there are nearly as many solutions as developers...

I don't like Crystal Reports. And it would seem its future is dubious, to the say the least.

I do like DE/Ff - I wouldn't have staked my career and financial well-being on it otherwise. Even as it was in DE6 it can do things other tools like Crystal can only pretend to do, although the method to do so is not always obvious.

This business of feeding parameters - i.e. data - to procedures is one area where it has deviated from its basic design approach and that seems to be a mistake that has lead to a clunky user experience. I can make it work considerably better as it is, but I also think that my suggestion above of making the form drive the procedure instead of the other way round is the real long term solution.

Regards
Peter J. Tabord
Head of Development
Database Software Ltd.
ptabord@ffenics.com
Pete Tabord
 
Posts: 1881
Joined: Fri Sep 07, 2007 12:48 pm
Location: Caernarfon, Gwynedd, UK
Has thanked: 0 time
Been thanked: 3 times
 

Postby Graham Smith » Thu Feb 21, 2008 2:21 pm

FfRob wrote:How does the end-user benefit by NOT having the parameters in the header?


Because you are assuming, as many people do, that this information needs to go at the top of every single page of a report - and that is simply a false assumption.

As an analogy, have you ever been to a web page that has a "spider"? A little box that floats and stays on the page even as you scroll down? Advertisers love these because they keep the ad present on the page in a way that is almost impossible to ignore. But do we really need to do this on a report?

<on soapbox>

If you begin with the assumption that the end user does not need to be constantly reminded of the selection criteria, then you are free to start thinking about different ways of approaching things. I'm so much in the habit of putting these fields in the header (i.e. PageHeader or SummaryHeader) that I often forget that myself. But as you have seen from the demo app, that is not the only way to do things.

The whole point is that as long as we remain wedded to the the way we have always done things, we'll never find new (and possibly better) ways of doing things. It's not that data-entry fields in Headers is a BAD thing, it's just that they are not the only (or even the best) approach all the time.

Live a little. Try new things. The Ffenics community and the product itself will only benefit from users trying new things and finding new ways to use it. It will only suffer from trying to remake it into something from the past.

<off soapbox>
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 

Postby FfRob » Thu Feb 21, 2008 2:27 pm

This product is targeted towards end-users who are not developers. They need something easy and simple to run their companies. They have little or no interest in computers.They need a report yesterday to make a business decision. They're not going to be researching on the internet. Maybe one in twenty would make that effort.

How should it be done?
Let me suggest this just off the top of my head- separate windows for:
Data entry form (because this is critical to the report/proc it belongs there)
Header
Body
Footer
List of Data Sources where you can see all available fields
Script

The ability to drag and drop from one window to another so that you could create a data-entry field in the form and then drag it into the header or somewhere else.
FfRob
 
Posts: 50
Joined: Thu Jan 17, 2008 1:15 am
Has thanked: 0 time
Been thanked: 0 time
 

Postby Pete Tabord » Thu Feb 21, 2008 4:33 pm

FfRob

Why do you think a data entry form (if such a thing existed in Ffenics or DFW - which it doesn't) should be different to a normal form - i.e. forms for entering data?

Is it not a purely artificial difference brought about by a quirk of design in DFD?

It seems to me it is those differences that make the situation confusing - because it isn't a proper form it in turn does not contain proper fully specified fields and so they can't be dragged and dropped etc. etc.

Regards
Peter J. Tabord
Head of Development
Database Software Ltd.
ptabord@ffenics.com
Pete Tabord
 
Posts: 1881
Joined: Fri Sep 07, 2007 12:48 pm
Location: Caernarfon, Gwynedd, UK
Has thanked: 0 time
Been thanked: 3 times
 

Postby FfRob » Thu Feb 21, 2008 10:25 pm

Forms are for persistent data. Data-entry forms are for setting initial and final conditions (or selection conditions) for a report or procedure. They are a visual extension of the control structure of the procedure. A giant visual IF-statement that a user can easily manipulate. Data-entry fields have very little meaning when separated from the procedure. And little meaning over time. You might want to save them for an audit trail - who ran what and when - but how often is that significant?
FfRob
 
Posts: 50
Joined: Thu Jan 17, 2008 1:15 am
Has thanked: 0 time
Been thanked: 0 time
 

Postby Pete Tabord » Fri Feb 22, 2008 10:18 am

But what you are all asking for is the ability to process the data - not merely when it is entered but for every page of a report. This means the data has to be stored rather than just fed in as an argument to an algorithm - it makes no difference to the program whether you intend to store it for 20 milliseconds or 20 years.

Furthermore, on a Windows machine where reports are spooled and actual page breaks are not known until the report is sent to the printer (or more accurately the printer driver), the data has to be stored in more than one place so that it is available for the headers and footers when they are generated. i.e we have to put all data in the report without knowing when or whether it is going to be summarized.

Which is why if you put an ordinary field on a header you get the next value - its just what happens to be available to the print driver when its asked to print that field. You can't control it, unlike summary variables, which are actually calculated when the report is printing, not when the data is extracted and processed. But of course if the relevant data was not output to the report in the first place, then the summary variable can't summarise it.

This is entirely different to outputting a report on a DOS machine where all formatting is done by the program and data can be supplied direct from the database or the internal statistical accumulators as required.

What I am saying is that if you want to store and process the data , no matter how briefly, why not have a proper form define that storage even if you do not keep the data after the report has run. Then we have no issues with special processing and quirky restrictions.

If all you want to do is control an IF statement than that is already supported.
Peter J. Tabord
Head of Development
Database Software Ltd.
ptabord@ffenics.com
Pete Tabord
 
Posts: 1881
Joined: Fri Sep 07, 2007 12:48 pm
Location: Caernarfon, Gwynedd, UK
Has thanked: 0 time
Been thanked: 3 times
 

Postby Graham Smith » Fri Feb 22, 2008 1:54 pm

FfRob wrote:Forms are for persistent data.


Why? Who says? I use forms as transient holder files all the time in DFD, DFW, Ffenics, and SQL. I hate to sound like a broken record but from the moment DFD was released, it has been an uphill battle to get people to give up old notions.

dBase users didn't understand DFD and tried to use it like they would dBase - they failed.
The introduction of subforms in DFD changed the product in radical ways but there are still apps out there that don't use them.
Express came along and was met with apathy because it didn't have DQL.
DFW came along and encountered resistance from DFD users because they had to learn new ways and many are still stuck in the past.
Now we have Ffenics and still face many of the same issues.

It's like buying a new automobile then trying to figure out how to hook up the horses to pull it.

Since this is a philosophical discussion, I'd like to go on record as being in favor of ripping DQL out of Ffenics and putting something more appropriate in it's place. I was one of the first people to push for it to be included in DFW and one of the reluctant first to admit I was wrong and it was a bad idea.

But that ain't gonna happen any time soon so instead, I want to find other better ways of doing things. And that most definitely includes me getting my head into a different position. Old habits die hard, but die they must.
Graham Smith
DataSmith, Delaware
"For every expert there is an equal and opposite expert.", Arthur C. Clarke (1917 - 2008)
"X-Clacks-Overhead: GNU Terry Pratchett"
User avatar
Graham Smith
 
Posts: 2501
Joined: Fri Sep 07, 2007 11:31 am
Location: Delaware, USA
Has thanked: 0 time
Been thanked: 1 time
 

Postby FfRob » Fri Feb 22, 2008 5:05 pm

The D-E data is stored in memory as soon as you enter it. It's there at the beginning of the report and it's unchanged until the end. When the report is closed, the data is flushed. I don't see any reason to involve an RDBMS in that process. It's like using a sledgehammer to drive a tack.
FfRob
 
Posts: 50
Joined: Thu Jan 17, 2008 1:15 am
Has thanked: 0 time
Been thanked: 0 time
 
 
Next

Return to Philosophical Discussions

Who is online

Users browsing this forum: No registered users and 2 guests

cron