On 7. Oct 2004, at 10:05, Johan Sörensen wrote:
The trouble is -- what if you only wanted to change the font for the current document? Perhaps I'd like to see the document I'm working on right now in a bigger font, or I'd like to treat tabs differently temporarily. Under the current system, it ain't temporary.
How would moving the stuff to a preferences window make it temporary?
and I think that is exactly the reason why people are so bothered by this, usually in mac osx applications things in the menus only apply to the current (document) window, not globally.
It's been out for a day -- I think people have started it, wanted to see which preferences it offered, and then stumbled upon the missing preferences window, and ranted about it. So let's give it 14 days, and we'll see how people feels about it in that time.
And I'm wondering what the HIG would say about this?
I'm getting slapped with AHIG a lot, but no-one provides any quotes, so here are some.
Regarding preferences in general: http://developer.apple.com/documentation/MacOSX/Conceptual/ AppleSWDesign/UsingTechnologies/chapter_7_section_6.html
[...] avoid implementing all the preferences you can think of. Instead, focus your preferences on the features users might really want to modify.
A preference should be a setting that the user changes infrequently. If a user might change the attributes of a feature many times in a work session, avoid using preferences to set those attributes. Instead, give the user modeless access to the controls for modifying that feature. For example, you might implement the feature using a menu item or a control in a palette or window.
[...]
Regarding the View menu, which I use for most options: http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGMenus/chapter_7_section_4.html#//apple_ref/doc/uid/ TP30000356/TPXREF148
The View menu provides commands that affect what users see in a window. In the Finder, for example, the View menu contains commands for displaying windows as columns, icons, or lists. Commands for showing, hiding, and customizing a toolbar belong in the View menu [...]
Personally I don't really have that much of a problem with it, apart from the fact that i have to move past 3-5 menu items in the view menu that I've only used once to change the wrapping for example.
And this is actually part of the reason why I did it as menu items. Many of the items I present in the View and Behavior menu are things I frequently change, and having them in the menu provides a key equivalent to do this (so I can work 100% from the keyboard).
So whether or not this goes against AHIG would probably depend on the frequency with which you change these items (ignoring that the View menu *is* for options relating to the view). Maybe my usage pattern differs from the average, maybe people are (without realizing it?) using preference windows as initial hints to what features a program offers (instead of going through the documentation), or maybe something third... let's put this to rest and see if it's really that unbearable!
But hey, if the developers feel this is the best thing since sliced bread, so be it.
I _do_ get the message that this bothers a lot of people, and this is of course not my goal with TextMate. But OS X also did initially bother a lot of Classic Mac users ;)
I just don't hope they keep on adding more and more menu items when the program grows in options, then TM would end up feeling like..well... windows really...
A preferences window is unavoidable in the long term, I'm not religious about it, and I wouldn't add arbitrary options to the menus!
And "keep on adding more and more", I really do not think TextMate stands out with huge unstructured menus. I'm currently in Mail.app, I see it has 17 items in its View menu, 5 of them are submenus.
But I would love to receive constructive criticism on the subject e.g. in the form of mockups.
Kind regards Allan