I've now got a similar thread to this here in the documentation forum - it is also an idea that is relevant to that forum.
I think pressing the spacebar should only show the options that are valid at that time. Also, it should show every valid option.
I think that initially, the "Edit" category should have hardly any entries... just things like
Grab/Move G (I think including the word "move" makes it easier for beginners to understand - they might ignore that entry if it just says "Grabber")
Type in Position/Rotation/Scale N
Enter Vertex Edit mode TAB
At the moment it only has one entry for "N" - it is under sequence - it is for "Str Params". But usually selecting that on the menu does nothing - since I wasn't in the sequence editor (or whatever).
So basically at the moment, you can get an incomplete list of hotkeys, and many of them don't even work when you click on the menu. Sometimes using the menu does work, but the hotkey is misleading...
e.g. if you aren't in edit mode and you go to shear (Ctrl-S) it works - because it takes you to edit mode first... but if you aren't in edit mode and want to use the hotkey, a beginner would assume that Ctrl-S is all that is needed... but Ctrl-S makes the Save file thing come up! (Ctrl-W is meant to be for that...)
And sometimes the menu doesn't take you to edit mode...
e.g. if you go to the edit menu and go to shrink/fatten (alt-s) it says "clear size?" !
I think the descriptions should be more descriptive....
"Join" could be "Join selected objects"
"Make Track" could be "Make 1st selected obj track 2nd obj"
"Make Parent" could be "Make 2nd selected obj parent of 1st obj"
I think there should also be some information included with blender that explains everything you can do with the mouse (move things, create new views, etc) and that you can press space to see the other relevant commands. Maybe the mouse stuff could somehow be on the spacebar menu - it could have a link to message explaining about the mouse.
I guess "enter vertex editing mode" or "edit vertexes" (TAB) should only show on the menu when an appropriate object is shown - e.g. not a light. And if a light is selected, things like the light properties (F4) would appear on the menu.
Maybe the first time blender is run it could have a little message that talks about the mouse and the spacebar menu.
I don't think the blender interface should become a novel.
Just like the B button in this interface does not say "Makes selected text apear bold" but tries to say just that with "B".
It might be a good idea to put the discription in the toolpopup or create a help bar where text may apear.
I do agree with the "buttons should do something or not been shown" feature. This will not be easy to implement in current blender.
Using baby language for better understanding does not sound like a good idea to me. Just like you don't call a steeringwheel a turn-a-left-and-righter. So yes, grabber might be the wrong word for the translate tool.
Maybe blender can become language independant and have external language files, so anyone can give any (own language) word to any feature. This will not help documentation.
The N not being added to the toolbox is just because of time (lack of it).
(first there was N in seq, then the toolbox hotkeys, then N in other windows)
As I understood it, GHOST was partly written so current windows can contain sub-windows. This would help programmers and users alot. These subwindows could contain HelpInfo or window related Toolboxes.
btw. "Make 1st selected obj track 2nd obj" should be "Make all selected objects track to active object" and "Make 2nd selected obj parent of 1st obj" should be "Make all selected objects child of active object"
But, context related menu is a good idea. (Hee, even Maya does not have that!)
That sort-of already exists in the Wkey specials menu, although it's very limited. I personally don't think hiding entries from the main toolbox is a good idea - it makes the interface harder to explore and it's much more difficult for the user to build a cognitive map of the system if it's constantly changing (see the horrible failure that is Microsoft's 'adapting start menu' and office toolbars). I think what would be good though is if the inaccessbile menu entries could be greyed out or something to show that they can't be used in that context.
I definitely agree with the idea of editing the language used to make it clearer. It would also help to define a list of terminology, so that it can be consistent throughout the program. I've been writing up some ideas to do with potential 'interface language guidelines' that I may end up posting soonish, which some of you might find interesting to discuss.