I didn't say it would be impossible to program F2009 to preserve
unlimited staff lists. Clearly anything like this is possible. The
point is that they very well could have faced a decision where
simplifying the staff lists made their lives considerably easier. This
might be a sensible business decision, considering the direction they
are heading with the expressions. I agree with your points about
springing it on the community without warning.
I have never used more than 2 staff lists, so I'm sure I am not as
sympathetic to the problem as I might be.
[EMAIL PROTECTED] wrote:
I am a programmer, too, and for about as long. I have encountered situations similar to
what you've described below. There may be issues with having large staff lists
(performance, field count bit size, whatever), but I can't see the reason for 4, as
opposed to say, 8 or 16. I am not in their shoes, and maybe they've encountered a limit
beyond my experience, but I find that hard to believe. They've removed features - they
did not warn the user base, they did not "deprecate" old features, and I think
that is what most find offensive. We have had no time to prepare, and have forced some of
us to consider not upgrading (I did upgrade, by the way, and I like WinFin2k9). This is
simply bad business. And, in the battle between business needs and programming, I have
found that programming usually loses. Seeing as they have not cited any programming
benefit, I can only conclude otherwise. Of course, if any of the MM lurkers wish to
correct me, I will stand corrected on that point.
Nevertheless: removal of a capability, no user base preparation (I mean all of us), and,
in my mind, several workable alternatives to what they could have done, instead. Goodness
- they could have written a plug-in that would scan the document and say "hey, too
many staff lists - WB will be upset!" if it were just the publ houses.
Sorry. As a long-time program project manager, this is a hot button for me.
---- Craig Parmerlee <[EMAIL PROTECTED]> wrote:
I wonder if we should be giving them some benefit of the doubt on this
subject. As a professional software designer for 35 years, it seems
entirely plausible to me that they may have faced a point where
preserving unlimited staff names, in combination with other new
features. would have taken significant extra programming and testing
effort. In cases like that, I believe it is appropriate for the system
architects / business planners to make some judgments about their
overall vision for the product. That seems to be the case in this
instance. Their vision is, evidently, that they want to put their
effort into the more elegant organization of expressions.
If there were absolutely no trade-off involved and they made this change
just to be hard-headed, that would be a bad deal. I really doubt that
was the scenario though.
[EMAIL PROTECTED] wrote:
Seems to me that if they wanted to put in limitations for some publishing house, it would not be
unreasonable to put in a "policies" configuration where you can select, say, the WB or
B&H guidelines and styles so the various houses get what they want. For the rest of us peons who
have different "guidelines", we can select the same old personal style we've been using
since, well, forever.
_______________________________________________
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
_______________________________________________
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
_______________________________________________
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
