Hacker News new | past | comments | ask | show | jobs | submit login

I learned the rules back in the days of MS-DOS and slow as heck floppy drives, so you might want to adjust them a bit.

  1. The user should always see some form of acknowledgement to their input in a few seconds.
  2. There should never be more than 30 seconds between proof of life. (The Windows "this program is not responding" message is a lie, and needs to go). This is why we had spinning cursors...  -/|\-/|\- repeat
  3. There should always be a "Press F1 for Help" somewhere on the screen
  4. Never allow the user to express an invalid state... don't enable the "submit" button until all the required fields are valid.
  5. Never make a user type data more than once, each data entry step is a source of errors.
  6. If possible, run the User Interface in its own thread, so that it always responds in less than 50 milliseconds.
  7. When communicating with a remote device, never lose data because the connection was broken, always be able to recover if the connection is re-established, and restarted.



These are good. Some, like 4 and 5, I take for granted although I shouldn't. 7 is great; I admit I've all but given up on interfaces' ability to do this; I've grown too accepting of stalled processes that require blunt intervention from the user, like reloads, force quits, and reboots.

But immediate feedback seems like low-hanging fruit; If 90s me could see how slow basic user interfaces responded 30 years in the future he would be shaking his head. We've all grown complacent.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: