A UserInterface must never present false information, or seem to present information that does not reflect the state of the application.

For instance, an app may have a list box for selecting an entity, and also a number of fields for describing the entity. Never should the fields describing the entity not describe the entity that is selected in the list box. In other words, it should never LOOK like item A is selected, when in fact B is selected. 

Disinformation is the greatest sin a UI can commit.

----

One mild form of disinformation: On some systems when I'm editing something with a proportional font, the cursor doesn't quite line up with the letters -- sometimes the cursor is lined up directly on top of a narrow "i" or "l". When I hit the delete button, will it delete that letter or the one next to it ? I find myself arrowing left and right and counting letters to make sure the cursor is "really" where I want it.

----

There is an operating system (which shall remain nameless) in which modifications to the file system that don't go through the GUI are not
reflected in the GUI. There is an option to "refresh" the screen, but this option
is rather carefully tucked away in the menu structure. Would this qualify as an application
of this AntiPattern?

''I don't think so... more of a 'this is how it was the last time we checked' type of thing.  Maybe not ideal, but not horrible.  Now, the operating system which pretends to have saved your file but only really does it when you eject the disk would seem to be a bit different (and I'm not sure it does this anymore anyway).''

----

(EditHint: move this section on write buffering to its own page ?)

Yes, write-buffering (write-back asynchronous vs. write-through synchronous) is a tradeoff. On one hand, when the user hits "save" (or "print"), we could just give the user a thermometer progress bar thingy (EditHint: what's the name ?) and refuse to do anything else until that is done. That annoys people when they have to sit and wait. On the other hand, we could just buffer it in RAM, then immediately pretend to be done and let the user get right back to work, meanwhile slowly spooling it to the hard drive (or printer) in the background. That annoys people who just want to kill the power and go home for the day, and then they discover that the file wasn't really saved (or wasn't completely printed).

(EditHint: Help me find the URI. I've been told that most Unix systems force a fflush() every 30 seconds. Somewhere I read that fflush() was written after someone noticed that some very early (mainframe ?) operating system always lost *lots* of data when the power went out. The disk-cache was working *too* good -- once the directory information was loaded into RAM, because it was constantly accessed, updates to the directory were *never* written to disk. Then when the power came back up, the only directory information on the disk was extremely stale -- the files were (probably) on the disk, but there was no way to find them without the directory information).

The Rio File Cache: Surviving Operating System Crashes
Peter M. Chen, Wee Teck Ng, Subhachandra Chandra, Christopher Aycock, Gurushankar Rajamani, David Lowell
http://www.eecs.umich.edu/CoVirt/papers/rioFileCache.pdf
http://research.compaq.com/wrl/people/dlowell/papers/rioFileCache.ps

UncivilizedShutdown
http://www.halfbakery.com/idea/Uncivilized_20Shutdown

----

CategoryUserInterface