So, no, confirmation dialogs aren't bad because pressing the return key is an onerous task. It's not because UI/UX designers think they're a great workflow.
Programmers use confirmation dialogs because (1) they're quick and easy to implement, and (2) they offload responsibility to the poor user, who did technically hit the "OK" button. So people work either quickly and dangerously, or slowly and safely, which is crazy because we've known for decades that Undo can allow them to work quickly and safely.
(OK, sometimes it is.) It's because they know they don't know how to recover if they make the slightest mistake. They'll never make *that* mistake again.) Have you seen newbies take forever to perform the simplest task? It's not because they can't find the right button. (This is often a reaction to being bitten by outcome #1. The other common outcome, when working in an environment without the safety of Undo, is that many people compensate by slowing way down. I've seen more than a few people alias rm="rm -i", and later type "rm importantfile", "y" anyway just because their hands were used to always typing "y" after "rm". The dialog itself adds only a tiny bit of friction, but they don't even get any benefit from it. When a user finally does want to cancel, they often realize it only after they've accidentally confirmed it. People don't take the time to read and consider every dialog presented to them, especially one where they answer the same way 98% of the time. It trains users that deletion is "command-D, return" (or whatever the keys are), in one motion. Martin: Based on usability studies I've seen, confirmation dialogs generally lead to two possible outcomes, neither of them desirable. Prompting is still on the table too, but first we want to take a stab at making the workflow intelligibly undoable, see if we can make it work without another blocking alert.Īpple Mail Datacide E-mail Client Keyboard Shortcuts Mac macOS 11.0 Big Sur Microsoft Outlook We’ve changed ‘discard’ to cmd-escape (also closer to other outlooks which use plain esc) in beta ~Thursday and production next month. Looks like what ends up in the trash will be what was in the last auto save (~30 seconds) of the draft - it doesn’t do an additional save before discarding. When I look in my Deleted Items folder, I see the drafts from when I tested this last night and just now, but none of the discarded drafts preserved the message text, and the subject line was only preserved in one. This is probably how it slipped through the cracks: it’s not really gone, so doesn’t meet the normal ‘must prompt’ criteria. That draft is sitting in your ‘deleted items’ folder, ready to send. The good news is that ‘discard’ is not data loss. In New Outlook, it discards the message you have just finished writing - without warning or confirmation - where it disappears into the aether. In Apple’s Mail app, this is the shortcut for sending a message. One of the keyboard shortcuts changed in New Outlook compared to the “classic” Outlook app is Command–Shift–D. Microsoft has two different versions of Outlook in the Outlook for Mac app. It’s also rigid, in a way, but the workflow that it enforces happens to be a close match to what I’ve always tried to achieve with other tools.New Outlook’s Dangerous “Discard” Shortcut I’m currently using OmniFocus as my issue tracker and am loving it. It may also be that I have a certain way that I like to work, and the Web-based trackers that I’ve used are rigid in making me change my style to fit theirs. Part of it is that for this kind of highly interactive work I think it really helps to have a desktop interface. Web-based bug trackers vary from terrible to pretty good-and FogBugz is certainly towards the good end-but I’ve yet to find one that I actually liked using. I’ve never had a problem with support e-mails falling through the cracks, and my entire e-mail history is easily accessible in EagleFiler. I can see how something like FogBugz would be useful for a setup involving multiple developers and support people, but for me I see no need for it. (Thanks to Fog Creek for offering a full refund with no questions asked.) At the time, I liked Trac somewhat better for issue tracking, but of course Trac doesn’t handle support e-mails. I tried FogBugz a few years ago, since it was getting rave reviews, and just couldn’t stand it. In this case, our solutions couldn’t be more different. I’m especially interested in what Gus thinks since he’s also a solo Mac developer. It’s all easy and does what I need and want it to do. Generally do everything I need to do when I’m wearing my support hat. Them away, respond, easily see previous e-mails from the reporter, and
I can turn e-mails into bug reports, file All e-mail to goes through FogBugz which is a
0 kommentar(er)
