On 7 Jan 2006 at 8:16, dhbailey wrote: > How about the equally valid musical concept of "thickening of the > texture?" Doubling a line is often used to thicken the texture of a > passage, so why don't we include that as yet a third way to arrive at > the same program feature?
You are conflating two completely different and independent aspects of the discussion: 1. indexing. 2. user interface. Good indexing takes care of different terminology for the same operation. Good indexing is an art, not a science, and is *very* difficult to do. Perhaps those of us who encounter problems finding something in the index should inform MakeMusic and ask for a cross reference to be added to the manual in the next version. As to UI, when I suggested that there's often more than one appropriate path to a particular feature, I was not meaning to lard up the menus with all the possible ways of describing it. That is a reductio ad absurdam reading of my suggestion. The whole idea is that a feature should be accessible from the contexts in which it makes sense for it to be accessible, whether that is only one place or multiple locations. One example is that the function of doubling at the octave could be available as it is in the transposition dialog (I think it's obviously quite handy there, though I don't believe it's the best *single* location for the feature because it's so non-obviously associately with transposition in the abstract, though quite appropriately associated with the way Finale models the task of transposition in its UI), but ought also to be something one can do with the canonic utilities, since, as Dennis pointed out, it's the simplest form of non-unison canonic relationship. That means two methods to accomplish the same task. Obviously, in that case one is accomplished in a plugin and one in the transposition code of the Finale main program (and, of course, there's the tuplet bug in the canonic utilities that could perhaps make the plugin break), so there's no benefit of implementing a single feature with one block of code, but I'm not sure that's much of an issue (though I don't know how hard it would be to revise the plugin to add octave doubling within the same layer of a staff). The plugin operates on internal Finale functionality exposed through the plugin API, so for Finale's programmers, it oughtn't really be a big deal to maintain. Let me say that menu customization is one of those things that sounds a lot more useful than it really is, in my experience. It can also lead to technical support nightmares. If I were a major software vendor and offered user-customizable menus, I'd also implement a "technical support" mode that returned all hidden menu items to their original locations and indicated which standard menu items had been customized, so that a support tech could put the user in a mode that would allow them to diagnose a problem without running up against "but I don't see that choice on the menu." I also agree wholeheartedly with Hiro that Microsoft's "user- adaptive" menus are a usability disaster. They serve to make support extremely difficult, and they mean that users lose access to any of the tasks they don't use daily (since they don't know either that there is a way to reveal the missing menu choices, nor that there *are* hidden items that could be revealed). Furthermore, they mean that menus are not reliably the same in layout, so any muscle memory is completely lost, since you may remember "the menu choice 3 down from the top" and if you haven't used item 2 for a week, your intended choice may end up being item 2, instead. This is disastrous, in my opinion -- it's incredibly user-hostile, because it takes away one of the most important learning tools, which is the visual memory of where something was, It means you have to actually read every menu every time you open it, which is going to slow down any user of the program. Of course, nobody has actually suggested adaptive menus, thank heavens. But I question the utility of user-editable menus. Perhaps if every top-level Finale menu allowed the addition of custom commands in a separate area at the bottom of the menu, that would be helpful, as it would allow ease of addition of custom menu choices, and also segregate them to a place that would not interfere with the organization of the standard menus (thus keeping tech support esay). If you could also add top-level custom menu choices, so you engineer your own menu structure, that would be good, too. But this is not really something that addresses the problem with the transposition dialog and octave doubling. If I had customizable menus, I wouldn't add a menu choice to take me to the transposition dialog in order to do octave doubling, since it's not a daily task. Nor is there any way to launch the feature without visiting the transposition dialog and applying the appropriate settings to it, so it's not a very good choice for a custom menu choice, since your path to it through your custom menu choice isn't going to be any quicker than the existing path through the Mass Edit menu (unless, of course, you could put a direct command for it in the top-level menu, which seems foolish to me). The problem with the inclusion of the "keep original notes" feature is much deeper than any kind of menu customizability could address. To me, it's nice that the feature is added to the transposition dialog, but it looks to me more like what ought to be a secondary location for it, a supplementary path to the feature. But there's no primary path, no other location in Finale where you can do the same thing. And that is the problem for me -- it's not that I want the feature to *not* be in the transposition dialog (it's obvious that it's quite useful there), but that the other places where the feature ought to are lacking it (e.g., canonic utilities), and those other locations seem much more primary to me for doubling than transposition. One solution would be to go with Dennis's suggestion to amalgamate a whole host of features that are related into a single tool. Another would be to beef up the existing places where such features belong (e.g., by adding octave doubling to the canonic utilities). I'm not certain that this one issue is sufficient to justify a major rewrite, but there are plenty of other UI infelicities that I believe could justify a major overhaul. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
