Ok-Cancel versus Cancel-Ok • Hacker News Board

Re: Ok-Cancel versus Cancel-Ok

#281

Post by oldcynic » Sun, Jun 10, 2018, 8:01 AM UTC

Sylos wrote: post #276

oldcynic wrote: post #261

Earlier quoted context omitted.

Interesting. I dropped Android a year or so back but can't remember bumping into an app doing it like that. Definitely encountered a few "are you sure?" style dialogues though.

The UI element typically used for this is the "Snackbar", so if you search for "Android Snackbar", you should find some examples. But yeah, I definitely also see a lot more confirm-dialogs still. Seems to be a classic case of such a UI pattern being great and hyper modern and marketable in 99% of cases. But if in 1% of cases, the user accidentally deletes a file that they didn't want to delete, then you lose that use…

Thanks again.

Perfect example of a UX pattern that's simply asking for trouble, or being clever rather than helpful. :)

You can undo if you notice quickly enough, if your dog, child, doorbell or 1,001 other things didn't distract you at the wrong moment and if you didn't get an incoming call in the temporary undo window. No, we won't tell you how long you can undo for, even though times can vary. Don't be old (or even middle-aged needing reading glasses), or slow.

Seems very much against long known recommendations from Nielsen et al for consistency of expectation etc.

A quick skim through search seems to indicate it came with Material Design. I suspect had it generally caught on it my switch to iOS would have come even sooner. :D

Re: Ok-Cancel versus Cancel-Ok

#282

Post by ProxCoques » Sun, Jun 10, 2018, 5:27 PM UTC

oldcynic wrote: post #280

ProxCoques wrote: post #272

Earlier quoted context omitted.

https://www.nngroup.com/articles/ten-usability-heuristics/ https://asktog.com/atc/principles-of-interaction-design/

That's something entirely different, and very well known. I can't find any reference to providing a delay before you truly perform an action, but allowing undo for that time. Relevant to delete / undo they talk of the preference for an undo (eg ^Z at any time) to "Are you sure?". No mention of delaying action or availability of undo. Then preference for consistency of action - within app and generally, not deviating…

On the web, it is extremely difficult to have an undo stack, so I'm talking about "undo" as implemented by appearing to do the action (eg delete), but delaying its actual action while giving the user the ability to undo it. If they take no action (or navigate away, etc.) the action is done.

In both of those links I posted, it clearly states well-designed systems have undo.

Re: Ok-Cancel versus Cancel-Ok

#283

Post by roryokane » Sun, Jun 10, 2018, 7:50 PM UTC

Too wrote: post #259

latexr wrote: post #241

Earlier quoted context omitted.

> Wow, you have to manually activate such an option? On windows it's default. I don’t think that’s deserving of “wow”. I don’t think it’s that big of a deal. It’s a clear option that is quite visible and present in the exact preference pane you’d expect. And you don’t need to activate it manually. You can do it via CLI: defaults write NSGlobalDomain AppleKeyboardUIMode -int 3 > not just bolted on as an afterthought.…

Once a friend of mine with a mac suddenly had a mouse malfunction, can't remember if it was broken or just out of battery but doesn't matter. He was literally stranded, and this is developer who knows how to use a terminal and a keyboard. Everything we were working had to be put on hold, i can't remember the exact scenario but we couldn't even save the document, unlock the machine, get to a terminal or something like…

There are definitely hotkeys that allow you to do anything via keyboard; your friend just didn't know them. If they had searched, they would have found the help page https://support.apple.com/en-us/HT204434 "Mac accessibility shortcuts". For example, the global hotkey Control-F7 toggles the above-described "All controls" navigation setting, and Control-F2 switches focus to the menu.

Re: Ok-Cancel versus Cancel-Ok

#284

Post by Groxx » Mon, Jun 11, 2018, 1:16 AM UTC

lucb1e wrote: post #37

santix wrote: post #20

Earlier quoted context omitted.

I was surprised at the minimum requirements. I don't know if I'm not up to date with current games, but from the style of it I thought it would be much lighter.

I haven't looked at them, but anything slightly modern should do. My laptop (5 years old), the desktops in school (2-3 years old), my girlfriend's laptop (3-4 years old), my cousin's laptop (another girl with a not-so-beefy laptop), and my brother's laptop all run it fine... Most of those don't even have dedicated GPU. Sure, once you go megabase scale, after a few hundred hours of playing, most hardware will lag a li…

Just to echo one of the points in here: the blog is full of really great details on all this, and how they've changed things, and why. One of the best dev blogs I've ever run across.

Re: Ok-Cancel versus Cancel-Ok

#285

Post by fnord123 » Mon, Jun 11, 2018, 7:04 AM UTC

Uristqwerty wrote: post #236

fnord123 wrote: post #182

Earlier quoted context omitted.

Toy cars in shops have the cars and trucks all facing right in the packaging. Maybe they've done some ab-testing to get this way. Maybe not. Maybe putting his airplanes facing left made your veteran's models pop because they were inconsistent with other models. Anyway, if you want to make people read the options on buttons, randomize the order each time the popup appears but always destructive buttons like "delete" r…

Is that packaging style the same for all English-speaking countries? Standing on the side of the road and facing traffic, you'd expect all of the near vehicles to be facing right in North America, so perhaps that carried, consciously or otherwise, into packaging decisions.

I was in a toy shop recently and it's actually about 70-75% right facing, so not all. I don't think there's a pattern based in some underlying reasons - though it is fun to fantasize about those possible reasons.

Re: Ok-Cancel versus Cancel-Ok

#286

Post by jeremiep » Thu, Jun 14, 2018, 5:08 PM UTC

blackenough wrote: post #234

jeremiep wrote: post #129

Earlier quoted context omitted.

Anything where your app state is modelled as a series of actions over immutable data, undo and replay will be essentially free to implement :)

destructive updates to your universe, or actions with side effects (anything regarding io) might not be recovered by a simple state management. delete my account, charge my credit card, add a friend, delete a friend...

But that is precisely how undo is currently implemented most of the time. Its a series of actions where you know how to undo the side-effects, or you know it was a destructive update and you just skip the undo of that step.

Where I have issues with that is it usually feels like an afterthought rather than a first-class feature.

If you instead model your application after an event log then your current state is just a fold over these events. You have the same list of actions you previously had to manage undo, but now its positioned at the very center of the architecture.

And then you start seeing emergent features of that design:

- you can time travel the UI's state, which is probably the best debugging tool you can have for UIs.

- you can replay the event log over fixed application code, which greatly decrease iteration times.

- it moves logic outside of the UI components, making the app easier to unit test.

- you're storing a sequence of intents rather than results; its effectively free to audit such a design, its convenient to report the last X actions performed with a bug report and more precise than asking the user what they were doing.

The list goes on and on. I believe most of the complexity in applications is generated from the fact there is very little synergy between the different features of these applications. If everything requires a different abstraction and set of indirections, then you're just accreting complexity over time.

If you have a design where features can emerge from it, its usually a safe-bet to say you're on to something :)