UI Design: The principle of grammar

While looking for information to "backup my personal research" on UI Design (and its relation with the underlying object graph an persistence mechanisms) I found this page "A Summary of User Interface Design Principles". And I got particularly interested in the 8th principle The principle of grammar: A user interface is a kind of language -- know what the rules are.

That principle says that the two most common grammars are known as "Action -> Object" and "Object -> Action". In Action->Object, the operation (or tool) is selected first (Similar to Edit then List?) and in "Object -> Action" the object is selected first and persists from one operation to the next (Similar to List then Edit?).

On the other hand this two "most common grammars" are IMHO not exactly "data manipulation oriented (DMO)", because the principle states that in "Action -> Object": When a subsequent object is chosen, the tool immediately operates upon the object. The selection of the tool persists from one operation to the next, so that many objects can be operated on one by one without having to re-select the tool. And in a typical DMO you do not choose the "edit" tool and then apply it to an list of different objects... so this grammar seems to apply more to a typical "tools for editing documents" kind of UI. But Object -> Actions matches better with List (You have to select an object) then Edit (The action).... I will have to look more in to this...

Another principle that is related to my doubts in UI Design is the 10th (and it is specially related to UI Design: When do you save?) is "The principle of safety: Let the user develop confidence by providing a safety net" according to this principle, the UI should provide a safety net for new users, but provide the option to "work in unsafe mode" for the advanced users. I think that the most important feature a program should provide is a "a safe cancel button that really cancels" and an "undo mechanisms" (because, as much as we would like the user to pay attention to our message box, the truth is that both novice and advanced users dismiss them without to much care, and after that, only "Undo" can save them)

The principle of context -- Limit user activity to one well-defined context unless there's a good reason not to (11th) IMO is more related to the modality of an UI that the 8th... perhaps because in general I tend to use modal windows when I want the user focused in a particular context, and I don't want him to "click around" and do possible conflicting actions (like trying to delete the record he is currently editing)

I also liked the 14th principle: "The principle of humility -- Listen to what ordinary people have to say" it reminded my that I have to pay attention to the user (A single designer's intuition about what is good and bad in an application is insufficient. Program creators are a small, and not terribly representative, subset of the general computing population.), but that the user is not the owner of all the answers: "One must be true to one's vision. A product built entirely from customer feedback is doomed to mediocrity, because what users want most are the features that they cannot anticipate."

The only thing I didn't liked about this principles were the examples, they were all about the typical "document editing UIs" like Word processors, Painting programs, etc, and not about data manipulating applications(applications built on top of CRUD and transaction principles) Mmmmm, perhaps I should write my own examples and post them here... If you have an example, please, share it with me...