Am I crazy? What do you think?

Question:
Are reports and print layouts too difficult to create?

Choices:
Yes, Marketcircle should make reports and print layouts easier.
It makes perfect sense if you don't mind turning yourself into a software engineer and spending six hours building each report and print layout.
No, the report and print layout editor are superlative just they way they are.

 

I would like to add prefixes, such as "Dr." and suffixes, such as "Ph.D" and job titles, such as "President" to my Avery 5962 label sheet. When I try, as I did today, and have done other times, I seem to spend a great deal of time using trial and error, and my time is wasted with unsuccessful results. I appreciate the way Daylite offers every possible option and opportunity, but I would like a training manual, video, instructions that will train me and enable me to add prefixes, suffixes, and job titles quickly and effectively. Is a mastery of software engineering necessary, to edit address labels?

Tried putting a report together the other day but gave up. This was after downloading a user guide (turned out to be something about the technical side of the process or whatever) and trying to fathom out what you have to do.

IMO the report writing function is severely flawed in that it needs a qualified developer to actually get a report. As users we should not have to turn to paid developers to put something like a report together.

Lets hope for a better option in version 4 when it arrives.

Anyone from Marketcircle here care to assure us that the matter is in hand?

Thanks in advance, Mike

Ditto for Billings.

Ah... now I understand what Marketcircle have done.

I've just been looking at the report engine docs and also f-script which is used to do all the work in the reporting engine.

No this is not a proper reporting tool designed for user customisation (and by user I mean reasonably intelligent computer literate professionals who would be able to eg: write macros in Excel or AppleScript.)

What they appear to have done is to expose the in memory object model of Daylite, ie: the internal API's of the application to the f-script interpreter. F-Script is a smalltalk like scripting language. I expect its a very powerful language.

The problem is with this approach is that its only really suitable for use by people who want to learn the internal API's of Daylite. Generally this would be those people on Daylites development team! (Oh yes and suitable for people who are happy with the Smalltalk-y way of coding. A fabulous thing but rather like teaching most English speakers Mandarin as it requires a bit of a paradigm shift).

Even worse.. this is really completely unusable unless detailed API documentation is provided (which it doesnt seem to be). I, or another casual user, will find it nigh on impossible to know which API objects exist and what their properties and methods are.

This has to have been a quick fix rather than a proper reporting strategy. I hope that a proper user based reporting system is somewhere on the product roadmap for Daylite.

To be fair Marketcircle have provided a lot of built in reports, but sadly they don't do what I want at the moment! I have a great deal of software experience, but it isn't worth my time learning an internals API in order to produce a couple of reports.

So I'd say that currently, the product does not have a viable end-user customisable reporting tool.

Hence the heavy signposting to specialist consultants to help write custom reports or sell off the shelf ones at about 1/3 the cost of the core product!

This latter approach is viable for enterprise level sales, but not for the small creative business

that's a bang-on comment about the viability of the Report Engine for enterprise level sales. A small, creative little consulting firm like ours does not have the resources to spend on hiring a third-party partner to write a simple Sales Activity Report. The report engine exposes a HUGE flaw in Marketcircle's business model, because it appears as though their implementation of the report engine is based on a BUSINESS decision to drive users to 3rd party developers, instead of creating a mechanism 'for the rest of us' to do our own reports. This is very UN-Apple-like, don't you think??

I find it really quite odd if this is what is going on. If for no other reason that the rest of the product has such a different and open philosophy. I think this is why I've been driven to post on this because I guess I feel that once one has made the buy decision based on the really great openness of the product it comes as a bit of a shock to find something like this lurking within. My guess is that this is not really the case and that Marketcircle might want to make this more usable in future... but everything takes time.

Thanks Paul for a very informative post - I don't feel so inadequate now in admiting I can't find my way around to putting the most basic report together - thought it was me!

I am also not keen on spending $80 on a report every time I need one either.

Would love to hear from Marketcirle on this one and to learn of future plans to bring the reporting in line with the high standard of the main product.

Thanks again Paul, Mike

Mega-dittoes, guys. We need an end-user-friendly reports & print layout designer module that let us easily get at our data. Folks (including me) have been asking for this for a long time now. I am guessing, though, that we'll not see something like this until Version 4, since Version 3 has been so focused on getting things like sync to work. Most everything else about Daylite is pretty easy to figure out and use... were the report module to be fixed I would be the happiest of campers!

BTW, I did find something that MIGHT help, called On-Target Reports

I haven't tried this but it's possible it might be integrated with Daylite to provide easier reporting capabilities. I told them at Marketcircle about this today so they could look into it.

The point-of-sale software LightSpeed from Xsilva makes extensive use of On-Target Reports in their software. LightSpeed also runs on OpenBase, as does Daylite, so it seems that On-Target Reports ought to integrate with Daylite fairly easily. Over to AJ and the engineers...

quote:

Choice:

It makes perfect sense if you don't mind turning yourself into a software engineer and spending six hours building each report and print layout

I'd have to say this "choice" really isn't fair.

Reports are not some "simple query" or pretty graph that you put into a page; it's a complicated process to build one and requires knowledge that, yes, the average user probably won't have.

The report engine in Daylite is pretty powerful (especially considering the price it sells for - ever heard of some $400 software called Crystal Reports?), and with power inherently comes complexity. So the way I see it, we could either have this power as it is now, or it could be 'dumbed down' and easier to use with less power, at which point it wouldn't be powerful enough and you'd all be back here complaining anyways, so we might as well have that power as it is now.

Additionally reports are usually complex (regardless of the actual application you use), and most often extremely specific and custom to a business, where standard reports are not adequate enough for it (else you wouldn't need to have a customized report done, right?), so you'll need someone with knowledge to get that done.

Just as with running a business, doing accounting, filing taxes, doing repairs on a house, etc. you either learn to do it yourself, or pay someone to do it for you.

And for all the complaints that have been posted about the report engine on this thread, there's not one post that compares it to another 'easy-to-use-but-just-as-powerful' product - my guess is that's because such a product simply doesn't exist (and yes I checked out this 'On target Report' - wasn't impressed by their download link, and didn't find it any more 'Apple-like').

And yes, the APIs *are* available .

@David:

Seek and you shall find: Adding salutation to a label sheet (1:52)

quote:

Originally posted by Jorge Nelson:

And for all the complaints that have been posted about the report engine on this thread, there's not one post that compares it to another 'easy-to-use-but-just-as-powerful' product - my guess is that's because such a product simply doesn't exist

Oh yes it does, its the report generator built into Moneyworks.

I suspect that you have more patience and time than I have.

Also, the API's provided are classic 'expose the object model to the user' style API's. They were not designed for this purpose. Its the API developed by the Daylite developers for the development of Daylite itself. Its not at all built for an external developer with typical 'scripting' or report writing skills to use.

By the way. I have used

1) Crystal Reports
2) Business Objects (a complex enterprise reporting tool)
3) Reporting built into Act!
4) The aforementioned Moneyworks built in report writer
5) SQL based tools over RDBMS, such as Sybase and Powerbuilders report writers

I've also written object-relational data models in Java/SQL and Hibernate.

And I can tell you, they are all easier to use than the reporting built into Daylite!

Yes.. I tried to make what I thought was a simple report... IMPOSSIBLE! I feel like I've been ******ed into purchasing this software. One thing I remember reading was "Daylite project management software for the way people think". The learning curve is way too steep!

I've re-edited this because I finally had the time to invest in learning some F-Script and build a print layout for my workflow.

Now I'm more impressed with how Daylite and the report scripting work and I can understand the logic behind it all.

I think what is lacking now is not anything in the design of the reporting facilities, but just in the way it is being communicated.

The documentation is simply too weak and spread out. I managed to figure things out by reading the following things.

1) These forums.
2) The various scripts and documents in the DayliteDeveloperKit
3) The Report writing overview document
4) The F-Script manual

I put in about 12 hours of effort and managed to produce a print layout which works off of an Opportunity, traverses roles to find the Main Contact for the Opportunity, gets the current user data and so on. Not terribly complicated in theory.

My conclusion is that all thats needed are a couple of really well written advanced 'cookbook' style tutorials that go deeper than the videos.

In reality, very little F-Scripting capability is needed to do what most people need which is just to pull data out of the object model and poke it into a report. I think this could be conveyed in a couple of tutorials for a) print layouts b) reports. F-Script is not a natural thing for people who are used to things like PHP, Applescript, Javascript etc, but its possible to give people some programming snippets that do most of what they want in a few tutorials.

One area that was difficult for me was the apparent lack of information about methods that might be available inside Daylite specific F-Script, ie: the Daylite API. The data model doc. in the DeveloperKit is great, but there are methods used in the sample reports (if one edits and pokes around in them) that aren't easy to find documented.

It could have saved me a lot of time if some detailed reporting/scripting tutorials existed and I'd have been a lot happier with the product. (Which by the way I think is excellent).

This message has been edited. Last edited by: Paul Freeman,