If I am seeing what you are seeing, the multitude of responses that have appeared recently are responses to messages that have been discussed on the forum for months in some cases, which suggests that MM staff have looked at them and discussed them before responding (the only way to prioritize what they think possible and desirable to do. That being the case, I suspect your concerns will also receive responses as soon as MM staff decide how to respond.

I am as anxious as anyone to see bugs corrected, as well as imperfectly implemented features corrected, and some features added. I guess we each prioritize what we would like to see based on our personal workflow, whereas (as MM reps have mentioned elsewhere) they must respond based on communications received from a variety of users through a variety of contacts and surveys. Presumably--even if its user interface leaves something to be desired--that is what the Zendesk CRM software is designed to help them do.

Ah, I see what you mean. Yes, I think I must have had a wrong impression of how the list worked.

What do you think of the idea of creating a list of acknowledged bugs, possibly along with workarounds, so that effort is not constantly duplicated? This would, at the very least, take some of the pressure off the tech support people, and help out users like me who are anxious about bugs.

If I'm not mistaken (and not being a MM employee, I can only suppose) keeping a bug-fix list is exactly what the Zendesk back-end is supposed to do, so a list created at this end would be relatively haphazard.

Greetings all:

Apologies for the delay in replying to this thread. I've taken a FIFO approach, as Adrian noted, to this Feature Request community. I am finally caught up on the 5 months of threads. My goal is to stay relatively up to day, but given priorities and schedules, I may go silent from time to time. 

My intent is to aggressively monitor this Feature Request community. Hopefully my activity over the past week is a small indication of my intentions. Greg is doing something similar for SmartMusic and that is working well. We're also in a new era of transparency and I want to be more forthcoming about what we will and won't be doing on Finale. Of course, <enter all caveats here>, time will tell. 

A good time to note my use of status:

• None - I haven't gotten to it or there is still active discussion on the request
• Planned - A story on our roadmap and something we're pursuing
• Not Planned - a story we won't be taking action in the next 2-5 years
• Completed - Functionality in Finale
• Answered - the catch all. I used this for those requests that were not requests as well as stories that we haven't said no to, but have much work to do before we'd get to them. 

I'm considering adding another status like "Invalid" or "Rejected" for those posts that aren't feature requests at all. Maybe Answered is enough. Time will tell.

Christopher: you started this thread by saying you'd posted 5 features and hadn't gotten a reply. If I haven't replied to them by now, please let me know. I'm still working through new threads, but I should be caught up to this post.

To be clear, I'm interested in making Finale better! Features, design flaws, bugs, and notational guffaws are all on the table and things we want to address. I'm not really interested in adding new bells and whistles that add questionable value to a small group of users. I want to remove hurdles to your workflow, speed up Finale, stabilize the code base, remove the pebbles in the shoe, clean up the confusing interface, and so much more. Lots to do, but I have great confidence in the team and our process.

A list of known bugs. I have mixed thoughts on that. We do have the Knowledge Base Articles which are as close to an acknowledged list. We use the KBAs to note the problem, provide a work around when possible, allow people to subscribe to the article (so that when it is fixed you'll be notified), and link the KBA back to our database of issues. It isn't perfect, but it is working as good as any previous system we've tried.

Should bug fixes be requested in a Feature Request community? That's a good question. It depends on how you define a bug. Today, right now, I would say design flaws, some would broadly define as a bug, are game for this area. I want this FR community to be the place for people to comment on where Finale is letting them down. So, if there is a behavior or a limitation or a dialog interaction / workflow that is preventing you from accomplishing your goal, please write a feature request. File specific bugs should be reported via the case system. Certainly "Be my manual..." questions should not go here. That is exactly what documentation, QuickStart Videos and the Problems & Questions are for.

As for the other community of Problems and Questions. I won't go there much and if I do I will likely make an unofficial reply. My understanding is that we only monitor for civility and false information. Again, I will see how things evolve and if there is activity on that board that I should be more involved in I will consider it.

Hope this helps. I look forward to hearing your ideas, having a productive dialog, and ultimately making Finale better.

Sincerely,

Michael Johnson

VP, Professional Notation

MakeMusic

Hi Michael,

Thank you for your measured reply to me flying off the handle. I didn't understand the way topics were listed in the forum, so I had the impression that all those questions got answered before mine, but they were actually OLDER questions! My apologies.

However, the five questions I posted in a row are still languishing on page 3, unanswered. Some are obvious bugs; while some are working as designed, but the design is strange/not according to convention/requiring kludges to bring up to standard.

As long as we're in this question on this topic, there is an inconsistency in the UI for this forum. When I am typing an answer, hitting Return once gives me a full paragraph break with an extra line. But when I look at the answer once it is posted, all my single Returns show up as simple carriage returns, without the extra line. Now that I know that, I hit Return twice for a paragraph break, but it is strange that it appears differently in the message editor. I notice even in your answers that your paragraph breaks are single carriage returns.

[Edit] And now, all my double Returns that showed up in my original reply are showing up as quadruple Returns! I removed them, and now everything is a single Return, showing up with the extra paragraph break line. Weird.

[Edit again] Every time I hit Update, all my Returns get doubled! Even though I removed the extras, they are all back, multiplying like heads on the Hydra!