Design – UI design and confirmation paradigm

designgui

I just saw this lecture by Spolsky, where he questions the need for choices and confirmation dialogs. At some point he has a MacOS settings window and he mentions that "now some are getting rid of the OK button". The window indeed has no OK (or cancel) button. Changing a setting makes it change, when you're done configuring, you close that window, period.

Being a long time Windows user and a recent Mac owner, the difference is noticeable at first. I looked for the OK button for a while, only to find out, quite naturally and painlessly, that there was none. I expressed satisfaction and went on my merry way.

However, I'm curious to know if this UI design pattern would succeed in the Windows-based world. Granted that if Microsoft brought it out with say Windows-8 (fat chance, I know), people would get used to it eventually. But is there some experience out there of such an approach, of changing the "confirmation paradigm" on a platform where it's so prevalent? Did it leave users (especially the non-technical ones) confused, frustrated, scared, or happy?

TL;DR: Remove OK/cancel confirmation, what happens?

EDIT:

Mac GUI for appearance settings.

alt text

Best Answer

I find a nice middle ground is when some text is temporarily displayed (not in a pop-up) saying "your change has been successfully saved" or something similar to Google Doc's auto-saving

Related Solutions

Design – Software Design for Non-Object Oriented Paradigms

Even for a system that is not designed according to the OO paradigm, you can still use UML notation to document the system, possibly extended with some Data Flow Diagrams (as I can't immediately find a corresponding diagram in UML). Diagrams worth looking into, even for non-OO systems are:

State (Transition) Diagrams
Use Case Diagrams
Sequence Diagrams

When modeling a non-OO system, you may have to be a bit flexible as to what you model as a 'class'.

For example, if you have a header file stack.h like this

struct stack;
struct stack* stack_create(void);
void stack_destroy(struct stack*);
void stack_push(struct stack*, void*);
void stack_pop(struct stack*);
void* stack_top(struct stack*);

with corresponding implementation, there is nothing to stop you from presenting that as a 'class' stack in your models.

UI Design for Changing Multiple Records at Once

I agree that a checkbox could puzzle the user.

My reaction to the problem of how to display an undefined text box and differentiate it from a valid but empty one is to use a placeholder for the undefined one and an empty one for the other.

The valid empty box will look normal to the user and the normal-ness will be reinforced when the user tries to use it. The placeholder box will have a placeholder message "type something here" that is greyed out or muted in some way so that it's clear to the user that it's not an actual value. This notion that it's temporary will be reinforced when the user enters the box and the placeholder text vanishes.

We see this behaviour frequently on the web so it should seem intuitive to the user and shouldn't make them think.

The other thing is that you could consider IF the users need to know there's a difference. If not, then both boxes could be left empty.

Related Topic

RESTful Design – What is the RESTful Way of Action Confirmation?