Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Apple Is Giving Design a Bad Name

fastcompany.com

Post reply on HN
Print view View original

61–70 of 97 posts

Re: How Apple Is Giving Design a Bad Name

#61

Post by Drdrdrq »

My pet peeve: when I try to click a button and just before I touch the screen it changes, so I hit completely another button (on Androod - but it is the same everywhere). So instead of cancelling a call I place another one, to a different person. No I didn't intend to call my mother in law!

The solution is so simple it hurts: if a clickable area has been shown less than X ms before the touch / click, ignore the event. Nobody can type this quick except for Superman, and he can change this via some setting, if you think he will be annoyed.

I am not sure why I haven't seen this solution anywhere yet. Do others not encounter this problem?

Re: How Apple Is Giving Design a Bad Name

#62

Post by gtf21 »

Drdrdrq wrote: post #61

My pet peeve: when I try to click a button and just before I touch the screen it changes, so I hit completely another button (on Androod - but it is the same everywhere). So instead of cancelling a call I place another one, to a different person. No I didn't intend to call my mother in law! The solution is so simple it hurts: if a clickable area has been shown less than X ms before the touch / click, ignore the event…

I encounter this problem all the time, incidentally also with calls.

Often I'll doing something at the same moment as someone else calls me, I end up hanging up the incoming call by mistake. A delay in "screen change" would be great!

Re: How Apple Is Giving Design a Bad Name

#63

Post by Drdrdrq »

frik wrote: post #60
drumdance wrote: post #55

Earlier quoted context omitted.

Yeah I remember being confused by the drag-to-trash metaphor too, except in my case we were still using floppy disks and I thought "are you sure this won't erase my term paper?"

Floppy drives had a mechanical eject push-button and there was no unix-style "mount" afaik.

On unix at least (linux and aix) there was mount / umount of a floppy, which should always be done before removing it from the slot. Linux couldn't force you though, but it was good practice.

Re: How Apple Is Giving Design a Bad Name

#64

Post by nextos »

bad_user wrote: post #34

" So often, the user has to try touching everything on the screen just to find out what are actually touchable objects. " This happened to me many times on iOS and I'm a (still young) software developer, being familiar with most user interfaces that happened since Windows 3.11 until now. To be honest, biggest culprits are third party apps, but they follow official guidelines and Apple's example. This was my biggest p…

Same here. I'd also add OS X UI has gone downhill since the good old Tiger days, backporting all bad ideas from iOS.

Somehow, it feels like the hardware design guys at Apple took over UI design and seem to have broken all the guidelines created by their former HIG lab, which once was at the forefront of UI research [1].

Now it seems minimalism (flat design) for the sake of it trumps everything else. I miss cozier designs, and so do many other heavy users I think.

[1] http://interface.free.fr/Archives/Apple_HIGuidelines.pdf

Re: How Apple Is Giving Design a Bad Name

#65

Post by afandian »

frik wrote: post #60
drumdance wrote: post #55

Earlier quoted context omitted.

Yeah I remember being confused by the drag-to-trash metaphor too, except in my case we were still using floppy disks and I thought "are you sure this won't erase my term paper?"

Floppy drives had a mechanical eject push-button and there was no unix-style "mount" afaik.

I don't know which floppy drives you used, but the ones I did had no push-button. It was software only. I skimmed through the models in Wikipedia and couldn't see any with manual ejects.

https://upload.wikimedia.org/wikipedia/commons/d/df/Macintos...

https://upload.wikimedia.org/wikipedia/commons/c/c9/Macintos...

https://upload.wikimedia.org/wikipedia/commons/b/b3/Macintos...

https://upload.wikimedia.org/wikipedia/commons/8/8e/Macintos...

https://upload.wikimedia.org/wikipedia/commons/2/2b/Power_Ma...

Re: How Apple Is Giving Design a Bad Name

#67

Post by spyder »

hamstergene wrote: post #50
cja wrote: post #13

Moved from Windows to OSX a couple of years ago after hearing for so long how much better the Mac experience and usability was. Some examples of why this was wrong: 1. Cmd-Tab lets me select a hidden window but it won't show it! 2. Many frequently used click targets are too small. For example, the close, minimise and maximise buttons. 3. The close minimise and maximise buttons reveal their functions only when the mou…

Please not yet another "I've switched from A to B and was shocked to discover that B does not work like A!" rant. You're simply executing working patterns from Windows and of course it does not work so well. 1. Cmd-Tab does not select windows, it selects apps. If the app is hidden (Cmd+H), it will be unhidden. 2. They are not such a frequent click targets. Also, that is not a maximize button. I see what your problem…

you are not supposed to use minimize so often.

So you are saying he is "holding it wrong"...

Re: How Apple Is Giving Design a Bad Name

#68

Post by Drdrdrq »

gtf21 wrote: post #62
Drdrdrq wrote: post #61

My pet peeve: when I try to click a button and just before I touch the screen it changes, so I hit completely another button (on Androod - but it is the same everywhere). So instead of cancelling a call I place another one, to a different person. No I didn't intend to call my mother in law! The solution is so simple it hurts: if a clickable area has been shown less than X ms before the touch / click, ignore the event…

I encounter this problem all the time, incidentally also with calls. Often I'll doing something at the same moment as someone else calls me, I end up hanging up the incoming call by mistake. A delay in "screen change" would be great!

Glad I'm not alone!

Not delay in screen change - system can't predict when user is going to press the button. But it is highly unlikely that the change of screen occured, I have noticed it, found the correct button and pressed it - all in 50 ms... The system should just disregard the touch, because it was obviously meant for previous screen.

Re: How Apple Is Giving Design a Bad Name

#69

Post by radicalbyte »

jonhohle wrote: post #46
radicalbyte wrote: post #24

Earlier quoted context omitted.

> the priority is how things _work_ I really wish that they would apply this to iTunes and with their power/USB cables. They've done a good job with OSX - F3, F4 and the multi-window support all work really well. Multi-windowing is an especially big improvement over windows. But there are easily 10 x as many iTunes users as OSX users so they should really do something about it.

I've never understood why iTunes is the way that it is, except that was already available on Windows, so it seemed like a good vector for devices. It really is a jumbled bag now though, and seems to go through significant UI changes every release for no good reason (hearts? stars? iTunes has them both!) OS X used to have a separate syncing application, iSync, for PDAs that was simple and generally worked. I was dusap…

The lack of stress relief which means that the cables break very quickly. It's a well known design defect in Apple products.

I'm very careful with my technology but I'm already on me 2nd MBP power supply and my wife is on her 3rd USB cable for her iPad. This all in 18 months.

Re: How Apple Is Giving Design a Bad Name

#70

Post by Someone »

izacus wrote: post #56
Someone wrote: post #53

Earlier quoted context omitted.

"7. Cmd+Down to open the selected file! Why not Enter?!" Consistency. Cmd+Up moves you up one level in the file system, Cmd+Down down one level. Also, at least historically, there was a consistency in that a key stroke is a command if and only if it contains the command key. The reason the Finder did not have copy-paste for years, and why it doesn't have cut till this day is that it is hard to implement. A proper cut…

>The reason the Finder did not have copy-paste for years, and why it doesn't have cut till this day is that it is hard to implement. A proper cut would immediately delete the file from the file system, and a later paste would paste the file with the contents it had when the file was cut or copied (Excel is also notoriously bad at this; cut a range, close the file, and try pasting) Huh? That's the strangest reasoning…

I know that, but that is inconsistent and that inconsistency _is_ the reason the Finder resisted implementing it for years, and why it doesn't have cut-paste to this day, but does have move.

It is hard to find things from decades ago on the web, but see https://www.quora.com/Why-does-Apple-not-provide-a-cut-funct... (2011). The answer from Eduo-Gutiérrez IMO points to the same.

The Apple Human Interface guidelines also are fairly clear on the fact that the clipboard behaves like a real object. My 1987 edition says (page 81):

The Clipboard holds whatever is cut or copied from a document. Its contents stay intact when the user changes documents, opens a desk accessory, or leaves the application.

That certainly is not the way Excel behaves.

Also,on page 83, discussing the Cut menu item:

When the user chooses Cut, the application removes the current selection from the document and puts it in the Clipboard, replacing the Clipboard's previous contents. [...] If the user chooses Paste immediately after choosing Cut, the document is just as it was before the Cut.

Post reply on HN