On 26 Jun 2009 at 20:23, John Howell wrote: > At 7:07 PM -0400 6/26/09, David W. Fenton wrote: > >On 26 Jun 2009 at 23:50, Owain Sutton wrote: > > > >> I can see how the regular use of a persistent 'properties' window makes > >> sense for some users, who will be routinely modifying all sorts of > >> details. > > I just experimented, using a Sib5 score I maintain for experimenting. > I entered the word "arco" in Technique Text (a text class which > automatically causes certain things to happen, in this case switching > from pizz. to arco or back again). Using the Properties Window I > very quickly changed that text to italic and then made it bold. > Piece of cake, and a total of 3 clicks since I have the Properties > Window open anyhow for the project I'm now working on. (It can be > made more or less transparent, by the way.) > > Of course I didn't know I could do this until someone HERE mentioned > it within the last 24 hours, but I can and I did and it worked > exactly as I wanted it to! > > Am I wrong, or isn't arguing about the way two different development > teams chose to implement any particular action something less than > helpful?
Yes, of course it's helpful. Applications should implement features in a way that is consistent with the platform the application is running on: > And as far as the Windows GUI goes, those of us who have never used > Windows at all couldn't care less, But those of us running Windows want an application that uses Windows UI conventions, just as you want an app that uses Mac UI conventions. This is not a triviality -- an app should not feel "foreign" to the OS it's running on. If it does, it's more difficult for users to learn and use. > and most Mac users don't even have > multi-button mice (although I do happen to have one). Oh, come on! That dogma went out the window years ago! > So complaining > about what right-clicks do or do not do isn't very useful either. The single button mouse has a command that is equivalent to the right click. I seem to recall it's some form of slow click, but I could be misremembering. > Of COURSE any software will do things in one way or in another, and > one of the most persistent complaints I've read on this List is the > way functions in Finale have been moved around from one version to > the next. As David Bailey has so calmly pointed out, maybe Finale > does exactly what you need, or maybe Sibelius does, or maybe neither > one of them does (especially in contemporary or non-measure-attached > notation), but complaining just because they're different strikes me > as something of a waste of time and effort. This is a very different kind of discussion. Applications should follow well-established UI conventions for the platforms on which they are running. Right click for properties on Windows is a UI requirement, not something that is optional. That Finale is inconsistent in implementing it is not an excuse for Sibelius to get it wrong. > >I suspect that Sibelius is not as rigid as it's being made out to be, > >and that Finale users like me who've found it frustrating have just > >not figured out how Sibelius conceptualizes the desired tasks. > > The best summary I've seen, David. A beginner would no doubt say > exactly the same thing about Finale, coming from, say, Mosaic, or > Music Construction Set!! Or Score, for that matter. But let me repeat that there are basic OS UI conventions that should be respected. Whether or not the Mac version exposes the properties dialog via an easily accessible shortcut menu is really irrelevant -- on Windows, that is the way it ought to be, because that's the standard for the OS and has been so for a very, very long time. Discoverability depends on consistency with user expectations, and failing to implement a properties dialog that is accessible via a shotcut menu is not helpful for discoverability. -- 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
