The simple and tragic answer might be that this forces developers to simplify their user interfaces so that they don't hide essential features under a context menu.
Bah Humbug to that!
Why would Apple put contexual menues to be accessed by the control key if they didn't expect users to, to, well, use them?
By the way, we have to remember that ever since Steve came back, it's not Apple inc., but Steve inc.
It's not Apple that makes these desisions, but Steve. Things will change, not when Apple's interface team says so, but when Steve says so.
If Steve doesn't want a 2 button mouse, then there won't be one. Period.
And OS X doesn't just support a 2 button mouse, it supports a 3 button mouse with scrollwheel. JUST LIKE LINUX AND OTHER UNIX'S DO.
Besides, if Apple's going to start using contextual menus, they NEED a right button.
They've had contextual menus for years, and no right button. In fact, they added the "gear" menu instead, so that you can get a context menu with a single click.
Quote:
I think Apple should give a CHOICE to users.
You can plug in any of the hundreds of USB mice and expect it to work. What do you want? Apple is giving you a choice right now: If they didn't ship a one button mouse, no-one else would.
Quote:
Maybe ship the KB and mouse seperately. Maybe they should offer various mouse and keyboard options like from other vendors.
They do. Try configuring a Mac mini, or just look in the "Accessories" pages in the Apple Store.
Finally, if anyone ever wants to meet a whole bunch of people who have not gotten "right click" in ten years of Windows use, I'd be happy to introduce you.
All that said, I can see Apple trying to meet people halfway. That's what the mini represents, after all. The challenges are: The mouse has to be ergonomic. Currently, the overwhelming majority of multibutton mice are poor, and scroll wheels are worse. The studies have been done, and the resulting RSI is epidemic and costing the US billions of dollars per year. If you haven't suffered it yet, you're either lucky or using the mouse sparely and correctly. Also, Apple mice are designed for all ages. The current mouse can be easily moved and clicked by the entire hand of a small child. If Apple does offer a mouse that is not designed for all ages, it will not ship standard.
This mouse wouldn't be for pros, who have had a vast selection of mice to choose from for years (of course, some pros will buy it). It wouldn't be for our recently acquired UNIX workstation users (including Motion users) since UNIX apps expect the aboriginal three-button mouse (with no scroll wheel) that has been shipping with UNIX workstations since the first XTerms (and with Xerox's graphical systems before that). This is for switchers. It's for mini customers in particular, since the mini doesn't come with a keyboard or mouse. It's an opportunity to make a little more money off people who've just gotta have the extra button, and I can believe it'll be wireless and cool-looking so that people who already have a (wired, conventional) PC mouse have a reason to throw it in the cart.
I expect the one-button mouse to continue to ship standard.
Kickaha, I have to come in here to share Junkyard Dawg?s ?embarrassment?, because honestly, his posting was just spot-on. The more I read in this thread about this argument of ?discoverability?, the more convinced I am that JD understands it, and you and all the other menu bar fans are labouring under a delusion. You?re all stating that actions on a menu bar are ?discoverable? and actions on a context menu are ?hidden?, as though that was an obvious truth. I don?t think it is. Here?s why...
Unfortunately, UI study after UI study says that both you and JD are wrong, but you do raise what looks to be on the surface an interesting argument, so let's drill deeper...
Quote:
You have an object on screen that you want to perform an action on. Two ways to do it; a) the context menu, or b) the menu bar. Method a): right-click the object. The program knows what the object is, and displays a context menu with actions appropriate to the object. Method b): left-click the object, move the cursor up to the menu bar, and click again on the menu item (out of probably half-a-dozen or so items) that you think has the action you need. If you get it wrong, as I do frequently, shuttle the mouse from side to side until you get it right. Now to my mind, method a is a lot more ?discoverable? than method b.
Discoverable does not mean 'find where the action you already know about resides', discoverable means 'find out what the application can *do*'. Menus are a fast way of listing all the actions that a user could do, in a format that they can quickly scan. If all the actions are in the menus, then scanning them takes just a few seconds. The equivalent with contextual menus would mean having at least one instance of every kind of object the app could work with on screen, and *then* clicking on each one in turn.
Quote:
OK, you do need to know that you can right-click to pull up a context menu, but on the Windows platform, that is becoming more and more an accepted convention. And that?s happening because it?s very convenient. A string of menu bar items and a plethora of toolbars can be really bewildering - very often it?s not obvious what you need to click on.
Newsflash: apps with a plethora of toolbars are a rarity on the Mac, and fall into the 'crap' bin quickly. MS Office being an exception, unfortunately. Seriously, most apps don't have toolbars like you're thinking of. There is *a* Toolbar in many apps that is user-configurable, but just the one. The analogue on the Mac is the Inspector palette, which keeps things cleaner, but even then can get rather overdone. (Pages, I'm looking in your direction.) In general, we simply don't have that visual clutter and "Oh god, what do I do now?" feel.
Quote:
Much easier to just right-click on something, and let the program throw up a list of appropriate actions. The concept is easily understood, even by beginners.
As long as they know they can click on that object, and they already have an idea of what that object is, and what they want to do, sure. Context menus are great for *efficiency* "Okay, I know I want to do task X on that thingy there, but I can't remember what menu it's under so... (right-click) ah, there it is." This is different than "I have no idea where to even start with this app." The process of *discovering* what the app can do is quite different.
Quote:
I?ve taught people to use MS Word. This is the sort of thing that happens very often: they?ve got some text selected that they want to copy. I say ?ok, copy, it?s on the menu bar under edit?. They look at the screen. Along the top are the words ?File Edit View etc.? Under that are a couple of rows of buttons. They?ve no idea where to click; they don?t know what a menu bar is.
*laugh* Hell, *I* don't know where to click in Word most of the time... you picked probably one of the biggest UI dogs out there for your example.
Quote:
More importantly, they don?t realise that if they click on the words at the top, a list of other words will appear underneath. And why should they? It?s not intuitively obvious; you just learn it by experience. The same way that Windows users learn about right-clicking.
Yes, but a) the menu bar never moves on them, b) it's always there, c) it's quickly scannable...
Right-clicking is, as you note, on a per object basis. That means *some* objects are right-clickable, and *some* are not. They have to learn which ones are, and which ones aren't. In each app. Menu bar? One thing to learn.
Remember, we're talking about discovering how the program works here, not long-term use, or trying to remember where something is in the menus. I'm a fan of contextual menus as well... as a *secondary* system for interaction. They're there for efficiency, and they do an excellent job of it. I have multi-button mice on all my machines for a good reason. But for *learning* an app, they blow chunks without a guru watching over your shoulder, telling you what you can and cannot do when.
"Read the manual!" I hear... guess what... I haven't had to read a manual for an app in years. A couple of years ago, my advisor and I had to submit a video to the UIST conference (yes, a UI conference), and he was panicking. We have a video editing suite in the dept (UNC-CH) for all the graphics guys to do their VR voodoo on for talks and such, but *nobody* knows how to effectively use it. (They give seminars in the basics that last for hours.) I told him to grab a FireWire DV camera, and we'd do it instead. He filmed it, I plugged it into my PowerBook, launched iMovie. In 20 minutes we had an edited movie, complete with titles, transitions, you name it. He looks at me and says "I didn't know you did video editing!" "I don't, this is the first time I've sat down at this app."
Everything was easy to figure out, everything was laid out nicely, and looking through the menus *first* gave me a good idea of what the app could do, and how I was to do it. If I'd had to right-click on everything just to figure out what I could do, it would have been a nightmare.
Users can see objects on screen, the nouns. What they can't see are the verbs, the actions. (Unless you make everything a toolbar button, and then they have to figure out what the icons mean.) Menus give them essentially a dictionary for the app: "Here are all the things you can do, listed and in a reasonable logical ordering." This gets them thinking in the app's methodology, and quickly. *THEN* once they figure out what to do, and how to do it, contextual menus give them speed. This is what I've been saying all along: menu bar for discoverability, contextual menu for speed. Two levels of access that have different purposes, and different approaches. Each does its own job very effectively.
Quote:
I actually hate menu bars. I?ve seen so many programs trying to fit their various options around this straight-jacket format of ?File, Edit, View, whatever? when it just doesn?t apply, and it makes it really difficult to find things. I bet a lot of applications could do without a menu bar altogether.
I've seen apps with minimal menu bars, sure... but you're always going to have to quit the app somehow, right?
Also, the Mac has *one* menu bar, top of screen. It is always there, period. When your app is activated, it *WILL* have a menu bar, unless you make it a Utility Palette or some such. At the very minimum, it will have the application menu which controls preferences, quitting, and visibility.
And basically, if a developer can't organize their app's feature into a menu bar, they really need to find another line of work, or hand off the UI development to someone who is talented in it. It's not difficult, nor is it a straight-jacket, unless the dev simply hasn't the imagination for it. No real shame there, UI design is not the same task as coding, and it takes a different set of skills and experiences.
It sounds like your vitriol is based on the *Windows* version of the menu bar (and toolbars). I agree with you there: they stink, in general. On the Mac, not so much. The menu bars are *one* way of accessing app features, the contextual menus are *another* way. But given that discoverability is a cornerstone of the Mac experience, the menu bar as the *primary* method of interaction has to be maintained... and frankly, developers like you are the reason we still have one-button mice. \
FOCUS Enhancements Demos Wireless, Ultra Wideband Transmission of High-Def TV Streams
Category: Home Networking Gear - May 02, 2005
By PRESS RELEASE
FOCUS Enhancements, Inc.'s semiconductor group is successfully demonstrating the transmission of two high-definition TV (HDTV) streams through walls at its Hillsboro, OR, facility. This exciting development is another successful step toward the ultimate goal of enabling consumer products that will transmit multiple HD streams throughout the home based on FOCUS UWB chipsets later this year. This industry-leading technology extends the WiMedia/MBOA UWB Standard to better meet the requirements of video and high-speed data distribution through the home and office of the future.
FOCUS Enhancements' UWB technology will create a true personal area network (PAN) larger than ten feet with the ability to deliver rich media and crisp video content to UWB receivers. Its innovative technology is seamlessly interoperable with the WiMedia/MBOA UWB Standard while also extending performance in two critical areas -- data rate and range. UWB will extend the performance of next-generation personal/digital video recorders, TVs, set-top boxes, Media PCs, and DVD players.
"UWB is the standard that makes next-generation, high-performance wireless networks possible for real world applications, enabling the delivery of high-resolution and high-quality digital media throughout the home," said Tom Hamilton, executive vice president and general manager of FOCUS Enhancements' semiconductor group. "Market interest is found in the wireless inter-connection of devices like TVs and home entertainment systems which will exchange music, photos, and video as well as store and distribute media. Our UWB technology is taking wireless to the next level with an emphasis on transmission quality for distance and speed."
Mike Kelly, vice president of marketing for FOCUS Enhancements' semiconductor group, stated, "FOCUS has essentially doubled the Institute for Electrical and Electronic Engineering's (IEEE's) targets of 110 Mbps at a distance of 10 meters. Other solutions fall short when trying to deliver sustained high-resolution video over longer distances and are not very tolerant of things getting in the way of the signal. We are overcoming these obstacles -- now with two HD streams through a wall -- and have something that is practical for use by consumers in the home."
FOCUS Enhancements expects to sample UWB chip-sets in the third quarter of 2005 and modules containing UWB chip-sets later in the year. Performance expectations are anticipated to range from 880 Megabits per second (Mbps) at 8 meters to 37 Mbps at around 40-plus meters.
About FOCUS Enhancements, Inc.
FOCUS Enhancements Inc. (NASDAQ: FCSE) is a leading designer of world-class solutions in advanced, proprietary video technology. Headquartered in Campbell, CA, FOCUS Enhancements designs, develops, and markets video solutions in two distinct markets: advanced proprietary video conversion integrated circuits (ICs) and affordable, high-quality, digital-video conversion and video production equipment. Semiconductor IC products include designs for PCs, game cards, Internet, set-top boxes, Internet appliances, and interactive TV applications, and they are sold directly to original equipment manufacturers (OEMs). FOCUS Enhancements' complete line of video presentation and video production devices are sold globally through resellers and distributors to the broadcast, education, cable, business, industrial, presentation, Internet, gaming, home video production and home theater markets. More information on FOCUS Enhancements may be obtained from the company's SEC filings, or by visiting the FOCUS Enhancements home page at
FOCUS Enhancements Demos Wireless, Ultra Wideband Transmission of High-Def TV Streams
Category: Home Networking Gear - May 02, 2005
By PRESS RELEASE
FOCUS Enhancements, Inc.'s semiconductor group is successfully demonstrating the transmission of two high-definition TV (HDTV) streams through walls at its Hillsboro, OR, facility. This exciting development is another successful step toward the ultimate goal of enabling consumer products that will transmit multiple HD streams throughout the home based on FOCUS UWB chipsets later this year. This industry-leading technology extends the WiMedia/MBOA UWB Standard to better meet the requirements of video and high-speed data distribution through the home and office of the future.
I just saw this at the E3 Expo here in the NY Hilton last thursday, and over the weekend.
It has a ways to go yet. I hope that it's better than Sony's Tv Everywhere concept.
By the way, since we're on this, briefly, I also saw HP and Samsung's new (July and June releases) 65" and 67" 1080p DLP rear projectors (about 18-20" deep) with real 1080p material. Amazingly enough my wife wants to get one this summer.
Yes, I admit it is a bit violent! I'm going to put an option to fade the rainbow so people don't get eyestrain. Please don't sue me!
Quote:
Interesting UI, that's for sure. I can't say I like it, at all, sorry.
No worries - I realise not everyone will take to it. It gives me eye-ache sometimes.
Quote:
You may want to look at FontBook
I've seen the screenshots for FontBook. Like all existing font managers, it shows you a list of font names which you need to click on (or in FontBook, double-click) to see a preview one at a time. Now, from a user interface point of view, having the sample text visible all the time for all fonts without any clicking at all surely has to be better. My Windows users tell me it is. Thanks for the tip though.
Quote:
And I'm sorry, but your app's UI hasn't exactly led me to change my mind regarding single button mice. In fact, it's rather strengthened my opinion.
Let me give you a quick example of why I was dismayed to find out about one-button mice. My option boxes can be set positively or negatively. To set positively, left-click. Negatively, right-click. Left-click to clear. Very quick, very user-friendly. Now for my Apple version, I have to find another way. So I have to program a method which is slower and clumsier in order to cater for a manufacturer which refuses to move with the times. Now I'm trying very hard to be impartial, but this doesn't seem like the one-button mouse is forcing me into good UI practices, does it?
As for a menu bar, I guess we'd agree that there's no way a menu bar would make this easier to do. You would say presumably that I should put a menu bar option called 'Option box', under which would be items 'Positive' and 'Negative'. Hmm. I could do that, but then see what happens - the option box has to be drawn differently to show that it's been selected. So now, the left-click can't be used to set the option box positively, because it has to be used to select the object. So what the menu bar has effectively done is to replace my quick easy way with a slow clunky way. This is why I'm feeling aggrieved.
Let me give you a quick example of why I was dismayed to find out about one-button mice. My option boxes can be set positively or negatively. To set positively, left-click. Negatively, right-click. Left-click to clear. Very quick, very user-friendly. Now for my Apple version, I have to find another way. So I have to program a method which is slower and clumsier in order to cater for a manufacturer which refuses to move with the times. Now I'm trying very hard to be impartial, but this doesn't seem like the one-button mouse is forcing me into good UI practices, does it?
Just make the right click a control-click and document it! oh and add the platinum theme to it. if you need any help with the design I don't mind helping.
Just make the right click a control-click and document it! oh and add the platinum theme to it. if you need any help with the design I don't mind helping.
Thanks for the offer - I will bear it in mind.
Yes, control-click is one of my options, but I don't really like it; instead of tapping one finger a half a centimetre, I have to bring my left hand up to the keyboard and fumble for a key! Now, honestly, is that a better way?
Yes, control-click is one of my options, but I don't really like it; instead of tapping one finger a half a centimetre, I have to bring my left hand up to the keyboard and fumble for a key! Now, honestly, is that a better way?
no i have a two-button mouse. It's not the criticism of second function clicking but the hidden contextual menus that are not intuitive. You have no idea what menu right-clicking will reveal so it's a bad design, however, a right click as a second function is different.
Yes, I admit it is a bit violent! I'm going to put an option to fade the rainbow so people don't get eyestrain. Please don't sue me!
No worries - I realise not everyone will take to it. It gives me eye-ache sometimes.
Heh, no worries. There are *much* worse UIs out there.
Quote:
I've seen the screenshots for FontBook. Like all existing font managers, it shows you a list of font names which you need to click on (or in FontBook, double-click) to see a preview one at a time. Now, from a user interface point of view, having the sample text visible all the time for all fonts without any clicking at all surely has to be better. My Windows users tell me it is. Thanks for the tip though.
I can't argue with that. In fact, I'd *love* to see that functionality in a font app.
Quote:
Let me give you a quick example of why I was dismayed to find out about one-button mice. My option boxes can be set positively or negatively. To set positively, left-click. Negatively, right-click. Left-click to clear. Very quick, very user-friendly. Now for my Apple version, I have to find another way. So I have to program a method which is slower and clumsier in order to cater for a manufacturer which refuses to move with the times. Now I'm trying very hard to be impartial, but this doesn't seem like the one-button mouse is forcing me into good UI practices, does it?
Okay, a UI purist would argue that you're trying to use a two-state UI element (checkbox) for a three-state choice (pos, neg, off), and that you're improperly using the widget.
BUT, I see what you're trying to do, and can offer up one way I've seen something similar handled. Tab stops in Pages are multi-state, in that instead of having a palette of tab types, you just click somewhere in the document ruler, and a left-tab appears. Clicking on it again converts it to a mid-tab, and subsequent clicks cycle it through right, decimal, etc. *Or*, ctrl-click pops up a menu of choices for direct access.
Alternately, you could break it out into two checkboxes, one for enable/disable in the search, and the second for pos/neg. Heck, disclosure triangles could be used to control the inclusion in the search, with the drop down offering options for that attribute.
Or, clicking on the name toggles on/off (with off greying out the text), and a single checkbox for making it negative.
In any case, it's best to use a custom icon for the multi-state widget, perhaps just a nice +, - layered over a Cocoa recessed button standard widget.
*So* many options to play with.
No straightjacket.
Quote:
As for a menu bar, I guess we'd agree that there's no way a menu bar would make this easier to do. You would say presumably that I should put a menu bar option called 'Option box', under which would be items 'Positive' and 'Negative'. Hmm. I could do that, but then see what happens - the option box has to be drawn differently to show that it's been selected. So now, the left-click can't be used to set the option box positively, because it has to be used to select the object. So what the menu bar has effectively done is to replace my quick easy way with a slow clunky way. This is why I'm feeling aggrieved.
Understood, but look at it this way: anytime you see an *identifiable* clickable widget on screen (button, slider, etc), *that is the object*. It *becomes* the discoverable way of interaction for the verb it represents. Menus are required for verbs *which cannot be easily signified by a widget*. Toolbars bastardize this horribly, IMO, especially when people try and make them the *primary* interaction method. Like contextual menus, they should be secondary to the menu bar for pure verbs.
Actually, if you think about it, checkboxes and the like are almost always used to set an attribute: they are the adjectives and adverbs. Pure verbs can't really be represented that way, and have to go in menus to be easily understood at a glance.
So in your case, you have an object (search criteria) and you are modifying an attribute of it (positive/negative). A UI widget is appropriate.
Notice that you had to use verbose phrasing in your large buttons across the top though... imagine instead if those were in the menu bar... *and* you had nice small icons in a user configurable toolbar. A new user could quickly scan the menus and say "Ah! I can do X, Y, and Z, cool." A seasoned user could quickly alter the toolbar to meet their needs. *You* don't have to redesign the UI every time you want to add new functionality. Add it to the menu bar, provide an icon for a toolbar button, link that to the menu bar, and you're *done*.
Sound difficult? With the Cocoa frameworks, you get this for free in your app. It's obscenely easy.
Thanks for your suggestions - I will give them due consideration, although there are practical problems with all of them. I have now read through the Apple UI guidelines (and very well-written and sensible they are) and I'm starting to see where you guys are coming from with this menu bar business. So there is only the one menu bar for all visible applications! Hmm. OK, my toolbar could be converted into a menu bar, but each item on the bar would actually be an action, not the route into a sub-menu. Would this accord with Apple usage?
Thanks for your suggestions - I will give them due consideration, although there are practical problems with all of them. I have now read through the Apple UI guidelines (and very well-written and sensible they are) and I'm starting to see where you guys are coming from with this menu bar business. So there is only the one menu bar for all visible applications! Hmm. OK, my toolbar could be converted into a menu bar, but each item on the bar would actually be an action, not the route into a sub-menu. Would this accord with Apple usage?
why not make an "inspector" these are small windows with actions etc.
Mine already did - this has got to go in the 'phony leaks to flush out mole' category surely.
No way.
Apple must realize that not all users have two arm. I have a client that lost one arm as a child and there is no way she can hold ctrl and use a mouse.....
It would have been nice if Apple made it a no cost option when she bought her $1500 computer instead of having to put it in the trash and buy at additional cost a two button mouse.
You can get options when you buy from Apple. They should have options for people with disabilites rather than trying to carry on a tradition of the one button mouse.
Comments
Originally posted by Henriok
The simple and tragic answer might be that this forces developers to simplify their user interfaces so that they don't hide essential features under a context menu.
Bah Humbug to that!
Why would Apple put contexual menues to be accessed by the control key if they didn't expect users to, to, well, use them?
By the way, we have to remember that ever since Steve came back, it's not Apple inc., but Steve inc.
It's not Apple that makes these desisions, but Steve. Things will change, not when Apple's interface team says so, but when Steve says so.
If Steve doesn't want a 2 button mouse, then there won't be one. Period.
And OS X doesn't just support a 2 button mouse, it supports a 3 button mouse with scrollwheel. JUST LIKE LINUX AND OTHER UNIX'S DO.
Originally posted by slughead
Besides, if Apple's going to start using contextual menus, they NEED a right button.
They've had contextual menus for years, and no right button. In fact, they added the "gear" menu instead, so that you can get a context menu with a single click.
I think Apple should give a CHOICE to users.
You can plug in any of the hundreds of USB mice and expect it to work. What do you want? Apple is giving you a choice right now: If they didn't ship a one button mouse, no-one else would.
Maybe ship the KB and mouse seperately. Maybe they should offer various mouse and keyboard options like from other vendors.
They do. Try configuring a Mac mini, or just look in the "Accessories" pages in the Apple Store.
Finally, if anyone ever wants to meet a whole bunch of people who have not gotten "right click" in ten years of Windows use, I'd be happy to introduce you.
All that said, I can see Apple trying to meet people halfway. That's what the mini represents, after all. The challenges are: The mouse has to be ergonomic. Currently, the overwhelming majority of multibutton mice are poor, and scroll wheels are worse. The studies have been done, and the resulting RSI is epidemic and costing the US billions of dollars per year. If you haven't suffered it yet, you're either lucky or using the mouse sparely and correctly. Also, Apple mice are designed for all ages. The current mouse can be easily moved and clicked by the entire hand of a small child. If Apple does offer a mouse that is not designed for all ages, it will not ship standard.
This mouse wouldn't be for pros, who have had a vast selection of mice to choose from for years (of course, some pros will buy it). It wouldn't be for our recently acquired UNIX workstation users (including Motion users) since UNIX apps expect the aboriginal three-button mouse (with no scroll wheel) that has been shipping with UNIX workstations since the first XTerms (and with Xerox's graphical systems before that). This is for switchers. It's for mini customers in particular, since the mini doesn't come with a keyboard or mouse. It's an opportunity to make a little more money off people who've just gotta have the extra button, and I can believe it'll be wireless and cool-looking so that people who already have a (wired, conventional) PC mouse have a reason to throw it in the cart.
I expect the one-button mouse to continue to ship standard.
Originally posted by RainbowGuy
Kickaha, I have to come in here to share Junkyard Dawg?s ?embarrassment?, because honestly, his posting was just spot-on. The more I read in this thread about this argument of ?discoverability?, the more convinced I am that JD understands it, and you and all the other menu bar fans are labouring under a delusion. You?re all stating that actions on a menu bar are ?discoverable? and actions on a context menu are ?hidden?, as though that was an obvious truth. I don?t think it is. Here?s why...
Unfortunately, UI study after UI study says that both you and JD are wrong, but you do raise what looks to be on the surface an interesting argument, so let's drill deeper...
You have an object on screen that you want to perform an action on. Two ways to do it; a) the context menu, or b) the menu bar. Method a): right-click the object. The program knows what the object is, and displays a context menu with actions appropriate to the object. Method b): left-click the object, move the cursor up to the menu bar, and click again on the menu item (out of probably half-a-dozen or so items) that you think has the action you need. If you get it wrong, as I do frequently, shuttle the mouse from side to side until you get it right. Now to my mind, method a is a lot more ?discoverable? than method b.
Discoverable does not mean 'find where the action you already know about resides', discoverable means 'find out what the application can *do*'. Menus are a fast way of listing all the actions that a user could do, in a format that they can quickly scan. If all the actions are in the menus, then scanning them takes just a few seconds. The equivalent with contextual menus would mean having at least one instance of every kind of object the app could work with on screen, and *then* clicking on each one in turn.
OK, you do need to know that you can right-click to pull up a context menu, but on the Windows platform, that is becoming more and more an accepted convention. And that?s happening because it?s very convenient. A string of menu bar items and a plethora of toolbars can be really bewildering - very often it?s not obvious what you need to click on.
Newsflash: apps with a plethora of toolbars are a rarity on the Mac, and fall into the 'crap' bin quickly. MS Office being an exception, unfortunately. Seriously, most apps don't have toolbars like you're thinking of. There is *a* Toolbar in many apps that is user-configurable, but just the one. The analogue on the Mac is the Inspector palette, which keeps things cleaner, but even then can get rather overdone. (Pages, I'm looking in your direction.) In general, we simply don't have that visual clutter and "Oh god, what do I do now?" feel.
Much easier to just right-click on something, and let the program throw up a list of appropriate actions. The concept is easily understood, even by beginners.
As long as they know they can click on that object, and they already have an idea of what that object is, and what they want to do, sure. Context menus are great for *efficiency* "Okay, I know I want to do task X on that thingy there, but I can't remember what menu it's under so... (right-click) ah, there it is." This is different than "I have no idea where to even start with this app." The process of *discovering* what the app can do is quite different.
I?ve taught people to use MS Word. This is the sort of thing that happens very often: they?ve got some text selected that they want to copy. I say ?ok, copy, it?s on the menu bar under edit?. They look at the screen. Along the top are the words ?File Edit View etc.? Under that are a couple of rows of buttons. They?ve no idea where to click; they don?t know what a menu bar is.
*laugh* Hell, *I* don't know where to click in Word most of the time... you picked probably one of the biggest UI dogs out there for your example.
More importantly, they don?t realise that if they click on the words at the top, a list of other words will appear underneath. And why should they? It?s not intuitively obvious; you just learn it by experience. The same way that Windows users learn about right-clicking.
Yes, but a) the menu bar never moves on them, b) it's always there, c) it's quickly scannable...
Right-clicking is, as you note, on a per object basis. That means *some* objects are right-clickable, and *some* are not. They have to learn which ones are, and which ones aren't. In each app. Menu bar? One thing to learn.
Remember, we're talking about discovering how the program works here, not long-term use, or trying to remember where something is in the menus. I'm a fan of contextual menus as well... as a *secondary* system for interaction. They're there for efficiency, and they do an excellent job of it. I have multi-button mice on all my machines for a good reason. But for *learning* an app, they blow chunks without a guru watching over your shoulder, telling you what you can and cannot do when.
"Read the manual!" I hear... guess what... I haven't had to read a manual for an app in years. A couple of years ago, my advisor and I had to submit a video to the UIST conference (yes, a UI conference), and he was panicking. We have a video editing suite in the dept (UNC-CH) for all the graphics guys to do their VR voodoo on for talks and such, but *nobody* knows how to effectively use it. (They give seminars in the basics that last for hours.) I told him to grab a FireWire DV camera, and we'd do it instead. He filmed it, I plugged it into my PowerBook, launched iMovie. In 20 minutes we had an edited movie, complete with titles, transitions, you name it. He looks at me and says "I didn't know you did video editing!" "I don't, this is the first time I've sat down at this app."
Everything was easy to figure out, everything was laid out nicely, and looking through the menus *first* gave me a good idea of what the app could do, and how I was to do it. If I'd had to right-click on everything just to figure out what I could do, it would have been a nightmare.
Users can see objects on screen, the nouns. What they can't see are the verbs, the actions. (Unless you make everything a toolbar button, and then they have to figure out what the icons mean.) Menus give them essentially a dictionary for the app: "Here are all the things you can do, listed and in a reasonable logical ordering." This gets them thinking in the app's methodology, and quickly. *THEN* once they figure out what to do, and how to do it, contextual menus give them speed. This is what I've been saying all along: menu bar for discoverability, contextual menu for speed. Two levels of access that have different purposes, and different approaches. Each does its own job very effectively.
I actually hate menu bars. I?ve seen so many programs trying to fit their various options around this straight-jacket format of ?File, Edit, View, whatever? when it just doesn?t apply, and it makes it really difficult to find things. I bet a lot of applications could do without a menu bar altogether.
I've seen apps with minimal menu bars, sure... but you're always going to have to quit the app somehow, right?
Also, the Mac has *one* menu bar, top of screen. It is always there, period. When your app is activated, it *WILL* have a menu bar, unless you make it a Utility Palette or some such. At the very minimum, it will have the application menu which controls preferences, quitting, and visibility.
And basically, if a developer can't organize their app's feature into a menu bar, they really need to find another line of work, or hand off the UI development to someone who is talented in it. It's not difficult, nor is it a straight-jacket, unless the dev simply hasn't the imagination for it. No real shame there, UI design is not the same task as coding, and it takes a different set of skills and experiences.
It sounds like your vitriol is based on the *Windows* version of the menu bar (and toolbars). I agree with you there: they stink, in general. On the Mac, not so much. The menu bars are *one* way of accessing app features, the contextual menus are *another* way. But given that discoverability is a cornerstone of the Mac experience, the menu bar as the *primary* method of interaction has to be maintained... and frankly, developers like you are the reason we still have one-button mice.
Originally posted by RainbowGuy
Ha! It's way more than four dozen - if you really look you can find hundreds.
So, there are hundreds of clickable areas that you have to really look for.
So, there are hundreds of clickable areas that most people won't bother even trying to find, because they won't know to look for them.
So, there are hundreds of features that will never get used...
Wait a minute! It's the FontBook of D'ni!
Multiple streams and Hi Def!!
FOCUS Enhancements Demos Wireless, Ultra Wideband Transmission of High-Def TV Streams
Category: Home Networking Gear - May 02, 2005
By PRESS RELEASE
FOCUS Enhancements, Inc.'s semiconductor group is successfully demonstrating the transmission of two high-definition TV (HDTV) streams through walls at its Hillsboro, OR, facility. This exciting development is another successful step toward the ultimate goal of enabling consumer products that will transmit multiple HD streams throughout the home based on FOCUS UWB chipsets later this year. This industry-leading technology extends the WiMedia/MBOA UWB Standard to better meet the requirements of video and high-speed data distribution through the home and office of the future.
FOCUS Enhancements' UWB technology will create a true personal area network (PAN) larger than ten feet with the ability to deliver rich media and crisp video content to UWB receivers. Its innovative technology is seamlessly interoperable with the WiMedia/MBOA UWB Standard while also extending performance in two critical areas -- data rate and range. UWB will extend the performance of next-generation personal/digital video recorders, TVs, set-top boxes, Media PCs, and DVD players.
"UWB is the standard that makes next-generation, high-performance wireless networks possible for real world applications, enabling the delivery of high-resolution and high-quality digital media throughout the home," said Tom Hamilton, executive vice president and general manager of FOCUS Enhancements' semiconductor group. "Market interest is found in the wireless inter-connection of devices like TVs and home entertainment systems which will exchange music, photos, and video as well as store and distribute media. Our UWB technology is taking wireless to the next level with an emphasis on transmission quality for distance and speed."
Mike Kelly, vice president of marketing for FOCUS Enhancements' semiconductor group, stated, "FOCUS has essentially doubled the Institute for Electrical and Electronic Engineering's (IEEE's) targets of 110 Mbps at a distance of 10 meters. Other solutions fall short when trying to deliver sustained high-resolution video over longer distances and are not very tolerant of things getting in the way of the signal. We are overcoming these obstacles -- now with two HD streams through a wall -- and have something that is practical for use by consumers in the home."
FOCUS Enhancements expects to sample UWB chip-sets in the third quarter of 2005 and modules containing UWB chip-sets later in the year. Performance expectations are anticipated to range from 880 Megabits per second (Mbps) at 8 meters to 37 Mbps at around 40-plus meters.
About FOCUS Enhancements, Inc.
FOCUS Enhancements Inc. (NASDAQ: FCSE) is a leading designer of world-class solutions in advanced, proprietary video technology. Headquartered in Campbell, CA, FOCUS Enhancements designs, develops, and markets video solutions in two distinct markets: advanced proprietary video conversion integrated circuits (ICs) and affordable, high-quality, digital-video conversion and video production equipment. Semiconductor IC products include designs for PCs, game cards, Internet, set-top boxes, Internet appliances, and interactive TV applications, and they are sold directly to original equipment manufacturers (OEMs). FOCUS Enhancements' complete line of video presentation and video production devices are sold globally through resellers and distributors to the broadcast, education, cable, business, industrial, presentation, Internet, gaming, home video production and home theater markets. More information on FOCUS Enhancements may be obtained from the company's SEC filings, or by visiting the FOCUS Enhancements home page at
http://www.FOCUSinfo.com.
Originally posted by tchwojko
So, there are hundreds of clickable areas that you have to really look for.
So, there are hundreds of clickable areas that most people won't bother even trying to find, because they won't know to look for them.
So, there are hundreds of features that will never get used...
Wait a minute! It's the FontBook of D'ni!
You missed the thread of his and my posts.
It isn't hundreds of clickable areas in his program, it's hundreds of different small font programs from developers.
Originally posted by TednDi
So it is possible:
Multiple streams and Hi Def!!
FOCUS Enhancements Demos Wireless, Ultra Wideband Transmission of High-Def TV Streams
Category: Home Networking Gear - May 02, 2005
By PRESS RELEASE
FOCUS Enhancements, Inc.'s semiconductor group is successfully demonstrating the transmission of two high-definition TV (HDTV) streams through walls at its Hillsboro, OR, facility. This exciting development is another successful step toward the ultimate goal of enabling consumer products that will transmit multiple HD streams throughout the home based on FOCUS UWB chipsets later this year. This industry-leading technology extends the WiMedia/MBOA UWB Standard to better meet the requirements of video and high-speed data distribution through the home and office of the future.
I just saw this at the E3 Expo here in the NY Hilton last thursday, and over the weekend.
It has a ways to go yet. I hope that it's better than Sony's Tv Everywhere concept.
By the way, since we're on this, briefly, I also saw HP and Samsung's new (July and June releases) 65" and 67" 1080p DLP rear projectors (about 18-20" deep) with real 1080p material. Amazingly enough my wife wants to get one this summer.
Amazing quality.
Originally posted by melgross
You missed the thread of his and my posts.
It isn't hundreds of clickable areas in his program, it's hundreds of different small font programs from developers.
Oops. My mistake. Sorry.
Originally posted by Kickaha
I hate to make a cliche, but *OW, MY EYES*!
Yes, I admit it is a bit violent! I'm going to put an option to fade the rainbow so people don't get eyestrain. Please don't sue me!
Interesting UI, that's for sure. I can't say I like it, at all, sorry.
No worries - I realise not everyone will take to it. It gives me eye-ache sometimes.
You may want to look at FontBook
I've seen the screenshots for FontBook. Like all existing font managers, it shows you a list of font names which you need to click on (or in FontBook, double-click) to see a preview one at a time. Now, from a user interface point of view, having the sample text visible all the time for all fonts without any clicking at all surely has to be better. My Windows users tell me it is. Thanks for the tip though.
And I'm sorry, but your app's UI hasn't exactly led me to change my mind regarding single button mice. In fact, it's rather strengthened my opinion.
Let me give you a quick example of why I was dismayed to find out about one-button mice. My option boxes can be set positively or negatively. To set positively, left-click. Negatively, right-click. Left-click to clear. Very quick, very user-friendly. Now for my Apple version, I have to find another way. So I have to program a method which is slower and clumsier in order to cater for a manufacturer which refuses to move with the times. Now I'm trying very hard to be impartial, but this doesn't seem like the one-button mouse is forcing me into good UI practices, does it?
As for a menu bar, I guess we'd agree that there's no way a menu bar would make this easier to do. You would say presumably that I should put a menu bar option called 'Option box', under which would be items 'Positive' and 'Negative'. Hmm. I could do that, but then see what happens - the option box has to be drawn differently to show that it's been selected. So now, the left-click can't be used to set the option box positively, because it has to be used to select the object. So what the menu bar has effectively done is to replace my quick easy way with a slow clunky way. This is why I'm feeling aggrieved.
Originally posted by RainbowGuy
Let me give you a quick example of why I was dismayed to find out about one-button mice. My option boxes can be set positively or negatively. To set positively, left-click. Negatively, right-click. Left-click to clear. Very quick, very user-friendly. Now for my Apple version, I have to find another way. So I have to program a method which is slower and clumsier in order to cater for a manufacturer which refuses to move with the times. Now I'm trying very hard to be impartial, but this doesn't seem like the one-button mouse is forcing me into good UI practices, does it?
Just make the right click a control-click and document it! oh and add the platinum theme to it. if you need any help with the design I don't mind helping.
Originally posted by MacCrazy
Just make the right click a control-click and document it! oh and add the platinum theme to it. if you need any help with the design I don't mind helping.
Thanks for the offer - I will bear it in mind.
Yes, control-click is one of my options, but I don't really like it; instead of tapping one finger a half a centimetre, I have to bring my left hand up to the keyboard and fumble for a key! Now, honestly, is that a better way?
Originally posted by RainbowGuy
Thanks for the offer - I will bear it in mind.
Yes, control-click is one of my options, but I don't really like it; instead of tapping one finger a half a centimetre, I have to bring my left hand up to the keyboard and fumble for a key! Now, honestly, is that a better way?
no i have a two-button mouse. It's not the criticism of second function clicking but the hidden contextual menus that are not intuitive. You have no idea what menu right-clicking will reveal so it's a bad design, however, a right click as a second function is different.
Originally posted by RainbowGuy
Yes, I admit it is a bit violent! I'm going to put an option to fade the rainbow so people don't get eyestrain. Please don't sue me!
No worries - I realise not everyone will take to it. It gives me eye-ache sometimes.
Heh, no worries. There are *much* worse UIs out there.
I've seen the screenshots for FontBook. Like all existing font managers, it shows you a list of font names which you need to click on (or in FontBook, double-click) to see a preview one at a time. Now, from a user interface point of view, having the sample text visible all the time for all fonts without any clicking at all surely has to be better. My Windows users tell me it is. Thanks for the tip though.
I can't argue with that. In fact, I'd *love* to see that functionality in a font app.
Let me give you a quick example of why I was dismayed to find out about one-button mice. My option boxes can be set positively or negatively. To set positively, left-click. Negatively, right-click. Left-click to clear. Very quick, very user-friendly. Now for my Apple version, I have to find another way. So I have to program a method which is slower and clumsier in order to cater for a manufacturer which refuses to move with the times. Now I'm trying very hard to be impartial, but this doesn't seem like the one-button mouse is forcing me into good UI practices, does it?
Okay, a UI purist would argue that you're trying to use a two-state UI element (checkbox) for a three-state choice (pos, neg, off), and that you're improperly using the widget.
BUT, I see what you're trying to do, and can offer up one way I've seen something similar handled. Tab stops in Pages are multi-state, in that instead of having a palette of tab types, you just click somewhere in the document ruler, and a left-tab appears. Clicking on it again converts it to a mid-tab, and subsequent clicks cycle it through right, decimal, etc. *Or*, ctrl-click pops up a menu of choices for direct access.
Alternately, you could break it out into two checkboxes, one for enable/disable in the search, and the second for pos/neg. Heck, disclosure triangles could be used to control the inclusion in the search, with the drop down offering options for that attribute.
Or, clicking on the name toggles on/off (with off greying out the text), and a single checkbox for making it negative.
In any case, it's best to use a custom icon for the multi-state widget, perhaps just a nice +, - layered over a Cocoa recessed button standard widget.
*So* many options to play with.
No straightjacket.
As for a menu bar, I guess we'd agree that there's no way a menu bar would make this easier to do. You would say presumably that I should put a menu bar option called 'Option box', under which would be items 'Positive' and 'Negative'. Hmm. I could do that, but then see what happens - the option box has to be drawn differently to show that it's been selected. So now, the left-click can't be used to set the option box positively, because it has to be used to select the object. So what the menu bar has effectively done is to replace my quick easy way with a slow clunky way. This is why I'm feeling aggrieved.
Understood, but look at it this way: anytime you see an *identifiable* clickable widget on screen (button, slider, etc), *that is the object*. It *becomes* the discoverable way of interaction for the verb it represents. Menus are required for verbs *which cannot be easily signified by a widget*. Toolbars bastardize this horribly, IMO, especially when people try and make them the *primary* interaction method. Like contextual menus, they should be secondary to the menu bar for pure verbs.
Actually, if you think about it, checkboxes and the like are almost always used to set an attribute: they are the adjectives and adverbs. Pure verbs can't really be represented that way, and have to go in menus to be easily understood at a glance.
So in your case, you have an object (search criteria) and you are modifying an attribute of it (positive/negative). A UI widget is appropriate.
Notice that you had to use verbose phrasing in your large buttons across the top though... imagine instead if those were in the menu bar... *and* you had nice small icons in a user configurable toolbar. A new user could quickly scan the menus and say "Ah! I can do X, Y, and Z, cool." A seasoned user could quickly alter the toolbar to meet their needs. *You* don't have to redesign the UI every time you want to add new functionality.
Sound difficult? With the Cocoa frameworks, you get this for free in your app. It's obscenely easy.
Originally posted by RainbowGuy
Thanks for your suggestions - I will give them due consideration, although there are practical problems with all of them. I have now read through the Apple UI guidelines (and very well-written and sensible they are) and I'm starting to see where you guys are coming from with this menu bar business. So there is only the one menu bar for all visible applications! Hmm. OK, my toolbar could be converted into a menu bar, but each item on the bar would actually be an action, not the route into a sub-menu. Would this accord with Apple usage?
why not make an "inspector" these are small windows with actions etc.
Originally posted by segovius
Mine already did - this has got to go in the 'phony leaks to flush out mole' category surely.
No way.
Apple must realize that not all users have two arm. I have a client that lost one arm as a child and there is no way she can hold ctrl and use a mouse.....
Originally posted by Kickaha
Any two button USB mouse will work for her.
It would have been nice if Apple made it a no cost option when she bought her $1500 computer instead of having to put it in the trash and buy at additional cost a two button mouse.
You can get options when you buy from Apple. They should have options for people with disabilites rather than trying to carry on a tradition of the one button mouse.