Those damn widget buttons! My rant for the day...
I dunno- something needs to be done to the buttons, imo. It pisses me off so much when I hit just outside the edge and all I get is "air" as I press my trackpad button. It's so unforgiving. Maybe there should be more button realstate or maybe OSX should cut you some slack when you hit "close-enough" to a button, but not quite inside the circle? How about if the button visually enlarges to accomodate a near miss? Either way, I scowl at the computer when my "poor-ish" hand-eye coordination has me miss the button and OSX just ignores me as if to be aloof.
...and before anybody attributes it to just that I am on a trackpad (though, I grant it can have some wiggy response, occasionally), I have had the same issue when I am on a standard mouse setup (with 19" screen to boot). I just think OSX should give more forgiving mouse clicks on the window widget buttons.
On a similar and related issue, the close tab buttons in Safari could use some work, as well. Always, I'm clicking close, but not close enough. The button realstate is just so stingy.
...and before anybody attributes it to just that I am on a trackpad (though, I grant it can have some wiggy response, occasionally), I have had the same issue when I am on a standard mouse setup (with 19" screen to boot). I just think OSX should give more forgiving mouse clicks on the window widget buttons.
On a similar and related issue, the close tab buttons in Safari could use some work, as well. Always, I'm clicking close, but not close enough. The button realstate is just so stingy.
Comments
Not.
Discrete boundaries are good.
Originally posted by Kickaha
Oooooh, what if they all just kinda merged into one another, with no visible boundaries, so if you're just a couple pixels off of Minimize, you end up Closing it! That'd be cool!
Not.
Discrete boundaries are good.
Well, no one suggested making them enlarge to the point that they intersected each other. That would be pretty dense. The way I see it, there is about 25% a button diameter worth of space going completely unused between each button. Why not put it to some use? For the purists, could always be a preferences option to disable this helping function.
As for hitting close when you wanted a minimize, who's friggin fault was it putting all those buttons together anyway?! There's a lot of UI optimizations to defend in OSX, but defending this move that was swiped from of all things WINDOWS, is the epitomy of thick-headed UI choices. Hence was the beauty of the unique widget locations of Mac Classic... The button relocation in OSX was a BIG step backwards.
I'd like to see OS X with a resolution independent GUI, so the GUI scales with a little bar widget, and stays the same regardless of the display resolution. Actually I'm surprised Apple hasn't done this yet, considering all their boasting about Quartz.
Of course the problem if Apple implemented resolution independent GUI scaling would be that their displays wouldn't have a high enough resolution for many buyers. Why buy an Apple display when you can buy a Sony at greater resolution for less dough?
Originally posted by Randycat99
Well, no one suggested making them enlarge to the point that they intersected each other. That would be pretty dense. The way I see it, there is about 25% a button diameter worth of space going completely unused between each button. Why not put it to some use? For the purists, could always be a preferences option to disable this helping function.
I'm not really sure I see it as a helping function, to be honest. Train users to expect a 'fuzz factor', and then they'll wonder why it doesn't extend just a *little* bit further. And so on. Clicking on a button is a discrete action: yes, or no. Was the click inside the *visible* boundary? Yes, or no. It's simple, direct, and a one-to-one mapping. It is obvious, easy, and I don't see how making it 'fuzzy' is going to help.
Honestly, if you're having problems with hitting the buttons, maybe you should look at activating Keyboard Access.
As for hitting close when you wanted a minimize, who's friggin fault was it putting all those buttons together anyway?! There's a lot of UI optimizations to defend in OSX, but defending this move that was swiped from of all things WINDOWS, is the epitomy of thick-headed UI choices. Hence was the beauty of the unique widget locations of Mac Classic... The button relocation in OSX was a BIG step backwards.
I'm not going to argue that one, but it was just an example of how a user can aim at the 'fuzzy' area of one button, and hit the 'fuzzy' area of *another* button, and because *there's no visible boundary*. Users would just have to *guess*. Not good. Heck, choose any two actions you want, and it still applies.
Here's one: user clicks near the buttons in the title bar to bring a window forward, and it zooms instead, because they were just a bit too close to that button, in the invisible region of 'helpfulness'. Surprises are bad. Or, tabs in Safari... the user was *just* outside the Close button on an inactive tab. Were they trying to close it, or bring that tab forward? You can't tell. If you're going to say 'just assume Close', then why not just make the buttons bigger, since that's all you're really doing, and it would have the benefit of *visibility*?
And waitaminnit... aren't you the one saying there's wasted space between the buttons in the title bar?? Would you *rather* have all buttons smushed up against each other?
Argue if you want for *larger* buttons, but making invisible active regions the user has to guess at is just begging for trouble.
1. Ditch the round window widgets.
2. Drop the r/y/g colors
3. Make them square with clear icons, even when not rolled over.
It wasn't broke, it didn't need fixing.
Originally posted by Kickaha
I'm not really sure I see it as a helping function, to be honest. Train users to expect a 'fuzz factor', and then they'll wonder why it doesn't extend just a *little* bit further. And so on. Clicking on a button is a discrete action: yes, or no. Was the click inside the *visible* boundary? Yes, or no. It's simple, direct, and a one-to-one mapping. It is obvious, easy, and I don't see how making it 'fuzzy' is going to help.
So is a "command line", but are you then going to argue OSX would be better off controlled entirely by a command line? Users aren't being trained to use a fuzz factor. They will always be aiming to hit the button directly. That's just human nature. On the occasions they don't, their command will still be received. Having defended that, I don't see the problem with just having larger buttons altogether (hence, the suggestion the button could enlarge once you get near it- as in within a few pixels). It would be clear which button the system understands you are about to activate. If it is the incorrect button, you will then have the feedback to further reposition the mouse cursor. All I see here is bonus...
Quote:
I'm not going to argue that one, but it was just an example of how a user can aim at the 'fuzzy' area of one button, and hit the 'fuzzy' area of *another* button, and because *there's no visible boundary*. Users would just have to *guess*. Not good. Heck, choose any two actions you want, and it still applies.
...not if there is visual feedback (as has already been suggested). In fact, there is already the hook for visual feedback, when you see the symbols appear inside the buttons as you mouse over them. This would be a small matter to just extend a bit on the concept.
Quote:
Here's one: user clicks near the buttons in the title bar to bring a window forward, and it zooms instead, because they were just a bit too close to that button, in the invisible region of 'helpfulness'.
How many people you know click in the space between buttons to bring a window to forefront??? Get serious, already! In this scenario, you have the space of entire title bar and any exposed area of the window itself to click on, and you are going to premise a user would instead attempt to hit some of that silvery space between buttons? Apple needs to give considerations to someone who chose that way to bring a window to the forefront? On top of that, that really delves into the topic of "clickthrough"- another topic of discussion altogether. I forgot which way OSX supports presently (cuz I instinctively do not try to click on buttons on windows that are not forefront in the first place, whether or not it is to hit the button or to just bring the window to forefront), but you could just as well argue on whether or not click-through should be supported for that scenario. With click-through "off", you scenario is irrelevant (hitting on the button would not close it, anyway). With click-through "on", a button action would occur, and you would certainly find some group of persons who find that sort of access to be a "good" feature.
Quote:
Surprises are bad. Or, tabs in Safari... the user was *just* outside the Close button on an inactive tab. Were they trying to close it, or bring that tab forward? You can't tell. If you're going to say 'just assume Close', then why not just make the buttons bigger, since that's all you're really doing, and it would have the benefit of *visibility*?
You got the entire width of the tab to click a tab to forefront. I think we can afford a close button that is a bit larger. ...but if it makes you feel any better, you could just remove the button altogether and rely on control-click to bring up a contextual menu for that option. I know it already does this, so that really brings to bear whether there needs to be a button there if it is going to be so small as to be difficult to hit accurately by some people. If a button is going to be implemented there, introducing a source of trouble either way, why have it there, at all (as per, keeping interfaces "simple" wherever possible)?
Quote:
And waitaminnit... aren't you the one saying there's wasted space between the buttons in the title bar?? Would you *rather* have all buttons smushed up against each other?
Never was there a "requirement" for them to be smushed together. You can make them dynamically bigger, you can make them statically bigger and then spread them out a bit more...just allow more active target area. If you can incorporate some visual feedback, that pretty much makes the concerns of any "drawbacks" moot. There would be no "surprises".
Quote:
Argue if you want for *larger* buttons, but making invisible active regions the user has to guess at is just begging for trouble.
No where was there a requirement that active regions be "invisible". It is only argued that there should be more active region, in one way or other. Arguing that a user will attempt to guess where the "invisible" region is, rather than just aim for the clearly marked area of the button, is pretty ridiculous.
Originally posted by johnq
We just need square widgets, period.
1. Ditch the round window widgets.
2. Drop the r/y/g colors
3. Make them square with clear icons, even when not rolled over.
It wasn't broke, it didn't need fixing.
Yes, it ISN'T broke, and it doesn't need fixing.
The close widgets on Safari Tabs are tiny for a reason. Ever switch tabs and accidentally close one?
Maybe you've got early stage Parkinson's disease. Seriously, I'm on a high resolution and I never have any trouble with OS X's widgets, and I'm not particularly steady-handed. I was a wreck trying to overclock my G4. You should go get checked out for nervous diseases, and maybe get your eyes checked while you're at it.
Personally, I've never found the minimize and zoom buttons to be problemmatic being next to the close button. The spacing between the icons is very good IMO, not nearly the problem it is in Windows. Even in Windows, the problem usually isn't accidentally hitting the close widget, it's accidentally hitting the maximize widget when you're going for the minimize widget or vice-versa. It's pretty much impossible to make that mistake with the OS X window widgets unless you're just not looking.
if shapeshifter wasn't a super-haxie, i have liked the themes that utilize bolder borders and rectangular widgets myself, too.
Always, I'm clicking close, but not close enough. The button realstate is just so stingy.
Well, how about using the menus, they have a larger area and are a bit more forgiving.
File:Close (cmd-W)
Window:Minimize (cmd-M)
Window:Zoom
These menus exists on every app.
Originally posted by Juha Otus
Well, how about using the menus, they have a larger area and are a bit more forgiving.
File:Close (cmd-W)
Window:Minimize (cmd-M)
Window:Zoom
These menus exists on every app.
Yes, I could do it any number of other ways, but I the mouseclicking issue is the one that is relevant because that is how I choose to work.
It's funny you should mention the keyboard commands, though, because that can be just as bad. Did you know cmd-Q (quit application) is right next to cmd-W? So is cmd-A. So here we are again, with 3 buttons that happen to be exist right on top of each other, and hitting one when you meant the other just might end up pissing you off (for a moment, at least). Maybe you want to "select all" and "copy", but you hamfistedly hit cmd-Q or cmd-W, instead of cmd-A. So you either end up nuking the window you had your important text you were about to copy/paste or you nuke your whole app that contained data in other windows that you weren't quite ready to part with, yet. Granted, you often will get a nice safety net in most other apps (word processors, for example) when it asks you first if you want to save before losing changes (tell me you haven't had "that moment", where you realize what you just did, a burning flush builds on your neck, and then a distinct expression of "whew, that was close" inside your head, when you see you have a 2nd chance now by just hitting the cancel button on the window prompt). However, a web browser is all too happy to screw you up (because you did ask it to do what it did, afterall)- no friend lookin' out "are you sure?" prompt, at all.
Maybe I should just rely on voice recognition to control my computer, eh? Oh wait- God forbid if it happens to mistake me saying, "open Mail", for "login Root account and reformat all non-system partitions..." Aiiiiyeeeeeee!!! Yeah, that is extreme exaggeration, but you get the point...
But close enough is good enough.
Did you know cmd-Q (quit application) is right next to cmd-W? So is cmd-A. So here we are again, with 3 buttons that happen to be exist right on top of each other, and hitting one when you meant the other just might end up pissing you off (for a moment, at least).
Well, not for me. I'm a Dvorak layout user:
12345 67890[]
',.PY FGCRL/=
AOEUI DHTNS-\\
`;QJKX BMWVZ
This layout has been better on my wrist problems than qwerty. However, I've been developing a better keyboard (sorry, text in finnish) that lets me type more naturally and won't get any typos.
Cmd-W and Cmd-M are the only keys I sometimes have a "DUH!"-experience with.
Originally posted by Juha Otus
Well, not for me. I'm a Dvorak layout user:
Code:
12345 67890[]
',.PY FGCRL/=
AOEUI DHTNS-\\
`;QJKX BMWVZ
This layout has been better on my wrist problems than qwerty. However, I've been developing a better keyboard (sorry, text in finnish) that lets me type more naturally and won't get any typos.
Cmd-W and Cmd-M are the only keys I sometimes have a "DUH!"-experience with.
Okay, you really wanna play this game?
Nobody can escape!!! We are stricken with keys that go together like peanut butter and dog turd no matter what the keyboard is! Aaaaagh!
There's only one answer! The Q and W keystoke MUST DIE!!! In lieu of the keystrokes, a unique physical button for each shall be located prominently and clearly outside the regular keyboard button pattern (preferably seperated themselves, on opposing ends of the keyboard). They can be colored Ultra-teal and red, respectively, with optional flasher illumination and protective flip-away cover, if desired. ...and for the utmost deliberance confirmation, the button face must read a valid fingerprint ID as you press it (so as to filter out any inadvertent swipe to the button as you manuever about the keyboard or the opportunistic landing of a pillow on said button during a heated pillow fight).
Okay, you really wanna play this game?
Okay.
I can see an R next to an C. So what if you meant to "copy", instead of "reload/refresh" a webpage?
Well, that hasn't really been a issue, because I'm a touch-typer.
M and W are the most difficult combinations for me, because I use the index finger to press M, but the home position is lost when I hold down Command with my right-hand thumb. Therefore, I sometimes press W instead.
Cmd-C and Cmd-R are a bad example, because those keys are really easy to hit right with my middle and ring-finger without losing the home position.
Cmd-F/G and Cmd-X/B could sometimes be an issue, if I'm operating an unfamiliar keyboard.
In lieu of the keystrokes, a unique physical button for each shall be located prominently and clearly outside the regular keyboard button pattern (preferably seperated themselves, on opposing ends of the keyboard).
Well, you know that's what F-keys are for, do you? You can paint them any color and/or program any function to them.
You are free to customize the keyboard hardware too, It's really not very hard to do.
I'm frequently overshooting the numbers and scraping an F-key (this is something I think most laptop and mini keyboard users can appreciate). Ironically, it's not too bad a penalty for doing so, because I never have anything assigned to them anyway (can you imagine if I did, and what sort of rope hanging functions I might think of putting there???
I have mixed views on F-keys, though. While I have no doubt they are a godsend to others who do use them, I can never manage to remember what I have assigned to them after a while anyway. So what happens? Do I make a guess? What if it is wrong, and the actual function that occurs happens to be wrong in a really bad way? Like I said, I have no doubt they are a boon to other people, so I would never argue to banish them. To me, they just "skerr" me like a supermodel hotchick hitchhiking on the side of the road. I mean, c'mon- like a super hot chick would really be stranded roadside. Clearly they are trained operatives sent to detour me from my mission given from the Queen.