Dynamic Reports for users

[Johhhn]

Is there an easy (or doable) way to allow users to create report layouts, but actually never use Layout mode? The users will probably create many one time reports and the layout mode is not an option.

Kind of like a custom merge letter, but for reports.

thanks!

[Johhhn]

OK, I figured out how to do it on a per layout basis, but any idea how to do it on a per record basis?

IE, a report table with each record being a 'report layout' ??

[AudioFreak]

Why a layout for each record, and how many records are we talking here?

If it's some kind of letter for a one time print, why not just use a global field to let each user input something? Or a regular field if you want to store and save what was printed.

More info would help us give you an accurate answer as to what you are doing. Or maybe a sample file of where you are at now.

Michael

[Johhhn]

Sorry for being vague, and thank you for responding.

Basically, users generating reports will happen quite often, and these reports can vary.

Table: Contacts

Fields: first name, last name, phone, zip, address, etc..

User may want to create a report that shows the following fields for the Contacts: last name, phone, zip.. and then the next day they may only want to show last name, phone, zip, and gender.

and so on and so on.. some of these reports (lists) may be used more than once, hence, why it'd be nice to be able to 'save' them.

And giving them access to Layout mode to create hundreds of reports is not an option (it's what we're leaving!)

[AudioFreak]

Since you seem to be the one developing this file for your company, I would suggest sitting down with the employees there and figuring out how many different reports are needed and what needs to be on them.

Then you can set up a few layouts that display the fields needed for that specific report. I think hundreds of different reports for a contact file seems a bit insane IMHO.

Once you have a few layouts(Report Templates) set up then you can make a script that goes to the specific layout that has the fields needed for the report.

But first you need to figure out how many different reports your company actually needs and what data needs to be on them.

FWIW where I work we have 33 files(tables)and I'm going to guess that there may be 60 report pages in all.

Michael

[Vaughan]

I agree with Michael: talk to the users and put a limit to the options.

I'd call these lists rather than reports because information isn't being summarised. Either way, reports have to do multiple jobs and usually have "extra" information on them that a particular person might not need, to make them useful for many people. Otherwise they can export the data to Excel and delete the columns they don't want.

Otherwise it gets massively out of control.

[bcooney]

There is an interesting technique for "customized" list reports in Scott Love and Steve Lane's Special Edition: Using FM8. If I recall, it uses globals to let the user "pick" the columns to include on the list report.

Given that, I second the advice that really, there is just so many reports necessary, and you probably could come up just a few to pls everyone. I also want to point out that I've seen clients request printed reports when they aren't necessary. They really don't need the printout, they are just used to getting one from the previous system. Often training them on list views, sorting and finding reduced the need for so many "customized" reports.

[Johhhn]

I agree with Michael: talk to the users and put a limit to the options.

I'd call these lists rather than reports because information isn't being summarised. Either way, reports have to do multiple jobs and usually have "extra" information on them that a particular person might not need, to make them useful for many people. Otherwise they can export the data to Excel and delete the columns they don't want.

Otherwise it gets massively out of control.

Yes, they are lists, but they can also be reports.

As far as everyone advising telling my client 'not' to do this or that,, that's all nice and good, but in the 'real' world, it's entirely up to the client as to what they want to do.

I've been using the global thing, and it's working great.. for now.

My philosophy is to give me clients what they want. If they want to be able to create a list of x y and l criteria one day and then another with x b and c, then so be it. It's not my job to tell them 'no'. They'll simply go back to their flat file database and and wonder why they are even paying me to upgrade it.

Within reason, I believe it's important to cater to a user's need,,, however, it *is* my duty to let them know that I think it's crazy to have a billion layouts laying around, but, if I can develop a solution to minimize all of it and allow the same flexibility, then it's only a win win situation.

There is an interesting technique for "customized" list reports in Scott Love and Steve Lane's Special Edition: Using FM8. If I recall, it uses globals to let the user "pick" the columns to include on the list report.

Given that, I second the advice that really, there is just so many reports necessary, and you probably could come up just a few to pls everyone. I also want to point out that I've seen clients request printed reports when they aren't necessary. They really don't need the printout, they are just used to getting one from the previous system. Often training them on list views, sorting and finding reduced the need for so many "customized" reports.

[comment]

I am not sure what exactly this "global thing" means, but if you're using global fields to indicate which field data goes into which column, you could replace them with related fields from a Templates table. Use only a single global field to select the current template.

[LaRetta]

As far as everyone advising telling my client 'not' to do this or that,, that's all nice and good, but in the 'real' world, it's entirely up to the client as to what they want to do.

Believe it or not, we design in the real world. How well would it work if the client told a doctor when to operate and how to operate? Would any smart doctor allow the client to make the decision for them? Nope. There is no difference here ... people pay for expertise which they lack. The 'real world' works very well under this philosophy.

LaRetta

[Vaughan]

Let me give you a perfect example.

I recently took over a database development job. It's in-house, but it was started by an external contractor. The client had given the contractor a report mock-up done in Excel (created by a third staff member) and told the contractor to make it. The contractor is a great guy who always gives the client what they want.

I received the job supposedly after the contractor had done all of the design ground work: he told me that it'd require a "reports" table and complex, multiple imports from the basic data to get the info into the necessary shape to create the reports. He added that the clients aren't really sure what they want.

I spent about two weeks going through this report with the client, trying to work out the basic data structure. (I believe that if the data structure is right then reports should come easily: any difficulty means the data structure is wrong.) Finally at the end I was confused and frustrated, despite the fact that the client was excellent. I figured that somewhere there was a "divide by zero".

So I spent a day looking at the mock-up report. It would have made Escher proud: despite the fact that it looked OK on paper, it simply could not be built. Columns and rows were confused. Categories were mixed and in some places were even recursive!

So instead of creating a convoluted system to try to create this confused report, I re-designed the report in Excel and discussed it with the client. They were thrilled and could see the new clarity in my design.

From this new report we were were able to re-caterogise the data, build up a coherent structure of the information they wanted to report on (this also involved some business process introspection on their part). Once this was done, creating an efficient data structure was a snap. The *correct* data structure made everything so much easier.

So in the real world, clients can often ask for something that can't be done.

[Johhhn]

I don't understand the confusion here.

Perhaps I wasn't clear when I wrote "Within reason, I believe it's important to cater to a user's need,,, however, it *is* my duty to let them know that I think it's crazy to have a billion layouts laying around, but, if I can develop a solution to minimize all of it and allow the same flexibility, then it's only a win win situation."

This would definitely apply to your situation, Vaughan.

And as far as people 'paying' for expertise,, you're exactly right, LaRetta! But, this isn't open heart surgery, nor is it brain surgery, it's FileMaker! And *no one* is telling *me* what to do, when or how, etc. Perhaps my phrase was confusing, that's quite understandable.. sometime I write like how I talk (very fast!) My point was that if a client wants to do xyz and I tell them *NO*, as many of you apparently do, then, depending upon the individual(s), they may simply go elsewhere or do it themselves.

I feel it's important to *educate* the client and then explore options for their problem. Hence, why I am here and now having this discussion with those of you that believe otherwise.

[Vaughan]

"But, this isn't open heart surgery, nor is it brain surgery, it's FileMaker!"

Sure, FileMaker is easy to use. So are a hammer and nails. But it's a stretch to go from showing somebody how to drive a nail to them then building a house.

FileMaker's ease of use hides the fact that designing databases requires knowledge and expertise. Regardless of the software it's going to be developed in, a database needs to be designed correctly. I'm particularly interested in data design and interface design myself.

"My point was that if a client wants to do xyz and I tell them *NO*, as many of you apparently do, then, depending upon the individual(s), they may simply go elsewhere or do it themselves."

There is always some developer that will underestimate a project's complexity and undercut on price. Clients *always* underestimate project complexity, because designing databases is not their area of expertise.

[Johhhn]

Not sure what you're saying here-- I think designing a database correctly is a given,, hence, why I offer to my clients alternative solutions rather than a billion layouts, which is what the original problem was.

Not sure on your second point either--

I think you misinterpreted what I was saying.

Basically-- if a client is dissatisfied, they will do it themselves or go elsewhere and find someone that will allow them to do a billion layouts, unless, you take care and find them a solution that will benefit them, but not cripple the database. It has nothing to do with undercutting on price, etc.. It has to do with trying to prevent a client from making a mistake by doing it "wrong" or going to the "wrong" person. I've many times in the past lost money fixing computers (I have my own Mac consulting biz) so that it was fixed *correctly*, even though a client couldn't afford to.

I *never* provide a solution half-a$$ just to make a buck. It's just not part of my genetic makeup.

"But, this isn't open heart surgery, nor is it brain surgery, it's FileMaker!"

Sure, FileMaker is easy to use. So are a hammer and nails. But it's a stretch to go from showing somebody how to drive a nail to them then building a house.

FileMaker's ease of use hides the fact that designing databases requires knowledge and expertise. Regardless of the software it's going to be developed in, a database needs to be designed correctly. I'm particularly interested in data design and interface design myself.

"My point was that if a client wants to do xyz and I tell them *NO*, as many of you apparently do, then, depending upon the individual(s), they may simply go elsewhere or do it themselves."

There is always some developer that will underestimate a project's complexity and undercut on price. Clients *always* underestimate project complexity, because designing databases is not their area of expertise.