Does anyone use Maya or tinkered with it? It has a context menu on steroids where basically everything is available to the user right under their pointer once they learn how to navigate it. It's not hard, just a bit quirky, all those little textl ables surrounding your pointer, each item having sub-menus. It's not a bad idea, but I do like the limited context menus relative to the more thorough menubar now.
I would say that there does seem to be a few apps that probably could go without the menubar and just float around that odn't now. There is at least one app, Cinema 4D that totally wastes the menubar area and stuffs its own Windows/*nix-ported menubar in its main Window. God, 3D app UIs suck so hard...
I'll take some screenshots of the Maya context menu when I get home, but that might not be for 6 or 7 hours, depending.
Uh, Windows doesn't allow you to put the menu bar anywhere you want., It alets you put the taskbar on any side of the screen, but so does OS X with the Dock. The Windows menubar is glued to each window, even with parent/child windows. Some apps treat the menus like it's another toolbar. which lets you hide it or rearrnage its place under the title bar. Maybew that's what you're thinking of.
What I would like to see is an application window contained within itself. A bit like the iApps, but without the anchor of the MenuBar.
"Knock, knock."
"Who's there?"
"THT's brain."
"Sorry, I don't believe you."
1) What do you gain by anchoring the menu-bar to a single-window application like iPhoto?
2) There is an "application window," but it's not what you think it is. The application window is the entire desktop. It's just transparent. It's where the menu-bar resides for example.
3) Think about what you LOSE by anchoring the menu-bar to an application window. i) consistency ii) infinite height iii) the menu-bar itself if you close the window. I suppose you're one of those who likes the idea of apps quitting when the last window is closed?
Developers choose to use the menu bar because it's a good widget.
It's true in a technical sense. But I would like to see Apple encourage the use of something better. In the broader sense however, Apple does highly stresses the use of the menu bar, does it not? It recommends that all apps follow the basic UI guidelines and employ the use of the menu bar instead of putting a pulldown menu elsewhere.
Quote:
So let me get this straight... because some apps require training for whatever reason, the menubar doesn't have utility? Er...
Er... no. Obviously it has utility. I'm looking for better utility than it provides. I want more help and better app design, and to do that, the developer should be freer, should be encouraged to employ something else that could be better. I want the app developers to use a UI design that is the most optimum for their apps.
My point was, the benifits of having a menu bar is to provide the user a common place to go to for commands and such, and thusly, helps make applications easier to use. For many applications, it doesn't really help since the user doesn't understand what the commands in the menu bar do. So, design something better. I don't know, maybe pop-up text help for pull down menu commands?
Quote:
And one would access them how? Keystrokes? Which would be discovered by the user how, documentation?
It'll just be the same tools that have been used before. Pop-ups, pull-downs, pop-up text help, drag-n-drop, etc. Which one to use depends on the UI.
Quote:
Personally, I haven't a clue how one would offer a compact, hierarchical command structure in a GUI system without something similar. Given that it should probably have an easy (read Fitt's Law Compliant) targeting, an edge of the screen makes sense. Hmmm... sounding familiar.
You don't have to have a compact hierarchical command structure. Some apps can be designed such that it has very few commands and don't require it. Other that have a lot of commands, well, I don't know what the right answer is, but I think it'll be interesting to see what developers come up with.
Quote:
You don't want to overwhelm the user with every possible command simultaneously
I wonder if this is really true. Splash a little Tufte-esque presentation, and I wonder if it really does overload the user with information. Whether it is the proper UI for an app, I don't know. It depends on the application.
Quote:
What do you suggest?
I already suggested a couple of things. A natural language interface where it can unsterstand context, be it typed or voice. One that can learn and tune itself to a user with use. A GUI could just be a text box like window that is popped out of the edge or corner of the screen through a mouse movement, function key, et al.
The idea of moving away from the menu bar is to move the focal point of the user to the natural language UI, and to move the system from an application centric view to a pure window view. It's like the iApps' single window design philosophy, but I would like to go further and have the apps entirely contained within their own window. I don't know what to do with apps that uses lots and lots of palettes, but that's part of the adventure in this thought experiment.
1) What do you gain by anchoring the menu-bar to a single-window application like iPhoto?
I never said that a menu bar or pull down menu system should be applied to a single window application. I'm saying that all of application's features should be contained with its own window. Whether it used a MS Windows like pull down menu system, pop-up menu system, pie style pop-up menu system, lots and lots of buttons, or something new is up to the developer since they'll know how to use there system the best.
Quote:
2) There is an "application window," but it's not what you think it is. The application window is the entire desktop. It's just transparent. It's where the menu-bar resides for example.
Bleh, I don't need to learn about the menu bar by way of MS Windows MDI analogies.
I would like to see all windows be self contained entities. The menu bar splits user focus, and I think the user should entirely be focused on the window itself. With larger screens and multitasking, user focus only splits more.
It's like the way browser tabs are such a hit. The user feels in more control when all of the action is framed within the browser window, instead of dealing with the window switching mechanism the host OS supplies and with browser windows spread and overlayed around the desktop.
Quote:
3) Think about what you LOSE by anchoring the menu-bar to an application window. i) consistency ii) infinite height iii) the menu-bar itself if you close the window. I suppose you're one of those who likes the idea of apps quitting when the last window is closed?
I'm trying to think about what we gain by not using the menu bar. All the Fitt's Law stuff can be traded off. Consistency and such can be achieved through other means.
As for apps closing upon the last app window closing, I'm not that worried about it since in the near future there will be enough memory to keep all apps running all the time. Kidding. I don't really care about it the issue.
Comments
I would say that there does seem to be a few apps that probably could go without the menubar and just float around that odn't now. There is at least one app, Cinema 4D that totally wastes the menubar area and stuffs its own Windows/*nix-ported menubar in its main Window. God, 3D app UIs suck so hard...
I'll take some screenshots of the Maya context menu when I get home, but that might not be for 6 or 7 hours, depending.
Originally posted by fahlman
Murbot, can I request having my posting privileges revoked?
THAT's a new one... !
Originally posted by BuonRotto
Uh, Windows doesn't allow you to put the menu bar anywhere you want., It alets you put the taskbar on any side of the screen, but so does OS X with the Dock. The Windows menubar is glued to each window, even with parent/child windows. Some apps treat the menus like it's another toolbar. which lets you hide it or rearrnage its place under the title bar. Maybew that's what you're thinking of.
Actually, I was thinking of the taskbar
Originally posted by THT
What I would like to see is an application window contained within itself. A bit like the iApps, but without the anchor of the MenuBar.
"Knock, knock."
"Who's there?"
"THT's brain."
"Sorry, I don't believe you."
1) What do you gain by anchoring the menu-bar to a single-window application like iPhoto?
2) There is an "application window," but it's not what you think it is. The application window is the entire desktop. It's just transparent. It's where the menu-bar resides for example.
3) Think about what you LOSE by anchoring the menu-bar to an application window. i) consistency ii) infinite height iii) the menu-bar itself if you close the window. I suppose you're one of those who likes the idea of apps quitting when the last window is closed?
Originally posted by Kickaha
It doesn't *NOW*.
Konfabulator. No menu bar.
Virtual Desktop. No menu bar.
Developers choose to use the menu bar because it's a good widget.
It's true in a technical sense. But I would like to see Apple encourage the use of something better. In the broader sense however, Apple does highly stresses the use of the menu bar, does it not? It recommends that all apps follow the basic UI guidelines and employ the use of the menu bar instead of putting a pulldown menu elsewhere.
So let me get this straight... because some apps require training for whatever reason, the menubar doesn't have utility? Er...
Er... no. Obviously it has utility. I'm looking for better utility than it provides. I want more help and better app design, and to do that, the developer should be freer, should be encouraged to employ something else that could be better. I want the app developers to use a UI design that is the most optimum for their apps.
My point was, the benifits of having a menu bar is to provide the user a common place to go to for commands and such, and thusly, helps make applications easier to use. For many applications, it doesn't really help since the user doesn't understand what the commands in the menu bar do. So, design something better. I don't know, maybe pop-up text help for pull down menu commands?
And one would access them how? Keystrokes? Which would be discovered by the user how, documentation?
It'll just be the same tools that have been used before. Pop-ups, pull-downs, pop-up text help, drag-n-drop, etc. Which one to use depends on the UI.
Personally, I haven't a clue how one would offer a compact, hierarchical command structure in a GUI system without something similar. Given that it should probably have an easy (read Fitt's Law Compliant) targeting, an edge of the screen makes sense. Hmmm... sounding familiar.
You don't have to have a compact hierarchical command structure. Some apps can be designed such that it has very few commands and don't require it. Other that have a lot of commands, well, I don't know what the right answer is, but I think it'll be interesting to see what developers come up with.
You don't want to overwhelm the user with every possible command simultaneously
I wonder if this is really true. Splash a little Tufte-esque presentation, and I wonder if it really does overload the user with information. Whether it is the proper UI for an app, I don't know. It depends on the application.
What do you suggest?
I already suggested a couple of things. A natural language interface where it can unsterstand context, be it typed or voice. One that can learn and tune itself to a user with use. A GUI could just be a text box like window that is popped out of the edge or corner of the screen through a mouse movement, function key, et al.
The idea of moving away from the menu bar is to move the focal point of the user to the natural language UI, and to move the system from an application centric view to a pure window view. It's like the iApps' single window design philosophy, but I would like to go further and have the apps entirely contained within their own window. I don't know what to do with apps that uses lots and lots of palettes, but that's part of the adventure in this thought experiment.
Originally posted by Eugene
1) What do you gain by anchoring the menu-bar to a single-window application like iPhoto?
I never said that a menu bar or pull down menu system should be applied to a single window application. I'm saying that all of application's features should be contained with its own window. Whether it used a MS Windows like pull down menu system, pop-up menu system, pie style pop-up menu system, lots and lots of buttons, or something new is up to the developer since they'll know how to use there system the best.
2) There is an "application window," but it's not what you think it is. The application window is the entire desktop. It's just transparent. It's where the menu-bar resides for example.
Bleh, I don't need to learn about the menu bar by way of MS Windows MDI analogies.
I would like to see all windows be self contained entities. The menu bar splits user focus, and I think the user should entirely be focused on the window itself. With larger screens and multitasking, user focus only splits more.
It's like the way browser tabs are such a hit. The user feels in more control when all of the action is framed within the browser window, instead of dealing with the window switching mechanism the host OS supplies and with browser windows spread and overlayed around the desktop.
3) Think about what you LOSE by anchoring the menu-bar to an application window. i) consistency ii) infinite height iii) the menu-bar itself if you close the window. I suppose you're one of those who likes the idea of apps quitting when the last window is closed?
I'm trying to think about what we gain by not using the menu bar. All the Fitt's Law stuff can be traded off. Consistency and such can be achieved through other means.
As for apps closing upon the last app window closing, I'm not that worried about it since in the near future there will be enough memory to keep all apps running all the time.