smooj

Broad elevator-pitch-level ideas may well be of little value, but specific ideas about strategy for a given organization at a given time are hugely valuable. There is a significant difference betwen the ideas person who just spouts out 'x for y' type product ideas, and the ideas person who is always coming up more effective processes for getting work done and achieving goals.

He was VP of Engineering at Yahoo before he left, so it stands to reason that he was applying for a very senior role.

I think those constraints are often the same as when you create a new record, so you can reuse code from there. But I'm sure there can be edge cases that make it tricky for some apps and/or situations.

Undo and redo aren't important features for every web app - in some they would't make sense at all - but for applications that facilitate any kind of creative process, such as photo editing, 3d modeling, or drawing, they are very important features to include. Users often want to try out an idea, then go back to an earlier version if the idea doesn't work out. In most cases for apps like these implementing undo/redo gives you a ton of usability bang for your proverbial buck.

I'm not sure about the legal implications either, but it would be interesting to know. From a totally different angle it might cause backlash from users if they felt betrayed by an action not actually doing what they thought it would do. You'd have to balance the conflicting desires to be able to undo things and have actions do what they say they will do. Maybe a 'trash can' or 'archive' system is the way to go.

Instead of actually deleting a record when a user hits 'delete' just flip a boolean that indicates it is 'deleted'. Then undoing a delete action is as easy as flipping the boolean back. For more complex application state you can keep a stack of state or actions (depending on the application and code) and then push onto the stack as the user performs actions (killing off actions older than a certain point). When the user hits undo pop from the history stack and push onto a second 'future' stack to support redo. I agree with the author that it would be nice if more web apps implemented undo/redo. I Iecently implemented it in an interior design app I was working on and it's really not that hard to do.