Moved from UserManualIsAnAntiPattern
This list is doubtless controversial:
- All operations [can be] guaranteed reversible.
- No deletions of network files
- The SpikeSolution for a feature might not be guaranteed reversible, but with some thought, it can be made reversible.
- That is more of a general feature than a UI feature. The implimentation may require a lot of stuff not related to the UI.
- All operations [can be] guaranteed harmless.
- Harmless is relative, and not always practical. For example, it is often not possible to undo a sales transaction or money withdrawal from an ATM machine (see BankMoneyTransfer).
- The context of each command [can be] obvious within the application.
- There is enough room in the UserInterface, that beginning users can see more explanatory buttons and menus, and advanced users can take shortcuts.
So. . . basically a CLI/console/xterm is a bad UI?
- Not all the commands can be reversed
- You can delete network files
- The operations are not harmless
- The context isn't obvious unless you check the path also
- There are no buttons, menus, or 3d views
To whoever put "disk defragmentation" in the above lists: disk defragmentation seems irrelevant to this. It's analogous to GarbageCollection and HeapCompaction?; these are background implementation details that should never even be seen by the user. Even on OSes that require the user to manually initiate disk defragmentation (and need it frequently because of the filesystem's design being unusually susceptible to fragmentation) there is no conceivable reason to want to re
fragment the disk, as file contents are not altered.
Actually, you might want to undo the defragmentation. Sometimes the defragmentation actually makes the fragmentation worse. For example, the paging file might wind up more fragmented after defragmentation than before.
That's why on an operating system like Microsoft Windows the default defragmentation tool will not touch the paging file. I think the list above applied to GUI not necessarily UI in general
I'm pretty sure the list above applied to UI in general. What it doesn't apply to is inherently broken systems like Windows filesystems. Ext2fs and Ext3fs don't have defragmentation tools, or if they do then they're never used. And logging filesystems have automatic compactors. So defragmentation is simply a non-issue.
-
- Once upon a time, I was seriously pursuing a career in recording engineering, focusing on the digital recording. Hardware then not being quite what it is today, one was quite often pushing the limits of how many tracks could be recorded and played back at the same time (processing and bandwidth; the hardware to actually do multiple channel recording was another issue). It was quite common to have a project with (say) 12 tracks playing back fine after they were recorded, but a few weeks later, they simply would not play. The culprit in most cases was that a defragment had occurred at some point, removing the necessary interleaving of the audio files.
-
- You see, when you record 2 tracks at the same time, the data from the two tracks will be interleaved on the disk, even though the tracks are in separate files. This 'fragmentation' ends up making playback involving those two tracks much more efficient. When you have 12 tracks, many of those tracks will have been recorded at the same time as others, and so the load on the drive (mainly seek times) ends up equivalent to only 8 or 9 tracks.
-
- There were many utilities (often built into the application; and this (may) still be common) for re-interleaving tracks after defragmentation or copying, in order to provide exactly that: a manner to refragment the disk.
-
- -- WilliamUnderwood
CategoryUserInterface