On 10/17/07, Oleh Kovalchuke <[EMAIL PROTECTED]> wrote: > > Colloquial, informal and elusive (also personal as well as 'my 2 cents'): > > "Delete" is final (barring "undo"), removes the item completely, from all > lists. > "Remove" - removes the item from the current list (other lists might still > contain the item). > > Oleh
----- You will all love my first answer - it depends. And there is no consistent rule. Examples: rm on a unix/linux file system does a very specific thing. Users of those OSes know what to expect. People not familiar with rm wouldn't have learned it and probably aren't to be bothered learning x-nix systems. Since as long as my first Mac - file management introduced the trash can metaphor. You didn't remove a file - you sent it to the trash, but you could decide to take things out of the trash which restored the file, or 'take out the trash' which meant completely deleting a file. MS copied that metaphor and changed labels, but the context/content/user expectation remained about the same. Gmail uses the term "delete" to actually remove from list, and move to trash - where you then have to select all and delete the trash as well. I won't belabor that point since most of us have used gmail. Delete on an OSes files system does the same thing. There are at least a few other examples where GUI based OSes have taken one route. This of course is very different when you are talking about a relational database, but this is not a dbase discussion list, so we can ignore that. Semantically - and to some degree philosophically - I think the two have different meanings. Unfortunately - that is moot since most thick client apps, thin client apps, web-apps, and every flavor of OS takes a different route depending on the mood, intellect, assumptions, caffeine level, and a host of other issues when the "Foo," thing is being designed by whoever designed it. So perhaps we should discuss 'best practices,' by that I mean the following: - Allow an action to be undone. Robust Undo, in other words. - Allow the user to recover from a mistake. Clearly communicate that. - Use labels on action commands that more closely match a tested group of user's mental model as to what might actually happen if they do something. See Norman "User Centered System Design," to understand what I am talking about here. - Don't annoy the user with nagging comments if it's a recoverable action. When I turn off the car, it does not pop up a display on the dashboard asking me if I am sure - because I can easily recover (I know that's not true driving down the highway). I suppose the key is context of action, content action acts upon, and expectation of user based on user profiles. Those are my 2 cents (if that). -- ~ will "Where you innovate, how you innovate, and what you innovate are design problems" ------------------------------------------------------- will evans user experience architect [EMAIL PROTECTED] ------------------------------------------------------- ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://gamma.ixda.org/unsubscribe List Guidelines ............ http://gamma.ixda.org/guidelines List Help .................. http://gamma.ixda.org/help
