|
On Wed, Jul 7, 2021 at 7:50 PM Nathan Andelin <nandelin@xxxxxxxxx> wrote:
vulgarity
Your last message took a seemingly strident tone plus the use of
and hyperbole.
I apologize for the delivery, but I firmly stand by the message.
In my experience, conditional expressions in documents and
reports are few.
All the more reason to leave it to the users.
The fact that back-end engines might be able to interpret
and run them is arguably irrelevant.
And I'm firmly arguing that it is relevant. I believe that what you
propose drastically (yes, drastically, no hyperbole) hurts
productivity, for both the users and the developers.
Actuallyt, Marco indicated thatone
failures in the engine running them causes significant problems and is
reason that their current solution is not considered viable any longer.
What Marco indicated was that XDocReport is not well maintained. My
understanding is that the "back-end engine" is FreeMarker, and he is
still very happy with that. If he can find some suitable front (and
middle?) end for his users and still use FreeMarker, I am confident
that is exactly what he will do.
I do understand that communication between users and developers may notclear
always go smoothly either. But it appears to me that you don't have a
picture of how much interaction between users and developers occurs inReportBro
environments where tools like Freemarker, xDocReport, Jasper, and
are deployed.
It's not about the smoothness of the communication. It's that the
developers need to be involved at all.
I will grant you that I have no experience with any of those software
packages you've mentioned. But I speak as passionately as I do about
this because what I *am* extremely familiar with is how much of *my*
time is spent doing things that users could and should do for
themselves.
I have said this over and over, and you don't seem to be acknowledging
it at all, which is very frustrating for me. What I'm talking about is
not specific to any particular software package, or even any "genre"
of software. I am talking about something very basic and fundamental,
applicable to any organization. What I'm talking about is the
principle that developers should not be spending their time doing
things that users can do. Why? Because that is time that developers
could have spent doing valuable work that users could not do.
The heavy communication you describe between developers and users is
completely appropriate and necessary when building a user-facing
application. I have spent months at a time where I was walking back
and forth from my desk to where my users do their work several times a
week, or even several times a day. It wasn't a short walk, either. But
the point of all that communication is so that the application can be
refined until it truly serves the users' needs. As most of us know,
even the users themselves often cannot accurately identify their own
needs at the start of a project. If we've done our jobs well, then
after a period of heavy collaboration, the application reaches a point
where the users just use it and the developers move on to develop
other things.
It sounds to me as though Marco's users are working with templates
basically every day. Or at least very routinely, on an ongoing basis.
Are you suggesting that a developer should be involved in a user's
day-to-day activities? Indefinitely?
John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.