(1) Complex languages lead to more complex misunderstandings. As a systemwide feature, this would probably do more damage than good, for now.
Complex languages also lead to more productivity. There's a tradeoff somewhere. I just know that with today's number of files, folders, and volume of information, I'm not being as productive as I should be. I don't need to be spending an hour or two every month organization data and email or searching on the internet or through help systems for arcane information on how to do something.
Quote:
(2) Worst. Idea. Ever.
The Menubar is a shackle upon innovation. It's getting more and more cumbersome as we multitask more and more, especially on larger and larger screens.
Complex languages also lead to more productivity. There's a tradeoff somewhere. I just know that with today's number of files, folders, and volume of information, I'm not being as productive as I should be. I don't need to be spending an hour or two every month organization data and email or searching on the internet or through help systems for arcane information on how to do something.
Hence, metadata. Not input devices or technologies.
Quote:
The Menubar is a shackle upon innovation. It's getting more and more cumbersome as we multitask more and more, especially on larger and larger screens.
Totally disagree. Name another tool with an infinite target depth.
At *BEST* I can see allowing a user to decide which edge to have it pop up on... or at least which monitor, perhaps 'all', but a 'shackle'? Please.
I still like the iSight based kiosk idea where you can pretend you are using a data glove. The UI needs to be remodelled to be a 3D world instead of 2D windows. Voice recognition needs to improve a lot as well.
Noooo...when I describe why commandline unix is the way it is I'm not praising it as better, I'm saying "why" we type cp instead of copy, mv instead of move etc. I'm not saying the folder/file thing (in Mac or Windows for that matter) is even at all worthwhile in the future.
I'm saying that due to physical demands of typing, unix was designed to be a shorthand. The same physical demands of speaking will mean a shorthand will need to be used if you are continually operating a computer. It already happens with speech macros now.
It simply sucks to have to type that much.
It simply sucks to have to mouse around that much. (But mousing is perhaps the least tiresome of them all)
It simply sucks to have to speak that much.
The Mac is nice that it gives you all options for input. That's nice and should always be the case. Up to the user.
But as far as future paradigms, natural speech will not be the primary input, nor will natural language typing. Not for a standard OS.
Sure, I want the OS to understand natural spoken language, recognize handwriting and natural language typing. But until some future technology is devised that we can't fathom, we'll use a mix of input methods.
I don't think any will win over the others since there are myriad uses and users.
Hence, metadata. Not input devices or technologies.
Metadata is vitally important yes. But what would you propose the interface to be? How are we going to take advantage of the metadata? Lots and lots of columns in Finder windows?
Quote:
Totally disagree. Name another tool with an infinite target depth.
Why would I have to since I am proposing not using a Menubar? I'm proposing moving away from the usage of a pull-down menu system.
For applications with heavy usage of the menubar or applications that require a lot of usage of pull-down menus, I am suggesting using something different. I'm definitely not suggesting abandoning Fitt's Law - that's why I think Apple should have an API for screen edge and screen corner applications, apps that essentially will live on the edges and corners of the screen.
Quote:
At *BEST* I can see allowing a user to decide which edge to have it pop up on... or at least which monitor, perhaps 'all', but a 'shackle'? Please.
Yes. By definition, is it not? All application UI design must conform to the Menubar and other application guidelines, therefore, all apps are shackled to that design.
There are cases of apps where a menubar would not be necessary, there are cases of apps where a some other UI design is better for the amount of commands in the apps, there could be cases where a pull-down menu system is too limiting. And for a multitasking system, the menubar splits the focus of the user. With ever larger screen resolutions, that focus between app window and menubar is split even further. So there is rationale for moving away from it.
Metadata is vitally important yes. But what would you propose the interface to be? How are we going to take advantage of the metadata? Lots and lots of columns in Finder windows?
See that little search window top right in the Finder toolbar?
Now mate that with smart folders, where the metadata selection is done once at folder creation time, and it becomes highly non-intrusive.
Seriously, look at the iApps and Xcode for examples of this in action. (Instant searching across a project's symbol space in Xcode has utterly changed how I develop, I swear.)
Quote:
Why would I have to since I am proposing not using a Menubar? I'm proposing moving away from the usage of a pull-down menu system.
Let me rephrase it:
What would you suggest as a UI mechanism that would replace a pull-down menu system, yet still offer the same benefits without adding additional drawbacks, and while solving some problems you see with it?
Quote:
For applications with heavy usage of the menubar or applications that require a lot of usage of pull-down menus, I am suggesting using something different.
Command keys?
Quote:
I'm definitely not suggesting abandoning Fitt's Law - that's why I think Apple should have an API for screen edge and screen corner applications, apps that essentially will live on the edges and corners of the screen.
No argument there.
Quote:
Yes. By definition, is it not? All application UI design must conform to the Menubar and other application guidelines, therefore, all apps are shackled to that design.
Sorry, but that makes as much practical sense to me as saying "a window is just a shackle to innovation!". Come up with an alternative. (I really *am* actively curious to see what people come up with, you know. )
Quote:
There are cases of apps where a menubar would not be necessary,
Such as? I find that in many apps I use the menubar for a while when I'm learning it, then move to command keys after I'm familiar with the app, and the menubar is there as a nice and convenient backup.
Quote:
there are cases of apps where a some other UI design is better for the amount of commands in the apps,
Example? (I'm not being persnickety, I'm actually intrigued to see these apps. )
Quote:
there could be cases where a pull-down menu system is too limiting. And for a multitasking system, the menubar splits the focus of the user. With ever larger screen resolutions, that focus between app window and menubar is split even further. So there is rationale for moving away from it.
So what do you propose as a replacement for a UI element that:
a) is compact
b) can be expanded to show layers of commands
c) is easy to hit with a cursor
d) can be contextually sensitive
e) solves the additional problems you see?
NeXT had no global menubar. Instead a right-click popped up a vertical menubar whereever your cursor was. Quick, easy, and convenient. Is this the type of thing you're thinking of?
Yes. By definition, is it not? All application UI design must conform to the Menubar and other application guidelines, therefore, all apps are shackled to that design.
This is a feature.
Quote:
There are cases of apps where a menubar would not be necessary, there are cases of apps where a some other UI design is better for the amount of commands in the apps, there could be cases where a pull-down menu system is too limiting.
And there are currently ways to deal with those cases, when they arise. Which is not often.
Quote:
And for a multitasking system, the menubar splits the focus of the user. With ever larger screen resolutions, that focus between app window and menubar is split even further. So there is rationale for moving away from it.
Toward what? That's the interesting question. It's altogether too easy to punt it by handwaving about an API for things that live at the edge of screens, but then what you're doing is rewinding the GUI back to the 1970s. The absolute, baseline, fundamental contribution of the Macintosh to the modern GUI is the "shackling" of applications to standard widgets with standard behaviors whose interactions have been carefully thought through, because applications do not exist in a vacuum. There has been to date no convincing rationale for moving away from that paradigm, and many reasons not to (Motif, to name one).
Exceptions have always been able to cope. Mac OS has supported custom widgets for decades. That doesn't mean there's any value in encouraging their use generally.
Now mate that with smart folders, where the metadata selection is done once at folder creation time, and it becomes highly non-intrusive.
They're cool, but I'm trying to set the bar higher with a natural language interface that interacts with the system in a more wide ranging way.
Quote:
What would you suggest as a UI mechanism that would replace a pull-down menu system, yet still offer the same benefits without adding additional drawbacks, and while solving some problems you see with it?
I think it would depend on the usage patterns of particular applications. I rarely ever use the menubar for web browsers, IM apps, etc. For those kinds of apps, only make readily available the most commonly used functions through buttons or its ilk and hide the rest in a palette or something.
For applications with lots of functions, I don't know. I think it'll be interesting to see what developers come up with. In a way, they are unshackled from the Menubar and are free to come up with something interesting for their particular apps. I think PTC came up with a rather interesting solution for there function (menu) system for Pro/E (prior to Wildfire where they shackled themselves to the MS Windows UI guidelines). Adobe uses lots and lots of palettes.
Quote:
Command keys?
Further evidence that the Menubar isn't what it is purported to be.
Quote:
So what do you propose as a replacement for a UI element that:
a) is compact
b) can be expanded to show layers of commands
c) is easy to hit with a cursor
d) can be contextually sensitive
e) solves the additional problems you see?
NeXT had no global menubar. Instead a right-click popped up a vertical menubar whereever your cursor was. Quick, easy, and convenient. Is this the type of thing you're thinking of?
Of course, it's still a menubar...
No. I was a NeXT user for 3 years, and even then I felt that it was cumbersome. What I am proposing is moving away from pull down menu functionality, not replacement. If there are lots of functions, then the challenge is to come up with a design that is particularly suited for the application. It could well be that a pull down menu is the ideal solution, but I'm curious to see what happens.
I thought it'd be kind of neat if the trackpad on laptops was proportionate to the screen, and functioned(with the help of a modifier key maybe) as a little touch screen. In conjunction with a regular trackpad, that could be kind of neat, I dunno, not that special, but it could work.
...And the most telling signs are that many many of the UI features have come about to stop the use of menubars: button bars, tabbed browsing, contextual menus, etc. Internet age era applications like browsers, newsreaders, IM et al also do not require the heavy usage of the menubar.
me, i simply do not get it.
Quote:
...The Menubar is a good fit for many applications, no doubt, but it isn't for others. In a multitasking system, why anchor the user to the top of the screen when it really should be on the application window?
"application window"? that term somewhat disturbs me. perhaps you should give "ms windows" a chance. actually, that os matches your needs perfectly - as far as i understand you.
i'm all about the minority report-style interface. i saw a concept one time of a mac monitor that had glass panels that could just be popped into place, and you would basically have virtual desktops that existed as a second monitor (dont ask me how all the science behind this works, cause i didnt come up with the idea). but anyways, when tom cruise is moving his arms around and flying stuff everywhere, thats just badass.
ps: obviously you would look crazy in an airport using your comp this way, so maybe it would only apply to desktop computers.
"application window"? that term somewhat disturbs me. perhaps you should give "ms windows" a chance. actually, that os matches your needs perfectly - as far as i understand you.
There aren't that many people who haven't used MS Windows. So, I use it every workday. It has its pluses and minuses just like Mac OS 10 or any other OS. I like the ability to change window size at all sides and corners. I like that apps are mostly contained within its own window. I don't like that the pull-down menu occupies so much space. I don't like the window -within-a-window interface used by many apps. I don't like the constant organizing and drilling through folders for accessing files and such.
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.
I think people are misunderstanding the mEnubar. The idea isn't that you have to go through the menubar for everything. The point is that it's a more compact way to have everything available. So it doesn't matter if it's a bit out of the way or if it requires an extra click. It's there for the stuff you don't use most often but still want access to on occasion. Having all that stuff in context menus, palettes or toolbars would be cumbersome, so it's all stashed into the menubar hierarchy, acessible but out of the way until you need it.
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.
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.
Nope. I've said it already: "... Apple to wean Macintosh users away from the MenuBar." It does not mean I'm asking Apple to replace the MenuBar with a Motif/MS Windows/NeXT/BeOS style pull-down menus. It means that application developers should be free to develop application specific interfaces for the functions in their apps. For instance, a Menubar or pull-down menu doesn't have to be used.
Will the uncommonality of these application specific UIs affect productivity? I'm not sure, especially at the application specific level. I've used computers most of my educated life, and there are a lot of applications I can't use w/o training because the subject matter is totally foreign. Commonality and pull-down menus didn't help whatsoever. Now, with larger screens and Mac OS apps like the single-window style iApps I can see a further dissociation between MenuBar and application. So why break the user focus with the MenuBar?
There will be some common functions for all apps, such as window characteristics, copy/paste, and such, but things like that I think can be left to the operating system.
Nope. I've said it already: "... Apple to wean Macintosh users away from the MenuBar." It does not mean I'm asking Apple to replace the MenuBar with a Motif/MS Windows/NeXT/BeOS style pull-down menus. It means that application developers should be free to develop application specific interfaces for the functions in their apps. For instance, a Menubar or pull-down menu doesn't have to be used.
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.
Quote:
Will the uncommonality of these application specific UIs affect productivity? I'm not sure, especially at the application specific level. I've used computers most of my educated life, and there are a lot of applications I can't use w/o training because the subject matter is totally foreign. Commonality and pull-down menus didn't help whatsoever. Now, with larger screens and Mac OS apps like the single-window style iApps I can see a further dissociation between MenuBar and application. So why break the user focus with the MenuBar?
So let me get this straight... because some apps require training for whatever reason, the menubar doesn't have utility? Er...
Quote:
There will be some common functions for all apps, such as window characteristics, copy/paste, and such, but things like that I think can be left to the operating system.
And one would access them how? Keystrokes? Which would be discovered by the user how, documentation?
Well, it certainly worked for DOS... \
Developers are free to not use a menubar if they wish. 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.
There are basically only four ways of inputting commands to a computer: a pointer on-screen, text input, voice (which is text currently - could be pitch or other musical input), and visual gestures (think pointing, rather like the on-screen version, or symbolic gesturing, rather like sign language... which is much like text again).
So you can either point at what you want that is presented to you, or specify free-form.
The former requires interacting with the computer in either video or audio. (I can't think of a good way to interact haptically for option choices.) You don't want to overwhelm the user with every possible command simultaneously, so you need to present them in a more compact format, but one that's easy to navigate conceptually. So, hierarchic is the current best fit. As audio: think phone tree. Ick. As video: could be pages of choices (DVD menu screens, purely modal), a toolbar (flat list, no hierarchy), or... a hierarchical menu. A menu is semi-modal - you can only drill down one menu tree at a time, but you can still see the rest of your environment, and you can slide sideways to another tree easily... no 'Back' like on DVD menus.
Free-form input is extremely interesting, but requires some serious thought - remember the Infocom games? Remember how frickin' *TEDIOUS* it was when you couldn't figure out what command it was *expecting*? Why? Because you didn't have a list of things to choose from. You had to experiment and guess to see what it would respond to. Annoying. So you end up having to provide the user with the information of what is acceptable in some other format, like a manual. Ouch. So much for ease of use. Cognitive and natural language inputs are quite interesting, and have seen some amazing advances recently, but free-form input is currently going to be essentially text, which means either a keyboard (command line anyone?) or voice recognition. The latter is fraught with peril, but even if the precision of input is *exact*, the contextual and cognitive problems still arise.
The only truly innovative approach I've seen is free-form visual gesturing... grab that, motion that direction and it knows to glom them together, etc... think Minority Report. But guess what... someone had to design the gesture language... again, you have a training problem and it's not obvious by inspection what the system allows at a given moment.
So. Given all that, where we want a choice-based UI method for ease of inspection, need a hierarchical method for ease of navigation, need a non-modal (or at least not fully modal) approach for flexibility, a simple way to back out of performing a selection, and given people's disgust with audio phone trees, probably a visual widget, and given *that* that a screen edge should be used for an infinite depth target...
Comments
Originally posted by Eugene
(1) Complex languages lead to more complex misunderstandings. As a systemwide feature, this would probably do more damage than good, for now.
Complex languages also lead to more productivity. There's a tradeoff somewhere. I just know that with today's number of files, folders, and volume of information, I'm not being as productive as I should be. I don't need to be spending an hour or two every month organization data and email or searching on the internet or through help systems for arcane information on how to do something.
(2) Worst. Idea. Ever.
The Menubar is a shackle upon innovation. It's getting more and more cumbersome as we multitask more and more, especially on larger and larger screens.
Originally posted by THT
Complex languages also lead to more productivity. There's a tradeoff somewhere. I just know that with today's number of files, folders, and volume of information, I'm not being as productive as I should be. I don't need to be spending an hour or two every month organization data and email or searching on the internet or through help systems for arcane information on how to do something.
Hence, metadata. Not input devices or technologies.
The Menubar is a shackle upon innovation. It's getting more and more cumbersome as we multitask more and more, especially on larger and larger screens.
Totally disagree. Name another tool with an infinite target depth.
At *BEST* I can see allowing a user to decide which edge to have it pop up on... or at least which monitor, perhaps 'all', but a 'shackle'? Please.
Originally posted by talksense101
I still like the iSight based kiosk idea where you can pretend you are using a data glove. The UI needs to be remodelled to be a 3D world instead of 2D windows. Voice recognition needs to improve a lot as well.
You mean like... http://rockfish-cs.cs.unc.edu/pubs/TR04-005.pdf ??
Yup, that's one of my projects.
I'm saying that due to physical demands of typing, unix was designed to be a shorthand. The same physical demands of speaking will mean a shorthand will need to be used if you are continually operating a computer. It already happens with speech macros now.
It simply sucks to have to type that much.
It simply sucks to have to mouse around that much. (But mousing is perhaps the least tiresome of them all)
It simply sucks to have to speak that much.
The Mac is nice that it gives you all options for input. That's nice and should always be the case. Up to the user.
But as far as future paradigms, natural speech will not be the primary input, nor will natural language typing. Not for a standard OS.
Sure, I want the OS to understand natural spoken language, recognize handwriting and natural language typing. But until some future technology is devised that we can't fathom, we'll use a mix of input methods.
I don't think any will win over the others since there are myriad uses and users.
Originally posted by Kickaha
Hence, metadata. Not input devices or technologies.
Metadata is vitally important yes. But what would you propose the interface to be? How are we going to take advantage of the metadata? Lots and lots of columns in Finder windows?
Totally disagree. Name another tool with an infinite target depth.
Why would I have to since I am proposing not using a Menubar? I'm proposing moving away from the usage of a pull-down menu system.
For applications with heavy usage of the menubar or applications that require a lot of usage of pull-down menus, I am suggesting using something different. I'm definitely not suggesting abandoning Fitt's Law - that's why I think Apple should have an API for screen edge and screen corner applications, apps that essentially will live on the edges and corners of the screen.
At *BEST* I can see allowing a user to decide which edge to have it pop up on... or at least which monitor, perhaps 'all', but a 'shackle'? Please.
Yes. By definition, is it not? All application UI design must conform to the Menubar and other application guidelines, therefore, all apps are shackled to that design.
There are cases of apps where a menubar would not be necessary, there are cases of apps where a some other UI design is better for the amount of commands in the apps, there could be cases where a pull-down menu system is too limiting. And for a multitasking system, the menubar splits the focus of the user. With ever larger screen resolutions, that focus between app window and menubar is split even further. So there is rationale for moving away from it.
Originally posted by THT
Metadata is vitally important yes. But what would you propose the interface to be? How are we going to take advantage of the metadata? Lots and lots of columns in Finder windows?
See that little search window top right in the Finder toolbar?
iTunes/iPhoto/Xcode/BibDesk (LaTeX .bib file editor - awesome), etc... it's an extremely powerful mechanism.
Now mate that with smart folders, where the metadata selection is done once at folder creation time, and it becomes highly non-intrusive.
Seriously, look at the iApps and Xcode for examples of this in action. (Instant searching across a project's symbol space in Xcode has utterly changed how I develop, I swear.)
Why would I have to since I am proposing not using a Menubar? I'm proposing moving away from the usage of a pull-down menu system.
Let me rephrase it:
What would you suggest as a UI mechanism that would replace a pull-down menu system, yet still offer the same benefits without adding additional drawbacks, and while solving some problems you see with it?
For applications with heavy usage of the menubar or applications that require a lot of usage of pull-down menus, I am suggesting using something different.
Command keys?
I'm definitely not suggesting abandoning Fitt's Law - that's why I think Apple should have an API for screen edge and screen corner applications, apps that essentially will live on the edges and corners of the screen.
No argument there.
Yes. By definition, is it not? All application UI design must conform to the Menubar and other application guidelines, therefore, all apps are shackled to that design.
Sorry, but that makes as much practical sense to me as saying "a window is just a shackle to innovation!". Come up with an alternative. (I really *am* actively curious to see what people come up with, you know.
There are cases of apps where a menubar would not be necessary,
Such as? I find that in many apps I use the menubar for a while when I'm learning it, then move to command keys after I'm familiar with the app, and the menubar is there as a nice and convenient backup.
there are cases of apps where a some other UI design is better for the amount of commands in the apps,
Example? (I'm not being persnickety, I'm actually intrigued to see these apps.
there could be cases where a pull-down menu system is too limiting. And for a multitasking system, the menubar splits the focus of the user. With ever larger screen resolutions, that focus between app window and menubar is split even further. So there is rationale for moving away from it.
So what do you propose as a replacement for a UI element that:
a) is compact
b) can be expanded to show layers of commands
c) is easy to hit with a cursor
d) can be contextually sensitive
e) solves the additional problems you see?
NeXT had no global menubar. Instead a right-click popped up a vertical menubar whereever your cursor was. Quick, easy, and convenient. Is this the type of thing you're thinking of?
Of course, it's still a menubar...
Originally posted by THT
Yes. By definition, is it not? All application UI design must conform to the Menubar and other application guidelines, therefore, all apps are shackled to that design.
This is a feature.
There are cases of apps where a menubar would not be necessary, there are cases of apps where a some other UI design is better for the amount of commands in the apps, there could be cases where a pull-down menu system is too limiting.
And there are currently ways to deal with those cases, when they arise. Which is not often.
And for a multitasking system, the menubar splits the focus of the user. With ever larger screen resolutions, that focus between app window and menubar is split even further. So there is rationale for moving away from it.
Toward what? That's the interesting question. It's altogether too easy to punt it by handwaving about an API for things that live at the edge of screens, but then what you're doing is rewinding the GUI back to the 1970s. The absolute, baseline, fundamental contribution of the Macintosh to the modern GUI is the "shackling" of applications to standard widgets with standard behaviors whose interactions have been carefully thought through, because applications do not exist in a vacuum. There has been to date no convincing rationale for moving away from that paradigm, and many reasons not to (Motif, to name one).
Exceptions have always been able to cope. Mac OS has supported custom widgets for decades. That doesn't mean there's any value in encouraging their use generally.
Originally posted by Kickaha
iTunes/iPhoto/Xcode/BibDesk (LaTeX .bib file editor - awesome), etc... it's an extremely powerful mechanism.
Now mate that with smart folders, where the metadata selection is done once at folder creation time, and it becomes highly non-intrusive.
They're cool, but I'm trying to set the bar higher with a natural language interface that interacts with the system in a more wide ranging way.
What would you suggest as a UI mechanism that would replace a pull-down menu system, yet still offer the same benefits without adding additional drawbacks, and while solving some problems you see with it?
I think it would depend on the usage patterns of particular applications. I rarely ever use the menubar for web browsers, IM apps, etc. For those kinds of apps, only make readily available the most commonly used functions through buttons or its ilk and hide the rest in a palette or something.
For applications with lots of functions, I don't know. I think it'll be interesting to see what developers come up with. In a way, they are unshackled from the Menubar and are free to come up with something interesting for their particular apps. I think PTC came up with a rather interesting solution for there function (menu) system for Pro/E (prior to Wildfire where they shackled themselves to the MS Windows UI guidelines). Adobe uses lots and lots of palettes.
Command keys?
Further evidence that the Menubar isn't what it is purported to be.
So what do you propose as a replacement for a UI element that:
a) is compact
b) can be expanded to show layers of commands
c) is easy to hit with a cursor
d) can be contextually sensitive
e) solves the additional problems you see?
NeXT had no global menubar. Instead a right-click popped up a vertical menubar whereever your cursor was. Quick, easy, and convenient. Is this the type of thing you're thinking of?
Of course, it's still a menubar...
No. I was a NeXT user for 3 years, and even then I felt that it was cumbersome. What I am proposing is moving away from pull down menu functionality, not replacement. If there are lots of functions, then the challenge is to come up with a design that is particularly suited for the application. It could well be that a pull down menu is the ideal solution, but I'm curious to see what happens.
Originally posted by THT
...And the most telling signs are that many many of the UI features have come about to stop the use of menubars: button bars, tabbed browsing, contextual menus, etc. Internet age era applications like browsers, newsreaders, IM et al also do not require the heavy usage of the menubar.
me, i simply do not get it.
...The Menubar is a good fit for many applications, no doubt, but it isn't for others. In a multitasking system, why anchor the user to the top of the screen when it really should be on the application window?
"application window"? that term somewhat disturbs me. perhaps you should give "ms windows" a chance. actually, that os matches your needs perfectly - as far as i understand you.
...circa 1982
(mostly kidding BTW!)
Note:
- Rounded filename rects on left (sans icons). So rounded filenames -is- a Mac thang, not a NeXT thang...
- Nice and messy file arrangement - must have annoyed Steve
- Mmmm...5.25" diskette image as folder/drive window
- Yay! File extensions on a Mac! In 1982
- Commands as clickable, draggable objects not in a menu...hmmm, where'd NeXT/Steve get that idea?
- Do It command. MAN I need one of those.
(From www.folklore.org, great site!)
ps: obviously you would look crazy in an airport using your comp this way, so maybe it would only apply to desktop computers.
Originally posted by Vox Barbara
"application window"? that term somewhat disturbs me. perhaps you should give "ms windows" a chance. actually, that os matches your needs perfectly - as far as i understand you.
There aren't that many people who haven't used MS Windows. So, I use it every workday. It has its pluses and minuses just like Mac OS 10 or any other OS. I like the ability to change window size at all sides and corners. I like that apps are mostly contained within its own window. I don't like that the pull-down menu occupies so much space. I don't like the window -within-a-window interface used by many apps. I don't like the constant organizing and drilling through folders for accessing files and such.
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.
Originally posted by Kickaha
At *BEST* I can see allowing a user to decide which edge to have it pop up on... or at least which monitor, perhaps 'all', but a 'shackle'? Please.
You mean, like *cough*Windows*cough*?
Originally posted by BuonRotto
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.
Nope. I've said it already: "... Apple to wean Macintosh users away from the MenuBar." It does not mean I'm asking Apple to replace the MenuBar with a Motif/MS Windows/NeXT/BeOS style pull-down menus. It means that application developers should be free to develop application specific interfaces for the functions in their apps. For instance, a Menubar or pull-down menu doesn't have to be used.
Will the uncommonality of these application specific UIs affect productivity? I'm not sure, especially at the application specific level. I've used computers most of my educated life, and there are a lot of applications I can't use w/o training because the subject matter is totally foreign. Commonality and pull-down menus didn't help whatsoever. Now, with larger screens and Mac OS apps like the single-window style iApps I can see a further dissociation between MenuBar and application. So why break the user focus with the MenuBar?
There will be some common functions for all apps, such as window characteristics, copy/paste, and such, but things like that I think can be left to the operating system.
Originally posted by THT
Nope. I've said it already: "... Apple to wean Macintosh users away from the MenuBar." It does not mean I'm asking Apple to replace the MenuBar with a Motif/MS Windows/NeXT/BeOS style pull-down menus. It means that application developers should be free to develop application specific interfaces for the functions in their apps. For instance, a Menubar or pull-down menu doesn't have to be used.
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.
Will the uncommonality of these application specific UIs affect productivity? I'm not sure, especially at the application specific level. I've used computers most of my educated life, and there are a lot of applications I can't use w/o training because the subject matter is totally foreign. Commonality and pull-down menus didn't help whatsoever. Now, with larger screens and Mac OS apps like the single-window style iApps I can see a further dissociation between MenuBar and application. So why break the user focus with the MenuBar?
So let me get this straight... because some apps require training for whatever reason, the menubar doesn't have utility? Er...
There will be some common functions for all apps, such as window characteristics, copy/paste, and such, but things like that I think can be left to the operating system.
And one would access them how? Keystrokes? Which would be discovered by the user how, documentation?
Well, it certainly worked for DOS...
Developers are free to not use a menubar if they wish. 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.
There are basically only four ways of inputting commands to a computer: a pointer on-screen, text input, voice (which is text currently - could be pitch or other musical input), and visual gestures (think pointing, rather like the on-screen version, or symbolic gesturing, rather like sign language... which is much like text again).
So you can either point at what you want that is presented to you, or specify free-form.
The former requires interacting with the computer in either video or audio. (I can't think of a good way to interact haptically for option choices.) You don't want to overwhelm the user with every possible command simultaneously, so you need to present them in a more compact format, but one that's easy to navigate conceptually. So, hierarchic is the current best fit. As audio: think phone tree. Ick. As video: could be pages of choices (DVD menu screens, purely modal), a toolbar (flat list, no hierarchy), or... a hierarchical menu. A menu is semi-modal - you can only drill down one menu tree at a time, but you can still see the rest of your environment, and you can slide sideways to another tree easily... no 'Back' like on DVD menus.
Free-form input is extremely interesting, but requires some serious thought - remember the Infocom games? Remember how frickin' *TEDIOUS* it was when you couldn't figure out what command it was *expecting*? Why? Because you didn't have a list of things to choose from. You had to experiment and guess to see what it would respond to. Annoying. So you end up having to provide the user with the information of what is acceptable in some other format, like a manual. Ouch. So much for ease of use. Cognitive and natural language inputs are quite interesting, and have seen some amazing advances recently, but free-form input is currently going to be essentially text, which means either a keyboard (command line anyone?) or voice recognition. The latter is fraught with peril, but even if the precision of input is *exact*, the contextual and cognitive problems still arise.
The only truly innovative approach I've seen is free-form visual gesturing... grab that, motion that direction and it knows to glom them together, etc... think Minority Report. But guess what... someone had to design the gesture language... again, you have a training problem and it's not obvious by inspection what the system allows at a given moment.
So. Given all that, where we want a choice-based UI method for ease of inspection, need a hierarchical method for ease of navigation, need a non-modal (or at least not fully modal) approach for flexibility, a simple way to back out of performing a selection, and given people's disgust with audio phone trees, probably a visual widget, and given *that* that a screen edge should be used for an infinite depth target...
What do you suggest?